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

Opportunity Name

EBS ST1 to SC1 migration (Cold HDD)

AWS Resource Type (AWS service name)

Amazon Elastic Block Store (Amazon EBS) Volumes

Opportunity Description

Some workloads running on st1 (Throughput Optimized HDD) don’t actually need throughput-optimized HDD performance. For infrequently accessed (“cold”) data, sc1 (Cold HDD) can be a much cheaper option.

This CloudFix opportunity identifies st1 volumes with consistently low IOPS and throughput usage that are candidates for migration to sc1, while accounting for SC1’s lower performance limits and its burst credit model.

This is best suited to volumes backing cold datasets, archives, or infrequently accessed warehouse/staging data. SC1 is generally not appropriate for frequently accessed, latency-sensitive, or performance-critical workloads.

Criteria for identifying the opportunity

A volume may be recommended when all of the following are true:

Hard constraints (must pass)

• Volume exists (validated via DescribeVolumes)

• Volume type is st1

• Size is within sc1 limits

  • Minimum size: 125 GiB (if smaller, CloudFix assumes 125 GiB for the target)

  • Maximum size: 16,384 GiB (16 TiB)

• CloudWatch metrics exist for the lookback period (default: 30 days)

Performance suitability checks (based on CloudWatch, default 30-day lookback)

• IOPS check: CloudFix inflates the observed P99 IOPS by a configurable safety margin (default 10%) before comparing to the SC1 limit: adjusted P99 IOPS ≤ 250

  • Uses VolumeReadOps + VolumeWriteOps

  • IOPS is computed as (ReadOps + WriteOps) / period, where the CloudWatch period varies (1 minute, 5 minutes, or 1 hour) depending on how far back the data point is

• Throughput check: workload must fit within SC1's baseline throughput for the required size

  • CloudFix applies a fixed 20% headroom to the observed peak throughput (this headroom is not the configurable safety margin used for the IOPS check)

  • It computes the minimum SC1 size needed so that SC1's baseline throughput (12 MiB/s per TiB) covers the buffered figure, then recommends targetSizeGiB = max(current size, required size)

  • The volume is rejected only if the required size exceeds 16,384 GiB (16 TiB); there is no burst-credit simulation or size-doubling loop

Out of scope / excluded

• Fixer implementation (finder only)

• Source types other than st1 (e.g., gp3 → sc1 is not directly recommended here)

• Advanced/random I/O pattern detection (M1)

• Multi-attach volumes are excluded (per spec exclusion)

Potential Savings (if known)

~67% storage cost reduction on GB-month pricing basis (example in spec: ~$0.045/GB-month for st1 vs ~$0.015/GB-month for sc1), subject to region and pricing updates.

What happens when the Fixer is Executed?

There is no automatic Fixer in this spec. This is a Finder-only opportunity.

If you implement the change manually, volume type changes often require a snapshot / new volume workflow and an operational cutover plan.

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

Because CloudFix does not implement a Fixer for this opportunity today, rollback is not automated.

If you migrate manually, rollback is typically possible by reverting the volume type back to st1 (or restoring from snapshot), depending on your migration approach.

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

No. This is a manual fix (Finder-only).

Does the fix require downtime?

Potentially, yes, depending on how you migrate:

• If you must detach/reattach or recreate a volume from snapshot, an application maintenance window may be required.

• If the volume backs data that can be replicated or rehydrated elsewhere, you may be able to avoid downtime with a more complex migration approach.

Additional Resources

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