AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成

AWSでシステムを構築する際、最初に設計しなければならないのがネットワークです。VPC（Virtual Private Cloud）の設計を間違えると、後からの修正に膨大な工数がかかります。

この記事では、AWS VPCの基本概念からサブネット設計、セキュリティグループの設定、そして実践的なネットワーク構成パターンまでを体系的に解説します。IT担当者やインフラエンジニアが、自社のAWS環境を安全かつ効率的に設計するための実践ガイドです。

AWS VPCとは？ネットワーク設計の基本を理解する

AWS VPC（Virtual Private Cloud）は、AWS上に作成する仮想的なプライベートネットワークです。オンプレミスのデータセンターでネットワークを構築するのと同じように、IPアドレス範囲の決定、サブネットの作成、ルーティングの設定、セキュリティの制御を行います。

VPCを使う最大のメリットは、論理的に隔離されたネットワーク空間を持てることです。他のAWSアカウントのネットワークとは完全に分離されているため、自社のリソースを安全に運用できます。

VPCの基本構成要素

VPCを理解するために、まずは基本構成要素を押さえましょう。

構成要素	役割	設定例
VPC	仮想ネットワークの最上位コンテナ	10.0.0.0/16
サブネット	VPC内のIPアドレス範囲の区分	10.0.1.0/24
インターネットゲートウェイ	VPCとインターネットの接続点	VPCに1つ
NATゲートウェイ	プライベートサブネットからの外部通信	パブリックサブネットに配置
ルートテーブル	ネットワークトラフィックの経路制御	サブネットごとに設定
セキュリティグループ	インスタンスレベルのファイアウォール	インバウンド/アウトバウンドルール
ネットワークACL	サブネットレベルのファイアウォール	許可/拒否ルール

CIDRブロックの基礎知識

VPCを作成する際に最初に決めるのがCIDRブロック（Classless Inter-Domain Routing）です。CIDRブロックはVPC全体で使えるIPアドレスの範囲を定義します。

例えば10.0.0.0/16を指定すると、10.0.0.0から10.0.255.255までの65,536個のIPアドレスが使えます。/16の数字が大きいほど使えるIPアドレスは少なくなります。

• /16：65,536アドレス（推奨：大規模システム）
• /20：4,096アドレス（中規模システム）
• /24：256アドレス（小規模システム）

重要なポイントとして、VPCのCIDRブロックは後から拡張は可能ですが、縮小はできません。また、オンプレミスネットワークや他のVPCとの接続を将来的に考えている場合は、IPアドレス範囲が重複しないように設計する必要があります。

サブネット設計のベストプラクティス

サブネットはVPCを論理的に区分する単位です。適切なサブネット設計は、セキュリティと運用効率の両面で重要です。

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

AWSのサブネットは、大きく2種類に分けられます。

パブリックサブネットは、インターネットゲートウェイへのルートを持つサブネットです。Webサーバーやロードバランサー（ALB）など、インターネットからアクセスされるリソースを配置します。

プライベートサブネットは、インターネットへの直接ルートを持たないサブネットです。データベースサーバーやアプリケーションサーバーなど、外部から直接アクセスさせたくないリソースを配置します。

プライベートサブネット内のリソースが外部APIの呼び出しやパッケージのダウンロードなど、インターネットへのアウトバウンド通信が必要な場合はNATゲートウェイを経由させます。

マルチAZ構成によるサブネット分割

AWSの各リージョンには複数のアベイラビリティゾーン（AZ）があります。高可用性を実現するために、最低2つのAZにまたがるサブネット構成が推奨されます。

東京リージョン（ap-northeast-1）での典型的なサブネット設計例を示します。

VPC: 10.0.0.0/16

パブリックサブネット（AZ-a）: 10.0.1.0/24  → ALB, NAT Gateway
パブリックサブネット（AZ-c）: 10.0.2.0/24  → ALB

プライベートサブネット - App（AZ-a）: 10.0.11.0/24  → EC2, ECS
プライベートサブネット - App（AZ-c）: 10.0.12.0/24  → EC2, ECS

プライベートサブネット - DB（AZ-a）: 10.0.21.0/24  → RDS Primary
プライベートサブネット - DB（AZ-c）: 10.0.22.0/24  → RDS Standby

このように用途（パブリック / アプリケーション / データベース）とAZの組み合わせで分割することで、障害時の影響範囲を限定しつつ、セキュリティレイヤーを明確に分離できます。

セキュリティグループの設計と実践ルール

セキュリティグループは、EC2インスタンスやRDSなどのリソースに対する仮想ファイアウォールです。インバウンド（受信）とアウトバウンド（送信）のトラフィックを制御します。

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

セキュリティグループには以下の特徴があります。

• ステートフル：許可したインバウンド通信の戻りトラフィックは自動で許可される
• 許可ルールのみ：明示的な拒否ルールは設定できない（デフォルトで全拒否）
• 複数アタッチ可能：1つのリソースに複数のセキュリティグループを付与できる
• セキュリティグループ間参照：送信元にIPアドレスではなくセキュリティグループIDを指定可能

レイヤー別セキュリティグループ設計

3層アーキテクチャの場合、以下のようなセキュリティグループ設計が推奨されます。

ALB用セキュリティグループ（sg-alb）：

方向	プロトコル	ポート	送信元/送信先
インバウンド	HTTPS	443	0.0.0.0/0
インバウンド	HTTP	80	0.0.0.0/0
アウトバウンド	TCP	8080	sg-app

アプリケーション用セキュリティグループ（sg-app）：

方向	プロトコル	ポート	送信元/送信先
インバウンド	TCP	8080	sg-alb
アウトバウンド	TCP	3306	sg-db
アウトバウンド	HTTPS	443	0.0.0.0/0

データベース用セキュリティグループ（sg-db）：

方向	プロトコル	ポート	送信元/送信先
インバウンド	TCP	3306	sg-app

ポイントは、送信元にIPアドレスではなくセキュリティグループIDを指定している点です。これにより、アプリケーションサーバーのIPアドレスが変わっても、セキュリティグループの設定を変更する必要がありません。

ネットワークACLとセキュリティグループの使い分け

AWSでは、ネットワークACL（NACL）とセキュリティグループの2層でセキュリティを制御できます。両者の違いを正しく理解し、適切に使い分けることが重要です。

特性	セキュリティグループ	ネットワークACL
適用レベル	インスタンス（ENI）	サブネット
ステート	ステートフル	ステートレス
ルール種別	許可のみ	許可と拒否
評価順序	すべてのルールを評価	番号順に評価（最初に一致したルール）
デフォルト	すべて拒否	すべて許可

実践的な使い分けとしては、セキュリティグループをメインのファイアウォールとして使い、ネットワークACLは特定のIPアドレスからのアクセスを拒否する場合や、サブネット全体に対する追加の防御層として使うのが一般的です。

例えば、不正アクセスが検知された特定のIPアドレスをブロックしたい場合、ネットワークACLの拒否ルールが有効です。セキュリティグループでは拒否ルールを設定できないため、このようなケースではネットワークACLが必要になります。

NATゲートウェイとVPCエンドポイントの活用

プライベートサブネット内のリソースが外部と通信する方法には、NATゲートウェイとVPCエンドポイントがあります。コストとセキュリティの両面から、適切な選択が求められます。

NATゲートウェイの配置と冗長化

NATゲートウェイは、プライベートサブネット内のリソースがインターネットへアウトバウンド通信を行うために使います。パブリックサブネットに配置し、プライベートサブネットのルートテーブルからNATゲートウェイへのルートを設定します。

本番環境では各AZにNATゲートウェイを配置することが推奨されます。1つのAZにしか配置しない場合、そのAZに障害が発生すると他のAZのリソースも外部通信ができなくなります。

ただし、NATゲートウェイは時間課金とデータ転送量課金が発生するため、コストには注意が必要です。開発環境では1つのAZにのみ配置してコストを抑える、という判断も現実的です。コスト管理についてはAWS Cost Explorerでコスト可視化する方法も参考にしてください。

VPCエンドポイントでコスト削減

AWSサービス（S3、DynamoDB、CloudWatchなど）へのアクセスは、NATゲートウェイを経由する代わりにVPCエンドポイントを使うことで、データ転送コストを削減しつつセキュリティも向上させられます。

VPCエンドポイントには2種類あります。

• ゲートウェイ型：S3とDynamoDBのみ対応。無料で利用可能
• インターフェース型（PrivateLink）：多くのAWSサービスに対応。時間課金あり

特にS3ゲートウェイエンドポイントは無料で使えるため、VPCを作成したら必ず設定しておくことをお勧めします。AWS S3の実践ガイドでS3の活用方法も確認しておくと良いでしょう。

実践的なVPCネットワーク構成パターン

ここでは、中小企業のWebサービス向けに実用的なVPC構成パターンを紹介します。

パターン1：シンプルなWebアプリケーション構成

小規模なWebアプリケーションに適した構成です。

インターネット
    │
    ▼
インターネットゲートウェイ
    │
    ▼
┌─パブリックサブネット──────┐
│  ALB (Application Load    │
│  Balancer)                │
│  NAT Gateway              │
└───────────────────────────┘
    │
    ▼
┌─プライベートサブネット(App)┐
│  ECS Fargate / EC2        │
│  (アプリケーション)         │
└───────────────────────────┘
    │
    ▼
┌─プライベートサブネット(DB)─┐
│  RDS (データベース)         │
│  ElastiCache              │
└───────────────────────────┘

この構成のポイントは以下の通りです。

• ALBをパブリックサブネットに、アプリとDBをプライベートサブネットに配置
• 各レイヤーをマルチAZで冗長化
• セキュリティグループの連鎖参照で通信を制御

AWS ECS/Fargateの導入ガイドやAWS RDSデータベースガイドと合わせて読むと、各コンポーネントの詳細設定も理解できます。

パターン2：マルチ環境（本番・ステージング・開発）構成

環境ごとにVPCを分離する構成です。

本番VPC:       10.0.0.0/16
ステージングVPC: 10.1.0.0/16
開発VPC:       10.2.0.0/16

各VPCはVPCピアリングまたはTransit Gatewayで接続します。環境ごとにVPCを分けることで、開発環境の設定ミスが本番環境に影響を与えるリスクを排除できます。

Transit Gatewayは複数VPCの接続を一元管理できるため、3つ以上のVPCを接続する場合はVPCピアリングよりも管理が容易です。

VPC設計をコード化して管理する

VPCの設計が完了したら、Infrastructure as Code（IaC）で構成をコード管理することを強く推奨します。手動でのコンソール操作は、設定の再現性が低く、ヒューマンエラーの原因にもなります。

TerraformによるVPC定義の例

Terraformの基礎を押さえた上で、VPCリソースの定義例を見てみましょう。

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "main-vpc"
    Environment = "production"
  }
}

resource "aws_subnet" "public_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"

  tags = {
    Name = "public-subnet-a"
    Type = "public"
  }
}

resource "aws_subnet" "private_app_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = "ap-northeast-1a"

  tags = {
    Name = "private-app-subnet-a"
    Type = "private"
  }
}

resource "aws_security_group" "app" {
  name_prefix = "app-sg-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

IaCでVPCを管理することで、環境の複製が容易になります。本番環境と同じ構成をステージング環境にもすぐに再現できるため、テスト環境の整備にかかる時間を大幅に短縮できます。

VPC設計で陥りがちなミスと対策

最後に、VPC設計でよくある失敗パターンとその対策をまとめます。

ミス1：CIDRブロックの設計不足

VPCのCIDRブロックを/24など小さく設定してしまい、後からリソースが増えた際にIPアドレスが不足するケースがあります。将来の拡張を見越して/16で確保しておくのが安全です。追加CIDRの割り当ても可能ですが、管理が複雑になります。

ミス2：セキュリティグループの過剰許可

開発時に0.0.0.0/0で全ポートを開放し、そのまま本番環境に持ち込んでしまうケースです。最小権限の原則に従い、必要なポートと送信元のみを許可してください。AWS IAMのベストプラクティスと同じ考え方がネットワークにも適用されます。

ミス3：単一AZ構成での運用

コスト削減のために単一AZで構成すると、AZ障害時にサービス全体が停止します。本番環境では必ずマルチAZ構成を採用しましょう。

ミス4：フローログの未設定

VPCフローログを有効にしていないと、ネットワークの問題が発生した際に原因調査ができません。フローログをCloudWatch LogsまたはS3に出力する設定は、VPC作成直後に必ず行うべきです。CloudWatchでの監視設定ガイドでログ活用の詳細を確認できます。

ミス5：DNS設定の見落とし

VPCのenableDnsSupportとenableDnsHostnamesを有効にしていないと、プライベートホストゾーン（Route 53）やVPCエンドポイントが正しく機能しません。VPC作成時にこれらのオプションを必ず有効化してください。

まとめ：段階的にVPC設計を最適化しよう

AWS VPCのネットワーク設計は、システム全体の安全性と拡張性の土台となります。この記事で解説した内容を振り返ります。

• CIDRブロックは余裕を持って設計し、将来の拡張に備える
• サブネットはパブリック/プライベートを分離し、マルチAZで冗長化する
• セキュリティグループは最小権限の原則で設計し、セキュリティグループ間参照を活用する
• NATゲートウェイは本番環境でAZごとに配置し、VPCエンドポイントでコストを削減する
• IaCで管理して再現性を確保する

まずは開発環境で小さなVPCを構築し、運用しながら設計を洗練させていくアプローチが現実的です。AWS Well-Architected Frameworkの設計原則も参照しながら、自社に最適なネットワーク構成を見つけてください。