こんにちは。AWS CLIが好きな福島です。
はじめに
昨今、AWSを利用するにあたり、複数のAWSアカウントを利用したマルチアカウント構成が主流になってきているかと存じます。
私もAWS歴は浅いですが、シングルアカウント構成の場合は、VPCの数はそれほど多くなく、1つのVPCに比較的大きなCIDRの割り当てやセカンダリCIDRの追加を行い、その中でサブネットを様々な用途ごとに分けることが多かったのかなと思っております。
しかし、マルチアカウント構成では、システムや環境ごとにアカウントを作成するケースが増え、 VPCの数もアカウントの数に比例して増加する傾向にあり、今後ネットワークアーキテクチャがより重要になるなと感じました。
そこで、マルチアカウント構成におけるネットワークアーキテクチャ関連のブログを書こうと思い、今回は第1弾として、マルチアカウント環境で増加するVPCのCIDR設計について、私の考えをブログにまとめてみたいと思います。
AWSで利用するCIDRについて
AWSで利用するCIDR範囲を決める
まず、VPCのCIDR設計を行う前にAWSで利用するCIDR範囲を決めることが重要でCIDRを決める上では以下がポイントかと存じます。
- 1.オンプレミスなどAWSと連携予定のネットワークのCIDRと重複しないCIDRを割り当てる
- 2.比較的大きなCIDRを確保する
- 3.AWS以外で利用するCIDRとAWSで利用するCIDRを適切に区切る
1,2については、記載の通りですが、3については、以下で詳細を説明いたします。
CIDRを適切に区切るとは
例えば、クラスB(172.16.0.0 - 172.31.255.255)の中からオンプレミスとAWSで利用するIPアドレスを考えた場合、以下の割り振りが考えられます。
パターンA
オンプレミス : 172.21.0.0 - 172.24.255.255
AWS : 172.25.0.0 - 172.28.255.255パターンB
オンプレミス : 172.20.0.0 - 172.23.255.255
AWS : 172.24.0.0 - 172.27.255.255
どちらのパターンも同じIPアドレスの数を割り当てられていますが、 CIDR表記に直すと以下の通りとなり、パターンAの方が数が多くなることが分かるかと存じます。
パターンA
オンプレミス: 172.21.0.0/16,172.22.0.0/15,172.24.0.0/16
AWS : 172.25.0.0/16,172.26.0.0/15,172.28.0.0/16パターンB
オンプレミス: 172.20.0.0/14
AWS : 172.24.0.0/14
このCIDR表記で表現する数が多くなると、ネットワーク周りの設定が増えてしまうため、CIDR表記で表現する数が少ないほうが設定が簡素化でき、メリットがあると考えております。 これが、AWSで利用するCIDRとオンプレミスで利用するCIDRを区切りよく分けるという意味になります。
ネットワーク周りの設定とは、例えばルーティングの設定になります。以下はイメージ図になりますが、パターンBの構成のほうがルーティングの設定が少なくなります。
◆イメージ図
また他には、Security GroupやNetwork ACLの設定などの簡素化にも繋がるかと存じます。
ただ、既にオンプレミスでバラバラにCIDRを利用しており、上記のように区切り良くCIDRを分けられないケースもあると思いますが、 ある程度区切りを意識することが重要と考えております。
AWSで利用するCIDRの更なる分割
AWSで利用するCIDRが決まったら、必要に応じて更にリージョンごとや環境ごとに割り当てるCIDRを決めておくと良いかと存じます。
リージョンごとに割り当てる
DRの切替方法にもよりますが、仮にDRごとに別々のCIDRを利用し、オンプレミスとAWSを接続する際に、DX + DXGW + TGWを利用する構成を想定します。 ここまでするかはおいておいて、オンプレミスから東京リージョンと大阪リージョンのVPCに接続する場合、以下の構成が考えられます。
そうなった場合、適切にCIDRを区切っておくことでルーティング(許可されたプレフィックス)の設定を簡素化することができます。 ただ、大阪リージョンで作成するVPCの数が少なければここまで考慮する必要はないかもしれません。
許可されたプレフィックスの設定は、20までという制限もあるため、ここも意識しておく良いかと存じます。
環境ごとに割り当てる
環境ごとにCIDRを割り当てるについてですが、異なる環境同士でルーティングすることもあるかと存じますため、 ルーティングの設計を簡素化するという観点ではなく、単純に管理のしやすさという点でCIDRを分けると良いかと存じます。
- イメージ
172.24.0.0/16 : 本番環境
172.25.0.0/16 : 検証環境
172.26.0.0/16 : 開発環境
など
上記の場合、IPアドレスから第2オクテットが24は本番なんだな、25が検証なんだなと分かりやすいかと存じます。
VPCのCIDRについて
VPCのCIDRについては、AWSで利用するCIDRから割り当てるCIDRを決定します。
マルチアカウント環境においては、VPCの数が多くなる傾向があるため、サブネットマスクを統一するであったり、/24といった分かりやすいサブネットマスクでCIDRを払い出すのがポイントかと存じます。
もちろん、決めたサブネットマスク以上にIPアドレスが必要な場合、例外として必要なIPアドレス分のサブネットマスクを割り当てることになるかと存じます。
その逆に決めたサブネットマスク以上に少ない場合でもいいケースもあるかと存じますが、IPが枯渇しているなどの理由がない限りは、管理のしやすさを選び、決めたサブネットマスクでCIDRを払い出すのが良いと思います。
また、もし設計時に問題がなかったが、決めたサブネットマスクでIPが枯渇した場合は、 VPCの場合セカンダリCIDRを追加することが可能なため、それを利用することで拡張が可能です。
なお、マルチアカウント構成の場合は、アカウントごとにVPCを作ることが多いかと存じますため、/16など大きなCIDRの割り当てる必要が少ないのもポイントかと存じます。 あるいは、/16など大きなCIDRを割り当てたVPCを作成し、そこから個々のアカウントにRAMによりVPCを共有する設計も有りかもしれません。
サブネット設計について
VPCのサブネットについて、考えてみたいと思います。特に決まりはないと思いますが、主に以下のサブネットはよく作られるのかなと思います。
- ①パブリックサブネット
インターネットと双方向に通信できるサブネット - ②プロテクテッドサブネット
AWSからインターネットへの片方向の通信ができるサブネット - ③プライベートサブネット
インターネットと双方向に通信できないサブネット - ④トランジットゲートウェイサブネット
トランジットゲートウェイアタッチメント用のサブネット
上記以外には、ELB用のサブネットなど、よく使うサービス用のサブネットを用意するのもありだと思います。
また、それぞれに割り当てるCIDRのサブネットマスクについて、④は、/28で十分であることがAWSのドキュメントに明記されています。
それ以外は必要に応じて割り当てることになりますが、VPCが/24である場合のサブネット設計例は以下があるかと存じます。
- 各サブネットはマルチAZ構成
- トランジットゲートウェイサブネットは「/28」
- それ以外は「/27」
- 残りのCIDR(/27)は、空きCIDRとして確保
ここでも、環境の統一を意識することは大事かと存じます。 Transit Gatewayを利用しなければ、トランジットゲートウェイサブネットは不要かもしれませんが、 シングルAZでいいシステムでも、環境の統一を考え、不要でもマルチAZに作るなどあってもいいのかもしれません。
終わりに
今回は、マルチアカウント環境におけるVPCのCIDR設計について、私なりの考えをまとめてみました。
どなたかのお役に立てれば幸いです。
