CloudFormation - seanremenyi/Notes_aws_developer GitHub Wiki

Manage, configure and provision your AWS infrastructure code

resources are defined using a cloudformation template Cloudformation interprets the template and makes appropriate API calls to create the resources you have defined Supports YAML or JSON

Benefits: Consistent: Infrastructure is provisioned consistently with fewer mistakes Quick and effictient: Less time and effort than configuring things manually Version Control: You can version control and peer review your templates Free to use: Free to use but you are charged for the aws resources you create using CloudFormation Manage updates: Can be used to manage updates and dependencies Rolling back: You can roll back to a previous state and delet the entire stack as well

YAML or JSON template: YAML or JSON template used to describe the end state of the infrastructure you are either provisioning or changing S3: After creating the template, you up load it to CloudFormation using s3 API calls: CloudFormation reads the template and makes the API calls on your behalf CloudFormation Stack: The resulting set of resources that CloudFormation builds from your template is called a "stack"

Template:

Resources section is Mandatory: Resources is the only mandatory section of the cloudformation template The transform section is for referencing additional code: The transform section is used to refernce additional code stored in S3, allowing for code re-use. E.g. Lambda code or template snippets/reusable prices of CloudFormation code Infrastructure as code: Cloudformation allows you to maage, configure and privision aws infrastructure as YAML or JSON code Parameters: Input custom values Conditions: e.g. provision resources based on environment Resources: This section is mandatory and describes the AWS resources that CloudFormation ill create Mappings: Allows you to create custtom mapping like region:AMI Transform: Allows you to reference code located in S3 e.g. lambda code or reusable snippets of CloudFormation code

Cloudformation and SAM (Serverless Application Model)

CloudFormation for serverless: The Serverless Application Model is an extension to CloudFormation to define serverless applications Simplified Syntax: SAM uses a simplified syntax for defining serverless resources, APIs, Lambda functions, DynamoDB tables,etc. SAM CLI: Use the SAM CLI to package your deployment code, upload it to S3 and deploy your serverless application defines and provision serverless applications using CloudFormation, has its own cli and own commands sam package pacages your application and uploads to s3 sam deploy deploys your serverless app using Cloudformation

Cloud formation Nested Stacks: Nested stacks: Enables re-use of Cloudformation code for common cases E.g. standard configureatin for a load balancer, web server or application server Instead of copying out the code each, time, create a standard template for each common use case and reference from within your CloudFormation template

Correct. By default, the “automatic rollback on error” feature is enabled. This will direct CloudFormation to only create or update all resources in your stack if all individual operations succeed. If they do not, CloudFormation reverts the stack to the last known stable configuration. The Transform section specifies one or more macros that AWS CloudFormation uses to process your template. The Transform section builds on the simple, declarative language of AWS CloudFormation with a powerful macro system. The declaration Transform: AWS::Serverless-2016-10-31 is required for AWS SAM template files.

How can you prevent CloudFormation from deleting your entire stack on failure?

Use the --disable-rollback flag with the AWS CLI

Set the 'Rollback on failure' radio button to No in the CloudFormation console

Correct. This AWS CLI option disables the rollback of the stack if stack creation fails.

Correct. This AWS CloudFormation console option disables the rollback of the stack if stack creation fails.

Transforms is used to reference code located in S3 and also for specifying the use of the Serverless Application Model (SAM) for Lambda deployments.

AppSpec files on an EC2/on-premises compute platform must be a YAML-formatted file named appspec.yml and it must be placed in the root of the directory structure of an application's source code. Otherwise, deployments fail. Reference: CodeDeploy AppSpec File reference.