AWS Storage Gatewayは、オンプレミスのサーバーやバックアップソフトから見える「いつものファイル共有・いつものディスク・いつものテープ装置」の顔をしたまま、裏側の保存先をAWSのストレージへ差し替えるサービスです。アプリケーションのコードや運用手順を書き換えずに置き場所だけをクラウドへ寄せられるため、オンプレミス環境を一気に捨てられない現場の移行手段になります。この記事では、2026年時点で新規に構築できる3種類のゲートウェイの違い、構成の天井を決めるクォータ、段階的に移行する組み立て方を実装者の目線で整理しました。移行全体の戦略はAWS移行の7R戦略で補完してください。
まとめ：Storage Gatewayは既存プロトコルを変えずに保存先だけをAWSへ寄せる橋渡し
Storage Gatewayの本質は、プロトコル変換装置です。オンプレミス側にはNFS・SMB・iSCSI・仮想テープという枯れたインターフェースを見せ、クラウド側ではS3のオブジェクト操作やEBSスナップショットへ変換します。既存の利用者やバックアップソフトから見れば、接続先が手元のアプライアンスに変わっただけです。
2026年9月時点で新規に構築できるのは、S3 File Gateway・Volume Gateway・Tape Gatewayの3種類です。4本柱の一角だったFSx File Gatewayは2024年10月28日以降、新規の利用者が作成できなくなりました。物理筐体のハードウェアアプライアンスも2025年5月12日で提供が終わり、配置形態は仮想アプライアンスかEC2インスタンスの2つに絞られます。古い解説記事のまま設計すると、構成図が最初から成立しません。
判断の軸は、アプリケーションがどのプロトコルで話すかという一点から始まります。そのうえでローカルにデータ全量を置く必要があるか、回線の上り帯域が日次の増分に追いつくかを順に詰めてください。恒久的な基盤として据え置くのではなく、AWSネイティブのストレージへ移るまでの橋として期間を区切って使う位置づけが、費用と運用の両面で噛み合います。
Storage Gatewayの定義と、プロトコル変換で橋渡しする仕組み
まず、このサービスがどこに置かれ、何を何に変換しているのかを押さえます。
オンプレミスのNFS・SMB・iSCSIをAWSストレージの操作に変換する
Storage Gatewayは、利用者のデータセンターやオフィス内に置いたゲートウェイアプライアンスと、AWS側のマネージドなサービス基盤の組み合わせで動きます。アプライアンスはファイル共有やiSCSIターゲットとして振る舞い、受け取った書き込みを非同期でAWSへ転送する構造です。転送先はゲートウェイの型で変わり、ファイル系ならS3のオブジェクト、ブロック系ならS3上のボリュームスナップショットになります。
この変換で肝になるのが、ローカルディスクに割り当てる「キャッシュ」と「アップロードバッファ」です。キャッシュは直近に読み書きしたデータを手元に残す領域、アップロードバッファはAWSへ送り切るまでの書き込みを受け止める領域を指します。上り帯域が細い環境でバッファを小さく取ると、書き込みが詰まってアプリケーション側の遅延として表面化します。
保存先がオブジェクトストレージになると、ファイルの部分更新がオブジェクトの再アップロードとして扱われる場面も出てきます。オブジェクトストレージの仕組みを押さえておけば、大きなファイルを頻繁に上書きする処理で性能が伸びない理由を説明できます。
配置形態はVMアプライアンスとEC2の2つ・ハードウェアは提供終了
ゲートウェイの実体は、VMware ESXi・KVM・Microsoft Hyper-Vのいずれかで動く仮想アプライアンス、またはAWS上のEC2インスタンスとして配置します。オンプレミスのデータをクラウドへ送る用途なら手元のハイパーバイザ上に、AWS上のワークロードへオンプレミス互換のインターフェースを見せたい場合やディザスタリカバリ用途ならEC2上に置く使い分けです。
かつては第3の選択肢として、ソフトウェアを事前導入した1Uサーバーのハードウェアアプライアンスがありました。こちらは2025年5月12日をもって提供が終了し、既存の利用者は2028年5月までサポートを受けられます。ハードウェア込みで提案されている構成図を見かけたら、その資料は更新が止まっていると判断してください。
2026年時点で新規に構築できるゲートウェイの3種類を整理する
公式ドキュメントは今もS3 File Gateway・FSx File Gateway・Tape Gateway・Volume Gatewayの4分冊ですが、新規に作れるのは3種類です。
S3 File GatewayはNFS・SMB共有をS3のオブジェクトに書き出す
S3 File Gatewayは、ローカルにNFSまたはSMBのファイル共有を公開し、そこへ書き込まれたファイルを1対1でS3オブジェクトへマッピングします。ファイル名がそのままオブジェクトキーになるため、AWS側からはS3 APIで直接読め、S3へ置いたオブジェクトをファイル共有側から参照することもできます。ログの集約先や解析パイプラインへの受け渡し口として使われる型です。
クォータは実装上の制約として効いてきます。1つのゲートウェイに作れるファイル共有は50まで、単一ファイルの上限は5TiB、パス長は1,024文字まで。メタデータのキャッシュ容量はゲートウェイのサイズ設定で決まり、Smallで500万・Mediumで1,000万・Largeで2,000万ファイルが目安になります。数千万件の小さなファイルを抱えた既存ファイルサーバーをそのまま乗せると、この上限に先に当たります。
プロトコルはクライアントの構成で決まり、LinuxやUNIX系の資産が中心ならNFS、Windowsのファイルサーバー置き換えならSMBを選び、後者はActive Directory連携でアクセス制御を引き継げます。書き出し先のAmazon S3側でストレージクラスとライフサイクルを同時に設計しておけば、保管費用が後から膨らむ事態を避けられるはずです。
Volume GatewayはiSCSIボリュームをキャッシュ型と保管型で提供する
Volume Gatewayは、アプリケーションサーバーからiSCSIデバイスとしてマウントできるブロックボリュームを提供します。対象はファイル共有ではなくブロックデバイスを要求するデータベースや業務アプリケーションです。取得したポイントインタイムのスナップショットはS3上に保持され、EBSボリュームとして復元してEC2へアタッチできるため、オンプレミスのサーバーをAWS上で立ち上げ直すディザスタリカバリの受け皿になります。
ボリュームの構成には、キャッシュ型と保管型の2つのモードがあります。キャッシュ型はデータの本体をS3に置き、頻繁に触る部分だけを手元に残す方式で、ローカルのディスク購入量を減らせる構成です。保管型はデータ全量をローカルディスクに保持し、そのスナップショットを非同期でAWSへ送るため、読み出しは常にローカル速度で返ります。
両者はクォータも異なり、キャッシュ型は1ボリューム最大32TiB・32本・合計1,024TiB、保管型は1ボリューム最大16TiB・32本・合計512TiBです。16TiBを超えるキャッシュ型のスナップショットは、Storage Gatewayのボリュームには戻せてもEBSへは復元できません。EBSへの展開を復旧手段に据えるなら、1ボリュームを16TiB以内に収める分割設計が要ります。
Tape Gatewayは仮想テープライブラリで既存のテープ運用を残す
Tape Gatewayは、既存のバックアップソフトウェアから見て物理テープライブラリと同じiSCSI接続のVTL（仮想テープライブラリ）として振る舞います。バックアップジョブの定義もテープのローテーション運用もそのままに、実体だけがS3とアーカイブ用のストレージクラスへ移る形です。テープ装置の保守費用とメディア交換の人手を止めたいが、バックアップソフトの入れ替えには踏み込めない現場に向きます。
仮想テープは1本100GiBから15TiBで作成でき、1つのゲートウェイに割り当てられるのは1,500本・合計1PiBまで。アーカイブへ送り出したテープの本数と総容量に上限はありません。ローカルディスクの推奨値はキャッシュが150GiBから64TiB、アップロードバッファが150GiBから2TiBで、下限を下回る構成は成立しません。
アーカイブ層に置いたテープは取り出しに時間がかかり、所要時間は選択したクラスで変わります。Amazon S3 Glacierの取り出し時間を確認し、自社のRTO（目標復旧時間）と突き合わせてください。「安いから深いアーカイブへ」と機械的に倒すと、復旧の場面で数時間待つことになります。
FSx File Gatewayは2024年10月28日以降に新規作成できない
FSx File Gatewayは、クラウド上のAmazon FSx for Windows File Serverの共有に対して、オンプレミス側からキャッシュ付きで低遅延にアクセスするための型でした。2024年10月28日をもって新規の利用者による作成が停止されており、すでに構築済みの環境は影響を受けず、セキュリティ更新とサポートも継続されます。
これから同じ要件を満たす経路は2つです。1つはオンプレミスからAmazon FSx for Windows File Serverへ直接接続する構成で、回線コストの低下によって現実的になったという判断が背景にあります。もう1つは、ローカルキャッシュが要る場合にFSx for NetApp ONTAPのFlexCacheやGlobal File Cacheでキャッシュ層を作る構成です。
3種類のゲートウェイの使い分けを決める判断軸とクォータの上限
型の選定は既存システムの制約から機械的に決まります。上から順に3つの問いを通せば、選択肢は1つに絞れます。
一次分岐はアプリケーションが話すプロトコルの種類によって決まる
最初の問いは、データを書いている主体が何のインターフェースを要求しているかです。ファイル共有として読み書きしているならS3 File Gateway、ブロックデバイスとしてマウントしているならVolume Gateway、バックアップソフトがテープ装置を掴んでいるならTape Gatewayになります。ここで無理に型を変えるとアプリケーション側の改修が発生し、コードを触らずに保存先だけ移すという利点が消えます。
次の問いは、AWS側でそのデータをどう使うかです。オブジェクトとしてS3から直接読み、解析や機械学習の入力にしたいならS3 File Gatewayの一択になります。Volume GatewayとTape Gatewayの書き出しは固有形式でS3に格納されるため、外部から中身をオブジェクトとして扱えません。データの二次利用まで見据えるなら、この差が型の選定を左右します。
キャッシュ型と保管型はデータ全量をローカルに置くかどうかで分かれる
Volume Gatewayを選んだ場合、次に決めるのがボリュームのモードです。基準は、読み出しの待ち時間に対する要求と、ローカルに確保できるディスク容量の2つ。全データへのミリ秒単位のアクセスが業務要件で、かつ手元に全量ぶんのディスクがあるなら保管型、ディスク投資を圧縮したくアクセスが特定の範囲に偏っているならキャッシュ型を選びます。
実務で誤りやすいのは、キャッシュ型のヒット率を楽観視する場面です。キャッシュから外れたブロックの読み出しはS3への往復になるため、アクセスが薄く広がる処理では体感性能が落ちます。直近30日で触られたデータ量を実測し、その容量をキャッシュとして確保できるかを先に確かめてください。
ゲートウェイごとに決まるクォータが実現できる構成の天井になる
3つ目の問いは、扱うデータ量とファイル数がクォータの内側に収まるかです。以下は2026年9月時点の主要な上限値で、設計の初期段階で突き合わせておくと後からゲートウェイを分割する手戻りを防げます。
| 観点 | S3 File Gateway | Volume（キャッシュ型） | Volume（保管型） | Tape Gateway |
|---|---|---|---|---|
| 単位あたり上限 | 1ファイル5TiB | 1ボリューム32TiB | 1ボリューム16TiB | 1本100GiB〜15TiB |
| 1GWあたりの数 | ファイル共有50 | ボリューム32本 | ボリューム32本 | テープ1,500本 |
| 1GWの合計容量 | 実質S3の容量に依存 | 1,024TiB | 512TiB | 1PiB |
| 件数の制約 | キャッシュ最大2,000万 | 規定なし | 規定なし | アーカイブは上限なし |
| 主な用途 | ファイル共有の移行 | DR・ブロック延伸 | 低遅延の全量保持 | テープ運用の置換 |
ファイル共有50という上限は、部署ごとに共有を切っている組織で先に当たります。共有の粒度を見直すか、ゲートウェイを複数台に分ける前提で台数を見積もってください。上限値はサービス側の更新で変わり得るため、設計を固める直前に公式のクォータ表を再確認します。
Storage Gatewayでオンプレミスから段階的にAWSへ移行する構成
このサービスがもっとも効くのは、一度に全部を切り替えられない移行案件です。影響範囲の小さい順に保存先を差し替え、最後にゲートウェイ自体を外す3段階を示します。
段階1ではバックアップとアーカイブの出力先だけを先に差し替える
最初に手を付けるのは、バックアップとアーカイブです。本番の読み書き経路に触らないため、失敗しても業務が止まりません。テープ装置を使っているならTape Gatewayに差し替え、ディスクへの出力なら共有先をS3 File Gatewayへ向けるだけで、テープメディアの購入と遠隔地保管の手間が消えます。
この段階で確認したいのは、日次の増分データ量を上り帯域が捌き切れるかどうかです。夜間バックアップのウィンドウ内に転送が終わらないと、アップロードバッファに滞留して翌日の業務時間帯へ食い込みます。初回のフルバックアップだけは転送量が桁違いになる点も計画に織り込んでください。
段階2ではファイルサーバーの実体をS3へ寄せて入口だけを残す
次に、部門ファイルサーバーの実体をS3へ移します。利用者から見えるドライブレターやUNCパスは変えず、SMB共有の提供元だけをS3 File Gatewayに置き換える形です。既存のアクセス権をActive Directory連携で引き継げるため、周知は「保存先サーバーが変わりました」程度で済みます。
ここで効いてくるのがS3側のライフサイクル設計です。一定期間アクセスがなければ低頻度アクセス層やアーカイブ層へ落とす規則を先に決めておけば、ファイルサーバーの容量が毎年積み上がる問題を構造的に解けます。
段階3ではゲートウェイを外してAWSネイティブの構成へ移行する
最終段階は、ゲートウェイを構成から抜くことです。アプリケーションをEC2やコンテナへ移したなら、ファイル共有はAmazon EFSやFSx for Windows File Serverへ、ブロックデバイスはEBSへ、オブジェクトアクセスはS3 SDKの直接呼び出しへ切り替えます。変換層が不要になり、ゲートウェイの月額と手元のハイパーバイザの維持費を落とせます。
段階3へ到達しないまま変換層を数年放置している現場は珍しくありません。段階1の時点で「いつゲートウェイを外すか」の条件を移行計画に書き込めば、先送りの力学に抗えます。上り帯域が足りない場合は、AWS Direct Connectの専用線を併用して転送の安定性を確保してください。
Storage Gatewayを採用すべき要件と見送るべき場面の判断
ここからは、どの解説記事も踏み込まない採用可否の線引きを、条件付きで言い切ります。
Storage Gatewayを採用してよい3つの条件を整理する
第1の条件は、書き込み側のアプリケーションやバックアップソフトに手を入れられないことです。パッケージ製品でソースがない、検証工数を確保できない、ベンダー保守の条件で構成変更が縛られている。こうした事情があるなら、インターフェースを保ったまま保存先を移せる価値が費用を上回ります。
第2の条件は、オンプレミス側にデータの実体を残す必要が当面あることです。工場や店舗のように現地で完結する読み書きが多い環境なら、キャッシュや保管型ボリュームでローカル性能を担保しつつ遠隔地バックアップだけクラウドへ寄せる構成が噛み合います。
第3の条件は、移行の期限が切られていることです。ハードウェア保守の期限やデータセンターの契約満了といった締切がある案件では、全システムの作り替えを待たず保存先だけ先行して移せる手段が要ります。外部と組んで進めるなら、AWSのインフラ構築支援のように既存環境の調査と移行手順の設計をまとめて引き受けられる体制を選ぶと、段階1で止まるリスクを下げられます。
見送るべき場面と、コストをゲートウェイ料金と保存先で見積もる方法
見送るべき筆頭は、新規に作るシステムです。これから書くアプリケーションなら最初からS3 SDKやEFSを直接叩けばよく、変換層を挟む理由がありません。ゲートウェイの運用・監視・バージョン更新という仕事を初日から背負い込むだけです。
2つ目は、一度きりの大容量データ移送です。数十TB以上を1回だけ運ぶなら、回線で流すより物理デバイスで送るほうが速く安く済みます。AWS Snowballの現行デバイスと移行手段を先に検討し、継続的な同期が要る場合にだけゲートウェイを選んでください。3つ目は恒久的な一次ストレージとして据える構想で、変換層が残る限りキャッシュミス時の遅延とローカル機材の維持費も残り続けます。
費用は2階建てで見積もります。ゲートウェイ側は書き込んだデータ量に応じた課金で、1台あたり月額125.00 USDが上限。アカウントごとに初回100GBぶんの書き込みは無料で、同一リージョン内のEC2ベースゲートウェイ宛ての転送は0.00 USD/GBです。ここに保存先であるS3やアーカイブクラスの保管料・リクエスト料・取り出し料が積み上がります。上限が決まっているぶんゲートウェイ側は読みやすく、変動要因は保存先の設計にほぼ集中する構造です。金額は2026年9月時点の公開情報にもとづくため、契約前に最新の料金表で再計算してください。
AWS Storage Gatewayの導入検討でよくある質問
設計と見積もりの場面で繰り返し挙がる論点を、実装の観点から答えます。
ゲートウェイの種類はいくつありますか？
公式ドキュメントはS3 File Gateway・FSx File Gateway・Tape Gateway・Volume Gatewayの4分冊ですが、2026年9月時点で新規に作成できるのは3種類です。FSx File Gatewayは2024年10月28日以降、新規の利用者による作成が停止されました。「4種類から選べる」と書かれた資料は更新時点が古いと考えてください。
キャッシュ型と保管型のボリュームはどちらを選ぶべきですか？
データ全量に低遅延のアクセスが要り、その容量ぶんのローカルディスクを用意できるなら保管型、ディスク投資を抑えたくアクセスが直近のデータに偏っているならキャッシュ型です。16TiBを超えるキャッシュ型のスナップショットはEBSへ復元できないため、EBSでの復旧を前提にするなら1ボリュームを16TiB以内に収めてください。
オンプレミスの回線が細くても導入できますか？
継続的な増分データ量が上り帯域に収まるなら導入できます。危険なのは初回の全量転送で、ここは物理デバイスでの持ち込みを併用するのが定石です。日次の増分を送り切れないとアップロードバッファに滞留するため、帯域の増強か対象データの絞り込みを先に済ませます。
ハードウェアアプライアンスはまだ購入できますか？
できません。2025年5月12日をもって提供が終了しています。導入済みの環境は2028年5月までサポートを受けられますが、新規調達の選択肢からは外れました。これから構築するなら、仮想アプライアンスかEC2インスタンス上のゲートウェイを選びます。
料金はどのように決まりますか？
ゲートウェイ経由でAWSへ書き込んだデータ量に対する課金が基本で、1台あたり月額125.00 USDが上限として設定されています。アカウントごとに初回100GBの書き込みは無料、同一リージョン内のEC2ベースゲートウェイ宛て転送は0.00 USD/GBです。これに保存先のS3・アーカイブクラスの保管料や取り出し料が加わります。
関連記事
- Amazon S3とは？仕組みとストレージクラス：S3 File Gatewayの書き出し先。
- Amazon S3 Glacierとは？取り出し時間と料金：Tape Gatewayのアーカイブ層。
- Amazon FSxとは？4つのファイルシステム：FSx File Gatewayの代替経路。
- AWS EFSとは？S3・EBS・FSxとの違い：段階3で移る共有ファイルシステム。
- AWS Direct Connectとは？専用線接続の仕組み：転送帯域を確保する併用構成。
- オブジェクトストレージとは？ブロックとの違い：変換の土台となる仕組み。
- AWS Snowballとは？現行デバイスと移行手段：一度きりの大容量移送の選択肢。
- AWS移行とは？7R戦略と移行ツール：移行全体のどこに置くかの地図。
