Automating Canary Deployments for Amazon Bedrock Models

AIP-C01 By islever Editorial Last updated

Implement model deployment strategies. Implement monitoring systems for GenAI applications.

Short answer

A Configuring an AWS Step Functions workflow to automate gradual traffic shifting and CloudWatch metric evaluation for Amazon Bedrock models meets the zero-touch rollback requirement.

Question

A company is designing a canary deployment strategy for a payment processing API. The system must support automated gradual traffic shifting between multiple Amazon Bedrock models based on real-time inference metrics, historical traffic patterns, and service health. The solution must be able to gradually increase traffic to new model versions. The system must increase traffic if metrics remain healthy and decrease traffic if the performance degrades below acceptable thresholds.
The company needs to comprehensively monitor inference latency and error rates during the deployment phase. The company must also be able to halt deployments and revert to a previous model version without any manual intervention.
Which solution will meet these requirements?
  1. Use Amazon Bedrock with provisioned throughput to host the versions of the model. Configure an Amazon EventBridge rule to invoke an AWS Step Functions workflow when a new model version is released. Configure the workflow to shift traffic in stages, wait for a specified time period, and invoke an AWS Lambda function to check Amazon CloudWatch performance metrics. Configure the workflow to increase traffic if the metrics meet thresholds and to trigger a traffic rollback if performance metrics fall below thresholds. Correct Answer
  2. Use AWS Lambda functions to invoke various Amazon Bedrock model versions. Use an Amazon API Gateway HTTP API with stage variables and weighted routing to shift traffic gradually to new model versions. Use Amazon CloudWatch to monitor performance metrics. Use external logic to adjust traffic between model versions and to roll back if performance falls below thresholds.
  3. Use Amazon SageMaker AI endpoint variants to represent multiple Amazon Bedrock model versions. Use variant weights to shift traffic. Use Amazon CloudWatch to monitor performance metrics. Use SageMaker Model Monitor to trigger AWS Lambda functions to roll back a model deployment if performance drops below a specified threshold. Configure an Amazon EventBridge rule to roll back model deployments if an anomaly is detected.
  4. Use Amazon OpenSearch Service to track inference logs. Configure OpenSearch Service to invoke an AWS Systems Manager Automation runbook to update Amazon Bedrock model endpoints to shift traffic based on the inference logs.

Key Takeaways

The question tests the ability to design an automated canary deployment for Bedrock models, trapping users into selecting either SageMaker native routing (invalid for Bedrock) or vague external logic that fails the automation requirement.

Amazon Bedrock lacks native weighted routing for canary deployments, requiring an automated orchestration layer like AWS Step Functions to shift traffic and evaluate CloudWatch metrics for zero-touch rollback.

Common mistake: Choosing Option C by assuming SageMaker endpoint variants can proxy Amazon Bedrock models, or choosing Option B because its 'external logic' fails the strict requirement for no manual intervention.

Expert Analysis

Bedrock Traffic Shifting Limitations: Amazon Bedrock does not natively support weighted routing or traffic splitting between different model ARNs or provisioned throughput allocations at the service level. Unlike Amazon SageMaker endpoints, which have native variant weights, Bedrock requires an external orchestration mechanism to route traffic between model versions.

Automated Orchestration vs. External Logic: Option A correctly identifies that an orchestration workflow (AWS Step Functions) is required to manage the canary process. By using EventBridge to trigger Step Functions, and Lambda to evaluate CloudWatch metrics against thresholds, Option A provides a fully automated, zero-touch rollback mechanism. Option B, while correctly identifying API Gateway's native weighted routing for the API layer, relies on "external logic" to adjust traffic and roll back. This vague phrasing fails the strict requirement of reverting "without any manual intervention" when compared to A's explicit automated state machine.

Invalid Architectures: Option C suggests using Amazon SageMaker AI endpoint variants to represent Bedrock model versions. SageMaker endpoints cannot host or proxy Bedrock foundation models; they are distinct services with separate hosting environments. Option D suggests updating Bedrock model endpoints to shift traffic, which is impossible as Bedrock endpoints do not expose traffic shifting parameters.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a question requires "no manual intervention" or "fully automated" rollback for canary deployments, immediately eliminate options that use vague terms like "external logic" or "custom scripts." Look for the option that explicitly defines an automated orchestration service like AWS Step Functions combined with CloudWatch alarms and Lambda for decision-making.

Community Votes

A
72%
B
14%
C
14%

72% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 7 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 7

  1. AM_aws 👍 3 Answered A
    https://docs.aws.amazon.com/decision-guides/latest/bedrock-or-sagemaker/bedrock-or-sagemaker.html - why C is not correct
  2. GiorgioGss 👍 2 Answered A
    B is to complex and only with A you can "gradually increase traffic".
  3. ArunRav 👍 2 Answered A
    Step function will help stepwise shifting.
  4. vedratna 👍 1 Answered B
    Option A is incorrect: Bedrock Provisioned Throughput does not have a "weighted routing" parameter. There is no configuration setting on a Bedrock Provisioned Model where you can say "Send 90% of requests to Model Version 1 and 10% to Model Version 2." Option B recognizes that because Amazon Bedrock cannot natively split traffic between different version ARNs, the traffic splitting must be offloaded to the API Layer (Amazon API Gateway). • API Gateway HTTP APIs natively feature a parameter called Route Weights / Weighted Routing. • Step Functions or external operational logic can easily call the API Gateway API to say: "Change the route weight of Stage Variable $v1 to 90% and Stage Variable $v2 to 10%." • API Gateway then distributes the live incoming customer calls accordingly, passing them down to the respective AWS Lambda functions, which then invoke the correct underlying Bedrock models.
  5. Chibuzo1 👍 1 Answered A
    Option A is the only solution that combines Bedrock-native compatibility, fully automated decision logic, real-time metric evaluation, and zero-touch rollback in a cohesive, serverless architecture.
Show 2 more comments
  1. 67bdb19 👍 1 Answered C
    Leaning toward C, but I'd be interested to hear arguments for the others.
  2. de1612d 👍 1 Answered A
    Answer is A

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How Can AgentCore Query Cross-Account DynamoDB While Preserving User Identity?

S-grade

Which API Gateway setup streams Bedrock responses with least operational overhead?

S-grade

Resilient Retry and Streaming Strategies for Amazon Bedrock

S-grade

Bedrock Prompt Management & Guardrails Detection

S-grade

Practice All AIP-C01 Questions

Access 110 questions with complete answers and detailed explanations.

View Full AIP-C01 Practice Test →

← Back to AIP-C01 Study Guide