【AWSユーザーガイド非公式解説】［VPC］4-1.VPC のサブネット（前半）
この記事はAWSユーザーガイドの以下リンクの解説記事です。
サブネットはVPCの内部に作成する仮想ネットワークです。EC2等のインスタンスはVPCに直接配置するのではなく、サブネットを作成しサブネット内に配置します。
サブネットの基本
サブネットはアベイラビリティゾーンをまたぐことはできません。
サブネットを作成する際は、アベイラビリティゾーンを指定して作成します。
障害対策の観点から複数のアベイラビリティゾーンにそれぞれサブネットを作成することが推奨されています。
このイメージ図では東京リージョンにVPCを作成し、ap-northeast-1aのアベイラビリティゾーンと、ap-northeast-1cのアベイラビリティゾーンにそれぞれプライベートサブネットとパブリックサブネットを配置しています。
サブネット IP アドレス範囲
サブネットはVPCのCIDRブロック範囲内でCIDRブロックを割り当てます。
VPCがIPv4のみの場合、サブネットもIPv4のみとなります。
IPv6のみのVPCを作成することはできず、IPv6を使用する場合は必ずデュアルスタックになります。
VPCがデュアルスタックの場合、IPv4のみ、デュアルスタック、IPv6のみを選択して割り当てます。
サブネットはVPCとは違いIPv6のCIDRブロックのみを割り当てることができます。
サブネットタイプ
サブネットのタイプはVPC外にどのように通信するかによって決まります。
- パブリックサブネット：インターネットゲートウェイへを通じて、インターネットと通信を行うサブネットです。
- プライベートサブネット：インターネットゲートウェイへのルート設定を行わないサブネットです。
- VPNのみのサブネット：仮想プライベートゲートウェイを通じて、 Site-to-Site VPN 接続を行うサブネットです。
公式ではVPNのみのサブネットとなっていますが、一般的にはプライベートサブネットとして取り扱われていると思います。 - 隔離されたサブネット：ゲートウェイの紐づけがなく、VPC内でのみ通信を行うサブネットです。
公式では隔離されたサブネットと読んでいますが、一般的にはプライベートサブネットとして取り扱われていると思います。
AWSでは、インターネットゲートウェイを通じて、インターネットと通信を行うサブネットはパブリックサブネットとなります。
サブネットの図表
公式ではここでいきなりローカルゾーンの図が出てきます。
ローカルゾーンはアベイラビリティゾーンの機能縮小版のようなものです。
上記リンクをみるとus-east-1 米国東部 (バージニア) には「アトランタ (米国)」というローカルゾーンがあります。
us-east-1アベイラビリティゾーンの具体的な場所は不明ですが、バージニア州のどこかにあると思われます。
アトランタはジョージア州です。
アトランタからバージニアまでは場所によりますが1,400kmほどの距離があり、そのレイテンシーを無視できない場合は、アトランタにあるローカルゾーンを使用する選択肢が考えられます。
ローカルゾーンではリージョンのすべての機能を使えるわけではありません。
使用可能な機能はローカルゾーンによって異なり、この記事作成時点でアトランタで使用可能な機能は下表のとおりです。
| 機能 | 可否または制限 |
|---|---|
| Amazon EC2 | C6i、M6i、R6i, C6gn、P5 インスタンス |
| Amazon EBS | 汎用 SSD (gp3)、汎用 SSD (gp2)、プロビジョンド IOPS SSD (io1)、スループット最適化 HDD (st1)、コールド HDD (sc1) |
| AWS Shield | スタンダード |
| Amazon ELB | ALB |
| Amazon ECS | ◯ |
| Amazon EKS | ◯ |
| Amazon VPC | ◯ |
| Amazon Direct Connect | ◯ |
| Amazon FSx | ◯ |
| Amazon EMR | ◯ |
| Amazon ElastiCache | ✕ |
| Amazon RDS | ✕ |
| Amazon GameLift | ◯ |
| Application Migration Service | ◯ |
| NAT ゲートウェイ | ✕ |
| Amazon Route 53** | ◯ |
機能が制限されていることからも、ローカルゾーンはアベイラビリティゾーンほどの大規模なデータセンターではなく、小規模または他社データセンターの区画を借りる形で作られていると推測されます。
アトランタローカルゾーンのゾーン名は「us-east-1-atl-2a」となります。米国東部 (バージニア) リージョンが「us-east-1」であることからもわかるように、アトランタローカルゾーンは米国東部 (バージニア) リージョンの一部（所属）という位置づけになり、米国東部 (バージニア) のVPCで使用することができます。
日本のような小さな国ではローカルゾーンは関係ないように思えますが、東京リージョンにもローカルゾーン台北 (台湾)「ap-northeast-1-tpe-1a」があります。台湾にはリージョンがないため、おそらく台湾の人は東京リージョンを使用していると思われます。地理的には大阪の方が近いような気もしますが、国際的には東京の方が有名だからかもしれません。
ローカルゾーンは有効化しないと使用できません。
EC２のダッシュボード右下の「ゾーン」から「追加のゾーンを有効にする」をクリックするとローカルゾーンを含めたゾーンの一覧を見ることができます。この画面でローカルゾーンを有効化するとローカルゾーンを利用可能になります。
注：下の画面はローカルゾーンで絞り込みを行っていますが、この画面にはアベイラビリティゾーンも出てきます。
ローカルゾーンを有効化するとサブネット作成画面で、ローカルゾーンを使用可能になります。
ローカルゾーンはアベイラビリティゾーンの機能縮小版であり、サブネット作成時にアベイラビリティゾーンまたはローカルゾーンを選択する形になります。
ローカルゾーンのイメージは以下です。
アベイラビリティゾーンと並列となり、ローカルゾーンにサブネットを配置します。
サブネットのルーティング
サブネット内のリーソスは通信を行う際にルートテーブルを使用します。
VPCにはメインルートテーブルがあり、サブネットを作成する際は自動的にメインルートテーブルが関連付けられます。メインルートテーブルではなく別のルートテーブルを作成して関連付けることもできます。ルートテーブルについては後述します。
サブネットの設定
サブネット作成時の設定画面は以下です。
IPアドレスの自動割り当て設定
-
パブリック IPv4 アドレスの自動割り当てを有効化
このサブネットのリソースに対してパブリックIPv4アドレスを割り当てるかを選択します。サブネットの設定で有効化をしていても、リソース側の設定でパブリックIPv4アドレスを割り当てずに起動することもできます。 -
お客様が所有する IPv4 アドレスの自動割り当てを有効化
AWS Outpostサブネットの場合に有効化できます。プライベートIPv4アドレスを持ち込み、サブネットに割り当てて、オンプレミス環境との接続が可能です。
リソースベース名設定
-
起動時にリソース名 DNS A レコードを有効化
DNSのAレコードとしてリソースベースのホスト名を登録するかどうかを選択できます。サブネットの設定で有効化をしていても、リソース側でDNSリクエストを無効にすることができます。 -
起動時にリソース名 DNS AAAA レコードを有効化
DNSのAAAAレコードとしてリソースベースのホスト名を登録するかどうかを選択できます。IPv6アドレスを使用する場合の設定です。サブネットの設定で有効化をしていても、リソース側でDNSリクエストを無効にすることができます。
DNS64の設定
- DNS64 を有効化
IPv6ベースのサブネットで他のIPv4ベースのサブネット等と通信を行う場合に有効化します。
サブネットのセキュリティ
AWSでは、リソースは可能な限りプライベートサブネットに配置し、インターネットアクセスが必要な場合はNATデバイス（NATゲートウェイ及びNATインスタンス）または踏み台サーバを利用することが推奨されています。オンプレミスネットワークでDMZに配置するサーバを限定する考えと同じです。
AWSは以下の機能を利用して、VPC内のリソースのセキュリティを確保します。
-
セキュリティグループ
セキュリティグループはEC2等のリソースに紐づけて使用する機能です。サブネットの章で説明するのは適切ではないですが、ネットワークACLとの関連があるため、説明しています。
セキュリティグループはリソースに対し、インバウンドのトラフィックとアウトバウンドのトラフィックを制御します。 -
ネットワークACL
ネットワークACLはサブネットに紐づけて使用します。サブネットに対し、インバウンドのトラフィックとアウトバウンドのトラフィックを制御します。
感覚的にはネットワークACLが外側、セキュリティグループが内側なので、まずは外側（ネットワークACL）で制御してより細かい制御を（セキュリティグループ）で制御するような気がしますが、AWSでは逆です。可能な限りセキュリティグループで制御し、セキュリティグループで制御できない通信要件の場合のみネットワークACLを使用することが推奨されています。
どちらもトラフィックを制御するという役割はおなじですが、セキュリティグループとネットワークACLは機能の違いがあります。
1つ目の大きな違いはセキュリティグループはステーフル、ネットワークACLはステートレスという点です。
-
ステートフル
行きの通信が許可されていれば、戻りの通信を許可しなくても自動で許可します。許可した通信を記憶（保持）していて、その通信に対する戻りの通信を許可する仕組みです。 -
ステートレス
行きの通信を許可されていても、戻りの通信を明示的に許可されていなければ通信が拒否されます。
例えばWebの仕組みでは行きは80番ポートまたは443ポートが一般的に使用されます。戻りの通信はブラウザ等により、ダイナミックポート「49152番 - 65535番」から割り当てられて使用されます。
セキュリティグループでインバウンド通信の80、443を許可しておけば、ダイナミックポートに対するアウトバウンド通信の許可は必要ありません。
下表はWebサーバのインバウンドルールの例です。
| タイプ | プロトコル | ポート範囲 | ソース |
|---|---|---|---|
| HTTP | TCP | 80 | 0.0.0.0/0 |
| HTTPS | TCP | 443 | 0.0.0.0/0 |
2つ目の大きな違いはセキュリティグループでは、ソース（送信元）にセキュリティグループを設定できるという点です。
DBサーバーにWebサーバからのアクセスのみを許可したい場合、WebサーバのIPアドレスで指定するのではなく、Webサーバのセキュリティグループからの通信を全て許可するというルールを設定することができます。
下表はDBサーバのインバウンドルールの例です。
| タイプ | プロトコル | ポート範囲 | ソース |
|---|---|---|---|
| MYSQL/Aurora | TCP | 3306 | SG-WEBSERVER-xxxxx |
AWSのリソースはDHCPがデフォルトであり、IPアドレスが変わった場合もセキュリティグループをソースに指定していれば、許可されます。
3つ目の大きな違いはセキュリティグループはデフォルトの設定が拒否であり、許可するルールを設定するもの、ネットワークACLは、許可・拒否を設定できます。
これらの違いから、通常の生業はセキュリリティグループで行い、セキュリティグループのみで実現できないような制御の場合にネットワークACLを利用することが推奨されています。例えば特定のIPアドレス範囲からの通信を拒否するというような設定はセキュリティグループでは実現が難しく（特定のIPアドレス範囲「以外」を網羅して許可するルールとして登録すればできないわけではない）、そのような場合はネットワークACLを使用することになります。
サブネットにはネットワークACLを紐づける必要があります。VPCにはデフォルトのネットワークACLがあり、全ての通信を許可する設定となっています。コンソールでサブネットを作成するとデフォルトのネットワークACLが紐づけられて作成されます。
デフォルトのネットワークACLの内容を編集して使用するか、または別のネットワークACLを作成して紐づけることも可能です。
VPC またはサブネットでフローログを作成し、VPC またはサブネットでネットワークインターフェイスとの間を行き来するトラフィックをキャプチャできます。個別のネットワークインターフェイスでフローログを作成することもできます。
サブネットの作成
サブネットからの IPv6 CIDR ブロックを追加または削除する
サブネットの IP アドレス指定属性を変更する
サブネットCIDR予約
基本的には使用方法は解説しませんが、サブネットCIDR予約に関しては機能がわかりづらいため解説します。
AWSではIPアドレスの割り当てはDHCPで自動割り当てとするのが原則です。しかしながら何らかの理由によりIPアドレスを手動割り当てを行いたい場合はEC2の設定で割り当てが可能です。
サブネットCIDR予約は今はまだ設定していないものの、将来的に手動割り当てを行う可能性があるCIDRブロックを登録しておき、AWSによる自動割り当ての範囲外とする機能です。
Discussion