翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ボリュームゲートウェイのセットアップ要件
以下に挙げる要件は、特記がない限り、すべてのゲートウェイ構成に共通です。
ハードウェアとストレージの要件
このセクションでは、ゲートウェイの最小ハードウェアと設定、および必要なストレージに割り当てる最小ディスク容量について説明します。
VM のハードウェア要件
ゲートウェイをデプロイする前に必ず、ゲートウェイ VM をデプロイする基盤となるハードウェアで、以下の最小リソースを専有できることを確認してください。
-
VM に割り当てられた仮想プロセッサ 4 個。
-
ボリュームゲートウェイの場合、ハードウェアの RAM に次の容量の専用領域を確保する必要があります。
-
16 TiB までのキャッシュ容量が使用可能な、ゲートウェイ用に予約された 16 GiB の RAM 領域
-
16 TiB~32 TiB のキャッシュ容量が使用可能な、ゲートウェイ用に予約された 32 GiB の RAM 領域
-
32 TiB~64 TiB のキャッシュ容量が使用可能な、ゲートウェイ用に予約された 48 GiB の RAM 領域
-
-
ディスクの空き容量 80 GiB (VM イメージとシステムデータのインストール用)。
詳細については、「ゲートウェイのパフォーマンスの最適化」を参照してください。ハードウェアがゲートウェイ VM のパフォーマンスにどのように影響を与えるかについては、「AWS Storage Gateway のクォータ」を参照してください。
Amazon EC2 インスタンスタイプでの要件
Amazon Elastic Compute Cloud (Amazon EC2) でゲートウェイをデプロイする場合、このゲートウェイが機能するためには、インスタンスサイズとして少なくとも xlarge を使用する必要があります。ただし、コンピューティング最適化インスタンスファミリーの場合は、サイズとして少なくとも 2xlarge が必要です
注記
Storage Gateway AMI は、Intel または AMD プロセッサを使用する x86 ベースのインスタンスとのみ互換性があります。Graviton プロセッサを使用する ARM ベースのインスタンスはサポートされていません。
ボリュームゲートウェイの場合、Amazon EC2 インスタンスはゲートウェイに使用する予定のキャッシュサイズに応じて、次の量の RAM を割り当てる必要があります。
-
16 TiB までのキャッシュ容量が使用可能な、ゲートウェイ用に予約された 16 GiB の RAM 領域
-
16 TiB~32 TiB のキャッシュ容量が使用可能な、ゲートウェイ用に予約された 32 GiB の RAM 領域
-
32 TiB~64 TiB のキャッシュ容量が使用可能な、ゲートウェイ用に予約された 48 GiB の RAM 領域
ゲートウェイの種類に応じて次のインスタンスタイプのうち 1 つを使用することをお勧めします。
キャッシュボリュームおよびテープゲートウェイの種類に応じた推奨事項
-
汎用インスタンスファミリー – m4、m5、または m6 インスタンスタイプ。
注記
m4.16xlarge インスタンスタイプの使用はお勧めしません。
-
コンピューティング最適化インスタンスファミリー — c4、c5、または c6 インスタンスタイプ 2xlarge 以上のインスタンスサイズを選択し、必要な RAM 要件を満たします。
-
メモリ最適化インスタンスファミリー – r3、r5、または r6 インスタンスタイプ。
-
ストレージ最適化インスタンスファミリー – i3 または i4 インスタンスタイプ。
ストレージの要件
ゲートウェイには VM 用の 80 GiB 以外にもディスク領域が必要になります。
次の表は、デプロイされるゲートウェイのローカルディスクストレージの推奨サイズを示しています。
ゲートウェイタイプ | キャッシュ (最小) | キャッシュ (最大) | アップロードバッファ (最小) | アップロードバッファ (最大) | その他の必要なローカルディスク |
---|---|---|---|---|---|
キャッシュ型ボリュームゲートウェイ | 150 GiB | 64 TiB | 150 GiB |
2 TiB |
— |
保管型ボリュームゲートウェイ | — | — | 150 GiB |
2 TiB |
1 つまたは複数の保管されたボリューム |
注記
キャッシュおよびアップロードバッファ用として、1 つ以上のローカルドライブを、最大容量まで構成することができます。
既存のゲートウェイにキャッシュやアップロードバッファを追加する場合、ホスト (ハイパーバイザーまたは Amazon EC2 インスタンス) に新しいディスクを作成することが重要です。ディスクがキャッシュやアップロードバッファとして割り当て済みである場合は、既存のディスクサイズを変更しないでください。
ゲートウェイクォータの詳細については、「AWS Storage Gateway のクォータ」を参照してください。
ネットワークとファイアウォールの要件
ゲートウェイには、インターネット、ローカルネットワーク、ドメインネームサービス (DNS) サーバー、ファイアウォール、ルーターなどへのアクセスが必要です。以下は、必要なポートと、ファイアウォールとルーターを経由してアクセスを許可する方法についての情報です。
注記
場合によると、AWS の IP アドレス範囲を制限するネットワークセキュリティポリシーを使用して、Amazon EC2 に Storage Gateway をデプロイするか、または他のタイプのデプロイ (オンプレミスを含む) を行うことがあります。この際に、AWS の IP 範囲で設定値が変更されると、ゲートウェイとサービスの間で接続に関する問題が発生することがあります。使用する必要がある AWS の IP アドレス範囲の値は、ゲートウェイをアクティブ化した AWS リージョンの Amazon サービスのサブセットの範囲内です。現在の IP 範囲値については、「AWS 全般のリファレンス」の「AWS IP アドレスの範囲」を参してください。
注記
ネットワーク帯域幅の要件は、ゲートウェイによってアップロードおよびダウンロードされるデータの量によって異なります。ゲートウェイのダウンロード、アクティブ化、および更新を正常に行うには、最低 100 Mbps が必要です。データ転送のパターンによって、ワークロードのサポートに必要な帯域幅が決まります。Storage Gateway を Amazon EC2 にデプロイしたり、他のタイプのデプロイを使用したりする場合があります。
トピック
ポート要件
Storage Gateway の使用には、特定のポートへのアクセス許可が必要です。次の図は、各ゲートウェイの種類に対して許可する必要がある、必須のポートを示しています。すべてのゲートウェイの種類で必要なポートと、特定のゲートウェイの種類で必要なポートがあります。ポートの要件の詳細については、「ボリュームゲートウェイのポート要件」を参照してください。
すべてのゲートウェイの種類に共通のポート
以下のポートは、すべてのゲートウェイタイプに共通で、すべてのゲートウェイタイプで必要です。
[プロトコル] |
ポート |
[Direction] (方向) |
ソース |
デスティネーション |
用途 |
---|---|---|---|---|---|
TCP |
443 (HTTPS) |
アウトバウンド |
Storage Gateway |
AWS |
Storage Gateway から AWS サービスエンドポイントへの通信用。サービスエンドポイントの詳細については、「ファイアウォールとルーターを介した AWS Storage Gateway アクセスの許可」を参照してください。 |
TCP |
80 (HTTP) |
インバウンド |
AWS マネジメントコンソールに接続するホスト。 |
Storage Gateway |
Storage Gateway のアクティベーションキーは、ローカルシステムにより取得されます。ポート 80 は Storage Gateway アプライアンスのアクティベーション時にのみ使用されます。 Storage Gateway では、ポート 80 をパブリックアクセスが可能なように設定する必要はありません。ポート 80 へのアクセスに必要なレベルはネットワークの設定によって決まります。Storage Gateway マネジメントコンソールからゲートウェイをアクティブ化する場合、コンソールに接続するホストには、ゲートウェイのポート 80 に対するアクセス権限が必要です。 |
TCP / UDP |
53 (DNS) |
アウトバウンド |
Storage Gateway |
ドメインネームサービス (DNS) サーバー |
Storage Gateway と DNS サーバー間の通信用。 |
TCP |
22 (サポートチャネル) |
アウトバウンド |
Storage Gateway |
サポート |
ゲートウェイで発生する問題のトラブルシューティングを支援する目的で、サポート に対し、ゲートウェイへのアクセス許可を付与します。このポートは、ゲートウェイの通常のオペレーションでは開いておく必要はありませんが、トラブルシューティングでは必要です。 |
UDP |
123 (NTP) |
アウトバウンド |
NTP クライアント |
NTP サーバー |
VM 時間をホスト時間に同期するためにローカルシステムで使用されます。 |
ボリュームゲートウェイとテープゲートウェイのポート
次の図は、ボリュームゲートウェイに対して開くポートを示しています。

共通ポートに加えて、ボリュームゲートウェイには次のポートが必要です。
[プロトコル] |
ポート |
[Direction] (方向) |
ソース |
デスティネーション |
用途 |
---|---|---|---|---|---|
TCP |
3260 (iSCSI) |
インバウンド |
iSCSI イニシエータ |
Storage Gateway |
ローカルシステムから、ゲートウェイで公開されている iSCSI ターゲットに接続するため。 |
ポートの要件の詳細については、「Additional Storage Gateway resources」セクションの「ボリュームゲートウェイのポート要件」を参照してください。
Storage Gateway ハードウェアアプライアンスのネットワークとファイアウォールに関する要件
それぞれの Storage Gateway ハードウェアアプライアンスには、以下のネットワークサービスが必要です。
-
インターネットアクセス – サーバー上の任意のネットワークインターフェイスを介した、インターネットへの常時接続のネットワーク接続。
-
DNS サービス – ハードウェアアプライアンスと DNS サーバー間の通信のための DNS サービス。
-
時刻同期 – 自動的に設定された Amazon NTP タイムサービスへのアクセス。
-
IP アドレス – 割り当てられた DHCP または静的 IPv4 アドレス。IPv6 アドレスを割り当てることはできません。
Dell PowerEdge R640 サーバーの背面には、5 つの物理ネットワークポートがあります。これらのポートは、サーバーの背面から見て左から右に、次のとおりです。
-
iDRAC
-
em1
-
em2
-
em3
-
em4
iDRAC ポートをリモートサーバー管理に使用できます。

ハードウェアアプライアンスでは、以下のポートの操作が必要です。
[プロトコル] |
ポート |
[Direction] (方向) |
ソース |
デスティネーション |
用途 |
---|---|---|---|---|---|
SSH |
22 |
アウトバウンド |
ハードウェアアプライアンス |
|
サポートチャネル |
DNS | 53 | アウトバウンド | ハードウェアアプライアンス | DNS サーバー | 名前解決 |
UDP/NTP | 123 | アウトバウンド | ハードウェアアプライアンス | *.amazon.pool.ntp.org |
時刻同期 |
HTTPS |
443 |
アウトバウンド |
ハードウェアアプライアンス |
|
データ転送 |
HTTP | 8080 | インバウンド | AWS | ハードウェアアプライアンス | アクティベーション (短時間のみ) |
ハードウェアアプライアンスでは、設計どおりに機能するためには、次のようなネットワークとファイアウォールの設定が必要です。
-
接続されているすべてのネットワークインターフェイスをハードウェアコンソールで設定します。
-
各ネットワークインターフェイスが一意のサブネット上にあることを確認します。
-
接続されているすべてのネットワークインターフェースに、前の図に示されているエンドポイントへのアウトバウンドアクセスを提供します。
-
ハードウェアアプライアンスをサポートするためには、少なくとも 1 つのネットワークインターフェイスを設定します。詳細については、「ハードウェアアプライアンスのネットワークパラメータの設定」を参照してください。
注記
サーバーの背面とポートを示す図については、「ハードウェアアプライアンスの物理的なインストール」を参照してください。
同じネットワークインターフェイス (NIC) 上のすべての IP アドレスは、ゲートウェイ用でもホスト用でも、同じサブネットにある必要があります。次の図は、アドレス割り当てスキームを示しています。

ハードウェアアプライアンスのアクティベーションと設定の詳細については、Storage Gateway ハードウェアアプライアンスの使用 を参照してください。
ファイアウォールとルーターを介した AWS Storage Gateway アクセスの許可
ゲートウェイが AWS と通信するためには、以下のサービスエンドポイントにアクセスする必要があります。ファイアウォールまたはルーターを使用してネットワークトラフィックをフィルタリングまたは制限する場合は、これらのサービスエンドポイントに対し AWS へのアウトバウンド通信を許可するように、対象のファイアウォールおよびルーターを設定する必要があります。
注記
Storage Gateway 用にプライベート VPC エンドポイントを設定し、AWS との接続とデータ転送に使用する場合、ゲートウェイからパブリックインターネットにアクセスする必要がありません。詳細については、「仮想プライベートクラウドでのゲートウェイのアクティブ化」を参照してください。
重要
ゲートウェイで使用する AWS リージョンに応じて、サービスエンドポイントの region
を、実際のリージョンを示す文字列に置き換えます。
head-bucket オペレーションには、すべてのゲートウェイで以下のサービスエンドポイントが必要です。
s3.amazonaws.com:443
以下のサービスエンドポイントは、コントロールパス (anon-cp、client-cp、proxy-app) とデータパス (dp-1) オペレーションのためにすべてのゲートウェイに必要です。
anon-cp.storagegateway.
region
.amazonaws.com:443 client-cp.storagegateway.region
.amazonaws.com:443 proxy-app.storagegateway.region
.amazonaws.com:443 dp-1.storagegateway.region
.amazonaws.com:443
次のゲートウェイサービスエンドポイントは、API コールを行うために必要です。
storagegateway.
region
.amazonaws.com:443
次に、米国西部 (オレゴン) リージョン (us-west-2
) にあるゲートウェイサービスエンドポイントの例を示します。
storagegateway.us-west-2.amazonaws.com:443
以下に示す Amazon S3 サービスエンドポイントは、ファイルゲートウェイのみで使用されます。ファイルゲートウェイでは、ファイル共有のマッピング先の S3 バケットにアクセスするために、このエンドポイントが必要です。
bucketname
.s3.region
.amazonaws.com
次に、米国東部 (オハイオ) リージョン (us-east-2
) にある S3 サービスエンドポイントの例を示します
s3.us-east-2.amazonaws.com
注記
S3 バケットが配置されている AWS リージョンをゲートウェイが特定できない場合、このサービスエンドポイントはデフォルトで s3.us-east-1.amazonaws.com
になります。ゲートウェイがアクティブ化されて S3 バケットが配置されている AWS リージョンに加えて、米国東部 (バージニア北部) リージョン (us-east-1
) へのアクセスを許可しておくことをお勧めします。
以下は、AWS GovCloud (US) リージョンの S3 サービスエンドポイントです。
s3-fips.us-gov-west-1.amazonaws.com (AWS GovCloud (US-West) Region (FIPS)) s3-fips.us-gov-east-1.amazonaws.com (AWS GovCloud (US-East) Region (FIPS)) s3.us-gov-west-1.amazonaws.com (AWS GovCloud (US-West) Region (Standard)) s3.us-gov-east-1.amazonaws.com (AWS GovCloud (US-East) Region (Standard))
次に、AWS GovCloud (米国西部) リージョンにある、S3 バケット用の FIPS サービスエンドポイントの例を示します。
bucket-name
.s3-fips.us-gov-west-1.amazonaws.com
Storage Gateway VM は、以下の NTP サーバーを使用するように設定されています。
0.amazon.pool.ntp.org 1.amazon.pool.ntp.org 2.amazon.pool.ntp.org 3.amazon.pool.ntp.org
-
Storage Gateway – サポート対象の AWS リージョンと Storage Gateway で使用できる AWS サービスエンドポイントのリストについては、「AWS 全般のリファレンス」の「AWS Storage Gateway エンドポイントとクォータ」を参照してください。
-
Storage Gateway ハードウェアアプライアンス – ハードウェアアプライアンスで使用できるサポート対象の AWS リージョンについては、「AWS 全般のリファレンス」の「Storage Gateway ハードウェアアプライアンスリージョン」を参照してください。
Amazon EC2 ゲートウェイインスタンスでのセキュリティグループの設定
セキュリティグループは、Amazon EC2 ゲートウェイインスタンスへのトラフィックを制御します。セキュリティグループを設定するときは、次のことを推奨します。
-
セキュリティグループで、外部のインターネットからの着信接続は許可しないでください。ゲートウェイのセキュリティグループ内のインスタンスのみがゲートウェイと通信できるようにします。ゲートウェイのセキュリティグループに属さないインスタンスにゲートウェイへの接続を許可する必要がある場合、ポート 3260 (iSCSI 接続用) および 80 (アクティベーション用) でのみ接続を許可することをお勧めします。
-
ゲートウェイのセキュリティグループに属さない Amazon EC2 ホストからゲートウェイをアクティベートする場合は、そのホストの IP アドレスからの着信接続をポート 80 で許可します。アクティブ化するホストの IP アドレスがわからない場合、ポート 80 を開き、ゲートウェイをアクティブ化して、アクティブ化の完了後、ポート 80 のアクセスを閉じることができます。
-
トラブルシューティングのために サポート を使用する場合にのみ、ポート 22 アクセスを許可します。詳細については、「EC2 ゲートウェイのトラブルシューティングに サポート を役立てたい」を参照してください。
場合によっては、Amazon EC2 インスタンスをイニシエータとして (Amazon EC2 にデプロイしたゲートウェイの iSCSI ターゲットに接続するため) 使用します。このような場合は、2 つのステップを実行するアプローチをお勧めします。
-
ゲートウェイと同じセキュリティグループのイニシエータインスタンスを起動してください。
-
アクセスを設定すると、イニシエータはゲートウェイと通信できます。
ゲートウェイで開くポートについては、「ボリュームゲートウェイのポート要件」を参照してください。
サポートされているハイパーバイザーとホストの要件
Storage Gateway は、オンプレミスの仮想マシン (VM) アプライアンスあるいは物理ハードウェアアプライアンスとして実行できます。また AWS 内では、Amazon EC2 インスタンスとしての実行が可能です。
注記
製造元がハイパーバイザーバージョンの全般サポートを終了した場合は、Storage Gateway でも該当するハイパーバイザーバージョンのサポートを終了します。特定のバージョンのハイパーバイザーのサポートについて詳しくは、製造元のドキュメントを参照してください。
Storage Gateway では、以下のハイパーバイザーのバージョンとホストがサポートされます。
-
VMware ESXi Hypervisor (バージョン 7.0 または 8.0) – このセットアップには、ホストに接続するための VMware vSphere クライアントも必要です。
-
Microsoft Hyper-V Hypervisor (バージョン 2012 R2、2016、2019、または 2022) – Hyper-V の無料スタンドアロン版を Microsoft Download Center
から入手できます。このセットアップでは、ホストに接続する Microsoft Windows クライアントコンピュータには Microsoft Hyper-V Manager が必要になります。 -
Linux カーネルベースの仮想マシン (KVM) – これは無料のオープンソースの仮想化テクノロジーです。KVM は、Linux バージョン 2.6.20 以降のすべてのバージョンに同梱されています。Storage Gateway は、CentOS/RHEL 7.7、Ubuntu 16.04 LTS、および Ubuntu 18.04 LTS の各ディストリビューションでテストされ動作が確認されています。他の最新の Linux ディストリビューションは動作しますが、機能やパフォーマンスは保証されません。既に KVM 環境が稼働しており、KVM の仕組みに精通している場合は、このオプションをお勧めします。
-
Amazon EC2 インスタンス – Storage Gateway では、ゲートウェイ の VM イメージを含む Amazon マシンイメージ (AMI) を提供します。Amazon EC2 に対してはファイル、キャッシュ型ボリューム、テープゲートウェイのテープのみがデプロイ可能です。Amazon EC2 にゲートウェイをデプロイする方法については、「ボリュームゲートウェイ用にカスタマイズされた Amazon EC2 インスタンスをデプロイする」を参照してください。
-
Storage Gateway ハードウェアアプライアンス – Storage Gateway では、仮想マシンによるインフラストラクチャが制限されている場所のためのオンプレミス用デプロイオプションとして、物理ハードウェアアプライアンスが提供されています。
注記
Storage Gateway では、スナップショットから作成された VM、または別のゲートウェイ VM のクローン、または Amazon EC2 AMI からのゲートウェイの復元はサポートされていません。ゲートウェイ VM が正しく機能しない場合は、新しいゲートウェイをアクティブ化し、データをそのゲートウェイに復旧します。詳細については、「予期しない仮想マシンのシャットダウンからの復旧」を参照してください。
Storage Gateway は動的メモリと仮想メモリのバルーニングをサポートしていません。
サポートされている iSCSI イニシエータ
キャッシュ型ボリュームまたは保管型ボリュームゲートウェイをデプロイするときに、ゲートウェイに iSCSI ストレージボリュームを作成できます。
これらの iSCSI デバイスに接続するために、Storage Gateway では、以下の iSCSI イニシエータがサポートされています。
-
Windows Server 2019
-
Windows Server 2016
-
Windows Server 2012 R2
-
Windows 10
-
Windows 8.1
-
Red Hat Enterprise Linux 5
-
Red Hat Enterprise Linux 6
-
Red Hat Enterprise Linux 7
-
Red Hat Enterprise Linux 8
-
Red Hat Enterprise Linux 9
-
VM のゲストオペレーティングシステムでのイニシエータの使用に代わる、VMware ESX イニシエータ
重要
Storage Gateway では、Windows クライアントからの Microsoft Multipath I/O (MPIO) はサポートされていません。
ホストが Windows Server Failover Clustering (WSFC) を使用してアクセスを調整する場合には、Storage Gatewayによる同じボリューム内の複数のホストへの接続がサポートされます。ただし、WSFC を使用せずに複数のホストを同じボリュームに接続すること (非クラスター NTFS/ext4 ファイルシステムの共有など) はできません。