CloudFormation is a tool for automating the creation, updating and management of your entire resource stack. It provides a way to turn your infrastructure into code, in the form of a YAML file, which can be controlled version along with your software.
What is CloudFormation?
CloudFormation’s concept is quite simple – creating resources manually can be painful, and although it can be automated with CLI or API requests, but if you need to update your stack in the future, it will still be a mostly manual process. Instead of worrying about this, CloudFormation offers a way to model the structure and configuration of all your resources.
This is done with a YAML or JSON template, which contains all the information required for your product stack, including resources that need to be created, parameters and configuration for those resources and the outputs they return. This file can be controlled by the version through Git and even used to create a continuous distribution pipeline that will automatically drive changes
You do not need to create the YAML template manually. It is much easier to use CloudFormation̵7;s web-based “Designer”, which visually shows the entire product stack. Here, for example, is one of the example templates for an automatic scaling, load-balanced WordPress distribution with an RDS instance as database.
You can extract new components from the specified directory and link the components. Visual Template Updates Updates the underlying YAML template. If you click on any resource in this template, it will automatically scroll to the entry in the YAML resource list. Very handy.
Once you have distributed this template, all the resources associated with it will be created in your account. When the stack needs to be updated, the existing resources will be updated with a new configuration, old resources will be deleted if they are no longer used and new resources will be spun up when they are added.
CloudFormation also manages to create dependencies in the right order, without you having to think about it yourself. For example, if you want to create an EC2 instance with a security group, CloudFormation will make sure to create the security group first and then create the instance with that security group. All you have to do is link them to the console.
The main disadvantage of CloudFormation is that if you commit to Infrastructure-as-code, you will have to commit completely – making manual changes to the resource configuration outside of CloudFormation is uncertain, as CloudFormation updates can overwrite your manual changes to enforce what you have in your template. For example, if you have deployed an elastic IP and want to point it to another instance, you must do so from the CloudFormation console, not from the EC2 Management Console. Technically, manual changes will last until at least the next CloudFormation update, and if the template configuration does not change in the meantime, CloudFormation will not implement the schema in the template. So while you may be able to get away with manual changes in the short term, it is not recommended and is completely short-lived.
Using the Online Editor
Go to the CloudFormation console, click “Create Bar” and select “With New Resources.”
This opens a dialog where you select your CloudFormation template. You can import an existing template from S3, but if you have just started, we suggest you try one of the templates. We choose the simple “LAMP Stack” template, which distributes a single web server. Click “View In Designer” to open the template.
This template is pretty basic. Only one EC2 instance and one security group for that instance.
If you want to add something new to the template, the easiest way is to find the resource in the sidebar and drag it in. For example, if you want to add an elastic IP to associate with this new instance, look in the “EC2” Section to find “EIP” and drag it here:
By default, it is not connected to anything. You need to connect it to the EC2 instance to get any effect. The purple colored dots are properties. You can subtract from these properties to create links to other resources. To link the elastic IP, drag the upper corner “EIPAssociation” to the instance. Compatible resources are highlighted in green when you drag.
Clicking on a resource will take you to the entry in the YAML template. Changes to this template will be communicated to the designer, but you may need to press the update button in the upper right corner.
In total, the YAML template will have a few different sections:
Metadata, is mostly used by CloudFormation Designer to keep track of where things are visually, but can also be used for general metadata.
Parameters, arguments that are sent to the CloudFormation console and can be sent to the template at runtime. For example, the default template contains some parameters to specify MySQL database name, username and password, for example:
DBName: Default: MyDatabase Description: MySQL database name Type: String MinLength: '1' MaxLength: '64' AllowedPattern: '[a-zA-Z][a-zA-Z0-9]*' ConstraintDescription: must begin with a letter and contain only alphanumeric characters.
Surveys, these are a bit complicated, but they are basically the same
case statements. You can use them to change parameter values depending on a key. For example, AWS uses this to change the AMI ID based on the region to which the template is distributed. You can use
Fn::FindInMap inherent function to look up these values elsewhere in the template. You may want to read more about this from the AWS documents.
Mappings: RegionMap: us-east-1: "HVM64": "ami-0ff8a91507f77f867" us-west-1: "HVM64": "ami-0bdb828fd58c52235" eu-west-1: "HVM64": "ami-047bb4163c506cd98" ap-southeast-1: "HVM64": "ami-08569b978cc4dfa10" ap-northeast-1: "HVM64": "ami-06cd52961ce9f0d85"
Conditions, which allows CloudFormation to distribute resources only if the conditions are met. For example, you can use this to distribute specific resources in production, testing, and staging environments, but not in development resources.
Conditions: CreateProdResources: !Equals [ !Ref EnvType, prod ]
Transforms, which enables custom processing on your template before it is distributed. This is a bit of a niche feature, but it is used by SAM to distribute Lambda features. You must set this manually and then call it by name:
Transform: [MyMacro, AWS::Serverless]
Outputs, which allows you to link resources between stacks, or simply return an answer. You can think of these as public versus private variables.
Outputs: BackupLoadBalancerDNSName: Description: The DNSName of the backup load balancer Value: !GetAtt BackupLoadBalancer.DNSName Condition: CreateProdResources InstanceID: Description: The Instance ID Value: !Ref EC2Instance
And finally, Resources, which is simply a matrix with all the resources in the template. This will vary wildly depending on what you use, as each service has its own characteristics. For example, an EC2 instance with a custom AMI might look like this:
Resources: MyEC2Instance: Type: "AWS::EC2::Instance" Properties: ImageId: "ami-0ff8a91507f77f867"
You can consult the AWS full schedule reference for more information on the specific service you use, or the resource and property reference.