AWS CloudFormation Basics: Infrastructure as Code on AWS

AWS CloudFormation is the AWS infrastructure-as-code (IaC) service. You describe the AWS resources you want (EC2 instances, S3 buckets, IAM roles, entire networks) in a text template written in YAML or JSON, and CloudFormation provisions them for you as a single unit called a stack. The service itself costs nothing: you pay only for the resources it creates on your behalf.

What AWS CloudFormation is

Infrastructure as code means treating your cloud environment the way developers treat application code. Instead of clicking through the AWS Management Console to build a VPC, launch instances, and attach security groups by hand, you write down the desired end state in a template file. That file can be stored in version control, reviewed by teammates, and deployed identically as many times as you like.

CloudFormation is the native AWS implementation of this idea. It reads your template, figures out the correct order to create resources in (it understands dependencies, so a subnet gets created before the instance that lives in it), and then builds everything. If any resource fails to create, CloudFormation rolls the whole stack back by default, so you are never left with a half-built environment you have to clean up manually.

Three template concepts come up constantly:

• Resources are the required section of every template: the actual AWS objects to create, each with a type (such as AWS::S3::Bucket) and its properties.
• Parameters let you pass values in at deploy time, so one template can serve dev, test, and production with different instance sizes or names.
• Outputs export useful values from the stack, such as a load balancer’s DNS name, so people or other stacks can consume them.

How stacks, change sets, and drift detection work

A stack is the running collection of resources that CloudFormation created from a template. The stack is the unit of management: update the template and CloudFormation updates the stack; delete the stack and CloudFormation deletes every resource it created, in the right order. That delete behavior is a big deal for cost control, because temporary environments can be torn down completely with one action instead of hunting for stray resources.

A change set is a preview of what an update will do before you execute it. When you submit a modified template, CloudFormation compares it against the running stack and lists exactly which resources will be added, modified, or replaced. Reviewing a change set before executing it is how teams avoid accidentally replacing a production database because a property change forced re-creation.

Drift detection answers a different question: has someone changed the live resources outside of CloudFormation? If an administrator edits a security group by hand in the console, the stack has drifted from its template. Drift detection compares actual resource configuration against the template’s expected configuration and reports the differences, which helps enforce the discipline that all changes go through code.

StackSets extend the model across accounts and Regions: define a template once, then deploy it as stacks into many AWS accounts and multiple Regions from a single operation. This is the standard answer for rolling out baseline resources (logging buckets, IAM roles, guardrail configurations) across an entire organization.

CloudFormation vs Elastic Beanstalk vs CDK

The exam loves to check whether you can tell the provisioning tools apart. AWS Elastic Beanstalk also creates infrastructure, but from the opposite direction: you hand it application code, and it provisions and manages the environment (instances, load balancer, scaling) for you. CloudFormation gives you full control over every resource; Beanstalk gives you convenience for standard web applications. The AWS Cloud Development Kit (CDK) sits on top of CloudFormation: you write infrastructure in a general-purpose programming language such as Python or TypeScript, and the CDK synthesizes that code into CloudFormation templates behind the scenes.

	AWS CloudFormation	AWS Elastic Beanstalk
Primary input	Template describing resources	Your application code
Scope	Any supported AWS resource	Web apps and worker environments
Control level	Full, resource-by-resource	Managed; platform handles details
Best for	Repeatable, reviewable infrastructure	Fast deployment without managing infrastructure
Cost of the service	Free (pay for resources created)	Free (pay for resources created)

Why infrastructure as code matters on AWS

The benefits CloudFormation delivers map directly onto themes the certification cares about. Repeatability removes human error: the template that built staging builds production identically. Disaster recovery gets faster because an environment can be re-created in another Region from the same template. Auditing improves because every infrastructure change is a template change with a history in version control. And automation of provisioning is one of the operational excellence practices described in the AWS Well-Architected Framework, so questions sometimes connect the two.

It is also worth knowing what CloudFormation is not. It does not monitor resources (that is Amazon CloudWatch), it does not record configuration history or evaluate compliance rules (that is AWS Config), and it does not deploy application code through a pipeline (that is the CodePipeline family). CloudFormation’s job begins and ends with provisioning and updating resources from templates.

How the CLF-C02 exam tests this

• A scenario describes a team that needs to create identical environments in multiple Regions, or rebuild an environment exactly, and asks which service to use. The answer is CloudFormation, because templates make provisioning repeatable anywhere.
• A question asks which service lets you “provision infrastructure by writing templates in YAML or JSON.” Only CloudFormation fits; distractors are usually Elastic Beanstalk, OpsWorks, or Systems Manager.
• A scenario says a developer wants to deploy a web app without managing the underlying infrastructure. That points to Elastic Beanstalk, not CloudFormation; the exam wants you to catch the “just run my code” phrasing.
• A question asks how a company can define infrastructure using a familiar programming language like Python. That is the AWS CDK, which generates CloudFormation templates from code.
• Cost-angle questions ask what CloudFormation costs: the service is free, and charges come only from the resources the stacks create.

Quick reference

• CloudFormation = AWS infrastructure as code: YAML or JSON templates provisioned as stacks.
• The stack is the management unit; deleting a stack removes all resources it created.
• Failed stack creation rolls back automatically by default.
• Change sets preview an update’s impact before you execute it.
• Drift detection finds live resources that were modified outside the template.
• StackSets deploy one template across multiple accounts and Regions.
• Elastic Beanstalk takes code and manages the environment; CDK writes CloudFormation in real programming languages.
• The service is free; you pay only for the AWS resources your stacks create.