AWS VPCとは何か（基本概念）

AWS VPC（Virtual Private Cloud）は、AWSクラウド上に作成する論理的な仮想ネットワーク空間です。
物理的なデータセンターでいう「社内LAN」を、クラウド上に丸ごと再現するイメージを持つと分かりやすいです。

VPCを使うと、以下のことが実現できます。
・IPアドレスの範囲を自分で決められる（CIDRブロック）
・インターネットに公開するゾーンと非公開ゾーンを分けられる（パブリック・プライベートサブネット）
・どのIPからどのポートへのアクセスを許可するか細かく制御できる（セキュリティグループ）
・複数のアベイラビリティゾーン（AZ）にまたがる冗長構成を組める（マルチAZ）

AWSの多くのサービス（EC2・RDS・ELBなど）はVPC内に配置するため、
aws vpc 設計の基礎を押さえることが、AWSの実践スキル全体に直結します。

VPCの主な構成要素

VPCを構成する要素を整理しておきましょう。

VPC設計の基本：CIDRブロックの考え方

VPCを作成する際に最初に決めるのが「CIDRブロック」です。
CIDR（Classless Inter-Domain Routing）は、IPアドレスの範囲を「アドレス/プレフィックス長」で表す記法です。

例えば 10.0.0.0/16 と指定すると、10.0.0.0～10.0.255.255 の65,536個のIPアドレスを使えます。
AWSでは /16（最大65,536アドレス）から /28（最小16アドレス）まで指定できます。

1. CIDRブロックの設計指針

実務でよく使われるVPC CIDRの目安を示します。

後からCIDRブロックを変更するのは非常に困難なため、最初に「少し大きめ」に設定しておくことが鉄則です。
本番環境では 10.0.0.0/16 を基本とし、サブネットに /24 （256アドレス）を割り当てる設計がよく使われます。

2. プライベートIPアドレス範囲（RFC 1918）を使う理由

VPC内では必ずプライベートIPアドレス範囲を使います。
インターネットには直接ルーティングされない専用の範囲であり、安全にVPC内部で自由にIPを割り振れます。

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

VPCの設計で最も重要な概念が「パブリックサブネット」と「プライベートサブネット」の使い分けです。
この2種類を適切に分けることで、インターネットに公開すべきリソースと非公開にすべきリソースを安全に管理できます。

1. パブリックサブネットの役割

パブリックサブネットは、インターネットゲートウェイ（IGW）へのルートを持ち、
インターネットと直接通信できるサブネットです。

典型的な用途は以下の通りです。
・Webサーバー（EC2インスタンス）
・ロードバランサー（ALB/NLB）
・踏み台サーバー（Bastion Host）
・NATゲートウェイ本体（後述）

# ルートテーブルに以下のルートを追加する
# 送信先: 0.0.0.0/0  →  ターゲット: インターネットゲートウェイ（igw-xxxxxxxxx）
# これによりパブリックサブネット内のインスタンスはインターネットと通信可能になる

# また、EC2インスタンスには「パブリックIPの自動割り当て」を有効にする
# または Elastic IP（固定パブリックIP）を割り当てる

2. プライベートサブネットの役割

プライベートサブネットは、IGWへの直接ルートを持たず、インターネットから直接アクセスできないサブネットです。

典型的な用途は以下の通りです。
・データベースサーバー（RDS）
・アプリケーションサーバー（APIサーバーなど）
・バッチ処理サーバー
・機密データを扱うサービス

プライベートサブネットに置いたリソースは直接インターネットからアクセスできないため、セキュリティが大幅に向上します。
ただしソフトウェアのアップデートなどでインターネットへのアウトバウンド通信が必要な場合は、NATゲートウェイを使います（後述）。

3. CIDRブロックの分割例

VPCを 10.0.0.0/16 で作った場合のサブネット割り当て例です。

パブリックは 10.0.1.x～10.0.9.x、プライベートは 10.0.10.x 以降のような「番号で種別を見分けやすい」設計にしておくと、
後から見返したときに混乱しにくくなります。

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

VPCのセキュリティ制御は「セキュリティグループ」と「ネットワークACL（NACL）」の2層構造です。
この2つは似て非なるものであり、役割を理解して使い分けることが大切です。

1. セキュリティグループ（Security Group）

セキュリティグループは、EC2インスタンスなどのリソースに直接アタッチするファイアウォールです。

主な特徴は以下の通りです。
・ステートフル：インバウンドで許可した通信のレスポンスは自動的に許可される
・許可ルールのみ：「拒否」のルールは設定できない（ルールにないものは自動的に拒否）
・インスタンス単位：1つのインスタンスに複数のセキュリティグループを適用可能

# インバウンドルール（受信許可）設定例（Webサーバー用セキュリティグループ）
# ルール1: HTTP (TCP 80)   送信元: 0.0.0.0/0  インターネットからのアクセスを許可
# ルール2: HTTPS (TCP 443) 送信元: 0.0.0.0/0  HTTPS接続を許可
# ルール3: SSH (TCP 22)    送信元: 203.0.113.50/32  自分のPCのIPアドレスのみ許可

# アウトバウンドルール（送信許可）
# デフォルト: すべてのアウトバウンドを許可（0.0.0.0/0）
# ステートフルのため、インバウンドで受けた通信のレスポンスは別途許可不要

2. ネットワークACL（NACL）

ネットワークACLはサブネット全体に適用するファイアウォールです。セキュリティグループとの違いをまとめます。

実務上はセキュリティグループを主軸に設計し、NACLは追加の防御層として使うケースが多いです。
特定のIPアドレスを明示的にブロックしたい場合（DDoS対策など）は、NACLの「拒否ルール」が有効です。

NACLはステートレスのため、インバウンドを許可した通信のレスポンスについても
アウトバウンドのルールで明示的に許可する必要があります。
エフェメラルポート（一般的に1024～65535）を戻り通信用に開ける必要がある点に注意してください。

3. セキュリティグループの設計ベストプラクティス

セキュリティグループを設計する際の実践的なポイントをまとめます。
・最小権限の原則：必要なポートのみ、必要なソースIPのみを許可する
・SSH（22番ポート）は必ず特定のIPに制限：0.0.0.0/0（全世界）に開放しない
・セキュリティグループ間参照を使う：WebサーバーからDBサーバーへのアクセスは、IPではなくWebサーバー用SGを送信元に指定する
・名前・説明文を丁寧に書く：後から見てどのリソース用か分かるように管理する

# DBサーバーのセキュリティグループのインバウンドルール
# ポート: MySQL/Aurora (TCP 3306)
# 送信元: sg-0123456789abcdef0 (Webサーバー用セキュリティグループのID)
# →「WebサーバーのSGがアタッチされたインスタンスからのみ3306番を許可」という意味
# IPアドレスではなくSGを参照することで、インスタンスのIP変動に依存しない柔軟な設計になる

NATゲートウェイの役割と設計パターン

プライベートサブネット内のEC2インスタンスは、直接インターネットと通信できません。
しかしソフトウェアの更新（yum/apt）や外部APIへのアクセスなど、インターネットへのアウトバウンド通信が必要な場面は多くあります。
このときに使うのが「NATゲートウェイ（NAT Gateway）」です。

1. NATゲートウェイの仕組み

NAT（Network Address Translation）ゲートウェイは、プライベートIPアドレスをパブリックIPアドレスに変換して
インターネットとの通信を中継するサービスです。

# 通信フロー（プライベートサブネットからインターネットへ）
# プライベートサブネット内のEC2（10.0.11.10）
#   → NATゲートウェイ（パブリックサブネット・10.0.1.x）
#     → インターネットゲートウェイ（IGW）
#       → インターネット（yumリポジトリ等）

# 設定のポイント:
# 1. NATゲートウェイ自体はパブリックサブネットに置く（必須）
# 2. NATゲートウェイにはElastic IP（固定パブリックIP）を割り当てる
# 3. プライベートサブネットのルートテーブルに追加するルート:
#    送信先: 0.0.0.0/0  →  ターゲット: nat-xxxxxxxxxxxxxxxxx

2. NATゲートウェイの設定手順（概要）

AWSコンソールでの設定手順を示します。

# Step 1: Elastic IPを取得する
# VPCコンソール → Elastic IP → 新しいElastic IPの割り当て

# Step 2: NATゲートウェイを作成する
# VPCコンソール → NATゲートウェイ → NATゲートウェイを作成
# - サブネット: パブリックサブネットを選択（プライベートサブネットではない）
# - 接続タイプ: パブリック
# - Elastic IP割り当てID: Step1で取得したEIPを選択

# Step 3: プライベートサブネットのルートテーブルを更新する
# VPCコンソール → ルートテーブル → プライベートサブネット用ルートテーブルを選択
# → ルートを編集 → ルートの追加
# 送信先: 0.0.0.0/0  /  ターゲット: NATゲートウェイ（nat-xxxxxxxxxxxxxxxxx）

3. NATゲートウェイのコスト注意点

NATゲートウェイは有料サービスであり、時間課金（約0.062 USD/時間）＋データ転送量課金がかかります。
開発環境や検証環境では、コスト削減のためにNATゲートウェイの代わりに
「NATインスタンス（EC2インスタンスでNATを行う）」を使う選択肢もあります。
ただし可用性・運用負荷を考えると、本番環境ではNATゲートウェイを使うことを強くすすめます。

また、検証が終わったらNATゲートウェイを削除し、Elastic IPも解放しておくことも忘れずに。
削除し忘れると課金が続くため注意してください。

マルチAZ構成で可用性を高める

AWSではデータセンターのような物理施設を「アベイラビリティゾーン（AZ）」と呼びます。
東京リージョン（ap-northeast-1）には複数のAZがあり、それぞれが物理的に独立した電源・ネットワークを持ちます。

マルチAZ構成とは、複数のAZにサブネット・リソースを分散配置することで、
1つのAZに障害が発生しても残りのAZでシステムを継続稼動させる設計です。

1. マルチAZ構成の基本パターン

典型的なWebアプリケーションのマルチAZ構成を示します。

この構成のポイントは次の通りです。
・ALB（Application Load Balancer）を2つのAZのパブリックサブネットに配置し、Webサーバーへのトラフィックを分散
・Webサーバーは2つのAZのプライベートサブネットに配置（ALB配下でオートスケーリング対応）
・RDSはマルチAZで配置し、プライマリに障害発生時にスタンバイへ自動フェールオーバー

なお、NATゲートウェイは各AZに1つずつ配置するのがベストプラクティスです。
1つのAZにNATゲートウェイが集中すると、そのAZに障害が起きたときに
他のAZからのインターネットアウトバウンド通信も止まってしまいます。

2. 踏み台サーバー（Bastion Host）の配置

プライベートサブネット内のサーバーにSSHで接続する際は、「踏み台サーバー」を経由する方法が一般的です。
踏み台サーバーはパブリックサブネットに配置し、自分のPCから踏み台にSSH、踏み台からプライベートサブネット内のサーバーにSSHという2段階の接続を行います。

# 踏み台サーバー経由でプライベートEC2に接続するSSH設定例（~/.ssh/config）

Host bastion
  HostName 203.0.113.10        # 踏み台サーバーのElastic IP
  User ec2-user
  IdentityFile ~/.ssh/mykey.pem

Host private-web
  HostName 10.0.11.20          # プライベートサブネット内のEC2プライベートIP
  User ec2-user
  IdentityFile ~/.ssh/mykey.pem
  ProxyJump bastion

# 使い方（自分のPCから実行）
# $ ssh private-web
# → 踏み台（203.0.113.10）を経由してプライベートEC2（10.0.11.20）に接続される

踏み台サーバーのセキュリティグループは、
SSH（22番ポート）のインバウンドを「自分のPCのIPアドレス/32」のみに制限してください。
0.0.0.0/0に開放することは絶対に避けてください。

VPC設計でよくあるトラブルと対処法

aws vpc 設計を初めて行う際に、実際によく直面するトラブルと対処法をまとめます。

1. プライベートサブネットのEC2がインターネットに繋がらない

最も多いトラブルです。次の順番で確認してください。

# チェックリスト（上から順に確認する）

# 1. NATゲートウェイが「利用可能」状態か確認
# AWSコンソール → VPC → NATゲートウェイ → ステータスを確認

# 2. プライベートサブネットのルートテーブルを確認
# 「0.0.0.0/0 → nat-xxxxxxxxxx」のルートが存在するか確認

# 3. NATゲートウェイがパブリックサブネットに配置されているか確認
# NATゲートウェイがプライベートサブネットに作られているとアウトバウンドが通らない

# 4. EC2からpingで確認
# $ ping 8.8.8.8
# → 到達できれば外部通信OK。できなければルートテーブルかセキュリティグループを再確認

2. セキュリティグループの設定後もSSHで繋がらない

セキュリティグループでSSHを許可したのに接続できない場合、よくある原因は以下です。
・自分のPCのグローバルIPアドレスが変わっている：プロバイダの都合でIPが変動することがある。現在のIPを確認して再設定する
・踏み台サーバー経由が必要なのに直接接続しようとしている：プライベートサブネットのEC2にはパブリックIPがない
・キーペアが間違っている：EC2作成時に指定したキーペア（.pemファイル）と一致しているか確認する

# 自分のPCの現在のグローバルIPアドレスを確認する
$ curl -s https://checkip.amazonaws.com
203.0.113.50

# このIPアドレスをセキュリティグループのインバウンドルールに設定する
# 送信元: 203.0.113.50/32  ポート: SSH(22)

3. RDSにアプリケーションから繋がらない

アプリケーションサーバーからRDSへの接続が失敗する場合は、次の2点を確認してください。
・RDSのセキュリティグループ：アプリケーションサーバー用SGを送信元として3306番（MySQL）や5432番（PostgreSQL）が許可されているか
・サブネットグループ：RDSのサブネットグループにアプリケーションサーバーと同じVPCのサブネットが含まれているか

「セキュリティグループは設定した」という場合でも、送信元をIPではなくSGで指定しているかを確認してください。
間違えてアプリサーバーのIPを直接指定すると、IPが変動したときに接続が切れます。

まとめ：VPC設計のベストプラクティス

この記事で解説したaws vpc 設計のポイントをまとめます。

VPC設計は「最初に正しく作ると後が楽」なインフラの基盤です。
この記事の構成を参考に、まずは検証環境で一度手を動かしてみてください。
一度作ってみると、各コンポーネントの関係がぐっと分かりやすくなります。

より複雑な冗長設計（マルチリージョン・VPC Peering等）は
AWS冗長設計入門で解説しています。あわせてご覧ください。

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

無料マニュアルを受け取る

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

• 前のページへ：AWSでマルチAZ冗長構成を設計する方法｜止まらないシステムの作り方入門
• この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る