Amazon EBS – Consider Upgrading io1 Volumes to io2

The Amazon EBS io1-to-io2 policy flags Amazon Elastic Block Store (Amazon EBS) volumes on the older io1 type and recommends io2 instead. For volumes up to 32,000 IOPS, io2 costs the same as io1. It adds 99.999% durability and up to 1,000 provisioned IOPS per GiB, versus 50 on io1. Above 32,000 IOPS, io2 is cheaper than io1, so the change never raises the bill at AWS list prices.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon EBS io1 and io2 volumes use the same billing model: a charge per provisioned GB-month plus a charge per provisioned IOPS-month. In US East (N. Virginia), both list storage at $0.125 per GB-month and IOPS at $0.065 per IOPS-month for the first 32,000 IOPS.

The pricing splits above 32,000 IOPS. Amazon EBS io2 charges about $0.046 per IOPS-month for IOPS 32,001 to 64,000, while io1 keeps charging $0.065 for every IOPS. High-IOPS io1 volumes pay a premium that io2 removes.

The second cost lever is the IOPS-to-storage ratio. Amazon EBS io1 allows at most 50 provisioned IOPS per GiB, so a volume that needs 20,000 IOPS must be at least 400 GiB, even if it stores 100 GiB of data. Amazon EBS io2 allows up to 1,000 IOPS per GiB, so storage can match the data instead of the IOPS target.

This policy is a no-regret change for most io1 volumes. The price either stays flat or drops, and durability improves by two orders of magnitude.

Potential Savings

For Amazon EBS io1 volumes at or below 32,000 IOPS, the io1-to-io2 upgrade is cost-neutral at list prices. The return is risk reduction: io2 is designed for an annual failure rate no higher than 0.001%, compared with up to 0.2% for io1.

For Amazon EBS io1 volumes above 32,000 IOPS, the saving is direct. A 1,280 GiB io1 volume at 64,000 IOPS costs about $4,320 per month in US East (N. Virginia). The same volume on io2 costs about $3,710 per month, a reduction of roughly 14%.

Volumes that were oversized only to satisfy the io1 50:1 ratio can also shrink after moving to io2. Amazon EBS volumes cannot be reduced in place, so that saving requires a data migration to a new, smaller io2 volume.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon EBS volume provisioned as io1 for a database, and the corrected io2 configuration.

Non-compliant configuration: Amazon EBS volume on io1

resource "aws_ebs_volume" "db_data" {
  availability_zone = "us-east-1a"
  size              = 1280
  type              = "io1"
  iops              = 64000
  encrypted         = true

  tags = {
    Name = "db-data"
  }
}

resource "aws_ebs_volume" "db_data" {
  availability_zone = "us-east-1a"
  size              = 1280
  type              = "io1"
  iops              = 64000
  encrypted         = true

  tags = {
    Name = "db-data"
  }
}

resource "aws_ebs_volume" "db_data" {
  availability_zone = "us-east-1a"
  size              = 1280
  type              = "io1"
  iops              = 64000
  encrypted         = true

  tags = {
    Name = "db-data"
  }
}

This io1 volume pays $0.065 for every one of its 64,000 provisioned IOPS. This configuration increases cost without improving performance, and it carries the lower io1 durability rating.

Compliant configuration: Amazon EBS volume on io2

resource "aws_ebs_volume" "db_data" {
  availability_zone = "us-east-1a"
  size              = 1280
  type              = "io2"
  iops              = 64000
  encrypted         = true

  tags = {
    Name = "db-data"
  }
}

resource "aws_ebs_volume" "db_data" {
  availability_zone = "us-east-1a"
  size              = 1280
  type              = "io2"
  iops              = 64000
  encrypted         = true

  tags = {
    Name = "db-data"
  }
}

resource "aws_ebs_volume" "db_data" {
  availability_zone = "us-east-1a"
  size              = 1280
  type              = "io2"
  iops              = 64000
  encrypted         = true

  tags = {
    Name = "db-data"
  }
}

Only the type attribute changes. The iops value carries over unchanged, because io2 accepts any IOPS value that was valid on io1.

The throughput attribute does not apply here. In the AWS Terraform provider, throughput is only valid for gp3, and Amazon EBS io1 and io2 throughput scales with provisioned IOPS.

Step-by-Step Fix Instructions

1. Search Terraform configuration for every aws_ebs_volume resource with type = "io1".

2. Check other places io1 can appear: the volume_type argument in root_block_device and ebs_block_deviceblocks on aws_instance, and in block_device_mappings on aws_launch_template.

3. For volumes above 32,000 IOPS, confirm the attached instance is built on the AWS Nitro System. On other instance types, both io1 and io2 deliver at most 32,000 IOPS.

4. Change type from "io1" to "io2". Leave iops, size, and multi_attach_enabled as they are.

5. Run terraform plan and confirm the change on aws_ebs_volume is an in-place update, not a replacement. Amazon EBS Elastic Volumes changes the volume type without detaching the volume.

6. Apply during a low-traffic window. Watch the volume move through the modifying and optimizing states to completed before making any further change to it.

7. Add Infracost to CI/CD so any new io1 volume is flagged in the pull request before it merges.

Best Practices

• Set type = "io2" as the Provisioned IOPS default in shared Terraform modules, and reject io1 in module validation.

• Migrate non-production volumes first, then production volumes in batches.

• Before moving to io2, check whether the volume needs Provisioned IOPS at all. An io1 volume that runs below 16,000 IOPS without Multi-Attach may fit gp3 at a lower price.

• This policy does not reduce cost for io1 volumes at or below 32,000 IOPS. For those volumes, the justification is durability and headroom, not savings.

Tools and Scripts

How does Infracost detect io1 volumes automatically?

The Amazon EBS io1-to-io2 policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks Amazon EBS volumes in each pull request and flags io1 volumes in the PR comment, with the file and line to change.

This catches an io1 volume before it exists, when the fix is a one-word change in the same pull request. Infracost also scans connected repositories for existing io1 volumes, so FinOps and platform teams can burn down that backlog and track progress on a burndown chart.

Teams can set the policy to warn engineers or to block pull requests that fail it, depending on how strictly they want to retire io1.

To list io1 volumes in the current region with the AWS CLI:

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=io1 \
  --query "Volumes[].[VolumeId,Size,Iops,MultiAttachEnabled]" \
  --output

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=io1 \
  --query "Volumes[].[VolumeId,Size,Iops,MultiAttachEnabled]" \
  --output

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=io1 \
  --query "Volumes[].[VolumeId,Size,Iops,MultiAttachEnabled]" \
  --output

To migrate one volume in place outside Terraform:

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type

If the volume is managed by Terraform, update type in code as well. Otherwise Terraform will report drift and the next terraform apply will try to change the volume back to io1.

Examples of Impact

Illustrative example: a high-IOPS database volume. A platform team runs an Amazon EBS io1 volume of 1,280 GiB at 64,000 IOPS for a transactional database. On io1, the volume costs about $4,320 per month. On io2 with identical settings, it costs about $3,710, saving roughly $7,300 per year on one volume.

Illustrative example: a fleet of mid-size volumes. A team runs 30 Amazon EBS io1 volumes of 1,000 GiB at 5,000 IOPS each. Each costs about $450 per month on io1 and the same on io2. Moving the fleet changes nothing on the bill, but the designed annual failure rate drops from up to 0.2% to 0.001% per volume.

The higher a volume's IOPS above 32,000, the larger the share of its bill this policy removes.

(These are illustrative scenarios using published US East (N. Virginia) list prices, not specific customer accounts.)

Considerations and Caveats

The Amazon EBS io1-to-io2 upgrade is low risk, but a few constraints apply.

• Nitro requirement for high IOPS: io2 volumes reach up to 256,000 IOPS only on Nitro-based instances. Other instance types top out at 32,000 IOPS on either io1 or io2.

• One change at a time: Elastic Volumes processes one modification per volume at a time. Wait for completedbefore resizing or retuning the same volume.

• Multi-Attach: Multi-Attach volumes can change between io1 and io2 while attached. Windows instances support Multi-Attach only on io2.

• Cost-neutral below 32,000 IOPS: The upgrade improves durability at the same price but does not lower the bill for most io1 volumes.

• Provider-specific: This policy targets Amazon EBS through the aws_ebs_volume resource. Azure managed disks and Google Cloud persistent disks use different tiers and attribute names.

Related Policies and Concepts

• Amazon EBS - consider updating io1/io2 volumes to gp3: the companion Block Storage policy for Provisioned IOPS volumes that would run at a lower cost on General Purpose SSD.

• Amazon EBS - consider upgrading gp2 volumes to gp3: the same generational-upgrade logic applied to General Purpose Amazon EBS volumes.

• RDS - consider upgrading gp2 storage type to gp3: the storage-class discipline applied to Amazon RDS instance storage.

• EMR - consider upgrading gp2 storage type to gp3: the storage-class discipline applied to Amazon EMR cluster volumes.

• Azure Disk Storage - consider updating Premium SSD disk to v2: the Azure equivalent of moving to a newer disk generation for better price performance.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon EBS io1-to-io2 policy is supported in Infracost and available in the free trial. Infracost flags io1 volumes in pull requests, so the team can switch to io2 before the volume is created.

Can this policy be customized?

Yes. Teams can configure how Infracost enforces the Amazon EBS io1-to-io2 policy. For example, a finding can warn engineers or block the pull request.

Does Infracost automatically fix violations?

Infracost reports Amazon EBS io1 volumes in the pull request, with the file and line to change. The team then changes the volume type from io1 to io2 in Terraform and applies it.

Is this policy cloud-agnostic?

No. The Amazon EBS io1-to-io2 policy targets AWS through the aws_ebs_volume Terraform resource. Azure managed disks and Google Cloud persistent disks have their own performance tiers with different resource and attribute names.

Does changing an Amazon EBS volume from io1 to io2 require downtime?

No. Amazon EBS Elastic Volumes changes an io1 volume to io2 in place, without detaching the volume or stopping the instance. The Amazon EBS volume stays in use while it moves through the modifying and optimizing states.

Does upgrading an Amazon EBS volume from io1 to io2 cost more?

No. At AWS list prices, Amazon EBS io2 storage and the first 32,000 provisioned IOPS cost the same as io1. Provisioned IOPS above 32,000 cost less on io2, so the io1-to-io2 upgrade either keeps the bill flat or lowers it.

How often should I review Amazon EBS io1 volumes?

Teams running Infracost in CI/CD get an Amazon EBS volume type check on every pull request that touches an Amazon EBS volume. For existing io1 volumes, a quarterly review is a reasonable cadence until the io1 backlog reaches zero.