Snow Family and offline data transfer

Closed to new customers

AWS stopped offering any AWS Snow Family device to new customers on 7 November 2025. Existing customers can continue to use the devices they have. New accounts should use AWS DataSync for online transfers, AWS Data Transfer Terminal for physical hand-off, AWS Partner offline services from the AWS Marketplace, or AWS Outposts for edge computing.

The Snow Family was AWS’s answer to a problem that predates cloud computing: sometimes the fastest way to move data is to move the disks. When a dataset would take weeks to push over the available link, shipping a ruggedised appliance beats waiting for the network.

It was also an edge-computing story. The devices ran EC2 instances, EKS Anywhere and an S3-compatible endpoint locally, so a ship, a mine or a film set with no reliable connectivity could collect and process data on site and post the results home.

What is left

AWS documents two surviving Snowball Edge configurations for existing customers: Storage Optimized 210 TB and Compute Optimized. The 80 TB Snowball, the 8 TB Snowcone, the 100 PB Snowmobile truck and the original Import/Export disk-shipping service that older material describes are no longer offered, and the capacity figures in that older material — 80 TB, 81 TB, 8 TB — do not correspond to anything AWS sells today.

What to use instead

Need	Current answer
Bulk transfer over the network	AWS DataSync, optionally over a Direct Connect hosted connection taken for the project
Physical hand-off of data on customer-supplied drives	AWS Data Transfer Terminal — book a slot, bring the devices, upload at facility speed
Offline transfer at larger scale	AWS Partner services in the AWS Marketplace
Compute at the edge or on-premises	AWS Outposts, racks or 2U servers

Choosing between network and physical transfer

The arithmetic that used to justify a Snow device still decides the question, whichever service performs the transfer. A 10 Gbps link carries roughly 1.25 GB per second in theory; sustained throughput on a shared corporate circuit is a fraction of that, so a hundred-terabyte copy runs for days rather than hours and competes with production traffic the whole time.

Weigh four things:

1. Volume. The larger the dataset, the sooner physical transfer wins.
2. Available bandwidth, and how much of it production can actually spare during business hours.
3. Deadline. A copy that can trickle for a month is a different problem from one that must land this weekend.
4. One-off or ongoing. A recurring transfer argues for network capacity that is kept; a single migration argues for capacity that is rented, or for physical hand-off.

AWS publishes a DataSync migration timeline estimator for the network case. Price the options with the AWS Pricing Calculator rather than against figures quoted anywhere else, including here.

A historical footnote

The case for physical transport is older than AWS. In the late 1800s Great Barrier Island, 90 kilometres north-east of Auckland, depended on a weekly steamer for contact with the mainland. When the SS Wairarapa struck Miner’s Head in October 1894, killing 121 of the 235 people aboard, news of the wreck could not reach Auckland until the next steamer sailed. Eighteen months later the island had the world’s first pigeon post service — two competing companies, in fact — which ran until a telegraph cable arrived in 1908.

The lesson survives the technology: when the link is the bottleneck, latency is a function of the carrier, not the protocol.