How to save money on AWS EBS Volumes?

Problem Statement & Impact

Cloud infrastructure expenses can rapidly escalate when block storage resources are mismanaged, over-provisioned, or left orphaned after compute instances are terminated. Amazon Elastic Block Store (EBS) provides persistent block-level storage volumes for use with Amazon EC2 instances. However, because EBS volumes persist independently of the lifecycle of the EC2 instances they are attached to, a common operational failure mode involves leaving unattached volumes—or volumes bound to terminated servers—active indefinitely. These orphaned volumes continue to accrue hourly billing charges while providing zero utility to the organization.

In addition to orphaned resources, cloud administrators frequently commit architectural errors by over-provisioning volume sizes and selecting inappropriate performance tiers. For instance, provisioning high-performance SSD tiers (such as io1 or io2) for workloads that require only baseline input/output operations per second (IOPS) drastically increases infrastructure overhead. Furthermore, unmonitored snapshot accumulation leads to silent financial leakage. EBS snapshots are incremental, meaning they only save changed blocks, but long-term retention policies without automated pruning cause storage costs to compound exponentially over months and years.

The financial and security consequences of failing to optimize EBS usage include bloated monthly cloud invoices, degraded operational visibility, and increased attack surfaces due to unmonitored snapshot copies containing sensitive database dumps or application secrets. Establishing a programmatic approach to EBS lifecycle management is mandatory to maintain predictable cloud operating expenditures (OpEx) while ensuring compliance with modern FinOps and security hardening standards.

Root Cause Analysis & Architecture

To understand why EBS costs spiral out of control, one must examine how the AWS billing engine calculates storage charges and how virtualization drivers handle block storage allocation. EBS volumes are provisioned in fixed Gigabyte (GB) increments per month, alongside separate charges for provisioned IOPS, throughput capacity, and cross-Availability Zone (AZ) data transfers. Unlike object storage such as Amazon S3, which scales dynamically based on actual object size, EBS volumes charge for the *allocated* capacity rather than the *used* capacity. If an administrator provisions a 500 GB gp3 volume but the underlying filesystem only utilizes 45 GB, the organization is billed for the entire 500 GB allocation.

From an architectural standpoint, legacy volume types such as gp2 rely on a burst bucket credit system. When a gp2 volume’s baseline performance (3 IOPS per GB up to 250 IOPS) is exhausted, the volume draws from accumulated burst credits. When those credits reach zero, I/O latency spikes dramatically. To compensate for this latency ceiling, engineers frequently over-provision gp2 volumes to higher capacities purely to gain higher baseline IOPS. AWS introduced gp3 to decouple storage capacity from IOPS and throughput, allowing administrators to provision 3,000 baseline IOPS and 125 MB/s throughput on a small 100 GB volume without paying for excessive storage capacity.

Snapshot mechanics also contribute significantly to cost overruns. When an EBS snapshot is taken, a pointer points to the blocks on the underlying volume. As blocks are modified or deleted, the older blocks are retained in the snapshot storage tier. If a database undergoes massive write operations daily, incremental snapshots capture large volumes of changed blocks. Without an automated lifecycle management policy (such as Amazon Data Lifecycle Manager), these snapshots persist indefinitely, creating a shadow storage repository that often surpasses the size of the primary production volumes.

Step-by-Step Implementation & Remediation Guide

To systematically reduce AWS EBS expenditures, administrators must execute a four-phase remediation workflow: identifying orphaned volumes, converting legacy gp2 volumes to gp3, right-sizing storage capacities using Elastic Volumes, and automating snapshot retention policies.

Phase 1: Identify and Terminate Orphaned EBS Volumes

Orphaned volumes are those in an available state (not attached to any running EC2 instance). Use the AWS CLI to query and list all unattached volumes across your target region.

aws ec2 describe-volumes \
    --filters Name=status,Values=available \
    --query "Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}" \
    --output table

Before deleting any volume identified in the output above, create a final archival snapshot to ensure no critical data is permanently lost:

aws ec2 create-snapshot \
    --volume-id vol-0123456789abcdef0 \
    --description "Archival snapshot of orphaned volume prior to deletion"

Once the snapshot is verified, delete the orphaned volume to immediately halt recurring storage charges:

aws ec2 delete-volume --volume-id vol-0123456789abcdef0

Phase 2: Migrate Legacy gp2 Volumes to gp3

Migrating from gp2 to gp3 reduces baseline costs by approximately 20% while providing independent control over IOPS and throughput. Execute the following CLI command to modify a volume in-place without downtime:

aws ec2 modify-volume \
    --volume-id vol-0987654321fedcba0 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

To verify the migration progress, check the volume modification status:

aws ec2 describe-volumes-modifications \
    --volume-ids vol-0987654321fedcba0 \
    --query "VolumesModifications[*].{State:ModificationState,Progress:Progress}" \
    --output table

Phase 3: Resize Volumes Dynamically Using AWS Elastic Volumes

When monitoring reveals that a volume is over-provisioned, you can reduce its size (if supported by the underlying filesystem) or increase it dynamically. To expand a volume to 200 GB:

aws ec2 modify-volume \
    --volume-id vol-11223344556bbaacc \
    --size 200

After the AWS modification completes, log into the EC2 instance via SSH and expand the underlying operating system filesystem to utilize the new space. For an ext4 filesystem, execute:

sudo growpart /dev/xvdf 1
sudo resize2fs /dev/xvdf1

For an XFS filesystem, use the following command instead:

sudo xfs_growd -d /

Phase 4: Automate Snapshot Lifecycle Policies

Prevent snapshot bloat by configuring an AWS Data Lifecycle Manager (DLM) policy via JSON configuration. Create a file named dlm-policy.json:

{
  "Description": "SiteSuraksha Daily EBS Snapshot Policy",
  "State": "ENABLED",
  "ExecutionRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSDataLifecycleManagerDefaultRole",
  "PolicyDetails": {
    "ResourceTypes": [
      "VOLUME"
    ],
    "TargetTags": [
      {
        "Key": "Backup",
        "Value": "True"
      }
    ],
    "Schedules": [
      {
        "Name": "DailyBackups",
        "CopyTags": false,
        "CreateRule": {
          "Interval": 24,
          "IntervalUnit": "HOURS",
          "Times": [
            "02:00"
          ]
        },
        "RetainRule": {
          "Count": 7
        }
      }
    ]
  }
}

Apply this policy to your AWS account using the CLI:

aws dlm create-lifecycle-policy --cli-input-json file://dlm-policy.json

Production Hardening & Edge Cases

Implementing block storage optimizations in production environments requires careful consideration of performance metrics, caching interactions, and operational edge cases. Directly modifying volume types or resizing partitions on heavily loaded database servers can introduce I/O latency spikes that impact active transaction logs. Always execute storage modifications during established maintenance windows and verify that the target EC2 instance type supports Elastic Volume modifications.

When transitioning from gp2 to gp3, note that while gp3 provides a lower baseline cost per gigabyte, aggressive manual provisioning of IOPS beyond the free tier (3,000 IOPS included) and throughput beyond 125 MB/s incurs additional per-unit charges. Administrators must cross-reference application performance monitoring (APM) data—such as CloudWatch metrics for VolumeQueueLength and BurstBalance—before tuning IOPS parameters. If VolumeQueueLength consistently remains below 1, the workload does not require high provisioned IOPS, and dropping down to standard gp3 baseline parameters is safe.

Another critical edge case involves encrypted volumes. AWS KMS customer managed keys (CMKs) must remain active during volume modifications and snapshot rotations. If a KMS key is scheduled for deletion or loses IAM permissions, volume resizing operations will fail mid-execution, potentially locking the block device and requiring manual intervention from AWS Support. Validate IAM role policies for automated tooling to ensure persistent access to encryption keys across all target regions.

Diagnostic Verification & Checklist

Post-implementation verification ensures that storage optimizations have successfully lowered cloud expenditure without compromising application resilience or data integrity. Utilize the verification matrix below to validate your EBS optimization lifecycle.