AWS Fargate PV1.3 adds secrets and enhanced container dependency management
AWS Secrets Manager support to specify sensitive information
You can now reference sensitive information in AWS Secrets Manager when using AWS Fargate PV 1.3. This means you can store sensitive information in either AWS Secrets manager or AWS Systems Manager Parameter Store. You can learn more about about it here: Specifying sensitive information to containers.
As you build applications, you need to reference sensitive information such as database credentials, tokens, configuration variables or SSH keys. Previously, you had to directly reference this sensitive information in the task definition or manage your own run-time secrets with custom solutions to decouple secrets from core application logic stored in container images. AWS Fargate now supports task definition conventions for accessing sensitive information stored in either AWS Secrets Manager and AWS Systems Manager Parameter Store.
AWS Secrets Manager support to specify sensitive information
You can now reference sensitive information in AWS Secrets Manager when using AWS Fargate PV 1.3. This means you can store sensitive information in either AWS Secrets manager or AWS Systems Manager Parameter Store. You can learn more about about it here: Specifying sensitive information to containers.
As you build applications, you need to reference sensitive information such as database credentials, tokens, configuration variables or SSH keys. Previously, you had to directly reference this sensitive information in the task definition or manage your own run-time secrets with custom solutions to decouple secrets from core application logic stored in container images. AWS Fargate now supports task definition conventions for accessing sensitive information stored in either AWS Secrets Manager and AWS Systems Manager Parameter Store.
Enhanced Container Dependency management
You can also specify additional task definition parameters that enable defining dependencies for container startup and shutdown as well as a per-container start and stop timeout value using Fargate PV 1.3.
Previously there was no way to ensure that containers start up or shut down in any particular order. Now, a number of common application use cases are enabled. For example, a telemetry sidecar container that must start before and shut down after the other containers in a task, or an initialization container that must complete its work before other containers in the task can start. Containers in a task definition can each have their own startup and shutdown timeouts. This enables new capabilities such as an extended stop timeout for a container that must do complex cleanup operations before it shuts down, without requiring all containers on the same instance to have the same shutdown timeout. To learn more about container dependency management and container timeout parameters, read our documentation.