SAA / ドメイン4 コストを最適化したアーキテクチャの設計
AWS Snow Family（Snowball）
は、大容量データを物理デバイスで AWS に移行したり、ネットワーク接続が限られる場所でエッジ処理を行ったりするためのサービスです。代表的には Snowball Edge デバイスを使い、環境でデータを書き込み、デバイスを AWS に返送して へ取り込みます。
SAA では、Snowball は「ネットワーク転送では時間がかかりすぎる大量データ移行」や「接続が不安定な現場でローカル処理が必要」という文脈で出ます。、、、S3 Transfer Acceleration と混同しやすいため、データ量、回線状況、移行頻度、エッジコンピューティング要件で判断します。
Point
- Snowball は直訳すると「雪玉」です。
- AWS Snow Family は、物理デバイスを配送してデータを運ぶサービス群です。
- 試験では「オンライン転送が現実的でないほど大きいデータ」を見たら Snowball を候補にします。
- 和訳
- Snow: 雪
- Ball: 玉
- Weblio英和辞書「snowball」
概要
は、インターネットや専用線で何日も何週間もかかるデータを、AWS が提供するのある物理デバイスにコピーして配送することで移行する仕組みです。データ移行だけでなく、Snowball Edge ではローカルストレージやローカルコンピュートを使い、工場、船舶、災害現場、遠隔地などの接続が限られる環境で処理を行う設計にも使われます。
基本的な流れは、AWS Snowball コンソールでジョブを作成し、 や通知設定を指定し、AWS から届いたデバイスをローカルネットワークに接続してデータを転送し、返送後に AWS 側で S3 へ取り込む、というものです。デバイスには暗号化や耐タンパー性があり、配送中のデータ保護も考慮されています。
ただし、公式ドキュメントでは Snowball Edge は新規顧客向けに利用できない旨が案内されています。現在の実務では、オンライン転送は 、セキュアな物理転送は AWS Data Transfer Terminal、エッジコンピューティングは なども代替候補として確認します。SAA 学習では、従来の Snowball の判断軸を押さえつつ、最新の推奨サービスも意識します。
| 観点 | Snowball を選びやすい条件 |
|---|---|
| データ量 | TB から PB 級で、ネットワーク転送が長すぎる場合 |
| ネットワーク | 帯域が狭い、不安定、切断される、または利用できない場合 |
| 移行頻度 | 一度きり、または大規模な初期移行 |
| 処理場所 | AWS へ送る前に現地で前処理や分析が必要な場合 |
| 宛先 | 主に Amazon S3 へのインポート、または S3 からのエクスポート |
主要技術
①Snowball Edge とジョブ
の作業単位はジョブです。データを AWS に取り込むインポートジョブ、AWS からへ持ち出すエクスポートジョブ、ローカルコンピュートやストレージを使うエッジ用途などがあります。ジョブを作ると AWS がデバイスを準備して配送し、利用者は受け取ったデバイスをローカルネットワークへ接続します。
| ジョブの考え方 | 主な用途 | SAA での判断 |
|---|---|---|
| インポート | オンプレミスデータを へ移行 | 大量データを AWS に入れる定番です。 |
| エクスポート | S3 のデータをオンプレミスへ持ち出す | AWS から大量データを取り出す要件で検討します。 |
| ローカルストレージ | 現地で一時的にデータを保管 | 回線が不安定な現場で役立ちます。 |
| ローカルコンピュート | デバイス上で処理を実行 | エッジで前処理や分析を行う要件で検討します。 |
Snowball Edge にはストレージ最適化やコンピューティング最適化の構成があります。SAA では詳細スペックの暗記よりも、「大容量の保管・移行が中心ならストレージ寄り」「現地で 互換インスタンスや処理を動かすならコンピュート寄り」と判断できれば十分です。
⚠️ 頻出: 「オンプレミスの数百 TB 以上を AWS に移行」「回線では移行期間が長すぎる」「初期移行だけ大容量」という条件では Snowball を選びます。継続的な同期や小規模な日次転送なら などを検討します。
②データ転送の流れと S3 連携
の代表的な移行先は です。利用者はジョブ作成時に S3 を指定し、デバイスが届いたらローカル環境からデータをコピーします。返送後、AWS がデータを S3 に取り込み、処理が完了するとデバイス上のデータは消去されます。
| ステップ | 作業内容 | 注意点 |
|---|---|---|
| ジョブ作成 | デバイス、S3 バケット、通知などを指定 | 、宛先、配送先を確認します。 |
| 受け取り | デバイスを電源とネットワークへ接続 | AWS OpsHub やクライアントでロック解除します。 |
| コピー | や S3 互換 などでデータ転送 | ローカルネットワークの帯域がボトルネックになります。 |
| 返送 | E Ink ラベルに従って AWS へ返送 | 物理配送時間を移行計画に含めます。 |
| 取り込み | AWS が S3 へデータをインポート | 取り込み後の検証と後続処理を設計します。 |
Snowball は配送を使うため、リアルタイム性が必要なデータ転送には向きません。大量のバックアップ、、メディアデータ、分析用データセット、データセンター移行の初期投入などに向きます。
⚠️ 頻出: Snowball は S3 と組み合わせる大量データ移行で出ます。 ボリュームをそのまま物理的に運ぶサービスではなく、データを S3 に取り込んだ後、必要に応じて 、EBS、、分析サービスなどで利用する流れを考えます。
③セキュリティ、暗号化、物理保護
は物理デバイスを配送するため、セキュリティの考え方が重要です。データは暗号化され、デバイスは堅牢な筐体と改ざんを検知しやすい仕組みを備えています。ジョブやアクセス権限は で制御し、通知や監査には 、 などを組み合わせます。
| セキュリティ観点 | 内容 | 試験での見方 |
|---|---|---|
| 暗号化 | データはデバイス上および配送中も保護 | 物理配送でも平文で運ぶわけではありません。 |
| 暗号鍵管理とアクセス制御に関係 | 鍵への権限不足は操作失敗の原因になります。 | |
| IAM | ジョブ作成やアクセスの認可 | で Snowball と への操作を許可します。 |
| 物理保護 | のある筐体、配送ラベル、改ざん検知 | 配送中の紛失・改ざんリスクを下げます。 |
| 監査・通知 | SNS、CloudTrail など | ジョブ状態や 操作を追跡します。 |
Snowball は「物理配送だから危険」という単純な扱いではありません。ネットワーク経由で長期間データを流すより、暗号化された専用デバイスを使って短期間で移行する方が適切な設計になる場合があります。
Point
- KMS = Key Management Service の略です。
- Snowball のようにデータを暗号化して運ぶサービスでは、鍵の管理と権限が重要です。
- IAM 権限、KMS キー、S3 バケット権限のどれかが不足すると、ジョブや取り込みが失敗する可能性があります。
- 和訳
- Key: 鍵
- Management: 管理
- Weblio英和辞書「management」
⚠️ 頻出: Snowball では「大容量を安全に物理移送できる」点が重要です。単なる外付けディスクではなく、AWS が管理する暗号化、配送、ジョブ管理を含むサービスとして理解します。
④エッジコンピューティング
は、ストレージを運ぶだけでなく、現地で処理を行うエッジデバイスとしても使えます。 互換ストレージ、 互換インスタンス、 on Snow、 と AWS IoT Greengrass などと組み合わせ、AWS に常時接続できない場所でも処理できます。
| エッジ要件 | Snowball Edge での考え方 | 代替候補 |
|---|---|---|
| 接続が不安定な現場でデータ収集 | ローカルに保存し、後で AWS へ移行 | はオンライン接続が前提です。 |
| 現地で前処理やフィルタリング | デバイス上のコンピュートを使用 | 常設基盤なら も検討します。 |
| 大量データを現場で一時保管 | ローカルストレージを使用 | 長期保管は S3 やストレージを考えます。 |
| Kubernetes ワークロード | EKS Anywhere on Snow | AWS リージョン連携の要件を確認します。 |
エッジ処理が必要な例として、工場のセンサーデータ、船舶や鉱山などの遠隔地、災害現場、映像やデータの前処理があります。すべてのデータをクラウドへ送る前に、現地で不要データを除外したり、低遅延で判断したりする用途です。
⚠️ 頻出: 「ネットワークがほぼない場所で処理したい」「現地でデータを集めて後で AWS に送る」「低遅延のローカル処理が必要」は Snowball Edge や Outposts などのエッジサービスを比較します。一度きりの物理移行なら Snowball、常設の AWS インフラが必要なら Outposts が候補になります。
⑤DataSync、Storage Gateway、Direct Connect との比較
の試験対策で最も重要なのは、他の移行・接続サービスとの使い分けです。特に 、、、 Transfer Acceleration と混同しやすいです。
| サービス | 向いている用途 | Snowball との違い |
|---|---|---|
| AWS Snowball | オフラインまたは低帯域環境での大容量一括移行 | 物理配送を使うため、オンライン転送より大量初期移行に向きます。 |
| AWS DataSync | と AWS 間のオンラインデータ転送 | 継続同期や定期転送に向きます。ネットワーク接続が必要です。 |
| AWS Storage Gateway | オンプレミスから AWS ストレージを透過的に使う | 移行デバイスではなく、ハイブリッドストレージ連携です。 |
| AWS Direct Connect | オンプレミスと AWS の専用接続 | 回線サービスです。大量転送にも使えますが、すぐに物理移行する用途とは違います。 |
| S3 Transfer Acceleration | 遠距離から S3 へ高速アップロード | インターネット経由で転送できる前提です。 |
判断の軸は、データ量と時間です。例えば 500 TB を低速回線で送ると移行に長期間かかる場合、Snowball が候補になります。一方、毎日更新されるファイルを継続的に AWS へ同期したいなら DataSync が自然です。オンプレミスアプリから S3 やファイル共有を継続利用したいなら Storage Gateway、長期的に大容量通信の専用線が必要なら Direct Connect を考えます。
「回線で送れるかどうか」は感覚ではなく、データ量と期限から必要なを出して回線帯域と比べます。 データ量を移行期限で割った値が回線帯域に対して十分小さければ、ネットワーク経由の転送が成り立ちます。 例えば 10 Gbps の回線を業務と分け合いながら使う場合でも、数百 TB を数か月で送る要件なら理論上の所要日数は数日規模に収まるため、物理配送を待つ Snowball より DataSync の方が素直な選択になります。 逆に、必要スループットが回線帯域を上回る、あるいは帯域の大半を業務が使っていて空きがない場合は Snowball を選びます。
| 見積もる項目 | 求め方 | 判断ポイント |
|---|---|---|
| 必要スループット | データ量 ÷ 移行期限 | 回線帯域と比べる基準になります。 |
| 実効帯域 | 回線速度のうち移行に回せる分 | 業務トラフィックと共用する分を差し引きます。 |
| 移行中の差分 | 移行期間中に発生する変更量 | 業務を止められないなら差分同期の手段が要ります。 |
移行中も既存アプリケーションが読み書きを続ける要件では、初回転送のあとに差分だけを繰り返し送れる手段が必要です。 物理配送は返送と取り込みの間に生じた変更を自分で埋める作業が残るため、期限内に差分まで含めて追随したい場合は不利になります。
⚠️ 頻出: 「1 回だけ大量データを移す」は Snowball、「継続的に同期する」は DataSync、「オンプレミスから AWS ストレージをローカルのように使う」は Storage Gateway、「専用線で接続する」は Direct Connect と切り分けます。
⑥コスト、時間、運用計画
はデバイス利用料、配送、ジョブ期間、データ転送、運用作業などを含めて考えます。SAA では具体的な料金暗記よりも、ネットワーク転送にかかる時間と費用、物理配送のリードタイム、現地作業の手間を比較して判断します。
| コスト・時間要素 | 内容 | 設計上の注意 |
|---|---|---|
| デバイス台数 | データ量に応じて複数台が必要 | PB 級では並列に複数ジョブを使うことがあります。 |
| ローカル転送時間 | からデバイスへコピーする時間 | LAN 帯域やストレージ性能がボトルネックになります。 |
| 配送時間 | デバイスの受け取りと返送 | リアルタイム要件には向きません。 |
| 取り込み時間 | AWS 到着後に へ取り込む時間 | 後続処理の開始時点を見積もります。 |
| 運用作業 | 接続、ロック解除、検証、返送 | 手順と担当者を事前に決めます。 |
データ移行では、単に「大量だから Snowball」ではなく、移行後の増分同期も考えます。初回だけ Snowball で大容量を移し、その後の差分は やアプリケーション側の同期で送る、という組み合わせが現実的です。
⚠️ 頻出: Snowball は「最短で即時に使えるオンライン転送」ではありません。配送と現地作業があるため、リアルタイム性よりも、大容量移行を現実的な期間に収めることを重視する選択肢です。
試験対策
SAA では、 は移行サービスの選択問題で出ます。問題文に「ペタバイト級」「帯域が限られている」「インターネットでは移行に時間がかかりすぎる」「遠隔地や切断環境」「初期移行」というキーワードがあれば Snowball を候補にします。
| 問題文のキーワード | 優先して考えるサービス | 理由 |
|---|---|---|
| 数百 TB から PB 級を一括移行 | Snowball | 物理配送でネットワーク制約を回避できます。 |
| 回線が遅い、接続がない | Snowball | オフライン転送に向きます。 |
| 毎日または継続的にファイル同期 | オンラインで継続転送できます。 | |
| から をファイル共有のように使う | ハイブリッドストレージ連携に向きます。 | |
| 専用線で安定接続したい | ネットワーク接続サービスです。 | |
| S3 への遠距離アップロードを高速化 | S3 Transfer Acceleration | インターネット経由のアップロード高速化です。 |
| 現地でローカル処理も必要 | Snowball Edge / | 一時的な物理デバイスか常設基盤かで判断します。 |
よくある誤答は、低速回線で大量データを DataSync だけで送ろうとする選択肢です。DataSync は強力なオンライン転送サービスですが、ネットワーク帯域が根本的に足りない場合は物理移送の方が適切です。逆に、継続的な同期要件があるのに Snowball だけを選ぶのも不十分です。
Snowball と Direct Connect も混同しやすいです。Direct Connect はオンプレミスと AWS を専用接続するサービスで、長期的なハイブリッド接続に向きます。Snowball はデバイスを配送するため、初期移行や切断環境でのデータ収集に向きます。
エッジコンピューティング要件では、Snowball Edge、Outposts、Local Zones、 などを比較します。ネットワークが限られる場所で一時的にデータ収集や前処理をするなら Snowball Edge、オンプレミスに AWS インフラを常設したいなら Outposts、都市圏の低遅延なら Local Zones、5G 通信事業者網の低遅延なら Wavelength を考えます。
最新の実務判断では、公式ドキュメントの案内に従い、新規利用可否と代替サービスを確認します。Snowball Edge が新規顧客向けに利用できない場合、オンライン転送は DataSync、セキュアな物理転送は Data Transfer Terminal、エッジ基盤は Outposts などを検討します。試験学習では、問題文が従来の Snowball/Snowball Edge を前提にしているか、最新の代替サービスを問うているかを読み分けます。