AWS CloudFormation
Infrastructure as Code (IaC)
What is Infrastructure as Code
Infrastructure as Code (IaC) is the management of infrastructure (networks, virtual machines, load balancers, and any other workloads) in a descriptive model. This means that the infrastructure configuration can be written as code files, which can be treated as just another software artifact in your application.
The purpose of IaC is to provide developers and system administrators with a high level of control and flexibility over their infrastructure. With IaC, you can manage your infrastructure consistently and repeatedly, which can help reduce the possibility of manual error. IaC can also make managing and scaling your infrastructure easier as your application grows.
What is AWS CloudFormation
AWS CloudFormation is a service that helps you model and set up your Amazon Web Services resources so you can spend less time managing those resources and more time focusing on your applications that run in AWS. You create a template that describes all the AWS resources you want (like Amazon EC2 instances or Amazon RDS DB instances), and AWS CloudFormation provides and configures those resources for you.
Working with Templates and Template Formats
Templates are one of the main entities in AWS CloudFormation. A template is a JSON or YAML formatted text file. The file is an ASCII text file with one declarative language that describes a set of AWS resources and properties.
JSON
JSON templates are formatted as JSON objects. For example, here's a simple CloudFormation template in JSON format that creates an EC2 instance:
{
"AWSTemplateFormatVersion" : "2010-09-09",
"Resources" : {
"MyEC2Instance" : {
"Type" : "AWS::EC2::Instance",
"Properties" : {
"ImageId" : "ami-0abcdef1234567890",
"InstanceType" : "t2.micro"
}
}
}
}YAML
Alternatively, YAML can be used as the format for CloudFormation templates. YAML tends to be more human-readable than JSON, hence more preferable. Here's the same example as above, written in YAML:
Basic Anatomy of a Template
A template in AWS CloudFormation is a JSON or YAML-formatted text file comprised of the following components:
AWSTemplateFormatVersion (optional): This defines the capabilities of the template. The latest template format version is
2010-09-09.Description (optional): A text string that describes the template.
Metadata (optional): Objects that provide additional information about the template.
Parameters (optional): Values to pass to your template at runtime (when you create or update a stack). You can refer to the parameters from the Resources and Outputs sections of the template.
Mappings (optional): A mapping of keys and associated values that you can use to specify conditional parameter values.
Conditions (optional): Conditions that control whether certain resources are created or whether certain resource properties are assigned a value during stack creation or update.
Transform (optional): For serverless applications (applications that use the AWS Serverless Application Model (SAM)), specifies the version of the AWS Serverless Application Model (SAM) to use.
Resources (required): Specifies the stack resources and their properties.
Outputs (optional): Describes the values that are returned whenever you view your stack's properties.
Stacks
In AWS CloudFormation, a stack is a collection of AWS resources that you can manage as a single unit. All the resources in a stack are defined by the stack's AWS CloudFormation template.
You can think of a stack as an instantiation of a CloudFormation template. When you create a stack, you provide a CloudFormation template that describes what resources you want AWS to create and configure. The set of resources that CloudFormation creates from this template is collectively referred to as a "stack".
For example, if you're running a web application, your stack might include a web server on an EC2 instance, a database on an RDS instance, and the associated networking infrastructure within a VPC.
All the resources within a stack are treated as a single unit. This means that stacks are created, updated, or deleted as a unit, keeping your infrastructure's management consistent and organized.
Logical IDs vs Physical IDs
In AWS CloudFormation, both Logical IDs and Physical IDs play important roles when defining and referencing resources. Here's a breakdown of what they are and how they differ:
Logical ID
This is the identifier you provide in the CloudFormation template to reference a specific resource. The Logical ID must be alphanumeric and unique within the template. This ID is used within the CloudFormation template to reference or connect resources. For instance, if you have an EC2 instance and a security group defined in your template, you would use the Logical ID of the security group when defining which security group the EC2 instance should use.
For example:
Physical ID
This is the identifier that AWS assigns to the resource after it is created. This ID is unique across your AWS account and is used to interact with the resource outside of CloudFormation (such as from the AWS Management Console, CLI, SDKs, etc.). For example, the physical ID of an EC2 instance is its Instance ID (like i-0abc1234de5fg678h), and the physical ID of an S3 bucket is its bucket name (like my-unique-bucket-name).
Physical IDs are especially important when you are managing resources outside of the CloudFormation environment, and they are typically used for debugging or managing resources manually.
What are intrinsic functions
In short - they make your CloudFormation templates more dynamic and less hard-coded, which is a good practice in managing infrastructure as code.
Intrinsic functions are built-in functions that you use to assign values to properties that are not available until runtime. These functions help you manage your templates by allowing you to get data from different parts of your template or even from outside your template (like from a parameter or another stack).
The full list of intristuc functions and how to use them you can find in CF's documentation.
Last updated
Was this helpful?