AWS Storage Gateway

解決する課題

オンプレミスのストレージは容量の上限があり、増設には機器調達やデータセンターのスペース確保が必要です。一方で既存のアプリやワークフローは、いきなりクラウドストレージのAPIへ書き換えられないことが多くあります。Storage Gateway はその橋渡しを担います。

• オンプレの容量が逼迫しているが、アプリは改修したくない（既存のファイル共有やiSCSI接続のまま使いたい）
• バックアップやアーカイブをクラウドへ逃がして運用コストを下げたい
• 物理テープ装置を仮想テープに置き換えて、テープ運用そのものをなくしたい
• オンプレとクラウドの間でデータを段階的に移行したい

主要概念と用語

• ゲートウェイアプライアンス: オンプレに置く仮想マシン（VMware/Hyper-V/KVM）または専用ハードウェアアプライアンス。EC2上にも展開可能。アプリとクラウドストレージの仲介役
• S3 File Gateway: 既存のアプリからNFS/SMBでマウントし、書き込んだファイルをS3オブジェクトとして保存するタイプ
• FSx File Gateway: オンプレからAmazon FSx for Windows File Serverへ低レイテンシでアクセスするためのタイプ
• Volume Gateway: iSCSIのブロックボリュームを提供し、データをS3に保存するタイプ。キャッシュ型と保管型の2モードがある
• Tape Gateway（VTL）: 既存のバックアップソフトに対して仮想テープライブラリを見せ、テープの実体をS3やアーカイブ階層へ保存するタイプ
• キャッシュ: 頻繁にアクセスするデータをローカルに保持する領域。ヒットすれば低レイテンシで応答する
• キャッシュ型ボリューム: 実体はクラウド、ローカルにはキャッシュのみを置くモード
• 保管型ボリューム: 実体をすべてローカルに置き、非同期でクラウドへスナップショットするモード

仕様・制限・クォータ

• ゲートウェイはオンプレ仮想化基盤、ハードウェアアプライアンス、またはEC2上で稼働する
• 1つのゲートウェイで扱えるファイル共有数・ボリューム数・仮想テープ数には上限があり、タイプごとに異なる
• 各ゲートウェイには十分なローカルキャッシュ用ディスクとアップロードバッファの割り当てが必要
• クラウド側への通信は基本的に**HTTPS（TLS）**で行われる
• S3 File Gateway で作成したオブジェクトは対象バケットに直接見える形で保存される（バックエンドはS3）

内部の仕組み

ゲートウェイアプライアンスはオンプレのネットワーク内に置かれ、アプリからは標準プロトコル（NFS、SMB、iSCSI）で見える普通のストレージとして振る舞います。アプリが書き込んだデータはまずローカルのキャッシュへ入り、ゲートウェイが非同期でクラウドへアップロードします。読み取り時はキャッシュにあればローカルから即応答し、なければクラウドから取得してキャッシュに載せます。

この「ローカルキャッシュ＋クラウド実体」という構造により、利用者から見ると低レイテンシのローカルストレージでありながら、容量はクラウド側のほぼ無制限のスケールを使えます。アップロード時は転送量を抑えるための圧縮や、変化分のみを送る仕組みが働きます。

設計パターン / ベストプラクティス

• 既存ファイルサーバーの容量拡張: S3 File Gateway でNFS/SMB共有を提供し、コールドデータはS3へ。アプリ改修なしで容量を伸ばす
• オンプレバックアップのクラウド集約: Tape Gateway で既存バックアップソフトの出力先を仮想テープにし、テープ運用を廃止
• 段階的なクラウド移行: まずゲートウェイ経由でデータをS3に蓄積し、後からクラウドネイティブな処理へ移していく
• ライフサイクルとの併用: S3側のライフサイクルルールで、保存後のオブジェクトを低頻度アクセス層やアーカイブ層へ自動移行しコストを最適化
• キャッシュ容量はワーキングセットを基準に: アクセス頻度の高いデータ量を見積もり、余裕を持ってキャッシュディスクを割り当てる

運用・監視

• CloudWatch メトリクスでキャッシュヒット率、アップロード待ちのデータ量、I/O状況などを監視する
• キャッシュヒット率が低下したらキャッシュディスクの増設や利用パターンの見直しを検討
• アップロードバッファが詰まると書き込みがブロックされうるため、上り帯域とバッファ容量のバランスを確認
• ゲートウェイソフトのメンテナンス更新を定期的に適用する
• 重要なゲートウェイは、ホスト障害に備えてスナップショットや構成のバックアップを保持

コスト

• 課金は主にゲートウェイの利用と、クラウド側で実際に保存されるストレージ容量、そしてデータ転送で構成される
• 実体の保存先がS3などのため、保存コストはバックエンドのストレージクラスに従う
• S3のライフサイクルで低頻度アクセス層やアーカイブ層へ移すことで、長期保管のコストを下げられる
• クラウドからオンプレへ取り出す**読み出し（egress）**には転送料がかかるため、頻繁な大量取得が見込まれる用途は事前に試算する

セキュリティ

• クラウドへの通信はTLSで暗号化される
• バックエンド（S3など）の保存時暗号化はKMSで管理できる
• アクセス権限はIAMで制御し、ゲートウェイやバケットへの操作を最小権限に絞る
• SMB共有ではActive Directory連携によるユーザー認証が利用できる
• ゲートウェイアプライアンス自体もオンプレのネットワークセグメントやファイアウォールで保護する

Well-Architected の観点

• 信頼性: 実体をクラウドの高耐久ストレージに保存し、オンプレ機器の故障からデータを守る。バックアップ・アーカイブの集約先として堅牢
• コスト最適化: オンプレ増設の代わりにクラウド容量を従量利用。ライフサイクルでアーカイブ層へ移し長期保管費を圧縮
• パフォーマンス効率: ローカルキャッシュで頻出データを低レイテンシ提供しつつ、容量はクラウドにスケールさせる
• セキュリティ: 転送・保存の暗号化、IAMによる最小権限、AD連携での認証

試験で問われるポイント

関連サービス・比較

オフラインでの大容量データ移送に使う AWS Snowball とよく対比されます。Storage Gateway は継続的なオンライン接続、Snowball は一回限りの物理輸送という役割の違いを押さえます。

ハンズオン / CLI例

# 登録済みのゲートウェイ一覧を確認
aws storagegateway list-gateways

# S3 File Gateway 上に NFS ファイル共有を作成（保存先バケットを指定）
aws storagegateway create-nfs-file-share \
  --client-token $(uuidgen) \
  --gateway-arn arn:aws:storagegateway:ap-northeast-1:123456789012:gateway/sgw-XXXXXXXX \
  --location-arn arn:aws:s3:::my-fileshare-bucket \
  --role arn:aws:iam::123456789012:role/StorageGatewayS3AccessRole

# 作成済みファイル共有の一覧
aws storagegateway list-file-shares \
  --gateway-arn arn:aws:storagegateway:ap-northeast-1:123456789012:gateway/sgw-XXXXXXXX