gp2 to gp3 is the best-known case of a pattern all three providers share: a volume type that costs more for the performance it delivers than its successor. AWS puts gp3 at a 20 percent lower price per GiB than gp2, with a baseline of 3,000 IOPS and 125 MiB/s that gp2 reaches only at 1 TiB; Azure sells capacity and performance separately on Premium SSD v2 where Premium SSD ties both to the tier; Google Cloud sets pd-standard and pd-ssd against the balanced types and Hyperdisk. The saving comes from the lower price per GiB and from no longer buying performance through size. The fix belongs to the team that maintains the volumes and their templates.

Symptom

The bill names the volume type on every line. On AWS lineItem/UsageType separates EUC1-EBS:VolumeUsage.gp2 from EUC1-EBS:VolumeUsage.gp3 and EBS:VolumeUsage.piops (io1) from EBS:VolumeUsage.io2; the sum of gp2 GB-months against all SSD GB-months is the share. On Azure MeterSubCategory carries Premium SSD Managed Disks with tier names like P30 LRS Disk in MeterName, against Azure Premium SSD v2 with the rows Provisioned Capacity, Provisioned IOPS and Provisioned Throughput (MBps). On Google Cloud the SKUs read Storage PD Capacity for pd-standard, SSD backed PD Capacity for pd-ssd, Balanced PD Capacity for pd-balanced and Hyperdisk Balanced Capacity for Hyperdisk. The types of all three providers sit side by side in block, object and file storage; the levers in overview in storage optimisation.

Every volume line namesits type: UsageType,MeterSubCategory, the SKUThe type with a successor:gp2, io1, Premium SSDtiers such as P30,pd-standard and pd-ssdIts successor: gp3, io2,Premium SSD v2, the balancedtypes and HyperdiskThe share: gp2 GB-monthsagainst all SSD GB-months
The volume type sits in every line, so the share of the older type in all SSD GB-months is the symptom

How to detect it

AWS

The gp2 and io1 volumes with size and performance:

aws ec2 describe-volumes --filters Name=volume-type,Values=gp2,io1 \
  --query 'Volumes[].[VolumeId,VolumeType,Size,Iops,State,Attachments[0].InstanceId]' --output table

A gp2 volume under 1 TiB has less baseline performance than any gp3, at a higher price per GiB; a gp2 volume over 1 TiB that is that large only for the IOPS gets smaller on gp3 and buys the IOPS separately. Compute Optimizer rates volumes from 14 days of read and write metrics, classifies them "Not optimized" when another type, size or IOPS setting would be cheaper or faster, and sometimes recommends the new generation type even for optimized volumes:

aws compute-optimizer get-ebs-volume-recommendations \
  --query 'volumeRecommendations[].[volumeArn,currentConfiguration.volumeType,finding,volumeRecommendationOptions[0].configuration.volumeType,volumeRecommendationOptions[0].savingsOpportunity.estimatedMonthlySavings.value]' --output table

Trusted Advisor surfaces the Cost Optimization Hub's recommendations as "Amazon EBS cost optimization recommendations for volumes" (read on 2026-10-21). In billing data the gp2 share is the sum of EBS:VolumeUsage.gp2 GB-months against EBS:VolumeUsage.gp2 plus .gp3 (AWS Cost and Usage Report).

Azure

The disks by type, with tier and VM:

az disk list --query "[].{name:name, sku:sku.name, tier:tier, gb:diskSizeGb, iops:diskIopsReadWrite, vm:managedBy}" -o table

Candidates are Premium SSD data disks (Premium_LRS) whose tier is larger than the size in use, because Azure rounds up to the next tier, and Standard HDD disks (Standard_LRS) with many transactions; Azure Advisor recommends for the second group, under "Standard SSD disks billing caps", the move to Standard SSD with its capped transactions. Premium SSD v2 bills capacity per GiB and hour and IOPS and throughput separately above that, with 3,000 IOPS and 125 MB/s at no extra charge, for data disks only. In the cost export the candidate is a disks/ resource with Premium SSD Managed Disks in MeterSubCategory (Azure cost exports).

Google Cloud

The disks by type:

gcloud compute disks list --format="table(name,zone.basename(),type.basename(),sizeGb,provisionedIops,users.list())"

Candidates are pd-standard disks used as boot or database disks and pd-ssd disks whose performance a pd-balanced or a hyperdisk-balanced delivers more cheaply. Google has no recommender for the disk type; the metrics compute.googleapis.com/instance/disk/read_ops_count and write_ops_count per disk against the type's limit are the evidence. In the billing export the share is the sum of usage.amount per capacity SKU (Google Cloud billing export).

How to fix it

  1. AWS: gp2 to gp3 is an online change without detaching and without a restart, through Elastic Volumes; without IOPS and throughput given, EBS carries over the gp2 volume's performance or the gp3 baseline, whichever is higher (modify a volume with Elastic Volumes):

    aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --volume-type gp3 --dry-run
aws ec2 describe-volumes-modifications --volume-ids vol-0123456789abcdef0

    A volume may be modified up to four times in 24 hours, each change only once the previous one has completed; io1 to io2 takes the same route with --volume-type io2.

  2. Azure: Premium SSD, Standard SSD and Standard HDD change with az disk update --sku StandardSSD_LRS --name <disk> --resource-group <rg> with the VM deallocated, at most twice a day; a data disk's move to Premium SSD v2 takes the same route with --sku PremiumV2_LRS, not for OS disks, without host caching, bursting and double encryption, and with Azure Backup active only after the move to the enhanced policy (convert disk types). Check the tier before the move: a 200 GiB disk as a P15 instead of a P20 is the same lever without a type change.

  3. Google Cloud: a Persistent Disk is not converted but replaced: snapshot, new disk of the wanted type from the snapshot, attach, delete the old disk (change the disk type); with Hyperdisk as the target there is gcloud compute disks convert <disk> --zone=<zone> --target-disk-type=hyperdisk-balanced. Neither route has a dry run; the list from the detection and a snapshot beforehand stand in for it.

  4. Change the templates: block device mappings in launch templates and AMIs, disk SKUs in VM definitions and scale sets, disk types in instance templates and storage classes, so new volumes come up in the right type.

The new price applies from the start of the change, on AWS from the start of the modification.

yes: AWS online, Azurewith the VM deallocatedno: a Google CloudPersistent DiskThe list from the detection;AWS checks with dry run,the others with a snapshotbeforehandDoes the type changein place?Modify the volume orupdate the disk SKU;on Azure check the tierfirstSnapshot, new disk of thewanted type, attach,delete the old diskChange the templates so newvolumes come up inthe right typeThe new price applies fromthe start of the change
AWS and Azure change the type in place, Google Cloud replaces the disk, and the template keeps new volumes on the right type

Risks and side effects

  • gp3 has no burst: a gp2 volume that regularly burst to 3,000 IOPS needs the baseline on gp3 that covers exactly that; one with more than 3,000 IOPS or more than 125 MiB/s needs the figures given at the change, or performance drops.
  • A volume modification on AWS takes minutes to hours, up to six at 1 TiB, with reduced performance while optimising; a database volume changes in the maintenance window.
  • Premium SSD v2 and Hyperdisk cannot serve as OS disks and are not available in every region and zone; a disk being replaced briefly has two copies and needs room in the quota.
  • Reservations for Premium SSD tiers on Azure apply per SKU; a disk that moves to v2 leaves the reservation (Azure reservations).
  • Standard HDD to Standard SSD lowers transaction cost only where transactions were the problem; a disk with little I/O gets more expensive with the move.

How to verify the saving

Before: per volume, the GB-months and the amount of the old type in the last full month, on AWS EBS:VolumeUsage.gp2, on Azure the tier meter, on Google Cloud the capacity SKU, and beside it the performance the volume used. After: the same volume on the new type in the first full month, with an equal or smaller size and the new amount, plus the lines for separately bought IOPS and throughput, which the proof nets off. The difference from the recommender or your own price list is the estimate, the team's release makes it accepted, the change implemented, and the following month's invoice realises it in the pattern of estimated, accepted, implemented, verified. The old type's share of all GB-months is the figure for the estate.

Sources

Read on 2026-10-21. General Purpose SSD volumes, Modify a volume with Elastic Volumes, Compute Optimizer EBS recommendations, Trusted Advisor cost optimization checks, Azure, convert disk types, Azure disk types, Azure Advisor cost recommendations, Google Cloud, change the disk type, gcloud compute disks convert.