For ECS workloads, the cleanest pattern is to treat password rotation and secret delivery as two separate concerns:

Secret Rotation happens in AWS Secrets Manager, while delivery to containers happens through ECS task roles and either secret injection or runtime retrieval. 

AWS explicitly recommends Secrets Manager when you need lifecycle features like automatic rotation; Parameter Store can hold sensitive values, but it does not provide automatic rotation by itself.

For database passwords and system-account credentials that must rotate automatically, store them in Secrets Manager

Enable either managed rotation or Lambda-based rotation, and make the application fetch the secret from Secrets Manager at runtime when possible. Rotation in Secrets Manager updates both the secret and the underlying credential on the target service or database, and Secrets Manager versions the secret using labels such as AWSCURRENT, AWSPREVIOUS, and AWSPENDING.

For ECS specifically, be careful with the common pattern of injecting secrets as environment variables in the task definition. AWS notes that if a secret is injected as an environment variable, a running container does not automatically receive the updated value after rotation; you must launch a new task or force a new deployment so the fresh value is picked up.

So in practice, the safest production approach is usually:

  1. Keep the secret in Secrets Manager

  2. Grant the ECS task role GetSecretValue access only to the needed secret

  3. Fetch the secret at application startup or on-demand, instead of hard-injecting it once as an env var

  4. Use caching with a short TTL if you want to reduce Secrets Manager calls

  5. Rotate the secret in Secrets Manager

  6. Let the app refresh the secret from Secrets Manager without requiring every rotation to restart the service

There are two patterns which can be used for Secret Rotation:

Pattern A: env-var injection into ECS task definition
This is simple and works well for secrets that rarely change. ECS can inject values from Secrets Manager or Parameter Store into container environment variables. But after rotation, the running task still has the old value until you replace the task. This pattern is fine for low-frequency rotations if you pair it with a controlled ECS rolling deployment.

Pattern B: Runtime retrieval from Secrets Manager
This is better for APIs and system accounts that rotate regularly. The application or a sidecar/agent fetches the current value from Secrets Manager using the task role. With this model, the app can refresh credentials on a timer, on auth failure, or through a small cache TTL. That avoids tying every rotation to an ECS redeploy. AWS recommends caching and supports this pattern through its SDKs and the Secrets Manager Agent

R

Subscribe for more content.

Keep Reading