Skip to content

Skill 4.2.7: Evaluate cost implications of using FMs for inference in production

Question 1 - FM Cost Evaluation for Multi-Model Workload

A financial services firm is planning to deploy a generative AI assistant on Amazon Bedrock to support customer service operations. The assistant will handle two distinct task types: simple account balance inquiries (high volume, low complexity) and complex fraud dispute explanations (low volume, high complexity requiring advanced reasoning). The finance team requires the solution to be as cost-effective as possible while maintaining quality for each task type. The platform team emphasizes that the architecture must avoid unnecessary operational complexity.

Which approach should the ML engineer recommend to optimize Foundation Model inference costs? (Select ONE)

  • A) Deploy a single large frontier model (e.g., Claude Opus) for all requests to ensure consistent high-quality responses across both task types.
  • B) Implement model routing with a smaller, cost-efficient model for balance inquiries and a larger model for complex fraud disputes, using Amazon Bedrock Converse API with explicit model selection per task.
  • C) Use SageMaker Multi-Model Endpoints with both models loaded on shared compute to achieve dynamic model loading and cost savings.
  • D) Process all requests through a single mid-sized model and implement response length capping to control costs.
  • E) Enable prompt caching on a single large model to reduce repetitive token processing for balance inquiries.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: This approach directly applies the principle of "right-sizing the model" for token-based billing. Simple, high-volume tasks are routed to a smaller model with lower per-token costs, while complex tasks requiring advanced reasoning use a more capable model. This optimizes cost per request without sacrificing quality where it matters.

Distractor Analysis

  • A is Incorrect: Using a single large frontier model for all requests maximizes per-token costs for simple, high-volume tasks. This is the most expensive option and fails to optimize based on task complexity.
  • C is Incorrect: SageMaker Multi-Model Endpoints are a traditional ML cost optimization pattern for hosted models, not applicable to Amazon Bedrock's serverless token-based billing. Bedrock does not support multi-model endpoints with dynamic loading; each model is invoked via API.
  • D is Incorrect: While response length capping helps control output tokens, it does not address the core issue of using an oversized model for simple tasks. The input token costs for complex model processing would still be unnecessarily high for balance inquiries.
  • E is Incorrect: Prompt caching reduces repetitive input token costs but requires a stable prefix. Different task types (balance inquiry vs. fraud dispute) likely have different system prompts, limiting cache effectiveness. This approach also still uses a large model for simple tasks, missing the larger optimization opportunity.

Key Takeaway: In token-based billing models like Amazon Bedrock, model selection per task complexity is the equivalent of instance right-sizing in traditional ML—match the model capability to the task requirement to avoid paying for unnecessary capability.

Question 2 - Provisioned Throughput vs. On-Demand Decision

A healthcare technology company is deploying a clinical documentation summarization service on Amazon Bedrock using Claude Sonnet. The service is expected to process medical dictation summaries during two 4-hour windows per day (morning and evening clinic shifts). Outside these windows, traffic drops to near zero. The workload is highly predictable during peak shifts, and the team wants to minimize costs while ensuring low latency for clinicians. The solution must not introduce significant architectural changes to the existing serverless application.

Which purchasing mode should the ML engineer configure for this inference workload? (Select ONE)

  • A) Purchase SageMaker AI Savings Plans for the expected SageMaker instance usage.
  • B) Use On-Demand inference for all traffic to maintain maximum flexibility.
  • C) Purchase Provisioned Throughput for the baseline predictable traffic and use On-Demand for overflow.
  • D) Use Batch Inference exclusively to take advantage of discounted asynchronous processing rates.
  • E) Implement a Multi-Model Endpoint on SageMaker to consolidate all clinical summarization models.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: Provisioned Throughput on Amazon Bedrock allows the team to reserve dedicated model units for predictable, steady-state traffic at a fixed hourly rate (typically 50% or more discount vs. On-Demand), while On-Demand handles any overflow or unpredictable spikes. This matches the predictable peak windows while maintaining latency guarantees.

Distractor Analysis

  • A is Incorrect: SageMaker AI Savings Plans apply exclusively to Amazon SageMaker instance usage (training, hosting, batch transform, notebooks), not to Amazon Bedrock token-based inference. This is a critical cost management distinction.
  • B is Incorrect: While On-Demand provides flexibility, it bills at the highest per-token rate. For a predictable, steady workload, this misses out on significant Provisioned Throughput discounts.
  • D is Incorrect: Batch Inference is designed for asynchronous, large-scale workloads where responses are not needed interactively. Clinical dictation summaries require real-time interactive responses for clinicians, making batch processing architecturally unsuitable.
  • E is Incorrect: Multi-Model Endpoints are a SageMaker inference feature for consolidating hosted models. Amazon Bedrock provides a managed serverless API; the workload runs on Bedrock, not SageMaker.

Key Takeaway: Provisioned Throughput is the commitment-based discount mechanism for predictable FM workloads on Amazon Bedrock, just as Savings Plans are for SageMaker compute—each covers different billing units.

Question 3 - Agent Cost Amplification Analysis

An e-commerce platform has deployed a conversational shopping assistant using Amazon Bedrock Agents with Action Groups for inventory lookup, order tracking, and returns processing. The finance team notices that while user traffic has remained stable over the past month, the Bedrock bill has increased by 40%. The ML engineer suspects hidden cost amplification through agent orchestration overhead. The team wants a tool that provides per-invocation visibility into the agent's resource consumption pattern. The solution must integrate natively with the existing Bedrock agent setup.

Which AWS capability should the engineer enable to diagnose this cost pattern? (Select ONE)

  • A) AWS CloudTrail event history for API call accounting
  • B) Amazon Bedrock AgentCore Observability
  • C) AWS X-Ray distributed tracing with custom subsegments
  • D) Amazon CloudWatch Logs with agent-specific log groups
  • E) AWS Cost Explorer with hourly granularity and resource-level filtering
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Amazon Bedrock AgentCore Observability (previously known as Agent Observability) provides per-invocation traces that capture the planning/LLM calls, tool invocations, knowledge base retrievals, memory operations, and coordination steps within an agent invocation. This precisely identifies cost amplification sources (e.g., unexpected retry loops, excessive tool calls, oversized context in orchestration) without requiring custom instrumentation.

Distractor Analysis

  • A is Incorrect: AWS CloudTrail records API calls for governance and audit, showing "who called what" at the service level, but it does not provide insight into the internal orchestration flow, token consumption per component, or cost attribution within a single agent invocation.
  • C is Incorrect: AWS X-Ray is a distributed tracing service for microservices architecture, but it does not natively capture Bedrock agent internal orchestration traces (planning, tool calls, memory) unless manually instrumented, which adds unnecessary complexity and does not provide agent-specific metrics out-of-the-box.
  • D is Incorrect: CloudWatch Logs could capture logs if manually configured, but Bedrock AgentCore Observability provides structured traces specifically designed for agent resource consumption analysis, including token usage per step and tool call counts, without the need for custom log schemas.
  • E is Incorrect: AWS Cost Explorer shows aggregated spend data and supports filters, but it cannot reveal internal agent orchestration patterns (e.g., why token consumption per user request increased). It identifies the symptom (cost increase) but not the root cause (amplification within agent invocations).

Key Takeaway: For Agent-based workloads on Bedrock, enable AgentCore Observability to gain per-invocation visibility into multi-step orchestration costs—one user request amplifies into multiple model and tool calls, and only trace-level observability reveals this amplification.

Question 4 - Prompt Caching Optimization Strategy

A legal research platform built on Amazon Bedrock (Claude Haiku) processes thousands of user queries daily against a large corpus of legal documents. Each user query follows the same pattern: a static 30-token system prompt containing legal disclaimers and instructions, a 200-token static document context (the specific legal domain), and a variable 50-token user question. The system architect wants to reduce inference latency and input token costs. Compliance policies mandate that the user's raw query text must never be cached.

Which prompt design should the engineer implement to maximize Prompt Caching benefits? (Select ONE)

  • A) Combine system prompt, document context, and user query into a single variable prompt without caching.
  • B) Place the static system prompt and document context at the beginning, followed by the user query, ensuring the cacheable prefix is stable.
  • C) Interleave the user query within the static document context to ensure the user query is not cached.
  • D) Use prompt caching only on the user query portion by placing it at the beginning of the prompt.
  • E) Disable prompt caching entirely because user query text cannot be cached.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Prompt caching on Amazon Bedrock caches the token prefix from the beginning of the prompt. Placing static content (system prompt and document context) at the start creates a stable, reusable cache checkpoint. Dynamic user queries at the end do not invalidate the cached prefix, maximizing cache hit rates and reducing both latency and input token costs.

Distractor Analysis

  • A is Incorrect: Combining all content into a single variable prompt defeats the purpose of prompt caching. The cache relies on stable prefix matching, so making everything variable eliminates cache effectiveness.
  • C is Incorrect: Interleaving user queries within the static content breaks the prefix stability requirement. Prompt caching only caches consecutive tokens from the beginning; any dynamic content within the prefix invalidates the cache from that point onward.
  • D is Incorrect: The user query is dynamic and varies per request. Placing it at the beginning of the prompt prevents any stable prefix from forming, as the first tokens change on every invocation, invalidating the cache entirely.
  • E is Incorrect: While user query text cannot be cached (per compliance), the static system prompt and document context form a substantial stable prefix that can be cached independently. This provides significant cost savings on the 230 cached tokens across thousands of requests.

Key Takeaway: Prompt caching optimizes input token costs by reusing KV (key-value) attention states for stable prefixes—always place static instructions at the beginning and dynamic user inputs at the end for maximum cache effectiveness.

Question 5 - Token Usage Monitoring Dashboard

A media streaming company runs multiple generative AI workloads on Amazon Bedrock across different teams (recommendation summaries, content moderation, and personalized newsletters). The CFO requires a unified view of token usage patterns and wants proactive alerting when any team's token spend approaches its monthly budget. The ML platform team must implement a solution that allows cost attribution to teams while minimizing operational overhead. The solution should not require custom metering applications.

Which combination of AWS services should the platform team use? (Select TWO)

  • A) AWS Budgets with cost allocation tags for per-team budget tracking and forecasted alerts
  • B) Amazon CloudWatch with a custom metric filter to extract token counts from Bedrock logs
  • C) AWS Cost Explorer with hourly granularity reports exported to S3
  • D) AWS Trusted Advisor for idle resource detection and cost anomaly alerts
  • E) Amazon Bedrock runtime CloudWatch metrics for token usage dashboards
Click to reveal Answer & Explanation

Correct Answers: A and E

Correct Options Analysis

  • A is Correct: AWS Budgets supports per-tag budget tracking, allowing the finance team to define monthly token-spend thresholds per team (via allocation tags). Forecasted budget alerts notify stakeholders before overruns occur, providing proactive cost controls.
  • E is Correct: Amazon Bedrock automatically emits runtime metrics (invocation counts, input/output token counts, latency) to Amazon CloudWatch. These metrics enable token usage dashboards per model or application without custom instrumentation.

Distractor Analysis

  • B is Incorrect: While you could parse Bedrock logs via CloudWatch metric filters to extract token counts, this is a manual, custom metering approach. Bedrock natively publishes token metrics to CloudWatch, making custom log-parsing unnecessary and increasing operational overhead, violating the requirement to minimize overhead.
  • C is Incorrect: AWS Cost Explorer provides historical spend analysis but does not generate real-time proactive alerts for budget thresholds. It lacks alerting capability needed for immediate action.
  • D is Incorrect: AWS Trusted Advisor checks for idle resources and best practices but does not track token-level spend, provide team-level attribution via tags, or generate budget-threshold alerts for Bedrock usage.

Key Takeaway: For FM workloads, native Bedrock CloudWatch metrics provide token observability, while AWS Budgets with cost allocation tags delivers proactive per-team spend alerting—no custom metering is needed.

Question 6 - Batch vs. Real-Time Inference Cost Decision

An insurance claims processing department ingests 500,000 claim documents every evening at midnight. These documents need to be summarized and classified using Amazon Bedrock (Claude Sonnet). The results must be available in the claims database before the next business morning (9 AM). The processing window is 9 hours, and the workload is perfectly predictable. The CFO wants the minimum possible inference cost without impacting the overnight processing deadline.

Which inference mode should the ML engineer configure for this workload? (Select ONE)

  • A) Real-time On-Demand inference with auto-scaling client logic
  • B) Real-time On-Demand inference with Provisioned Throughput
  • C) Amazon Bedrock Batch Inference with On-Demand pricing
  • D) Amazon Bedrock Batch Inference with Provisioned Throughput reserved for the overnight window
  • E) SageMaker Batch Transform with Bedrock model access
Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: Amazon Bedrock Batch Inference is purpose-built for asynchronous, high-volume workloads (up to 50,000 records per job) with 50% lower per-token pricing compared to real-time On-Demand. The 9-hour processing window comfortably accommodates 500,000 documents, and batch inference handles queueing, retries, and output storage automatically. On-Demand batch pricing avoids commitment overhead for a daily 30-minute submission pattern.

Distractor Analysis

  • A is Incorrect: Real-time On-Demand inference bills at the highest per-token rate. Processing 500,000 documents synchronously requires custom queueing, retry logic, and rate-limit management—significant operational overhead for a workload that does not require interactive responses.
  • B is Incorrect: Real-time Provisioned Throughput requires a minimum commitment duration (typically 1 hour or 1 month depending on the model) and is designed for low-latency interactive workloads. Reserving throughput for a 9-hour nightly window is less cost-effective than batch's 50% discount without commitment.
  • D is Incorrect: While Batch Inference with Provisioned Throughput is valid for continuous batch workloads, it requires a minimum one-month commitment in most Bedrock configurations. This is overkill for a nightly, 9-hour processing window and would result in paying for unused reserved capacity during daytime hours.
  • E is Incorrect: SageMaker Batch Transform works with SageMaker-hosted models, not directly with Amazon Bedrock foundation models. This option confuses service boundaries and would require custom SageMaker deployment, adding unnecessary complexity.

Key Takeaway: For asynchronous, predictable bulk workloads on Amazon Bedrock, Batch Inference delivers 50% lower token costs than real-time On-Demand without requiring capacity commitments.

Question 7 - Multi-Agent Cost Attribution

A logistics company has deployed an agent-based route optimization assistant on Amazon Bedrock Agents that uses multiple sub-agents: a traffic analysis agent, a weather agent, and a fuel cost estimation agent. The system processes 10,000 route queries daily. The finance team reports that while user traffic is stable, Bedrock spend on the traffic analysis agent has unexpectedly grown 3x over the past two weeks. The ML engineer suspects the traffic agent is making redundant tool calls due to a recent API integration change. The team must diagnose the per-invocation cost breakdown by agent and tool.

Which observability approach provides the most granular visibility for this diagnosis? (Select ONE)

  • A) AWS CloudTrail event history filtered by InvokeModel API calls
  • B) Amazon Bedrock AgentCore Observability with per-trace analysis
  • C) Amazon CloudWatch Alarms on overall Bedrock invocation metrics
  • D) AWS Compute Optimizer recommendations for Bedrock workloads
  • E) AWS X-Ray service map with Bedrock as an integrated service
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Amazon Bedrock AgentCore Observability captures per-invocation traces showing each orchestration step, tool invocation, knowledge base retrieval, and memory operation. For multi-agent systems, it attributes token consumption and latency to each sub-agent (e.g., traffic agent vs. weather agent) and each tool call (e.g., redundant API requests), enabling precise diagnosis of cost amplification.

Distractor Analysis

  • A is Incorrect: AWS CloudTrail logs API calls (e.g., InvokeModel, InvokeAgent) but does not provide internal agent orchestration details such as number of tool calls per invocation, token usage per planning step, or sub-agent resource consumption. It cannot reveal redundant internal tool calls.
  • C is Incorrect: CloudWatch Alarms on aggregate Bedrock metrics show overall invocation counts or token usage trends but lack per-agent/per-tool granularity. They can confirm a cost increase but cannot pinpoint which agent or tool produced the redundant calls.
  • D is Incorrect: AWS Compute Optimizer analyzes compute resource utilization (EC2, EBS, Lambda, ECS) to recommend right-sizing; it does not analyze Bedrock agent inference consumption patterns or provide token-level cost attribution.
  • E is Incorrect: AWS X-Ray traces distributed microservices but requires custom instrumentation to capture Bedrock agent internal orchestration (planning, tool calls, memory). AgentCore Observability provides this granularity natively without custom code, making X-Ray less efficient for this use case.

Key Takeaway: Multi-agent Bedrock workloads require AgentCore Observability for per-invocation attribution of token consumption and tool call patterns—aggregate CloudWatch metrics cannot identify which sub-agent amplifies costs.

Question 8 - Cross-Region FM Cost Implications

A multinational enterprise operates in the eu-west-1 (Ireland) region and processes customer support requests from European users. The team is evaluating two foundation models on Amazon Bedrock: Claude Sonnet (available in eu-west-1) and a newer, more cost-efficient model available only in us-east-1 (N. Virginia). The new model would reduce per-token costs by 30%, but geography constraints (GDPR) require that personal data must not leave the EU. The support requests contain customer PII that must stay within EU borders. The architect must decide whether to use the cheaper model in us-east-1.

Which decision should the ML engineer make, and why? (Select ONE)

  • A) Use the cheaper model in us-east-1 because the 30% token-cost reduction outweighs compliance risks.
  • B) Use the cheaper model in us-east-1 but implement client-side anonymization to remove PII before transmission.
  • C) Continue using Claude Sonnet in eu-west-1 because GDPR data-residency requirements prohibit transferring PII to us-east-1.
  • D) Use both models with a routing layer that sends non-PII requests to us-east-1 and PII requests to eu-west-1.
  • E) Use SageMaker hosting for the cheaper model in eu-west-1 by importing the model weights.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: GDPR restricts cross-border transfer of personal data outside the EEA unless adequate protection mechanisms exist. Using Bedrock in us-east-1 would send PII-containing prompts outside EU borders, violating data-residency obligations. Compliance constraints override cost optimization; the correct decision is to maintain inference in eu-west-1 despite higher per-token costs.

Distractor Analysis

  • A is Incorrect: Cost optimization must never override regulatory compliance. GDPR violations can result in fines up to €20 million or 4% of annual global turnover—far exceeding any token-cost savings. This option fails the compliance-first principle.
  • B is Incorrect: Client-side anonymization is risky because NLP models can sometimes reconstruct PII from context, and anonymization tools may miss subtle PII patterns (e.g., names in free text). Additionally, GDPR defines "personal data" broadly, and failing to fully anonymize before transmission creates compliance risk. This approach is operationally complex and legally uncertain.
  • D is Incorrect: Maintaining a routing layer to separate PII and non-PII requests is possible but introduces significant operational complexity (request classification, fallback logic, dual-region monitoring). For a customer-support workload where most requests contain PII, the cost benefit would materialize only for a small fraction of traffic, making this approach unjustified.
  • E is Incorrect: SageMaker hosting does not grant access to proprietary foundation model weights (e.g., Anthropic Claude models). Importing Bedrock models for self-hosting is not supported; Bedrock models are accessed exclusively through the Bedrock API. This option misunderstands service boundaries.

Key Takeaway: Regulatory compliance (e.g., GDPR data residency) takes precedence over cost optimization—never route PII to regions that violate data-residency obligations, even for significant cost reductions.

Question 9 - Context Length Optimization

A customer feedback analysis system on Amazon Bedrock (Claude Sonnet) processes user reviews. The current implementation sends the entire conversation history (average 2,500 tokens) plus a 800-token system prompt and the user review (150 tokens) with each request. The ML engineer discovers that only the last 3 turns of conversation are relevant for sentiment classification. The team wants to reduce inference costs without implementing custom summarization logic or maintaining external state.

Which optimization should the engineer recommend? (Select ONE)

  • A) Implement prompt caching for the full conversation history to reduce repeated token processing costs.
  • B) Truncate the conversation history to the last 3 turns (approximately 600 tokens) before sending to the model.
  • C) Use Amazon Bedrock Batch Inference to process reviews asynchronously at 50% discount.
  • D) Switch to a smaller model (Claude Haiku) to reduce per-token costs.
  • E) Store conversation history in Amazon DynamoDB and retrieve only recent turns using LangChain.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Context length directly drives input token costs. Sending only the last 3 turns (600 tokens) instead of full conversation history (2,500 tokens) reduces input tokens by 76% per request. This is a direct prompt engineering optimization that requires no additional architecture or external state management—simply truncating irrelevant historical context before making the API call.

Distractor Analysis

  • A is Incorrect: Prompt caching is effective for stable, repeated prefixes across multiple requests. However, conversation history varies per user session, so the prefix is unlikely to be reused across different users. Furthermore, caching does not reduce token volume sent; it only reduces processing cost (at a reduced cached-token rate), making it less effective than eliminating unnecessary tokens entirely.
  • C is Incorrect: Batch Inference provides 50% cost reduction for asynchronous workloads. However, sentiment classification for customer feedback might require real-time or near-real-time processing, and batch is appropriate only for workloads that can tolerate delay. This option changes the architecture rather than solving the root cause of oversized context.
  • D is Incorrect: Switching to a smaller model may reduce per-token cost but introduces a quality tradeoff that may not be acceptable for sentiment classification accuracy. The optimization should first address unnecessary context before changing model capabilities.
  • E is Incorrect: Using DynamoDB with LangChain introduces external state management and custom orchestration overhead. The root issue is unnecessary historical tokens in each request; simple truncation at the application layer solves this without additional services or frameworks.

Key Takeaway: Context length directly drives input token cost—review and truncate irrelevant historical context before considering model switching or caching strategies, as token elimination is always cheaper than token caching.

Question 10 - Vector Database Storage Cost Optimization

A RAG-based enterprise search system uses Amazon OpenSearch Serverless for vector storage with Amazon Bedrock (Titan Text embedding) for query and document embedding. The system stores 50 million document embeddings (1,536 dimensions each) for a static internal knowledge base that updates weekly. The ML engineering team observes that OpenSearch Serverless storage costs exceed Bedrock embedding costs by 4x. The CFO requests storage cost reduction without affecting search quality or introducing new technologies.

Which optimization should the engineer implement? (Select ONE)

  • A) Switch to a smaller embedding dimension (e.g., 384 dimensions) by selecting a more compact embedding model.
  • B) Enable vector compression using Product Quantization (PQ) to reduce storage per vector while maintaining recall accuracy.
  • C) Move the vector index to Amazon RDS for PostgreSQL with pgvector extension to reduce storage costs.
  • D) Reduce the number of stored documents by implementing document summarization before embedding.
  • E) Store embeddings in Amazon S3 with Parquet format and query using Amazon Athena for cost reduction.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Product Quantization (PQ) compresses high-dimensional vectors by approximating each vector as a combination of codebook entries, reducing storage by 4-8x (from 1,536 floats to compressed codes) with minimal impact on recall accuracy. Amazon OpenSearch Serverless supports PQ-based index compression. This directly addresses storage costs (the main bill driver) without changing embedding models or introducing new technologies.

Distractor Analysis

  • A is Incorrect: Switching to a smaller embedding dimension (384) is technically feasible with a smaller Titan model, but it requires re-embedding all 50 million documents—a significant processing expense. Additionally, lower dimensions reduce semantic fidelity, potentially degrading search quality for a large corpus. Violating the constraint to avoid affecting search quality.
  • C is Incorrect: Moving to Amazon RDS PostgreSQL with pgvector would introduce a completely different database technology, requiring migration, data conversion, query rewriting, and ongoing managed database overhead. This increases operational complexity and may not reduce costs compared to optimizing existing OpenSearch Serverless.
  • D is Incorrect: Document summarization before embedding changes the retrieval content, potentially reducing answer quality or losing critical details from source documents. This is a content-level change rather than a storage optimization and may not be acceptable if users need access to full document content.
  • E is Incorrect: Storing embeddings in S3 and querying with Athena is architecturally incorrect for vector search. Athena lacks native k-NN/ANN vector search capabilities, and scanning 50M Parquet records per query would be prohibitively slow and expensive. This option misunderstands vector search requirements.

Key Takeaway: Vector database storage is a significant cost driver in RAG systems—utilize native compression techniques (e.g., PQ, HNSW index compression) in OpenSearch Serverless to reduce storage footprint without switching technologies or re-embedding.