Environment variables and secrets on AWS

Why this matters

In Course 3, you learned that API keys and database passwords never belong in your code. On Vercel, you put them in the dashboard's environment variables section. On Fly.io, you use fly secrets set.

AWS has two services for this: SSM Parameter Store and Secrets Manager. They do similar things, but they are priced and designed differently. This lesson covers both so you can pick the right one.

SSM Parameter Store

SSM stands for Systems Manager. Parameter Store is one feature within it. It stores configuration values as key-value pairs.

Step 1: In the Console, search for "Systems Manager" and open it.

Step 2: In the left sidebar under Application Management, click Parameter Store.

Step 3: Click Create parameter.

Step 4: Enter a name. Use a path-style naming convention so your parameters stay organised:

/myapp/production/DATABASE_URL
/myapp/production/API_KEY
/myapp/staging/DATABASE_URL

Step 5: Choose the type. String for non-sensitive config (like a public API URL). SecureString for secrets (like database passwords and API keys). SecureString encrypts the value using AWS KMS.

Step 6: Enter the value and save.

What you should see: Your parameter listed in Parameter Store with the type and last modified date.

Parameter Store's standard tier is free for up to 10,000 parameters. For most applications, you will never hit that limit.

Secrets Manager

Secrets Manager is more expensive ($0.40 per secret per month) but adds features that matter for production systems: automatic rotation, cross-account access, and integration with RDS for database credential rotation.

Use Secrets Manager for database credentials that you want to rotate automatically. Use Parameter Store (SecureString) for everything else. This split keeps costs low while using the right tool for each job.

The setup process is similar. Search for "Secrets Manager" in the Console, click Store a new secret, choose the secret type (typically Other type of secret for API keys, or Credentials for Amazon RDS database for database passwords), enter the key-value pairs, and give it a name.

Injecting secrets into ECS tasks

Your secrets are stored. Now your containers need to read them without the values appearing in your task definition.

Step 1: Open your ECS task definition and create a new revision.

Step 2: In the container definition, find the Environment variables section.

Step 3: For each secret, set the key to the environment variable name your application expects (e.g. DATABASE_URL). Set the value source to ValueFrom and paste the ARN of the SSM parameter or Secrets Manager secret.

ECS will fetch the secret at container startup and inject it as an environment variable. The value never appears in the task definition itself.

Step 4: Your task's IAM role needs permission to read the secrets. Go to the task execution role in IAM and add a policy that allows ssm:GetParameters for Parameter Store or secretsmanager:GetSecretValue for Secrets Manager. Scope the policy to the specific parameter ARNs your task needs, not a wildcard.

What you should see: Your container starting successfully and your application reading the environment variables as normal.

For S3 and CloudFront frontends

Static frontends do not have a runtime environment. They cannot read secrets at startup the way a backend container does.

If your frontend needs API keys (like a public Stripe publishable key or a Google Maps key), those values need to be baked into the build. Your build process should read them from environment variables and embed them in the JavaScript bundle.

REACT_APP_API_URL=https://api.yourapp.com npm run build

Only put genuinely public values in your frontend build. Private keys, database credentials, and anything a user should not see must stay on the backend.

Verifying your setup

After configuring secrets:

1. Deploy a new revision of your ECS task.
2. Check the task logs (Lesson 6 covers this in detail). Your application should start without "missing environment variable" errors.
3. Confirm your application behaves correctly by testing the features that depend on those secrets.

If a container fails to start after adding secrets, the most common cause is the task execution role missing the permission to read the secret. Check the task's stopped reason in the ECS console. It usually tells you exactly which permission is missing.