Cloud Service
AWS Snowball Edge
テラバイト〜ペタバイト級のデータを物理デバイスで安全に移送し、回線が細くても短期間で移行できる。エッジでの計算も担えるオフライン移送アプライアンス。
- 1.頑丈な物理デバイスにデータをコピーして輸送し、ネットワークに依存せず大容量データを移行できる
- 2.ストレージ最適化と計算最適化のタイプがあり、エッジ側でEC2やLambdaの処理も実行できる
- 3.回線が細い・現場がオフライン・短期間で移行したい、といった大容量移送の課題に向く
AWS Snowball Edge は、頑丈な物理デバイスにデータをコピーして輸送することで、ネットワーク回線に頼らず大容量データを AWS へ移行するためのオフライン移送アプライアンスです。あわせて、デバイス上で計算処理を実行できるため、回線が細い拠点や接続が不安定な現場でのデータ収集・前処理にも使われます。
解決する課題
数十テラバイトから数ペタバイトに及ぶデータを限られた回線でクラウドへ送ると、転送に数週間から数か月かかることがあります。途中で回線が詰まれば業務にも影響し、転送コストもかさみます。Snowball Edge はこの「太い回線がないのに大容量を動かしたい」という課題を、物理輸送という手段で解決します。
- 回線が細い、または不安定で、大容量データをオンラインで送りきれない
- データセンター閉鎖やクラウド移行で、短期間にまとまった量を移したい
- 工場・船舶・遠隔地など、接続が乏しい現場でデータを収集・前処理したい
- 機微なデータを、物理デバイスで暗号化したまま安全に移送したい
主要概念と用語
- Snow ファミリー: 物理デバイスでデータ移送やエッジ計算を行う一連のサービスの総称。用途や容量に応じて複数の形態がある
- Snowball Edge Storage Optimized: ストレージ容量を重視したタイプ。主に大容量のデータ移行に向く
- Snowball Edge Compute Optimized: 計算リソースを重視したタイプ。エッジでの処理やGPUを伴うワークロードに向く
- ジョブ: デバイスの注文から返送までの一連の作業単位。インポート(オンプレからクラウドへ)とエクスポート(クラウドからオンプレへ)の方向がある
- OpsHub: デバイスをGUIで管理・操作するためのアプリケーション。CLIやAPIの代わりに視覚的に操作できる
- エッジコンピューティング: デバイス上でEC2インスタンスやLambda関数を動かし、移送前にデータをフィルタ・変換する仕組み
- E Ink ラベル: デバイス側面の電子ペーパー表示。返送時に宛先が自動で切り替わり、誤配送を防ぐ
仕様・制限・クォータ
- デバイスは頑丈な筐体で、輸送中の振動・衝撃に耐える設計になっている
- 容量はタイプによって異なり、ストレージ最適化タイプほど多くのデータを格納できる
- 1ジョブあたりに扱える容量には上限があり、それを超える場合は複数台を並行して使う(クラスター構成も可能)
- デバイス上ではS3互換のエンドポイントやNFSでデータを書き込める
- 計算最適化タイプでは、デバイス上でEC2互換のインスタンスを起動できる
- 具体的な容量・台数上限・対応リージョンは変動し得るため、利用前に公式ドキュメントで最新値を確認する
オンラインで送るか物理移送にするかは、回線速度とデータ量で決まります。同じ容量でも、細い回線なら物理輸送のほうが短期間で安全に終わることが多くあります。
内部の仕組み
ジョブを作成するとAWSからデバイスが発送されます。利用者はオンプレのネットワークにデバイスを接続し、S3互換のインターフェースやファイル共有経由でデータをコピーします。書き込まれたデータはデバイス内で暗号化され、コピーが完了したら電源を落として返送します。
返送されたデバイスはAWSのデータセンターで受領され、中のデータが指定のS3バケットへ取り込まれます。取り込みが終わるとデバイスは安全に消去され、次のジョブに回されます。E Ink ラベルにより返送先が自動表示されるため、宛名の貼り替えが不要です。
計算最適化タイプでは、デバイス上でEC2インスタンスやLambdaを動かし、移送する前にデータをフィルタ・集計・変換できます。これにより、現場で生成された生データのうち必要な部分だけを抽出してから運ぶ、といった使い方ができます。
単なる「運ぶ箱」ではなく、現場でデータを絞り込んでから運べるのが計算最適化タイプの価値です。送る量そのものを減らせます。
設計パターン / ベストプラクティス
- データセンター閉鎖に伴う一括移行: 細い回線で送りきれない大容量を、複数台のデバイスに分けて並行コピーし短期間で移送する
- 遠隔地・オフライン現場での収集: 接続が乏しい拠点でデータを蓄積し、計算最適化タイプでフィルタしてから運ぶ
- 継続移送とのすみ分け: 一回限りの大量移送はSnowball Edge、常時のハイブリッド接続は Storage Gateway や DataSync、と役割で使い分ける
- 取り込み先の整理: インポート先のS3バケットやプレフィックス、ライフサイクルを事前に設計し、取り込み後すぐ整理できる状態にしておく
- 複数台の並行運用: 単一デバイスの容量を超えるなら、ジョブを分割し並行して進めることで全体の移送期間を短縮する
運用・監視
- ジョブの状態(発送・到着・コピー中・返送・取り込み完了)をマネジメントコンソールで追跡する
- 取り込み完了後は、取り込まれたオブジェクト数や容量を確認し、移送漏れがないか突き合わせる
- デバイス操作はOpsHubのGUI、または専用のクライアント・APIで行う
- エッジで計算を行う場合は、デバイス上のインスタンスやログの状態を監視し、処理が滞っていないか確認する
- 大量データのコピーは時間がかかるため、並列コピーや十分な性能のホスト・ネットワークを用意して書き込み速度を確保する
デバイスには標準の利用日数が設定されており、超過すると追加料金が発生し得ます。コピー作業のスケジュールに余裕を持たせ、返送期限を守ってください。
コスト
- 課金は主にジョブごとの利用料金と、標準日数を超えた追加の利用日数、そして**輸送(配送)**で構成される
- オンライン転送の転送料と異なり、物理移送では回線の太さに左右されずコストを見積もれる
- 取り込み先のS3に保存されたデータには、通常どおりS3のストレージ料金がかかる
- 細い回線で長期間オンライン転送する場合と比べ、大容量では物理移送のほうが総コストと所要時間で有利になりやすい
大容量移行では、オンライン転送にかかる時間・帯域の占有・転送料を、物理移送のジョブ料金と並べて比較すると判断しやすくなります。
セキュリティ
- デバイス内のデータは保管時に暗号化され、鍵はKMSで管理できる
- デバイスのロック解除には専用の認証情報が必要で、盗難・紛失時もデータを保護する
- 取り込み完了後、デバイスは安全に消去されてから次のジョブに使われる
- アクセス権限はIAMで制御し、ジョブの作成や取り込み先バケットへの操作を最小権限に絞る
- E Ink ラベルと頑丈な筐体により、輸送中の誤配送や物理的な改ざんのリスクを下げる
- 「回線が細く大容量データを短期間で移行したい」→ オンライン転送ではなく Snowball Edge(物理移送)
- 「常時接続でオンプレとクラウドを橋渡ししたい」→ Snowball Edge ではなく Storage Gateway
- 「オンライン転送を自動化・スケジュール化したい」→ AWS DataSync
- キーワードはオフライン物理移送・回線非依存・エッジ計算
関連サービス・比較
オンラインでの大容量転送に使う AWS DataSync とよく対比されます。Snowball Edge は回線に依存しない物理移送で一回限りの大量移行に向くのに対し、DataSync は回線を使ったオンライン転送を自動化・継続実行するのに向きます。回線の太さとデータ量、移送が一回限りか継続かで使い分けます。
| 観点 | Snowball Edge | AWS DataSync |
|---|---|---|
| 移送方式 | 物理デバイスを輸送 | ネットワーク経由でオンライン転送 |
| 回線への依存 | 回線が細くても物理輸送で完結 | 回線の太さに転送時間が依存 |
| 主な用途 | 一回限りの大容量移行・エッジ計算 | 継続的・反復的なオンライン転送 |
| エッジ処理 | デバイス上で計算・前処理が可能 | 転送の最適化が中心で計算はしない |
ハンズオン / CLI例
# 1. インポートジョブ(オンプレからS3へ取り込む)を作成
aws snowball create-job \
--job-type IMPORT \
--resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::my-import-bucket"}]}' \
--address-id ADID00000000-0000-0000-0000-000000000000 \
--role-arn arn:aws:iam::123456789012:role/SnowballImportRole \
--snowball-type EDGE_S \
--shipping-option SECOND_DAY
# 2. ジョブの状態を確認
aws snowball describe-job --job-id JID00000000-0000-0000-0000-000000000000
# 3. アカウント内のジョブ一覧を表示
aws snowball list-jobs
AWS Service
AWS Snowball Edgeを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ストレージ
比較で見る軸
クラウド: AWS / カテゴリ: ストレージ / 難易度: intermediate
導入後に効く点
ストレージ最適化と計算最適化のタイプがあり、エッジ側でEC2やLambdaの処理も実行できる
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- ストレージ
- 難易度
- intermediate
- 関連資格
- SAA-C03 / SOA-C02
- 設計柱
- cost / performance / security
判断チェックリスト
- 自社の用途が「ストレージ / cost」に近いか確認する。
- 強みである「頑丈な物理デバイスにデータをコピーして輸送し、ネットワークに依存せず大容量データを移行できる」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。