Overview
In any mature AWS environment, Amazon Elastic Block Store (EBS) volumes represent a significant portion of monthly cloud spend. For years, the General Purpose SSD (gp2) volume type was the default choice for balancing cost and performance for EC2 instances. However, with the introduction of the newer General Purpose SSD (gp3) volume type, continuing to use gp2 represents a critical missed opportunity for cost optimization.
The core issue with the legacy gp2 model is its coupled architecture: performance (measured in IOPS) is directly tied to provisioned storage capacity. This forces engineering teams to over-provision storage simply to achieve necessary performance levels, leading to significant waste.
The migration from gp2 to gp3 resolves this inefficiency. By decoupling storage size from performance metrics like IOPS and throughput, gp3 allows organizations to provision and pay for only the resources they actually need. This strategic shift not only reduces direct storage costs but also introduces a more transparent and flexible model for managing cloud resources, aligning perfectly with modern FinOps principles.
Why It Matters for FinOps
From a FinOps perspective, the gp2 to gp3 migration is a high-impact initiative with low operational risk. The business case is built on tangible financial and governance improvements. The most direct benefit is an immediate storage cost reduction of approximately 20% per gigabyte, which can translate into substantial savings at scale.
Beyond direct savings, this migration eliminates the hidden “performance tax” inherent in gp2. Teams no longer need to inflate storage requests to prevent application latency, which curbs storage sprawl and improves the accuracy of unit economics. Because gp3 breaks out costs for storage, IOPS, and throughput as separate line items (when provisioned above the baseline), it provides greater visibility for showback and chargeback models. This allows FinOps teams to better understand whether an application’s cost drivers are related to storage capacity or performance demands, enabling more sophisticated financial governance.
What Counts as “Idle” in This Article
In the context of this optimization, “idle” refers not to an unused resource but to financial inefficiency. A gp2 volume is considered a candidate for optimization when it represents wasted potential—paying a premium for a legacy service when a more cost-effective and flexible alternative exists.
The primary signal for this type of waste is simply the existence of a volume with the type gp2. Further qualification often involves ensuring the volume is stable and not part of a short-lived or transient workload. For example, volumes that have been running for more than a week and are not attached to highly managed services are prime candidates. The goal is to convert this inefficient spend into direct savings without impacting the performance or availability of the underlying application.
Common Scenarios
Scenario 1: Legacy “Lift and Shift” Workloads
Many organizations have hundreds of EC2 instances running standard workloads like web servers, development environments, and internal applications. These instances were often created years ago using gp2 as the default. Migrating these volumes to gp3 provides an immediate 20% cost reduction on storage, as their performance needs typically fall well within the generous baseline included with gp3.
Scenario 2: Performance-Intensive Databases
Databases often require high IOPS for transaction processing but may not store terabytes of data. With gp2, a team might provision a 2 TB volume solely to get 6,000 IOPS, while only using 200 GB of actual space. Migrating to a gp3 volume allows them to provision a 200 GB volume and separately purchase the 6,000 IOPS, drastically cutting costs by eliminating payment for unused storage.
Scenario 3: System Boot Volumes
The root boot volumes for EC2 instances are perfect candidates for this optimization. They rarely require high sustained performance and are typically small. Converting these volumes from gp2 to gp3 is a low-risk action that captures the 20% storage savings across a large fleet of instances with virtually no need for performance tuning, as their activity is almost always covered by the gp3 baseline.
Risks and Trade-offs
While the migration from gp2 to gp3 is a safe, online operation in most cases, FinOps and engineering teams must consider potential trade-offs to avoid disrupting production environments. The most critical risk involves performance mismatches, particularly with throughput.
Large gp2 volumes receive a higher throughput limit as part of their bundled price. A simple migration to gp3 without explicitly provisioning equivalent throughput can result in performance throttling, as the gp3 baseline is lower. Similarly, if a gp2 volume was provisioned for high IOPS, the migration process must ensure the new gp3 volume is configured with a matching provisioned IOPS value to prevent application slowdowns. Finally, like any infrastructure change, there is a minuscule risk of failure during the modification process. This risk is mitigated by creating a volume snapshot before initiating the change, ensuring a reliable rollback point.
Recommended Guardrails
To implement a gp2 to gp3 migration program successfully and safely, FinOps teams should establish clear governance and guardrails.
Start by implementing a policy that mandates gp3 as the default volume type for all new EC2 instance deployments. Use cost and asset management tools to continuously scan the environment for existing gp2 volumes that are candidates for migration. A robust tagging and ownership strategy is crucial for identifying application owners who must be notified before a change is made.
Establish clear exclusion criteria to prevent unintended consequences. For example, volumes attached to sensitive, managed services like Amazon EMR or those created within the last seven days should be automatically excluded from migration workflows. Finally, set up automated alerts and budget thresholds within your cloud financial management platform to track the progress and validate the savings generated by the program.
Provider Notes
AWS
This optimization is powered by native AWS capabilities that make it a reliable and non-disruptive process. The core service is Amazon EBS (Elastic Block Store), which provides block-level storage for EC2 instances. The migration focuses on transitioning volumes from the legacy gp2 type to the modern gp3 type, as detailed in the official documentation on EBS volume types.
The entire process is enabled by the Elastic Volumes feature, which allows for modifying the size, type, and performance of an EBS volume without detaching it from the instance or requiring a reboot. This “live” modification capability is what makes the gp2 to gp3 migration a low-risk, high-reward FinOps initiative.
Binadox Operational Playbook
Binadox Insight: The fundamental value of the gp2 to gp3 migration lies in decoupling resources. By separating storage capacity from performance (IOPS and throughput), you shift from a bundled, inefficient pricing model to an à la carte model that aligns cost directly with consumption—a core tenet of FinOps.
Binadox Checklist:
- Inventory all AWS EBS volumes to identify the total count and cost of legacy gp2 volumes.
- Prioritize migration targets, starting with large, non-critical volumes to maximize savings and minimize risk.
- Develop a clear communication plan to inform application owners of planned migration windows.
- Establish an automated process for taking pre-migration snapshots to ensure data safety.
- Implement a policy to use gp3 as the default for all new deployments to prevent future waste.
- Track and report on cost savings post-migration to demonstrate the program’s value.
Binadox KPIs to Track:
- Percentage of total EBS spend attributed to gp2 vs. gp3 volumes.
- Monthly cost savings realized from completed gp2 to gp3 migrations.
- Number of gp2 volumes migrated per week or month.
- Ratio of automated vs. manual migrations to measure operational efficiency.
- Number of performance-related incidents reported on recently migrated volumes (target should be zero).
Binadox Common Pitfalls:
- Forgetting to match throughput on large volumes, leading to performance throttling.
- Migrating volumes attached to managed clusters (like EMR) that have specific storage configurations.
- Failing to take snapshots before modification, removing the option for a quick rollback.
- Neglecting to set equivalent provisioned IOPS, causing application slowdowns.
- Focusing only on large volumes and ignoring the cumulative savings from migrating thousands of smaller boot volumes.
Conclusion
The migration from AWS EBS gp2 to gp3 volumes is more than a simple technical upgrade; it is a foundational FinOps play. It offers a straightforward path to reducing cloud waste, improving cost visibility, and enforcing better architectural standards across an organization. The financial benefits are immediate and significant, while the operational risks are well-understood and easily mitigated.
By treating this migration as a continuous improvement program rather than a one-time project, FinOps practitioners can ensure their organization’s storage footprint remains efficient and cost-effective. The next step is to use cloud visibility tools to quantify the gp2 footprint in your environment and build the business case for launching a systematic migration initiative.
7-day free trial