AWS Migration Services: Snowball & Application Migration Service
Moving large datasets and entire servers into AWS — physical data transfer devices for the Snow Family when network transfer isn't practical, and lift-and-shift server migration with AWS Application Migration Service.
Want a visual for this topic?
Generate a diagram tailored to AWS Migration Services: Snowball & Application Migration Service — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain when physically shipping a device (Snowball) beats transferring data over the network
- •Calculate roughly how long a given dataset would take to transfer over a given network link, to justify a Snowball decision
- •Describe how AWS Application Migration Service performs continuous replication for a near-zero-downtime cutover
- •Distinguish a lift-and-shift migration approach from a re-architecting migration approach
What is it?
This topic covers two distinct AWS migration tools solving different problems: the Snow Family (Snowball Edge and related devices) are physical, rugged, high-capacity storage devices AWS ships to your data center for offline bulk data transfer, used when moving data over the network would take impractically long. AWS Application Migration Service (MGN, formerly known under the Server Migration Service naming) performs continuous, near-real-time replication of entire on-premises or other-cloud servers into AWS, enabling a lift-and-shift migration with minimal cutover downtime.
Why it exists
Moving very large datasets (many terabytes to petabytes) over even a fast internet connection can take days, weeks, or longer — network transfer has a hard physical ceiling. Snowball exists because, past a certain data volume and available bandwidth, physically shipping a high-capacity storage device is genuinely faster than any network transfer, an insight often summarized as 'never underestimate the bandwidth of a truck full of hard drives.' Separately, migrating an entire running server (with its OS, installed software, and state) into AWS used to mean either a slow, error-prone manual rebuild or significant downtime during a one-time cutover copy — Application Migration Service exists to make that migration continuous and the actual cutover near-instant.
Problem it solves
Snowball solves the physics of large-scale data transfer when network bandwidth and time constraints make online transfer impractical, and also serves disconnected or bandwidth-constrained environments (like a ship or a remote facility) needing to move data to AWS at all. Application Migration Service solves minimizing downtime during a server migration: because replication runs continuously in the background well before cutover, the actual cutover only needs to account for the last few minutes of change, not a full data copy.
Intuition
Snowball is the physical-shipping equivalent of realizing it's faster to drive a truck full of hard drives across the country than to wait for an upload bar to finish over a home internet connection — at large enough data volumes, physical transport genuinely wins the race against network transfer. Application Migration Service is like renovating a house by building and continuously keeping an exact, live-updated replica ready in a new location, so that on moving day you only need to move the last day's changes, not everything from scratch — dramatically cutting the actual disruption window.
Analogy
Migrating a database over a slow network connection versus using Snowball is like choosing between mailing a single book at a time versus shipping an entire library in one truck — past a certain volume, the truck wins decisively even though a single mailed letter would arrive 'instantly' by comparison for a tiny amount of data.
Technical explanation
The general rule of thumb for choosing Snowball over network transfer: if the dataset would take more than about a week to transfer over your available bandwidth, physical transfer is very likely faster and often cheaper — AWS itself provides calculators and guidance for this exact tradeoff. Snowball Edge devices also support limited local compute (running EC2 instances or Lambda functions on the device itself) for edge-processing use cases before data ever reaches AWS. Application Migration Service installs a lightweight agent on the source server that performs continuous, block-level replication to a staging area in your AWS account, without requiring the source server to be stopped or significantly disrupted during this replication phase; when ready, you can launch non-disruptive test instances from the replicated data to validate the migration before performing the actual cutover, which only needs to catch up on the small delta of changes since the last replication sync, keeping actual downtime to typically minutes rather than the hours a full one-time copy-and-switch would require.
Architecture
A media company needs to migrate an 800TB on-premises video archive to S3; given their available internet bandwidth, a network transfer is calculated to take over two months, so they instead order several Snowball Edge devices, load the archive locally at the data center's internal network speed, and ship the devices to AWS, completing the transfer in about two weeks total including shipping time. Separately, the same company migrates its on-premises application servers to EC2 using Application Migration Service: replication runs continuously for two weeks while they validate test instances launched from the replicated data, and the actual production cutover — the only real downtime window — takes under 15 minutes.
Workflow
- For large dataset migration, calculate expected network transfer time against available bandwidth; if it exceeds roughly a week, evaluate Snowball. 2) Order the appropriately sized Snow Family device, load data locally, and ship it back to AWS for import into S3. 3) For server migration, install the Application Migration Service replication agent on source servers and let continuous replication run well ahead of the planned cutover date. 4) Launch and validate test instances from the replicated data without disrupting the source. 5) Perform the final cutover during a short planned window, catching up only the recent delta of changes.
Example
A hospital system migrating patient-record servers to AWS uses Application Migration Service specifically because continuous replication lets them validate the migrated environment extensively (a hard requirement given compliance obligations) over several weeks without any production impact, with the actual go-live cutover scheduled for a low-traffic overnight window and completing in under 20 minutes.
Real-world usage
Snowball is commonly used for large-scale data center decommissioning, media/entertainment archive migration, and initial bulk-load migrations for organizations moving petabyte-scale datasets to AWS. Application Migration Service is AWS's current recommended default tool for lift-and-shift server migrations at virtually any scale, having superseded older, less capable migration tooling.
Trade-offs
Snowball trades physical shipping time and logistics for a dramatically faster effective transfer rate at large data volumes — the crossover point where it beats network transfer is a straightforward bandwidth-and-volume calculation, not a subjective call. Application Migration Service trades a longer overall migration project timeline (weeks of replication running before cutover) for a much shorter, much safer actual cutover window — the right tradeoff for nearly any production server migration where minimizing downtime matters more than minimizing total project duration.
Visual explanation
Picture a Snowball Edge device being shipped to a data center, connected locally to load data directly onto it (often at much higher throughput than the facility's external internet link would allow), then shipped back to AWS, where the data is loaded into S3 — the device itself becomes the transfer medium instead of any network link. Picture Application Migration Service as a lightweight replication agent installed on a source server, continuously streaming block-level changes to a staging area in AWS, with a test/cutover process launching a fully synced replica EC2 instance from that continuously updated replication data whenever you're ready.
Advantages
- —
Snowball can be dramatically faster and cheaper than network transfer for genuinely large datasets, with a straightforward, well-documented decision threshold
- —
Snowball Edge devices also support local compute, useful for edge-processing before data reaches AWS at all
- —
Application Migration Service's continuous replication keeps actual cutover downtime to typically minutes, not hours or days
- —
Both services are fully managed migration paths requiring no custom-built transfer or replication tooling
Disadvantages
- —
Snowball introduces physical shipping logistics and lead time, which network transfer entirely avoids for smaller datasets
- —
Snowball devices are a security consideration in transit, though AWS encrypts data on the device by default
- —
Application Migration Service's replication agent adds a small ongoing resource overhead on the source server during the replication window
- —
Neither service replaces the harder work of actually validating application behavior post-migration — they solve the data/server movement problem, not application correctness
Common mistakes
- —
Defaulting to network transfer for a very large dataset without calculating the actual expected transfer time against available bandwidth, missing an obvious Snowball opportunity
- —
Treating a Snowball transfer as instantaneous once devices ship, forgetting to account for shipping lead time in migration project planning
- —
Performing a server migration as a single one-time copy-and-cutover instead of using Application Migration Service's continuous replication, resulting in unnecessarily long downtime during cutover
- —
Not validating a migrated test instance thoroughly before final cutover, treating Application Migration Service's replication as a guarantee of application correctness rather than just data/server-state fidelity
In the AWS Console
- 1
AWS Console → AWS Snow Family → Create job
Specify the amount of data, choose a Snow Family device type/capacity, and provide a shipping address.
AWS provides bandwidth-vs-data-volume guidance during job creation to help confirm Snowball is genuinely faster than network transfer for your specific case.
- 2
AWS Console → Application Migration Service → Source servers → Add source server
Install the provided replication agent on the source server; replication to a staging area in your AWS account begins automatically.
Launch a non-disruptive test instance from the replicated data well before the planned cutover to validate the migration works as expected.
🎤 Interview questions
What's the general rule of thumb for deciding between Snowball and a network-based transfer for a large dataset? (Listen for: roughly, if the transfer would take more than about a week over available bandwidth, physical Snowball transfer is likely faster and often cheaper.)
How does Application Migration Service minimize downtime during a server cutover? (Listen for: continuous, ongoing block-level replication runs well before the planned cutover; the actual cutover only needs to catch up on the recent delta of changes, not a full copy.)
What's a lift-and-shift migration, and how does Application Migration Service support it? (Listen for: moving a server as-is into AWS without re-architecting it; MGN replicates the entire server's state continuously so it can be launched as an equivalent EC2 instance.)
Besides bulk data transfer, what else can a Snowball Edge device do? (Listen for: it supports limited local compute — running EC2 instances or Lambda functions directly on the device — useful for edge processing before data reaches AWS.)
Why would a compliance-heavy organization specifically value Application Migration Service's continuous replication approach over a one-time cutover migration? (Listen for: it allows extensive validation of test instances launched from replicated data over an extended period with zero production impact, before committing to a short, low-risk final cutover.)
📂 Subtopics
The Bandwidth Math Behind Choosing Snowball
A concrete way to reason about when physical transfer beats the network, rather than relying on intuition alone.
~8 min
How Application Migration Service's Replication-to-Cutover Flow Works
The three phases of an MGN migration — replicate, test, cutover — and why splitting them apart minimizes risk and downtime.
~8 min