Where to Save ECS Fargate App Configurations Without Terraform Overhead

Question

Hi everyone,
I’m running an ECS cluster on Fargate, and I’m trying to find the best way to manage application configuration.
My current setup:
Sensitive config (e.g. secrets, tokens): stored in SSM Parameter Store
Non-sensitive config (e.g. feature flags, settings): stored in S3
These values are read by the ECS task during startup. However:
Problems I'm facing:
I manage all infrastructure using Terraform, so each time I update a config value, a new parameter or S3 file update triggers unnecessary Terraform churn.
Over time, this has made the infra codebase bloated, and terraform plan has started to slow down.
Also, when I update a config (in S3 or Parameter Store), I need to manually restart the ECS service to pick up the new values.
Questions:
Is there a better way to store and update ECS app configuration without creating new secrets every time?
How can I make config updates apply without needing to restart ECS services manually?
Should I separate config from Terraform entirely? If so, what’s the best practice for this?
Appreciate any insights or patterns that have worked well for you!

M Zubair Bin Ramzan · Answer

✅ Problem 1: Terraform Overhead for Config Updates
🔥 Why It Happens:
Storing configs (like JSON files in S3 or strings in SSM) via Terraform makes every change part of the infra state, causing:

Slow terraform plan
Bloated state files
Unnecessary apply overhead

✅ Recommendation: Decouple Config from Terraform
Terraform should manage infrastructure, not dynamic app-level config.

🔄 Instead, use a separate workflow or tool (like a script or CI/CD pipeline) to manage config changes:
Option A: Use aws ssm put-parameter and aws s3 cp

Use CLI or SDK to update parameters or config files without Terraform.

Example:

aws ssm put-parameter \
  --name "/myapp/config/feature-flag" \
  --value "true" \
  --type "String" \
  --overwrite

Option B: Use a GitOps-style repo just for config

Store JSON/YAML config in a config-repo, then use a script or GitHub Action to sync it to S3 or SSM.

✅ Problem 2: Manual ECS Restarts After Config Changes
By default, ECS tasks only read environment variables at container startup, so updated config values in S3/SSM won’t be picked up unless the task is restarted.

✅ Solutions:
🌀 Option 1: ECS Sidecar or Startup Script to Pull Config at Runtime
Have your app fetch config from SSM or S3 on boot rather than passing as environment variables.

Pros: No need to restart ECS task if the app polls or pulls config at runtime. Cons: Adds complexity; app must handle config updates gracefully.

♻️ Option 2: Force ECS Task Refresh via CI/CD
After a config change, trigger a new ECS deployment, even with the same container image.

Example using aws cli:

aws ecs update-service \
  --cluster my-cluster \
  --service my-service \
  --force-new-deployment
Automate this step as part of your config deployment pipeline.

🛠️ Option 3: Use AppConfig + Lambda Integration (Advanced)
AWS AppConfig is purpose-built for dynamic config management with validation, versioning, and deployment strategies.

AppConfig stores config (JSON, YAML, etc.)
Can integrate with S3 or SSM
Supports gradual config rollout
Optionally use Lambda, CloudWatch, or CodePipeline to trigger ECS restarts
Consider this if you're scaling or need more governance.

Regards
M Zubair Bin Ramzan
https://zeonedge.com

Where to Save ECS Fargate App Configurations Without Terraform Overhead

Add your answer

Relevant content