「オンプレの大量データをAWSへ移したい。ネット経由（DataSync）で送る？それとも物理デバイス（Snowball）を取り寄せる？」——この選択、感覚で決めると事故ります。私はSAP（Solutions Architect Professional）の学習で、移行を自己診断の最弱分野（診断0.2）から始めました。本記事は、そこから抜け出した整理——大量データ移送は「回線 × 容量 × 期限」の1軸で即断できる——を、実際のつまずきとともに解説します。
1. 結論：判断軸は「回線 × 容量 × 期限」の1本
細かいサービス名に入る前に、これだけ握れば設問でも実務でも判断がブレない軸を置きます。両者はそもそも「運ぶ手段」が根本的に違うだけです。
- Snowball＝物理輸送（大型トラック）。デバイスを取り寄せてデータを詰め、AWSへ配送する。初期の一括移送向き。
- DataSync＝オンライン同期（定期宅配便）。ネットワーク経由で転送する。回線がある前提での増分同期向き。
だから判断は「どっちが速い/えらい」ではなく、今の環境が「回線・容量・期限」のどこで詰まるかで決まります。回線が細い・容量が桁違い・期限が厳しい——このどれかに刺されば物理（Snowball）、そうでなければオンライン（DataSync）。これがブレない軸です。
2. なぜ、わざわざ物理トラック（Snowball）なのか
「今どきネットで送ればよくないか？」と最初は思いました。ですが、オンライン転送が破綻する条件が明確に3つあります。ここに1つでも刺さると、物理輸送の出番です。
- ①回線が細い / そもそも無い：山間部の拠点や閉域環境など、十分な帯域を確保できないケース。
- ②大量すぎて時間がかかりすぎる：数十TB〜PB級を細い回線で流すと、転送だけで数週間〜数ヶ月かかる。
- ③従量課金で通信コストが高い：大量データをオンラインで流し続けると、転送料金が無視できない額になる。
逆に言えば、「太い回線があり、容量もそこまで大きくない」なら素直にDataSync。物理デバイスの取り寄せ・配送のリードタイムを負う理由がありません。
3. 本命は「合わせ技」：初期一括はSnow、差分はDataSync
試験でも実務でも一番効くのは、実はどちらか一方ではなく組み合わせです。私が設問で組み立てて「これだ」と腹落ちしたのがこの型でした。
- まず初期の大きな塊をSnowballで物理搬送（数十TBを一気に運ぶ）。
- その間に増えた差分をDataSyncでオンライン同期して追いつかせる。
- 最後に切替（カットオーバー）。
「太い塊は物理で、細い差分はオンラインで」。この合わせ技は本番頻出パターンで、移行サービス全体に共通する背骨でもあります（後述）。
4. シナリオ早見：この条件ならこっち
判断軸を具体的なケースに当てると、迷いが消えます。要件文の「回線・容量・期限」に線を引く癖をつけると一発です。
| 状況（回線・容量・期限） | 選ぶ手段 | 決め手 |
|---|---|---|
| 光回線あり・500GB・期限に余裕 | DataSync | 回線が安定し容量も小さい。物理を取り寄せる理由がない |
| 山間部で回線が細い・80TB | Snowball | オンラインでは時間もコストもかかりすぎる |
| 初期は大量・その後も更新が続く | Snow＋DataSync | 塊は物理で一括、差分はオンラインで追随 |
容量の目安はざっくり、数十TB〜PB級ならSnowball、数GB〜十数TBで回線があるならDataSync。この桁感を持っておくと、要件を見た瞬間に候補を1つに絞れます。
5. 移行の一本背骨：「先に塊 → 差分で追いつき → 切替」
ここが、私が移行分野を「暗記の集合」から「1本の筋」に変えられた瞬間でした。Snow＋DataSyncの合わせ技は単発の小ワザではなく、AWSの移行サービスに共通する背骨です。
- サーバー移行（MGN）：先にまるごと複製（塊）→ 継続レプリケーションで差分を追いつかせ → 切替。
- データ移送（Snow＋DataSync）：初期一括（塊）→ 差分同期 → 切替。
- DB移行（DMS）：初期ロード（塊）→ 継続レプリケーションで差分 → 切替。
どれも「先に塊を運び、あとから差分で追いつき、最後に切り替える」という同じ形。この背骨が見えると、個々のサービスは「同じ発想の別実装」に見えてきて、丸暗記が要らなくなります。
6. 私がつまずいたポイント（実体験）
整理して書いていますが、移行は私の最弱分野でした。つまずきの正体は知識の量ではなく、2つの癖だったと気づけたのが転機です。
- 「大量＝とりあえずSnowball」の早押し：容量だけ見て飛びつくと、「回線は太いし期限も緩い」ケースでDataSyncを取りこぼす。容量・回線・期限を3点セットで見る、と決めてから安定しました。
- 公式用語が概念理解後も口から出ない：「継続レプリケーション」「増分同期」といった語を、意味は分かるのに自分の言葉で出せなかった。絵（トラック／宅配便）で掴んでから用語を貼り直す順にしたら定着しました。
まとめ
大量データ移送は「回線 × 容量 × 期限」の1軸で決まる。回線が細い・容量が桁違い・期限が厳しいなら物理のSnowball、太い回線で容量も小さいならオンラインのDataSync。そして本命は初期一括Snow＋差分DataSyncの合わせ技。「先に塊→差分で追いつき→切替」という移行の背骨を掴めば、移行分野はもう暗記科目ではありません。
このSnow／DataSyncの整理は、私がAWS SAP合格を目指して続けている学習記録の一部です。次回は同じ「差分で追いつく」背骨がそのまま効くDB移行（DMS＋SCT）を扱います。挑戦の全体像と他テーマは、以下からどうぞ。