EBS GP3 to HDD Retyping (ST1 or SC1 for Low-Usage Volumes)

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 (MultiAttachEnabled is 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:

IOPS compatibility

• For st1: observed peak IOPS must not exceed 500 IOPS (st1's IOPS limit; no additional margin is applied — this is a hard cutoff).

• For sc1: requires very low usage (observed peak IOPS ≤ 250 IOPS, also a hard cutoff).

Throughput compatibility with baseline/burst behavior

• CloudFix evaluates whether observed throughput is sustainable on the target HDD type using its baseline (not burst) throughput, since burst credits are finite and deplete under sustained load.

• The required volume size is calculated directly from observed throughput: CloudFix takes the peak observed throughput, adds a 20% headroom buffer, and computes the smallest size whose baseline throughput (40 MiB/s per TiB for st1, 12 MiB/s per TiB for sc1) covers that buffered figure — then uses whichever is larger, that calculated size or the volume's current size.

• A recommendation is only produced when the resulting HDD cost, at that calculated size, is still lower than the volume's current gp3 cost.

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?

CloudFix has an automatic Fixer for this opportunity. Amazon EC2's Elastic Volumes feature lets a volume's type be changed in place via the ModifyVolume API — there is no need to create a new volume, detach/reattach, or copy data to a new device. The gp3 volume keeps its volume ID throughout.

When you execute the Fixer, it runs as an AWS Systems Manager Automation execution (see the CloudFix knowledge base article on Direct SSM Automation execution for how runbooks are generated and started) that performs, in order:

1. Idempotency check — confirms the volume is still gp3. If it has already been retyped to st1/sc1, the run exits successfully; any other current type raises an error.

2. Snapshot — takes an EBS snapshot of the volume and waits for it to complete. This snapshot is a safety net for the retype step, not a migration mechanism — the volume itself is never re-created.

3. Optional expansion — if the volume is smaller than the 125 GiB HDD minimum (or otherwise needs to grow to meet the sizing CloudFix calculated), it calls ModifyVolume to expand the volume first and waits for that modification to complete.

4. Retype — calls ModifyVolume to change the volume type to the target (st1 or sc1) and waits for the modification to complete, retrying once if the first attempt does not report completed.

5. Verification — confirms the volume reaches an available or in-use state after retyping.

6. Snapshot cleanup — once the retype is verified, the temporary snapshot from step 2 is deleted automatically (unless snapshot deletion is disabled for the run).

Because the type change is an online, in-place modification, this is fundamentally different from a manual "snapshot → new volume → cutover" migration — there's no new volume to attach and no data to copy at the application layer.

Is it possible to roll back once CloudFix implements the Fixer?

There is no separate, automated "revert to gp3" action. If you need to undo the retype:

• While the Fixer run is still in progress, the pre-retype snapshot it created is available in your account (it is only deleted after the retype is verified successful) — you can create a new gp3 volume from it if needed.

• After the Fixer has completed and deleted its safety snapshot, moving back to gp3 means running the same kind of in-place retype (ModifyVolume back to gp3) yourself, or from your own separate snapshot/backup if you have one.

Can CloudFix implement the fix automatically once I accept the recommendation?

Yes. Once you generate the runbook for this finder and execute it against a recommendation from Available to Execute, CloudFix performs the snapshot-and-retype sequence above automatically.

Does the fix require downtime?

No. ModifyVolume-based type changes are an online operation — the volume can remain attached and in use throughout, including during the snapshot and any size expansion. AWS does recommend avoiding heavy I/O against the volume while a modification is in progress, but no detach/reattach or maintenance window is required by the Fixer itself.

Additional Resources

• AWS EBS HDD volume types (st1 and sc1): https://docs.aws.amazon.com/ebs/latest/userguide/hdd-vols.html