Forget memorizing names for a second. These three services exist because data has three completely different problems. Understand the problems and the services pick themselves.
Everyone confuses these because they all "involve data and AWS." The trick is to stop thinking about the services and ask one question about your data:
Snow = a moving truck (one big trip). Storage Gateway = a delivery pipe between your house and a warehouse (always on). AWS Backup = an insurance policy (copies, kept safe, claimable). Different jobs — they're not alternatives to each other.
Here's the thing that makes Snow "obvious" once you feel it: moving big data over the internet is shockingly slow. Not because AWS is slow — because of physics and your connection.
Transfer time = data size ÷ your upload speed. Watch how ugly it gets as the data grows:
| Data to move | Over 100 Mbps | Over 1 Gbps | Ship a Snowball? |
|---|---|---|---|
| 1 TB | ~1 day | ~2.5 hrs | No — just upload it |
| 10 TB | ~12 days | ~1 day | Maybe |
| 80 TB | ~3 months | ~9 days | Yes — ship it |
| 1 PB | ~3 years | ~4 months | Definitely |
"Never underestimate the bandwidth of a truck full of hard drives." A truck carrying 80 TB across the country in 2 days has an effective data rate that crushes most internet links. For huge data, a physical box is literally faster than fibre. That's the entire reason Snow exists.
So AWS ships you a rugged, encrypted device. You plug it in, copy your data on, ship it back, and AWS loads it straight into S3. Pick the device by how much you're moving:
| Device | Holds | Picture it as | When |
|---|---|---|---|
| Snowcone | ~8–14 TB | A lunchbox | Small or edge transfers; rugged, portable. |
| Snowball Edge | ~80 TB each | A suitcase | The workhorse — TBs to PBs (use several). |
| Snowmobile | up to 100 PB | A 45-ft truck | Moving an entire data center. Exabyte scale. |
Bonus — edge computing. Snow devices aren't just storage; they can run EC2 instances and Lambda offline. So a ship, an oil rig, or a war zone with no connectivity can collect and process data on a Snowball locally, then ship the device back. Same family, second use case.
All devices are encrypted (KMS), tamper-evident, and use an E-Ink shipping label that auto-updates for the return trip. Mnemonic for size: cone < ball < mobile.
Snow is a one-time move. But what about a company that can't just leave on-prem? Their 10-year-old app expects a local file share or tape drive, rewriting it is off the table, but they're out of disk space and want cloud's bottomless storage.
Storage Gateway solves exactly this. A small gateway appliance (a VM or hardware box) sits in their data center. To the old app it looks like the same local storage it always used. Behind the scenes, it stores everything in AWS and keeps a local cache of the hot data so it still feels fast.
Think of a mini-fridge in your kitchen stocked from a giant warehouse across town. You grab milk from the fridge instantly (the local cache). When the fridge runs low, it's restocked from the warehouse in the background (S3). You get warehouse-sized capacity with fridge-speed access — and you never had to move your kitchen.
The four "types" of Storage Gateway are just which kind of storage your old app expects to talk to:
Cached = the real data lives in AWS, only hot bits are kept locally (minimal on-prem disk). Stored = the full data set stays on-prem (all of it, fast), and AWS just holds async backups. Cached = cloud is home; Stored = cloud is the safety copy.
Now your data is already in AWS. Different problem entirely: what happens when someone deletes it, a disk dies, or ransomware hits? You need copies you can restore from.
You could back up each service by hand — EBS has snapshots, RDS has its own, DynamoDB another, EFS another. But that means many schedules, many scripts, no single view, and no easy way to prove to an auditor that everything is protected. That's the mess AWS Backup removes.
So you write one policy ("daily, keep 35 days, move to cold after 90") and it protects EC2/EBS, RDS, Aurora, DynamoDB, EFS, FSx, S3, even on-prem via Storage Gateway, from one dashboard.
Recovery Point Objective = how much data you can afford to lose, which is just how often you back up. Back up every hour → you lose at most an hour. That's why backup frequency is a policy decision, not an afterthought.
AWS Backup is for scheduled protection & recovery — not one-time bulk transfer (that's Snow) and not live hybrid access (that's Storage Gateway). If the question says "centrally manage backups," "retention policy," or "immutable / ransomware-proof," it's AWS Backup (+ Vault Lock).
Move once → Snow. Keep using → Storage Gateway. Protect → AWS Backup. Match the verb in the question and you can't get it wrong.