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

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/16や10.2.0.0/16など、10.0.0.0/16範囲外のCIDRを指定する必要があります。

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

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

セカンダリCIDRの追加

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

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

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

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

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

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

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

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

これで、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を指定します。

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

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

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用のサブネットを指定して作成します。

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

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

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

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

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

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

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

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

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

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

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

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のルートが無性に気になります。

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

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

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

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

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

デフォルトの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をクリックします。

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

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

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

デフォルトの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にルーティングするように設定します。

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

VPC BのTransit Gateway AttachmenへのルーティングもVPC Aの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の空きがない。」という場面に遭遇しても、この記事を読めば平常心を保つことができます。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!