2. Agenda
• Introduction
• Best practices
• Key new features
• YAML support
• Cross-stack references
• Q & A’s
New
New
3. AWS CloudFormation
• Create templates that describe and model AWS
infrastructure
• CloudFormation then provisions AWS resources
based on dependency needs
• Version control/replicate/update the templates like
application code
• Integrates with development, CI/CD, management
tools
• No additional charge to use
4. CloudFormation concepts and technology
JSON/YAML formatted file
Parameter definition
Resource creation
Configuration actions
Framework
Stack creation
Stack updates
Error detection and rollback
Configured AWS resources
Comprehensive service support
Service event aware
Customizable
Template CloudFormation Stack
14. Avoid manual resource modifications
• Avoid making quick-fixes out of band
• Update your stacks with CloudFormation
• Do not manually change resources
• Consider using resource based permissions to limit
ability to make changes directly
20. cfn-init
cfn-hup
AWS CloudFormation provides helper
scripts for deployment within your
EC2 instances
Metadata Key —
AWS::CloudFormation::Init
Cfn-init reads this metadata key and
installs the packages listed in this key
(e.g., httpd, mysql, and php). Cfn-init
also retrieves and expands files listed
as sources.
Amazon EC2
AWS CloudFormation
cfn-signal
cfn-get-
metadata
Bootstrap your applications using helper scripts
23. Ownership based template design
• Use Microservices approach to define templates
• Limit one template to a single service
• Use nested stacks and cross-stack reference to break
up large templates
• Organize templates according to team structure/job
function/line of business
32. Best Practices Summary
• CloudFormation Designer
• Avoid manual resource
modifications
• Preview updates with Change
Sets
• Learn the intrinsic functions
• Bootstrap your applications using
UserData and helper scripts
• Protect critical resources using
stack policiess
• Ownership based
template design
• Plan for multi-region
• Use Pseudo-Parameters
• Use Mappings
• Use Conditionals
33. Key new features
• YAML formatted templates
• Overview of template structure / basics
• New function formatting (!Ref / !GetAZs / !FindInMap)
• New Intrinsic Function ( Fn::Sub )
•Cross Stack References
• New function Fn::ImportValue
• Allows use of outputs from unrelated stacks without custom
resource
New
New
34. CloudFormation - YAML
Why YAML?
• Better authoring and readability of templates
• Comments – Finally Yay!!
• Simplification as templates get more and more complex
New
35. Cloudformation - YAML
• Structure is shown through indentation (one or more spaces).
• Sequence items are denoted by a dash
• Key value pairs within a map are separated by a colon.
• Tips: Use a monospace font, don’t use Tab, save using UTF-8
Resources:
VPC1:
Type: "AWS::EC2::VPC"
Properties:
CidrBlock: !Ref VPC1Cidr
Tags:
-
Key: "Name"
Value: "TroubleShooting"
36. CloudFormation – YAML Template Structure
All sections is the same as in a JSON template
---
AWSTemplateFormatVersion: "version date"
Description:
String
Metadata:
template metadata
Parameters:
set of parameters
Mappings:
set of mappings
Conditions:
set of conditions
Resources:
set of resources
Outputs:
set of outputs
37. CloudFormation – YAML Function Declaration
• Two ways to declare Intrinsic functions: Long and Short
• Short Form:
• !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]
• Long Form:
• "Fn::FindInMap" : [ "MapName", "TopLevelKey", "SecondLevelKey"]
• Tag = ! (Its not Negation operator)
• Few things to note with Tags
• You cannot use one tag immediately after another
• !Base64 !Sub…
• Instead, you can do this
• "Fn::Base64": !Sub...
• !Select [ !Ref Value, [1,2,3]]
38. CloudFormation – Intrinsic Functions
Fn::Base64 Fn::And
Short !Base64 valueToEncode Short !And [condition]
Long "Fn::Base64": valueToEncode Long "Fn::And": [condition]
Fn::Equals Fn::If
Short !Equals [value_1, value_2] Short !If [condition_name, value_if_true, value_if_false]
Long "Fn::Equals": [value_1, value_2] Long "Fn::If": [condition_name, value_if_true, value_if_false]
Fn::Not Fn::Or
Short !Not [condition] Short !Or [condition, ...]
Long "Fn::Not": [condition] Long "Fn::Or": [condition, ...]
39. CloudFormation – Intrinsic Functions Cont.
Fn::FindInMap
Short !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]
Long "Fn::FindInMap" : [ "MapName", "TopLevelKey", "SecondLevelKey"]
Fn::GetAtt
Short A) !GetAtt logicalNameOfResource.attributeName
B) !GetAtt
- logicalID
- attributeName
C) !GetAtt [logicalID, attributeName]
Long "Fn::GetAtt": [ logicalNameOfResource, attributeName ]
40. CloudFormation – Intrinsic Functions Cont. 2
Fn::Join
Short A) !Join [ delimiter, [ comma-delimited list of values ] ]
B) !Join
- delimiter
-
- value1
- value2
Long "Fn::Join": [ delimiter, [ comma-delimited list of values ] ]
Fn::GetAZs
Short A) !GetAZs region (e:g !GetAZs "us-east-1")
B) !GetAZs “”
C) !GetAZs {Ref : "AWS::Region"}
Long "Fn::GetAZs": region
41. CloudFormation – Intrinsic Functions Cont. 3
Fn::Select
Short A) !Select [ index, listOfObjects ]
B) !Select
- index
-
- value1
- value2
Long "Fn::Select": [ index, listOfObjects ]
Ref Fn::ImportValue
Short !Ref logicalName Short !ImportValue sharedValueToImport
Long “Ref”: logicalName Long "Fn::ImportValue": sharedValueToImport
42. CloudFormation – Fn::Sub
• Substitute variables in an input string with values
• Function accepts a string or a map as a parameter.
• Usage
• VarName: ${MyVariableValue}
• Literal: ${!LiteralValue}
• Use | if you are spanning multiple lines
• Available in JSON as well
New
43. CloudFormation – Fn::Sub Declaration
Fn::Sub
Option 1 Short:
!Sub
- String
- VarName: VarValue
Long:
"Fn::Sub":
- String
- VarName: VarValue
Option 2
When you’re
only substituting
parameters,
logical IDs, or
resource
attributes do not
specify a
variable
mapping
Short:
!Sub String
Long:
"Fn::Sub": String
45. CloudFormation – Cross Stack References
• Sharing resources made easy
• IAM roles, VPC, Security groups
• Add an explicit “Export” declaration to stack output
• Use the resource in another stack using a new intrinsic function,
Fn::ImportValue`
• Few guidelines:
• Export names must be unique within an account and region
• Cannot create references across regions
• Cannot delete a stack that is referenced by another stack (Dependencies are
communicated in errors)
• Outputs cannot be modified or removed as long as it is referenced by a
current stack
New
46. CloudFormation – Fn::ImportValue
The new intrinsic function for accessing exported outputs.
JSON
{ "Fn::ImportValue" : sharedValueToImport }
YAML
"Fn::ImportValue": sharedValueToImport
!ImportValue sharedValueToImport
Ask us questions, we have moderators who can help answer those. We will use some time at the end so that we can answer some of these questions live
Webcast will be recorded, we will send you url to the recording as well as the slide deck
CloudFormation allows you to declaratively model your infrastructures architecture into a template.
For example the template for a simple web application could include things such as Amazon EC2 instances, an Elastic Load Balancer and an Amazon RDS instance.
For more complicated architectures it can also include a lot more such as Lambda functions, SNS queues , DynamoDB tables or IAM policies.
Once you have finished authoring your template you then upload it to CloudFormation and we take care of all the fine details of provisioning the infrastructure into what we call a stack.
Using Cloudformation you don’t need to worry about the ins and outs of each of the different services APIs, we take care of that for you.
Once your infrastructure has been provisioned you can make changes to it by modifying your template and CloudFormation will work out how to apply those changes to your infrastructure.
As we will discuss in this presentation this process can be automated into your existing deployment pipelines with things like Jenkins. The templates can be also included into your existing development processes and be stored in source control and be code reviewed.
CloudFormation allows you to declaratively model your infrastructures architecture into a template.
For example the template for a simple web application could include things such as Amazon EC2 instances, an Elastic Load Balancer and an Amazon RDS instance.
For more complicated architectures it can also include a lot more such as Lambda functions, SNS queues , DynamoDB tables or IAM policies.
Once you have finished authoring your template you then upload it to CloudFormation and we take care of all the fine details of provisioning the infrastructure into what we call a stack.
Using Cloudformation you don’t need to worry about the ins and outs of each of the different services APIs, we take care of that for you.
Once your infrastructure has been provisioned you can make changes to it by modifying your template and CloudFormation will work out how to apply those changes to your infrastructure.
As we will discuss in this presentation this process can be automated into your existing deployment pipelines with things like Jenkins. The templates can be also included into your existing development processes and be stored in source control and be code reviewed.
So if you look at the components behind Cloudformation. It's starts off with a template.
This is the JSON formatted script file, that deals with things like parameter definition that drive a user driven template, such as name of my databases.
It deals with the resource creation, so the creation of AWS components such as EC2 instances or RDS databases.
And it deals with the configuration actions I wish to apply against this resources, so it might be install software or might be creating an SQS queue for example.
Than that template is deployed into the cloud formation framework. And the framework deals what we call Stack creation, updates and any error detection and rollback required in the creation of a stack.
So a stack is collection of resources that you want to manage together. And the resulting artifact is what we call a Stack of configured AWS services. So this could be in an Elastic Load Balancer and Autosclaing group with EC2 instances and an RDS database.
So the stack is service event aware, the stack creation actions or the changing of that environment can be feed back into Cloudfomration and trigger actions within the CloudFormation tempalte.
And it is also customizable, so once you created a stack you can of course access the underlying resources and change them of modify them as you so which.
Now the error detection and rollback is an interesting point. If at any time in the stack creation a problem is detected, the default behaviour of Cloudformation is to roll-back the creation of all resources and put you back in a constitent known state. So you know if your stack is working or is rolled back and is not.
The development process that you use for developing business logic can be the same as what you when writing CloudFormation templates.
You start of with your favorite IDE or Text Editor to write the code, Eclipse, VIM or VisualStudio
You then commit to template to your source code repository using your usual branching strategy
and then have the template reviewed as part of your typical code review process.
The template is then integrated and run as part of your CI and CD pipelines.
Being simply a JSON document, you can even write Unit Tests for your templates. When developing a CloudFormation template you can use all of your normal software engineering principles
At the end of the day
It’s all software – a template can be reused across applications – just like code library's and a stack can be shared by multiple applications.
The development process that you use for developing business logic can be the same as what you when writing CloudFormation templates.
You start of with your favorite IDE or Text Editor to write the code, Eclipse, VIM or VisualStudio
You then commit to template to your source code repository using your usual branching strategy
and then have the template reviewed as part of your typical code review process.
The template is then integrated and run as part of your CI and CD pipelines.
Being simply a JSON document, you can even write Unit Tests for your templates. When developing a CloudFormation template you can use all of your normal software engineering principles
At the end of the day
It’s all software – a template can be reused across applications – just like code library's and a stack can be shared by multiple applications.
The development process that you use for developing business logic can be the same as what you when writing CloudFormation templates.
You start of with your favorite IDE or Text Editor to write the code, Eclipse, VIM or VisualStudio
You then commit to template to your source code repository using your usual branching strategy
and then have the template reviewed as part of your typical code review process.
The template is then integrated and run as part of your CI and CD pipelines.
Being simply a JSON document, you can even write Unit Tests for your templates. When developing a CloudFormation template you can use all of your normal software engineering principles
At the end of the day
It’s all software – a template can be reused across applications – just like code library's and a stack can be shared by multiple applications.
Resources – EC2 instances, VPC,
Parameters – is a way to ask questions during template creation for user inputs. It contains a list of attributes with values and constraints. User inputs can be Instance types, keynames, VPC ID’s, Username Passwords for DB’s etc.
Notice, Keyname doesn’t have default attribute and EC2InstanceType does. CFn fails to create a stack if no value is chosen. You will also notice that the key names are a drop down list to choose from
Another neat feature, we are forcing the users to choose from 3 instance types. So you can restrict your templates to use only specific values if needed.
Outputs is a way to provide your output of CFn stack. Here is where your resource output goes like website url’s, any resource you created that are useful for other stacks
CloudFormation supports provisioning in over 20 AWS services, and we are continuously expanding the AWS services supported in CloudFormation.
But, what if you want to provision something that is not supported in CloudFormation today?
What if, you want to provision something on-premises when you provision a CloudFormation stack?
What if, you want to provision something in a 3rd party service?
There are a few different ways to achieve that.
Intrinsic functions are
Conditions for turning resources on or off during provisioning
Helper functions to look up environment info and operations such as string manipulation
AWS CloudFormation provides the following helpers to allow you to deploy your application code or application and OS configuration at the time you launch your EC2 instances:
cfn-init: Used to retrieve and interpret the resource metadata, installing packages, creating files and starting services.
cfn-signal: A simple wrapper to signal a CloudFormation WaitCondition allowing you to synchronize other resources in the stack with the application being ready.
cfn-get-metadata: A wrapper script making it easy to retrieve either all metadata defined for a resource or path to a specific key or subtree of the resource metadata.
cfn-hup: A daemon to check for updates to metadata and execute custom hooks when the changes are detected.
Supports YAML 1.1 specification except for:
Hash merges
Aliases
The binary, omap, pairs, TIMESTAMP, and set tags
Supports all CloudFormation features and functions except for CloudFormation Designer
You can construct commands or outputs that include values that aren’t available until you create or update a stack
Use pipe symbol = | for spanning multiple lines