Skill 4.2.6: Optimize infrastructure costs by selecting purchasing options
Question 1 - SageMaker Savings Plans vs Compute Savings Plans
A financial services company operates a fraud detection suite on Amazon SageMaker AI that includes a real-time inference endpoint for transaction scoring, a nightly batch transform job for account profiling, and several Studio notebooks used by data scientists. The inference endpoint handles a steady year-round transaction volume, while the batch transform and notebooks have variable usage patterns. The infrastructure lead wants to reduce costs on the predictable SageMaker usage without committing to a specific instance type or family.
Which purchasing option should the company select to maximize savings on the steady SageMaker usage? (Select ONE)
- A) Purchase EC2 Instance Savings Plans for the
ml.*instance family used by the endpoint - B) Purchase Compute Savings Plans to cover Amazon EC2, AWS Fargate, and SageMaker AI usage
- C) Purchase SageMaker AI Savings Plans with a 1-year or 3-year commitment
- D) Convert the real-time endpoint to Amazon Bedrock on-demand inference and eliminate compute costs
- E) Register the account for Enterprise Discount Program pricing through AWS Organizations
Click to reveal Answer & Explanation
Correct Answer: C
Correct Answer Analysis
C is Correct: Amazon SageMaker AI Savings Plans are specifically designed for SageMaker workloads (training, inference, batch transform, notebooks). They provide up to 64% savings in exchange for a consistent hourly spend commitment over 1 or 3 years, without requiring commitment to a specific instance family or region.
Distractor Analysis
- A is Incorrect: EC2 Instance Savings Plans apply exclusively to Amazon EC2 instances, and do not cover SageMaker
ml.*instance types. Committing to an EC2 family would not reduce SageMaker endpoint costs. - B is Incorrect: Compute Savings Plans apply to Amazon EC2, AWS Fargate, and AWS Lambda usage only — they explicitly exclude SageMaker ML instance usage.
- D is Incorrect: Moving a SageMaker real-time fraud detection endpoint to Amazon Bedrock on-demand inference is an incompatible architectural shift. This would require re-platforming to a foundation model, which may not meet the deterministic scoring/security requirements of a fraud detection system.
- E is Incorrect: Enterprise Discount Program (EDP) is a negotiated agreement with AWS for large enterprise customers, not a standard self-service purchasing option applicable to this scenario without additional enterprise negotiation.
Key Takeaway: SageMaker AI Savings Plans are the only Savings Plans type that covers SageMaker
ml.*instance usage — remember that EC2 and Compute Savings Plans do not extend to SageMaker.
Question 2 - Provisioned Throughput vs On-Demand for Bedrock
A healthcare technology company has deployed a patient triage assistant using Amazon Bedrock with the Claude 3 Sonnet model. Traffic analysis shows consistent, predictable, high-volume inference requests 24/7 with minimal fluctuation. The team currently uses on-demand pricing and is looking to reduce per-request costs while maintaining low latency for interactive patient interactions. The workload cannot tolerate cold starts or reduced throughput during peak hospital admission hours.
Which purchasing option should the company implement for optimal cost and performance? (Select ONE)
- A) Purchase a 3-year SageMaker AI Savings Plan to cover the Bedrock inference costs
- B) Purchase Amazon Bedrock Provisioned Throughput for the Claude model with a 1-month or 6-month commitment
- C) Enable prompt caching on the triage prompts to reduce token costs during high-volume periods
- D) Migrate to Amazon Bedrock batch inference during peak hours to take advantage of discounted batch rates
- E) Configure an auto-scaling policy that provisions additional Bedrock model units when request volume increases
Click to reveal Answer & Explanation
Correct Answer: B
Correct Answer Analysis
B is Correct: Amazon Bedrock Provisioned Throughput allows customers to reserve dedicated model capacity for a specific foundation model (like Claude 3 Sonnet) at a fixed hourly rate with a 1-month or 6-month commitment. This provides significant cost savings over on-demand token pricing for predictable, steady, high-volume workloads while maintaining consistent low-latency performance.
Distractor Analysis
- A is Incorrect: SageMaker AI Savings Plans cover SageMaker
ml.*compute usage only — they do not apply to Amazon Bedrock foundation model inference, which is billed by tokens or provisioned throughput. - C is Incorrect: Prompt caching reduces token processing costs for repeating prefixes but does not provide the same predictable discount as provisioned throughput and does not reserve capacity. It is a complementary optimization, not a purchasing option.
- D is Incorrect: Bedrock batch inference is designed for asynchronous, large-scale workloads that tolerate delayed responses (hours to days), not interactive patient triage that requires real-time responses during admission hours.
- E is Incorrect: Amazon Bedrock does not support auto-scaling of provisioned throughput via a user-defined policy in the same way SageMaker endpoints do. Additionally, provisioned throughput capacity is committed at purchase time and cannot be dynamically scaled without modifying the commitment.
Key Takeaway: Provisioned Throughput on Bedrock is the commitment-based purchasing option for predictable, interactive foundation model inference — it reserves capacity at a fixed hourly rate rather than paying per token.
Question 3 - EC2 Spot Instances for Training Jobs
A machine learning engineering team at an e-commerce company runs a weekly model training job for product recommendation models on Amazon SageMaker AI. The training job uses distributed data parallelism across multiple GPU instances and can resume from checkpoints saved in S3 if the instances are interrupted. The job completes in 2 hours on on-demand instances, and the team is looking to reduce training costs by 60-70%. The training pipeline has flexible execution windows within a 4-day period before model deployment.
Which TWO purchasing strategies should the team use for the training infrastructure? (Select TWO)
- A) Run the training job on Amazon EC2 Spot Instances with SageMaker managed spot training
- B) Purchase a 3-year EC2 Reserved Instance for the specific
p4d.24xlargeinstance type used in training - C) Purchase Compute Savings Plans covering the exact EC2 and SageMaker usage of the training job
- D) Configure automatic checkpointing to Amazon S3 and enable spot interruption handling
- E) Convert to Amazon Bedrock Provisioned Throughput for the model training workload
Click to reveal Answer & Explanation
Correct Answers: A and D
Correct Options Analysis
- A is Correct: SageMaker managed spot training allows training jobs to use EC2 Spot capacity, which offers up to 90% savings compared to on-demand and is ideal for fault-tolerant, interruptible workloads. The 4-day flexibility window makes spot interruption unlikely to cause delays.
- D is Correct: Configuring automatic checkpointing to S3 ensures that when a spot instance is reclaimed, the training state is preserved, and SageMaker automatically resumes training on a new instance from the last checkpoint. This is the required pattern for spot training reliability.
Distractor Analysis
- B is Incorrect: A 3-year Reserved Instance for a specific
p4d.24xlargeinstance type is a long-term commitment that is only cost-effective for steady, year-round usage. A weekly 2-hour training job uses roughly 104 hours/year, far below the usage threshold where RI commitment makes economic sense. - C is Incorrect: Compute Savings Plans require a consistent hourly spend commitment (e.g., $X/hour). A weekly intermittent training job has such low utilization that committing to an hourly rate would waste the majority of the commitment's value.
- E is Incorrect: Amazon Bedrock Provisioned Throughput is for foundation model inference serving, not for custom training jobs. Bedrock does not support training custom recommendation models on
p4dGPU instances.
Key Takeaway: Spot capacity is the cost-effective purchasing option for interruptible training workloads with checkpointing — reserved capacity is economically justified only for sustained, year-round usage.
Question 4 - Cost Allocation Tags and Budgets for Multi-Team Environment
A large organization runs multiple machine learning workloads in a shared AWS account: a marketing team uses Amazon Bedrock for content generation, a risk team runs Amazon SageMaker AI endpoints, and an engineering team runs EC2 instances for a custom inference engine. The finance team reports that total AWS costs have increased 35% quarter over quarter, but cannot identify which team or workload is driving the increase. The cloud governance team wants to enforce spend accountability per team and receive proactive alerts when each team's spend is on track to exceed their monthly allocation.
Which TWO actions will address the requirements? (Select TWO)
- A) Activate AWS Cost Explorer and generate a monthly cost report broken down by AWS service
- B) Apply cost allocation tags (e.g.,
team,workload-type,environment) to all ML resources - C) Create separate AWS accounts for each team using AWS Organizations and consolidate billing
- D) Create an AWS Budget per team with forecasted cost alerts configured for the team's monthly threshold
- E) Use AWS Trusted Advisor cost checks to identify idle and underused ML resources
Click to reveal Answer & Explanation
Correct Answers: B and D
Correct Options Analysis
- B is Correct: Cost allocation tags enable AWS Cost Explorer to group and filter spend by custom dimensions like
teamandworkload-type. This is the foundational prerequisite for attributing shared account costs to specific teams or workloads. - D is Correct: AWS Budgets supports creating per-team budgets with forecasted cost alerts that notify stakeholders when spend is projected to exceed their defined threshold before the overage occurs. This directly satisfies the proactive alerting requirement.
Distractor Analysis
- A is Incorrect: AWS Cost Explorer reporting by service alone does not enable per-team attribution if cost allocation tags are not applied. Service-level breakdowns cannot distinguish which team is driving Bedrock or SageMaker costs.
- C is Incorrect: While separate AWS accounts per team would enable cost isolation, this introduces significant architectural and operational overhead (VPC peering, IAM complexity, data sharing), and does not necessarily provide proactive budget alerts without additional configuration. The question's "shared AWS account" context suggests tagging is the more appropriate solution.
- E is Incorrect: AWS Trusted Advisor cost checks historically have identified idle load balancers, underutilized EBS volumes, and idle RDS instances — they do not provide per-team cost attribution or forecasted threshold alerts.
Key Takeaway: Cost allocation tags are the prerequisite to cost attribution, and AWS Budgets provides proactive forecasted alerts — both together enable per-team spend accountability in a shared account.
Question 5 - Model Selection vs Provisioned Throughput for Bedrock Cost Optimization
A startup is building a customer support chatbot using Amazon Bedrock. Initial usage shows the team selected Claude 3.5 Sonnet for all interactions, including simple intent classification, FAQ lookups, and sentiment analysis. Analysis reveals that 70% of requests are simple intent classification that could achieve 99% accuracy with a smaller model. Monthly token consumption is 1.2 billion input tokens and 400 million output tokens, and costs are 3x the team's target budget. The workload has variable traffic with peaks during business hours.
Which TWO strategies should the team implement to reduce costs while maintaining response quality? (Select TWO)
- A) Upgrade all workflows to Claude 3.5 Sonnet v2 to improve quality and reduce retries
- B) Route simple intent classification and FAQ lookups to a smaller model like Claude 3 Haiku or Amazon Titan Text Lite
- C) Purchase 6-month Provisioned Throughput for Claude 3.5 Sonnet based on the peak traffic volume
- D) Enable prompt caching for the static system instructions and tool schemas that repeat across all requests
- E) Purchase a SageMaker AI Savings Plan to cover the Bedrock token-based billing
Click to reveal Answer & Explanation
Correct Answers: B and D
Correct Options Analysis
- B is Correct: Model selection based on task complexity is a core Bedrock cost optimization lever. Simple intent classification and FAQ lookup tasks that do not require a large frontier model can be routed to smaller, cheaper models (e.g., Claude 3 Haiku, Titan Text Lite) at a fraction of the cost per token while maintaining quality thresholds.
- D is Correct: Prompt caching reduces the cost of processing repeated token prefixes (system instructions, tool definitions) that appear in every request. Static content that repeats across requests is billed at a reduced cached rate after the initial write, directly reducing input token costs.
Distractor Analysis
- A is Incorrect: Upgrading to a larger or newer model increases per-token costs and does not address the fundamental over-provisioning of model capability for simple tasks. The issue is not quality or retries but inappropriate model sizing.
- C is Incorrect: Provisioned Throughput is ideal for predictable, steady, high-volume workloads. This scenario explicitly states variable traffic with peak-only periods, making on-demand pricing more appropriate. Additionally, committing peak capacity for a variable workload wastes capacity during off-peak hours.
- E is Incorrect: SageMaker AI Savings Plans apply only to SageMaker
ml.*instance usage, not Amazon Bedrock token-based billing. This is a fundamental service-level mismatch.
Key Takeaway: For Bedrock cost optimization, model selection (rightsizing the FM) and prompt caching are the primary levers when traffic is variable — provisioned throughput is reserved for predictable steady-state workloads.
Question 6 - Spot Instances for Real-Time Inference Baseline
A media streaming company runs a real-time content moderation classification model on Amazon SageMaker AI endpoints. The endpoint serves interactive client requests with a p99 latency requirement of 150ms. The team observes the endpoint traffic is steady, year-round, with no seasonal fluctuations. The finance team suggests using EC2 Spot capacity to reduce the endpoint's infrastructure costs.
What should the ML engineer recommend to the finance team? (Select ONE)
- A) Accept the recommendation and enable SageMaker managed spot training for the inference endpoint
- B) Accept the recommendation and configure the endpoint with EC2 Spot Instances, enabling auto-scaling to replace reclaimed instances
- C) Reject the recommendation because Spot Instances cannot support SageMaker real-time endpoints
- D) Reject the recommendation because Spot Instances can be reclaimed with short notice, breaking the real-time latency SLA
- E) Accept the recommendation and use spot capacity only during off-peak hours using a custom scaling policy
Click to reveal Answer & Explanation
Correct Answer: D
Correct Answer Analysis
D is Correct: EC2 Spot Instances can be reclaimed by AWS with as little as 2 minutes of notice when demand for on-demand capacity increases. A real-time inference endpoint with a strict 150ms latency SLA cannot tolerate sudden capacity loss without causing request timeouts, throttling, or cold starts while replacement instances are provisioned. Spot capacity does not provide a serving availability guarantee.
Distractor Analysis
- A is Incorrect: "SageMaker managed spot training" is specific to training jobs, not inference endpoints. Additionally, spot training is designed for interruptible workloads with checkpointing — not real-time serving.
- B is Incorrect: While SageMaker endpoints can technically be launched with EC2 Spot instances in some configurations, this is explicitly discouraged for production real-time serving because spot reclamation causes unpredictable capacity loss that cannot be auto-scaled instantly enough to maintain latency SLAs.
- C is Incorrect: This is factually inaccurate — SageMaker real-time endpoints can be launched with spot instances; the issue is not technical feasibility but reliability and SLA compliance.
- E is Incorrect: Spot capacity is not suitable for any portion of a real-time serving baseline, even off-peak. Reclamation risk exists at all times, and the sudden loss of even off-peak capacity would trigger client-facing errors.
Key Takeaway: Spot Instances are suitable for fault-tolerant, interruptible workloads like batch training with checkpointing — never for real-time inference serving with strict availability and latency requirements.
Question 7 - Compute Savings Plans for Serverless ML Workload
A machine learning team runs a serverless inference pipeline using AWS Lambda functions for lightweight text preprocessing before calling Amazon Bedrock for LLM inference. The Lambda functions process millions of requests monthly with consistent daily patterns. The team also runs periodic data preprocessing jobs on AWS Fargate with moderate, predictable usage. The team wants to reduce the cost of the Lambda and Fargate usage and is evaluating purchasing options.
Which purchasing option should the team select? (Select ONE)
- A) Purchase SageMaker AI Savings Plans with a 1-year commitment
- B) Purchase Compute Savings Plans with a 1-year commitment
- C) Purchase EC2 Instance Savings Plans for the lambda and fargate instance types
- D) Purchase Amazon Bedrock Provisioned Throughput for the Lambda preprocessing function
- E) No purchasing option applies because Lambda and Fargate are serverless services with no commitment discounts
Click to reveal Answer & Explanation
Correct Answer: B
Correct Answer Analysis
B is Correct: AWS Compute Savings Plans provide flexibility across Amazon EC2, AWS Lambda, and AWS Fargate usage. By committing to a consistent hourly spend ($/hour) over a 1-year or 3-year term, the team receives discounted rates on Lambda execution time and Fargate vCPU/memory consumption, regardless of region, instance family, or operating system.
Distractor Analysis
- A is Incorrect: SageMaker AI Savings Plans apply only to SageMaker
ml.*instance types (training, inference, notebooks, processing). They do not cover serverless services like Lambda and Fargate. - C is Incorrect: EC2 Instance Savings Plans are tied to specific EC2 instance families and regions. Lambda functions and Fargate tasks do not map to specific EC2 instance types that customers can commit to.
- D is Incorrect: Amazon Bedrock Provisioned Throughput applies to foundation model inference capacity, not Lambda function execution. Lambda preprocessing would still incur Lambda compute costs regardless of Bedrock provisioning.
- E is Incorrect: Both Lambda and Fargate are explicitly covered by Compute Savings Plans, making this statement factually incorrect.
Key Takeaway: Compute Savings Plans are the correct purchasing option for serverless compute (Lambda and Fargate) — they provide flexible coverage across compute services regardless of region or family.
Question 8 - Provisioned Throughput for Batch Inference Workload
A research institution processes genomic data using a large language model on Amazon Bedrock to summarize and annotate research papers. The workload involves processing 50,000 papers per week, with a total input of approximately 200 million tokens per week. The processing can tolerate up to 24 hours of latency per paper and runs continuously throughout the week. The institution wants to minimize the cost per token while maintaining a reasonable processing rate.
Which purchasing option should the institution select? (Select ONE)
- A) Purchase Amazon Bedrock Provisioned Throughput with a 1-month commitment
- B) Use Amazon Bedrock on-demand inference with prompt caching
- C) Use Amazon Bedrock batch inference to process the weekly papers at a discounted rate
- D) Purchase a 3-year SageMaker AI Savings Plan to reduce per-token costs
- E) Run the workload on Amazon SageMaker AI real-time endpoints with spot instances
Click to reveal Answer & Explanation
Correct Answer: C
Correct Answer Analysis
C is Correct: Amazon Bedrock batch inference (also called "model invocation logging to S3" or asynchronous inference) is specifically designed for large-scale, asynchronous workloads that tolerate significant latency. Batch inference offers up to 50% lower cost per token compared to on-demand real-time inference, making it the most cost-effective option for processing 50,000 papers/week with 24-hour latency tolerance.
Distractor Analysis
- A is Incorrect: Provisioned Throughput is designed for real-time interactive workloads requiring low-latency responses. It would reserve capacity at an hourly rate regardless of whether the institution's pipeline is actively submitting requests, resulting in wasted committed capacity when workload arrival is not perfectly steady.
- B is Incorrect: On-demand inference charges the standard per-token rate. While prompt caching could reduce repeat token costs, it does not provide the 50% batch pricing discount and is still priced for real-time response expectations.
- D is Incorrect: SageMaker AI Savings Plans apply to SageMaker compute infrastructure (training, endpooints, batch transform), not Amazon Bedrock foundation model inference by token. This is a service-level mismatch.
- E is Incorrect: Running on SageMaker real-time endpoints with spot instances introduces unnecessary complexity and cost. Genomic paper summarization using an LLM is best served by Bedrock, not a custom SageMaker endpoint, and spot capacity is unsuitable for a sustained processing pipeline.
Key Takeaway: Bedrock batch inference provides the lowest per-token cost for workloads that can tolerate hours of latency — a direct alternative to provisioned throughput when the workload is asynchronous.
Question 9 - Cost Analysis and Trusted Advisor for Underutilized Resources
A machine learning platform team at a retail company receives complaints from the finance department about rising AWS costs. The team reviews Amazon SageMaker AI usage and discovers multiple unused endpoints created for previous experiments, idle notebooks left running overnight, and an incorrect instance type (ml.p4d.24xlarge) being used for a lightweight inference workload that only requires CPU. The team needs to identify all cost optimization opportunities and receive actionable recommendations.
Which AWS service should the team use to identify these specific resource cost issues? (Select ONE)
- A) AWS Cost Explorer to analyze spend by tag
- B) AWS Trusted Advisor cost optimization checks
- C) Amazon CloudWatch dashboards to monitor instance utilization
- D) AWS X-Ray trace analysis to identify underutilized resources
- E) Amazon Bedrock AgentCore Observability to monitor agent consumption
Click to reveal Answer & Explanation
Correct Answer: B
Correct Answer Analysis
B is Correct: AWS Trusted Advisor includes cost optimization checks that automatically surface idle and underutilized resources, including: * Idle SageMaker notebook instances and endpoints * Underutilized Amazon EBS volumes * Idle load balancers and RDS instances * Unassociated Elastic IP addresses It provides actionable recommendations directly aligned with the cost issues described in the scenario.
Distractor Analysis
- A is Incorrect: AWS Cost Explorer reports historical and forecasted spend by tag, service, or usage type, but it does not identify specific underutilized resources or provide recommendations for resource-level cost optimization. It answers "where did the money go?" not "what specific resources are waste?"
- C is Incorrect: CloudWatch dashboards display utilization metrics, but someone must proactively build the dashboard, define thresholds, and interpret the metrics to identify waste. CloudWatch does not automatically generate recommendations.
- D is Incorrect: AWS X-Ray traces request flows across services to identify latency bottlenecks and error propagation. It is a performance debugging tool, not a cost optimization tool — it does not surface idle resources.
- E is Incorrect: Amazon Bedrock AgentCore Observability captures inference calls, tool invocations, and memory operations inside agent executions. It is designed for Bedrock agent debugging and performance analysis, not for identifying underutilized AWS infrastructure resources.
Key Takeaway: AWS Trusted Advisor automatically scans for idle and underutilized AWS resources (including SageMaker endpoints) that inflate your bill, providing actionable recommendations without manual analysis.
Question 10 - Cross-Service Purchasing Option Application
A large fintech company runs a comprehensive ML platform with heterogeneous workloads:
- Workload 1: Real-time credit scoring inference on 50
ml.c5.xlargeinstances running 24/7 on SageMaker AI - Workload 2: Amazon ECS-based feature engineering on 100 EC2 instances with steady 24/7 utilization
- Workload 3: An LLM-powered document parsing pipeline using Amazon Bedrock with 10 billion input tokens/year
The procurement team is evaluating which purchasing options to apply to each workload. Which combination of purchasing options is correct for maximizing savings? (Select ONE)
- A) SageMaker AI Savings Plans for Workload 1, Compute Savings Plans for Workload 2, Provisioned Throughput for Workload 3
- B) Compute Savings Plans for Workload 1, EC2 Reserved Instances for Workload 2, Batch Inference for Workload 3
- C) EC2 Instance Savings Plans for Workload 1, Compute Savings Plans for Workload 2, On-Demand Bedrock for Workload 3
- D) SageMaker AI Savings Plans for Workload 1, EC2 Instance Savings Plans for Workload 2, SageMaker AI Savings Plans for Workload 3
- E) Compute Savings Plans for all three workloads with a single 3-year commitment
Click to reveal Answer & Explanation
Correct Answer: A
Correct Answer Analysis
A is Correct: This option correctly matches each workload to its applicable purchasing option:
* Workload 1 (SageMaker AI): SageMaker AI Savings Plans apply specifically to SageMaker ml.* instance types and provide up to 64% discount. With 50 instances running 24/7, the steady usage justifies a commitment.
* Workload 2 (EC2 via ECS): Compute Savings Plans apply to Amazon EC2 usage running on any instance family, region, or operating system. The steady 24/7 utilization makes this economically viable.
* Workload 3 (Bedrock): Provisioned Throughput provides discounted fixed hourly rates for predictable, high-volume foundation model inference, which the 10 billion annual input tokens represent.
Distractor Analysis
- B is Incorrect: Compute Savings Plans do not cover SageMaker
ml.*instance usage (Workload 1). EC2 Reserved Instances are less flexible than Compute Savings Plans for ECS workloads. Batch inference is not a purchasing option but a capacity mode that only applies if the document parsing can tolerate hours of latency. - C is Incorrect: EC2 Instance Savings Plans do not apply to SageMaker ML instances (Workload 1). On-Demand Bedrock for a predictable 10B token/year workload would incur the highest per-token rates.
- D is Incorrect: SageMaker AI Savings Plans do not apply to Amazon Bedrock token-based inference (Workload 3). Bedrock requires Provisioned Throughput or batch inference for discounted pricing.
- E is Incorrect: Compute Savings Plans do not cover SageMaker AI or Amazon Bedrock usage. This option would save money only on Workload 2, leaving Workloads 1 and 3 at full on-demand rates.
Key Takeaway: Precision about coverage matters: SageMaker AI Savings Plans → SageMaker only, Compute Savings Plans → EC2/Lambda/Fargate, Provisioned Throughput → Bedrock FMs. Never apply a commitment across service boundaries.
Summary of Purchasing Options Coverage
| Purchasing Option | Coverage | Best For |
|---|---|---|
| SageMaker AI Savings Plans | SageMaker ml.* instance usage (Training, Inference, Batch Transform, Notebooks) |
Steady SageMaker workloads |
| Compute Savings Plans | EC2, Lambda, Fargate | Serverless and container workloads |
| EC2 Instance Savings Plans | EC2 instances in a specific family/region | Steady EC2 workloads with known instance families |
| EC2 Spot Instances | Interruptible EC2 capacity at up to 90% discount | Training with checkpointing, batch processing |
| Bedrock Provisioned Throughput | Reserved FM capacity at fixed hourly rate | Predictable, interactive, high-volume FM inference |
| Bedrock Batch Inference | Discounted token rates for asynchronous processing | Large-scale, latency-tolerant FM workloads |
| AWS Budgets | Cost tracking and forecasted alerts | Proactive spend monitoring per team/workload |
| Cost Allocation Tags | Attribute spend by custom dimensions | Multi-team spend accountability |