VPC講座

この講座では、AWSの仮想ネットワークサービスであるVPCについて学びます。

• VPC（Virtual Private Cloud）の概念と役割
• サブネット（Public/Private）の設計
• CIDRブロックによるIPアドレス管理
• インターネットゲートウェイとNATゲートウェイの仕組み
• ルートテーブル・セキュリティグループ・ネットワークACLの設定

1. VPCとサブネット

AWSで仮想ネットワークを作成できるVPCと、その関連サービスについて解説します。

1.1 VPCとは

VPC（Virtual Private Cloud）は、AWSの中に作ることができる「自分専用の仮想ネットワーク」です。

通常、サーバやデータベースといった機器を導入する際には、いきなり機器を置くのではなく、まずそれらを配置するためのネットワークの領域を確保しなければなりません。これはクラウドの世界でも同じです。

AWSにおいても同様で、まずAWSアカウントを作ったら、VPCというネットワークの区画を作成し、その中に仮想サーバやデータベースといったリソースを配置していきます。

このVPCは、AWSアカウントの中に複数作成することができます。例えば、「顧客向けのWebサイト」と「社内用の業務システム」のように異なるシステム同士の通信を分けたり、一つのVPCの中に複数のサーバやデータベースをまとめて構成したりするなど、用途に合わせて自由にネットワークを設計することができます。

1.2 サブネットとは

VPCの中にさらに細分化したネットワーク領域を作成できるサブネットについて解説します。

サブネットは、VPCの中に作成できる、役割ごとにリソースを隔離できるネットワーク領域で、インターネットへの接続可否によりセキュリティレベルを分けることができます。VPCの内部を、役割や機密性ごとにサブネットとして分割することで、目的に合わせてリソースを適切に配置することができます。

サブネットは、インターネットへの接続経路を持つかどうかによりPublic SubnetとPrivate Subnetの2つに分類されます。

Public Subnetは、インターネットとの通信が許可されているサブネットです。例えば、Webサーバや企業のコーポレートサイトなど、インターネット側に公開する必要があるリソースを配置するときに利用されます。

Private Subnetは、インターネットから直接アクセスできないサブネットです。内部でのみ完結する処理や、データベースのような直接外部から参照されたくないリソースを配置することに適しています。

1.3 CIDRブロック

VPCやサブネットの定義を行う上で必要となるCIDRブロックという考え方について説明します。専門的に聞こえますが、順を追って理解していけば難しくありません。

CIDRブロックとは

まず、コンピュータが自分自身の位置、つまり「住所」を表すために必要となるのが「IPアドレス」です。

AWSのVPCやサブネットでは、「プライベートIPアドレス」と呼ばれる、組織内で自由に使用できるIPアドレスの中から、好きな範囲を切り取って利用します。

この、VPCやサブネットを作る際に「IPアドレスをどこからどこまで使用するか（範囲）」を定義したものが、CIDRブロックです。

CIDRブロックの表記

CIDRブロックは、以下のように表記します。

10.0.0.0/16

IPアドレス部分

先頭の 10.0.0.0 の部分が「先頭のIPアドレス」を表し、「このIPアドレスから利用できるようになる」という開始位置を示します。

サブネットマスク

ここで、10.0.0.0/16 の、/16 部分を「サブネットマスク（またはプレフィックス長）」と呼び、これにより「利用できる範囲」を表します。

/x の部分は、0〜32の範囲で指定します。これは、IPアドレスの左から「何桁をロック（固定）するか」という意味になります。

逆に言うと、「32」からこの数値をマイナスしたときの結果が、「自由に変更して使える範囲」になります。

例えば、/32（最大値）とした場合、32-32はゼロなので、「自由に変更できる部分がない」、つまり「すべてロックされている」状態です。そのため、10.0.0.0/32 と書くと、その「10.0.0.0」というIPアドレス「1個だけ」を指すことになります。

10.0.0.0/32
→ 10.0.0.0のみが利用可能

逆に、範囲を広くしたい場合は数字を小さくします。もし「0.0.0.0/0」とした場合は、ロックがゼロなので、世界中のすべてのIPアドレスを表すことになります。

0.0.0.0/0
→ 0.0.0.0〜255.255.255.255のすべて利用可能

よく使われる範囲

少しずつロックを緩めて範囲を広げてみましょう。

/24

まず、/24 です。これは左から24桁をロックするという意味です。

32 - 24は「8」なので、最後の8桁だけが自由に使えます。これを10進数で考えると、左の3つの数字（8桁×3）は固定され、最後の1つの数字だけが0〜255まで変化できる状態です。計算すると2の8乗で、256個のIPアドレスが利用できます。AWSでは「サブネット」のサイズとして最もよく使われます。

10.0.0.0/24
→ 10.0.0.0〜10.0.0.255までが使える

/16

次に、さらに範囲を広げた /16 です。左から16桁をロックします。32引く16は「16」なので、後半の16桁（2ブロック）が自由に使えます。10進数では、左の2つの数字（8桁×2）だけ固定され、右側の2つの数字がフルに変化できる状態です。計算すると2の16乗で、約6万5千個（65,536個）のIPアドレスが利用できます。AWSでは「VPC全体」のサイズとして標準的です。

10.0.0.0/16
→ 10.0.0.0〜10.0.255.255までが使える

/8

最後に、非常に巨大な範囲である /8 です。左から8桁だけをロックします。32引く8は「24」となり、残りの24桁がすべて自由に使えます。10進数では、一番左の数字（8桁×1）だけ固定され、残りの3つの数字すべてが変化できる状態です。計算すると2の24乗で、なんと約1,677万個ものIPアドレスが含まれる巨大なブロックになります。

10.0.0.0/8
→ 10.0.0.0〜10.255.255.255までが使える

この数値は大変巨大なものであるため、通常AWSのVPCやサブネットの設計ではあまり使いません。

CIDRブロックのまとめ

数字が小さくなるほど、固定される場所が減り、使える範囲が増えていきます。

AWSが固定している範囲

CIDRブロックの計算方法がわかったところで、AWSを利用する上で必ず覚えておかなければならない重要なルールについて説明します。それは、「AWSが自動的に予約しているIPアドレス」の存在です。

先ほど、/24 のサブネットでは256個のIPアドレスが使えると説明しましたが、実はAWSでは、この中から「5個」のIPアドレスがシステム用に予約されており、私たちは利用することができません（Subnet CIDR blocks（AWS公式ドキュメント）に「The first four IP addresses and the last IP address in each subnet CIDR block are not available for your use」と明記されています）。そのため、実際にサーバなどに割り当てられる数は、256個から5個を引いた「251個」になります。

具体的に、10.0.0.0/24 というサブネットを例にして、どのIPアドレスが予約されているかを見てみましょう。実際に覚える必要はないので、「これは利用できないものである」と意識してもらえれば大丈夫です。

1.4 AWSでのCIDRの使われ方

ここまで複雑な計算方法について解説してきましたが、AWSでの利用方法はある程度のパターンがあります。

VPCでの設定

まず、VPCに対しては /16 の範囲を利用することが多いです。/16 は「後ろの2つ（右側の2ブロック）」が自由に使えるので、

10.0.0.0/16

とした場合は、

10.0.0.0〜10.0.255.255

までの「65,536通り」のIPアドレスが使えます。

サブネットでの設定

続いてサブネットでの設定例です。

サブネットのCIDRブロックは、VPCで指定した範囲の「内側」である必要があり、VPCより広い範囲を指定することはできません。

サブネットでは一般的に「/24」の範囲が使われます。これは後ろの一つ（右側の1ブロック）が自由に使えるという意味なので、

10.0.0.0/24

とした場合は、

10.0.0.0〜10.0.0.255

までの「256通り」のIPアドレスが利用できます。

※ AWSの予約部分は一旦除外して考えています。

設定の例

実際の設定例をみていきます。例えば、一つのVPCの中にサブネットが2つ存在する場合、

VPC：10.0.0.0/16
サブネットA：10.0.0.0/24
サブネットB：10.0.1.0/24

のように設定します。

そうすると、利用できる範囲はそれぞれ以下のようになります。

VPC：10.0.0.0 〜 10.0.255.255
サブネットA：10.0.0.0 〜 10.0.0.255
サブネットB：10.0.1.0 〜 10.0.1.255

もしサブネットCを増やしたい場合は、「10.0.2.0/24」や「10.0.3.0/24」などを設定していけば、重複することなく更に増やすことができます。

また、VPC自体を増やすなら、「10.1.0.0/16」や「10.2.0.0/16」などとすれば、別の独立したネットワーク（VPC）を作ることができます。

このように、CIDRやサブネットマスクの考え方は少し複雑ですが、VPCやサブネットに設定するべき内容に絞って考えると、ある程度シンプルに整理することができます。

2. インターネットへの接続

サブネットをインターネットへ接続させるためのサービスとして、インターネットゲートウェイとNATゲートウェイについて解説します。

2.1 インターネットゲートウェイ

Public Subnetをインターネットへ接続したい場合、そのままでは接続できません。そこで必要になるのが、インターネットゲートウェイです。

インターネットゲートウェイは、VPCとインターネットを繋ぐ「出入り口」となるコンポーネントです。VPCは作成直後は外部と隔離されているため、この出入り口を取り付ける必要があります。

具体的には、VPCにインターネットゲートウェイを設置し、ルートテーブルで通信経路を向けることで、そのサブネットがインターネットと通信できるようになります。これをパブリックサブネットと呼びます。

2.2 NATゲートウェイとは

もう一つのインターネットへの経路となるNATゲートウェイについて解説します。

NATゲートウェイは、Private Subnet内のリソースがOSやソフトウェアのアップデートなどでインターネットに接続する必要がある場合に利用するコンポーネントです。

前述の通り、Private Subnetは通常インターネットに接続できません。そのため、配置されたリソースのOSやソフトウェアを更新できないという課題が発生します。そこで解決策として利用できるのがNATゲートウェイです。

NATゲートウェイは、Private Subnetからインターネットへ向けた発信（アウトバウンド）と、その応答の戻り通信だけを許可することができます。これにより、Private Subnet内のリソースから開始されるインストールやアップデートの通信は許可され、目的を達成できます。

一方で、インターネット側からNATゲートウェイを通じてPrivate Subnetのリソースに対して接続を開始することはできません。そのため、Private Subnetが外部からの直接的な攻撃対象となるリスクを回避できます。

構成としては、NATゲートウェイ自体はPublic Subnet内に配置され、Private Subnetのルートテーブルで通信の転送先として指定する形で利用します。

ゾーナルとリージョナル

NATゲートウェイには、ゾーナル（Zonal）とリージョナル（Regional）の2つの種類があります。

ゾーナルNATゲートウェイは、特定のアベイラビリティゾーン（AZ）のPublic Subnetに配置する従来のタイプです。マルチAZ構成で高可用性を確保する場合は、各AZにNATゲートウェイを1つずつ配置する必要があります。

リージョナルNATゲートウェイは、2025年に追加された新しいタイプで、リージョン全体で1つのNATゲートウェイを共有できます。AZごとに個別のNATゲートウェイを作成する必要がなく、構成がシンプルになります。また、リージョナルNATゲートウェイはPublic Subnetに配置する必要がないため、VPC設計がさらに簡素化されます。

ただし、リージョナルNATゲートウェイの時間料金は、リージョン内のAZ数に応じた課金となるため、AZ数が多いリージョンではゾーナルNATゲートウェイを必要なAZにだけ配置する方がコストを抑えられる場合があります。用途やコスト要件に応じて使い分けてください。

2.3 ルートテーブルとは

ルートテーブルについて解説します。

ルートテーブルは、サブネットの中に作られたリソースが、通信を行う際にどこを通ればよいかを判断するための「通信のルールブック」のようなものです。

このルールブックには、大きく分けて2つの項目を設定します。

1つ目は「宛先（Destination）」、つまり「どこへ送りたい通信か」というIPアドレスの範囲です。2つ目は「ターゲット（Target）」、つまり「その通信をどのコンポーネントに転送するか」という転送先です。

AWSは、サブネットの内部にあるリソースから通信のリクエストを受け取ると、このルートテーブルを上から順に確認し、宛先に一致するルールに従ってデータを転送します。

具体的な設定例を見ていきましょう。

最もよく使われるのが、「0.0.0.0/0」という宛先に対する設定です。この「0.0.0.0/0」は、すべてのIPアドレスを表しており、「VPC内部以外の、その他すべての通信」を意味します。これを「デフォルトルート」とも呼びます。

この「その他すべての通信」をどこに向けるかで、サブネットの役割が決まります。2つのパターンを紹介します。

パブリックサブネットにする場合

まず1つ目は、「パブリックサブネット」にする場合です。インターネットへ直接接続させたいときは、宛先「0.0.0.0/0」に対して、ターゲットを「インターネットゲートウェイ」に設定します。

こうすることで、サーバからの通信はインターネットゲートウェイを通って、外の世界へ出ていくことができます。

プライベートサブネットにする場合

2つ目は、「プライベートサブネット」にする場合です。

例えば、データベースサーバのように「外部からは隠したいけれど、ソフトウェアのアップデートのために外へのアクセスはしたい」というケースです。この場合は、宛先「0.0.0.0/0」に対して、ターゲットを「NAT（ナット）ゲートウェイ」に設定します。

こうすることで、外部から直接覗かれることなく、安全にインターネットへの片道通信だけが可能になります。

なお、どちらのルートテーブルにも、デフォルトで「local（ローカル）」というターゲットが設定されています。これはVPC内部の通信を行うためのもので、自動的に適用されます。

まとめると、ルートテーブルで「0.0.0.0/0」のターゲットを「インターネットゲートウェイ」に向ければパブリックサブネットになり、「NATゲートウェイ」に向ければプライベートサブネットとして機能する、という点を覚えておいてください。

3. ファイアウォール

これまでは、サブネットの内部から外側へ向かう通信方法について解説してきました。続いて、外側からVPCやサブネット内のリソースへ接続する際の通信制御を行う、仮想ファイアウォールの設定について説明します。

3.1 セキュリティグループ

セキュリティグループは、AWSでVPC内部のリソースに向けて設定できるファイアウォールの一つで、内部リソースへの「許可設定」を行うことができます。

ホワイトリスト方式

セキュリティグループは、デフォルトでは全ての通信が「拒否」されており、そこに対して必要な通信の「許可」だけを追加していくホワイトリスト方式です。

通信の許可設定は、主に「タイプ」「プロトコル」「ポート範囲」「ソース」の4つの項目で行います。

まず「タイプ」です。これは、AWSが事前に用意してくれている「よく使われる通信プロトコルのプリセット」です。

例えば「HTTP」や「SSH」などをリストから選ぶだけで、プロトコルとポート番号（80番や22番など）の組み合わせが自動的に設定されます。

もしリストにないポートを使いたい場合は「カスタムTCP」を選んで手動入力したり、「すべてのトラフィック」を選んで全開放したりすることも可能です。

次に「ソース」です。これは「通信の送信元」、つまり「どこからのアクセスを許可するか」を指定する項目です。

設定方法は大きく3パターンあります。

• 「0.0.0.0/0」を指定して、世界中すべての場所からの通信を許可するパターン
• 特定のIPアドレスやCIDRブロックを指定して、特定の場所からのみ許可するパターン
• AWSリソースの直接指定。例えばIPアドレスの代わりに「特定のセキュリティグループID」を指定することで、「そのグループに属するサーバからの通信だけを許可する」といった、AWSならではの柔軟な連携設定が可能

許可設定の方向

続いて、セキュリティグループにおける通信の「方向」について説明します。設定には、外から中へ入ってくる「インバウンド」と、中から外へ出ていく「アウトバウンド」の2種類があります。

まず「インバウンド」です。こちらは、デフォルトの状態ではルールが空っぽであり、つまり「すべて拒否」される状態になっています。そのため、WebサーバやSSH接続など、必要な通信については明示的に許可ルールを追加しない限り、外部からは一切アクセスできません。

次に「アウトバウンド」です。こちらは逆に、デフォルトですべての通信が「許可」されています。「内部から外へ出ていく通信」は、Windows Updateやソフトウェアのインストールなど、管理者自身が意図して行うことが多いため、基本的には制限をかけないのが一般的です。ただし、セキュリティをより強固にするために、ここを制限することもあります。例えば、プログラムのバグや、万が一ウイルスに感染した場合などに、意図しないサーバへデータを送信してしまう「情報の持ち出し」を防ぐためです。要件に応じて、必要な宛先だけに絞る設定も検討しましょう。

ステートフル

最後に、セキュリティグループを理解する上で欠かせないステートフルという性質について説明します。

「ステートフル」とは、通信の状態（ステート）を記憶してくれる機能のことです。

具体的には、「リクエスト（行きの通信）が許可されれば、その戻りのレスポンス（帰りの通信）は、ルールに関係なく『自動的に』許可される」という仕組みです。

例えば、このサーバから外部の「サイトA」にアクセスする場合を考えてみましょう。アウトバウンドルールで「サイトAへのアクセス」が許可されていれば、リクエストは送信されます。そして、サイトAからデータが返ってくるとき、インバウンドルールでそのIPアドレスが許可されていなくても、セキュリティグループは「これはさっき自分が送ったリクエストの返事だな」と判断して、自動的に通してくれます。

これは逆に、外部からWebサーバへアクセスが来た場合も同じです。インバウンドで「Webサイトの閲覧」を許可しておけば、サーバがユーザへデータを送り返す際のアウトバウンドルールを個別に書く必要はありません。つまり、セキュリティグループは「入ってくる許可」か「出ていく許可」、どちらか片方の道さえ開いておけば、その往復の通信は成立する、と覚えておいてください。

3.2 ネットワークACL

ネットワークACL（アクセスコントロールリスト）は、VPCの「サブネット」単位で設定できるファイアウォールです。セキュリティグループが「インスタンスごとの盾」であるのに対し、こちらはサブネットへの出入りを管理する「関所」のような役割を果たします。

ブラックリスト方式

セキュリティグループが「許可」のみを行えるのに対し、ネットワークACLは通信の「許可」と「拒否」の両方を設定できます。これにより、例えば「特定の悪意あるIPアドレスからの通信だけをブロックする」といったブラックリスト方式の制御が可能です。

設定項目はセキュリティグループと似ていますが、重要な違いが2点あります。

1つ目は「ルール番号」です。ネットワークACLのルールには番号が振られ、番号が小さい順（昇順）に評価されます。条件に一致するルールが見つかった時点で、それ以降のルールは無視されます。

2つ目は「送信元・送信先」です。ここにはIPアドレス（CIDRブロック）しか指定できません。セキュリティグループのように「他のセキュリティグループID」を指定することはできないため、IPベースでの管理が必須となります。

デフォルトの挙動

ネットワークACLのデフォルト設定は、作成パターンによって異なります。VPC作成時に自動で作られる「デフォルトのネットワークACL」は、利便性を優先して「すべての通信を許可」しています。一方で、ユーザが手動で新規作成する「カスタムネットワークACL」は、安全性を考慮して「すべての通信を拒否」する状態から始まります。

ステートレス

最後に、セキュリティグループとの最大の違いであるステートレスという性質について説明します。「ステートレス」とは、通信の状態（ステート）を記憶しないという性質です。具体的には、「リクエスト（行きの通信）が許可されていても、その戻りのレスポンス（帰りの通信）は、自動的には許可されない」という仕組みです。

例えば、サーバから外部の「サイトA」にアクセスする場合を考えてみましょう。アウトバウンドルールで「サイトAへのアクセス」を許可してリクエストを送っても、サイトAからデータが返ってきたとき、インバウンドルールでその通信が許可されていなければ、データはサブネットの入り口で遮断されてしまいます。

そのため、ネットワークACLを設定する際は、「行きのルール」と「帰りのルール」をそれぞれ明示的に設定する必要があります。特に、戻りの通信で使用される「エフェメラルポート（一時的なポート）」の許可設定を忘れると通信が成立しないため、セキュリティグループよりも設定の難易度が高くなります。

3.3 セキュリティグループとネットワークACLの比較

セキュリティグループとネットワークACLの違いをまとめます。

3.4 使い分け

基本的な通信制御はネットワークACLを「すべて許可」にしておき、セキュリティグループで制御することが多いです。デフォルト状態でも、セキュリティグループはインバウンドルールは「すべて拒否」、アウトバウンドルールは「すべて許可」ですが、ネットワークACLは「すべて許可」となるため、特に意識しなくても通信ができるようになっています。

ネットワークACLは、特定のIPアドレスをブロックしたい場合など、セキュリティグループで設定しきれない場合に利用されることが多いです。

4. 主なユースケース

VPCは、AWSでシステムを構築する際の基盤となるサービスです。以下に代表的なユースケースを紹介します。

4.1 Webアプリケーションの構築

パブリックサブネットにWebサーバを配置してインターネットからのアクセスを受け付け、プライベートサブネットにデータベースを配置して外部からの直接アクセスを遮断する構成が一般的です。この構成により、ユーザには快適なWeb体験を提供しつつ、重要なデータは安全に保護することができます。

4.2 マルチ環境の分離

開発環境、ステージング環境、本番環境をそれぞれ別のVPCとして作成することで、環境間の影響を完全に分離できます。開発中のバグや設定ミスが本番環境に影響を与えることを防ぎ、安全な開発・運用体制を構築できます。

4.3 ハイブリッドクラウド構成

オンプレミス（社内データセンター）とAWSをVPN接続やDirect Connectで繋ぐことで、既存の社内システムを維持しながらクラウドのメリットを活用できます。段階的なクラウド移行や、機密データを社内に残しつつ処理能力だけクラウドを利用するといった柔軟な構成が可能です。

5. 設計のポイント

VPCを設計する際の主要な検討項目を以下にまとめます。

6. まとめ

この講座では、VPC（仮想ネットワーク）について学びました。

• VPCは、AWS上に作成できる自分専用の仮想ネットワーク
• サブネットでVPC内をさらに細分化し、パブリック/プライベートで役割を分ける
• CIDRブロックでIPアドレスの範囲を定義する
• インターネットゲートウェイでVPCをインターネットに接続する
• NATゲートウェイでプライベートサブネットから外部への片方向通信を許可する
• ルートテーブルで通信経路を制御する
• セキュリティグループはインスタンス単位でステートフルなファイアウォール
• ネットワークACLはサブネット単位でステートレスなファイアウォール