CDK Notes

Bootstrap

cdk bootstrap aws://${accountId}/ap-southeast-1 --trust ${trustedAccountId}

Create CDK project manually

Create CDK project manually, see project tenant-api for example.

mkdir packages/tenant-api
cd packages/tenant-api
npx aws-cdk init app --language=typescript

# copy tsconfig and .eslintrc.json from project tenant-api
cp ../tenant-api/tsconfig.json .
cp ../tenant-api/.eslintrc.json .

# remove unused package-lock.json
rm package-lock.json

# create and modify package.json and project.json
# inside package.json: remove dependencies, remove devDependencies, add scripts
# you may copy tenant-api/{package.json,project.json}, then use them as a starting point
code package.json
code project.json

Prefer to resolve with parameter rather than LookupValue

Avoid using StringParameter.valueFromLookup and HostedZone.fromLookup for the reason that they are resolved during synth.

Prefer StringParameter.valueForStringParameter and HostedZone.fromHostedZoneAttributes so that they are resolved runtime during deployment. We can then use the same Cloudformation output for all the environments (any aws account id/region combination).

cdk.context.json

cdk.context.json contains cache information from lookup functions: HostedZone.fromLookup, StringParameter.valueFromLookup, Bucket.fromBucketName

A CDK application first tries to get lookup value from the cache in cdk.context.json. If it doesn't exist, it'll get it from the environment, and keeps in the cache. Next time when the method is called, it gets it from the cache.

Do not manually add or change the content of cdk.context.json.

CDK Trigger

Triggers allows us to execute code during deployments. This can be used for a variety of use cases such as:

• Self tests: validate something after a resource/construct been provisioned
• Data priming: add initial data to resources after they are created
• Preconditions: check things such as account limits or external dependencies before deployment.