リージョンとゾーン
Amazon EC2 は、世界各地の場所でホスティングされています。これらの場所は、AWS リージョン、アベイラビリティーゾーン、Local Zones、AWS Outposts、および Wavelength Zones で構成されます。
-
リージョンはそれぞれ、地理的に離れた領域です。
-
アベイラビリティーゾーンは、各リージョン内の複数の独立した場所です。
-
Local Zones を使用すると、コンピューティングやストレージなどのリソースをエンドユーザーに近い複数の場所に配置できます。
-
AWS Outposts では、ネイティブの AWS のサービス、インフラストラクチャ、運用モデルをほぼすべてのデータセンター、コロケーションスペース、オンプレミスの施設で利用できます。
-
Wavelength Zones を使用すると、デベロッパーは 5G デバイスやエンドユーザーに非常に低いレイテンシーを提供するアプリケーションを構築できます。Wavelength は、標準の AWS コンピューティングおよびストレージサービスを通信事業者の 5G ネットワークのエッジにデプロイします。
AWS は、最新の高可用性のデータセンターを運用しています。しかし、非常にまれですが、同じ場所にあるインスタンスすべての可用性に影響する障害が発生することもあります。すべてのインスタンスを 1 か所でホストしている場合、そのような障害が起きると、すべてのインスタンスが利用できなくなります。
目次
リージョン
各リージョンは、他のリージョンと完全に分離されるように設計されています。これにより、最大限の耐障害性と安定性が達成されます。
リソースを表示すると、指定したリージョンに結び付けられているリソースのみが表示されます。これは、リージョンが相互に分離されており、リージョン間ではリソースが自動的にレプリケートされないためです。
インスタンスを起動するときは、同じリージョン内にある AMI を選択する必要があります。AMI が別のリージョンにある場合は、使用しているリージョンに AMI をコピーできます。詳細については、Amazon EC2 AMI のコピーを参照してください。
リージョン間のデータ転送には料金がかかることに注意してください。詳細については、Amazon EC2 料金表 - データ転送
利用できるリージョン
アカウントにより、利用できるリージョンが決まります。
-
AWS アカウント は複数のリージョンを提供するため、要件に合った場所で Amazon EC2 インスタンスを起動できます。例えば、ヨーロッパの顧客に近づけるため、または法的要件を満たすために、ヨーロッパでインスタンスを起動することができます。
-
AWS GovCloud (米国西部) アカウントでは、AWS GovCloud (米国西部) リージョンおよび AWS GovCloud (米国東部) リージョンにアクセスできます。詳細については、「AWS GovCloud (US)
」を参照してください。 -
Amazon AWS (中国) アカウントでは、北京および寧夏リージョンにのみアクセスできます。詳細については、「Amazon Web Services in China
」(中国でのアマゾン ウェブ サービス) を参照してください。
次の表は、AWS アカウント で提供されるリージョンの一覧です。AWS GovCloud (US) Regions や中国のリージョンなど、追加のリージョンを AWS アカウント から表示またはアクセスすることはできません。2019 年 3 月 20 日より後に導入されたリージョンを使用するには、そのリージョンを有効にする必要があります。詳細については、「AWS Account Management リファレンスガイド」の「アカウントで使用できる AWS リージョンを指定する」を参照してください。
コード | 名前 | オプトインステータス |
---|---|---|
us-east-1 | 米国東部 (バージニア北部) | 不要 |
us-east-2 | 米国東部 (オハイオ) | 不要 |
us-west-1 | 米国西部 (北カリフォルニア) | 不要 |
us-west-2 | 米国西部 (オレゴン) | 不要 |
af-south-1 | アフリカ (ケープタウン) | 必須 |
ap-east-1 | アジアパシフィック (香港) | 必須 |
ap-south-2 | アジアパシフィック (ハイデラバード) | 必須 |
ap-southeast-3 | アジアパシフィック (ジャカルタ) | 必須 |
ap-southeast-5 | アジアパシフィック (マレーシア) | 必須 |
ap-southeast-4 | アジアパシフィック (メルボルン) | 必須 |
ap-south-1 | アジアパシフィック (ムンバイ) | 不要 |
ap-northeast-3 | アジアパシフィック (大阪) | 不要 |
ap-northeast-2 | アジアパシフィック (ソウル) | 不要 |
ap-southeast-1 | アジアパシフィック (シンガポール) | 不要 |
ap-southeast-2 | アジアパシフィック (シドニー) | 不要 |
ap-northeast-1 | アジアパシフィック (東京) | 不要 |
ca-central-1 | カナダ (中部) | 不要 |
ca-west-1 | カナダ西部 (カルガリー) | 必須 |
cn-north-1 | 中国 (北京) | 不要 |
cn-northwest-1 | 中国 (寧夏) | 不要 |
eu-central-1 | 欧州 (フランクフルト) | 不要 |
eu-west-1 | 欧州 (アイルランド) | 不要 |
eu-west-2 | 欧州 (ロンドン) | 不要 |
eu-south-1 | 欧州 (ミラノ) | 必須 |
eu-west-3 | 欧州 (パリ) | 不要 |
eu-south-2 | 欧州 (スペイン) | 必須 |
eu-north-1 | 欧州 (ストックホルム) | 不要 |
eu-central-2 | 欧州 (チューリッヒ) | 必須 |
il-central-1 | イスラエル (テルアビブ) | 必須 |
me-south-1 | 中東 (バーレーン) | 必須 |
me-central-1 | 中東 (アラブ首長国連邦) | 必須 |
sa-east-1 | 南米 (サンパウロ) | 不要 |
詳細については、AWS グローバルインフラストラクチャ
リージョン エンドポイント
コマンドラインインターフェイスまたは API アクションを使用してインスタンスを操作するときは、そのリージョンエンドポイントを指定する必要があります。Amazon EC2 のリージョンとエンドポイントの詳細については、「Amazon EC2 デベロッパーガイド」の「Amazon EC2 service endpoints」を参照してください。
AWS GovCloud (米国西部) のエンドポイントとプロトコルの詳細については、「AWS GovCloud (US) ユーザーガイド」の「Service Endpoints」(サービスエンドポイント) を参照してください。
アベイラビリティーゾーン
リージョンごとにアベイラビリティーゾーンと呼ばれる複数の独立した場所があります。アベイラビリティーゾーンのコードは、リージョンコードとそれに続く文字識別子です。例えば、us-east-1a
と指定します。
インスタンスを起動するときに、リージョンと仮想プライベートクラウド (VPC) を選択し、いずれかのアベイラビリティーゾーンからサブネットを自ら選択するか、またはサブネットが選択されることを許可します。インスタンスを複数のアベイラビリティーゾーンに配布する場合は、1 つのインスタンスで障害が発生したら別のアベイラビリティーゾーンのインスタンスが要求を処理するように、アプリケーションを設計できます。また、Elastic IP アドレスを使用すると、あるアベイラビリティーゾーンのインスタンスの障害を、別のアベイラビリティーゾーンのインスタンスにアドレスをすばやく再マッピングすることによってマスクできます。
次の図は、AWS リージョン内の複数のアベイラビリティーゾーンを示しています。アベイラビリティーゾーン A とアベイラビリティーゾーン B にはそれぞれ 1 つのサブネットがあり、各サブネットにはインスタンスがあります。アベイラビリティーゾーン C にはサブネットがないため、このアベイラビリティーゾーンにインスタンスを起動することはできません。
アベイラビリティーゾーンが拡大すると、アベイラビリティーゾーンを拡張しにくくなる場合があります。その場合、ユーザーがアベイラビリティーゾーンに既にインスタンスを持っているのでない場合は、制約のあるアベイラビリティーゾーンでのインスタンスの起動を制限する場合があります。最終的に、制約のあるアベイラビリティーゾーンを新しいアカウントに対するアベイラビリティーゾーンのリストから削除することもあります。したがって、アカウントによってリージョン内で使用できるアベイラビリティーゾーンの数が異なる場合があります。
AZ ID
リソースがリージョンのアベイラビリティーゾーン全体に分散されるようにするために、アベイラビリティーゾーンは最も古いリージョンの各 AWS アカウント のコードに個別にマッピングされます。例えば、AWS アカウントの us-east-1a
の物理的な場所は、別の AWS アカウントの us-east-1a
の場所と異なる可能性があります。
アベイラビリティーゾーンをマッピングするアカウントも含め、すべてのリージョンのアカウント間でアベイラビリティーゾーンを調整するには、アベイラビリティーゾーンを示す一意で一貫性のある識別子、AZ ID を使用します。例えば、use1-az1
は us-east-1
リージョンの AZ ID であり、どの AWS アカウント でも同じ物理的な場所を表します。アカウントの AZ ID を表示して、別のアカウントのリソースに対するリソースの物理的な場所を特定できます。例えば、AZ ID use1-az2
のアベイラビリティーゾーンにあるサブネットを別のアカウントと共有する場合、このサブネットは AZ ID が同じく use1-az2
であるアベイラビリティーゾーンのそのアカウントでも利用できます。
アカウントの AZ ID を表示するには、EC2 ダッシュボード
次の図は、アベイラビリティーゾーンのコードの AZ ID に対するマッピングが異なる 2 つのアカウントを示しています。
利用可能なアベイラビリティーゾーン
次のリストに示すように、各リージョンには複数のアベイラビリティーゾーンがあります。
-
米国東部 (バージニア北部) –
use1-az1
|use1-az2
|use1-az3
|use1-az4
|use1-az5
|use1-az6
-
米国東部 (オハイオ) –
use2-az1
|use2-az2
|use2-az3
-
米国西部 (北カリフォルニア) –
usw1-az1
|usw1-az2
|usw1-az3
† -
米国西部 (オレゴン) –
usw2-az1
|usw2-az2
|usw2-az3
|usw2-az4
-
アフリカ (ケープタウン) –
afs1-az1
|afs1-az2
|afs1-az3
-
アジアパシフィック (香港) –
ape1-az1
|ape1-az2
|ape1-az3
-
アジアパシフィック (ハイデラバード) –
aps2-az1
|aps2-az2
|aps2-az3
-
アジアパシフィック (ジャカルタ) –
apse3-az1
|apse3-az2
|apse3-az3
-
アジアパシフィック (マレーシア) –
apse5-az1
|apse5-az2
|apse5-az3
-
アジアパシフィック (メルボルン) –
apse4-az1
|apse4-az2
|apse4-az3
-
アジアパシフィック (ムンバイ) –
aps1-az1
|aps1-az2
|aps1-az3
-
アジアパシフィック (大阪) –
apne3-az1
|apne3-az2
|apne3-az3
-
アジアパシフィック (ソウル) –
apne2-az1
|apne2-az2
|apne2-az3
|apne2-az4
-
アジアパシフィック (シンガポール) –
apse1-az1
|apse1-az2
|apse1-az3
-
アジアパシフィック (シドニー) –
apse2-az1
|apse2-az2
|apse2-az3
-
アジアパシフィック (東京) –
apne1-az1
|apne1-az2
|apne1-az3
|apne1-az4
-
カナダ (中部) –
cac1-az1
|cac1-az2
|cac1-az4
-
カナダ西部 (カルガリー) –
caw1-az1
|caw1-az2
|caw1-az3
-
欧州 (フランクフルト) –
euc1-az1
|euc1-az2
|euc1-az3
-
欧州 (アイルランド) –
euw1-az1
|euw1-az2
|euw1-az3
-
欧州 (ロンドン) –
euw2-az1
|euw2-az2
|euw2-az3
-
欧州 (ミラノ) –
eus1-az1
|eus1-az2
|eus1-az3
-
欧州 (パリ) –
euw3-az1
|euw3-az2
|euw3-az3
-
欧州 (スペイン) –
eus2-az1
|eus2-az2
|eus2-az3
-
欧州 (ストックホルム) –
eun1-az1
|eun1-az2
|eun1-az3
-
欧州 (チューリッヒ) –
euc2-az1
|euc2-az2
|euc2-az3
-
イスラエル (テルアビブ) –
ilc1-az1
|ilc1-az2
|ilc1-az3
-
中東 (バーレーン) –
mes1-az1
|mes1-az2
|mes1-az3
-
中東 (アラブ首長国連邦) –
mec1-az1
|mec1-az2
|mec1-az3
-
南米 (サンパウロ) –
sae1-az1
|sae1-az2
|sae1-az3
-
AWS GovCloud (米国東部) –
usge1-az1
|usge1-az2
|usge1-az3
-
AWS GovCloud (米国西部) –
usgw1-az1
|usgw1-az2
|usgw1-az3
† 新しいアカウントは、米国西部 (北カリフォルニア) の 2 つのアベイラビリティーゾーンにアクセスできます。
アベイラビリティーゾーンのインスタンス
インスタンスを起動するときは、インスタンスと特定のお客様を近づけるリージョン、または法的要件や他の要件を満たすリージョンを選択します。個別のアベイラビリティーゾーンでインスタンスを起動することにより、リージョン内の 1 つの場所で障害が発生しても、アプリケーションを保護することができます。
インスタンスを起動するときは、必要に応じて、使用するリージョン内のアベイラビリティーゾーンを指定できます。アベイラビリティーゾーンを指定しないと、アベイラビリティーゾーンが自動的に選択されます。初期インスタンスを起動する場合は、デフォルトのアベイラビリティーゾーンを受け入れることをお勧めします。これにより、システムの状態や利用可能なキャパシティーに基づいて、最適なアベイラビリティーゾーンを選択できます。追加のインスタンスを起動する場合、アベイラビリティーゾーンを指定するのは、新しいインスタンスを実行中のインスタンスと近づけるか、分離することが必要な場合に限ります。
Local Zones
ローカルゾーンは、地理的にユーザーに近い場所に位置する AWS リージョンを拡張したものです。Local Zones はインターネットへの独自の接続を持ち、AWS Direct Connect をサポートしているため、Local Zonesで作成されたリソースは、低レイテンシーの通信でローカルユーザーにサービスを提供できます。詳細については、AWS ローカルゾーンユーザーガイドの「AWS ローカルゾーンとは」を参照してください。
ローカルゾーンのコードは、そのリージョンコードの後に、物理的な場所を示す識別子が続きます。例えば、ロサンゼルスの us-west-2-lax-1
です。
次の図は、AWS リージョン us-west-2
、そのアベイラビリティーゾーンのうちの 2 つ、およびそのローカルゾーンのうちの 2 つを示しています。VPC は、アベイラビリティーゾーンといずれかのローカルゾーンにまたがっています。VPC 内の各ゾーンには 1 つのサブネットがあり、各サブネットにはインスタンスがあります。
利用可能な Local Zones
利用可能なローカルゾーンのリストについては、「AWS ローカルゾーンユーザーガイド」の「Available Local Zones」を参照してください。発表されたローカルゾーンのリストについては、「AWS Local Zones ロケーション
ローカルゾーンのインスタンス
ローカルゾーンを使用するには、最初にそれを有効にする必要があります。次に、ローカルゾーン内にサブネットを作成します。インスタンスの起動時にローカルゾーンのサブネットを指定できます。これにより、インスタンスは、ローカルゾーンのサブネットに配置されます。
ローカルゾーンでインスタンスを起動する際には、ネットワーク境界グループからの IP アドレスの割り当ても行います。ネットワークボーダーグループは、AWS が IP アドレスをアドバタイズするアベイラビリティーゾーン、Local Zones、または Wavelength Zones の一意のセットです (例: us-west-2-lax-1a
)。ネットワークボーダーグループから次の IP アドレスを割り当てることができます。
-
Amazon が提供する Elastic IPv4 アドレス
-
Amazon が提供する IPv6 VPC アドレス (ロサンゼルスゾーンのみで利用可能)
Local Zones でインスタンスを起動する方法の詳細については、「AWS Local Zones ユーザーガイド」の「AWS Local Zones 入門」を参照してください。
Wavelength Zone
AWS Wavelength を使用することで、デベロッパーは、モバイルデバイスおよびエンドユーザー向けに、非常にレイテンシーが低いアプリケーションを構築できます。Wavelength は、標準の AWS コンピューティングおよびストレージサービスを通信事業者の 5G ネットワークのエッジにデプロイします。デベロッパーは、Virtual Private Cloud (VPC) を 1 つ以上の Wavelength Zones に拡張し、Amazon EC2 インスタンスなどの AWS リソースを使用して、超低レイテンシーやリージョンの AWS サービスへの接続を必要とするアプリケーションを実行できます。
Wavelength Zone は、Wavelength インフラストラクチャをデプロイする先のキャリアロケーション内の独立したゾーンです。Wavelength Zone は、リージョンに関連付けられています。Wavelength Zone は、リージョンの論理的な拡張であり、リージョンの制御プレーンによって管理されます。
Wavelength Zone のコードは、そのリージョンコードの後に、物理的な場所を示す識別子が続きます。例えば、ボストンの us-east-1-wl1-bos-wlz-1
です。
次の図は、AWS リージョン us-west-2
、そのアベイラビリティーゾーンのうちの 2 つ、および Wavelength Zone を示しています。VPC はアベイラビリティーゾーンと Wavelength Zone にまたがっています。VPC 内の各ゾーンには 1 つのサブネットがあり、各サブネットにはインスタンスがあります。
Wavelength Zone は、すべてのリージョンで利用できるわけではありません。Wavelength Zone をサポートするリージョンについては、AWS Wavelength デベロッパーガイドの利用可能な Wavelength Zoneを参照してください。
利用可能な Wavelength Zone
利用可能な Wavelength Zone のリストについては、「AWS Wavelength ガイド」の「Available Wavelength Zones」を参照してください。
Wavelength Zone のインスタンス
Wavelength Zone を使用するには、まずゾーンにオプトインする必要があります。次に、Wavelength Zone にサブネットを作成します。インスタンスの起動時に Wavelength のサブネットを指定できます。また、ネットワークボーダーグループからキャリア IP アドレスを割り当てます。これは、AWS が IP アドレスをアドバタイズするアベイラビリティーゾーン、Local Zones、または Wavelength Zones の一意のセットです (例: us-east-1-wl1-bos-wlz-1
など)。
Wavelength Zone でインスタンスを起動する際のステップバイステップの指示については、「AWS Wavelength デベロッパーガイド」の「Get started with AWS Wavelength」を参照してください。
AWS Outposts
AWS Outposts は、AWS のインフラストラクチャ、サービス、API、ツールをお客様のオンプレミスまで拡張するフルマネージドサービスです。AWS は、AWS Outposts マネージドインフラストラクチャへのローカルアクセスを提供することで、AWS リージョンと同じプログラミングインターフェイスを使用してオンプレミスでアプリケーションを構築して実行できるようにします。同時に、コンピューティングとストレージのローカルリソースを使用して、レイテンシーを短縮し、ローカルのデータ処理ニーズに対応します。
Outpost とは、お客様のサイトにデプロイされる AWS のコンピューティングおよびストレージキャパシティーのプールです。AWS は、AWS リージョンの一部としてこのキャパシティーを運営、監視、管理します。Outpost にサブネットを作成し、AWS リソースを作成したときにこれらのサブネットを指定します。Outpost サブネット内のインスタンスは、プライベート IP アドレスを使用して、AWS リージョン内の他のインスタンスと通信します。これらはすべて同じ VPC 内にあります。
次の図は、AWS リージョン us-west-2
、そのアベイラビリティーゾーンのうちの 2 つ、および Outpost を示しています。VPC はアベイラビリティーゾーンと Outpost にまたがっています。Outpost は、オンプレミスの顧客データセンターにあります。VPC 内の各ゾーンには 1 つのサブネットがあり、各サブネットにはインスタンスがあります。
Outpost のインスタンス
AWS Outposts の使用を開始するには、Outpost を作成し、Outpost 容量を注文する必要があります。AWS Outposts には、Outposts ラックと Outposts サーバーの 2 つのフォームファクタがあります。Outposts の設定の詳細については、「AWS Outposts ファミリー
EC2 インスタンスを起動するには、Outpost サブネットを作成する必要があります。セキュリティグループは、アベイラビリティーゾーンサブネットのインスタンスと同様に、Outpost サブネットのインスタンスのインバウンドトラフィックとアウトバウンドトラフィックを制御します。Outpost サブネットの EC2 インスタンスに接続するには、アベイラビリティーゾーンサブネットのインスタンスで SSH を使用した接続を許可する場合と同様に、インスタンスの起動時にキーペアを指定できます。
詳細については、「Get started with Outposts racks」または「Get started with Outposts servers」を参照してください。
Outposts ラックのボリューム
Outposts コンピューティング容量が Outpost ラックにある場合、作成した Outpost サブネットに EBS ボリュームを作成できます。ボリュームの作成時に、Outpost の Amazon リソースネーム (ARN) を指定します。
次の create-volume コマンドは、指定した Outpost に空の 50 GB ボリュームを作成します。
aws ec2 create-volume --availability-zone
us-east-2a
--outpost-arn arn:aws:outposts:us-east-2
:123456789012
:outpost/op-03e6fecad652a6138
--size50
Amazon EBS gp2 ボリュームのサイズは、ボリュームをデタッチする必要なく動的に変更することができます。ボリュームをデタッチせずに変更する方法の詳細については、「Amazon EBS ユーザーガイド」の「Request modifications to your EBS volumes」を参照してください。
Outpost ラック上のインスタンスのルートボリュームを 30 GiB 以下に制限することをお勧めします。AMI またはインスタンスのブロックデバイスマッピングでデータボリュームを指定し、追加のストレージを提供できます。ブートボリュームから未使用のブロックを削除するには、AWS パートナーネットワークブログの「How to Build Sparse EBS Volumes
ルートボリュームの NVMe タイムアウトを増やすことをお勧めします。詳細については、「Amazon EBS ユーザーガイド」の「I/O オペレーションタイムアウト」を参照してください。
Outposts サーバー上のボリューム
Outposts サーバー上のインスタンスはインスタンスストアボリュームを提供しますが、EBS ボリュームはサポートしません。単一の EBS スナップショットのみを持つ Amazon EBS-backed AMI を選択します。アプリケーションの要件を満たすのに十分なインスタンスストレージを備えたインスタンスサイズを選択してください。詳細については、「インスタンスストアの制限」を参照してください。