はじめに

NTTソフトウェアの青木です。

AWSブログでは、メンバーがAWSのいろいろなテーマでお話していきます。
今回は第三弾として、私の好きなVPC(Amazon Virtual Private Cloud)をテーマにお話します。

VPCに柔軟性をもたせたい！

VPCは、ネットワークカテゴリに位置し、お手軽にプライベートネットワーク空間を構築できますが、一度リソース(仮想NIC)を使用し始めてしまうと、CIDR blockを変更できず、簡単には拡大縮小することができません。

また、運用を続けていくと、様々な通信要件の変化が発生します。
そのような環境の変化に対し、柔軟性を持ったVPCを設計することが重要です。
クラウドのメリットを損なうことなくスピード感を持って対処できる環境を目指します。

VPC設計時に考慮すべき2つのこと

私は、VPC設計時に下記2点を特に意識しています。

1. オンプレミス環境も含め、全てのVPCでプライベートIPアドレスの重複なくCIDR blockを定義すること。
2. VPCはできるだけ大きく作り、サブネットに割り当てていないCIDR blockを確保しておくこと。

1. オンプレミス環境も含め、全てのVPCでプライベートIPアドレスの重複なくCIDR blockを定義すること。

これは、VPCサブネットのルーティングに関する以下のような 急な通信要件の変更 を考慮しています。

• 1-a. 当初は予定になかったが、オンプレミス環境ともプライベート通信する必要が出てきた場合。
• 1-b. 本番環境と検証環境とのプライベート通信のreachabilityが不要なのでVPCを分けた。しかし通信要件が変わり、例外的にプライベート通信が必要になった場合。

例えば、図のようにVPC2を増設したとします。

DC1のカスタマーゲートウェイに着目すると、以下の状況となり、VPC2とDC1とのプライベート通信を確立することができません。

1. VPC1とDC1をVPN接続していた(vti1)。
2. AWS利用規模拡大により、VPC2をVPC1と連続したCIDR blockの 10.1.0.0/16 で増設した。
3. VPC2もVPC1と同様にDC1とVPN接続しようとした(vti3)。
4. しかし、実は 10.1.0.0/16 はDC2で既に接続しており(vti2)、DC1からのルーティングができなくなってしまった。

そのような状況にならないためにも、オンプレミス側も含めたNW管理者とのコミュニケーションが重要になります。

なお、VPCを起点に考える場合は、RouteTableの設計に注意が必要です。

1. VPCサブネットは、RouteTableで定義したRoute情報を元にルーティングされます。
2. Targetは、longest matchの規則により決まります。
3. そのため、CIDR blockが重複したサブネットへの経路を追加しようとするとDestinationが重複し、設定することができません。

2. VPCはできるだけ大きく作り、サブネットに割り当てていないCIDR blockを確保しておくこと。

これは、VPCサブネットのCIDR block、トラフィックの分散、サブネット構成の変更に関する以下のような 運用課題 を考慮しています。

• 2-a. サブネットで利用可能なプライベートIPアドレスが残り少なくなってしまった場合。
• 2-b. 利用可能なIPアドレスは残っているが、これ以上インスタンスを増やすとGWのボトルネックが予想できる場合。
• 2-c. 当初は、パブリックサブネットとプライベートサブネットのみで良かったが、第3のサブネット(internalなDMZなど)が必要になった場合。

VPCサブネットは、VPCのCIDR block内に構築していきます。
冒頭でも記載しましたが、一度作成するとサブネットのCIDR blockを変更する際には一旦削除して再構築する必要があります。
しかしその際、EC2が稼動し始め、仮想NIC(ENI)を利用し始めてしまうと、容易に削除することはできません。

そのため、サブネットの拡張が必要になったときに サブネットの追加作成で対処できる ように
敢えて、VPC内全てを使い切らず、サブネットに割り当てていないCIDR blockを残しておきます。

図にすると以下のようなイメージです。例としてVPCは10.0.0.0/18とします。

図のようなサブネット配置とすることで、次のようなアクションにより運用課題に対して柔軟に対応できます。

サブネットを追加作成して...

• 同じRouteTableを関連付ける。
  →　同じ用途(＝経路、FW)のサブネットのIP枯渇に対する拡張対応ができる。

• 異なるRouteTableを関連付ける。例えば、プライベートサブネットで、0.0.0.0/0への経路のみ異なるものなど。
  →　GWの負荷をコントロールすることができる。0.0.0.0/0であればNATインスタンスのNW負荷など。

• 異なるルールのNetwork ACLを関連付ける。例えば、プライベート網の内、一部のCIDR blockとの通信を拒否するルール。
  →　第3の用途のサブネットを追加できる。拒否したプライベートCIDR blockからはアクセスできないinternalなDMZの追加など。

また、図のような配置とした利点は他にもあり

• 用途毎にAZを2種類以上用意している。
  →　AZ障害に対応できる。

• 用途毎に連続配置にしている。
  →　VPCのRouteTable、Network ACLにはそれぞれ、エントリー数の最大値があり、CIDRを合算することでそのエントリー数を減らせます。
  例えば、図中の用途Aは10.0.0.0/21にまとめて1エントリーにできます。

しかしながら、VPCのよくある質問にもありますようにサブネットの中に、一部Amazon側に確保されてしまうIPがあり、サブネットを作れば作るほど、その数は増えますので、VPCに割り当て可能なCIDR blockと、サブネットの切り出しについてバランスを取ることが重要です。
※なお、サブネットの最小サイズの/28で作ると、利用可能なIPアドレスの数は11個になります。

(該当箇所引用)
Q: サブネットに割り当てる IP アドレスをすべて使用できますか?

いいえ。各サブネットにおいて、Amazon が先頭の4 IP アドレスを確保し、最後の1 IP アドレスは、IP ネットワーキングの目的で確保されます。

おわりに

今回は、様々な通信要件の変更に対応できるよう、柔軟性を持ったVPCの設計について、まとめてみました。
VPCやサブネットを作るときにこうした設計をしておくと、運用を始めたあとで「あっ...！」と困ることが激減します。ぜひあなたのAWSライフの一助にしてください。

次回は、運用効率を意識したVPC関連のマネージド・サービスについてまとめようと思います。