A (very) high level overview on AWS CloudFormation

What is AWS CloudFormation?

• AWS CloudFormation is an AWS native service with main focus on IaC (Infrastructure as Code) and one for the core components towards DevOps common practices in context of service deployments into AWS
• AWS CloudFormation is meant to handle AWS related infrastructure
• As with other services AWS CloudFormation is a so-called regional service while service such like R53 would be global ones

Things around AWS CloudFormation

• CloudFormation (aka CF) is the AWS „swiss army nife” service to codify resources in the AWS cloud
• Native AWS service that is available to be used with no extra costs (which obviously does not imply for the services that get deployed with AWS CF)
• AWS CF shines within the AWS cloud and therefore has no native integration into other clouds
• IaC outside AWS with CloudFormation is a bit tricky but AWS Lambda (so by building AWS custom resources) could become your friend
• AWS Quick Starts shares a repository of Third-Party tools
• Allows to deploy anything that can can be done manually through the Console
  • EC2, VPC, Subnet, RDS, …
• Native JSON or YAML to write high-level descriptive configuration files
• Graphical UI to generate deployments by drag-and-drop methodology
• CF always knows state of a given deployment at any time
• Deletion protection otherwise consistent cleanups with the benefit to not be left with leftover artifact
  • Though: additions outside the CF template’s deployment may not be deleted 
    (example a deployed service will generate SSM Parameter Store entries – those would not be deleted automatically)
• Deployment logs are available through CloudWatch
• In case of larger deployments and/or when to find the needle in the haystack AWS Athena can be used to search CloudWatch logs with native SQL
• Automated roll backs in case of failures
  • Helps to
    • Keep the environment secured so that in case of half-ready deployments security would be kept
    • Keep costs low since a half-ready and not functioning deployment still could cost money
  • “Nested stacks” with templates as modules
    • An individual template in a nested stack acts as a silo or block to create resources, infrastructure
    • Allows to create fully self-contained infrastructure deployments
      Therefore during removal no artifacts would be left over
    • Simplification to hand over and route parameters
    • Resources can be deployed by being dependent on other stacks
• Change sets to modify, change and update given deployments 
  (it though depends on the service if it would be an update or a replacement)
• Parameters can be handed through other templates at runtime (inside and outside a nested stack)
• AWS SSM can access AWS CloudFormation parameters at runtime for a given stack
• AWS AppConfig and/or AWS SSM Parameter Store to host configurations and parameters at an application level in addition to AWS CloudFormation makes it a very powerful combo
• Re-usable IaC
  • A best practice is to write templates as region, account, AZ agnostic as possible. Therefore  
    • the deployment itself will work as it has no hard bindings
    • the code can be re-used by others
• CF can be interacted with via the Console, the CLI or the API
  … think about the capabilities when mixing CF API, Automation, Ticketing system …