Decoupled Bedrock Model Cascade with SQS and Fargate
A media company is building an AI-powered content moderation system by using Amazon Bedrock. The system first classifies text by using a small, low-latency model. Then the system escalates requests that have a confidence score below 0.65 to a larger, more expensive model. The system must respond in near real time for high-confidence results. The system must process low-confidence requests asynchronously. The system must scale to meet sudden spikes in demand. The company wants to optimize costs for the system by invoking the larger model only when required. The company wants to use decoupled components to achieve high resiliency for the system. Which solution will meet these requirements?
Community Insight
The question tests selection of an event-driven, decoupled architecture that invokes the expensive model only when confidence is low; the common trap is choosing synchronous escalation paths that never allow asynchronous processing of low-confidence requests.
This AIP-C01 scenario tests how to build a cost-optimized, resilient content moderation pipeline on Amazon Bedrock by combining a fast small model with an on-demand escalation to a larger model. The page establishes that an Amazon SQS front queue processed by AWS Fargate, plus a second SQS queue for asynchronous large-model escalation, satisfies every stated requirement for decoupling, near-real-time response, spike scaling, and pay-for-what-you-use cost control.
The most common wrong answer is A, because synchronously calling the larger model inside the request path violates the requirement that low-confidence requests be processed asynchronously, and provisioned concurrency alone does not provide decoupled, resiliency-focused components. Some learners also favor B, which doubles cost by invoking both models on every request—the opposite of the stated cost-optimization goal.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option C routes incoming requests into an Amazon SQS queue, decoupling producers from processing so sudden demand spikes are absorbed by the queue buffer rather than overwhelming the models. AWS Fargate scales the consumer tasks automatically without server management, invoking the small low-latency Bedrock model first to keep high-confidence results fast and cheap. When the confidence score falls below 0.65, the request is placed into a second SQS queue, which allows the larger, more expensive model to run asynchronously and only when required, directly satisfying the cost-optimization requirement. This two-queue design gives high resiliency through decoupled components, retries, and independent scaling of each stage.Why the Other Options Are Wrong
Option A escalates synchronously to the larger model in the request path, which fails the explicit requirement that low-confidence requests be processed asynchronously and creates latency and availability coupling between the two models. Option B runs both the small and large model in parallel branches for every request, discarding all cost savings because the expensive model is invoked 100% of the time. Option D places models on Amazon EC2 instances with custom phrase-length and keyword routing, which reintroduces undifferentiated instance management, lacks managed decoupling, and replaces Bedrock's confidence-based escalation with a brittle hand-written heuristic instead of the actual score threshold.Community Comment Notes
A single community comment identified the same verdict, selecting C because "Send requests to an Amazon SQS queue. Use AWS Fargate to process messages." The comment's reasoning aligns with the requirement set—decoupled queues for asynchronous large-model escalation—though no further discussion was provided to corroborate or challenge the choice.Official Reference
Exam Strategy
On AIP-C01 architecture questions, look for keywords like decoupled, asynchronous, and invoke only when required—these point to SQS-based pipelines rather than synchronous API calls or always-on parallel invocations. Match each stated requirement (latency, async processing, spike scaling, cost, resiliency) to the option and eliminate any design that violates even one.
Frequently Asked Questions
Why is synchronously calling the larger model (Option A) wrong here?
The requirements state low-confidence requests must be processed asynchronously. A synchronous escalation blocks the request path, adding latency and coupling availability of the expensive model to every response.
Why is the Step Functions parallel-branch design (Option B) a poor choice?
Invoking both models for every request defeats the stated cost-optimization goal, since the larger, more expensive Bedrock model would run 100% of the time regardless of the small model's confidence score.
Related Analysis
Practice All AIP-C01 Questions
Access 110 questions with complete answers and detailed explanations.
View Full AIP-C01 Practice Test →