High Availability - Infrastructure as Code


Continuous Integration

  • Developers push the code to a code repository often
    • GitHub, BitBucket, CodeCommit (in AWS) etc…
  • A testing / build server checks the code as soon as it’s pushed
    • Jenkins CI, TeamCity, CodeBuild (in AWS), etc…
    • The developer gets feedback about the tests and checks that have passed / failed
  • Helps
    • Find bugs early, fix bugs
    • Deliver faster as the code is tested
    • Deploy often
    • Happier developers, as they’re unblocked

Continuous Delivery

  • Ensure that the software can be released reliably whenever needed.
  • Ensures deployments happen often and are quick
  • Automated deployment -> Shift away from e.g. “one release every 3 months” to 5 releases a day.
  • CodeDeploy in AWS, Jenkins CD, Spinnaker, etc…

Technology Stack

  • AWS CodePipeline allows you to automate all steps of the deployment:

    Step Name AWS Others
    1 Code CodeCommit GitHub, GitLab etc..
    2 Build & test CodeBuild Jenkins CI, TeamCity etc..
    3 Deploy ElasticBeanstalk, CodeDeploy Octopus
    4 Provision ElasticBeanstalk, CloudFormation Terraform
  • CodeDeploy

    • Two deployment options:
      1. In-place deployment: EC2/On-Premises apps are stopped & updated & validated.
      2. Blue/green deployment: Using slots (deploy A -> switch to A -> stop B) with minimal downtime and rollback capabilities.
        • EC2/On-Premises: Must have one ore more EC2 with tags or ASG
        • Lambda
          • Canary: Traffic is sifted in two increments, 90% to first version, 10% to second before 100% to second.
          • Linear: Traffic is shifted in equal increments with number of minutes e.g. 10% per minute.
          • All-at-once: All traffic is shifted at once.
        • Amazon ECS: Task set switches


  • Code will be deployed and create / update / delete infrastructure
    • Can be JSON or YAML.
  • Can be part of disaster recovery strategy.
  • Declarative way of outlining AWS infrastructure for any resources (most of them are supported)
    • CloudFormation provisions in the right order with the exact configuration that you specify.
  • 💡 Allows re-use the best practices around your company for configuration parameters.
  • Templates
    • You can upload in S3 and then reference in CloudFormation
    • Update a template
      • Can’t edit previous ones.
      • Have to re-upload a new version of the template to AWS.
    • Building Blocks
      • Cloud formation template consists of components and helpers:
        • Template components
          1. Resources: your AWS resources declared in the template (❗ mandatory)
          2. Parameters: the dynamic inputs for your template
            • Allows you to parameterize & prompt inputs while deploying.
          3. Mappings: the static variables for your template
          4. Outputs: References to what has been created
          5. Conditionals: List of conditions to perform resource creation
          6. Metadata
        • Template helpers
          1. References (Logical IDs are used to reference resources within the template)
          2. Functions
  • Templates
    • JSON or YAML text file that contains instructions for building out AWS environment
  • Change sets
    • Before making changes to your resources, you can generate a change set, which is a summary of your proposed changes, e.g. resource A will be deleted.
  • Stacks
    • The entire environment described by the template and created, updated, and deleted as a single unit
    • Related resources in a template.
      • When you update stack, it updates the resources
    • Can rollback on failure after timeout in minutes.
    • Termination protected with stack from being accidentally deleted.
    • Monitoring
      • Fires events such as on resource creation
      • Can have monitoring time (CloudFormation monitors resources during X minutes after creation)
      • Can set up CloudWatch alarms if something fails.
    • Can have IAM role or policy to deny/allow access.
    • Can use sample template or create one in Designer.
    • Identified by name
    • Can have input parameters that’ll be filled from portal.
    • Reusable output information
      • It’s output information (key, value, description) can be imported by other stacks by using an unique export/import name.
    • Stack Sets lets you create stacks in AWS accounts across regions by using a single AWS CloudFormation template
    • Operations
      • Deleting a stack -> deletes every artifact created by CloudFormation
      • Deploying templates/stacks
        1. by uploading YAML files directly or referencing to Amazon S3 URL
        2. Use a sample template
        3. Create template in Designer
          • Helps you to see resources & relations
          • Might be good for PowerPoints - ❗ Redeploying a stack deletes old instances.
      • Changing a stack
        • Done using Stack change sets
        • Warns you about resources that’ll be deleted, modified and added.
        • Drift: difference between the expected configuration values and actual deployed.
          • Allows you to better manage your CloudFormation stacks and ensure consistency in your resource configurations
  • Can deploy Elastic Beanstalk that’ll then deploy:
    • E.g. EC2, ALB, ASG, RDS
  • IAM Conditions for CloudFormation
    • cloudformation:TemplateURL: Ensure template in TemplateURL is used for e.g. update/delete.
    • cloudformation:ResourceTypes: Specify which types of resources can be created or updated.
    • cloudformation:StackPolicyURL
      • Stack policies prevents stack resources from unintentionally being updated or deleted during stack updates
      • You define which actions (t.ex. update) are allowed on which resources in a JSON file.


  • Control
    • No resources are manually created / configured.
    • Code can be version controlled e.g. using git.
    • Changes are reviewed through code
    • Cost control:
      • Each stack has ID: follow-up costs.
      • Estimate costs of a stack.
      • You can automate deletion of templates at 5 PM and recreation at 8 AM safely.
  • More productivity:
    • Destroy and re-create an infrastructure on the cloud on the fly.
    • Automated generation of diagram for your templates!
    • Declarative programming (no need to figure out ordering and orchestration)
  • Better separation of concerns:
    • Many stacks for many apps, and many layers.
    • E.g. VPC stacks, network stacks, app stacks


  • AWS managed service for Chef & Puppet
  • They work great with EC2 & On Premise VM
  • Alternative to AWS SSM (Systems Manager)
  • OpsWorks stacks
    • Groups applications into layers depending on Chef recipes
    • No need to provision chef server
    • Uses the embedded Chef solo client that is installed on EC2 instances on your behalf

Systems Manager

  • Serverless & free & open-source
  • Is built-in in AWS AMIs
  • Does not require any jump-boxes (bastion hosts)
  • Can run Ansible, PowerShell DSC or any script from S3 through Run command.
  • Can use AWS Systems Manager Automation
    • Leverages documents for tasks that can be automated.

Chef & Puppet

  • Help with managing server configuration as code
  • Helps in having consistent deployments
    • Can automate: user accounts, cron, NTP, packages, services
  • They leverage “Recipes” or “Manifests”
  • Similar to SSM / Beanstalk / CloudFormation but they’re open-source tools that work cross-cloud.

Serverless applications

  • Serverless applications are e.g. Lambda, DynamoDB, API Gateway…
  • To be order to locally run, debug and easily deploy serverless applications you can use:
    • AWS Serverless Application Model (AWS SAM)
      • Open source tool used to package, test, and deploy serverless applications
      • YAML based infrastructure as code.
    • serverless.com
      • Vendor-neutral (Azure, Google, AWS) serverless framework.
      • YAML-based infrastructure as code.

Licenses and Attributions

Speak Your Mind