Proposal: Store app context in Parameter Store

CDK uses contexts to store data that is generated the first time an application is run, for use in subsequent application invocations. These contexts contain information such as AMI IDs, availability zones, and so forth. Such storage is needed in order to preserve dynamic values that might change in a later query. Preserving these values prevents an otherwise-working stack from being unnecessarily modified, risking downtime or other availability issues.

Currently the context data is stored in cdk.json in the app’s home directory. Sharing of this data between users is currently done by committing the file into the app’s source code repository. However, this leads to several risks:

1. There’s no requirement that the file be committed
2. The file may be committed and pushed upstream, but there’s no synchronization mechanism: nothing prevents Betty from running cdk deploy without having first downloaded the changes pushed upstream by Abigail
3. If the file is committed, context must be sanitized before making the application public

Instead of keeping this state in the repo, I propose we keep it in SSM Parameter Store instead. It’s purpose built for sharing this information; it’s inexpensive; and better still, its data is scoped by region + account. It resolves all of the problems above AFAICT.

Is anyone aware of any drawbacks to this approach?

[rix0rrr]

No, this is very likely a good idea for multiple reasons. And it meshes well with CloudFormation’s “state lives in the cloud” philosophy.

Thanks for writing it down so lucidly.

[cynicaljoy]

I’d imagine this would need to be configureable within the cdk.json as some teams restrict SSM - but I would take advantage of this. We’re currently adding the context file to the .gitignore as some of our values that we pull from SSM are protected, so if the app context was stored in SSM we’d gain version history and could manage the access there of with IAM.