An enterprise is designing a deployment pipeline for a high-throughput microservice hosted… — AWS Certified Solutions Architect - Professional

An enterprise is designing a deployment pipeline for a high-throughput microservice hosted on Amazon ECS with AWS Fargate, positioned behind an Application Load Balancer (ALB). Due to strict corporate service limits, the AWS account has a highly constrained Fargate vCPU quota that prevents the concurrent execution of two full fleets ( $200\%$ capacity) of the microservice.

The deployment strategy for new versions must satisfy the following criteria:
1. Route exactly $10\%$ of production traffic to the new version for an initial $15\text{-minute}$ evaluation period.
2. If health metrics remain stable, increase traffic to the new version by $30\%$ every $10\text{ minutes}$ until it reaches $100\%$ .
3. Automatically roll back traffic to $100\%$ on the old version immediately if any Amazon CloudWatch alarms (such as HTTP $5\text{XX}$ error rates) are triggered.
4. Keep the total running Fargate task count across both versions aligned with active traffic demands to avoid exceeding the vCPU quota.

Which combination of actions should the solutions architect implement to meet these requirements? (Select TWO.)

Register the current version and the new version of the microservice as two separate Amazon ECS services, each associated with its own Application Load Balancer (ALB) target group. Use an AWS Step Functions state machine to programmatically update the weights of the target groups in the ALB listener rule according to the deployment schedule, monitor the CloudWatch alarms, and immediately revert the weight of the current version's target group to $100\%$ if an alarm is triggered.Cevap
Enable Application Auto Scaling for both ECS services using target tracking policies based on the `ALBRequestCountPerTarget` metric. This dynamically adjusts the task count of each service in proportion to the shifting traffic weights, preventing the combined task count from exceeding the Fargate vCPU quota.Cevap
C
Configure the ECS service to use the AWS CodeDeploy blue/green deployment controller. Create a custom deployment configuration with the Canary type to route $10\%$ of traffic for $15\text{ minutes}$ , followed by a Linear type to route $30\%$ every $10\text{ minutes}$ , and link the CloudWatch alarms to the deployment group for automatic rollback.
D
Configure the ECS service to use the ECS rolling update (`ECS`) deployment controller. Set the `maximumPercent` to $110\%$ and the `minimumHealthyPercent` to $90\%$ . Configure an AWS Lambda function triggered by ECS deployment events to adjust the ALB listener rule's target group weights during the update.
E
Set up Route 53 weighted routing policies targeting two separate ALBs, with each ALB routing to one of the ECS services. Implement an AWS Lambda function to adjust the Route 53 record weights according to the schedule, and configure CloudWatch alarms to trigger a weight rollback.

Cevap

Implement two separate Amazon ECS services registered with separate ALB target groups, orchestrate the weighted routing via an AWS Step Functions state machine, and enable Application Auto Scaling based on target tracking of request counts on both services.

The correct strategy involves registering the old and new versions as two separate ECS services and using ALB weighted target groups to perform the traffic shifting. An AWS Step Functions state machine handles the custom progression (

10\%

for

15\text{ minutes}

, then

+30\%

every

10\text{ minutes}

) and handles immediate rollbacks by reverting ALB weights if a CloudWatch alarm triggers. To satisfy the vCPU quota constraint, enabling Application Auto Scaling with the `ALBRequestCountPerTarget` target tracking metric ensures the task counts dynamically scale in proportion to the traffic weights, keeping the aggregate capacity within bounds.

Adım Adım Çözüm

Analyze capacity constraints.

Standard AWS CodeDeploy blue/green deployments require provisioning a full

100\%

duplicate task set (resulting in

200\%

concurrency capacity) before shifting traffic, which is blocked by the tight Fargate vCPU service quota.

Understanding resource constraints is critical to ruling out standard AWS CodeDeploy blue/green mechanisms.

Evaluate traffic shifting options.

The requirements demand a custom multi-phase traffic-shifting pattern (

10\%

canary, followed by

+30\%

linear steps) and instant rollback. Application Load Balancer listener rules support weighted target groups, which can route a precise percentage of traffic to separate target groups.

This establishes that ALB-level routing is needed to satisfy the custom progression and rapid rollback criteria.

Design orchestration and rollback logic.

An AWS Step Functions state machine can update the ALB listener rule target group weights over time, pausing for the required intervals (

15\text{ minutes}

and then

10\text{ minutes}

). It can simultaneously monitor CloudWatch alarms during execution and immediately update the weights back to

100\%

for the active version if an alarm is triggered.

An orchestrator is required to manage the custom deployment schedule and execute instantaneous rollback logic.

Optimize scaling to prevent quota exhaustion.

Configuring Application Auto Scaling using target tracking based on the `ALBRequestCountPerTarget` metric ensures that task counts for each service scale up and down dynamically in direct response to the volume of traffic routed to their respective target groups.

This prevents running excess idle tasks, keeping the combined task count aligned with current traffic load and staying within the vCPU quota.

Anahtar Kavram

Custom ECS deployment strategies under tight resource quotas using ALB weighted target groups, Step Functions orchestration, and request-based auto-scaling.

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru