CloudFormation
As you learned in Chapter 10, “The Performance Efficiency Pillar,” CloudFormation uses templates to let you simultaneously deploy, configure, and document your infrastructure as code. Because CloudFormation templates are code, you can store them in a version-controlled repository just as you would any other codebase. The resources defined by a template compose a stack. When you create a stack, you must give it a name that’s unique within the account. One advantage of CloudFormation is that you can use the same template to build multiple identical environments. For example, you can use a single template to define and deploy two different stacks for an application, one for production and another for development. This would ensure both environments are as alike as possible. In this section, we’ll consider two templates: network-stack.json and web-stack.json . To download these templates, visit https://www.wiley.com/go/sybextestprep , follow the instructions to log in, and then click to the resource page for this book.
Creating Stacks
In a CloudFormation template, you defi ne your resources in the Resources section of the template. You give each resource an identifier called a logical ID . For example, the following snippet of the network-stack.json template defi nes a VPC with the logical ID of PublicVPC :
“Resources”: {
“PublicVPC”: {
“Type”: “AWS::EC2::VPC”,
“Properties”: {
“EnableDnsSupport”: “true”,
“EnableDnsHostnames”: “true”,
“CidrBlock”: “10.0.0.0/16”
}
}
}
The logical ID, also sometimes called the logical name , must be unique within a template. The VPC created by CloudFormation will have a VPC ID, such as
vpc-0380494054677f4b8 , also known as the physical ID . CloudFormation can read templates only from an S3 bucket. You can keep your templates anywhere, but for CloudFormation to use them, they must be in an S3 bucket. To create a stack named Network using a template stored in an S3 bucket, you can issue the
AWS command-line interface (CLI) command in the following format:aws cloudformation create-stack --stack-name Network --template-url
https://s3.amazonaws.com/cf-templates-c23z8b2vpmbb-us-east-1/network-stack.json
You can optionally defi ne parameters in a template. A parameter lets you pass custom values to your stack when you create it, as opposed to hard-coding values into the template. For instance, instead of hard-coding the Classless Interdomain Routing (CIDR) block into a template that creates a VPC, you can defi ne a parameter that will prompt for a CIDR when creating the stack.
Deleting Stacks
You can delete a stack from the web console or the AWS command-line interface (CLI). For instance, to delete the stack named Network, issue the following command: aws cloudformation delete-stack –stack-name Network If termination protection is not enabled on the stack, CloudFormation will immediately delete the stack and all resources that were created by it.
Using Multiple Stacks
You don’t have to define all of your AWS infrastructure in a single stack. Instead, you can break your infrastructure across different stacks. A best practice is to organize stacks by lifecycle and ownership. For example, the network team may create a stack named Network to define the networking infrastructure for a web-based application. The network infrastructure would include a virtual private cloud (VPC), subnets, Internet gateway, and a route table. The development team may create a stack named Web to define the runtime environment, including a launch template, Auto Scaling group, application load balancer, IAM roles, instance profile, and a security group. Each of these teams can maintain their own stack. When using multiple stacks with related resources, it’s common to need to pass values from one stack to another. For example, an application load balancer in the Web stack needs the logical ID of the VPC in the Network stack. You therefore need a way to pass the VPC’s logical ID from the Network stack to the Web stack. There are two ways to accomplish this: using nested stacks and exporting stack output values.
Nesting Stacks
Because CloudFormation stacks are AWS resources, you can configure a template to create additional stacks. These additional stacks are called nested stacks, and the stack that creates them is called the parent stack. To see how this works, we’ll consider the network-stack.json and web-stack.json templates.
In the template for the Web stack (web-stack.json), you’d define the template for the Network stack as a resource, as shown by the following snippet:
“Resources”: {
“NetworkStack” : {
“Type” : “AWS::CloudFormation::Stack”,
“Properties” : {
“TemplateURL” : “https://s3.amazonaws.com/cf-templatesc23z8b2vpmbb- us-east-1/network-stack.json”
}
},
The logical ID of the stack is NetworkStack, and the TemplateURL indicates the location of the template in S3. When you create the Web stack, CloudFormation will also automatically create the Network stack first. The templates for your nested stacks can contain an Outputs section where you define which values you want to pass back to the parent stack. You can then reference these values in the template for the parent stack. For example, the network-stack.json template defines an output with the logical ID VPCID and the value of the VPC’s physical ID, as shown in the following snippet:
“Outputs”: {
“VPCID”: {
“Description”: “VPC ID”,
“Value”: {
“Ref”: “PublicVPC”
}
},
Also read this topic: Introduction to Cloud Computing and AWS -1
The Ref intrinsic function returns the physical ID of the PublicVPC resource. The parent web-stack.json template can then reference this value using the Fn::GetAtt intrinsic function, as shown in the following snippet from the Resources section:
“ALBTargetGroup”: {
“Type”: “AWS::ElasticLoadBalancingV2::TargetGroup”,
“Properties”: {
“VpcId”: { “Fn::GetAtt” : [ “NetworkStack”, “Outputs.VPCID” ] },
Exporting Stack Output Values
If you want to share information with stacks outside of a nested hierarchy, you can selectively export a stack output value by defining it in the Export fi eld of the Output section, as follows:
“Outputs”: {
“VPCID”: {
“Description”: “VPC ID”,
“Value”: {
“Ref”: “PublicVPC”
},
“Export”: {
“Name”: {
“Fn::Sub”: “${AWS::StackName}-VPCID”
}
}
}
Any other template in the same account and region can then import the value using the Fn::ImportValue intrinsic function, as follows:
“ALBTargetGroup”: {
“Type”: “AWS::ElasticLoadBalancingV2::TargetGroup”,
“Properties”: {
“VpcId”: { “Fn::ImportValue” : {“Fn::Sub”:
“${NetworkStackName}-VPCID” } },
Keep in mind that you can’t delete a stack if another stack is referencing any of its outputs.
Stack Updates
If you need to reconfigure a resource in a stack, the best way is to modify the resource configuration in the source template and then either perform a direct update or create a change set.
Direct Update
To perform a direct update, upload the updated template. CloudFormation will ask you to enter any parameters the template requires. CloudFormation will deploy the changes immediately, modifying only the resources that changed in the template.
Change Set
If you want to understand exactly what changes CloudFormation will make, create a change set instead. You submit the updated template, and once you create the change set, CloudFormation will display a list of every resource it will add, remove, or modify. You can then choose to execute the change set to make the changes immediately, delete the change set, or do nothing. You can create multiple change sets using different templates, compare them, and then choose which one to execute. This is useful if you want to compare multiple different configurations without having to create a new stack each time.
Update Behavior
How CloudFormation updates a resource depends on the update behavior of the resource’s property that you’re updating. Update behaviors can be one of the following:
Update with No Interruption The resource is updated with no interruption and without changing its physical ID. For example, changing the IAM instance profile attached to an EC2 instance doesn’t require an interruption to the instance.
Update with Some Interruption The resource encounters a momentary interruption but retains its physical ID. This happens when, for example, you change the instance type for an EBS-backed EC2 instance.
Replacement CloudFormation creates a new resource with a new physical ID. It then points dependent resources to the new resource and deletes the original resource. For example, if you change the availability zone for an instance defined in a template, CloudFormation will create a new instance in the availability zone defined in the updated template and then delete the original instance.
People also ask this Questions
- What is a defense in depth security strategy how is it implemented?
- What is AWS Solution Architect?
- What is the role of AWS Solution Architect?
- Is AWS Solution Architect easy?
- What is AWS associate solutions architect?
- Is AWS Solutions Architect Associate exam hard?
Infocerts, 5B 306 Riverside Greens, Panvel, Raigad 410206 Maharashtra, India
Contact us – https://www.infocerts.com
