Backup, block/file elasticity, and migration economics

Storage growth is not one portable autoscaling feature. S3 accepts additional objects without provisioning a volume, so lifecycle changes class and retention rather than capacity. EFS grows and shrinks its stored capacity as files are added or removed; throughput mode remains a separate performance decision. Supported RDS deployments can use storage autoscaling with a configured maximum, but operators still need free-space alarms and a response before that ceiling. EBS Elastic Volumes provides an explicit online modification of size, type, or supported performance settings; it is not demand-triggered magic, and filesystem expansion remains part of the runbook. FSx capacity is also service-specific and explicit. The direct FSx documentation must govern allowed increases and current constraints. For each mechanism state trigger, lead time, maximum, shrink behavior, billing consequence, alarm, and backup or replica amplification. Native elasticity wins only when the service semantics fit. A block workload cannot choose EFS to avoid capacity planning, and an SMB workload cannot choose S3 merely because object capacity is elastic.

A migration plan must identify total bytes, change rate, deadline, source read rate, usable network throughput, encryption, validation, and downtime. DataSync handles online movement and repeated synchronization. Storage Gateway supplies a continuing hybrid file or volume interface and may support a transition period, but it is not a substitute for a sized migration. Transfer Family supplies managed partner-facing protocols such as SFTP or AS2. Choose each only for its contract. Snowball Edge requires current eligibility: AWS states that new customers cannot order it. New customers should evaluate DataSync for online movement, Data Transfer Terminal or partners for physical transfer, and Outposts only when ongoing edge compute is the requirement. The transfer equation should reserve bandwidth for production traffic and account for protocol overhead, retry, and verification. If growth continues during the copy, the final synchronization window depends on change rate, not only the initial dataset. A physical method loses when data must stay continuously synchronized; an online method loses when measured bandwidth cannot meet the deadline.

Design alarms in layers. Warn when observed growth will exhaust free space before the next safe provisioning action, warn again when an autoscaling maximum or service quota is approaching, and cap automated expansion where the service supports a maximum. A runaway log writer can otherwise convert availability protection into uncontrolled spend. Include replicas, snapshots, backups, and temporary migration copies in the growth model; a primary volume increase can multiply downstream storage. Test restoration after resizing because capacity availability does not prove the recovery-time objective. EBS modification may preserve online service, yet application I/O limits and filesystem steps still need validation. For a temporary FSx processing window, deletion after verified output may be cheaper than holding peak capacity indefinitely. For predictable stable data, fixed provisioned capacity and planned maintenance can be safer than automation. For uncertain fast growth, guarded native or configured expansion can beat human response. The decision is complete only when an operator can name the observed trigger, the performed action, the hard ceiling, the expected bill change, and the rollback or migration path.