10 Proven Strategies to Reduce AWS Costs by 50%

Most AWS accounts that have been running for more than a year carry a quiet layer of waste: instances sized for a load test that finished two years ago, volumes still billing after their instance was terminated, snapshots nobody remembers taking. None of it is dramatic on its own. Added up, it is usually a fifth to two fifths of the bill.

This guide walks through the techniques we apply, in the order we apply them. Each one is something you can do yourself with the AWS console and a few hours.

1Use Reserved Instances Strategically

Reserved Instances (RIs) are discounted up to 75% against On-Demand pricing, but many accounts either skip them entirely or buy the wrong shape of commitment.

The right approach

• Analyze historical usage: use AWS Cost Explorer to find workloads that have run consistently for a year or more
• Start with Standard RIs: buy 1 year Standard RIs for 60 to 70% of your baseline capacity, not all of it
• Convertible RIs for flexibility: pick Convertible when you expect the instance family to change
• Regional RIs for AZ flexibility: buy Regional to avoid locking a discount to one availability zone

2Use Spot Instances for Interruptible Work

Spot capacity is discounted up to 90% against On-Demand. The work is in deciding which workloads can absorb a two minute termination notice, and building the fault tolerance to prove it.

Where Spot fits

Implementation

# Example: Auto Scaling Group with Spot Instances
aws autoscaling create-launch-template \
  --launch-template-name spot-template \
  --launch-template-data '{
    "ImageId": "ami-12345678",
    "InstanceType": "m5.large",
    "InstanceMarketOptions": {
      "MarketType": "spot",
      "SpotOptions": {
        "SpotInstanceType": "one-time",
        "MaxPrice": "0.10"
      }
    }
  }'

3Right-Size Your Instances

Oversized instances are the single most common finding in an audit. Right-sizing means matching instance type and size to what the workload actually uses, rather than what somebody guessed at launch.

Step by step right-sizing

4Tune Auto Scaling

Auto Scaling is supposed to mean you pay for capacity only while you need it. In practice most groups are configured with a floor high enough that they never scale down, or a cooldown so long that they never scale up in time.

Predictive scaling configuration

{
  "AutoScalingGroupName": "web-servers-asg",
  "PolicyName": "predictive-scaling-policy",
  "PolicyType": "PredictiveScaling",
  "PredictiveScalingConfiguration": {
    "MetricSpecifications": [
      {
        "TargetValue": 70.0,
        "PredefinedMetricSpecification": {
          "PredefinedMetricType": "ASGAverageCPUUtilization"
        }
      }
    ],
    "Mode": "ForecastAndScale",
    "SchedulingBufferTime": 300,
    "MaxCapacityBreachBehavior": "IncreaseMaxCapacity"
  }
}

5Optimize Storage Costs

Storage creeps. EBS volumes outlive their instances, snapshot schedules run without a retention policy, and S3 buckets keep cold objects in Standard because nobody set a lifecycle rule.

Where to look first

Strategies 6 to 10: quick wins

Getting started

You do not have to do all ten. Start with the two that need no code changes: buy reserved capacity for the workloads you know are permanent, and resize the instances that are obviously too big. Spot and predictive scaling can wait until the easy money is banked.

If you would rather have someone find these savings in your account, our AWS cost audit does exactly that, at a fixed price.

One caveat: cost optimization is not a one-time project. Accounts drift. Set a monthly review, even a short one, or you will be reading this guide again next year.