Deploying Application Stack Updates to AWS Environments

This guide focuses on the mechanisms and strategies for updating existing application stacks across different environments (Development, Staging, Production) using AWS Infrastructure as Code (IaC) and deployment services.

Learning Objectives

• Update IaC Templates: Modify and deploy AWS SAM and CloudFormation templates to existing stacks.
• Manage Environment Parity: Use parameters and configurations to differentiate between staging and production environments.
• Execute Deployment Strategies: Implement Canary, Blue/Green, and Linear shifts using AWS CodeDeploy.
• Handle Runtime Configurations: Utilize API Gateway staging variables and Lambda aliases to manage environment-specific logic.

Key Terms & Glossary

• AWS SAM (Serverless Application Model): An extension of CloudFormation specifically for serverless applications, simplifying the definition of functions, APIs, and tables.
• Stack: A collection of AWS resources managed as a single unit via CloudFormation.
• Change Set: A preview of changes CloudFormation will make to your stack before you execute the update.
• Staging Variable: A name-value pair used in API Gateway to change the behavior of an API stage (e.g., pointing to a different Lambda alias).
• Lambda Alias: A pointer to a specific Lambda function version, allowing you to promote code (e.g., from PROD to DEV) without changing the client-side configuration.

The "Big Idea"

Updating application stacks is not just about changing code; it's about consistent promotion. The goal is to ensure that the template used in a Staging environment is identical to the one used in Production, with only environment-specific "knobs" (Parameters) changing. This reduces "environment drift" and ensures that a successful test in Staging accurately predicts success in Production.

Formula / Concept Box

Hierarchical Outline

1. Infrastructure as Code (IaC) Updates
   • AWS SAM CLI: Using sam deploy to push updates.
   • Parameter Overrides: Using --parameter-overrides to pass environment-specific values (e.g., DBName=prod-db).
   • Configuration Files: Using samconfig.toml to define multiple environments (e.g., [staging.deploy.parameters]).
2. Environment Management
   • API Gateway Stages: Differentiating dev, test, and prod endpoints.
   • Lambda Aliases: Using aliases (e.g., STABLE, LATEST) for traffic shifting.
   • AWS AppConfig: Managing application-level configurations without redeploying code.
3. Deployment Automation
   • AWS CodeDeploy: Automating the rollout to EC2, Lambda, or ECS.
   • Deployment Groups: Defining the target instances or functions for the update.

Visual Anchors

Deployment Pipeline Flow

Lambda Alias Traffic Shifting

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, rounded corners, minimum height=1cm, minimum width=2.5cm, align=center}] \node (client) {Client Request}; \node (alias) [right=of client, fill=blue!10] {Lambda Alias$PROD)}; \node (v1) [above right=of alias, fill=green!10] {Version 1$Old)}; \node (v2) [below right=of alias, fill=yellow!10] {Version 2$New)};

\draw[->, thick] (client) -- (alias); \draw[->, thick] (alias) -- node[above, sloped] {90%} (v1); \draw[->, thick, dashed] (alias) -- node[below, sloped] {10% (Canary)} (v2); \end{tikzpicture}

Definition-Example Pairs

• Parameter Mapping: The process of using a single template but injecting different values per environment.
  • Example: A CloudFormation template defines DBInstanceClass as a parameter. In Staging, you pass t3.micro to save costs; in Production, you pass r5.large for performance.
• Rollback Configuration: Automated reversal of a deployment if health checks fail.
  • Example: Using CloudWatch Alarms to trigger a CodeDeploy rollback if the 5XXError rate on a new Lambda version exceeds 1% during the first 10 minutes of deployment.

Worked Examples

Scenario: Deploying a SAM Template to Staging

Goal: Update an existing Lambda function in the staging environment with a specific database connection string.

1. Modify the Template: In template.yaml, define a parameter:
   yamlCopy

   Parameters: EnvName: Type: String Default: dev
2. Run Deploy Command: Use the SAM CLI to target the existing staging stack:
   bashCopy

   sam deploy \ --stack-name my-app-staging \ --parameter-overrides EnvName=staging DBConn=jdbc:mysql://staging-db:3306 \ --capabilities CAPABILITY_IAM
3. Verify: Log into the console and check the Change Set tab in CloudFormation to see exactly which resources (e.g., Lambda environment variables) will be modified.

Checkpoint Questions

1. What AWS service allows you to preview changes to a stack before they are applied?
2. If you want to shift 10% of traffic to a new Lambda version every 5 minutes, which CodeDeploy configuration should you use?
3. How do API Gateway Staging Variables interact with Lambda functions?
4. What is the benefit of using samconfig.toml for multi-environment deployments?

▶Click to see answers

1. AWS CloudFormation Change Sets.
2. Linear10PercentEvery5Minutes.
3. They can be passed as part of the context or used to dynamically determine which Lambda Alias or function ARN to invoke.
4. It allows you to store environment-specific deployment parameters (like stack name and S3 bucket) so you don't have to type long CLI commands manually for every update.