AWS 383: Deploy the same approved environment through CloudFormation and CDK
Why this lesson matters
CloudFormation YAML and CDK can express equivalent outcomes while exposing different source abstractions, defaults, generated resources, dependency graphs, asset behavior, tests, and upgrade risks. This lab compares them fairly by one approved architecture and one acceptance contract, never by line count alone.
Approved environment contract
Build two isolated copies, raw and cdk, in the same sandbox Region. Each must contain a VPC, two private subnets across Availability Zones, route tables, restrictive security groups, encrypted S3 bucket with public access blocked/versioning/lifecycle, KMS key, least-privilege workload role, log group with retention, SNS alarm topic, parameters/tags, and nonsecret outputs. Do not couple either copy to the other.
| Dimension | Required comparison evidence |
|---|---|
| Functional | Same resource behavior and negative tests |
| Security | IAM, encryption, public access, network paths |
| Resilience | AZ placement, retention, replacement effects |
| Generated resources | Full processed-template inventory |
| Identity | Logical/physical IDs and rename behavior |
| Reproducibility | Pinned tools/context and template hashes |
| Operations | Diff/change set, drift, update, rollback, delete |
| Cost | Exact created resources and retained residue |
Source and synthesis procedure
Write the raw template first from the contract, not by copying synthesized CDK. Validate/lint/policy-test it. Build a pinned TypeScript CDK app using L1/L2 constructs, typed configuration, committed lock/context, assertions, and no secret. Run npm ci, tests, cdk synth, lint/policy/security checks against generated templates, and compare inventories/property values.
cfn-lint raw/template.yaml
aws cloudformation validate-template --template-body file://raw/template.yaml
npm ci --prefix cdk
npx --prefix cdk cdk synth --all
npx --prefix cdk cdk diff '*'
sha256sum raw/template.yaml cdk/cdk.out/*.template.jsonAccount access is optional. On the evidence track, use supplied templates/change sets/events. On an approved live track, set a budget and teardown timer, verify caller/account/Region, use unique names/tags, create change sets, inspect IAM/replacement, then execute one stack at a time. Never deploy into production.
Equal verification and lifecycle
Use the same assertions on both outputs: resources/types, encryption/key policy, bucket controls, IAM action/resources/conditions, security-group directions, logging, retention, tags, deletion/update-replace policy, outputs, and cost. CDK defaults may be safer or broader, but document rather than silently normalize them.
Build a normalized comparison table keyed by architectural purpose rather than logical ID, because generated names differ. Mark every difference as intentional, abstraction default, unsupported parity, or defect. Compare dependency edges and deployment order as well as properties. Verify that both implementations expose the same supported operator inputs while rejecting invalid CIDRs, retention periods, environment names, and privileged role selections before deployment.
Run positive/negative runtime tests: approved principal can use allowed operation; unauthenticated/public access fails; denied IAM action fails; logs appear; alarm can be tested safely; cross-AZ design is visible. Match stack, commit, template hash, physical resources, CloudTrail actor, and test results.
Perform three reviewed updates: a nonreplacement tag/log change, a property that could replace a resource, and a security tightening. Create change/drift-aware evidence before execution, inject one rollback-trigger alarm in the supplied/live-safe path, and verify final state. Make one approved out-of-band test change, detect drift, then reconcile through each owner independently.
Record update duration, API failures, resource replacement, temporary capacity, rollback events, and any retained physical resource. After rollback, rerun the negative security tests and compare physical IDs to the pre-change inventory. A stack status of complete is insufficient when an old bucket, key, role, or network interface remains outside expected ownership.
Cleanup in dependency order through stack deletion, respecting retained resources. Inventory buckets/versions, KMS aliases/keys, logs, ENIs, snapshots, alarms/topics, roles, CloudFormation stacks, CDK assets/bootstrap, and tags. Do not delete shared CDKToolkit; record it separately and remove only if exclusively created and unused.
Failure matrix
Diagnose 18 cases: YAML/schema, circular dependency, missing capability, IAM deny, quota, name collision, CDK version/context change, logical-ID rename, hidden generated role, bootstrap absent, asset KMS denial, change-set replacement, rollback alarm, rollback failed, drift overwrite, negative test unexpectedly passes, delete blocked, and retained cost. Record first event, cause, repair, retry safety, user/data effect, and prevention.
Acceptance
Submit the contract, both sources, locks/context, source and generated validation reports, normalized resource/property diff, IAM/security comparison, change sets, equal runtime tests, three updates, drift/recovery, failure matrix, cost, and two-pass cleanup. Pass requires equivalent approved outcomes, honest abstraction differences, generated-template review, traceability, and zero unowned live resource.