AWSの要！VPCを徹底解剖 - ネットワーク設計の基礎と実践

こんにちは！現役エンジニアのakrです。

「【AWSプロフェッショナルへの道】現役エンジニアが贈るクラウド実践ガイド」の第2回をお届けします。前回はAWSの基礎とアカウント作成、そしてIAMの重要性について学びました。

今回は、AWSの心臓部とも言えるサービス、VPC (Virtual Private Cloud) に焦点を当てます。VPCは、AWS上にあなた専用のプライベートな仮想ネットワークを構築するためのサービスで、セキュリティやアプリケーションの設計において非常に重要な役割を担います。

「ネットワークって難しそう...」と感じる方もいるかもしれませんが、心配いりません。本記事では、VPCの基本から実践的な設計までを、分かりやすく丁寧に解説していきます。

1. VPCとは何か？なぜVPCが必要なのか？

AWSを使い始める上で、VPCの理解は避けて通れません。VPCとは、AWSクラウド内に論理的に分離された、お客様専用の仮想ネットワークのことです。これにより、まるで自分のデータセンターを持っているかのように、ネットワーク環境を自由に構築・管理できます。

なぜVPCが必要なのか？

AWSは多数のユーザーが利用する共有のインフラですが、VPCを使うことで、他のユーザーのネットワークから完全に分離された、セキュアな環境を構築できます。これにより、以下のようなメリットが得られます。

分離とセキュリティ: あなたのAWSリソース（EC2インスタンス、RDSデータベースなど）は、他のAWSユーザーから隔離されたネットワーク内に配置されます。これにより、意図しないアクセスを防ぎ、セキュリティを強化できます。
カスタマイズ性: IPアドレス範囲、サブネット、ルートテーブル、ネットワークゲートウェイなどを自由に設定し、アプリケーションの要件に合わせたネットワーク設計が可能です。
オンプレミスとの接続: VPNや専用線（AWS Direct Connect）を使って、オンプレミスのデータセンターとVPCをシームレスに接続し、ハイブリッドクラウド環境を構築できます。

AWSアカウントを作成すると、デフォルトでVPCが作成されていますが、学習を進める上では、自分でVPCを設計・構築する経験が不可欠です。

2. VPCの主要な構成要素を理解する

VPCを設計するには、いくつかの重要な構成要素を理解する必要があります。

2.1. リージョンとアベイラビリティゾーン (AZ)

AWSのインフラは、地理的な「リージョン」と、その中に複数存在する「アベイラビリティゾーン (AZ)」で構成されています。

リージョン:
- 世界中に分散されたAWSの物理的なデータセンターの集合体です。例えば「東京リージョン (ap-northeast-1)」、「バージニア北部リージョン (us-east-1)」などがあります。
- 各リージョンは完全に独立しており、データやリソースはリージョン間で自動的に共有されません。レイテンシーやデータの規制要件に応じて最適なリージョンを選択します。
アベイラビリティゾーン (AZ):
- 各リージョン内には、それぞれ物理的に独立した複数のAZがあります。AZは、電力、ネットワーク、冷却システムが独立しており、異なるAZ間の障害は互いに影響を与えません。
- 高可用性 (High Availability) を実現するために、複数のAZにリソースを分散配置することがAWS設計のベストプラクティスです。

VPCは特定のリージョン内に作成され、そのリージョン内のすべてのAZにまたがることができます。

2.2. CIDRブロック (IPアドレス範囲)

VPCを作成する際には、まずそのVPC内で使用するIPアドレスの範囲を「CIDRブロック (Classless Inter-Domain Routing)」という形式で指定します。例えば 10.0.0.0/16 のように表記します。

/16は、IPアドレスの最初の16ビットがネットワークアドレスであることを意味し、残りの16ビットがホストアドレスとして利用できます。
利用できるIPアドレスの数は、指定したCIDRブロックの範囲によって決まります。
VPCのCIDRブロックは、作成後に変更することができないため、慎重に計画する必要があります。将来的な拡張や、他のネットワークとの重複を避けるよう考慮しましょう。

2.3. サブネット

VPC内のCIDRブロックは、さらに細かいIPアドレスの範囲に分割できます。これが「サブネット」です。

サブネットは、特定のAZに関連付けられます。例えば、VPCのCIDRが 10.0.0.0/16 なら、AZ-Aに 10.0.1.0/24、AZ-Bに 10.0.2.0/24 といったサブネットを作成できます。
一般的に、インターネットから直接アクセスさせたいリソースを配置する「パブリックサブネット」と、データベースなどインターネットから直接アクセスさせたくないリソースを配置する「プライベートサブネット」に分けて設計します。
サブネットごとに異なるネットワーク設定（例: インターネットへの接続許可/不許可）を適用できます。

2.4. ルートテーブル

「ルートテーブル」は、ネットワークトラフィックがどこへ向かうべきかを決定するルール（ルート）の集合体です。

各サブネットには、関連付けられたルートテーブルが必要です。
ルートには、送信先IPアドレスと、その送信先へトラフィックを転送するためのゲートウェイやネットワークインターフェースが指定されます。
例えば、0.0.0.0/0（すべてのトラフィック）をインターネットゲートウェイに向けるルートがあれば、そのサブネットはインターネットに接続できます。

2.5. インターネットゲートウェイ (IGW)

「インターネットゲートウェイ (IGW)」は、VPCとインターネット間の通信を可能にするためのゲートウェイです。

VPCにアタッチすることで、パブリックサブネット内のリソース（例: パブリックIPアドレスを持つEC2インスタンス）がインターネットと通信できるようになります。
IGW自体は単一障害点ではなく、高可用性を持っています。

2.6. NATゲートウェイ (NAT Gateway)

「NATゲートウェイ (NAT Gateway)」は、プライベートサブネット内のリソースが、インターネットと通信できるようにするためのサービスです。

プライベートサブネット内のEC2インスタンスなどが、ソフトウェアのアップデートなどで外部インターネットにアクセスしたい場合、NATゲートウェイを経由して通信します。
NATゲートウェイはパブリックサブネットに配置され、プライベートサブネットからインターネットへの「出ていく」通信のみを許可し、インターネットからプライベートサブネットへの「入ってくる」通信はブロックします。これにより、セキュリティを維持しつつインターネットアクセスを可能にします。
高可用性が必要な場合は、各AZにNATゲートウェイを配置するのがベストプラクティスです。

2.7. ネットワークACLとセキュリティグループ

ネットワークのアクセス制御には、「ネットワークACL (Access Control List)」と「セキュリティグループ (Security Group)」の2つの仕組みがあります。

ネットワークACL:
- サブネットレベルでトラフィックを制御するステートレスなファイアウォールです。
- 送信元IPアドレス、ポート番号などに基づいて、インバウンド（入ってくる）およびアウトバウンド（出ていく）トラフィックを許可または拒否できます。
- ルールは番号順に評価され、最後のルールはすべてを拒否します。
- サブネット内のすべてのリソースに適用されます。
セキュリティグループ:
- EC2インスタンスなどのインスタンスレベルでトラフィックを制御するステートフルなファイアウォールです。
- 特定のポートやプロトコルからのアクセスを許可できます。デフォルトでは全てを拒否します。
- インバウンドルールを許可すると、それに対応するアウトバウンドルールは自動的に許可されます（ステートフル）。
- 特定のインスタンスにのみ適用されます。

これらの違いについては、後日「セキュリティ」の回で詳しく解説しますが、VPC設計の段階から両者の役割を理解しておくことが重要です。

3. 実践！シンプルなVPCを構築してみよう

それでは、実際にAWSマネジメントコンソールを使って、WebアプリケーションをデプロイするためのシンプルなVPCを構築してみましょう。今回は以下の構成を目指します。

VPC: 10.0.0.0/16
パブリックサブネット (Webサーバー用): 10.0.1.0/24 (AZ-A)
プライベートサブネット (データベース用): 10.0.2.0/24 (AZ-A)
インターネットゲートウェイ
NATゲートウェイ (パブリックサブネットに配置)
各サブネットに対応するルートテーブル

3.1. VPCの作成

AWSマネジメントコンソールにIAMユーザーでサインインします。
サービス検索バーで「VPC」と入力し、VPCコンソールを開きます。
左のナビゲーションペインから「VPC」を選択し、「VPCを作成」をクリックします。
「VPCのみ」を選択し、以下の情報を入力します。
- 名前タグ: my-web-app-vpc
- IPv4 CIDRブロック: 10.0.0.0/16
- その他の設定はデフォルトのままで「VPCを作成」をクリック。

これで、あなたのプライベートネットワークの基盤ができました。

3.2. サブネットの作成

次に、VPC内にサブネットを作成します。今回は、アプリケーションの要件に応じて、最低限のパブリックサブネットとプライベートサブネットを1つずつ作成します。

VPCコンソールで「サブネット」を選択し、「サブネットを作成」をクリックします。
VPC ID: 先ほど作成した my-web-app-vpc を選択します。
アベイラビリティゾーン (AZ): 任意のAZを選択します（例: ap-northeast-1a）。本番環境では、複数のAZにサブネットを分散することが非常に重要です。今回は学習のため1つのAZに集約します。
サブネットの名前: my-web-app-public-subnet-a
IPv4 CIDRブロック: 10.0.1.0/24
「新しいサブネットを追加」をクリックし、同様にプライベートサブネットを作成します。
- アベイラビリティゾーン (AZ): 先ほどと同じAZ（例: ap-northeast-1a）
- サブネットの名前: my-web-app-private-subnet-a
- IPv4 CIDRブロック: 10.0.2.0/24
「サブネットを作成」をクリック。

これで、VPC内に2つのサブネットが作成されました。

3.3. インターネットゲートウェイ (IGW) の作成とアタッチ

パブリックサブネットからインターネットへ接続できるように、IGWを作成しVPCにアタッチします。

VPCコンソールで「インターネットゲートウェイ」を選択し、「インターネットゲートウェイを作成」をクリックします。
名前タグ: my-web-app-igw
「インターネットゲートウェイを作成」をクリック。
作成されたIGWを選択し、「アクション」→「VPCにアタッチ」を選択します。
アタッチするVPC: my-web-app-vpc を選択し、「インターネットゲートウェイをアタッチ」をクリック。

これで、VPCがインターネットと通信する準備ができました。

3.4. ルートテーブルの設定

サブネットがどこへトラフィックを送信するかを定義します。

VPCコンソールで「ルートテーブル」を選択します。VPCを作成すると、デフォルトで1つのルートテーブルが作成されています。これはすべてのサブネットに関連付けられています。
パブリックサブネット用の新しいルートテーブルを作成します。
- 「ルートテーブルを作成」をクリック。
- 名前タグ: my-web-app-public-rt
- VPC: my-web-app-vpc を選択し、「ルートテーブルを作成」。
作成した my-web-app-public-rt を選択し、「ルート」タブ→「ルートを編集」→「ルートを追加」をクリック。
- 送信先: 0.0.0.0/0 (すべてのインターネットトラフィック)
- ターゲット: 「Internet Gateway」を選択し、先ほど作成した my-web-app-igw を選択します。
- 「変更を保存」をクリック。
次に、このルートテーブルをパブリックサブネットに関連付けます。
- my-web-app-public-rt を選択したまま、「サブネットの関連付け」タブ→「サブネットの関連付けを編集」をクリック。
- my-web-app-public-subnet-a にチェックを入れ、「関連付けを保存」。

これで、パブリックサブネット内のリソースはインターネットと通信できるようになりました。

3.5. NATゲートウェイの作成 (オプションだが推奨)

プライベートサブネットからインターネットへ「出ていく」通信を許可するために、NATゲートウェイを作成します。

VPCコンソールで「NATゲートウェイ」を選択し、「NATゲートウェイを作成」をクリックします。
名前タグ: my-web-app-nat-gw-a
サブネット: パブリックサブネット（my-web-app-public-subnet-a）を選択します。
Elastic IP割り当て ID: 「Elastic IPを割り当て」をクリックし、新しいEIPを作成します。
「NATゲートウェイを作成」をクリック。作成には数分かかる場合があります。

3.6. プライベートサブネットのルートテーブル設定

NATゲートウェイを作成したら、プライベートサブネットがそれを利用するようにルートテーブルを設定します。

VPCコンソールで「ルートテーブル」を選択し、新しいルートテーブルを作成します。
- 名前タグ: my-web-app-private-rt
- VPC: my-web-app-vpc を選択し、「ルートテーブルを作成」。
作成した my-web-app-private-rt を選択し、「ルート」タブ→「ルートを編集」→「ルートを追加」をクリック。
- 送信先: 0.0.0.0/0
- ターゲット: 「NAT Gateway」を選択し、先ほど作成した my-web-app-nat-gw-a を選択します。
- 「変更を保存」をクリック。
次に、このルートテーブルをプライベートサブネットに関連付けます。
- my-web-app-private-rt を選択したまま、「サブネットの関連付け」タブ→「サブネットの関連付けを編集」をクリック。
- my-web-app-private-subnet-a にチェックを入れ、「関連付けを保存」。

これで、プライベートサブネット内のリソースもNATゲートウェイ経由でインターネットにアクセスできるようになりました。

4. VPC設計のベストプラクティス

より堅牢でスケーラブルなVPCを設計するために、いくつかのベストプラクティスを意識しましょう。

複数のアベイラビリティゾーン (AZ) の利用:
- アプリケーションの高可用性を確保するため、必ず複数のAZにリソース（特にサブネット）を分散配置しましょう。これにより、1つのAZで障害が発生しても、他のAZでサービスを継続できます。
プライベートサブネットとパブリックサブネットの分離:
- セキュリティを考慮し、インターネットから直接アクセスが必要なリソース（Webサーバーなど）はパブリックサブネットに、データベースやアプリケーションサーバーなど直接アクセス不要なリソースはプライベートサブネットに配置しましょう。
IPアドレス範囲の計画:
- 将来的なネットワーク拡張や、オンプレミス環境との接続を考慮し、VPCやサブネットのCIDRブロックは慎重に決定しましょう。他ネットワークとのIPアドレス重複は避けなければなりません。
最小権限の原則に基づくセキュリティグループとネットワークACLの設定:
- 必要な通信のみを許可し、不要なポートやIPアドレスからのアクセスは厳しく制限しましょう。
タグ付けの徹底:
- VPCやサブネット、ゲートウェイなどのリソースには、必ず分かりやすいタグ（例: Project:WebApp, Environment:Prod）をつけましょう。これにより、リソースの管理やコスト分析が容易になります。

まとめ

今回はAWSのVPCについて、その役割から主要な構成要素、そしてシンプルなVPCの構築手順までを解説しました。

VPCはAWSクラウド内に論理的に分離された仮想ネットワークで、セキュアな環境を構築する基盤です。
リージョン、AZ、CIDR、サブネット、ルートテーブル、IGW、NATゲートウェイといった要素を理解することが重要です。
パブリックサブネットとプライベートサブネットを適切に分離し、セキュリティと可用性を高めましょう。
実践的なVPC構築を通じて、設定方法を習得しました。

VPCはAWSにおけるネットワークの「箱」を作るサービスです。この箱の中に、次回以降で学ぶEC2インスタンスやRDSデータベースといった様々なリソースを配置していくことになります。

次回、第3回では 「仮想サーバーの起動から運用まで！EC2完全マスターガイド」 と題して、AWSのコンピューティングサービスの中心であるEC2について詳しく解説します。お楽しみに！

この記事が皆さんのAWS学習の一助となれば幸いです。

もしこの記事が役に立ったと感じたら、ぜひ「いいね」👍をお願いします！励みになります！