AWS Cost Optimization: How Much Should You Actually Commit?

Every AWS cost optimization conversation we are brought into has done the easy half already. Idle instances gone, gp2 became gp3, the dev account shuts down at night. The bill fell maybe eleven percent and stopped moving.

What is left is the decision nobody wants to own. How much compute do you commit to for the next one or three years, at a discount of up to 72%, in a contract AWS says "can't be cancelled during the term".

Our position: buy a one-year Compute Savings Plan sized to your quietest hour, buy it this quarter rather than modelling it for another one, and leave the deeper discounts alone until the platform stops changing shape. On a regulated account the extra six percent is rarely worth what it costs in movement.

Why does AWS cost optimization stall at the commitment?

Because every other lever is reversible and this one is not. Delete an unattached volume on Tuesday and you can create it again on Wednesday. Buy a three-year plan and you own 1,095 days of it, which AWS defines to the second as 94,608,000 seconds.

There is no exit. The documentation on plan types is blunt: "The terms of the commitment can't be changed after purchase. As your usage changes, you can sign up for additional Savings Plans." Additional. Not smaller.

Reserved Instances are gentler here, which nobody expects. A Convertible RI "can be changed across instance family, instance size, OS, and tenancy" if you do the exchange by hand. A Savings Plan has no equivalent, and that asymmetry is the real argument for the flexible plan over the cheap one.

What are the four Savings Plans actually committing you to?

Four, not two. The Database plan is the one most teams have not noticed yet.

• Compute Savings Plans, up to 66% off On-Demand, apply to EC2 "regardless of instance family, instance size, Region, operating system, or tenancy", and to Fargate and Lambda as well.
• EC2 Instance Savings Plans, up to 72%, tie you "to a specific instance family in a chosen AWS Region (for example, m5 in Virginia)".
• Database Savings Plans, up to 35%, span Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, DMS and OpenSearch. Read the condition twice: they "automatically apply to the latest provisioned instance generations". A fleet a generation behind gets upgraded before the plan pays.
• SageMaker AI Savings Plans, up to 64%, cover SageMaker usage across family, size, Region and component.

The six points between the Compute plan and the EC2 Instance plan are the whole decision, and the honest way to read them is as a fee for staying able to move. Six points of a $40,000 compute bill is around $2,400 a month. Ask whether your architecture will stand still for three years in exchange.

How much should you commit, and why is the average the wrong number?

Commit near your floor, because of one sentence buried in the page on how plans apply to usage: "Each hour's commitment can only be used within that hour and cannot be carried over."

That turns a one-year plan into 8,760 small bets rather than one annual bet. Size it at your average and every quiet hour, weekend and holiday burns money you cannot reclaim. For a payments platform the gap is wide. Traffic through a settlement window has little to do with traffic at 4am on a Sunday.

So the number to find is the lowest hourly compute spend of the last sixty days, then a little under it. Aim for utilisation above 98%, and treat anything below 95% as hours you bought and never used.

The first time we sized one of these we took the Cost Explorer recommendation at face value and landed at 91% utilisation. It still saved money. It saved roughly a third less than it should have.

What does a half-yearly DR drill do to an EC2 Instance Savings Plan?

It runs your workload somewhere the plan cannot reach, for a full working day, twice a year, because a regulator says so.

The RBI Cybersecurity Directions 2026 set this out for NBFCs. Paragraph 102 requires the DC and DR sites to be "geographically well separated". Paragraph 129 puts drills for critical systems "at least on a half-yearly basis". Paragraph 131 is the expensive one: the testing "shall involve switching over to the DR / alternate site and thus using it as the primary site ... where usual business operations of at least a full working day ... are covered".

Now hold an EC2 Instance Savings Plan for one family in ap-south-1 against that text. Through the drill your primary Region is nearly idle, so the commitment goes unused hour by hour, while the alternate Region runs at On-Demand rates because the plan was bought for a Region it is not in. You pay twice to prove the architecture works. A Compute plan follows the workload.

Two days a year does not decide the business case. It does tell you that a Region-scoped plan assumes the workload never moves, while a direction your board has adopted says it must. The rest of what that direction asks of an AWS account is in our walkthrough of the 2026 direction.

Who in your organisation is spending your discount?

Possibly an account you have never logged into. Reserved Instances apply first, then EC2 Instance plans, then Compute plans, "because Compute Savings Plans have broader applicability", and within that AWS applies the commitment "to your highest savings percentage first". The discount lands where it is worth most, not where you intended.

Then the sharing default. The billing preferences documentation makes open sharing the default, where "discounts are available to all sharing-activated accounts within the organization". Only the management account can change it, and there is a cutoff most people miss: the final bill "is calculated based on the preferences set at 23:59:59 UTC time on the last day of the month".

Open sharing is the right default and we leave it on. The reporting is what breaks: a plan bought by the platform account and consumed by three product accounts makes every per-team number wrong until somebody decides which account carries the amortised commitment. Which AWS cost metric settles that is in the post on which cost number to report.

What is still charged at On-Demand after you commit?

More than the name suggests. Three of these catch people out.

• Spot, and anything an RI already covers. Savings Plans do not apply "to spot usage or usage covered by RIs". Size a plan against a bill that is half Spot and you have over-committed by half.
• The EKS control plane. "Amazon EKS charges will not be covered by Savings Plans, but the underlying EC2 instances will be." What else on EKS is still yours is in the post on managed Kubernetes.
• Dedicated Instance fees. "Dedicated Instances are charged $2/hour in every Region you have at least one Dedicated Instance running. These dedicated fees are not discounted by Savings Plans."

A fourth rarely changes the sizing: "Savings Plans doesn't provide capacity reservations."

Then the non-compute half of the bill. CloudWatch, KMS, AWS Config, GuardDuty, NAT processing and cross-zone transfer are untouched by any of this. Which of those a regulator requires you to keep is in what a fintech can cut without failing an audit.

What can you run on Monday?

Two calls and ten minutes. The first asks AWS what it would recommend and, more usefully, hands back your own hourly floor, average and peak. Cost Explorer is a global endpoint, so point it at us-east-1.

for TERM in ONE_YEAR THREE_YEARS; do
  echo "== $TERM"
  aws ce get-savings-plans-purchase-recommendation \
    --region us-east-1 \
    --savings-plans-type COMPUTE_SP \
    --term-in-years "$TERM" \
    --payment-option NO_UPFRONT \
    --lookback-period-in-days SIXTY_DAYS \
    --account-scope PAYER \
    --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[0].{
              commitment:HourlyCommitmentToPurchase,
              floor:CurrentMinimumHourlyOnDemandSpend,
              average:CurrentAverageHourlyOnDemandSpend,
              peak:CurrentMaximumHourlyOnDemandSpend,
              savings:EstimatedSavingsPercentage}' \
    --output table
done

Read floor against commitment. The API reference defines that floor as "the lowest value of hourly On-Demand spend over the lookback period", and a recommendation well above it is betting your quiet hours look like your busy ones. Then read peak against floor. Past roughly three to one, the platform is too variable for a three-year term.

If you already hold plans, the second call says whether they work.

aws ce get-savings-plans-utilization \
  --region us-east-1 \
  --time-period Start=2026-07-01,End=2026-10-01 \
  --granularity MONTHLY \
  --query 'SavingsPlansUtilizationsByTime[].{month:TimePeriod.Start,
            unused:Utilization.UnusedCommitment,
            pct:Utilization.UtilizationPercentage}' \
  --output table

One warning from experience. Run the first command from the management account with --account-scope PAYER, or you size the commitment against one member account and miss the rest of the organisation. The recommendation still looks convincing.

When is committing nothing the honest answer?

More often than a cost consultant will tell you. Three cases, and we would say so without hesitating.

If you are still spending AWS credits, committing buys a discount on money you were not going to pay. If a migration falls inside the term, the bill you are committing against is about to stop existing. And if the peak-to-floor ratio from that first command is wide, the plan sits idle most of the week.

A fourth case is less about arithmetic. Where no single person owns the AWS bill, a three-year commitment creates an obligation with no owner, and in eighteen months nobody will remember what it was sized against. Fix that first. How credits and lock-in distort all of this is in what lock-in costs a fintech.

The short version

Buy a one-year Compute Savings Plan with no upfront, sized just under your lowest hourly compute spend over the last sixty days. Pay the six-point difference against the EC2 Instance plan for the right to move Region, change family and run a DR drill without losing the discount.

Check utilisation monthly and expect above 98%. Size nothing against a bill that is half Spot, half credits or about to be re-architected. And if you want the fast version: run the first command, compare floor with commitment, and start the argument there.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.