Start with one small stack, inspect its CloudFormation template, deploy it into a sandbox, and remove it deliberately. Once that loop makes sense, choose the networking and application examples that match your workload. You do not need a database, container platform, and pipeline in your first deployment.
This guide organizes the blog's AWS CDK examples by the decisions you need to make. It is a reading path, not a claim that every example forms one application or has been deployed against your account.
1. Understand the deployment loop
Begin with what AWS CDK is, then use these focused references:
| Question | Guide |
|---|---|
| What does synthesis produce? | cdk synth and the cloud assembly |
| Why does an environment need bootstrapping? | cdk bootstrap |
| Which stacks are in my app? | cdk list and environment information |
| What will a deployment change? | cdk diff |
| How do I deploy several stacks? | deploying all stacks |
Use a sandbox account, confirm the CLI identity and region, and inspect the diff before applying changes. Compilation does not establish cloud permissions or deployment success.
2. Work with values and ownership
Read tokens when a name or ARN is unresolved during synthesis. Use outputs and cross-stack exports to inspect deployed identifiers and design explicit interfaces. Read context and cached lookups when account discovery and reproducibility matter.
Dependency ordering explains when references already establish creation order and when an explicit dependency is justified. Resource creation order is different from application readiness; retries, health checks, and migrations still need design.
3. Choose the network you actually need
Use VPC creation for a new network or VPC import when another stack already owns it. Then read subnet selection and subnet tagging.
A subnet selector does not provide missing routes or authorize traffic. For a private Lambda workload that needs outbound access, follow Lambda VPC internet access. Account for NAT, endpoints, and public-address costs explicitly.
4. Pick one application exercise
| Your goal | Suggested example | What to examine |
|---|---|---|
| Small HTTP backend | Lambda and HTTP API | Handler packaging, integration, and public access |
| Static frontend | React, private S3, and CloudFront | Origin access control and route fallback limits |
| Private relational database | RDS PostgreSQL and EC2 | Credentials, network rules, backup and deletion policies |
| Container service | Fargate with a load balancer | Task networking, image versions, and health checks |
| Tool server | Python MCP on EC2 | Transport, local verification, and authenticated access |
| GraphQL application | AppSync notes application | Schema, resolver packaging, and data access |
For Lambda dependencies, compare npm packages and layers with container images.
5. Review permissions and operations
IAM users and scoped policies explains a user-specific example and why workloads should generally use roles. S3 bucket policies covers resource permissions. S3 CORS addresses browser behavior, which is separate from authorization. SES configuration separates infrastructure creation from sending a message.
Before cleanup, inspect retained storage, snapshots, logs, and resources shared with other stacks. Before production, establish recovery requirements, monitoring, runtime updates, and deployment review. The official CDK developer guide remains the reference for supported behavior.
If your team is choosing a different infrastructure tool, compare the workflow with the Pulumi introduction and Terraform fundamentals.
Comments
Share your thoughts and questions below