Opportunity Name
EBS GP3 to HDD migration (ST1 or SC1 based on observed usage)
AWS Resource Type (AWS service name)
Amazon Elastic Block Store (Amazon EBS) Volumes
Opportunity Description
Some workloads do not require SSD performance, but are still running on gp3 (SSD) EBS volumes. This CloudFix opportunity identifies low-usage gp3 volumes that can be migrated to lower-cost HDD-backed EBS types to reduce storage spend.
Depending on observed usage and sizing constraints, CloudFix may recommend either:
-
st1 (Throughput Optimized HDD) for workloads that benefit from higher throughput HDD performance, or
-
sc1 (Cold HDD) for infrequently accessed / “cold” workloads with very low IOPS and throughput needs.
Because HDD volumes are best suited to large, sequential I/O, CloudFix emphasizes low observed IOPS/throughput and warns that small, random I/O patterns can degrade performance.
Criteria for identifying the opportunity
A gp3 volume may be recommended for migration to st1 or sc1 when all of the following are true:
Baseline eligibility checks
-
Volume exists (EC2
DescribeVolumes) -
Volume type is
gp3 -
Not a boot/root volume (HDD types are not recommended/allowed for root in this workflow)
-
Multi-attach is not enabled (
MultiAttachEnabledis false) -
Sufficient age / metrics availability
-
Volume is at least 7 days old (to ensure adequate telemetry)
-
CloudWatch metrics exist for the lookback period (default 30 days)
-
Sizing constraints
-
HDD minimum size: 125 GiB
-
If the source gp3 volume is smaller than 125 GiB, CloudFix assumes a 125 GiB target size for evaluation.
-
-
Maximum size: 16,384 GiB (16 TiB)
Performance suitability checks (CloudWatch-based, default 30 days)
CloudFix evaluates usage using EBS volume metrics over the lookback period and applies a conservative buffer:
-
A safety margin is applied to IOPS and throughput during validation (e.g., +10% or per configuration).
IOPS compatibility
-
For st1: usage must remain within HDD-appropriate limits (st1 supports higher than sc1; sc1 is capped lower).
-
For sc1: requires very low usage (e.g., ≤ 250 IOPS limit).
Throughput compatibility with baseline/burst behavior
-
CloudFix evaluates whether observed throughput is sustainable on the target HDD type.
-
If observed throughput exceeds baseline at the current size, CloudFix simulates whether the workload can be supported without the credit balance going negative (burst-credit style validation).
-
If the workload is not supported at the current size, CloudFix may increase the target size (doubling steps) until it is:
-
compatible, and
-
still cheaper than gp3, and
-
≤ 16 TiB.
-
Target type selection (ST1 vs SC1)
CloudFix selects the cheapest HDD type that still fits the observed usage:
-
If the volume’s usage fits SC1 limits, CloudFix may recommend SC1 because it offers additional cost savings over ST1.
-
If SC1 would be too restrictive but the volume still appears HDD-appropriate, CloudFix may recommend ST1 instead.
Note: This opportunity assumes the workload is HDD-suitable (generally sequential I/O). Advanced random I/O pattern detection may not be included, so you should validate application performance requirements before migrating.
Potential Savings (if known)
Approximate storage-price deltas (region-dependent):
-
GP3 → ST1: ~44% reduction (example: ~$0.08 → ~$0.045 per GB-month)
-
GP3 → SC1: larger reduction is possible (SC1 example pricing: ~$0.015 per GB-month)
Actual savings estimates shown in CloudFix are based on current cost data and computed target pricing.
What happens when the Fixer is Executed?
There is no automatic Fixer for this opportunity (Finder only).
Migrating to a different EBS volume type typically requires a controlled workflow (for example: snapshot → create new volume of the new type → attach/migrate data → cut over).
Is it possible to roll back once CloudFix implements the Fixer?
CloudFix does not execute an automated change here, so rollback is not automated.
For manual migrations, rollback is usually possible by:
-
restoring from a snapshot, or
-
moving back to gp3 (or another type) using the same migration approach you used originally.
Can CloudFix implement the fix automatically once I accept the recommendation?
No. This opportunity is a manual process (Finder-only).
Does the fix require downtime?
Potentially, yes, depending on how the volume is used:
-
If the volume must be detached and reattached, or data must be copied to a new volume, you may need a maintenance window.
-
Some workloads can migrate with reduced downtime using replication or application-level cutover patterns, but that’s environment-specific.
Additional Resources
-
AWS EBS HDD volume types (st1 and sc1): https://docs.aws.amazon.com/ebs/latest/userguide/hdd-vols.html
Bill Gleeson
Comments