AWSネットワーク設計で失敗しないポイント

AWSでアプリケーションを構築する際、つい後回しにされがちなのがネットワークの基本設計です。しかし、VPCにおけるIPアドレスの採番や通信制御の設定は、一度構築した後に変更しようとすると、システム停止や大規模なリベンジ作業を伴う「取り返しのつかない」要素を多く含んでいます。

 本記事では、将来的な拡張性やオンプレミス接続を見据えた「失敗しないIP採番設計」のポイントから、実務で混同しやすいセキュリティグループとNetwork ACLの使い分けまで、AWSネットワーク設計の勘所を解説します。

「最初の設計こそが最大のセキュリティ対策であり、安定運用の鍵」となります。将来の技術的負債を未然に防ぎ、堅牢なインフラ基盤を構築するためのガイドとしてお役立てください。

VPCで失敗しないIP採番設計

AWSでアプリケーションを構築する際、多くの担当者が「サーバーを立てる」「アプリを動かす」ことを優先しがちですが、最初に最も慎重に考えるべきなのがネットワーク設計です。

特にVPCのIPアドレス設計（IP採番）は、後からの変更が非常に難しく、初期設計の良し悪しが将来の運用負荷や拡張性に大きく影響します。オンプレミス環境と同様、AWSでもネットワークの変更は一大事です。一度設定したVPCのプライマリCIDR（アドレス範囲）を後から変更・縮小することはできず、実質的には「新しいVPCを作成してリソースを移行する」という、システム停止や大規模な移行作業が発生します。そのため、「とりあえず適当に決める」という判断は、後々大きな技術的負債になりかねません。

AWS VPCでは、RFC1918で定義されたプライベートIPアドレス帯（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）からCIDRを指定します。

このCIDRがVPC全体のアドレス空間となり、その中からサブネットを切り出して利用します。つまり、VPCのCIDR設計は「将来を見据えた敷地の広さ」を決める作業だと考えると分かりやすいでしょう。

VPCのCIDR設計における注意点

将来の接続を前提に考える重要性

VPCのCIDR設計でまず意識すべきなのが、他ネットワークとの接続可能性です。オンプレミス環境とのVPN接続、AWS Direct Connect、別VPCとのVPCピアリングなどでは、IPアドレスの重複（オーバーラップ）が許されません。

例えば、オンプレミスで「10.0.0.0/16」をすでに使用しているにもかかわらず、AWSのVPCでも同じ範囲を割り当ててしまうと、接続時にルーティングが成立せず深刻な問題が発生します。その結果、「VPCを最初から作り直すしかない」という事態に陥るケースも少なくありません。事前にオンプレミス接続や他システム連携の可能性を洗い出し、社内のIPアドレス利用状況を整理したうえで、重複しないCIDRを決めることが極めて重要です。

適切なインフラ設計をお約束するスタイルズのAWS導入・移行サービスはこちら→

VPC・サブネットに関するAWSの制限

AWSにはCIDR設計に関する明確なルールが存在します。

VPCのCIDRは /16〜/28 の範囲で指定でき、サブネットは /16〜/28 の範囲で作成可能です。ただし、サブネット内ではAWSが予約するIPアドレスが5つ存在します。

そのため、計算上のIP数から「マイナス5」した数が、実際に利用可能なIP数となる点に注意が必要です。

ELB用サブネットのCIDR設計

特に見落とされがちなのが、ELB（ALB/NLB）を配置するサブネットのCIDRサイズです。

AWSでは、ELBを配置するサブネットは /27以上（32IP） が推奨されており、かつ最低でも8個以上の空きIPアドレスが必要です。これは、ELBがトラフィックの増減に応じて内部的にノード（IPアドレス）を動的に増減させるためです。

サブネットが小さすぎると、ELB作成時にエラーが発生したり、急激な負荷増加時のスケールアウトに失敗したりするリスクがあります。「今は小規模だから」と、最小サイズの /28 でギリギリの設計をしてしまうと、将来的にELBを追加・拡張できない事態になりかねません。サブネット設計では、将来の構成変更を見据え、余裕を持ったCIDRを割り当てることがベストプラクティスです。

セキュリティグループとNACLの違い

Network ACLとセキュリティグループの基本

AWSにおける通信制御には、「セキュリティグループ」と「Network ACL（NACL）」の2つが提供されています。どちらもネットワーク通信を制御する仕組みですが、その役割や特性は大きく異なります。セキュリティグループはインスタンス単位で適用される仮想ファイアウォールとして機能し、一方でNACLはサブネット単位で適用されるネットワーク制御を担います。

技術的な違いの比較

両者の最大の違いは、「ステートフル」か「ステートレス」かという点です。「ステートフル（Stateful）」は状態を保持するという意味で、過去のやり取り（セッション情報など）を記憶し、それを元に次の処理を行います。一方、「ステートレス（Stateless）」は状態を保持しません。リクエストごとに独立して処理を行うため、過去の情報をサーバー側で保持しないのが特徴です。

セキュリティグループはステートフルであり、インバウンド通信を許可すれば、その戻りとなるアウトバウンド通信は自動的に許可されます。対照的に、NACLはステートレスであるため、インバウンドとアウトバウンドの両方を個別に明示して許可する必要があります。

また、セキュリティグループは「許可ルールのみ」を設定しますが、NACLは「許可」と「拒否」の両方を設定でき、ルール番号の昇順（数字の小さい順）に評価されます。

なぜセキュリティグループが実務で多用されるのか

実務においてセキュリティグループが多用される理由は、設定がシンプルで運用ミスが起きにくいからです。ステートフルな特性により、戻り通信の複雑なポート開放を意識する必要がなく、インスタンス単位で柔軟に制御できます。複数の担当者が運用する環境では、設定の分かりやすさや保守性は非常に重要です。その点で、セキュリティグループは「まず基本として押さえるべき機能」としての使いやすさがあります。

適切なインフラ設計をお約束するスタイルズのAWS導入・移行サービスはこちら→

効果的な使い分けのシナリオ

セキュリティグループはインスタンス単位できめ細やかなアクセス制御を実装できる一方で、NACLはサブネット単位で広範囲に適用される設定となります。したがって、基本方針としては通常の通信制御をセキュリティグループで行い、NACLは補助的に使うのが一般的です。 個別システムの通信制御はセキュリティグループで実施し、全体として明らかに不要な通信や、DDoS攻撃などで特定のIPアドレスから大量の攻撃がある場合などに、NACLを使ってサブネットの入り口で遮断するといった使い分けが適しています。NACLは「最後の防波堤」、セキュリティグループは「日常的な門番」と考えると、その役割の違いを理解しやすくなります。

まとめ

VPC設計におけるIP採番やCIDR設計、および通信制御は、後からの修正が極めて困難なシステムの基盤部分です。特にIPアドレス設計は、オンプレミス環境との接続や将来的なネットワークの拡張を見据えて、慎重に行う必要があります。また、ELBの配置条件やAWS特有の制約を考慮せずに進めてしまうと、後から「リソースを作成できない」「スケールできない」といった深刻な問題に直面し、多大な工数や手戻りが発生する恐れがあります。

セキュリティグループとNACLについても、それぞれの特性を正しく理解し、目的に応じて適切に使い分けることが肝要です。AWSのネットワーク設計は一見すると複雑ですが、今回挙げたような「最初に押さえるべきポイント」を確実に理解しておくことで、将来のトラブルを未然に防ぐことができます。

「最初の設計こそが、最大のセキュリティ対策と安定運用に直結する」という意識を持ち、VPC設計に取り組むことが成功への近道です。もし、具体的な設計内容に不明な点や不安がある場合は、専門知識を持つベンダーなどのパートナーに相談することも、確実なシステム構築に向けた有効な選択肢となるでしょう。