AWS CloudFormation

AWS CloudFormation is the native Infrastructure-as-Code (IaC) service for AWS. It provisions and manages AWS resources via declarative JSON or YAML templates, treats a deployed set of resources as a single unit (a stack), and tracks every change with rollback on failure. CloudFormation is the substrate for higher-level tools like AWS CDK and SAM, which compile down to CloudFormation templates.

Key Features:

Declarative Templates: JSON/YAML describing resources, parameters, mappings, conditions, outputs, and metadata. Templates are version-controllable and reproducible.
Stacks & Change Sets: A stack is a deployed instance; change sets preview what will change before you apply.
Drift Detection: Compares the live state of resources against the template's intended state.
Rollback & Stack Policies: Automatic rollback on create/update failure; stack policies prevent accidental changes to critical resources.
Nested & Cross-Stack References: Reusable child stacks (AWS::CloudFormation::Stack) and exported outputs imported across stacks.
StackSets: Deploy the same stack to many accounts and regions in one operation — the standard AWS Organizations rollout pattern.
Custom & Third-Party Resources: Lambda-backed custom resources for non-CFN logic; CloudFormation Registry for community-published types (e.g., Datadog monitors).
CDK Integration: AWS Cloud Development Kit lets you author infrastructure in TypeScript/Python and synthesize CloudFormation templates.

Common Use Cases:

Environment Provisioning: Dev/stage/prod replicas from one template parameterized by stage.
Blue/Green Deployments: Spin up a parallel stack, shift traffic, retire the old.
Org-Wide Guardrails: StackSets deploy CloudTrail trails, GuardDuty, and Config recorders to every account.
Disaster Recovery: Re-create infrastructure in another region from the same template.
Compliance Templates: Pre-blessed stacks (e.g., HIPAA-aligned VPC) developers consume via Service Catalog.

Workflow Steps:

Author Template: JSON/YAML, or compile from CDK.
Validate: aws cloudformation validate-template for syntax; cfn-lint for richer rules.
Create Change Set: Preview additions, modifications, and replacements before apply.
Execute Change Set: CloudFormation orchestrates dependency order, parallel where safe.
Monitor Events: CREATE_IN_PROGRESS / CREATE_COMPLETE / UPDATE_ROLLBACK_IN_PROGRESS in the Events tab.
Outputs: Read deployed values (URLs, ARNs, IDs) from the Outputs section.

Example Template — EC2 + Security Group:


AWSTemplateFormatVersion: '2010-09-09'
Description: Single EC2 instance behind an SSH/HTTP security group.

Parameters:
  KeyName:
    Type: AWS::EC2::KeyPair::KeyName
  AllowedSshCidr:
    Type: String
    Default: 203.0.113.0/24
  InstanceType:
    Type: String
    Default: t3.micro
    AllowedValues: [t3.micro, t3.small, t3.medium]

Resources:
  AppSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: SSH from office, HTTP from anywhere
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref AllowedSshCidr
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0

  AppInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      KeyName: !Ref KeyName
      SecurityGroups:
        - !Ref AppSecurityGroup
      Tags:
        - {Key: Name, Value: !Sub '${AWS::StackName}-app'}

Outputs:
  PublicDns:
    Description: Public DNS of the instance
    Value: !GetAtt AppInstance.PublicDnsName
    Export:
      Name: !Sub '${AWS::StackName}-PublicDns'

Deploy via CLI:


aws cloudformation deploy \
  --stack-name app-prod \
  --template-file app.yaml \
  --parameter-overrides KeyName=my-keypair InstanceType=t3.small \
  --capabilities CAPABILITY_NAMED_IAM \
  --tags Project=demo Owner=platform

aws cloudformation describe-stacks --stack-name app-prod \
  --query 'Stacks[0].Outputs'

# Preview changes safely
aws cloudformation deploy --no-execute-changeset ...
aws cloudformation describe-change-set --change-set-name

Service Limits & Quotas:

Stacks per region per account: default soft limit 2,000.
Resources per stack: 500 (raise with nested stacks).
Template body size: 1 MB inline, 1 MB via S3 (51 MB raw if compressed).
Parameters per template: 200.
Outputs per template: 200.
StackSets target accounts per operation: default 100 per region (raisable).

Pricing Model:

CloudFormation itself is free for AWS resource types (you pay only for the resources created).
Third-party / Registry types: $0.0009 per handler operation beyond a free tier of 1,000/month.
StackSets: free orchestration; only the deployed resources are billed.
Common cost surprise: failed updates that get stuck in UPDATE_ROLLBACK_FAILED — resources keep running while you debug. Use change sets and --disable-rollback selectively to avoid orphaned partial deployments.

Key Concepts:

Templates: The declarative source of truth.
Stacks: Live instances of a template.
Change Sets: Preview of pending changes before execution.
Drift Detection: Identifies hand-edits that diverge from the template.
Stack Policies: JSON guards on which resources updates can replace.
Helper Scripts: cfn-init, cfn-signal, cfn-hup coordinate EC2 bootstrapping.

Common Interview Questions:

CloudFormation vs. Terraform — when pick which?

CloudFormation: deepest AWS service coverage on day one of a new feature, no state file to manage, integrated with StackSets and Service Catalog. Terraform: multi-cloud, larger module ecosystem, explicit plan/apply UX, broader community. Many AWS-only teams use CDK (compiles to CloudFormation) to get a real programming language without losing native integration.

What's a change set?

A preview of what CloudFormation would do if you applied a template change — additions, modifications, and (importantly) replacements. Reviewing change sets before execution catches accidental destroy-and-recreate of stateful resources like RDS instances.

How do you reuse infrastructure across stacks?

Three options: nested stacks (AWS::CloudFormation::Stack), cross-stack references via Export/!ImportValue, or SSM Parameter Store as a loose-coupling registry. CDK encourages constructs as the abstraction over nested stacks.

What is drift detection and what are its limits?

Compares deployed resource state with template state and flags differences. Coverage isn't 100% — some properties (e.g., Lambda code SHA) aren't checked. Use it as one signal in compliance, not the sole one; AWS Config and SCPs prevent drift more reliably.

How do you handle secrets in CloudFormation?

Never hardcode. Use NoEcho parameters for inputs, dynamic references like {{resolve:secretsmanager:...}} or {{resolve:ssm-secure:...}} to fetch from Secrets Manager / SSM at deploy time, and prefer IAM roles for runtime credentials over passing keys through templates.

What's a StackSet and when use it?

A template plus an orchestration layer that deploys the same stack to many accounts and regions. The canonical use is rolling out org-wide baseline controls (CloudTrail, GuardDuty, IAM roles for cross-account access) from the management account.