Why is Your EBS Almost as Expensive as EC2?

Open your AWS bill. Find the line that says “EC2-Other.” That’s where EBS hides.

AWS buries your block storage costs inside the EC2 section of Cost Explorer, lumped together with NAT Gateway, data transfer, and Elastic IP charges under a meaningless label.

EBS is usually the biggest piece. According to the Vantage AWS Cost Leaderboard, EBS is the fifth most expensive AWS service across their customer base, behind only EC2 compute, S3, RDS, and SageMaker. And it doesn’t even get its own line.

The Ratio

Here’s a quick diagnostic I use when reviewing AWS costs: divide your EBS spend by your EC2 compute spend. Call it your EBS ratio.

For stateless workloads, this number should be well under 0.2. A web server, an application backend, a batch processing job - these are compute-heavy by nature. The volumes attached to them are small, and if you’re treating your instances as disposable (as you almost always should), you shouldn’t have many snapshots either.

A t3.medium running a web app costs about $30/month. Attach a 20GB gp3 root volume and you’re paying $1.60/month for storage. That’s a ratio of 0.05. The storage cost is a rounding error on the compute cost, which is exactly what you’d expect for a stateless server.

Now consider a self-managed database. An r6g.xlarge costs about $147/month. A 500GB gp3 volume takes $40/month. That ratio is 0.27, and that’s before snapshots.

This is where it gets expensive. Say you take daily snapshots with 30-day retention (a common AWS Backup lifecycle policy). The first snapshot stores the full 500GB: that’s $25/month at $0.05/GB. Each subsequent snapshot is incremental: it only stores blocks that changed since the last one. Assuming a 3% daily change rate, each incremental snapshot adds about 15GB. In addition to the $25 for the initial snapshot, 29 incremental snapshots take another $22/month.

The snapshots (totalling $47/month) cost more than the base volume. Your total EBS bill is now $87/month against $147 in compute. The ratio is 0.59. For a single instance. Meanwhile, 500GB costs $11.50/month on S3.

The key insight: snapshots of large volumes are what push the ratio from almost reasonable to alarming.

When a High Ratio Makes Sense

A high ratio isn’t always waste. If you’re using EC2 to run a self-managed database, you’re not really paying for compute anymore. You’re paying for storage that happens to have a compute layer in front of it. A 2TB volume on an r6g.2xlarge with daily snapshots and 30-day retention pushes the ratio to 1.18. That’s $347/month in EBS against $294 in compute. EBS costs more than the instance itself. That’s not waste. That’s the cost of treating EC2 as a database host. The ratio reflects the reality that most of your spending is on storage, not compute.

The red flag is when the ratio is high and nobody can explain why.

How to Calculate the Ratio

Cost Explorer doesn’t separate EBS from the rest of “EC2-Other” by default. But you can get the numbers with the Cost Explorer API.

Two CLI calls:

# EC2 compute costs for March 2026
aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-04-01 \
  --granularity MONTHLY \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["Amazon Elastic Compute Cloud - Compute"]
    }
  }' \
  --metrics BlendedCost

# EBS costs (volumes + snapshots)
aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-04-01 \
  --granularity MONTHLY \
  --filter '{
    "Dimensions": {
      "Key": "USAGE_TYPE_GROUP",
      "Values": [
        "EC2: EBS - SSD(gp2)",
        "EC2: EBS - SSD(gp3)",
        "EC2: EBS - SSD(io1)",
        "EC2: EBS - SSD(io2)",
        "EC2: EBS - Snapshots",
        "EC2: EBS - Magnetic",
        "EC2: EBS - Throughput Optimized HDD",
        "EC2: EBS - Cold HDD",
        "EC2: EBS - System Operation (Provisioned IOPS)"
      ]
    }
  }' \
  --metrics BlendedCost

Each Cost Explorer API call costs $0.01. Two cents to know whether you have a problem.

Taming the Ratio

If your ratio is higher than your workloads justify, here’s what to do.

Upgrade Your Volume Types

This is the easiest win. gp2 volumes still exist in a lot of environments, and gp3 is cheaper at baseline while giving you more control over IOPS and throughput. If you’re on io1, check whether io2 Block Express makes sense. These are generation upgrades: better performance at lower cost, and the migration is straightforward.

Audit Your AMIs

Every AMI you create generates EBS snapshots underneath it. People create AMIs as golden images, as pre-deployment checkpoints, as “just in case” saves before risky changes. Then the AMI goes stale but nobody deregisters it, because nobody wants to be the one who deleted the backup they needed. The snapshots underneath persist for as long as the AMI exists.

Go through your AMIs. Which are golden images, and which are forgotten backups?

Separate Data from Disk Images

A 2TB snapshot of a database server doesn’t contain 2TB of irreplaceable data. It contains an operating system, installed packages, configuration files, temp directories, and somewhere in there, the actual data you care about. That data might be 50GB. It might be 500GB. But it’s almost certainly not 2TB.

If you need to retain the data in that snapshot, extract it and put it in S3. Standard S3 costs $0.023/GB, less than half of EBS snapshot pricing at $0.05/GB. If the data is archival, S3 Glacier drops to $0.004/GB. You’d be paying 92% less to store the same information, and it would be in a format you can actually query and manage.

Rightsize Your Volumes

Volumes are often provisioned for peak capacity and never adjusted downward. A 500GB volume running at 12% utilization is 440GB of paid-for storage doing nothing. Check CloudWatch’s VolumeReadBytes and VolumeWriteBytes metrics. If a volume has been sitting well below its provisioned size for months, shrink it. EBS doesn’t support in-place volume reduction, so you’ll need to snapshot, create a smaller volume, and copy the data over. But in some cases, the ongoing savings make it worth the one-time effort.

Delete Unattached Volumes

When an EC2 instance is terminated, its EBS volumes don’t necessarily go with it. If DeleteOnTermination is set to false (which is the default for non-root volumes), the volume persists after the instance is gone. These orphaned volumes sit in your account at full price, attached to nothing. Check for volumes in the available state. If nobody can explain why they exist, they’re candidates for deletion or snapshot-and-delete.

Set Up Lifecycle Policies

This is the one that prevents the problem from coming back. To save money on snapshots, make snapshot deletion the default action. AWS Data Lifecycle Manager and AWS Backup both support automated retention policies. Define how many snapshots you want to keep and how long, and the system will clean up after itself.

The Takeaway

Divide your EBS costs by your EC2 costs. If the number is under 0.2, you’re in good shape. If it’s between 0.2 and 0.4, make sure you understand why. Large volumes and snapshot retention for databases can justify it. But if it’s above 0.4 and you can’t explain it, you’re paying for storage you’ve forgotten about.