AWS Storage Gateway入門｜オンプレのNAS・テープ・ファイルサーバーをAWSと接続する実践ガイド

「AWSへ移行したいが、既存のファイルサーバーやバックアップテープはすぐには捨てられない」――そんな現場の声は多い。オンプレのインフラをゼロからクラウドへ置き換えるのはコストも工数もかかりすぎる。既存の資産を活かしながら、段階的にAWSを取り込んでいきたいというのが本音だろう。

AWS Storage Gatewayはそのニーズに応えるサービスだ。オンプレミスにゲートウェイのソフトウェアアプライアンスを配置し、既存のNFS・SMB・iSCSI・VTLプロトコルをそのまま使いながら、バックエンドをAmazon S3やAmazon FSx、S3 Glacierに切り替えられる。アプリケーション側は何も変えなくてよい。

この記事では、AWS Storage Gatewayの4つのタイプと選び方、セットアップの基本手順、料金の構造、そして現場でよく起きるトラブルと対処法まで、オンプレ経験者向けに解説する。

なぜAWS Storage Gatewayなのか？オンプレストレージとの根本的な違い

オンプレのファイルサーバーをそのままAWSへ移行しようとすると、まずプロトコルの壁にぶつかる。アプリケーションやバックアップツールはNFSやSMBでマウントすることを前提に設計されており、S3のHTTP APIにすぐ対応するのは現実的ではない。かといって、全アプリを書き直す余裕もない。

AWS Storage Gatewayがやっていることは、大きく分けると「プロトコル変換」と「ローカルキャッシュ」の2つだ。

オンプレ（またはEC2上）にゲートウェイアプライアンスを置く。そのゲートウェイがNFS・SMB・iSCSI・VTLのエンドポイントとして振る舞う。ゲートウェイは受け取ったデータをローカルディスク（キャッシュ）に一時保存しながら、バックグラウンドでAWSへ非同期転送する仕組みだ。

オンプレの物理NASでは、ディスクがフルになったら増設かリプレースが必要だった。Storage Gatewayを挟むと、バックエンドはS3の事実上無制限の容量になるため、容量設計の繰り返しから解放される。また、S3に乗ることで自動的に11ナイン（99.999999999%）の耐久性を得られるのも大きい。オンプレのRAIDでは実現できないレベルだ。

4つのゲートウェイタイプの違いと選び方

AWS Storage Gatewayには現在4種類のタイプがある。選び方を間違えると後で設計をやり直すことになるので、最初にしっかり理解しておきたい。

【S3 File Gateway】NAS代替で最もよく使われる

NFSまたはSMBでマウントでき、書き込んだファイルはS3オブジェクトとして保存される。S3側から直接オブジェクトとして参照できるため、データ分析やAI学習用のデータ投入パイプラインとしても使いやすい。既存のNetApp・EMC・NASサーバーをStorage Gatewayに置き換えるケースが典型だ。

ローカルキャッシュには最近アクセスしたデータだけが残り、古いデータはS3にのみ存在する。読み出し時はキャッシュヒットすればローカル速度、ミスすればS3から取得するため、キャッシュサイズの設計が肝になる（後述）。

【Amazon FSx File Gateway】WindowsファイルサーバーのSMB専用

Active Directoryとの統合が前提のWindowsファイルサーバー環境向け。バックエンドはAmazon FSx for Windows File Serverで、ACLやオフラインファイル（クライアントキャッシュ）もそのまま機能する。S3 File GatewayとSMBで迷ったときは、AD統合が必要かどうかで選ぶといい。

【Volume Gateway】iSCSIブロックデバイスとして使う

Cachedモードはプライマリデータをクラウド（S3）に置き、頻繁にアクセスするデータだけをローカルキャッシュに保持する。Storedモードはプライマリをオンプレのローカルディスクに置き、非同期でS3へスナップショットを取る。DR目的での利用が多い。

EBSスナップショットとして保存されるため、必要なときにEBSボリュームとして復元できる。オンプレのiSCSIデバイスをAWSにDRサイトを持つ構成として利用する場面で重宝する。

【Tape Gateway】テープから卒業するための架け橋

既存のバックアップソフト（Veeam、Veritas NetBackup、Commvaultなど）がテープデバイスに書き込む設定をそのまま使える。ゲートウェイがVTL（Virtual Tape Library）として振る舞い、書き込まれたデータをS3 GlacierやDeep Archiveに転送する。

物理テープの保管・輸送コストがゼロになるうえ、復元時はクラウドからすぐに取り出せる。「テープの倉庫保管費用を切りたいが、バックアップソフトを変えるコストが払えない」という現場にとって現実的な解だ。

基本的なセットアップ手順（S3 File Gatewayを例に）

ここでは最も利用頻度の高いS3 File Gatewayのセットアップ手順を示す。VMware ESXiにデプロイする例で説明するが、Hyper-V・KVM・EC2 AMIでも手順の大筋は同じだ。

1. AWSコンソールでゲートウェイを作成する

AWS管理コンソール → Storage Gateway → 「ゲートウェイの作成」を開く。ゲートウェイタイプで「Amazon S3 File Gateway」を選択し、ホストプラットフォームで「VMware ESXi」を選ぶ。

# コンソール操作（AWSマネジメントコンソール）
# 1. Storage Gateway → 「ゲートウェイの作成」
# 2. ゲートウェイタイプ: Amazon S3 File Gateway
# 3. ホストプラットフォーム: VMware ESXi（または使用環境に合わせて選択）
# 4. OVAファイルのダウンロードリンクが表示される

2. ゲートウェイソフトウェアをオンプレにデプロイする

提供されるOVAファイルをVMware vCenterからインポートしてVMを作成する。ハードウェア要件は最低でも4 vCPU・16GB RAM・80GBのルートディスク + キャッシュ用ディスク（最小150GB）が必要だ。

キャッシュディスクは別ボリュームとして追加する。後からサイズ変更は難しいので、最初から余裕を持たせること（推奨はワーキングセットの1.1倍以上）。

3. ゲートウェイをアクティベートする

VMを起動し、VMコンソールからゲートウェイのIPアドレスを確認する。コンソールの「ゲートウェイIPアドレス」欄に入力して「ゲートウェイの接続」を押す。

# アクティベーションに必要なネットワーク要件
# ゲートウェイVM → 外部（HTTPS:443）: storage.us-east-1.amazonaws.com への疎通
# ゲートウェイVM → AWSリージョンエンドポイントへのアウトバウンド通信
# ゲートウェイVM → 管理コンソールPC（HTTP:80）: アクティベーションコード取得用
# ※ ポート80が閉じているとアクティベーションに失敗する（後述のトラブル参照）

アクティベーションが成功するとアクティベーションコードが発行され、コンソールでゲートウェイが「オンライン」状態になる。この後、ローカルディスクをキャッシュ用ディスクとして割り当てる。

4. S3バケットとNFSファイル共有を作成する

Storage Gatewayのコンソールから「ファイル共有の作成」を選ぶ。共有先のS3バケット名を入力し、IAMロールを割り当てる（ゲートウェイがS3に書き込むための権限）。アクセスプロトコルはNFSを選択する。

# AWS CLI でファイル共有を確認する例（AWS CLI）
aws storagegateway list-file-shares \
  --gateway-arn "arn:aws:storagegateway:ap-northeast-1:123456789012:gateway/sgw-XXXXXXXX"

NFSクライアントIPの制限（マウント許可IPアドレス）は「0.0.0.0/0」だとすべてのIPからマウント可能になってしまうため、本番環境では必ずサブネットを絞ること。

5. LinuxサーバーからNFSマウントする

# LinuxサーバーにNFSクライアントをインストール
sudo yum install -y nfs-utils   # RHEL/CentOS系
# sudo apt-get install -y nfs-common   # Debian/Ubuntu系

# マウントポイントを作成
sudo mkdir -p /mnt/s3-share

# NFSマウント（ゲートウェイIPは実際のIPに変更）
sudo mount -t nfs -o nolock,hard,intr \
  192.168.1.100:/mybucket /mnt/s3-share

# /etc/fstab に追加して永続化
# 192.168.1.100:/mybucket /mnt/s3-share nfs nolock,hard,intr 0 0

マウントが成功したら、通常のNFSディレクトリとまったく同じ感覚でファイルを読み書きできる。書き込んだファイルはバックグラウンドでS3に転送される。Linuxコマンドの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説している。

料金の仕組みとコスト感覚

AWS Storage Gatewayの料金は複数の要素から構成される。「ゲートウェイ料金を払えばいい」と思っていると請求書を見て驚くことになるので、構造を把握しておこう（以下は2026年3月時点の東京リージョン（ap-northeast-1）を参考にした目安。最新料金はAWS公式をご確認いただきたい）。

【S3 File Gateway】の料金構成

・ゲートウェイ使用料: アクティブなゲートウェイ1台あたり月額固定（24時間稼働で課金）
・S3ストレージ料金: 保存するファイルのデータ量に応じてS3の料金が発生（ストレージクラスによる）
・S3リクエスト料金: ファイルの書き込み・読み出しごとにGETやPUTリクエストが発生
・データ転送料金: S3からの下り（クラウド → オンプレ方向）に料金が発生。同一AWSリージョン内での通信は無料

S3に保存されるデータにはS3のストレージクラスを設定できる。頻繁に参照しないアーカイブファイルならS3 Glacier Instant Retrievalへのライフサイクル移行と組み合わせることでコストを大幅に下げられる。ストレージクラスの詳細は「S3ストレージクラス完全比較 AWS料金を最大90%削減する方法」で解説している。

【Tape Gateway】の料金構成

・ゲートウェイ使用料: S3 File Gatewayと同様に月額固定
・仮想テープの保存料金: S3 GlacierまたはDeep Archiveのストレージ料金（GB単位）
・仮想テープの書き込み料金: ゲートウェイへのデータ書き込みに対して課金

物理テープの1本あたりのコストと月次保管料、さらに復元時の輸送料を計算すると、Tape Gatewayへの移行でトータルコストが下がるケースが多い。特にテープを数百本単位で保管している環境では効果が大きい。

コスト見積もりの落とし穴

・キャッシュディスクのコスト: EC2上でゲートウェイを動かす場合、EBSボリューム費用がかかる。オンプレのVMならローカルディスクのコストだが見落としがち
・データ取り出しコスト: GlacierやDeep Archiveに移行したデータを大量に取り出す場合、取り出し料金が予想外に膨らむことがある
・NATゲートウェイ経由の通信: オンプレのゲートウェイがVPN経由でAWSと通信している場合、NAT Gatewayを経由するとデータ転送料金が二重にかかる場合がある

応用・実務Tips

【Tips 1】キャッシュサイズはワーキングセットの1.1倍以上を目安に

S3 File GatewayとVolume Gateway（Cached）は、直近にアクセスしたデータをローカルキャッシュに保持する。キャッシュサイズが不足すると、読み出しのたびにS3から取得するため速度が低下し、コストも増える。

実務的な目安としては、「週次でアクセスされるデータ量（ワーキングセット）の1.1倍以上」のキャッシュを確保しておくのが安全だ。NASのアクセスログからホットデータのサイズを測定してから設計に臨むことをすすめる。

【Tips 2】バンド幅スロットリングで日中の帯域を確保する

ゲートウェイのキャッシュアップロードが業務時間帯の回線を占有すると、他のシステムに影響が出る。コンソールの「帯域幅スロットリングの設定」から時間帯ごとのスロットリングを設定できるので、夜間は全帯域を使い、昼間は制限するスケジュールを組もう。

【Tips 3】VPC Endpoint経由でプライベート接続する

Storage GatewayをEC2上で動かす場合、またはオンプレからAWS VPN・Direct Connect経由で接続している場合、Storage Gateway用のVPCエンドポイントを経由することでインターネットに出ずにS3へアクセスできる。

セキュリティポリシーでインターネット経由の通信を禁じている環境（金融・医療・政府系）では必須の設定だ。

【Tips 4】S3バケットのバージョニングを有効にしておく

S3 File GatewayからS3に書き込まれるオブジェクトは、バケットのバージョニングを有効にしておくと誤削除・誤上書きから保護できる。File Gatewayは削除操作もS3へ伝播するため、「アプリが誤ってファイルを消してしまった」ときの復元手段として有効だ。

【Tips 5】AWS Backupとの連携で管理を一元化する

Volume GatewayのEBSスナップショットはAWS Backupのバックアッププランに組み込むことができる。バックアップの保持期間・スケジュール・タグ管理をAWS Backupで一元化すると、オンプレのバックアップポリシーとAWS側を統合して運用できる。詳細は「AWS Backup入門｜EC2・RDS・EFSを一元管理するバックアップポリシーと料金ガイド」を参照してほしい。

よくあるトラブルと対処法

【トラブル1】アクティベーションが「ゲートウェイに接続できませんでした」で失敗する

最も多いのはHTTP（ポート80）の閉鎖だ。アクティベーションのコード発行はゲートウェイVM → ブラウザ側（管理者のPC）方向にHTTPで通信する仕組みのため、ゲートウェイVMからポート80へのアウトバウンドが通っていないと失敗する。

また、ゲートウェイからAWSリージョンのエンドポイント（storagegateway.ap-northeast-1.amazonaws.com）へのHTTPS（443）が通っていないと、アクティベーション後も「オフライン」のままになる。セキュリティグループ・ファイアウォールの設定を確認しよう。

【トラブル2】NFSマウント後にファイルの書き込みが遅い

初回書き込み直後はキャッシュへの書き込みが先行し、バックグラウンドでS3へアップロードが続く。この間は見かけ上のストレージ残量が圧迫されていくので、キャッシュが逼迫するとさらに遅くなる。

ゲートウェイのコンソールで「キャッシュ使用率」を確認し、80%を超えているようであればキャッシュディスクの追加（EBSのアタッチ後コンソールから割り当て）を検討する。

【トラブル3】S3に届いたファイルが文字化けしている（文字コード問題）

NFSマウント先のLinuxクライアントがUTF-8以外のロケールで動いている場合、ファイル名が文字化けしてS3に保存されることがある。クライアント側のロケールをUTF-8に統一しておくことが前提だ。

SMBの場合はWindowsクライアントとゲートウェイVM間のNetBIOS名解決が失敗すると接続できないことがある。Active Directory統合ありのSMBなら、DNS正引き・逆引きの両方を整備しておこう。

【トラブル4】Tape Gatewayでバックアップソフトがテープを「認識しない」

バックアップソフト側で「VTLデバイスの再スキャン」（デバイスの検出）を実行していないことが原因のほとんどだ。iSCSIイニシエーターでゲートウェイをターゲット追加した後、バックアップソフト側のデバイスリフレッシュ操作を必ず行う。Veeamなら「Tape」メニュー → 「Rescan」、NetBackupなら「Device Monitor」からの再スキャンが相当する。

本記事のまとめ

AWS Storage Gatewayは、既存のオンプレインフラをそのまま活かしながらAWSのスケールと耐久性を獲得できるハイブリッドストレージサービスだ。主なポイントを整理する。

Storage Gatewayを起点として段階的にワークロードをクラウドへ移行していくことで、大規模な一括移行のリスクを避けながらAWSのメリットを享受できる。クラウドへの移行パターンについては「AWS移行の6R入門｜Rehost・Replatform・Refactorの違いとクラウド移行パターンの選び方」も参考にしてほしい。

また、Storage Gatewayを使わずにファイル共有をAWSで完結させる場合は、Amazon EFS（NFSベースのマネージドファイルシステム）やAmazon FSx（Windows/Lustre対応）も選択肢になる。ストレージサービスの全体比較は「EBSとS3の違い・EFSとの比較｜Amazon S3/EBS/EFS 徹底比較ガイド」で整理している。