What's changed: Initial: 5 sections for Domain 1 (FM integration, data management, compliance)
1.1Requirements Analysis and Foundation Model Selection
Learn to design GenAI solutions and select/configure the right foundation model (FM). Cover model evaluation in Amazon Bedrock, resilience via Cross-Region Inference, provisioned throughput, fine-tuning/LoRA, and the Well-Architected Framework (Generative AI Lens).
Professional GenAI development starts with deciding which foundation model, in what architecture, and how to run it in production. Model development/training is out of scope; the exam tests how you integrate existing FMs.
1.1.1Model selection and configuration
- Amazon Bedrock: managed access to FMs from many providers (Anthropic Claude, Amazon Nova/Titan, Meta Llama, etc.) via a single API—the basis for switching models without code changes.
- Model selection: choose the best FM via benchmarks, capability analysis, and limitation evaluation (context length, modalities, latency, cost). Pick per use case, not one model for everything.
- Dynamic model selection: build an abstraction with Lambda + API Gateway + AWS AppConfig to switch models/providers without redeploying.
- FM customization: adapt with fine-tuning or LoRA (low-rank adaptation), versioning and rolling back via SageMaker Model Registry.
Common on AIP-C01: single API to many FMs = Bedrock, switch models without code change = dynamic selection via AppConfig, resilient inference for Region failure/capacity = Cross-Region Inference, guaranteed steady throughput = provisioned throughput, lightweight domain adaptation = LoRA.
Resilient designs combine Amazon Bedrock Cross-Region Inference (an inference profile auto-routes across Regions to absorb capacity shortfalls/Region failures), a circuit breaker with Step Functions, and graceful degradation to a fallback model. For strict throughput, choose provisioned throughput (reserve capacity per model); for bursty traffic, stay on-demand and handle 429s with exponential backoff. Review designs with the Generative AI Lens of the AWS Well-Architected Framework. Validate feasibility, performance, and business value with a PoC on Amazon Bedrock before production. For customization, escalate from the cheapest option: prompt → RAG → fine-tuning/LoRA.
| Need | Choose | Why |
|---|---|---|
| Steady high throughput | Provisioned throughput | Reserve capacity for latency/availability |
| Resilient to Region failure/capacity | Cross-Region Inference | Auto-routes across Regions |
| Swap models without redeploy | AppConfig + Lambda abstraction | Switch model ID via config |
| Domain specialization | Fine-tuning/LoRA | When prompt/RAG is insufficient |
Scenario: a chat app gets intermittent 429s due to model capacity shortfalls in one Region. → Use Bedrock Cross-Region Inference (an inference profile) to auto-route across Regions, with clients retrying via exponential backoff. Add provisioned throughput for peak windows that need guaranteed capacity.
Trap: “to improve accuracy, fine-tune first” is wrong—escalate by cost: prompt optimization → RAG → fine-tuning/LoRA. Also “Cross-Region Inference is a DR feature that continuously replicates data” is wrong—it routes inference requests, not data replication.
1.1.2Section summary
- Single API = Bedrock / select by benchmarks per use case / swap via AppConfig abstraction
- Resilience = Cross-Region Inference + circuit breaker / adapt in order prompt → RAG → LoRA
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to switch the foundation model/provider used by a production chat app without redeploying. Best design?
Q2. Intermittent throttling occurs due to model capacity shortfalls in one Region. You want higher availability with minimal code change. What?
Q3. You want to lightly adapt a model to internal document vocabulary, but full fine-tuning is costly. Which escalation order minimizes cost?