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.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
Economic design must meet deadline, correctness, and recovery needs. Calculate over consistent scope and make demand assumptions explicit.
Reference: Savings Plans overview · SAA-C03