COLUMN

基本的な仕様

Amazon VPCに利用するIPv4アドレス範囲については、下記のようなルールがあります。

• 許可されるIPアドレス範囲は/16のサブネットマスク(65,536個のIPv4アドレス)から、/28のサブネットマスク(16個のIPv4アドレス)
• RFC1918に規定されたプライベートIPv4アドレスが推奨されるが、RFC1918に規定されていないIPv4アドレスも設定自体は可能
• VPCには、2つ目のIPv4アドレス範囲（セカンダリCIDRブロック）を利用することも可能
• VPCに関連付けたIPv4アドレス範囲から、サブネットに利用
• サブネットは/16から/28のサブネットマスクを利用可能

そのほかは基本的にはこちらのドキュメントに記載があります。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-cidr-blocks.html

基本的な仕様からは多くのIPv4アドレス範囲から選択できるようになっています。

AWSのネットワーク設計・構築に関するご相談・お悩みなどNTT東日本のクラウドエンジニアがご相談にお応えします！お気軽にお問い合わせください。

制限事項

次に、制限事項を確認したいと思います。

VPCに関する制限事項

• 一部のAWSサービスで、172.17.0.0/16と、172.16.0.0/12のCIDR範囲を使用
  （例えば、Amazon SageMaker AIで172.17.0.0/16を使用し、Amazon RDSで172.16.0.0/12を使用）
• セカンダリCIDRブロックは、ルートテーブルにある送信先のCIDRブロックとの重複は不可
• VPCピアリング、Transit Gateway、Direct Connectを使用して複数のVPCや他のネットワークと接続する場合は重複不可

サブネットに関する制限事項

各サブネットの最初の4つのIPアドレスと、最後のIPアドレスは使用不可

（例）10.0.0.0/24のサブネットの場合

• 10.0.0.0　　・・・ネットワークアドレス
• 10.0.0.1　　・・・VPCルータ用
• 10.0.0.2　　・・・AWSが内部のDNSサーバ用に予約済（Amazon Route 53 Resolver）
• 10.0.0.3　　・・・将来の利用のために予約済
• 10.0.0.255　・・・ブロードキャストアドレス

導き出されるベストプラクティス

これらの制限事項と、他のネットワークとの兼ね合いによる制約事項を加味したうえで、IPv4アドレス範囲を決める際のベストプラクティスを検討します。

VPCに払い出すIPアドレス範囲のベストプラクティス

他のネットワーク等によるIPアドレス範囲に制約事項が"ない"場合

AWSを初めて利用する、Webシステムなどで他のネットワークと接続せず独立したVPCを作る場合です。

① RFC1918で定められたIPv4アドレスのうち、10.0.0.0/8の一部をAWS用として確保します

IPアドレスの範囲は自由に決めることもできますが、IPアドレスを一目見たときに何の用途で、どの場所に使われているかがわかりやすいよう管理しておくことが推奨です。

今後のAWS利用の拡大を踏まえると、VPCが複数に増えていくことも踏まえ10.0.0.0/8の一部をAWS用として確保してしまうのがAWSを最大利用する際のベストプラクティスといえます。VPCを/16で払い出す場合、最大256個のVPCまで拡張させることができます。

他のアドレス範囲が使えないということもないのですが、下記の理由から選択肢の優先度は下がると考えられます。

• 172.12.0.0/12については、今後もRDSやSageMaker AIを使用しない、という場合には利用してもよいと考えられます。
• 192.168.0.0/16については、単一のVPCで運用する場合では問題ありませんが、今後VPCを複数利用する際に別のIPアドレス範囲から払い出すことになるため、IPアドレス管理の観点で若干複雑になります。
• その他のIPv4アドレス範囲については、RFC6890で規定された100.64.0.0/10を除き非推奨です。すでに他のシステムやサイト、AWSの内部で利用されており、他のサイトの利用やAWSの利用に影響がある可能性があります。100.64.0.0/16については、キャリアグレードNATと呼ばれ、大規模なネットワークの内部で使われております。

② 一つのVPCあたり、できるだけ大きなサブネットマスクとし可能であれば、/16で払い出します

/16で65,536個のIPv4アドレスが利用できるとなると、非常に多く使えるイメージがあります。

65000台のサーバやコンテナを使うシーンは想像できないと思うかもしれません。

しかし、利用者側で指定しない場合でも、VPCに払い出されたIPアドレスはAWSのマネージドサービスが利用します。

(例)

• サブネットを払い出した際の予約アドレス（前述の通り）
• VPCエンドポイント
• Network Load Balancer
• NAT Gateway

IPアドレスが足りなくなると新たなリソースを構築できなくなりますので、VPCのサブネットマスクはできるだけ大きく払い出すことを推奨します。

また、予約アドレスを留意してサブネット内部のIPアドレス範囲を決めておきます。

基本的に同じ役割のリソースは、例えば第4オクテットをそろえておく（AutoScalingの場合は、範囲をそろえておく）、カスタマーマネージドプレフィックスリストを使って事前に決めてしまうのもよいかと思います。

他のネットワークの兼ね合いでIPアドレス範囲に制約事項が"ある"場合と、その回避策

次に、制約事項がある場合のベストプラクティスを考えてみたいと思います。

例えば、次のような制限事項があります。

• オンプレミス側で10.0.0.0/8を使用しており、通信が必要な場合
• オンプレミス側ですでに172.16.0.0/12を使用している場合
• オンプレミス側のIPアドレス範囲が重複している場合
• すでに利用できる範囲がほとんどない場合

いずれの場合も、オンプレミス側のIPアドレスは変更ができない前提とします。

オンプレミス側で10.0.0.0/8を使用しており、通信が必要な場合

制約がない場合と同様、AWS用のIPv4アドレス範囲を10.0.0.0/8の中から、できるだけ連続した多くのIPアドレスを使用できるようにします。

たとえば、オンプレミス側で10.0.0.0/16 - 10.100.0.0/16を利用している場合には10.128.0.0/9をAWS用として確保しておき、10.128.0.0/16から順に払い出す運用とするなど決めておきます。

拠点側で飛び飛びで利用している場合も、いくつかを確保しておきます。

オンプレミス側ですでに172.16.0.0/12を使用している場合

前述の通り、SageMaker AIとRDSを使用しない場合は、制約がない場合と同様です。

SageMaker AIとRDSを利用する場合は、通信の方向を意識して構成します。

• オンプレミス⇒AWSの片方向通信でよい場合

オンプレミスと接続するVPCと、ワークロード用のVPCに分割します。

オンプレミスと接続するVPCは、オンプレミスとIPアドレス範囲が重複しないようにします。

ワークロード用のVPCは、172.16.0.0/12以外のIPv4アドレス範囲でVPCを作成します。

オンプレミスと接続するVPCとワークロード用のVPCをPrivatelinkで接続します。

172.16.0.0/12の範囲で拠点側のIPアドレスが重複している場合は、重複があるごとに中継用のVPCを構築します。

次の図は本ケースでの構成イメージとなります。

• オンプレミス⇔AWSの双方向通信が必要な場合

この場合、VPCから見た場合、オンプレミス側のIPアドレスを別のものに見せかける必要があります。

一例としては、下記のような構成となります。

VPC側ではNATインスタンスを利用していますが、これは静的NATを使用するためです。

NAT Gatewayは動的NATとなるため、オンプレミスからの通信において通信経路を固定するために、静的NATを利用します。

NATインスタンスを利用する場合は帯域や可用性の確保も考慮に入れたインスタンス設計が必要となります。

拠点側のIPアドレス範囲が重複している場合

これも前述の構成のように、通信方向を意識して構成します。

• オンプレミス⇒AWSの片方向通信でよい場合

オンプレミスと接続するVPCと、ワークロード用のVPCに分割します。

オンプレミスと接続するVPCは、オンプレミスとIPアドレス範囲が重複しないように、重複があるごとにVPCを構成します。

ワークロード用のVPCは、172.16.0.0/12以外のIPv4アドレス範囲でVPCを作成します。

オンプレミスと接続するVPCとワークロード用のVPCをPrivatelinkで接続します。

• オンプレミス⇔AWSの双方向通信が必要な場合

これは前述の構成と同様ですので、構成例は省略します。

そのほか、オンプレミスで大量のアドレスを使用しており、RFC1918の範囲ですでに重複しない範囲が/24以下の場合もあります。

この場合は、100.64.0.0/10の範囲を利用する以外の方法でもっと良い方法があれば次回以降のコラムで投稿したいと思います。

AWSのネットワーク設計・構築に関するご相談・お悩みなどNTT東日本のクラウドエンジニアがご相談にお応えします！お気軽にお問い合わせください。

まとめ

VPCに払い出すIPv4アドレス範囲については、VPCがリリースした当初よりも制限のあるIPアドレスが増えているため、オンプレミスやその他の全体のネットワーク設計を見ながら実施する必要があります。

特に重複しているアドレスを使用した場合は、運用面における負荷が増える可能性が高いためIPアドレス設計は初期段階から計画的に行う必要があります。

適切なIPアドレス計画をもって、シンプルなネットワーク構成を心掛けるようにしましょう。

NTT東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供をおこなっております。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！