CloudFormation lets you model, provision, and manage AWS and third-party resources by treating infrastructure as code (IaC). It’s a declarative (meaning you don’t need to figure out ordering) method of defining and creating infrastructure for any AWS resource. No resources are manually created (i.e. avoid environment drift). The IaC can be version controlled and therefore coding best practices can be leveraged. Enables you to create & destroy infrastructure easily. Bonus : automated generation of diagrams. *Will not need to write CFTs for the exam*
CF is free, but resources are not. Each resource made in a stack is tagged with an ID (for cost monitoring) so you can estimate cost of resources made in stack.
Use Cases:
- Manage infra with DevOps
- Replicate infra quickly
- Scale production stacks elastically
- Control & track changes to infra
- Document and enforce best practices
******Read the User Guide ******
Run through the AWS CloudFormation Workshop (Basic, Intermediate, & Advanced)
- Templates have to be uploaded to S3
- Manual deployment:
- Edit template in CloudFormation Designer
- Use console to input parameters
- Automated deployment:
- Edit YAML file
- Use AWS CLI to deploy template
- this method recommended for fully automated deployment methods
CF Template components:
- Resources (mandatory):
- The actual things made by the CFT
- Resources are declared & can reference each other
- Resource type identifiers are in the form:
service-provider::service-name::data-type-name
- Parameters – dynamic inputs
- great for reuse of templates
- use if a resource’s configuration would likely change in new CF deploys
- some inputs cannot be determined ahead of time
- Settings to control Parameters:
- Type:
- String
- Number
- Comma delimited list
- List
- AWS Parameter
- Description
- Constraints
- ConstraintDescription
- Min/MaxLength/Value
- Defaults
- AllowedValues (array)
- AllowedPattern (regex)
- NoEcho (bool)
- Type:
- referenced using the Fn::Ref function. (in YAML
!Ref
) - Pseudo Parameters
- Mappings – static variables
- Fixed variables in your CFT
- Handy for differentiating between different types of environments (dev vs prod)
- Values are hardcoded into the template
- Use Mappings over Parameters when all values that can be chosen are known in advance
- Allow safer control over the template
- Use
Fn::FindInMap
to return a named value from a key (JSON) - YAML example:
!FindInMap [MapName, TopLevelKey, SecondLevelKey]
- Outputs – (popular exam questions) what has been created
- Declares optional output values that can then be imported into other stacks
- Useful for cross-stack ‘collaboration’
- Can’t delete a CF stack if it’s outputs are being referenced by another CF stack
- You can’t modify or remove an output value that is referenced by another stack
- Use the
Fn::ImportValue
(JSON) /!ImportValue
(YAML) function to leverage an output in another stack
- Conditions – if statements for making resources
- Environment (dev / test / prod) differentiator
- During a stack update, you can’t update conditions by themselves. You can update conditions only when you include changes that add, modify, or delete resources
- Know the Condition functions
- Metadata – arbitrary objects to provide additional details about the template
The Must Know Intrinsic Functions: !Ref, !GetAtt, !FindInMap, !ImportValue, !Join, !Sub
!Base64
/ Fn::Base64
is used to pass in UserData. UserData script log is in /var/log/cloud-init-output.log
Use cfn-init for more complicated deployments (more readable than UserData scripts). Log information for this kind of deployment is in /var/log/cfn-init.log
Use cfn-signal to create a wait condition to prevent a CFT from completing until your resources are fully deployed (e.g. software installed on EC2 instances are up and running).
- Stack failure options:
- CreateStack API
- Default – OnFailure=ROLLBACK
- Troubleshoot – OnFailure=DO_NOTHING
- Delete – OnFailure=DELETE
- UpdateStack API
- automatically rolls back to previous known working state
- CreateStack API
- Nested stacks are just what they sound like 🙂
- Used for isolating repeated patterns & reusing common components
- Considered best practice
- Create a nested stack using the
AWS::CloudFormation::Stack
resource - To update a nested stack, always update the root/parent stack
ChangeSets – allow you to preview how proposed changes to a stack might impact your running resources. Don’t indicate whether CloudFormation will successfully update a stack.
Deletion Policy – can be applied to any resource created. Options are Delete
, Retain
, or Snapshot
. Know the default behaviors for AWS::RDS::DBCluster
and AWS::RDS::DBInstance
. For Amazon S3 buckets, you must delete all objects in the bucket for deletion to succeed.
Know the steps for enabling/disabling stack termination protection.