Migrating Large Datasets to AWS Without Snowball
AWS is retiring the Snowball appliance, so for almost every new migration the old "ship a box or push it over the wire" decision is already made for you: you are transferring over the network, and the real question is whether your bandwidth and your cutover window can absorb the volume. AWS will discontinue support for Snowball devices in all commercial Regions on December 31, 2026, covering both the Storage Optimized and Compute Optimized devices, and ordering is already restricted. This article covers migrating data to AWS without Snowball: what changed, what to measure before you touch anything, and how to size an online transfer so the cutover is boring.
What AWS changed, and the dates that bind you
If your migration plan has a Snowball-shaped hole in it, check these dates before anything else.
Read in order, that means:
- If you do not already have active Snow jobs, you cannot order a device. Plan an online transfer.
- If you are an existing Snow customer, you can still order, but AWS strongly encourages completing jobs and returning devices, and support ends in all commercial Regions on December 31, 2026.
- After December 31, 2026 you will no longer be able to access the AWS Snow Console or Snowball resources, though the change does not affect GovCloud or ADC Region customers with active Snow jobs today.
AWS is candid about the direction of travel: the retirement notice says customers strongly prefer online migrations to offline. For a mid-size company migrating from on premises, the planning assumption should be online transfer first, with offline as a narrow exception for existing customers who genuinely cannot move the data over any available link in time.
Check these before you move anything
The failure mode in large transfers is not the tool, it is discovering on week three that your window was never achievable. Three checks close that gap.
Measure sustained throughput, not the link rating
Your 1 Gbps circuit does not give you 1 Gbps of useful transfer. AWS recommends transferring a 10 GB sample and observing the throughput to establish a baseline rate in MB/s. Do this against the actual destination, over the actual path, at the actual time of day you will run the migration. A link that tests clean at 2am behind no other traffic is not the link you have at 2pm.
Small files are where throughput goes to die. If your dataset is millions of tiny objects, the per-object overhead dominates and your effective rate collapses well below line rate, which is a separate problem from raw bandwidth.
Inventory what you are actually moving
Volume, current location, destination bucket or filesystem, and how much of it is cold, stale, or deletable. Every terabyte you move is bandwidth spent and, at the far end, storage paid for. Prune before you transfer, not after.
Define the window and the delta
Decide how many business days of transfer you can tolerate, and whether the source keeps changing while you copy. A static archive is a single bulk copy. A live file server or database needs a bulk seed followed by an incremental catch-up right before cutover, which changes both your tooling and your timeline.
The sizing math
The core calculation is arithmetic: transfer time equals data volume divided by sustained throughput. The table below shows the theoretical minimum at full line rate, in decimal terabits. Treat these as a floor, not a plan. Real-world efficiency on a sustained copy falls below line rate, and small-file workloads can be far worse.
| Data volume | 100 Mbps | 1 Gbps | 10 Gbps |
|---|---|---|---|
| 10 TB | ~9.3 days | ~22 hours | ~2.2 hours |
| 100 TB | ~93 days | ~9.3 days | ~22 hours |
| 500 TB | ~463 days | ~46 days | ~4.6 days |
Two things fall out of this table immediately. A 100 Mbps internet link is not a serious transport for a hundred terabytes. And at 10 Gbps, even half a petabyte is a one-week job, which is the whole reason AWS is comfortable retiring the appliances.
For a sanity anchor, AWS's own planning guide uses this example: to move 300 TB of data to AWS over 10 days at a transfer speed of 250 MB/s, you need 4 Snowball Edge devices. Run that same formula against your measured rate and your window before you commit to a date.
Your online paths on AWS, and what each costs later
Over your existing internet connection
For file and object data, AWS recommends DataSync for online transfers. The trade-off is that a flat-out copy saturates the same link your production traffic uses, so throttle it or run it off-hours. The cost that shows up later is almost always the delta: if the source keeps changing, budget for an incremental sync immediately before cutover rather than assuming one bulk copy is enough. We cover the mechanics of planning that cutover in our cloud migration service.
AWS Direct Connect
When the internet link is the bottleneck, a private circuit raises the ceiling. Direct Connect dedicated connections are available at 1, 10, 100, and 400 Gbps, and partner-provided hosted connections range from 50 Mbps up to 25 Gbps.
The catch is lead time, and it is the single most common planning mistake. AWS states it can take up to 72 business hours to review your request and provision the port, but that is only the AWS side. The physical circuit is the long pole: AWS's hybrid connectivity guidance notes that connectivity can be established within hours over an existing path, but may take weeks or months if additional circuits must be installed. You also have to work a Letter of Authorization and Connecting Facility Assignment through your network provider to order the cross connect.
The cost that lands later is a standing monthly charge for a port you now own. That is only worth it if you want the link for ongoing hybrid connectivity or egress anyway. Provisioning Direct Connect purely for a one-off migration, then tearing it down, rarely pays for itself. If the circuit is part of a longer-term hybrid or landing-zone design, bake it into the network work; that is the kind of decision our cloud architecture practice plans around where you will be in three years, not just the migration week.
Native object upload
If your source is already object storage or a database with a native export, go direct: S3 multipart uploads, or the service's own migration tooling, rather than staging everything through a file-copy layer. Fewer hops, fewer places for the transfer to stall.
Online versus the remaining offline option
| Situation | Reach for |
|---|---|
| New AWS customer, any volume | Online only. Snowball is not orderable. |
| Volume fits your window over the existing link | DataSync or native upload, throttled off-hours |
| Link is the bottleneck, ongoing hybrid wanted | Direct Connect, but start the circuit order early |
| Existing Snow customer, low bandwidth, large volume, hard deadline before Dec 31 2026 | Snowball Edge, if you can finish and return in time |
If you are an existing customer and still need offline
A real low-bandwidth, high-volume case can still justify a device while you can get one. Snowball Edge devices have approximately 39.5 TB or 210 TB of usable storage depending on the model. On security, Snowball Edge encrypts all data with 256-bit encryption, keys are managed through AWS KMS and are never stored on the device, and all memory is erased when the device is disconnected and returned. The hard constraint is the calendar: scope the job so the device is filled, shipped, ingested, and returned well before support ends, because there is no renewal after that.
Frequently asked questions
Can I still order an AWS Snowball device?
Only if you are an existing Snow customer. Snowball Edge devices became available to existing customers only on November 7, 2025, and three previous-generation models were discontinued on November 12, 2024. New customers cannot order one, and support for Snowball ends in all commercial Regions on December 31, 2026. Plan a network transfer instead.
How do I estimate how long a network migration to AWS will take?
Divide the data volume by your sustained throughput, not your link rating. AWS recommends copying a 10 GB sample first to measure the real rate in MB/s, then plan against less than line rate because overhead and small files eat into the theoretical maximum. For scale, AWS's own example notes that moving 300 TB over 10 days at a transfer speed of 250 MB/s requires 4 Snowball Edge devices.
Is Direct Connect worth it just for a migration?
Usually not on its own. The AWS port can be provisioned in up to 72 business hours, but the physical circuit can take weeks or months if a new one must be installed, and it carries a standing monthly cost. It pays off when you will keep the link for ongoing hybrid connectivity or egress, not as a one-off transport you decommission after cutover.
What replaces Snowball for moving large datasets to AWS?
For file and object data, AWS DataSync over your internet link or a Direct Connect circuit. For object-native or database sources, native upload and the relevant migration service. The combination of higher bandwidth availability and AWS's own preference for online migrations is why the appliances are being retired rather than refreshed.
What happens to data migrations after December 31, 2026?
For commercial Regions, Snowball is no longer an option. After that date you lose access to the Snow Console and Snowball resources, though GovCloud and ADC customers with active jobs are not affected. Any offline job must be completely finished and the device returned before the cutoff.
