こんにちは！エンタープライズクラウド部 技術２課の日高です。
Amazon VPC（今後はVPCと表記）を設計する際に「VPCとサブネットのCIDRの範囲はどうしよう」など迷ってしまうことありませんか？？
今回はVPC・サブネットの設計をなるべく迷わずに行えるように、設計時のポイントをまとめてみました。
VPCの構築時に必要な項目
マネジメントコンソールで、VPCを作成しようとすると主に「CIDR範囲」と「テナンシー」を記入/選択すると思います。
しかし作成後の、VPCの詳細を見てみると「CIDR範囲」と「テナンシー」以外にも様々な設定が表示されます。
この章では、それぞれの項目がどんな役割なのかを書いていきます。
テナンシー
EC2を起動するハードウェアを ①共有(default)で使うか ②専用(dedicated)で使うか を指定する項目です。
②で起動するとインスタンスは常に「Dedicated Instances」として起動されます。
「Dedicated Instances」は通常のインスタンスと比べて料金が高いため特別な要件がない方は①の利用をお勧めします。
※料金比較
リージョン：オハイオ OSタイプ：Linux インスタンスタイプ：m5a.large
オンデマンドの時間単価
通常のインスタンス料金：0.086 USD
Dedicated Instances料金：0.0910 USD
【参考資料】
通常のインスタンス料金：
https://aws.amazon.com/jp/ec2/pricing/on-demand/
Dedicated Instances料金：
https://aws.amazon.com/jp/ec2/pricing/dedicated-instances/
DHCPオプションセット
DHCPのオプションに関するパラメータ(DNSサーバやドメイン名など)を指定する項目で、(1)デフォルト DHCP オプションセットを使うか (2)カスタムDHCP オプションセットを使うか を指定できます。
基本的に、(1)で問題ないですが、Amazon 以外の DNS、NTPなどを利用したい場合は(2)を選択します。
※詳しくは以下をご覧ください
DNS解決
VPC が Amazon 提供の DNS サーバーを介した DNS 解決策をサポートするかどうかを指定する項目です。
推奨設定は、要件により有効・無効の判断は変わると思うので後述の「DNS解決とDNSホスト名の考慮事項」にまとめたいと思います。
DNSホスト名
VPC 内に起動されるインスタンスが パブリック DNS ホスト名を取得するかどうかを指定する項目です。
有効にすることで、VPC内に起動されるインスタンスに名前解決可能なFQDNが付与されます。
推奨設定は、要件により有効・無効の判断は変わると思うので後述の「DNS解決とDNSホスト名の考慮事項」にまとめたいと思います。
DNS解決とDNSホスト名の考慮事項
DNS解決とDNSホスト名の有効/無効の組み合わせにより、どのように動作するか書いていきます。
※VPCのDNS解決とDNSホスト名の関係性について検証した結果については下記ブログにまとめているので、よければご覧ください
(1)両方有効にする
Amazon Route 53 のプライベートホストゾーンや、VPC ピアリングを使用する場合は有効にする必要があります。
また以下のような要件の場合両方を有効にします。
- パブリック IP アドレスを持つインスタンスで、対応するパブリック DNS ホスト名を受け取れる。
- Amazon Route 53 Resolver サーバーを使って、Amazon が提供するプライベート DNS ホスト名を解決できる。
(２)少なくとも 1 つの属性が無効
- パブリック IP アドレスを持つインスタンスは、対応するパブリック DNS ホスト名を受け取らない。
- Amazon Route 53 Resolver は、Amazon が提供するプライベート DNS ホスト名を解決できない。
※詳しくは以下をご覧ください docs.aws.amazon.com
※補足
DNS解決とDNSホスト名を指定しないでVPCを新規作成するとデフォルトでは以下の設定値になります。
- VPCの新規作成時に「VPCなど」を選び作成した場合＝「DNS解決」「DNSホスト名」ともに有効になっています。
- VPCの新規作成時に「VPCのみ」を選び作成した場合＝「DNS解決」が有効に、「DNSホスト名」が無効になっています。
- VPCの新規作成時にCloudFormationで作成した場合＝「DNS解決」が有効に、「DNSホスト名」が無効になっています。
VPC設計時のポイント
先に概要を示すとこのようになります。
・CIDRは/16程度の大きめのものを割り当てる
・IPアドレス範囲の重複に気をつける
・RFC1918準拠のプライベートIPアドレス範囲から指定する
CIDRは/16程度の大きめのものを割り当てる
新機能の追加など、拡張が発生した際にIPアドレス不足になることを避けるためにVPCのCIDRは/16程度の大きめのものを割り当てることを推奨します。
また、VPCはAWSアカウント内に複数構築が可能な為、別システムをAWSに構築する際はVPCを分けて構築するか、別アカウントを利用して構築することを推奨します。
理由としては、同一のVPCに複数のシステムを構築すると環境が複雑になり「運用性」「拡張性」が悪くなってしまいます。 さらに、侵入された場合などに被害がすべてに広がってしまいます。
IPアドレス範囲の重複に気をつける
オンプレミスとの接続の際や、他VPCと接続する際にIPアドレスの重複があると通信ができなくなってしまいます。
そのため、VPCの設計をする際に、オンプレミスとの接続や他VPCとの接続は今後ありえるのかも検討する必要があります。
RFC1918準拠のプライベートIPアドレス範囲から指定する
基本的にVPCのCIDRはRFC1918準拠のプライベートIPアドレス範囲から指定することを推奨しています。
※RFC1918準拠のプライベートIPアドレス範囲
もちろんグローバルIPアドレスの範囲からCIDRを指定することも可能ではあります。
しかし、すでに他で利用されているグローバルIPアドレスと重複した場合に通信ができなくなる可能性があるため基本的にVPCのCIDRはRFC1918準拠のプライベートIPアドレス範囲から指定することを推奨しています。
※参考資料（RFC 1918 - Address Allocation for Private Internets） www.faqs.org
サブネット設計時のポイント
・/24程度の大きめなものを割り当てる
・役割別でサブネットを作成する
・CIDRブロックのうち、5つのIPアドレスは利用できない
・2つ以上のアベイラビリティゾーン（今後はAZと表記）を利用する
/24程度の大きめなものを割り当てる
こちらもVPC同様、IPアドレス不足を防ぐためにCIDRは大きめなものを割り当てることをお勧めします。
サービスによっては、1つで複数のIPアドレスを消費するものも存在する為、極端に小さいCIDRは使わないことをお勧めします。
役割別でサブネットを作成する
サブネットはインターネット通信の可否によって役割を分けて設計することをお勧めします。
このようにサブネット単位でルーティングを設定し、細かい通信制御にセキュリティグループを設けることで通信制御が分かりやすくなります。
・パブリックサブネット：インターネットゲートウェイ経由でインターネットと直接通信ができるサブネット
・プロテクテットサブネット：NATゲートウェイ経由でインターネットと通信ができるサブネット
・プライベートサブネット：インターネットと通信ができないサブネット
CIDRブロックのうち、5つのIPアドレスは利用できない
各サブネット CIDR ブロックの最初の 4 つの IP アドレスと最後の IP アドレスはAWSにより予約されているため利用できません。
例)CIDR ブロック 10.0.0.0/24 を持つサブネットの場合以下のIPアドレスが予約されます。
・10.0.0.0.: ネットワークアドレスです。
・10.0.0.1: AWS が VPC ルーター用に予約しています。
・10.0.0.2: AWS が予約しています。DNS サーバーの IP アドレスは、VPC ネットワーク範囲のベースにプラス 2 したものです。複数の CIDR ブロックを持つ VPC の場合、DNS サーバーの IP アドレスはプライマリ CIDR にあります。また、VPC 内のすべての CIDR ブロックに対して、各サブネットの範囲 + 2 のベースを予約します。
・10.0.0.3: 将来の利用のために AWS が予約しています。
・10.0.0.255: ネットワークブロードキャストアドレスです。VPC ではブロードキャストがサポートされないため、このアドレスを予約します。
※サブネットのサイズ設定抜粋
2つ以上のアベイラビリティゾーン（今後はAZと表記）を利用する
まず、AZとは「1 つの AWS リージョン内にある、1 つ以上のデータセンターのこと」です。
AZとAZの間は、数km～100km以内の範囲で離れて配置されています。
突然ですが、例を挙げて考えてみましょう。
停電、落雷、竜巻、地震など意図しない障害があり、AZ①は障害が起こっている AZ②はその障害に巻き込まれていないとします。
この場合AZ①のみを利用している場合はシステムが止まってしまいますが、AZ②も利用している場合は縮退運転でシステムを動作させることができます。
このように可用性考慮の為、サブネットを作成する際は2つ以上のアベイラビリティゾーン（今後はAZと表記）を利用することをお勧めします。
補足（サブネットの計算方法）
ここまででVPCの設計とサブネットの設計方法についてご理解いただけたと思います。
ただ、私自身サブネットの計算を難しく感じていたため補足としてこの章で書いていきたいと思います。
ネットワークアドレスの規則性
サブネットのCIDRはネットワークアドレスを記入しています。
そのため、このネットワークアドレスの規則性を押さえることで、サブネットのCIDRを~/24で設定したい際に利用できるCIDRはこれだ！と理解することができます。
/24~/31のネットワークアドレス
今回はVPCのCIDRが10.0.0.0/16の場合を例にして見ていきます。
結論として 24~/31のネットワークアドレス の規則性（第４オクテットが～の倍数）は以下の表のようになっています。
サブネットのCIDRが/27だった場合、どのようになるかを見ていきます。
まず/27のネットワーク部とホスト部はこのようになります。
ネットワークアドレスはホスト部がすべて０でなくてはいけないため、６ビット目以上の桁でしか１は使えません。 そのため、/27のサブネットの第４オクテットは必ず32の倍数になります。
この/27を基準に１ビット桁数が増えるとサブネットの第４オクテットの倍数は２倍になり、１ビット桁数が減ると0.5倍ずつになります。 例としては、/26のサブネットの第４オクテットは64の倍数になりますし、/28のサブネットは16の倍数になります
/16~/23のネットワークアドレス
/24~/31と同様、VPCのCIDRが10.0.0.0/16の場合を例にして見ていきます。
結論として/16~/23のネットワークアドレスは /24~/31の第３オクテット版となります。
これはネットワーク部を８ビットずらすとちょうど１オクテット分になるためです。
まとめ
VPCとサブネットの設計のポイントについて書かせていただきました。
本記事が誰かの助けになれば幸いです。
日高 僚太(執筆記事の一覧)
2024 Japan AWS Jr. Champions / 2024 Japan AWS All Certifications Engineers
EC部クラウドコンサルティング課所属。2022年IT未経験でSWXへ新卒入社。
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
