Storage Gateway は「オンプレミスの既存システムと AWS ストレージをつなぐ」ためのサービス群です。ファイル共有をそのままクラウドに寄せたいのか、ブロックストレージとして扱いたいのか、テープ運用を残したままアーカイブしたいのか――この“入口の違い”が、そのまま File / Volume / Tape の選び分けになります。
一方で、SAA-C03 学習者として最初に知っておきたいのは、SAA-C03 試験ガイドでは Storage Gateway が「範囲外のサービス例」として挙げられている点です。
つまり「Storage Gateway の細かな手順暗記」は優先度が上がりにくいです。ただし、ハイブリッド構成の考え方（オンプレ要件を保ちつつ S3/FSx/EBS/Glacier を使い分ける発想）は、周辺テーマの設計判断で役に立ちます。そこでこの記事は、出題“されうる問われ方”に耐えるレベルの整理に絞ってまとめます。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
Storage Gateway を一言で言うと何か
Storage Gateway は、オンプレや社内ネットワーク側から見える“いつものアクセス方法”を保ちながら、実体の保存先を AWS に寄せられるゲートウェイです。
よくある設問の形は、サービス名を直接聞くというより、次のように 要件で分岐させてきます。
- 既存アプリは NFS/SMB の共有フォルダ前提。保存先は S3（または FSx）に寄せたい
- 既存サーバーは iSCSI のブロックとして認識したい。スナップショットも取りたい
- 既存のバックアップ製品が **テープ運用（VTL）**前提。テープをクラウド保管し、長期は Glacier に落としたい
ここで迷わないために、まず「何を“見せる”サービスか」を先に押さえるのがコツです。
- File Gateway：オンプレからは ファイル共有に見える（NFS/SMB）
- Volume Gateway：オンプレからは iSCSI ボリュームに見える（ブロック）
- Tape Gateway：オンプレからは **仮想テープライブラリ（VTL）**に見える（iSCSI）
File Gateway が問われるときの読み取り方
File Gateway は「共有フォルダ運用を大きく変えずに、クラウドへ逃がす」発想の問題で登場しやすいタイプです。
S3 File Gateway の要点
S3 File Gateway は、オンプレのクライアントから NFS/SMB で書き込まれたファイルを、データは S3 オブジェクトとして保存し、メタデータも S3 側に反映します。ローカルにはキャッシュを持ち、よく触るデータのレイテンシを抑えます。
**設問での“ひっかかりどころ”**はここです。
- 「ファイルサーバーに見える」＝ EFS ではなく、S3 をファイル共有っぽく使う選択肢がある
- ただし実体は S3。アクセス制御・暗号化・監査は IAM/KMS/CloudWatch/CloudTrail など AWS 側の仕組みと組み合わせる
- S3 の性質（オブジェクト、バージョニング等）を前提に、ファイル更新時の挙動が気になるケースがある
FSx File Gateway の要点
FSx File Gateway は、主に FSx for Windows File Server をバックエンドにして、オンプレから SMB アクセスする構成を取りやすいゲートウェイです。Active Directory 連携が前提に出てくることが多く、「Windows 共有＋ドメイン運用」の匂いがしたら候補になります。
File Gateway 系の典型シナリオ
- 既存アプリやバックアップスクリプトが「共有フォルダへの書き込み」前提で、S3/FSx に集約してコストと運用を軽くしたい
- 拠点からのアクセスがあるので、ローカルキャッシュで体感速度を落としにくくしたい
ついでに知っておくと安心な最新事情
以前は Storage Gateway のハードウェアアプライアンスという選択肢もありましたが、**提供終了（2025/5/12）**が明記されています。設計の前提として「今は VM/EC2 での導入が中心」と捉えるのが安全です。
Volume Gateway が問われるときの読み取り方
Volume Gateway は「オンプレのサーバーに iSCSI のボリュームとして見せたい」問題で整理するとブレません。
Cached volumes と Stored volumes の違い
Volume Gateway には代表的に次の 2 形態があります。
- Cached volumes：主データは S3。頻繁に使う部分だけローカルに保持して低レイテンシを狙う
- Stored volumes：主データをローカルに保持しつつ、AWS 側にもバックアップ目的で保存（スナップショット等）していく考え方（オンプレ容量を厚めに持つ）
※SAA-C03 ではこのレベルの“違いの言語化”ができれば十分で、容量上限や細かい運用手順まで暗記する優先度は上げにくいです。
ありがちな設問パターン
- オンプレアプリがブロックデバイス前提で、クラウドへ段階移行したい
- DR を意識して、ボリュームの状態を AWS 側へ寄せておきたい
- 「S3 を主にしてオンプレを軽くしたい」のか「オンプレを主にしてクラウドへバックアップしたい」のか、文章がどちらを指しているかを見抜かせる
ここは、“どちらが主ストレージか”を一文で言い切るとミスが減ります。
Tape Gateway が問われるときの読み取り方
Tape Gateway は「テープ運用を捨てられない事情」を読み取れるかが勝負です。
Tape Gateway は、既存のテープベースのバックアップソフトから見ると **VTL（仮想テープライブラリ）**として動作し、テープやドライブは iSCSI デバイスとして見えます。
何がうれしいのか
- 物理テープの調達・保管・搬送・保守の手間を減らしつつ、運用手順は大きく変えにくい
- 書き込んだ“仮想テープ”の実体は S3 に保存される
- 長期保管は Glacier Flexible Retrieval / Deep Archive へアーカイブできる、という説明が公式ドキュメントにある
典型シナリオ
- 既存バックアップが「テープ」を前提に組まれていて、いきなりバックアップ製品や手順を総入れ替えできない
- 監査やコンプライアンスで「長期保管」「取り出しは低頻度」が要件にある
- それでも保管コストと運用負荷を下げたい
Tape Gateway は単体暗記よりも、「テープ前提の世界観が文章に滲んでいるか」を嗅ぎ分けるのがポイントです。
File Volume Tape を設計判断で切り分けるコツ
最後に、試験でも実務でも使える“判断の軸”に落としておきます。
まずプロトコルで切る
- NFS/SMB の共有：File Gateway（S3 または FSx）
- iSCSI のブロック：Volume Gateway
- VTL のテープ：Tape Gateway
次に主ストレージがどこかで詰める
- 「オンプレ容量を減らして、クラウドを主にしたい」：File Gateway（S3）や Volume Gateway（cached）側の発想
- 「オンプレを主にしつつ、クラウドに保護コピーを持ちたい」：Volume Gateway（stored）や Tape Gateway の発想
学習の進め方
SAA-C03 観点では、Storage Gateway 自体の深掘りよりも、S3/EBS/FSx/Glacier といった“バックエンドのストレージ”を中心に理解しておくと、周辺の設計問題にもつながりやすいです（試験ガイドの範囲感も踏まえた現実的な戦い方です）。
そのうえで、「ハイブリッド構成を体系的に一周したい」場合は、Udemy の SAA-C03 対策講座の中でもストレージ設計（S3、EBS、EFS、FSx、バックアップ/アーカイブ）を丁寧に扱うコースを選ぶと、Storage Gateway を“暗記”せずに位置づけとして理解しやすくなります。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
Storage Gateway は、オンプレのアクセス方法を保ちながら AWS のストレージに寄せるためのサービス群で、File は共有フォルダ、Volume は iSCSI ブロック、Tape は VTL テープという「見せ方」の違いで整理すると迷いにくくなります。
SAA-C03 では試験ガイド上、Storage Gateway 自体は範囲外の例として挙げられているため、手順や細部の暗記に寄り過ぎないのが現実的です。
ただし、問題文に出てくる要件（NFS/SMB、iSCSI、テープ運用、長期保管、ローカルキャッシュ）から「どの世界観の話か」を見抜けると、ストレージ設計の判断が一段ラクになります。
