How and when is cached context data populated and updated, especially in relation to CDK Pipelines involving multiple environments?

[jmm]

Hello,

The "Runtime Context" and CDK Pipeline documentation seem light on details about the caching of AWS account data.

• When is the cache potentially populated / updated? On any synthesis that has access to the AWS account and references account data that hasn't been referenced before (or that has been deleted from the cache)? When bootstrapping via CDK?

• If you provision a CDK Pipeline in one account or region to deploy to one or more other environments (account or region) and the app depends on account context data, don't you need to get account data for the deployment environment(s) populated into cdk.context.json before you can deploy via the pipeline? How do you do that?

• The CDK Pipeline documentation says:

  Use administrative credentials only to bootstrap and to provision the initial pipeline. Drop administrative credentials as soon as possible.

  Now that you've done the initial deployment, you no longer need AWS administrative access.

  Credentials for production environments should be short-lived. After bootstrapping and initial provisioning, there is no need for developers to have account credentials; all changes can be deployed through the pipeline.

  But does that account for caching of account data related to addition of resources?

  Let's say you create version 1 of a CDK app with a pipeline and it just deploys a Lambda (and for the sake of simplicity let's say there's one deployment environment and the pipeline is provisioned in that environment). So you bootstrap and provision the pipeline and then drop admin credentials.

  Then you create version 2 that just changes the Lambda code and the changes can just be deployed through the pipeline.

  But then let's say you create version 3 and use ec2.AmazonLinuxImage or Vpc.fromLookup. Don't you need to do something outside of the pipeline to get new account data cached in cdk.context.json?

• I'd encourage explaining the AMI part better:

  The AWS CDK uses context to cache information from your AWS account, such as the Availability Zones in your account or the Amazon Machine Image (AMI) IDs used to start your instances.

  The project file cdk.context.json is where the AWS CDK caches context values retrieved from your AWS account. This practice avoids unexpected changes to your deployments when, for example, a new Amazon Linux AMI is released, changing your Auto Scaling group.

  I would expect to need to specify AMIs and therefore they couldn't unexpectedly change.

  I'm reading this document to understand the dynamics of the caching and how that impacts the workflow you need to use and this part makes it harder to understand because it doesn't explain how and why AMIs would be cached or could change in the first place.

  You have to dig into the Auto Scaling construct documentation to find that there are functions for using the latest version -- but that actually use a cached, non-latest version in the future.

• Also, the "Runtime Context" documentation says:

  The project file cdk.context.json is where the AWS CDK caches context values retrieved from your AWS account. [...] The AWS CDK does not write context data to any of the other files listed.

  But the "Amazon EC2 Auto Scaling Construct Library" docs say:

  NOTE: The Amazon Linux images selected will be cached in your cdk.json [...]

[ghost]

To address your last point, it used to be that context data was in cdk.json along with everything else. This was changed at some point but I think that EC2 Auto Scaling README was simply not updated. That'll be an easy fix. :-) I'll look into the rest.

[jmm]

Thanks @Jerry-AWS!