AWS Snow Family vs Network Transfer for an EKS Migration: When Does Physical Data Transfer Still Make Sense in 2026?

Key points:

• For a new EKS migration in 2026, the AWS Snow Family is effectively off the table. Snowmobile was discontinued in 2024, Snowcone on November 12, 2024, Snowball Edge closed to new customers on November 7, 2025, and AWS will discontinue support for Snowball devices on December 31, 2026 in all commercial Regions.
• Do the math before you pick: days = (bytes x 8) / (bandwidth in bit/s x utilization x 86,400). At 80% utilization, 100 TB takes about 11.6 days on 1 Gbps and 1.2 days on 10 Gbps (AWS DataSync docs).
• Network transfer wins below roughly 100 TB on a 1 Gbps link and below roughly 1 PB on 10 Gbps, and it is the only option that keeps syncing deltas until cutover. A single DataSync task can fill a 10 Gbps link, and Direct Connect inbound data transfer is free.
• Physical transfer still makes sense when the data is created far from a fast link (field capture, film sets, labs), when the dataset is hundreds of terabytes behind a link under 1 Gbps, or when security rules forbid the data crossing the internet. In 2026 that means AWS Data Transfer Terminal (your own drives, up to 100 Gbps per fiber, $300 per port-hour in North America and Europe) or partner appliances.
• EKS changes where the data lands; the transfer itself stays the same. Bulk data goes to S3, EFS or FSx and is mounted into pods with CSI drivers; databases move with AWS DMS or native replication. The app layer on EKS is the smaller job, and a managed platform such as Qovery handles it in your own AWS account.

A year ago the answer to "should we ship our data to AWS on a Snowball?" was "maybe, do the math". Today the answer for most teams is "you can't order one anyway, so do the math on the network".

I have helped teams move petabytes onto EKS, and the physical-versus-network question is almost always decided by three numbers: dataset size, usable bandwidth, and how long the source keeps changing. Here is how I would decide in November 2026, including the AWS changes of the last two years.

What is the current status of the AWS Snow Family in 2026?

AWS has wound the Snow Family down. Snowmobile and Snowcone are discontinued, Snowball Edge has been closed to new customers since November 7, 2025, and AWS states that "on December 31, 2026, AWS will discontinue support for AWS Snowball devices in all AWS commercial Regions" (AWS Snowball). After that date you can no longer access the Snow console or Snowball resources.

The timeline, from AWS's own pages:

AWS says the end of support does not affect GovCloud or ADC Region customers with active Snow jobs. Everyone else should treat Snowball as gone for any migration that will not be finished in the next six weeks.

AWS points new customers to three replacements: AWS DataSync for online transfers, AWS Data Transfer Terminal for physical transfers, and AWS Partner solutions such as Seagate and Tsecond on the AWS Marketplace. For edge compute, it points to AWS Outposts.

If you are an existing Snowball customer with a job in flight, finish it and plan the next wave on the network. I would not start a new Snowball-based migration plan in November 2026.

How long does it take to move data to AWS over the network?

Use AWS's own formula: days = (data size in bytes x 8) / (circuit in bit/s x network utilization x 3,600 x available hours per day). For 100 TB on a 1 Gbps link at 80% utilization, running 24 hours a day, that is about 11.57 days (AWS DataSync docs). Treat the result as a theoretical minimum.

Here is the table I keep pinned for migration planning. Decimal units (1 TB = 10^12 bytes), 80% sustained utilization, 24 hours a day:

Caveats when you read it:

• 80% is optimistic for shared links. If production traffic shares the circuit and you throttle the transfer to nights, use AVAILABLE_HOURS = 10 or 12 and the numbers double.
• Small files are slower than the table. Millions of small files are bounded by metadata operations and storage IOPS, not bandwidth. Run a proof of concept on a representative folder before you trust any estimate.
• Cutover is extra. AWS notes that with large migrations, "it's not uncommon for cutover activities to take up to 30 percent of your overall migration time" (AWS DataSync docs).
• The 100 Gbps column needs parallelism. AWS says a single DataSync task can fully use a 10 Gbps link (AWS), so filling 100 Gbps means partitioning the dataset across many tasks and agents, and storage that can read at 12.5 GB/s.

When did physical transfer beat the network, and what was the cost?

Physical transfer beat the network when the dataset divided by your usable bandwidth took longer than shipping and loading a device, typically above 100 TB on links under 1 Gbps. A Snowball Edge Storage Optimized 210 TB job cost $1,800 for up to 100 TB or $3,200 for 101 to 210 TB, with 15 days on site included (AWS Snowball pricing).

The numbers that defined the trade-off, so you can compare the replacements fairly:

• Capacity: the current Storage Optimized device holds 210 TB on NVMe and can transfer "up to 1.5 gigabytes of data per second" (AWS Storage Blog). Filling 210 TB at that ceiling takes about 39 hours, before shipping either way.
• Cost: $1,800 or $3,200 per job in US East, $250 per extra day on site after 15 days, plus shipping. Data imported into S3 was free.
• Time: shipping days each way, plus loading, plus AWS-side ingest. A realistic end-to-end cycle was measured in weeks, not days.

Compare that with the network. 100 TB through DataSync costs $1,250 in Basic mode at $0.0125 per GB (DataSync pricing), and takes 1.2 days on a dedicated 10 Gbps link. A 10 Gbps hosted Direct Connect port runs $2.48 per hour, about $1,800 for a month of project time (Direct Connect pricing). For a 100 TB migration with a decent link, the network was already competitive with Snowball before Snowball went away.

What are the network options for moving data to AWS before an EKS migration?

Your network options are AWS DataSync over the internet or a VPN, DataSync over AWS Direct Connect (dedicated or a hosted connection bought for the project), and AWS Transfer Family for SFTP-style pushes from partners or legacy systems. For most EKS migrations, DataSync plus a temporary Direct Connect is the default.

Pricing sources: DataSync, Direct Connect, Transfer Family, Data Transfer Terminal.

AWS's own replacement guidance says that if bandwidth is the blocker, you should "consider using DataSync with an AWS Direct Connect hosted connection. You can procure this connection from an AWS Direct Connect Delivery Partner for the duration of the data transfer project" (AWS). That is the modern equivalent of renting a Snowball, except you rent a fat pipe for a month.

When does physical data transfer still make sense when moving to EKS?

Physical transfer still makes sense in four situations: the data is created somewhere without a fast link, the dataset is hundreds of terabytes behind a link slower than 1 Gbps, a security rule forbids the data crossing any network, or you need a one-time bulk seed faster than a circuit can be provisioned. Outside those, the network is simpler and keeps syncing deltas until cutover.

My rule of thumb, using the table above:

• Under 10 TB: network, always. Even 100 Mbps finishes in under two weeks.
• 10 to 100 TB: network if you have 1 Gbps or more. On a slow link, buy a hosted Direct Connect for the project before considering anything physical.
• 100 TB to 1 PB: network if you can get 10 Gbps (1.2 to 11.6 days). If you are stuck at 1 Gbps or less and the data sits on drives you can carry, Data Transfer Terminal becomes attractive.
• Over 1 PB, or data captured in the field: physical seed plus network delta. Copy the bulk to fast NVMe drives, upload at a terminal or through a partner appliance, then run DataSync incrementals until cutover.

A worked example. 100 TB at a Data Transfer Terminal on a 100 Gbps port is about 2.8 hours of theoretical transfer at 80% utilization. AWS's performance guidance says to budget roughly 15% protocol overhead and warns that 100 Gbps requires 12.5 GB/s of storage throughput, which only Gen 5 NVMe drives deliver (AWS Migration blog). Book four hours, bring NVMe, and the port cost in North America is about $1,200 with no per-GB fee (pricing). AWS also states that Data Transfer Terminal "is available only to AWS Enterprise Support customers at this time" (AWS docs), and you only learn the facility address after you book.

Physical transfer never removes the delta problem. Your source keeps changing while drives travel. Plan a final network sync and a write freeze, whatever carried the bulk.

Where does the data land when the destination is EKS?

On EKS, migrated data lands in AWS storage services, not inside the cluster. Bulk files go to Amazon S3, Amazon EFS or Amazon FSx, which pods then mount through CSI drivers; block volumes come from EBS; databases move to Amazon RDS or Aurora with AWS DMS or native replication. Pick the landing service before you pick the transfer method, because DataSync writes directly to S3, EFS and FSx.

The mapping I use:

Two things I see teams get wrong:

• Copying data into persistent volumes inside the cluster. That ties your data to a node group and a cluster version. Put it in S3, EFS or RDS, and let pods attach to it.
• Moving databases with file copies. A database file copy needs downtime for the whole transfer. DMS or native replication runs the bulk load and then streams changes, so the cutover window is minutes.

If you are leaving ECS rather than a data center, the data part is often trivial and the work is in the app layer. We wrote about that in ECS vs EKS in 2026: The ECS Limits AWS Won't Raise.

How do you plan the cutover so the data and the EKS apps arrive together?

Run the data and the application as two parallel workstreams that meet at cutover: seed the bulk data early, keep it in sync with incremental transfers or change data capture, stand up the apps on EKS against the synced copy, then freeze writes, run a final delta and switch traffic. The transfer method only decides how fast the seed happens.

The sequence I recommend:

1. Inventory and measure. Dataset sizes, file counts, change rate per day, and the real sustained throughput of your link. Measure, do not read it off the contract.
2. Pick the landing services (S3, EFS, FSx, RDS) and create them in the target account and Region.
3. Seed. DataSync over the internet or Direct Connect, or a physical seed through Data Transfer Terminal or a partner for the largest sets.
4. Sync deltas. Scheduled DataSync tasks for files, DMS change data capture for databases.
5. Deploy the apps on EKS against the synced data, in a staging environment first, and run your real test suite there.
6. Cut over. Freeze writes, final delta, verify checksums and row counts, switch DNS or load balancer weights, keep the old side read-only for rollback.

I covered the zero-downtime side of this in How to Plan a Phased Hybrid Cloud Migration Without Taking Production Down, and the full checklist in The Cloud Migration Checklist I Wish I Had.

How does Qovery help once the data is on AWS?

Qovery handles the application half of an EKS migration: it creates and manages an EKS cluster in your own AWS account (or connects the one you already have), deploys your services, workers and cron jobs from Git, and provisions managed services such as Amazon RDS through Blueprints. Your data, cluster and AWS bill stay in your account; Qovery's control plane is separate and never hosts your apps.

During a data migration, that gives you:

• Staging on EKS from day one. Environment cloning and a preview environment per pull request let you test the app against synced data long before cutover.
• No platform build first. Qovery-managed EKS includes Karpenter for node autoscaling, so you do not spend the migration window writing cluster Terraform.
• Same workflow if AWS is not the only target. Qovery runs on GCP, Azure, Scaleway or any existing Kubernetes cluster too, so a later move does not mean a new toolchain.
• Guardrails for the people and agents doing the work. RBAC, audit logs and OPA-based policy tokens scope who can deploy what during a sensitive cutover.

Qovery does not move your data. DataSync, Direct Connect, DMS or a terminal does that. Qovery makes sure the apps on EKS are ready when the data is.

How do I deploy the migrated apps to EKS with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent to deploy each service to your AWS account. The skills deploy and onboard; the MCP Server operates what already exists. Use only the commands you need.

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Or scoped to the current project
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# 3. MCP Server for Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# 4. MCP Server with write access, only when you explicitly want it
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

• Command 1 installs the skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform). Your agent asks you to approve the shell command.
• Command 2 limits the install to one repository.
• Command 3 adds the read-only MCP Server; it opens an OAuth login in your browser and acts with your permissions.
• Command 4 enables writes, which also require write access enabled in the Qovery Console.

Then ask in plain language: "deploy this app to my AWS account with Qovery, using the RDS database and S3 bucket we migrated". Start from the AI agent quickstart or the Claude Code integration.