2.4. Reflection Checkpoint

Key Takeaways

• Model selection is an empirical engineering decision driven by task benchmarks, context window requirements, and cost per query — not model size or recency. Use Bedrock Model Evaluations for systematic head-to-head comparison.
• Three deployment modes serve different needs: on-demand for variable traffic, provisioned throughput for sustained high-volume SLA-bound workloads, SageMaker endpoints for custom/fine-tuned models. Break-even on provisioned requires ~60–70% sustained utilization.
• Dynamic model selection via AWS AppConfig decouples model identity from application code — enabling zero-deployment model updates and A/B tests.
• Resilient FM systems need circuit breakers, cross-region fallback, and graceful degradation — the model API is an unreliable external dependency.
• Data quality must be validated before FM consumption. Glue Data Quality enforces rules at scale; SageMaker Data Wrangler transforms; Lambda performs FM-specific checks (token count, encoding, PII).
• Images cannot be passed to Bedrock via S3 URL — they must be base64-encoded in the request body by your application layer.

Connecting Forward

Phase 3 tackles the two highest-tested topics in Domain 1: vector stores and RAG retrieval mechanics (sections 3.1–3.2), and prompt engineering with governance (section 3.3). These sections contain the concepts most frequently tested in multi-constraint exam scenarios.

Self-Check Questions

• A company is choosing between Bedrock on-demand and provisioned throughput for a customer support bot expecting 200 requests/hour during business hours and near-zero overnight. Walk through the calculation and recommendation.
• You receive a bug report: your multimodal FM pipeline processes a batch of 500 product images and returns "Unable to process image" errors for 47 of them, but all files exist in S3 and are valid JPEGs. What are the two most likely architectural causes?