AWS VPCサブネット設計入門｜CIDR基礎

AWS VPCサブネット設計入門｜CIDR基礎から実践まで完全ガイド

AWS VPCのサブネット設計で最も重要なことは、将来の拡張性とセキュリティ要件を考慮したCIDRブロックの割り当てです。後からサブネットを追加する際にIPアドレス不足に悩まされないために、最初に十分なIPアドレス空間を確保しておくことが成功の鍵となります。

本記事では、AWS VPCにおけるサブネット設計の基礎から応用まで、CIDR計算の方法、セキュリティグループとネットワークACLの使い分け、そして実際の運用に役立つベストプラクティスまで、具体的な手順と実例を交えて詳しく解説します。AWS認定ソリューションアーキテクトやAWS認定SysOpsアドミニストレーターを目指す方はもちろん、すでにAWSを運用しているエンジニアにとっても、サブネット設計を見直すきっかけとなる内容です。

目次

• AWS VPCとサブネットの基礎知識
• CIDR（Classless Inter-Domain Routing）の基礎
  • CIDR計算の具体的な方法
  • CIDR設計のベストプラクティス
• AWS VPCにおけるサブネットの種類と用途
  • パブリックサブネットの設計
  • プライベートサブネットの設計
  • 隔離サブネット（DBサブネット）の設計
• ネットワークセキュリティの設計
  • セキュリティグループの設定
  • ネットワークACLの設定
  • ルートテーブルの設計
• マルチAZアーキテクチャの設計
• IPアドレス管理の最適化
• サブネット設計に関するトラブルシューティング
• AWS VPCサブネット設計に関するFAQ
• まとめ：AWS VPCサブネット設計のベストプラクティス

AWS VPCとサブネットの基礎知識

AWS Virtual Private Cloud（VPC）は、AWSクラウド内に仮想的なネットワークを構築するためのサービスです。VPCを使用することで、AWSリソースを論理的に分離し、セキュリティと制御を強化できます。

サブネットはVPC内でIPアドレス範囲を分割した小さなネットワークです。AWSでは、サブネットを以下の2つの主要なタイプに分類します。

AWS VPCを設計する際には、まずVPCのCIDRブロックを決定します。VPCのCIDRブロックは、/16から/28までの範囲で指定できますが、一般的には/16（65,536 IPアドレス）から始めるのが推奨されます。これは、将来の拡張性を考慮した設計です。

VPCを作成する際の主なパラメータは以下の通りです。

VPCを作成する際は、AWSマネジメントコンソール、AWS CLI、またはAWS CloudFormationを使用できます。以下はAWS CLIを使用したVPC作成の例です。

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=MyVPC}]'

VPCを作成した後、サブネットを設計する際には、以下のポイントを考慮します。

• IPアドレスの効率的な利用：サブネットのサイズは、将来のリソース拡張を考慮して決定します。
• セキュリティ要件：機密性の高いリソースはプライベートサブネットに配置します。
• 可用性：重要なリソースは複数のアベイラビリティーゾーン（AZ）に分散させます。
• ネットワークトラフィックの分離：異なる用途のリソースは別のサブネットに配置します。

CIDR（Classless Inter-Domain Routing）の基礎

CIDRは、IPアドレスの割り当てとルーティングを効率的に行うための仕組みです。CIDR表記では、IPアドレスの後にスラッシュ（/）とプレフィックス長（ネットワーク部のビット数）を付けて表します。例えば、10.0.0.0/16は、10.0.0.0から10.0.255.255までのIPアドレス範囲を表します。

CIDR計算の具体的な方法

CIDR計算を行う際には、以下の手順を踏みます。

1. IPアドレス範囲の決定：VPC全体のCIDRブロックを決定します。例えば、10.0.0.0/16を使用します。
2. サブネットのサイズの決定：各サブネットに必要なIPアドレス数を考慮して、サブネットのCIDRブロックを決定します。例えば、/24（256 IPアドレス）や/28（16 IPアドレス）などです。
3. サブネットの分割：VPCのCIDRブロックを、必要な数のサブネットに分割します。例えば、10.0.1.0/24、10.0.2.0/24などです。

以下の表は、CIDRブロックのサイズと利用可能なIPアドレス数の関係を示しています。

CIDR計算を行う際には、以下のツールを活用すると便利です。

• IP Subnet Calculator
• Subnet Calculator
• AWS提供のVPC CIDR計算ツール

CIDR設計のベストプラクティス

AWS VPCのCIDR設計において、以下のベストプラクティスを参考にしてください。

1. 将来の拡張性を考慮する：VPCのCIDRブロックは、将来のリソース拡張を考慮して十分なサイズを確保します。例えば、/16を使用することで、最大65,536個のIPアドレスを利用できます。
2. サブネットのサイズを適切に選択する：各サブネットのサイズは、配置するリソースの要件に応じて決定します。例えば、/24は一般的なアプリケーションサーバーに適しています。
3. IPアドレスの重複を避ける：VPC間でIPアドレスが重複しないように、CIDRブロックを設計します。特に、オンプレミスネットワークとの接続を考慮する場合は注意が必要です。
4. サブネットの分離：異なる用途のリソースは、別のサブネットに配置します。例えば、Webサーバー用のパブリックサブネット、アプリケーションサーバー用のプライベートサブネット、データベースサーバー用の隔離サブネットなどです。
5. マルチAZ設計：重要なリソースは、複数のアベイラビリティーゾーン（AZ）に分散させます。例えば、パブリックサブネットを2つのAZに配置し、プライベートサブネットも2つのAZに配置します。

以下の表は、AWS VPCのCIDR設計における一般的なパターンを示しています。

プライベートサブネット（アプリケーションサーバー）

AWS VPCにおけるサブネットの種類と用途

AWS VPCでは、サブネットの種類によってリソースの配置場所やインターネットへの接続性が異なります。主なサブネットの種類とその用途について解説します。

パブリックサブネットの設計

パブリックサブネットは、インターネットゲートウェイ（IGW）に直接接続されたサブネットです。このサブネットに配置されたリソースは、インターネットから直接アクセスできます。主な用途は以下の通りです。

• Webサーバー
• ロードバランサー
• NATゲートウェイ
• バスタブサーバー

パブリックサブネットを設計する際には、以下のポイントに注意します。

1. セキュリティグループの設定：パブリックサブネットに配置するリソースには、必要最小限のポートのみを開放します。例えば、Webサーバーの場合はHTTP（80番ポート）とHTTPS（443番ポート）のみを開放します。
2. ネットワークACLの設定：ネットワークACLを使用して、不要なトラフィックをブロックします。例えば、SSH（22番ポート）やRDP（3389番ポート）からのアクセスを制限します。
3. ルートテーブルの設定：パブリックサブネットのルートテーブルには、インターネットゲートウェイ（IGW）へのルートを設定します。
4. マルチAZ設計：パブリックサブネットは、複数のアベイラビリティーゾーン（AZ）に配置します。例えば、us-east-1aとus-east-1bにそれぞれパブリックサブネットを配置します。

以下の表は、パブリックサブネットのルートテーブルの例です。

プライベートサブネットの設計

プライベートサブネットは、インターネットゲートウェイ（IGW）に直接接続されていないサブネットです。このサブネットに配置されたリソースは、インターネットから直接アクセスできません。主な用途は以下の通りです。

• アプリケーションサーバー
• バックエンドサービス
• 内部APIサービス

プライベートサブネットを設計する際には、以下のポイントに注意します。

1. NATゲートウェイの配置：プライベートサブネットからインターネットへのアウトバウンド通信を可能にするために、NATゲートウェイをパブリックサブネットに配置します。
2. セキュリティグループの設定：プライベートサブネットに配置するリソースには、必要最小限のポートのみを開放します。例えば、アプリケーションサーバーの場合は、データベースサーバーからの接続のみを開放します。
3. ネットワークACLの設定：ネットワークACLを使用して、不要なトラフィックをブロックします。例えば、外部からの不正なアクセスを制限します。
4. ルートテーブルの設定：プライベートサブネットのルートテーブルには、NATゲートウェイへのルートを設定します。
5. マルチAZ設計：プライベートサブネットは、複数のアベイラビリティーゾーン（AZ）に配置します。例えば、us-east-1aとus-east-1bにそれぞれプライベートサブネットを配置します。

以下の表は、プライベートサブネットのルートテーブルの例です。

隔離サブネット（DBサブネット）の設計

隔離サブネットは、インターネットゲートウェイ（IGW）にもNATゲートウェイにも接続されていないサブネットです。このサブネットに配置されたリソースは、インターネットから完全に隔離されています。主な用途は以下の通りです。

• データベースサーバー（RDS、Aurora、DynamoDB Accelerator）
• 内部ストレージサービス
• 機密性の高いバッチ処理

隔離サブネットを設計する際には、以下のポイントに注意します。

1. セキュリティグループの設定：隔離サブネットに配置するリソースには、必要最小限のポートのみを開放します。例えば、データベースサーバーの場合は、アプリケーションサーバーからの接続のみを開放します。

ネットワークセキュリティの設計

AWS VPCにおけるネットワークセキュリティの設計は、サブネットレベルとリソースレベルの両面から検討する必要があります。まず、サブネットの種類に応じてセキュリティ要件を分類し、パブリックサブネットとプライベートサブネットで異なるアプローチを採用します。パブリックサブネットではインターネットからのアクセスを許可する一方で、プライベートサブネットでは外部からの直接アクセスを制限することが一般的です。

セキュリティ設計の要となるのがセキュリティグループとネットワークACL（Access Control List）の適切な設定です。セキュリティグループはステートフルなファイアウォールとして機能し、インスタンスレベルでトラフィックを制御します。一方、ネットワークACLはサブネットレベルでステートレスなルールを適用し、セキュリティグループではカバーしきれないトラフィックフローを管理します。これらを組み合わせることで、多層的なセキュリティ対策が可能となります。

設計時には以下のポイントに留意してください：

• 最小権限の原則に基づき、必要最小限のポート・プロトコルのみを開放する

セキュリティグループの設定

AWS VPCにおけるセキュリティグループは、サブネット内のリソースに対してインバウンドおよびアウトバウンドの通信を制御するファイアウォール機能です。VPC内の各リソース（例：EC2インスタンス）に対して独立したルールを設定でき、柔軟なセキュリティポリシーを実現します。セキュリティグループはステートフルな動作を特徴とし、許可されたリクエストに対する応答トラフィックは自動的に許可されるため、双方向の通信制御が効率的に行えます。

セキュリティグループのルールは、送信元（ソース）と宛先（ターゲット）のIPアドレス、ポート番号、プロトコル（TCP/UDP/ICMP等）を組み合わせて定義します。例えば、Webサーバー用のEC2インスタンスに対して、HTTP（ポート80）およびHTTPS（ポート443）のインバウンドトラフィックを許可するルールを設定することで、インターネットからのアクセスを制御できます。また、データベースサーバーには、特定のサブネットやセキュリティグループからのMySQL（ポート3306）トラフィックのみを許可することで、不要なアクセスを制限できます。

セキュリティグループの設定は、AWS Management Console、AWS CLI、またはAWS SDKを通じて行うことができます。ルールの追加や変更は即座に反映され、リアルタイムでセキュリティポリシーを更新できる点が特徴です。ただし、セキュリティグループはデフォルトで全てのアウトバウンドトラフィックを許可しているため、不要な通信を防ぐためには必要最小限のルールに絞り込むことが重要です。また、セキュリティグループ同士の参照（セキュリティグループIDをソースとして指定）を活用することで、より動的で保守性の高いセキュリティ設計が可能になります。

• セキュリティグループのルールは、リソース単位ではなく、VPC内のリソースグループ全体に適用される点に注意が必要です。例えば、特定のEC2インスタンスにのみ異なるルールを適用したい場合は、別のセキュリティグループを作成し、そのグループをインスタンスに関連付ける必要があります。

ネットワークACLの設定

ネットワークACL（Access Control List）は、サブネットレベルでトラフィックの許可・拒否を制御するファイアウォール機能です。VPC内の各サブネットに対して設定され、ステートレスなルールに基づいてパケットの通過可否を判断します。例えば、特定のIPアドレスからのSSH接続を許可しつつ、他のポートへのアクセスを制限するといった使い方が可能です。ネットワークACLはサブネット単位で適用されるため、セキュリティ要件に応じて柔軟にルールを設定できます。

ネットワークACLのルールは、番号順に評価される点に注意が必要です。低い番号のルールが優先され、一致した時点で処理が終了します。このため、許可ルールと拒否ルールの順序には十分な配慮が求められます。また、デフォルトでは全てのトラフィックを拒否する設定となっているため、明示的に許可ルールを追加する必要があります。例えば、社内ネットワークからのHTTP/HTTPSアクセスのみを許可する場合は、該当する送信元IPアドレスとポート（80/443）を指定したルールを作成します。

AWS Management ConsoleやAWS CLIを使用してネットワークACLを設定できます。CLIの場合、aws ec2 create-network-acl-entryコマンドでルールを追加しますが、その際にはルール番号やプロトコル、送信元/宛先IPアドレス、許可/拒否のアクションを指定します。なお、ネットワークACLはサブネットに関連付けることで機能するため、設定後は必ず関連付けを確認してください。

• ネットワークACLはステートレスなため、戻りのトラフィックを明示的に許可するルールが必要な点に留意してください。

ルートテーブルの設計

VPC内のネットワークトラフィックは、ルートテーブルによって制御されます。ルートテーブルは、サブネット内のリソースが通信する際の経路情報を定義する重要なコンポーネントです。各サブネットは少なくとも1つのルートテーブルに関連付けられており、デフォルトではメインルートテーブルが使用されます。しかし、セキュリティやパフォーマンスの最適化のために、カスタムルートテーブルを作成し、サブネットに明示的に関連付けることが推奨されます。

ルートテーブルの設計では、まずトラフィックの流れを整理することが大切です。例えば、パブリックサブネットとプライベートサブネットで異なるルートテーブルを使用することで、不要な通信を制限できます。パブリックサブネットのルートテーブルには、インターネットゲートウェイ（IGW）へのルートを設定し、プライベートサブネットにはNATゲートウェイやVPCエンドポイント経由のルートを定義します。このように、用途に応じたルーティングルールを適用することで、セキュリティと効率性を両立させられます。

また、ルートテーブルの管理には、不要なルートが蓄積されないよう注意が必要です。特に、古いセキュリティグループやネットワークACLとの整合性を保ちながら、定期的にルートテーブルをレビューすることをおすすめします。AWS CLIを使用してルートテーブルの一覧を確認する場合は、以下のコマンドが利用できます。

• aws ec2 describe-route-tables：VPC内のすべてのルートテーブルを表示します。

マルチAZアーキテクチャの設計

マルチAZ（アベイラビリティーゾーン）アーキテクチャは、AWS VPCにおける高可用性と耐障害性を実現するための重要な設計パターンです。これは、1つのリージョン内に複数の独立したAZを活用し、システムを分散配置することで、単一障害点を排除します。例えば、Webサーバーやデータベースなどの重要なコンポーネントを異なるAZに配置することで、1つのAZで障害が発生してもサービス全体が停止するリスクを軽減できます。

設計時には、AZ間のネットワーク遅延やコストを考慮する必要があります。AWSでは、同一リージョン内のAZ間通信は低レイテンシーで行われるため、パフォーマンスへの影響は比較的小さくなります。ただし、リージョン間通信と比較すると、AZ間のデータ転送には若干のコストが発生する点に留意が必要です。また、AZ間でリソースを複製する際には、データ整合性や同期の仕組みを適切に設計することが求められます。

具体的な実装方法としては、以下のようなアプローチが一般的です。

• 冗長化されたサブネットを異なるAZに配置し、ロードバランサーでトラフィックを分散する。

IPアドレス管理の最適化

AWS VPCにおけるIPアドレス管理は、ネットワーク設計の効率性と拡張性を左右する重要な要素です。サブネット設計では、将来的なリソース追加やネットワーク変更に柔軟に対応できるよう、適切なIPアドレス空間の割り当てが求められます。特に、CIDR（Classless Inter-Domain Routing）ブロックの選定は、IPアドレスの枯渇リスクを最小化しつつ、無駄のない運用を実現するために不可欠です。

具体的には、サブネットごとに必要なIPアドレス数を見積もり、それに応じたサブネットマスクを設定することが基本となります。例えば、パブリックサブネットとプライベートサブネットで異なるCIDR範囲を使用することで、セキュリティポリシーの適用やルーティングの整理が容易になります。また、マルチAZ（アベイラビリティーゾーン）構成を採用する場合は、各AZに均等なIPアドレス空間を割り当てることで、負荷分散や冗長性の確保が可能です。

IPアドレス管理の最適化には、以下のポイントを考慮することが効果的です。

• 将来のリソース拡張を見据えた余裕のあるCIDRブロックの割り当て

これらの設計原則に基づくことで、ネットワークの運用コスト削減やパフォーマンス向上につながります。AWSの公式ドキュメントでは、VPC設計に関するベストプラクティスが詳しく解説されているため、実装前に確認することを推奨します。

サブネット設計に関するトラブルシューティング

VPCのサブネット設計で発生しやすいトラブルの多くは、CIDRブロックの不適切な割り当てやリソースの配置ミスに起因します。例えば、サブネット間でIPアドレスの重複が発生すると、通信障害やリソースの競合が生じる可能性があります。このような問題を防ぐには、設計段階でCIDRブロックの範囲を事前に計画し、他のVPCやオンプレミスネットワークとの整合性を確保することが重要です。

また、サブネットの種類（パブリック/プライベート）を誤ると、セキュリティリスクや運用コストの増加につながります。例えば、本来プライベートサブネットに配置すべきリソースをパブリックサブネットに配置してしまうと、インターネットからの不要なアクセスを許可することになります。AWSのセキュリティグループやネットワークACLを活用し、サブネットごとの役割に応じた適切なアクセス制御を実施することで、このようなミスを未然に防ぐことができます。

トラブル発生時には、以下の点を確認するとよいでしょう。

• VPCのCIDRブロックとサブネットのCIDRブロックに重複や不整合がないか

これらのトラブルシューティング手順を実施しても問題が解決しない場合は、AWSサポートや公式ドキュメントを参照し、必要に応じて専門家に相談することを検討してください。

AWS VPCサブネット設計に関するFAQ

AWS VPCのサブネット設計に関して、よく寄せられる疑問や実務的なポイントについて、具体的な事例を交えながら解説します。設計時の判断基準や注意点を理解することで、より安全で効率的なネットワーク構築に役立ててください。

Q1. VPCのサブネット設計で最も重要なポイントは何ですか？

VPCのサブネット設計で最も重要なポイントは、CIDRブロックの割り当てと用途に応じた分離です。まず、VPC全体のCIDR範囲を決定し、その中でパブリックサブネット（インターネット向け）とプライベートサブネット（内部向け）を明確に分けます。例えば、VPCのCIDRを10.0.0.0/16とし、パブリックサブネットを10.0.1.0/24、プライベートサブネットを10.0.2.0/24といった具合に、用途ごとに異なるサブネットに分離します。これにより、セキュリティリスクの軽減や、リソースの整理が容易になります。また、将来的な拡張性を考慮し、CIDR範囲に余裕を持たせることも大切です。

Q2. パブリックサブネットとプライベートサブネットの違いは何ですか？

パブリックサブネットとプライベートサブネットの主な違いは、インターネットとの接続性です。パブリックサブネットには、インターネットゲートウェイ（IGW）が接続されており、直接インターネットと通信できます。一方で、プライベートサブネットはIGWに接続されておらず、NATゲートウェイやNATインスタンスを介して間接的にインターネットと通信します。これにより、プライベートサブネット内のリソース（例：データベースやバックエンドサーバー）を外部からの直接アクセスから保護できます。用途に応じて適切なサブネットを選択することが重要です。

Q3. サブネットのCIDRブロックを間違えた場合の対処法はありますか？

サブネットのCIDRブロックを間違えた場合、サブネットの再作成が必要になることが一般的です。AWSでは、一度作成したサブネットのCIDRブロックを変更することはできません。そのため、設計段階で慎重にCIDR範囲を決定し、将来的な拡張性を考慮することが重要です。万が一間違えた場合は、以下の手順で対処します：
1. 既存のサブネット内のリソースを新しいサブネットに移行する。
2. 古いサブネットを削除し、正しいCIDRブロックで新たにサブネットを作成する。
3. 必要に応じてルートテーブルやセキュリティグループの設定を更新する。
この際、ダウンタイムを最小限に抑えるために、リソースの移行計画を事前に立てておくことをおすすめします。

Q4. 複数のAZ（アベイラビリティーゾーン）にサブネットを分散させるメリットは何ですか？

複数のAZにサブネットを分散させる主なメリットは、高可用性と耐障害性の向上です。AWSのAZは物理的に離れた場所に存在するため、1つのAZで障害が発生しても他のAZでサービスを継続できます。例えば、パブリックサブネットとプライベートサブネットを異なるAZに配置することで、片方のAZで障害が発生しても、もう片方のAZでシステムを稼働させ続けることが可能です。また、ロードバランサーを活用することで、複数のAZ間でトラフィックを分散させ、システム全体のパフォーマンスを向上させることもできます。これにより、サービスの安定性と信頼性が高まります。

まとめ：AWS VPCサブネット設計のベストプラクティス

AWS VPCのサブネット設計では、まずCIDRブロックの選定が重要な基盤となります。プライベートIPアドレスの枯渇を防ぐため、将来的な拡張性を考慮したアドレス空間の割り当てが求められます。また、パブリックサブネットとプライベートサブネットを明確に分離することで、セキュリティと運用の効率化を図ることができます。さらに、サブネットのサイズは用途に応じて適切に設計し、不要なリソースの浪費を避けることが大切です。これらの原則を踏まえた設計は、ネットワークの安定性とセキュリティの向上に寄与します。

実際の運用では、サブネット設計の見直しや監視を定期的に行うことが推奨されます。AWSの提供するツールや機能を活用し、ネットワークの状態を把握することで、問題の早期発見やパフォーマンスの最適化が可能になります。設計段階から運用まで一貫したアプローチを取ることで、柔軟かつ堅牢なネットワーク環境を構築できます。

ABOUT ME

たから

フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営