AWS CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources, provision and update them in an orderly and predictable fashion.

CloudFormation is not just an application deployment tool but can provision any kind of AWS resource.

Creates and builds those described resources in an automated manner

Launches and configures resources programmatically, treating infrastructure like code with its repeatability and reusability

Like source code, should be stored in a repository

Supports drift detection (determines whether the stack has drifted from its expected template configuration, returns detailed information about the drift status of each resource in the stack that supports drift detection)

CloudFormation consists of

1. Template

   1. is an architectural diagram

   2. a JSON or YAML-format, text-based file that describes all the AWS resources you need to deploy to run your application

   3. Name used for a resource within the template is a logical name but when CloudFormation creates the resource, it generates a physical name that is based on the combination of the logical name, the stack name, and a unique ID 

2. Stack

   1. is the end result of that diagram, which is actually provisioned

   2. is the set of AWS resources that are created and managed as a single unit when CloudFormation instantiates a template.

   3. Collection of resources can be created, updated, and deleted by creating, updating, and deleting stacks. 

   4. Only actions that the users have permission to do 

3. Change Set

   1. Change Sets presents a summary of the proposed changes CloudFormation will make when a stack is updated.

   2. Change Sets help check how the changes might impact running resources, especially critical resources, before implementing them.

   3. CloudFormation makes the changes to the stack only when the change set is executed, allowing you to decide whether to proceed with the proposed changes or explore other changes by creating another change set.

   4. Change sets don’t indicate whether AWS CloudFormation will successfully update a stack for e.g. if account limits are hit or the user does not have permission.

CloudFormation template can be used to set up the resources consistently and repeatedly over and over across multiple regions.

Resources can be updated, deleted and modified in a controlled and predictable way, in effect applying version control to the infrastructure as done for software code.

AWS CloudFormation Template consists of elements :-

1. List of AWS resources and their configuration values

2. An optional template file format version number

3. An optional list of template parameters (input values supplied at stack creation time)

4. An optional list of output values like public IP address using the Fn::GetAtt function

5. An optional list of data tables used to lookup static configuration values for e.g., AMI names per AZ

CloudFormation supports Chef & Puppet Integration, meaning that you can deploy and configure right down the application layer.

CloudFormation provides a set of application bootstrapping scripts that enable you to install packages, files, and services on the EC2 instances by simply describing them in the CloudFormation template.

By default, automatic rollback on error feature is enabled, which will cause all the AWS resources that CloudFormation created successfully for a stack up to the point where an error occurred to be deleted.

In case of automatic rollback, charges would still be applied for the resources the time they were up and running.

CloudFormation provides a WaitCondition resource that acts as a barrier, blocking the creation of other resources until a completion signal is received from an external source e.g. application, or management system.

CloudFormation allows deletion policies to be defined for resources in the template for e.g. resources to be retained or snapshots can be created before deletion useful for preserving S3 buckets when the stack is deleted

Challenges from building architectures manually:

1. High investment of time and effort

2. Scalability: Building manually means each part of the architecture is being built separately. Without consistency in how they're being built, some resources may scale correctly while others may not, leading to painful bottlenecks that can be hard to identify. 

3. No Version Control: Building manually means you don't have inherent version control. When you make changes or updates to your infrastructure, you have no easy way of rolling back to your last working configuration. 

4. Lack Of Audit Trails: Manual builds rarely have clear and verifiable audit trails, because manual builds require manual tracking by the person doing the building. 

5. Inconsistent Data Managment:  With a variety of data sources to manage, it's possible that setting them up manually means they are managed in different ways. This can lead to confusion and serious errors, especially when others try to work with these resources. 

IAM

1. IAM can be applied with CloudFormation to access control for users whether they can view stack templates, create stacks, or delete stacks.

2. IAM permissions need to be provided to the user to the AWS services and resources provisioned, when the stack is created

3. Before a stack is created, AWS CloudFormation validates the template to check for IAM resources that it might create.

Service Role

1. A service role is an AWS IAM role that allows AWS CloudFormation to make calls to resources in a stack on the user’s behalf.

2. By default, AWS CloudFormation uses a temporary session that it generates from the user credentials for stack operations.

3. For a service role, AWS CloudFormation uses the role’s credentials.

4. When a service role is specified, AWS CloudFormation always uses that role for all operations that are performed on that stack.

CreationPolicy Attribute

1. is invoked during the associated resource creation

2. can be associated with a resource to prevent its status from reaching create complete until AWS CloudFormation receives a specified number of success signals or the timeout period is exceeded.

3. helps to wait on resource configuration actions before stack creation proceeds for e.g. software installation on an EC2 instance.

DeletionPolicy Attribute

1. preserve or (in some cases) backup a resource when its stack is deleted

2. By default, if a resource has no DeletionPolicy attribute, AWS CloudFormation deletes the resource

3. To keep a resource when its stack is deleted,

   1. specify Retain for that resource, to prevent deletion

   2. specify Snapshot to create a snapshot before deleting the resource, if the snapshot capability is supported for e.g RDS, EC2 volume etc.

DependsOn Attribute

1. helps specify that the creation of a specific resource follows another

2. resource is created only after the creation of the resource specified in the DependsOn attribute.

Metadata Attribute

1. enables association of structured data with a resource

UpdatePolicy Attribute

1. defines AWS CloudFormation handles updates to the AWS::AutoScaling::AutoScalingGroup resource.

Organize Your Stacks By Lifecycle and Ownership

Use Cross-Stack References to Export Shared Resources

Use IAM to Control Access

Use modules to reuse resource configurations

1. As your infrastructure grows, common patterns can emerge in which you declare the same components in each of your templates. 

2. Modules are a way for you to package resource configurations for inclusion across stack templates, in a transparent, manageable, and repeatable way. 

Verify Quotas for All Resource Types

Reuse Templates to Replicate Stacks in Multiple Environments

Use Nested Stacks to Reuse Common Template Patterns

Do Not Embed Credentials in Your Templates

Use AWS-Specific Parameter Types

Use Parameter Constraints

Use AWS::CloudFormation::Init to Deploy Software Applications on Amazon EC2 Instances

Validate Templates Before Using Them

Manage All Stack Resources Through AWS CloudFormation

Create Change Sets Before Updating Your Stacks

Use Stack Policies

Use AWS CloudTrail to Log AWS CloudFormation Calls

Use Code Reviews and Revision Controls to Manage Your Templates

Deploy your infrastructure in groups, not all at once. This provides helpful operational isolation in case an incorrect change is pushed and to ensure the entire infrastructure isn't affected when a stack needs to be taken down. 

Use the latest helper scripts

1. The helper scripts are updated periodically. Be sure you include the following command in the UserData property of your template before you call the helper scripts to ensure that your launched instances get the latest helper scripts:

   1. yum install -y aws-cfn-bootstrap

2. 
   

Validate templates for organization policy compliance

1. You can also validate your template for compliance to organization policy guidelines. 

2. AWS CloudFormation Guard (cfn-guard) is an CLI tool that provides a policy-as-code language to define rules that can check for both required and prohibited resource configurations.

Update your Amazon EC2 instances regularly

1. On all your Amazon EC2 Windows instances and Amazon EC2 Linux instances created with CloudFormation, regularly run the yum update command to update the RPM package. 

Look towards breaking the templates into smaller manageable templates 

Format Version (optional)

The AWS CloudFormation template version that the template conforms to.

 The template format version isn't the same as the API or WSDL version.

 The template format version can change independently of the API and WSDL versions.

Description (optional)

A text string that describes the template. This section must always follow the template format version section.

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 parameters from the Resources and Outputs sections of the template.

Types:

1. 1. String

   2. Number

   3. List<Number>

   4. CommaDelimitedList: An array of literal strings that are separated by commas. 

   5. AWS-Specific Parameter Types: AWS values such as Amazon EC2 key pair names and VPC IDs. 

   6. SSM Parameter Types: Parameters that correspond to existing parameters in Systems Manager Parameter Store. 

Rules (optional)

Validates a parameter or a combination of parameters passed to a template during a stack creation or stack update.

Mappings (optional)

A mapping of keys and associated values that you can use to specify conditional parameter values, similar to a lookup table. 

You can match a key to a corresponding value by using the Fn::FindInMap intrinsic function in the Resources and Outputs sections.

Conditions (optional)

Conditions that control whether certain resources are created or whether certain resource properties are assigned a value during stack creation or update. 

For example, you could conditionally create a resource that depends on whether the stack is for a production or test environment.

Transform (optional)

For serverless applications (also referred to as Lambda-based applications), specifies the version of the AWS Serverless Application Model (AWS SAM) to use. 

When you specify a transform, you can use AWS SAM syntax to declare resources in your template. The model defines the syntax that you can use and how it is processed.

You can also use AWS::Include transforms to work with template snippets that are stored separately from the main AWS CloudFormation template. 

You can store your snippet files in an Amazon S3 bucket and then reuse the functions across multiple templates.

Resources (required)

Specifies the stack resources and their properties, such as an Amazon Elastic Compute Cloud instance or an Amazon Simple Storage Service bucket. You can refer to resources in the Resources and Outputs sections of the template.

Attributes

1. 1. DeletePolicy:

      1. If a resource has no DeletionPolicy attribute, AWS CloudFormation deletes the resource by default. 

      2. To keep a resource when its stack is deleted, specify Retain for that resource. You can use retain for any resource (default). 

      3. Example: The following snippet contains an Amazon S3 bucket resource with a Retain deletion policy. When this stack is deleted, CloudFormation leaves the bucket without deleting it. 

         1. {

         2.   "AWSTemplateFormatVersion" : "2010-09-09",

         3.   "Resources" : {

         4.     "myS3Bucket" : {

         5.       "Type" : "AWS::S3::Bucket",

         6.       "DeletionPolicy" : "Retain"

         7.     }

         8.   }

         9. }

   2. CreationPolicy

      1. Associate the CreationPolicy attribute with a resource to prevent its status from reaching create complete until AWS CloudFormation receives a specified number of success signals or the timeout period is exceeded. 

   3. DependsOn

      1. With the DependsOn attribute you can specify that the creation of a specific resource follows another. When you add a DependsOn attribute to a resource, that resource is created only after the creation of the resource specified in the DependsOn attribute. 

   4. Metadata

      1. The metadata attribute enables you to associate structured data with a resource. By adding a metadata attribute to a resource, you can add data in JSON or YAML to the resource declaration. 

   5. UpdatePolicy

      1. Use the UpdatePolicy attribute to specify how AWS CloudFormation handles updates to the following resources:

         1. AWS::AppStream::Fleet

         2. AWS::AutoScaling::AutoScalingGroup

         3. AWS::ElastiCache::ReplicationGroup

         4. AWS::OpenSearchService::Domain

         5. AWS::Elasticsearch::Domain

         6. AWS::Lambda::Alias

   6. UpdateReplacePolicy

      1. Use the UpdateReplacePolicy attribute to retain or, in some cases, backup the existing physical instance of a resource when it's replaced during a stack update operation. 

Outputs (optional)

Describes the values that are returned whenever you view your stack's properties. For example, you can declare an output for an S3 bucket name and then call the aws cloudformation describe-stacks AWS CLI command to view the name.

Example

1. {
     "AWSTemplateFormatVersion": "2010-09-09“
     "Description": "Create an EC2 instance running the latest Amazon Linux AMI.",
       "Parameters": {
           "KeyPair": {
               "Description": "The EC2 Key Pair to allow SSH access to the instance",
               "Type": "String“
           }
       },
       "Resources": {
           "Ec2Instance": {
               "Properties": {
                   "ImageId": "ami-9d23aeea",
                   "InstanceType" : "m3.medium",
                   "KeyName": {
                       "Ref": "KeyPair“
                   }
               },
               "Type": "AWS::EC2::Instance“
           }
       },
       "Outputs": {
           "InstanceId": {
               "Description": "The InstanceId of the newly created EC2 instance",
               "Value": {
                   "Ref": "Ec2Instance“
               }
           }
       },
   }

2. 
   

CloudFormation is designed to complement both Elastic Beanstalk and OpsWorks.

CloudFormation with Elastic Beanstalk

1. CloudFormation supports Elastic Beanstalk application environments as one of the AWS resource types.

2. This allows you, for example, to create and manage an AWS Elastic Beanstalk–hosted application along with an RDS database to store the application data. In addition to RDS instances, any other supported AWS resource can be added to the group as well.

CloudFormation with OpsWorks

1. CloudFormation also supports OpsWorks and OpsWorks components (stacks, layers, instances, and applications) can be modeled inside CloudFormation templates, and provisioned as CloudFormation stacks.

2. This enables you to document, version control, and share your OpsWorks configuration.

3. Unified CloudFormation template or separate CloudFormation templates can be created to provision OpsWorks components and other related AWS resources such as VPC and Elastic Load Balancer

Drift is the difference between the expected configuration values of stack resources defined in CloudFormation templates and the actual configuration values of these resources in the corresponding CloudFormation stacks. 

After you create a stack from a template, you can detect drift from the Console, CLI, or from your own code. 

You can detect drift on an entire stack or on a particular resource, and see the results in just a few minutes. You then have the information necessary to update the template or to bring the resource back into compliance, as appropriate.

When you initiate a check for drift detection, CloudFormation compares the current stack configuration to the one specified in the template that was used to create or update the stack and reports on any differences, providing you with detailed information on each one.

The initial list of resources spans API Gateway, Auto Scaling, CloudTrail, CloudWatch Events, CloudWatch Logs, DynamoDB, Amazon EC2, ELB, IAM, AWS IoT, Lambda, Amazon RDS, Route 53, Amazon S3, Amazon SNS, Amazon SQS, and more.

You can perform drift detection on stacks that are in the CREATE_COMPLETE, UPDATE_COMPLETE, UPDATE_ROLLBACK_COMPLETE, and UPDATE_ROLLBACK_FAILED states. 

CloudFormation only determines drift for property values that are explicitly set, either through the stack template or by specifying template parameters. This does not include default values for resource properties. To have CloudFormation track a resource property for purposes of determining drift, explicitly set the property value, even if you are setting it to the default value. 

The drift detection does not apply to other stacks that are nested within the one you check; you can do these checks yourself instead.

Example Using CloudFormation

Example Using CloudFormation