← AWS Solutions Architect Associate: architecture decisions
18 / 18 · 60 MIN

Compute: commitments and batch recovery

Compare cost per result, hourly commitment, and interruption tolerance before choosing capacity.

Separate demand, price, and capacity

A Saturday change needs available capacity and predictable spending. A Savings Plan addresses eligible-use pricing; it does not reserve EC2 capacity in an AZ. Record these needs separately and identify the appropriate mechanism for each. Commitment should start from forecast demand after known changes, not the largest historical peak. The technical manager needs to reconcile retirement, migration, and scheduling plans with FinOps. A financial commitment without a map of covered applications can retain spending after the work that justified the purchase has disappeared.

Use compatible intervals

In the exercise, commitment is eight units per hour and eligible usage at plan rates is five in one hour and eleven in the next. The average is eight, but the first hour leaves three commitment units unused. Do not turn that amount into credit for the second hour. This model does not calculate an AWS bill: relevant On-Demand rates and application rules are missing. It exposes the error of comparing only averages. Analyze hourly distribution, term, applicable sharing, and expected changes before estimating utilization and financial risk.

Choose scope without premature purchase

Compute Savings Plans can follow eligible EC2, Fargate, and Lambda usage and offers regional flexibility. EC2 Instance Savings Plans has a different scope tied to family and Region. This distinction helps formulate alternatives without proving that a purchase is beneficial. An application consumes four of ten forecast hourly units and will retire before commitment begins. The exercise’s remaining baseline is six, subject to uncertainty. Document which teams retain that demand, how changes will be communicated, and the observed period. Do not extend the discount to S3 storage or traffic by analogy.

Compare valid results and complete costs

One option costs 18 units and completes 900 valid files; another costs 15 and completes 600. The first has unit cost of 0.020, below the second’s 0.025. Lower total price does not mean greater efficiency. Define deadlines and quality too: invalid files must not improve the metric by enlarging its denominator. During migration, compute savings can be partly consumed by transfer and operations. Maintain the same cost boundary across alternatives and identify excluded values. Fictional numbers teach comparison; they are not current prices for AWS services.

Prepare for interruption before the notice

Spot can suit interruptible work, but the design must not depend on receiving a notice. Delivery is best effort, and hibernation does not offer two minutes of advance warning. Save durable progress during processing, use stable identifiers, and control repeated effects. If the latest checkpoint covers minute 18 and failure occurs at minute 23, the model requires five minutes of replay, plus excluded startup time. Another copy on the same instance store does not solve local loss. Exercising resume includes validating final results rather than merely restarting the process.

Define an acceptance experiment

The team proposes a smaller instance because average CPU is low. However, the batch reaches 95% memory and already fails from memory shortage. The experiment must preserve data, deadline, correctness, and resume capability. Compare candidate families using the same workload, including the busiest close; measure memory, duration, I/O, and cost per valid result. Introduce a simulated failure in the teaching model and confirm the ledger does not duplicate effects. The project decision presents benefit, limits, change effort, owners, and a return criterion. A discount does not fix a technical constraint.

# Synthetic hourly model, usage already valued at plan rates
commitment = 8
usage = [5, 11]
unused = sum(max(0, commitment-u) for u in usage) # 3
# Excess usage needs applicable rates before calculating a bill.
IN PRACTICE

Fictional commitment of 8/hour and use of 5/hour, 11/hour: the average hides 3 unused units in hour one. This is not an AWS bill calculation.

Common pitfalls

Using averages to hide underutilization; assuming capacity reservation; shrinking RAM based on CPU; saving checkpoints only after notice; confusing discounts with efficiency.

Related topics: Data protection and recovery · Storage and content delivery · Costs, commitments, and retirement

Take this idea with you

Economic design must meet deadline, correctness, and recovery needs. Calculate over consistent scope and make demand assumptions explicit.

Create account

Reference: Savings Plans overview · SAA-C03

AWS is a trademark of Amazon.com, Inc. or its affiliates. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by AWS. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.