Study guide
10.4 Intelligent Prompt Routing & Application Eligibility
AWS Certified Generative AI Developer - Professional AIP-C01
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Foundation Model Fundamentals
1.1 AIP-C01 Exam Structure, Logistics & Passing Strategy 1.2 AIP-C01 Scoring & Professional Decision Strategy 1.3 Foundation Model Landscape & Model Selection on Amazon Bedrock 1.4 Model Abstraction, Controlled Switching & Resilience 1.5 Customization Spectrum: Prompting vs RAG vs Fine-Tuning vs Continued Pre-training 1.6 Custom Model Deployment & Lifecycle Management
2 Chapter 2: Bedrock Knowledge Bases & RAG Architectures
2.1 Managed RAG Architecture with Bedrock Knowledge Bases 2.2 Knowledge Source Integration, Synchronization & Freshness 2.3 Data Ingestion, Parsing & Chunking Strategies 2.4 Embedding Models & Vector Representations 2.5 Vector Index Scale, Migration & Retrieval Evaluation 2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores 2.7 Vector Store Security, Multi-Tenancy & Connectivity
3 Chapter 3: Advanced Vector Search, Indexing & Data Compliance
3.1 Hybrid Search, Metadata Filtering & Semantic Reranking 3.2 Metadata Filtering, Reranking & Query Transformation 3.3 Fine-Tuning & Continued Pre-Training Data Pipeline Engineering 3.4 Data Validation, Multimodal Processing & Model Formatting 3.5 Data Privacy, Data Residency & Compliance Governance 3.6 Privacy Preservation, Source Lineage & Audit Evidence
4 Chapter 4: Prompt Engineering & Bedrock Runtime APIs
4.1 Advanced Prompt Engineering Techniques & Inference Parameters 4.2 Inference Parameters, Prompt Governance & Regression 4.3 Converse API vs InvokeModel API & Message Formatting 4.4 Tool Calling, FM API Resilience & Model Routing 4.5 Streaming Architectures & Asynchronous Event Processing 4.6 Resilient Streaming, Deployment & Asynchronous Processing
5 Chapter 5: Amazon Bedrock Agents & Tool Integration
5.1 Agentic Architecture, ReAct Reasoning Loops & Orchestration 5.2 Agent Frameworks, MCP & Lifecycle Management 5.3 Action Groups, OpenAPI Schemas & AWS Lambda Integration 5.4 Agent Memory, Session State & Multi-Agent Collaboration Patterns 5.5 Persistent State & Multi-Agent Coordination 5.6 Advanced Agent Prompt Templates & Flow Customization 5.7 Agent Safeguards, Tool Reliability & Cost Control
6 Chapter 6: Workflow Orchestration & Application Integration
6.1 Amazon Bedrock Prompt Flows & Visual Orchestration 6.2 Step Functions Orchestration & Human-in-the-Loop Workflows 6.3 Enterprise Integration: API Gateway, AppSync, and EventBridge 6.4 Hybrid Integration, GenAI Gateways & CI/CD Tooling
7 Chapter 7: AI Safety & Guardrails for Amazon Bedrock
7.1 Guardrails Architecture, Denied Topics & Content Filters 7.2 Content Safety, Defense in Depth & Threat Detection 7.3 Sensitive Information Filters & PII Redaction/Masking 7.4 Contextual Grounding Checks & Hallucination Prevention
8 Chapter 8: Security, Access Control & Network Architecture
8.1 IAM Least Privilege & Resource Policies for Bedrock 8.2 PrivateLink VPC Endpoints & Network Isolation 8.3 Encryption with AWS KMS & Cross-Account Access Patterns
9 Chapter 9: Governance, Auditing & Operational Logging
9.1 SageMaker Model Cards & AI Governance Frameworks 9.2 Lineage, Fairness, Transparency & Continuous Governance 9.3 Invocation Logging, CloudTrail Auditing & Observability 9.4 Responsible AI, Bias Mitigation & Red Teaming Methodologies
10 Chapter 10: Performance, Throughput & Cost Optimization
10.1 On-Demand vs Provisioned Throughput & Capacity Planning 10.2 Capacity Measurement, Scaling Patterns & Resilience 10.3 Batch Inference & Bedrock Intelligent Prompt Routing 10.4 Intelligent Prompt Routing & Application Eligibility 10.5 Prompt Caching, Token Optimization & Latency Reduction
11 Chapter 11: Testing, Evaluation & Troubleshooting GenAI Solutions
11.1 Amazon Bedrock Model Evaluation (Automatic & Human Workflows) 11.2 Human, RAG & Continuous Evaluation 11.3 Evaluation Metrics & RAG Quality Benchmarking (Ragas, ROUGE, BLEU) 11.4 RAG and Agent Performance Evaluation 11.5 CloudWatch Metrics, Throttling & Operational Observability 11.6 Quota Diagnosis, Retry Control & Operational Troubleshooting 11.7 Troubleshooting Common GenAI Failure Modes & Agent Traces 11.8 Prompt Maintenance, Content Handling & Deployment Validation
10.4 Intelligent Prompt Routing & Application Eligibility
Key Takeaways Explain This Topic AI
Configured routers use exactly two supported same-family models, a fallback, and quality-difference criteria.
Prompt routing does not automatically incorporate private application metrics or policy constraints.
Enforce tenant, modality, residency, and tool eligibility before a managed routing decision.
Last updated: September 2026
- 10.4 Intelligent Prompt Routing & Application Eligibility
- Intelligent prompt routing
An Amazon Bedrock prompt router exposes a single inference target and predicts which configured model should handle an incoming prompt. Current documentation describes default and configured routers, a fallback model, and routing criteria based on predicted response-quality difference. Configured routers select exactly two supported models within the same model family.
The router can reduce cost when a lower-cost model can answer many prompts while the stronger model handles prompts whose predicted quality difference warrants escalation. The response identifies the selected model, enabling cost and quality analysis. It does not use the application's private acceptance metrics automatically, and AWS notes limitations such as language and use-case sensitivity.
Use a prompt router only after evaluation. Build a dataset containing easy, hard, domain-specific, unsafe, tool-using, and long-context requests. Compare the router with always-small and always-large baselines. Measure task success, safety, latency, and cost. Tune the fallback and quality-difference criterion, then canary the router target like any other model change.
When to route in application code
Application routing remains appropriate when the rule depends on information the managed router does not know: tenant entitlement, data residency, modality, required tool, legal risk, or a model feature. A deterministic image-versus-text branch should not be delegated to a quality predictor. Likewise, a request that must remain in one Region needs a policy check before model selection.
Static rules can be combined with a router: first enforce authorization, modality, and residency, then use a router among eligible models. Keep a circuit breaker and fallback plan for router or model errors. Do not retry a failed prompt blindly against a less capable model if the result could violate the business contract.
Common exam distinctions
Choose batch inference when latency is not interactive and the workload is large and file-oriented.
Choose intelligent routing when two eligible models in a supported family offer a quality-versus-cost tradeoff per prompt.
Choose explicit application routing when policy, modality, tools, or custom measurements determine eligibility.
Choose Provisioned Throughput when measured sustained demand and supported model economics justify reserved model units.
Choose cross-Region inference when supported on-demand traffic may use the profile's listed Regions.
The strongest design may combine them: a router serves interactive requests, a batch job processes offline backlogs, and an evaluation pipeline compares selected-model outcomes over time. Keep their IAM roles, metrics, budgets, and failure handling separately observable.
Router evaluation scenario
Build a dataset with routine FAQs, extraction, long-context analysis, coding, ambiguous questions, unsafe requests, and domain-specific edge cases. Compare three strategies: always use the lower-cost model, always use the fallback model, and use the router. Record which model was selected, response quality, policy compliance, latency, and cost for every slice.
Tune the response-quality-difference criterion only on a development set, then evaluate on a holdout. If the router sends specialized domain prompts to the cheaper model and quality falls, application-side classification or a separate router may be necessary. Current documentation notes that managed routing cannot adapt automatically to private application performance data.
The response's selected-model information should feed dashboards and budgets. Alert on a sudden routing-distribution shift because it can indicate traffic drift, configuration change, or new model behavior. Reevaluate when router models change or AWS adds a new supported candidate.
Keep a fallback for router-target failure, but enforce eligibility again. A global fallback or cross-Region model may be disallowed for one tenant even when technically available.
Safety and routing
Apply input safety and authorization regardless of the selected model. Confirm that both candidates support the required Guardrail and output controls. If one candidate lacks a mandatory feature, it should not be in the eligible router pair.
Routing criteria express a quality tradeoff, not a hard legal policy. Put nonnegotiable controls before the router and validate outputs after it. Test adversarial prompts against both routes because an attacker can shape prompt complexity and may influence which model is selected.
Budget forecasts should include the observed routing mix and its uncertainty. A traffic shift toward difficult prompts can move most calls to the higher-cost fallback without any request-volume increase.
Record the router ARN and configuration version with each release. If a default router changes underneath an application contract, rerun acceptance tests before expanding traffic and preserve a configuration-based rollback path.