01 Infrastructure as Code (IaC) Core Principles
Architectural PillarsInfrastructure as Code (IaC) replaces manual, error-prone server provisioning and web console clicks with machine-readable definition files managed under version control. In modern cloud platforms, IaC is governed by four non-negotiable architectural tenets:
Deterministic Execution
Executing an IaC template 1 time or 100 times produces the exact same infrastructure end-state. If a resource already exists in the target state, the engine leaves it untouched without recreating or duplicating it.
Replace, Never Mutate
Instead of SSH-ing into instances to hot-patch configuration drift, modern cloud deployments tear down old container tasks or virtual machines and deploy fresh, identical immutable images.
Git-Driven State
Every firewall rule, IAM role, database parameter, and VPC subnet is audited in Git. Rollbacks become simple git revert operations reviewed by team members via Pull Requests.
Automated Drift Detection
Cloud engines continuously compare the declared template against the actual deployed cloud reality, alerting on manual unauthorized changes ("console drift") and restoring expected state.
▶ Declarative vs Imperative / Programmatic IaC
You define the desired final state in static files (YAML, JSON, or HCL). The engine parses the document, builds a Directed Acyclic Graph (DAG) of dependencies, and figures out the sequence of API calls needed.
- Highly predictable and safe; zero side effects
- Can be verbose: 50 lines of YAML just for one secured VPC subnet
- No native loops, abstractions, or conditional composition without cumbersome DSL hacks
You express infrastructure using full modern programming languages (TypeScript, Python, Go, Java). CDK executes your code to synthesize pure declarative CloudFormation under the hood.
- Full IDE autocomplete, type checking, refactoring, and package managers (npm / PyPI)
- High-level constructs (L2/L3) generate 500+ lines of hardened CloudFormation from 5 lines of code
- Enables unit testing with standard test frameworks (Jest, Pytest)
02 AWS CloudFormation: Anatomy, Intrinsic Functions & Change Sets
Declarative Foundation
AWS CloudFormation is AWS's native managed provisioning engine. A template is a JSON or YAML document defining the resources, parameters, and relationships that make up an application stack. The only mandatory section is Resources:.
CloudFormation Top-Level Template Anatomy
Runtime inputs (e.g. InstanceType, Environment) with constraints and NoEcho: true for secrets.
Static lookup tables (e.g. Region-to-AMI IDs or Environment-to-Capacity mappings).
Boolean logic (Fn::Equals, Fn::If) to conditionally provision resources (e.g. Prod vs Dev).
Values returned after stack creation (ALB DNS, S3 Bucket Arn) with optional cross-stack Export.
Production CloudFormation YAML: Secure S3, VPC & ECS Task Role
Demonstrates Parameters, Intrinsic Functions (!Sub, !Ref, !GetAtt), DeletionPolicy, and Encryption.
CloudFormation Intrinsic Functions
!Ref
Returns the value of a parameter or the physical ID of a resource (e.g. !Ref VpcId).
!Sub
String variable interpolation: !Sub "${AWS::StackName}-alb-${AWS::Region}".
!GetAtt
Retrieves specific resource attributes: !GetAtt MyAlb.DNSName or MyBucket.Arn.
!Join
Concatenates a list of strings with a delimiter: !Join [ ":", [ "arn:aws:s3::", !Ref MyBucket ] ].
!ImportValue
Imports an exported value from another stack to establish cross-stack dependencies.
Operational Safety: Change Sets & Drift
Always create a Change Set before updating a stack. CloudFormation previews exact resource additions, updates, and destructive Replacement: True actions before executing.
Run aws cloudformation detect-stack-drift to check if engineers modified security groups or bucket policies manually in the console. CloudFormation reports exact property differences.
Attach CloudWatch metric alarms (e.g. ALB 5xx rate > 1%) to stack creation. If the alarm trips during rollout, CloudFormation automatically rolls back all changes to the prior stable state.
03 AWS Cloud Development Kit (CDK) v2: Mental Model & Construct Tree
Programmable InfrastructureThe AWS Cloud Development Kit (CDK) is an open-source software development framework to define cloud application resources using familiar programming languages. CDK does not bypass CloudFormation; it synthesizes into CloudFormation templates, giving you programmatic composition with the rock-solid rollback guarantees of AWS's deployment engine.
The CDK Tree Hierarchy
The Compilation Container
An App is the root of your CDK construct tree. It coordinates synthesis across all stacks and binds environments (AWS account IDs and regions).
1:1 CloudFormation Stack
Each Stack class synthesizes directly into a single AWS CloudFormation stack template file (up to 500 AWS resources) managed as an atomic unit.
Encapsulated Cloud Components
Constructs represent one or more AWS resources with logic, sensible defaults, and security policies bundled together into composable objects.
▶ Understanding Construct Levels: L1 vs L2 vs L3
Raw Resource Mirror
Prefixed with Cfn* (e.g. CfnBucket, CfnVPC). Auto-generated directly from the CloudFormation resource specification. Requires setting every single required property manually.
const bucket = new s3.CfnBucket(this, 'MyBucket', {
bucketName: 'raw-bucket',
versioningConfiguration: { status: 'Enabled' }
});
Batteries-Included Intelligence
Handcrafted by AWS service teams. Encapsulates best-practice security defaults (encryption enabled, public access blocked). Exposes intent-based methods like bucket.grantRead(role).
const bucket = new s3.Bucket(this, 'MyBucket', {
versioned: true,
encryption: s3.BucketEncryption.S3_MANAGED,
enforceSSL: true
});
Turnkey Systems
Combines multiple services into an entire architecture. For example, ApplicationLoadBalancedFargateService creates an ALB, Target Group, ECS Cluster, Task Definition, and CloudWatch logs in ~15 lines.
new ecs_patterns.ApplicationLoadBalancedFargateService(this, 'Svc', {
taskImageOptions: { image: ContainerImage.fromRegistry('app') },
publicLoadBalancer: true
});
The 6 Core AWS CDK CLI Lifecycle Commands
cdk.out/.04 Production Architecture: AI Agent Microservice in AWS CDK
End-to-End CodeHere is a complete, production-grade AWS CDK implementation provisioning a modern AI Agent service: an isolated VPC with public/private subnets, an ECS Fargate service running behind an Application Load Balancer, an Amazon DynamoDB session memory table, and an AWS Secrets Manager secret holding LLM API credentials.
AWS CDK Implementation (TypeScript)
Uses L2 constructs with automatic least-privilege IAM policy generation (grantReadWriteData, grantRead).
Equivalent AWS CDK Implementation (Python)
Pythonic idioms with identical synthesis semantics and type-safety.
05 Architectural Comparison: CloudFormation vs AWS CDK vs Terraform
Tool EvaluationChoosing the right IaC tool depends on team expertise, multi-cloud requirements, and abstraction needs. Here is how the three dominant cloud automation tools compare:
| Feature | AWS CloudFormation | AWS CDK v2 | HashiCorp Terraform |
|---|---|---|---|
| Language Paradigm | Declarative (JSON / YAML) | Programmatic (TypeScript, Python, Go, Java, C#) | Declarative DSL (HashiCorp HCL) |
| State Management | Managed natively by AWS (No state files to store) | Managed natively by AWS (Synthesizes to CloudFormation) | Remote State File (Requires S3 + DynamoDB locking) |
| Abstraction Level | Low-level resource primitives (L1 only) | L1 (Primitives), L2 (Curated), L3 (Architectures) | Resource blocks & Community Modules |
| Type Checking & IDE | Schema validation via IDE plugins (cfn-lint) | Full compile-time type safety & IntelliSense | HCL LSP & terraform validate |
| Multi-Cloud Support | AWS Only | AWS Only (CDK for Terraform / CDKTF exists) | Universal (AWS, Azure, GCP, Datadog, etc.) |
| IAM Generation | Manual 40+ line JSON policy definitions | Automatic least-privilege (e.g. table.grantRead()) |
Manual data sources & policy attachments |
| Best Fit | Simple stacks, immutable vendor templates | AWS-native applications, complex microservices, developers | Multi-cloud ecosystems, centralized DevOps teams |
06 Testing & Shift-Left Governance with cdk-nag
Security Guardrails
One of the greatest benefits of AWS CDK is that you can write unit tests and compliance audits using standard testing frameworks before a single resource is deployed to AWS. The cdk-nag library uses CDK Aspects to traverse your construct tree and flag security vulnerabilities (NIST 800-53, HIPAA, PCI-DSS, AWS Well-Architected).
1. Unit Testing with @aws-cdk/assertions
Jest TestVerifies that synthesized CloudFormation templates adhere strictly to security baselines (e.g. all S3 buckets have encryption enabled):
2. Security Compliance with cdk-nag
AWS Solutions Pack
Enforce automated compliance checks across all stacks during cdk synth. Fails builds if any resource violates rules:
07 Enterprise CI/CD Deployment with AWS OIDC
Continuous Delivery
In professional engineering teams, developers never run cdk deploy from local workstations. All deployments run through automated CI/CD pipelines using keyless AWS OpenID Connect (OIDC) authentication, running linting, tests, security audits, and cdk diff on every pull request.
Production GitHub Actions CDK Deployment Pipeline
Runs unit tests, cdk-nag checks, and deploys with zero static credentials.
08 Frequently Asked Questions (FAQ)
Why should I use AWS CDK instead of writing raw CloudFormation templates? →
Raw CloudFormation JSON/YAML is verbose, repetitive, and prone to copy-paste errors. A secure VPC in CloudFormation requires 150+ lines of YAML with dozens of route table associations and internet gateways. With AWS CDK, new ec2.Vpc(this, 'Vpc') generates all of that automatically with hardened security defaults. CDK also gives you IDE autocomplete, type checking, code sharing across projects via npm/PyPI packages, and unit testing using standard test runners like Jest or Pytest.
What is CDK Bootstrapping and why is it necessary? →
When you run cdk bootstrap, the CDK CLI provisions dedicated assets infrastructure in your target AWS account and region: an Amazon S3 bucket (to store synthesized templates and Lambda deployment zips) and an Amazon ECR repository (to store locally built Docker images). When you deploy a stack with Lambda code or Docker assets, CDK packages the assets, uploads them to these bootstrap stores, and references them in the synthesized CloudFormation template.
How does AWS CDK automatically generate least-privilege IAM policies? →
In AWS CDK L2 constructs, resources implement the IGrantable pattern. Calling sessionTable.grantReadWriteData(taskRole) automatically creates an IAM policy containing only the exact DynamoDB actions needed (GetItem, PutItem, UpdateItem, DeleteItem, BatchGetItem, BatchWriteItem) scoped strictly to that specific table's ARN and index ARNs. This eliminates overly permissive dynamodb:* wildcards.
What is CloudFormation Drift Detection, and how should teams handle drift? →
Drift occurs when an engineer manually alters an AWS resource via the AWS Management Console, CLI, or an external script without updating the code template. CloudFormation drift detection compares the live resource state returned by AWS service APIs against the stack template. When drift is detected, best practice is to backport the changes into the CDK/CloudFormation code or re-deploy the stack to overwrite and reconcile the out-of-band changes.
How can I migrate an existing CloudFormation stack into AWS CDK without downtime? →
You can use cdk-from-cfn or create a CDK stack that mirrors the existing CloudFormation logical IDs using L1 constructs (e.g. CfnBucket). As long as the logical IDs in the synthesized CDK output match the logical IDs of the existing CloudFormation stack, CloudFormation will update the stack in-place without deleting or recreating any databases, S3 buckets, or compute instances.
How should database deletion policies be configured to avoid data loss? →
By default, CloudFormation and CDK delete resources when a stack is destroyed. For stateful resources like Amazon RDS databases, DynamoDB tables, and S3 buckets, always set removalPolicy: cdk.RemovalPolicy.RETAIN (or in CloudFormation YAML: DeletionPolicy: Retain and UpdateReplacePolicy: Retain). Even if someone accidentally deletes the stack or renames a resource, the physical data store will be orphaned safely in the AWS account rather than destroyed.