AWS re:Invent Notes: GPSTEC319 — GPS: Build Once, Deploy Many: Architecting Deployments CloudFormation

Here are some raw notes from GPSTEC319  —  GPS: Build Once, Deploy Many: Architecting and Building Automated, Reusable Reference Deployments with AWS CloudFormation

---

what they learned from building over 50 reference deployments

by automating deployments, we can reduce human error

A day in the life of IT (stages)

• discover solutions to a business problem (partner, vendor, demo, try it out, PoC, etc
• try (PoC)
• deploy
  • deploy to staging
  • then to production
• then back to discovery

AWS Quick Start

• automated reference deployments on AWS
• help streamline installation and configuration of workloads on AWS
• primarily a tech program
• work with partners team
• focus on enabling customers
• wide spectrum of quick starts
• aim to reduce complexity (picture)
  • can take over 100 steps to create multi-AZ VPC, with quick start it’s easier

How do you build a quick start reference deployment/architecture:

• Plan and Design
• Build and Test
• Optimize and Enhance

Plan and Design

• the value of planning
  • define the scope and organization of the assets
  • produced architectural diagrams
• attributes of great architectures
  • secure
    • tips
      • lock down external admin access (CIDR block)
      • implement security groups with principle of least privilege and role-based access (don’t open all ports, just what is necessary)
      • no default passwords (but provide a way to set one) – change at first login
      • use public and private subnets (sensitive workloads in private)
      • avoid outputting secrets Iin logs and scrub as needed
      • implement ways of auditing access and usage
  • reliable
    • tips
      • span multiple AZs (separate fault domains)
      • consider multiple regions for DR
      • regularly create snapshots of data
      • implement health checks to remove/replace problematic nodes (meaningful checks, server serving content?
      • scale up to handle additional load
  • performant
    • tips
      • deliver static content from edge network locations (CloudFront)
      • implement caching where it makes sense (where there is a close cache)
      • avoid storing state in compute or app-level instances
        • if node down, don’t want to have session state in that, would log user out / dynamoDB
      • utilize high performance features of load balancers
        • SSL offloading
      • run on instance types with appropriate compute/RAM/storage
      • take advantage of HP database services like Aurora or DynamoDB
  • efficient
    • tips
      • scale down based on load
        • in automated fashion based on events/actions
      • explore containerized solutions for higher compute density
      • separate constant load as opposed to bursty load
        • reserved instances vs. spot
      • implement pay-per-execution serverless components
        • can you use Lambda?
      • use services with lower operational burden like RDS, EFS, Directory Service
        • no need to worry about patching / is it running

AWS Well-Architected Framework

security / reliability / performance efficiency / cost optimization / operation excellence

Build and Test a reference deployment

• Recurring themes
  • Scripting
    • chef, puppet, ansible
  • Orchestration
  • Source control
    • capture versioning history

common commands that are run as deployments/reference architectures have been created

AWS CloudFormation – Orchestration side

Template anatomy

• only one item required – Resources
  • think of it as a program
• AWSTemplateFormatVersion
• Description
• Metadata
• Parameters
• Mappings
• Conditions
• Rules
  • from AWS Service Catalog
  • have to use specific instance or regions (ex.)
• Transform
• Outputs
  • show relevant information to user / what is VPC ID

Stacks

• stack is a single unit to manage related AWS resources
• you can create, update, and delete

CFN-INIT

• enables a variety of scripting languages for bootsrapping
• credentials are specified in Authentication section
• Configuration is stored in Init section
• executes as “root” or “administrator” (Windows)

SOURCE CONTROL

• define a strategy for organizing the assets within a repository
• helps keep all files in the expected locations
• make use of submodules for common code (get modules)
• avoid storing software bits/binaries

OPTIMIZE AND ENHANCE

Attributes of great templates

• Maintainable
  • tips
    • store in source control systems and version (see what differentials are / revert if needed)
    • testing can be easily automated and on a recurring basis
    • implement stack nesting to reuse common template patterns
    • use intrinsic functions to resolve and combine properties (Ref, Join, Sub, GetAtt, etc)
• Flexible
  • tips
    • relative paths to resolve external template assets (other scripts)
    • assets can be moved to a different S3 bucket
    • driven by parameters, mappings, and conditions
      • deploy or not deploy based on parameters
    • run on multiple AWS regions/accounts (concurrently)
    • supports AWS GovCloud (via conditionals)
• Reusable
  • tips
    • new and existing VPC deployments (support them both)  want to make sure your script works with new or existing deployments
    • templates based on roles
      • template for DB, for networking, etc.
    • make use of common templates as submodules
    • combine templates to build a larger and/or more complex deployment
      • combine compute types
    • do not use named resources (avoids global resource collisions)
      • CloudFromation can dynamically name stuff
• Standardized
  • tips
    • settle on spaces or tabs (or other coding conditions)
    • beautification and readability of templates
    • sensible and common defaults across other architectures
    • predictable AMI mappings (helps in automated maintenance too)