パブリック/プライベートサブネットの設計と使い分け

2026年9月24日 2026年9月24日

akinori

概要

AWS で VPC を設計するとき、最初に迷うのが「サブネットをどう分けるか」です。とくに パブリックサブネット と プライベートサブネット の違いと使い分けは、セキュリティにもコストにも直結する基本設計です。この記事では、両者の違いを「ルートテーブルの中身」というレベルまで掘り下げつつ、実際にどうリソースを配置するのかを入門者向けに整理します。

パブリックとプライベートを分けるものは何か

まず誤解しやすいポイントから。サブネット自体に「パブリック」「プライベート」という属性フラグがあるわけではありません。

サブネットが「パブリック」になる条件はただ一つです。それは、そのサブネットに紐づくルートテーブルが、インターネットゲートウェイ（IGW）への経路を持っているかどうかです。

IGW への 0.0.0.0/0 経路を持つ → パブリックサブネット
IGW への経路を 持たない → プライベートサブネット

つまり「パブリック/プライベート」は物理的な区別ではなく、ルーティング設計の結果としての呼び名です。ここが腹落ちすると、以降の設計判断がぶれなくなります。

ルートテーブルの中身を比較する

パブリックサブネットのルートテーブル（イメージ）:

宛先 (Destination)	ターゲット (Target)
`10.0.0.0/16`	`local`（VPC内通信）
`0.0.0.0/0`	`igw-xxxx`（インターネットゲートウェイ）

プライベートサブネットのルートテーブル（イメージ）:

宛先 (Destination)	ターゲット (Target)
`10.0.0.0/16`	`local`（VPC内通信）
`0.0.0.0/0`	`nat-xxxx`（NAT ゲートウェイ）

違いは 0.0.0.0/0 の向き先だけです。IGW を向いていれば外から入れる（＝パブリック）、NAT を向いていれば「出られるが入られない」（＝プライベート）になります。

パブリックIPだけでは外部通信は成立しない

もう一つの落とし穴。EC2 にパブリック IP を割り当てても、それだけではインターネットと通信できません。次の 3点セット がそろって初めて疎通します。

サブネットのルートテーブルに IGW への経路がある
インスタンスにパブリック IP（または EIP）が付いている
セキュリティグループ／ネットワーク ACL で該当通信が許可されている

「パブリック IP を付けたのに繋がらない」の大半は、1 のルート不足が原因です。

何をどこに置くか（配置の原則）

原則はシンプルです。インターネットから直接アクセスされる必要があるものだけをパブリックに置く。それ以外は全部プライベート。

典型的な3層構成での配置例:

リソース	配置	理由
ALB（ロードバランサー）	パブリック	外部からのHTTP(S)受け口
Webサーバー / APサーバー	プライベート	外部公開せずALB経由でのみ受ける
RDS / Aurora	プライベート	DBは絶対に外部公開しない
NATゲートウェイ	パブリック	プライベートからの外向き通信の出口
Bastion（踏み台）	パブリック（または SSM で不要化）	運用アクセスの入口

ポイントは、アプリケーションサーバーやDBをパブリックに置かないことです。外部からの受け口は ALB に集約し、その背後は全てプライベートに閉じ込めます。これだけで攻撃面（アタックサーフェス）が大きく減ります。

NATゲートウェイ — プライベートの「出口」

プライベートサブネットのサーバーも、外向きの通信は必要です（OSアップデート、外部APIコール、パッケージ取得など）。このとき使うのが NATゲートウェイ です。

NATゲートウェイは パブリックサブネット に置く
プライベートサブネットのルートテーブルで 0.0.0.0/0 を NAT に向ける
「内 → 外」は通すが、「外 → 内」は通さない（＝プライベート性を維持したまま外に出られる）

NATはコスト注意ポイント

入門段階で必ず知っておきたいのが、NATゲートウェイは無料ではないことです。起動しているだけで時間課金が発生し、通過データ量にも課金されます。

そのため、可用性重視なら AZ ごとに NAT を置きますが、コスト重視の検証環境では NAT を1つに集約する、あるいは VPCエンドポイント を使って NAT を経由せず AWS サービス（S3, DynamoDB など）へ直接アクセスさせる、といった最適化が定石になります。

サブネットのCIDR設計

サブネットに割り当てる IP レンジ（CIDR）は後から広げにくいので、最初に少し余裕をもって切ります。VPC を 10.0.0.0/16 とした場合の一例:

サブネット	CIDR	AZ	種別
public-1a	`10.0.0.0/24`	ap-northeast-1a	パブリック
public-1c	`10.0.1.0/24`	ap-northeast-1c	パブリック
private-app-1a	`10.0.10.0/24`	ap-northeast-1a	プライベート
private-app-1c	`10.0.11.0/24`	ap-northeast-1c	プライベート
private-db-1a	`10.0.20.0/24`	ap-northeast-1a	プライベート
private-db-1c	`10.0.21.0/24`	ap-northeast-1c	プライベート

補足: AWS では各サブネットで先頭4つ＋末尾1つの計5アドレスが予約されるため、/24（256個）でも実際に使えるのは251個です。細かく切りすぎると足りなくなるので注意します。

実装例（構成イメージ）

Terraform でのイメージ（抜粋・概念確認用）:

# パブリックサブネット
resource "aws_subnet" "public_1a" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.0.0/24"
  availability_zone       = "ap-northeast-1a"
  map_public_ip_on_launch = true   # 起動時に自動でパブリックIP付与
  tags = { Name = "public-1a" }
}

# パブリック用ルートテーブル（IGWへ）
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
}

resource "aws_route_table_association" "public_1a" {
  subnet_id      = aws_subnet.public_1a.id
  route_table_id = aws_route_table.public.id
}

# プライベートサブネット
resource "aws_subnet" "private_app_1a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = "ap-northeast-1a"
  tags = { Name = "private-app-1a" }
}

# プライベート用ルートテーブル（NATへ）
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main.id
  }
}

map_public_ip_on_launch = true を付けると、そのサブネットで起動したインスタンスに自動でパブリック IP が振られます。パブリックサブネット用の設定です。

確認方法

設計が意図どおりか、次の観点で確認します。

ルートテーブルの確認 — 対象サブネットに紐づくルートテーブルを開き、0.0.0.0/0 の向き先が IGW か NAT かを見る
疎通確認（プライベート側） — プライベートのサーバーから curl https://example.com などで外向き通信が通ること（NAT経由）、外部からそのサーバーへ直接アクセスできないこと
DBの隔離確認 — RDS のセキュリティグループが、アプリ層のSGからのみ許可されており、パブリックからの経路がないこと