AWS publishes a rich menu of compute pricing options, and picking the wrong one consistently is one of the primary causes of unexpectedly high cloud bills. On-Demand is the default and the most expensive. A disciplined commitment and right-sizing strategy typically achieves 40–70% savings over On-Demand baselines.

Understanding the Pricing Hierarchy

  • On-Demand: No commitment, no discount. Pay per second (Linux) or per hour (Windows). Correct for unpredictable or short-duration workloads.
  • Reserved Instances (RIs): 1 or 3-year commitment to a specific instance family, size, region, and tenancy. Up to 72% discount over On-Demand for all-upfront, 3-year Standard RI. Can be sold on the RI Marketplace if no longer needed (Standard RIs only).
  • Savings Plans: Commitment to a $/hour spend rate, not a specific instance type. Compute Savings Plans apply across EC2, Lambda, and Fargate across any instance family, size, region, and OS. More flexible than RIs; typically 66% discount at 3-year all-upfront.
  • Spot Instances: Spare AWS capacity at up to 90% discount. AWS can reclaim with 2-minute notice. Correct for stateless, fault-tolerant workloads: batch processing, rendering, training jobs, CI/CD runners.

Reserved Instances vs Savings Plans: Which to Choose

The choice depends on how predictable your instance type and region choices are:

  • If your workloads are stable and you're confident you'll stay on the same instance family in the same region: Standard RIs offer the highest discount. Lock in specific instance type for maximum savings.
  • If your workloads are stable in spend but you anticipate instance family changes, region migrations, or you want coverage across Lambda and Fargate: Compute Savings Plans provide flexibility with a slightly lower maximum discount.
  • For RDS, ElastiCache, OpenSearch, and Redshift: purchase Reserved Nodes (separate from EC2 RIs) — these have no Savings Plan equivalent.

In practice: most organisations use Compute Savings Plans for EC2 baseline coverage and supplement with On-Demand for burst capacity. The Savings Plans console shows commitment recommendations based on your trailing 7, 14, 30, or 60-day usage.

Right-Sizing: Stop Paying for Unused Capacity

Right-sizing is the process of matching instance size to actual utilisation. AWS Compute Optimizer analyses 14 days of CloudWatch metrics and recommends over-provisioned, under-provisioned, or optimally sized instances.

Key metrics for the right-sizing decision:

  • CPU utilisation: If p99 (99th percentile) CPU is below 20% over the trailing 14 days, the instance is a right-sizing candidate. Don't right-size based on average CPU — a web server might average 5% CPU but need headroom for traffic spikes.
  • Memory utilisation: CloudWatch does not collect memory metrics by default. Install the CloudWatch Agent on EC2 instances to publish memory utilisation. This is often the metric that reveals true over-provisioning — an m5.xlarge (16 GB) running a Java app that never exceeds 4 GB is a clear m5.large or even m5.medium candidate.
  • Network throughput: Check if the instance type's network bandwidth limit is ever being hit. If so, right-sizing down may impair performance even if CPU is low.

The right-sizing process: identify candidates → test in non-prod → measure performance → commit. Automate with AWS Systems Manager for rolling restarts during maintenance windows.

Spot Strategy for Fault-Tolerant Workloads

A Spot Instance interruption is a 2-minute notice, not an immediate termination. Applications that handle SIGTERM gracefully — checkpoint state, drain in-flight requests, push incomplete work back to the queue — are candidates for Spot.

Spot diversification: never run critical Spot workloads on a single instance type in a single AZ. Use EC2 Auto Scaling with capacity-optimized allocation strategy and specify 6–10 instance types across 3 AZs. The Auto Scaling group will draw from the pools with the most available capacity, minimising interruption frequency.

Mixed instance groups: combine On-Demand base capacity (to absorb interruptions) with Spot for burst capacity. A typical pattern: 20% On-Demand base, 80% Spot. The On-Demand base keeps your minimum viable cluster alive during a Spot capacity crunch; Spot handles scale-out.

FinOps Tooling and Tagging

Tagging is the foundation of cost attribution. Without mandatory tags (cost-centre, team, environment, application), AWS Cost Explorer cannot break down costs by business unit. Enforce tags via SCP: deny resource creation if mandatory tags are absent.

Cost anomaly detection: enable AWS Cost Anomaly Detection with SNS alerts. It uses ML to detect spend patterns that deviate from your baseline and alerts within 24 hours — catching runaway S3 transfer costs, forgotten large EC2 instances, or Lambda invocation explosions before they become large charges.

Sripadatech provides FinOps consulting and ongoing cloud cost management for AWS environments. Contact us to start a cost optimisation engagement.