Study guide
10.1 On-Demand vs Provisioned Throughput & Capacity Planning
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.1 On-Demand vs Provisioned Throughput & Capacity Planning
Key Takeaways Explain This Topic AI
Supported custom Bedrock models may use on-demand custom model deployments instead of mandatory Provisioned Throughput.
Size model units against both input and output throughput; the larger requirement is binding.
A quota is an upper bound, not a guarantee that every on-demand request succeeds during high demand.
Last updated: September 2026
10.1 On-Demand vs Provisioned Throughput & Capacity Planning
Amazon Bedrock offers multiple inference paths. On-demand inference charges for use and is governed by model- and Region-specific capacity and quotas. Provisioned Throughput purchases model units for a fixed hourly cost and a selected commitment term. Supported custom models may also be deployed for on-demand inference through a custom model deployment. The available choice depends on the exact model, customization type, Region, endpoint, and current support table.
Compare capacity options without obsolete absolutes
Option Cost behavior Appropriate workload Important caveat
On-demand Usage-based model pricing Variable, bursty, or early-stage traffic A quota is an upper bound, not a promise that every request succeeds during high demand
Cross-Region inference On-demand requests routed within the profile's supported Regions Traffic that can use the listed Regions and benefits from a larger capacity pool Validate residency, IAM, logging, and model support
Provisioned Throughput Hourly model-unit charge while allocated Sustained load needing reserved capacity and consistent performance Model-unit capacity and purchase options are model-specific
Custom model deployment Usage-based on-demand inference for supported custom models Customized models with variable traffic Not every custom model or Region supports this path
Batch inference Asynchronous job pricing and quotas Large offline workloads without interactive latency requirements Input format, minimum job size, and model support apply
Provisioned Throughput documentation describes no-commitment, one-month, and six-month choices for supported purchases. Billing continues until a no-commitment allocation is deleted or until the relevant commitment lifecycle permits termination. Never insert a made-up discount percentage into an architecture decision; use the current pricing page and the quote for the selected model.
A model unit represents input- and output-token processing capacity over time for a particular model. AWS advises customers to obtain current model-unit details from the relevant documentation or account team. One model's unit numbers cannot be reused for another model. Provisioned capacity reduces exposure to shared on-demand capacity variation, but applications still need timeouts, retries, monitoring, and admission control.
Eligibility before economics
Create an eligibility matrix before comparing prices. A path is eligible only if the exact model supports the required Region, API, modality, Guardrail or tool behavior, streaming mode, and deployment option. An inexpensive batch price is irrelevant to a live chat request. A cross-Region profile is ineligible when policy requires one Region. A custom on-demand deployment is ineligible when the selected custom model does not support it.
Then estimate economics with measured distributions, not a single average. Include peak and quiet hours, input and output tokens, retries, cache writes and reads, failed calls, evaluation traffic, and idle provisioned time. Model a low, expected, and high case. Sensitivity analysis often shows whether token growth or utilization is the dominant risk.
Provisioned Throughput has a fixed hourly component and model-specific units. It can fit a sustained known workload, but buying for a one-hour peak may create large idle cost. On-demand fits variable traffic but requires queue and retry behavior. Cross-Region inference can improve available capacity for eligible workloads. Batch moves offline work out of the interactive path. The decision is a portfolio, not necessarily one mode for the whole application.
Record the evidence and review it after launch. A workload that begins as a low-volume prototype can later justify reserved capacity, while a seasonal product may move the other direction.
Endpoint and quota inventory
Before testing, record the endpoint surface, model or inference-profile ID, Region, service tier, quota names, and requested limits. Token accounting can differ across surfaces, and some models have output-token burndown factors. The application should report actual input, output, cache, and retry usage from responses where available rather than estimating all demand from character counts.
Separate business traffic, evaluation, load testing, and background processing with tags, accounts, queues, or schedules appropriate to the organization. A benchmark that consumes the same on-demand quota as production can create the outage it is intended to prevent. Conversely, testing an isolated path may not reveal the real production quota.
Review supported-model tables immediately before purchase or launch. Bedrock evolves quickly; a valid option for one model version can be unavailable for another.
Finally, verify regional availability and account quotas in the environment that will run the workload. A feature visible in documentation or another account is not proof that the intended account can purchase or invoke it immediately.