Question

Difficulty: HardDeployment Strategy Design

An enterprise architecture team is designing a deployment workflow for a critical customer-facing microservice running on Amazon ECS with the AWS Fargate launch type behind an Application Load Balancer. The update process must be managed using AWS CloudFormation. The team requires a traffic shifting model that shifts 10%10\% of production traffic to the new version initially, and then progressively increases the traffic by 10%10\% every 55 minutes until the new version handles 100%100\% of the traffic. If any CloudWatch alarms are triggered during the deployment or during a subsequent 1515-minute monitoring window, the deployment must automatically roll back.

Which configuration represents the most operationally efficient method to achieve these requirements?

  1. A
    Define the ECS service deployment controller type as `ECS` in the CloudFormation template. Create an AWS CodeDeploy deployment group that uses the `CodeDeployDefault.ECSCanary10Percent5Minutes` configuration. Configure the Application Load Balancer with a single target group, and configure CodeDeploy to register new tasks directly into this target group. Associate the CloudWatch alarms with the deployment group, and set the rollback wait time to 1515 minutes.
  2. B
    Configure the CloudFormation template to update the ECS service using the default rolling update deployment controller. Set the service's minimum healthy percent to 50%50\% and maximum percent to 200%200\%. Configure a Route 53 weighted record set pointing to two different Application Load Balancer DNS names representing the old and new task versions. Use a custom AWS Lambda function triggered by a CloudWatch event rule to shift Route 53 weights by 10%10\% every 55 minutes, and revert the weights to 100%100\% on the old version if the alarms are triggered.
  3. Define the ECS service deployment controller type as `CodeDeploy` in the CloudFormation template. Use the `AWS::CodeDeploy::BlueGreen` hook to manage the deployment. Create a custom CodeDeploy deployment configuration specifying a time-based linear traffic routing of 10%10\% every 55 minutes. Configure the CodeDeploy deployment group with two target groups, associate the target CloudWatch alarms, and set the original task set termination wait time to 1515 minutes with automatic rollback enabled.Answer
  4. D
    Update the ECS service deployment controller type to `External` in the CloudFormation template. Use an AWS Lambda-backed custom resource in CloudFormation to invoke a custom AWS Step Functions state machine that updates the Application Load Balancer target group weights by 10%10\% every 55 minutes. Include a step in the state machine to monitor the CloudWatch alarms for 1515 minutes after 100%100\% traffic is reached, and trigger a target group weight rollback if any alarm is activated.

Answer

The configuration that sets the ECS service deployment controller to CodeDeploy, utilizes the CloudFormation BlueGreen hook, defines a custom linear deployment configuration of 10% every 5 minutes, and sets the original task set termination wait time to 15 minutes is correct.
The correct option natively integrates AWS CloudFormation, Amazon ECS, and AWS CodeDeploy. By declaring the ECS service deployment controller as `CodeDeploy` and using the `AWS::CodeDeploy::BlueGreen` transform hook, CloudFormation delegates the update process to CodeDeploy. CodeDeploy handles traffic shifting using two target groups, applying the custom time-based linear configuration (10%10\% every 55 minutes). The 1515-minute baking period is configured using the original task set's termination wait time; if any associated CloudWatch alarms trigger during this interval, CodeDeploy automatically rolls back the traffic to the original task set without downtime.

Step-by-Step Solution

1
Determine the appropriate deployment controller and integration method for CloudFormation.
Identify that the ECS service must use `DeploymentController: { Type: 'CODE_DEPLOY' }` and the CloudFormation template must invoke the `AWS::CodeDeploy::BlueGreen` hook to intercept updates and delegate traffic routing to CodeDeploy.
This enables native CloudFormation-managed Blue/Green updates, eliminating custom scripting.
2
Define the traffic shifting configuration in CodeDeploy.
Create a custom CodeDeploy deployment configuration since the native configurations (like `CodeDeployDefault.ECSLinear10PercentEvery1Minutes` or `CodeDeployDefault.ECSLinear10PercentEvery3Minutes`) do not match the required 10%10\% every 55 minutes cadence.
Custom configurations allow custom linear shifting percentages and intervals.
3
Configure target groups and the baking period monitoring requirements.
Provide two target groups to the deployment group (one active production target group and one replacement target group). Set the 'termination wait time' for the original task set to 1515 minutes.
Two target groups are mandatory for CodeDeploy ECS deployments to route traffic. The termination wait time acts as the post-deployment baking/monitoring window during which the old task set remains active and ready for rapid rollback.
4
Configure automatic rollback behaviors.
Associate the CloudWatch alarms with the CodeDeploy deployment group and configure automatic rollback on alarm execution.
If an alarm transitions to the ALARM state during traffic routing or the 1515-minute post-traffic shift window, CodeDeploy immediately shifts traffic back to the old target group and terminates the replacement task set.

Key Concept

AWS CloudFormation blue/green deployments for Amazon ECS using AWS CodeDeploy target groups and lifecycle/termination wait times.
Rate this question