VPCとサブネットでネットワークを構築する

前回までの記事では、IAMによるアクセス管理について解説しました。本記事では、AWSのネットワーク基盤であるVPC（Virtual Private Cloud）について解説します。VPCの基本概念から、CIDRブロックの設計、パブリック/プライベートサブネットの使い分け、マルチAZ構成まで、安全で可用性の高いネットワーク基盤を構築するための知識を身につけましょう。

VPC（Virtual Private Cloud）とは

VPCは、AWSクラウド内に構築できる論理的に隔離された仮想ネットワークです。オンプレミス環境で構築するプライベートネットワークと同様に、IPアドレス範囲の選択、サブネットの作成、ルートテーブルやネットワークゲートウェイの設定を行うことができます。

VPCを利用することで、AWS上のリソースを論理的に分離し、セキュアなネットワーク環境を構築できます。EC2インスタンス、RDSデータベース、Lambda関数などのAWSリソースは、VPC内に配置して通信を制御します。

VPCの特徴

VPCには以下の特徴があります。

VPCの基本構成要素

VPCを構成する主要な要素を以下に示します。

graph TB
    subgraph "AWS Cloud"
        subgraph "VPC (10.0.0.0/16)"
            subgraph "AZ-a"
                PubSub1[パブリック<br/>サブネット<br/>10.0.1.0/24]
                PriSub1[プライベート<br/>サブネット<br/>10.0.11.0/24]
            end
            subgraph "AZ-c"
                PubSub2[パブリック<br/>サブネット<br/>10.0.2.0/24]
                PriSub2[プライベート<br/>サブネット<br/>10.0.12.0/24]
            end
            IGW[インターネット<br/>ゲートウェイ]
            RT[ルートテーブル]
        end
    end
    
    Internet((インターネット)) --> IGW
    IGW --> PubSub1
    IGW --> PubSub2

デフォルトVPCとカスタムVPC

AWSアカウントを作成すると、各リージョンにデフォルトVPCが自動的に作成されます。本番環境では要件に応じたカスタムVPCを作成することが推奨されています。

デフォルトVPC

デフォルトVPCは、AWSアカウント作成時に各リージョンに自動的に作成されるVPCです。以下の特徴があります。

• CIDR: 172.31.0.0/16
• 各AZに/20のパブリックサブネットが作成される
• インターネットゲートウェイが自動的にアタッチされる
• サブネットに起動したインスタンスにはパブリックIPが自動的に割り当てられる

デフォルトVPCは、AWSを手軽に試すには便利ですが、以下の理由から本番環境では推奨されません。

1. IPアドレス範囲が固定: CIDRブロックを変更できないため、オンプレミスや他のVPCとの接続時にIPアドレスが重複する可能性がある
2. セキュリティ設定が緩い: すべてのサブネットがパブリックで、インスタンスに自動的にパブリックIPが割り当てられる
3. 設計の自由度が低い: サブネット構成やルーティングが事前に決められている

カスタムVPC

カスタムVPCは、ユーザーが要件に応じて設計・作成するVPCです。以下のメリットがあります。

• IPアドレス範囲を自由に設計できる
• パブリック/プライベートサブネットを適切に配置できる
• セキュリティ要件に応じたネットワーク設計が可能
• マルチAZ構成による高可用性を実現できる

CIDRブロックの設計

VPCを作成する際、最初に決定するのがCIDR（Classless Inter-Domain Routing）ブロックです。CIDRブロックはVPC内で使用するプライベートIPアドレスの範囲を定義します。

CIDRの基本

CIDR表記は「IPアドレス/プレフィックス長」の形式で表されます。プレフィックス長は、ネットワーク部のビット数を示します。

VPCのCIDRブロックは/16から/28の範囲で指定できます。AWSでは、RFC 1918で定義されたプライベートIPアドレス範囲の使用が推奨されています。

VPC CIDRの設計指針

VPCのCIDRブロックを設計する際は、以下の点を考慮します。

将来の拡張性を考慮する

VPCのCIDRブロックは作成後に縮小できません。拡張は可能ですが、連続したIPアドレス空間を確保できない場合があります。将来的なリソース増加を見越して、十分な大きさのCIDRブロックを確保しましょう。

他のネットワークとの重複を避ける

オンプレミス環境、他のVPC、パートナー企業のネットワークとVPN接続やVPCピアリングを行う場合、CIDRブロックが重複していると通信できません。企業全体でIPアドレス管理を行い、重複を避けることが重要です。

サブネット分割を計画する

VPCのCIDRブロックは複数のサブネットに分割されます。各サブネットに適切なIPアドレス数を割り当てられるよう、全体設計を行います。

実践的なCIDR設計例

本番環境向けの実践的なVPC CIDR設計例を示します。

VPC CIDR: 10.0.0.0/16（65,536 IPアドレス）

パブリックサブネット（Webサーバー、踏み台サーバー用）
├── AZ-a: 10.0.1.0/24  （251 IPアドレス）
├── AZ-c: 10.0.2.0/24  （251 IPアドレス）
└── AZ-d: 10.0.3.0/24  （251 IPアドレス）

プライベートサブネット（アプリケーションサーバー用）
├── AZ-a: 10.0.11.0/24 （251 IPアドレス）
├── AZ-c: 10.0.12.0/24 （251 IPアドレス）
└── AZ-d: 10.0.13.0/24 （251 IPアドレス）

プライベートサブネット（データベース用）
├── AZ-a: 10.0.21.0/24 （251 IPアドレス）
├── AZ-c: 10.0.22.0/24 （251 IPアドレス）
└── AZ-d: 10.0.23.0/24 （251 IPアドレス）

この設計では、第3オクテットを用途（1-9: パブリック、11-19: アプリケーション、21-29: データベース）で分類しています。これにより、ルートテーブルやセキュリティグループの設定が直感的になります。

AWSが予約するIPアドレス

各サブネットでは、AWSが5つのIPアドレスを予約しています。例えば10.0.1.0/24のサブネットでは、以下のIPアドレスは使用できません。

したがって、/24のサブネットで実際に使用できるIPアドレス数は256 - 5 = 251個となります。

サブネットの概念と種類

サブネットは、VPCのCIDRブロックを分割した小さなネットワークセグメントです。サブネットは特定のアベイラビリティゾーン（AZ）に作成され、AZを跨ぐことはできません。

パブリックサブネットとプライベートサブネット

サブネットは、インターネットとの接続性によって「パブリックサブネット」と「プライベートサブネット」に分類されます。

graph TB
    subgraph "VPC"
        subgraph "パブリックサブネット"
            Web[Webサーバー]
            Bastion[踏み台サーバー]
        end
        subgraph "プライベートサブネット"
            App[アプリサーバー]
            DB[(データベース)]
        end
        IGW[インターネット<br/>ゲートウェイ]
        NAT[NAT<br/>ゲートウェイ]
    end
    
    Internet((インターネット)) <--> IGW
    IGW <--> Web
    IGW <--> Bastion
    Web --> App
    Bastion --> App
    App --> DB
    App --> NAT
    NAT --> IGW

パブリックサブネット

パブリックサブネットは、インターネットゲートウェイへのルートを持ち、インターネットと直接通信できるサブネットです。以下のリソースを配置します。

• インターネットからアクセスされるWebサーバー
• Application Load Balancer（ALB）
• 踏み台サーバー（Bastion Host）
• NAT Gateway

パブリックサブネットに配置するインスタンスには、パブリックIPアドレスまたはElastic IPを割り当てる必要があります。

プライベートサブネット

プライベートサブネットは、インターネットゲートウェイへの直接ルートを持たないサブネットです。インターネットから直接アクセスできないため、セキュリティが強化されます。以下のリソースを配置します。

• アプリケーションサーバー
• データベースサーバー（RDS）
• バッチ処理サーバー

プライベートサブネット内のリソースがインターネットにアクセスする必要がある場合（OSパッチのダウンロードなど）は、NAT Gatewayを経由します。

パブリックサブネットとプライベートサブネットの違い

両者の違いを表にまとめます。

マルチAZ構成の設計

可用性の高いシステムを構築するためには、複数のアベイラビリティゾーン（AZ）にリソースを分散配置するマルチAZ構成が重要です。

マルチAZ構成の必要性

単一のAZにすべてのリソースを配置した場合、そのAZで障害が発生するとシステム全体が停止します。マルチAZ構成にすることで、1つのAZに障害が発生しても、別のAZでサービスを継続できます。

graph TB
    subgraph "VPC (10.0.0.0/16)"
        subgraph "AZ-a"
            ALB1[ALB]
            Web1[Web]
            App1[App]
            DB1[(Primary DB)]
        end
        subgraph "AZ-c"
            ALB2[ALB]
            Web2[Web]
            App2[App]
            DB2[(Standby DB)]
        end
    end
    
    Users((ユーザー)) --> ALB1
    Users --> ALB2
    Web1 --> App1
    Web2 --> App2
    App1 --> DB1
    App2 --> DB1
    DB1 -.->|同期レプリケーション| DB2

マルチAZ構成のベストプラクティス

マルチAZ構成を設計する際のベストプラクティスを紹介します。

2AZ以上に分散する

最低でも2つのAZ、可能であれば3つ以上のAZにリソースを分散配置します。東京リージョンでは4つのAZが利用可能です。

各AZで同じ構成にする

各AZには同じサブネット構成（パブリック/プライベート）を作成し、同じ種類のリソースを配置します。これにより、AZ間でのフェイルオーバーがスムーズになります。

ロードバランサーを活用する

Application Load Balancer（ALB）やNetwork Load Balancer（NLB）を使用して、複数AZのインスタンスにトラフィックを分散します。ロードバランサー自体もマルチAZで動作します。

RDSのマルチAZ配置を有効化する

Amazon RDSでは、マルチAZ配置を有効にすることで、プライマリDBとは別のAZにスタンバイDBが自動的に作成されます。プライマリDBに障害が発生すると、自動的にスタンバイDBにフェイルオーバーします。

VPCの作成手順

AWSマネジメントコンソールからVPCを作成する手順を説明します。

コンソールからVPCを作成する

1. AWSマネジメントコンソールで「VPC」サービスを開きます
2. 左側のナビゲーションペインで「VPC」を選択し、「VPCを作成」をクリックします
3. 「VPCなど」を選択すると、VPCと関連リソースをまとめて作成できます
4. 以下の設定を行います

5. 「VPCを作成」をクリックします

この設定により、VPC、サブネット、インターネットゲートウェイ、NAT Gateway、ルートテーブルが自動的に作成されます。

AWS CLIでVPCを作成する

AWS CLIを使用してVPCを作成することもできます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# VPCの作成
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=production-vpc}]'

# サブネットの作成（パブリック）
aws ec2 create-subnet \
  --vpc-id vpc-xxxxxxxxx \
  --cidr-block 10.0.1.0/24 \
  --availability-zone ap-northeast-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=production-public-1a}]'

# サブネットの作成（プライベート）
aws ec2 create-subnet \
  --vpc-id vpc-xxxxxxxxx \
  --cidr-block 10.0.11.0/24 \
  --availability-zone ap-northeast-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=production-private-1a}]'

ルートテーブルの設定

ルートテーブルは、サブネット内のトラフィックがどこに送信されるかを定義します。各サブネットは1つのルートテーブルに関連付けられます。

ルートテーブルの基本

ルートテーブルには「ルート」と呼ばれるルーティングルールが含まれています。各ルートは、宛先CIDRとターゲット（次のホップ）を指定します。

パブリックサブネットのルートテーブル例:
宛先               ターゲット
10.0.0.0/16       local（VPC内通信）
0.0.0.0/0         igw-xxxxxxxx（インターネットゲートウェイ）

プライベートサブネットのルートテーブル例:
宛先               ターゲット
10.0.0.0/16       local（VPC内通信）
0.0.0.0/0         nat-xxxxxxxx（NAT Gateway）

パブリックサブネットとプライベートサブネットの違いは、0.0.0.0/0（デフォルトルート）のターゲットがインターネットゲートウェイかNAT Gatewayかという点にあります。

メインルートテーブルとカスタムルートテーブル

VPCには「メインルートテーブル」が存在し、明示的にルートテーブルを関連付けていないサブネットはメインルートテーブルを使用します。セキュリティのベストプラクティスとして、以下を推奨します。

• メインルートテーブルはデフォルトのまま（VPC内通信のみ）にする
• パブリックサブネット用、プライベートサブネット用にカスタムルートテーブルを作成する
• 各サブネットに適切なカスタムルートテーブルを明示的に関連付ける

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

実務でVPCを設計する際のベストプラクティスをまとめます。

IPアドレス設計

• 将来の拡張を見越して十分な大きさのCIDRブロックを確保する
• 他のVPCやオンプレミス環境とのCIDR重複を避ける
• サブネット分割を計画し、用途ごとにアドレス範囲を整理する
• 命名規則を統一し、管理しやすくする

セキュリティ設計

• インターネットからアクセスが不要なリソースはプライベートサブネットに配置する
• データベースは必ずプライベートサブネットに配置する
• 踏み台サーバーまたはSession Managerを使用してプライベートサブネットにアクセスする
• セキュリティグループとネットワークACLで多層防御を実装する

可用性設計

• 本番環境では必ずマルチAZ構成にする
• 各AZに同じ構成のサブネットを作成する
• ロードバランサーを使用してトラフィックを分散する
• NAT Gatewayは各AZに1つずつ配置して単一障害点を排除する

まとめ

本記事では、AWS VPCの基本概念から実践的な設計方法までを解説しました。

• VPCはAWSクラウド内に構築する論理的に隔離された仮想ネットワーク
• CIDRブロックの設計では、将来の拡張性と他ネットワークとの重複回避を考慮する
• パブリックサブネットとプライベートサブネットを適切に使い分けてセキュリティを確保する
• マルチAZ構成により高可用性を実現する
• ルートテーブルでトラフィックの経路を制御する

次回の記事では、VPCのセキュリティを強化するセキュリティグループとネットワークACLについて詳しく解説します。

参考リンク

• Amazon VPC ユーザーガイド
• VPC CIDR ブロック
• サブネットの設定
• ルートテーブルを設定する
• RFC 1918 - Address Allocation for Private Internets