CDK Aspects

[eladb]

Environments define some abstract "place" where a copy of a piece of software is deployed (for now, let's leave it undefined what the mapping between Environments and accounts/regions is).

We'll probably want to define some cross-cutting concerns that are particular attributes of individual environments. Some potential use cases:

COMPLIANCE (for prod environments)

• All data must be encrypted at rest (HIPAA (?))
• Data may not be replicated outside its geographical region (GDPR)
• CloudTrail must be enabled for all events, all logs are sent to another account

COST/CONVENIENCE (for dev environments)

• Deployments happen as quickly as possible, vs rolling update or blue/green deployments in prod
• environment.cheap == true, only start 1 instance instead of multiple, smaller instance sizes, lower provisioned throughput, ...

We'd want to toggle these things on a per-environment basis. Would be ideal if we could enforce them without Construct support. Would be even better if we could enforce/validate them (maybe using AWS Policy?)

CDK aspects can be attached to constructs and can register to events such as afterAddChild, beforeValidation, beforeSynthesis, afterSynthesis. Aspects can inspect the tree or synthesized artifacts and perform validations or apply policy on the tree.

Example of aspects:

• Enforce usage of free tier capacity
• Add tags
• Enforce security policy (i.e. no ""/"" IAM policies)
• Verify that IAM policies were not widened without permissions (i.e. compare IAM policies to a checked in version)

[Add yours]

[luistapia6-11]

This is really interesting! Will we be able to run test against the code for compliance? For example, if corp policy is that no IGW shall be attached to VPCs, if the code fails, it does not deploy the stack?

[eladb]

Yap. That’s the idea. Great example!