I'm starting a new AWS CDK infrastructure repository in Python and deciding how to manage values that vary between development, staging, and production. These include account IDs, regions, resource names, and a few environment-specific settings. Right now they're represented by typed Python classes that contain plain configuration values. That gives me early failures for things like invalid account IDs, duplicate names, or other mistakes before synthesis or deployment.
I previously used Terraform, so I'm tempted to switch to a data-oriented approach such as one or more YAML files that can be edited without writing Python. For anyone who has maintained either pattern over time:
- If you use YAML or another data file, do you keep one file per environment or a single file containing all environments? What drove that choice?
- Do you validate the file with a schema before passing it to CDK, or rely on synthesis and deployment to catch errors? Has skipping validation caused problems?
- Have you moved from code-based configuration to file-based configuration, or vice versa? What pain point prompted the change?
I'm committed to using CDK and am only trying to choose a maintainable configuration layer.
4 Answers
For larger multi-account setups, a single environment configuration file can work well if it supports defaults plus increasingly specific overrides. For example, define global settings, then account- or environment-specific values that override them. A shared Environment or Config class can handle loading, precedence, and validation so the stacks don’t know where the values came from.
CDK’s context configuration is another option for a modest number of environment-specific values. It’s built in and can be selected at synthesis time, but it can become hard to manage as the number of environments and settings grows. For values that need to change without a deployment, consider a managed service such as Parameter Store or Secrets Manager, while keeping deployment configuration and secrets out of the source tree.
If you want language-agnostic configuration, start with JSON or YAML and validate it before constructing the stacks. One file containing all environments is convenient when the environment set is small and centrally managed; separate files are safer when access or ownership differs. Either way, don’t rely on raw parsing alone—schema validation restores much of the safety you currently get from typed classes.
I’d keep the typed Python configuration you already have. Catching an invalid account ID or naming mistake when the program loads is a major benefit. YAML looks simpler initially, but without schema validation it usually moves those failures to synth or deployment. If you genuinely need non-Python users to edit the values, add a schema and validation rather than accepting an untyped dictionary.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically