AWS CloudFormation

AWS CloudFormation is a service that allows you to define your entire AWS infrastructure as a text file (a template) and then provision it automatically. The problem it solves is the complexity and error-prone nature of manually creating and managing AWS resources. Without CloudFormation, administrators often use the AWS Management Console, CLI commands, or scripts to create resources one by one. This manual approach leads to configuration drift, inconsistent environments, and difficulty replicating infrastructure across regions or accounts. CloudFormation treats infrastructure as code, enabling version control, peer review, and automated deployments.

CloudFormation uses templates written in JSON or YAML. A template describes the AWS resources you want to create, their properties, and dependencies. When you submit a template, CloudFormation creates a "stack" — a collection of resources managed as a single unit. The service automatically determines the correct order to create, update, or delete resources based on dependencies. For example, if your template includes an EC2 instance and a security group that references it, CloudFormation creates the security group first.

Key components of a template: - AWSTemplateFormatVersion: (optional) Specifies the template format version. - Description: A text description of the template. - Parameters: Input values you supply at stack creation (e.g., instance type, key pair). - Mappings: Static lookup tables (e.g., mapping region to AMI ID). - Conditions: Conditions that control whether certain resources are created. - Resources: (Required) The AWS resources to create (e.g., EC2 instances, S3 buckets, IAM roles). - Outputs: Values returned after stack creation (e.g., the public IP of an EC2 instance).

Example snippet of a CloudFormation template (YAML):

AWSTemplateFormatVersion: '2010-09-09'
Description: A simple EC2 instance
Parameters:
  InstanceType:
    Type: String
    Default: t2.micro
    AllowedValues: [t2.micro, t2.small, t2.medium]
Resources:
  MyEC2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: ami-0abcdef1234567890
      SecurityGroups:
        - !Ref MySecurityGroup
  MySecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupDescription: Enable SSH access
      SecurityGroupIngress:

- IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0
Outputs:
  InstanceIP:
    Description: Public IP of the instance
    Value: !GetAtt MyEC2Instance.PublicIp

When you create a stack, CloudFormation performs the following steps: 1. Validate the template syntax. 2. Check for circular dependencies. 3. Create resources in the correct order, waiting for each to complete before proceeding. 4. If any resource creation fails, CloudFormation rolls back the entire stack (by default), deleting any resources that were created successfully. This ensures you don't have orphaned resources.

CloudFormation itself is free. You only pay for the AWS resources created (e.g., EC2 instances, S3 buckets). There is no additional charge for using CloudFormation. However, there are limits: you can have up to 200 stacks per region per account (soft limit, can be increased), and each template can be up to 51,200 bytes (50 KB) when using an S3 URL.

In on-premises environments, infrastructure is typically provisioned manually or through scripts like Ansible, Chef, or Puppet. These tools are configuration management tools, not infrastructure provisioning tools. CloudFormation is specific to AWS and focuses on provisioning resources, not configuring software on those resources. For software configuration, you would use tools like AWS OpsWorks (which supports Chef/Puppet) or AWS Systems Manager. AWS Elastic Beanstalk is a higher-level service that automates deployment of applications but abstracts away the underlying infrastructure — you don't control individual resources directly. CloudFormation gives you fine-grained control.

On the CLF-C02 exam, you will be tested on the purpose of CloudFormation, its benefits (automation, consistency, rollback), and how it differs from Elastic Beanstalk and OpsWorks.

A startup runs a web application with separate environments for development, testing, and production. They use CloudFormation templates to define the entire stack: VPC, public/private subnets, Auto Scaling group, Application Load Balancer, and RDS database. Each environment uses the same template but different parameter values (e.g., instance type t2.micro for dev, t2.medium for prod). This ensures environments are identical in configuration, reducing the 'it works on my machine' problem. The team stores templates in a Git repository, enabling code review and versioning. When a developer needs a new environment, they run a CloudFormation create-stack command. Cost is controlled because dev stacks use smaller instances and can be shut down overnight. A common mistake is forgetting to delete stacks, leading to unexpected charges; the team uses AWS Config rules to flag stacks running longer than 30 days.

A financial services company must maintain a disaster recovery (DR) environment in a different AWS region. They use CloudFormation Stack Sets to deploy the same infrastructure (EC2, RDS, Lambda) to both primary and DR regions from a single template. The template includes parameters for region-specific AMI IDs using Mappings. The DR stack is kept in a stopped state (e.g., RDS in standby, EC2 stopped) to minimize costs. In a disaster, they update the stack to start resources and change Route 53 failover. Without CloudFormation, manually recreating infrastructure in another region would take hours and risk configuration errors. The biggest risk is template drift — if someone manually modifies resources in the primary region, the template becomes out of sync. To mitigate this, they use AWS Config to detect changes and enforce that all changes go through CloudFormation.

A healthcare company must comply with HIPAA. They use CloudFormation to enforce security baselines. Their templates always include encryption at rest for EBS volumes and RDS, restrict security group ingress to specific IPs, and enable CloudTrail logging. Any deviation from the template is flagged. They also use CloudFormation Guard (a policy-as-code tool) to validate templates before deployment. If a developer tries to create an unencrypted resource, the template is rejected. This approach ensures that all infrastructure is compliant from the start. A common pitfall is that CloudFormation does not automatically enforce compliance during updates — you must re-validate templates. Additionally, if a resource is created outside CloudFormation (e.g., via Console), it is not managed and may violate compliance.