VPCにセカンダリCIDRを追加した場合のVPCのルートテーブルとTransit Gateway Route Tableの設定をまとめてみた

セカンダリCIDR追加時のVPCのルートテーブルとTransit Gateway Route Tableの設定内容をまとめました。 Transit Gateway Attachment用のサブネットを作ろうとするも、対象VPCのCIDRには既に空きがない場面に遭遇しそうな方は必見です。
2021.09.02

VPCにセカンダリCIDRを追加した場合のルーティングを完全に理解したい

こんにちは、のんピ(@non____97)です。

皆さんはVPCにセカンダリCIDRを追加した場合のルーティングを完全に理解していますか? 私は理解していません。

そもそも、セカンダリCIDRの設定自体したことがないです。

そんな私ですが、とある案件でTransit Gateway Attachment用のサブネットを作ろうとするも、対象VPCのCIDRには既に空きがない場面に遭遇しました。

その対処方法として、「VPCにセカンダリCIDRを追加すれば良いのかな?」と直感的に思ったのですが、セカンダリCIDR追加後のルーティングへの影響がイマイチ分かりませんでした。

そこで、VPCにセカンダリCIDRを追加した場合のVPCのルートテーブルとTransit Gateway route tableの設定をまとめてみようと思います。

いきなりまとめ

  • セカンダリCIDRに割り当て可能な範囲は制限されるので要注意
  • セカンダリCIDR追加時に自動で対象VPCの各ルートテーブルに、追加したセカンダリCIDRのルートが設定される
  • Transit GatewayのPropagationを有効にすると、アソシエーションしたVPCのセカンダリCIDRへのルートもTransit Gateway Route Tableに追加される
    • ただし、セカンダリCIDRのルートを削除しても通信はできる

検証の環境

今回の検証の構成は以下の通りです。

検証環境構成

検証の内容としては、VPC AとVPC BのそれぞれのVPCにセカンダリCIDRを追加して、セカンダリCIDRにTransit Gateway Attachment用のサブネットを作成します。その後、VPC間をTransit Gatewayで接続してVPC AのEC2インスタンスからVPC BのEC2インスタンスにpingで疎通確認をします。

セカンダリCIDRについて重要なポイントを一点補足します。ポイントはプライマリCIDRの範囲によって、割り当て可能なセカンダリCIDRの範囲は制限される点です。

例えば、プライマリCIDRの範囲が10.0.0.0/8の場合、以下のような制限があります。

  • 172.16.0.0/12および192.168.0.0/16の範囲は割り当てできない。
  • プライマリCIDRが10.0.0.0/15の範囲内にある場合、10.0.0.0/16の範囲のCIDRブロックは追加できない。

そのため、AWSに割り当てるネットワークとして、10.0.0.0/16を確保しており、実際に使用しているCIDRが10.0.0.0/24のみだとしても、セカンダリCIDRは10.1.0.0/1610.2.0.0/16など、10.0.0.0/16範囲外のCIDRを指定する必要があります。

その他の制約事項については、AWS公式ドキュメントにまとめられていますので、こちらをご覧ください。

なお、検証開始時点では以下のような環境です。

検証環境構成_スタート時点

セカンダリCIDRの追加

まず、セカンダリCIDRの追加を行います。

VPCのコンソールから、セカンダリCIDRを追加したいVPCを選択して、アクション - CIDRの編集をクリックします。

セカンダリCIDRの追加

新しいIPv4 CIDRを追加をクリックして、追加したいCIDRを入力します。その後、保存をクリックし、正常に保存できたことを確認して閉じるをクリックします。

CIDRの編集

セカンダリCIDR追加後、VPCのIPv4 CIDRの項目を確認すると、セカンダリCIDR(10.1.0.0/28)が追加されていることが分かります。

VPC AのセカンダリCIDR追加の確認

ここで、セカンダリCIDRを追加したVPC Aの各ルートテーブルを確認します。

VPC Aの各ルートテーブルを確認すると、セカンダリCIDR(10.1.0.0/28)のルートが追加されていることが分かります。

  • VPC AのPrivateサブネットのルートテーブル VPC AのPrivateサブネットのルートテーブル
  • VPC AのPublicサブネットのルートテーブル VPC AのPublicサブネットのルートテーブル

VPC Aに対して正常にセカンダリCIDRが追加できていることを確認できたので、VPC Bに対してもセカンダリCIDR(10.1.1.0/28)を追加します。

VPC BのセカンダリCIDR追加の確認

これで、VPC AとVPC Bに、Transit Gateway Attachment用のサブネットを作成する分のCIDRを確保できました。

Transit Gateway Attachment用のサブネットの作成

続いて、Transit Gateway Attachment用のサブネットを作成します。

まず、VPC AのTransit Gateway Attachment用のサブネットです。

CIDRは先ほど追加したセカンダリCIDRを指定して、AZはPrivateサブネットやPublicサブネットと同じAZを指定します。

Transit Gateway Attachment用サブネットの作成

サブネット作成後に意図したCIDRでサブネットが作成されているかを確認します。

VPC AのTransit Gateway Attachment用のサブネットの確認

なお、サブネットに関連付けるルートテーブルは明示的に指定せず、VPCのメインルートテーブルをそのまま使用します。

VPC Aのデフォルトルートテーブル

VPC BもVPC Aと同様にTransit Gateway Attachment用のサブネットを作成します。

Transit Gateway Attachmentの作成

Transit Gateway Attachment用のサブネットを作成が完了したので、Transit Gateway Attachmentを作成します。

まず、VPC AのTransit Gateway Attachmentです。

特別な設定はなく、作成したVPC AのTransit Gateway Attachment用のサブネットを指定して作成します。

VPC AのTransit Gateway Attachmentの作成

VPC AのTransit Gateway Attachment

なお、Transit Gatewayで、Default association route tableDefault propagation route tableは有効にしています。そのため、Transit Gateway Attachmentを作成すると、自動でデフォルトのTransit Gateway Route Tableとのアソシエーション及び、アソシエーションしたTransit Gateway Attachmentへのルートが追加されます。

  • デフォルトのTransit Gateway Route TableのAssociations デフォルトのTransit Gateway Route TableのAssociations
  • デフォルトのTransit Gateway Route TableのPropagations デフォルトのTransit Gateway Route TableのPropagations
  • デフォルトのTransit Gateway Route TableのRoutes デフォルトのTransit Gateway Route TableのRoutes

VPC BのTransit Gateway AttachmentもVPC Aと同様に作成します。

VPC BのTransit Gateway Attachment

VPC BのTransit Gateway Attachment作成後、デフォルトのTransit Gateway Route Tableを確認すると、VPC Aと同様にアソシエーション及び、ルートの追加がされていることが分かります。

  • デフォルトのTransit Gateway Route TableのAssociations VPC B追加後のデフォルトのTransit Gateway Route TableのAssociations
  • デフォルトのTransit Gateway Route TableのPropagations VPC B追加後のデフォルトのTransit Gateway Route TableのPropagations
  • デフォルトのTransit Gateway Route TableのRoutes VPC B追加後のデフォルトのTransit Gateway Route TableのRoutes

VPCのルートテーブルの設定

最後にVPCのルートテーブルを設定して、お互いのVPCと通信をする際にTransit Gatewayを経由するように設定します。

まず、VPC AのPrivateサブネットのルートテーブルです。

VPC AのPrivateサブネットのルートテーブルを選択して、ルートタブのルートを編集をクリックします。

VPC AのPrivateサブネットのルートテーブル編集

送信先がVPC BのCIDRである10.0.1.0/24である場合、Transit Gatewayを経由するようなルートを追加して、変更を保存をクリックします。

VPC AのPrivateサブネットのルートテーブルにVPC Bへのルートを追加

編集後のルートは以下のようになります。

VPC AのPrivateサブネットのルートテーブル_VPC Bへのルートを追加後

VPC BのPrivateサブネットのルートテーブルもVPC Aと同様に設定します。

VPC BのPrivateサブネットのルートテーブル_VPC Aへのルートを追加後

これで下準備は完了です。

VPC AのEC2インスタンスからVPC BのEC2インスタンスへのping

それでは、VPC AのEC2インスタンスからVPC BのEC2インスタンスへpingが通るか確認してみます。

pingの実行結果は以下の通りで、正常に疎通できることが確認できました。

$ ping -c 5 10.0.1.123
PING 10.0.1.123 (10.0.1.123) 56(84) bytes of data.
64 bytes from 10.0.1.123: icmp_seq=1 ttl=254 time=1.03 ms
64 bytes from 10.0.1.123: icmp_seq=2 ttl=254 time=0.660 ms
64 bytes from 10.0.1.123: icmp_seq=3 ttl=254 time=0.614 ms
64 bytes from 10.0.1.123: icmp_seq=4 ttl=254 time=0.608 ms
64 bytes from 10.0.1.123: icmp_seq=5 ttl=254 time=0.632 ms

--- 10.0.1.123 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4078ms
rtt min/avg/max/mdev = 0.608/0.709/1.034/0.165 ms

Transit Gateway Route Tableの各セカンダリCIDRのルートを削除した状態で通信ができるか

Transit GatewayのPropagationの無効化

pingも通ったしこれでめでたしめでたし」という感じですが、Transit Gateway Route TableのセカンダリCIDRのルートが無性に気になります。

デフォルトのTransit Gateway Route TableのRoutes

このルートを削除した状態で通信ができるかをおまけで検証したいと思います。

まず、こちらのルートはPropagationにより自動で追加されたルートなので、Propagationを無効化します。

Propagationを無効化するために、対象のTransit Gatewayを選択して、アクション - Modifyをクリックします。

Transit GatewayのModify

Default propagation route tableのチェックボックスを外して、Modify transit gatewayをクリックします。

Default propagation route tableの無効化

設定後、Transit Gatewayを確認するとDefault propagation route tabledisableになっていることが確認できます。

Default propagation route table無効後のTransit Gateway

デフォルトのTransit Gateway Route TableのPropagationの削除

Default propagation route tableを無効化してもPropagation済みのルートは削除されないので、Transit Gateway Route TableのPropagationを削除します。

デフォルトのTransit Gateway Route TableのPropagationタブからPropagationを削除したいTransit Gateway Attachment(まずはVPC AのTransit Gateway Attachment)を選択して、Delete propagationをクリックします。

デフォルトのTransit Gateway Route TableのPropagationの削除

確認のウィンドウが表示されるので、Delete propagationをクリックします。

Transit Gateway Route TableのPropagationの削除の確認

VPC AのTransit Gateway AttachmentのPropagationの削除後、デフォルトのTransit Gateway Route TableのRoutesを確認すると、VPC Aへのルートが削除されていることが確認できます。

VPC AのTransit Gateway AttachmentのPropagationの削除後のルート

VPC BのTransit Gateway AttachmentのPropagationも同様に削除します。削除後にデフォルトのTransit Gateway Route TableのRoutesを確認すると、VPC Bへのルートが削除されていることが確認できます。

VPC BのTransit Gateway AttachmentのPropagationの削除後のルート

デフォルトのTransit Gateway Route Tableへのルートの追加

全てのルートを削除してしまったので、VPC AとVPC BへのルートをデフォルトのTransit Gateway Route Tableに追加してあげます。

デフォルトのTransit Gateway Route TableのRoutesタブからCreate static routeをクリックします。

VPC AのCIDR(10.0.0.0/24)への通信が発生したときはVPC AのTransit Gateway Attachmentにルーティングするように設定します。

VPC AのTransit Gateway Attachmentへのルーティング

すると、RoutesにVPC AのTransit Gateway Attachmentにルーティングが追加されます。

VPC AのTransit Gateway Attachmentへのルーティング

VPC BのTransit Gateway AttachmenへのルーティングもVPC AのTransit Gateway Attachmentと同様に設定します。

VPC BのTransit Gateway Attachmentへのルーティング

VPC AのEC2インスタンスからVPC BのEC2インスタンスへのping

これでTransit Gateway Route TableのセカンダリCIDRへのルートを削除できたので、この状態でVPC AのEC2インスタンスからVPC BのEC2インスタンスへのpingを叩いてみます。

pingの実行結果は以下の通りで、正常に疎通できることが確認できました。Transit Gateway Attachmentが存在するセカンダリCIDRへのルートは不要ということですね。

$ ping -c 5 10.0.1.123
PING 10.0.1.123 (10.0.1.123) 56(84) bytes of data.
64 bytes from 10.0.1.123: icmp_seq=1 ttl=254 time=1.14 ms
64 bytes from 10.0.1.123: icmp_seq=2 ttl=254 time=0.598 ms
64 bytes from 10.0.1.123: icmp_seq=3 ttl=254 time=0.592 ms
64 bytes from 10.0.1.123: icmp_seq=4 ttl=254 time=0.585 ms
64 bytes from 10.0.1.123: icmp_seq=5 ttl=254 time=0.613 ms

--- 10.0.1.123 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4077ms
rtt min/avg/max/mdev = 0.585/0.705/1.141/0.220 ms

最終的なルートテーブル

最終的なルートテーブルは以下の通りです。

検証環境構成_ルーティング情報

VPCにセカンダリCIDRを追加した場合のルーティングを完全に理解した

これでVPCにセカンダリCIDRを追加した場合のルーティングを完全に理解しました。

「後からTransit GatewayやNetwork Firewallなど専用のサブネットを追加したい。でもCIDRの空きがない。」という場面に遭遇しても、このブログを読めば平常心を保つことができます。

以上、東京オフィスの のんピ(@non____97)でした!