Separate Dev and Prod Configuration with Environment Variables and Stages
Learn how to decouple your code from your configuration using Lambda environment variables and API Gateway stages.
Some services in this lesson have no free tier and will incur charges.
AWS Services Used
You can complete most of this lesson using only Lambda environment variables (free). Secrets Manager is the recommended upgrade for sensitive values but incurs charges.
Learning Outcomes
By the end of this lesson, you will be able to:
- Explain why dev and prod should not share the exact same configuration.
- Use Lambda environment variables to change behavior without changing code.
- Explain what an HTTP API stage is and why
devandprodare useful. - Use stage variables for non-sensitive configuration.
- Explain why secrets should not be stored in plain environment variables.
Why this lesson matters
Right now, your project probably has one set of values hard-coded or copied around: one API URL, one bucket name, one table name. That works while learning, but it's risky for real apps.
A dev environment should let you test changes safely, while prod stays stable. Use this golden rule:
Code stays the same; Configuration changes by environment.
Part 1: Lambda Environment Variables
Lambda environment variables are key-value pairs stored in your function configuration. They let you use the same code to talk to different resources.
Example Setup
Instead of hard-coding my-bucket-name in your Python code, use os.environ["UPLOAD_BUCKET"].
| Variable | Dev Value | Prod Value |
|---|---|---|
TABLE_NAME | metadata_dev | metadata_prod |
UPLOAD_BUCKET | my-app-dev-uploads | my-app-prod-uploads |
URL_EXPIRES | 300 (5 mins) | 3600 (1 hour) |
Part 2: Don't Store Secrets in Env Vars
AWS recommends Secrets Manager instead of plain environment variables for sensitive values like API keys, database passwords, or private tokens.
- Normal Config: Bucket names, table names, stage names (Use Env Vars).
- Sensitive Secrets: Credentials, private keys (Use Secrets Manager).
Part 3: HTTP API Stages
In API Gateway, a stage is a named reference to a deployment of your API (e.g., dev, prod, v2). The stage name appears in the URL:
https://abc123.execute-api.us-east-1.amazonaws.com/dev
https://abc123.execute-api.us-east-1.amazonaws.com/prodPart 4: Stage Variables
Stage variables are key-value pairs attached to an API stage. They act like environment variables for your API definition. They are useful for passing different metadata to your Lambda integrations without changing the API routes themselves.
Warning: Like Lambda env vars, stage variables are not intended for sensitive data.
Part 5: Frontend Environment Separation
If you host your frontend in Amplify, you can use branch-specific overrides.
- The
devbranch of your code can be built with thedevAPI URL. - The
mainbranch can be built with theprodAPI URL.
This ensures your test site never accidentally writes data to your production bucket.
Lab Checklist
| Step | Success Condition |
|---|---|
| Decouple Code | Code uses os.environ instead of hard-coded strings |
| Add Env Vars | Variables are configured in the Lambda console |
| Create Stages | API has at least two stages (e.g., dev and prod) |
| Deploy | Changes are deployed to specific stages |
| Verify | Dev URL and Prod URL return data from different sources |
Micro-activity 1: Configuration Map
Fill out your project's configuration for each environment. Your answers are saved in your browser.
Micro-activity 2: Reflection
Think about it
Why are Lambda environment variables better than hard-coding table names? Why should stage variables not be used for database passwords?
Summary
In this lesson, you moved from a single "toy" setup to a professional environment-aware architecture. Decoupling code from configuration using Lambda environment variables and API stages is a fundamental requirement for scaling applications safely in the cloud.