Cut AWS Compute Costs Safely: Spot Instances, Savings Plans, and Right-Sizing

The Right Order to Optimize Compute Cost

Most teams overpay for AWS compute because they attack the problem in the wrong sequence. They buy a commitment for capacity they do not need, or chase Spot savings on workloads that cannot tolerate interruption. Do it in this order and the savings compound safely:

1. Right-size first. Never commit to or discount an instance that is twice as big as it needs to be.
2. Cover steady-state demand with Savings Plans. Get a discount on the baseline you will always run.
3. Run interruptible and bursty workloads on Spot. Capture the deepest discounts where interruption is acceptable.

Get the order wrong and you lock in waste. Get it right and a 40-60% reduction on compute is realistic without any reliability cost.

Step 1: Right-Sizing

Right-sizing means matching instance type and size to actual utilization. The typical fleet has instances sitting at 10-20% CPU and 30% memory, sized for a peak that was guessed at, not measured. Pull two weeks of CloudWatch metrics (and memory, via the CloudWatch agent, since memory is not collected by default) and look for:

• Instances with p95 CPU under 40% and low memory: downsize one step.
• Instances on older generations: move m5 to m6i or m7i for better price-performance at the same or lower cost.
• Idle instances running 24/7 for a job that runs an hour a day: schedule start/stop or move to serverless.

AWS Compute Optimizer gives machine-generated right-sizing recommendations for free; treat it as a starting list, then validate against your own understanding of each workload. Right-sizing alone frequently cuts 20-30% before any purchase commitment.

Step 2: Savings Plans for the Baseline

Once instances are correctly sized, cover your predictable, always-on demand with a commitment. You have two main options:

• Compute Savings Plans give up to roughly 66% off on-demand and apply flexibly across instance families, sizes, regions, and even Fargate and Lambda. Maximum flexibility, slightly smaller discount.
• EC2 Instance Savings Plans give a deeper discount (up to about 72%) but lock you to a specific instance family in a region.

For most teams, Compute Savings Plans are the safer default because they follow you as your architecture changes. Commit only to your steady-state floor, the compute you are confident you will run for the full term regardless of growth. A common mistake is committing to peak or to current usage that includes waste you have not cleaned up yet. That is why right-sizing comes first.

Choose a one-year, no-upfront plan when you are unsure, and a three-year, all-upfront plan for rock-solid baseline workloads where you want the maximum discount. Ramp your coverage: aim to cover 70-80% of steady usage, not 100%, so seasonal dips do not leave you paying for unused commitment.

Step 3: Spot Instances for Interruptible Work

Spot Instances sell you spare EC2 capacity at 70-90% off on-demand, with one catch: AWS can reclaim them with a two-minute warning. That makes them perfect for workloads that tolerate interruption and terrible for a single stateful database.

Great Spot candidates:

• Stateless web and API fleets behind a load balancer with many replicas
• Batch processing, data pipelines, and CI/CD build runners
• Containerized workloads on EKS or ECS with multiple nodes
• Big data jobs (EMR, Spark) that checkpoint and resume

The key to using Spot safely is diversification. Do not request a single instance type in a single Availability Zone. Configure your Auto Scaling group or EKS managed node group with a broad mix of instance types across multiple AZs so that if one Spot pool dries up, capacity comes from another. A mixed-instances policy that blends a small on-demand base with a large Spot portion gives you resilience and savings together.

# EKS managed node group with Spot and diversified types
eksctl create nodegroup \
  --cluster prod \
  --spot \
  --instance-types m6i.large,m5.large,m6a.large,m5a.large \
  --nodes-min 3 --nodes-max 20

Handle the two-minute interruption notice gracefully: drain the node, let Kubernetes reschedule pods, and make sure your app tolerates a pod moving. For CI, make jobs retryable. Done right, Spot interruptions become invisible to users.

Putting the Three Together

A well-optimized production fleet often looks like this: a right-sized on-demand or Savings Plan base covering the minimum capacity needed to stay up, with the elastic layer above it running on diversified Spot. Your Savings Plan discounts apply to the on-demand base automatically, and Spot handles the variable load at the deepest discount. Reserve pure on-demand only for the small slice of workloads that are both unpredictable and interruption-intolerant.

Guardrails and Ongoing Hygiene

• Tag everything so you can attribute cost to teams and services. You cannot optimize what you cannot attribute.
• Set budgets and anomaly alerts so a runaway job or a forgotten test cluster does not surprise you at month end.
• Review quarterly. Utilization drifts, new instance generations launch, and your Savings Plan coverage needs rebalancing.
• Do not over-commit. An unused Savings Plan is pure loss. Under-commit and buy more later rather than the reverse.

This is ongoing work, not a one-time cleanup, which is why cost optimization pairs well with continuous DevOps support. A structured AWS cost optimization engagement can run the full right-size, commit, and Spot migration, and a managed DevOps service keeps the fleet efficient as usage grows.

Reduce Your AWS Bill With Senior Engineers

InstaDevOps puts a senior DevOps engineer on retainer to right-size your fleet, buy the right commitments, and safely migrate interruptible workloads to Spot. Plans start at $2,999/mo (Startup) and $4,999/mo (Business), with work typically starting within about 48 hours. Book a free 15-minute call to find your savings.