「検証のつもりで VPC を 10.0.0.0/24 で作ってしまいました。サーバーが増えてきたので、後から /16 に広げられますか」
「ネットワーク ACL でインバウンドの 3306 を許可したのに、DB につながりません。セキュリティグループのときは同じ設定でつながったのですが」
第5回では、S3・EBS・EFS などのストレージを見ました。第6回と第7回では、ネットワーキング（VPC・接続・DNS・配信）を扱います。オンプレでは、LAN のアドレスを決め、ルーターで経路を引き、ファイアウォールで通信を絞ってきました。AWS でも考えることは同じですが、それをVPC という仮想のネットワークの上で、設定画面と API で組み立てます。用語と制約がオンプレと少しずつ違うため、知らずに作ると、後から直せない設計になりがちです。
第6回では、VPC と CIDR の設計、サブネットとルートテーブル、インターネットゲートウェイと NAT ゲートウェイ、パブリック IP・Elastic IP・IPv6・ENI、セキュリティグループとネットワーク ACL を扱います。料金・上限は2026年9月時点の値で、料金は東京リージョンの例です。
VPC（Virtual Private Cloud）とは
VPC は AWS アカウント内に作る論理的に隔離された仮想ネットワークで、オンプレの「自社 LAN」に相当します。作成時に IPv4 の CIDR（例：10.0.0.0/16）を決め、その中をサブネットに分割し、ルートテーブル・ゲートウェイ・セキュリティグループで通信を制御します。
他の利用者の VPC とは、同じ物理基盤上にあっても完全に分離され、明示的に接続（ピアリング、Transit Gateway、VPN。第7回）しない限り一切通信できません。1 リージョンに複数の VPC を作れ（既定の上限 5、引き上げ可。2026年9月時点）、本番／検証／共通基盤のように分けるのが一般的です。アカウント作成時には「デフォルト VPC」（172.31.0.0/16、各 AZ に /20 のパブリックサブネット）が用意されており、検証には便利ですが、本番では CIDR を自分で設計した VPC を使います。
VPC は 1 リージョン内のもので、AZ（第2回）をまたぐことはできても、リージョンをまたぐことはできません。オンプレの L2／L3 の感覚と違い、VPC 内にブロードキャスト・マルチキャストは存在せず（Transit Gateway のマルチキャストを除く）、ARP も AWS が肩代わりします（ARP と GARP は連載「TCP/IP入門」第7回の「ARPの仕組み」「Gratuitous ARPとアドレスの重複」で扱っています）。VRRP や GARP に依存する HA 製品はそのままでは動きません。
- VPC＝アカウント内の隔離された仮想 LAN。CIDR を決めてサブネットに分割
- 1 リージョン内、複数 AZ にまたがる。リージョンはまたげない
- ブロードキャスト／マルチキャストなし。ARP・VRRP 前提の製品は要注意
CIDR 設計と制約
VPC で最初に決めるのが CIDR（アドレスの範囲）です。後から縮小・変更できないので、ここが VPC の設計でいちばん大事なところです。
- VPC の CIDR は /16（65,536）〜/28（16）。後から追加（セカンダリ CIDR）はできるが縮小・変更はできない。最初の設計が重要
- RFC 1918 のプライベートアドレス（10/8、172.16/12、192.168/16。連載「TCP/IP入門」第6回の「プライベートアドレスと共有アドレス」）を使う。オンプレや他 VPC と重複させない（重複すると VPN・ピアリングで経路が引けない）。全社で「VPC 用に 10.0.0.0/8 のうち /16 を割り当てる台帳」を持つのが定石（同じく第6回の「アドレス設計の考え方」）
- サブネットは VPC の CIDR 内で /16〜/28。各サブネットで 5 アドレスが予約される（
10.0.0.0/24なら .0＝ネットワーク、.1＝VPC ルーター、.2＝DNS リゾルバー、.3＝将来用、.255＝ブロードキャスト）。利用可能は 251 - サブネットは1 つの AZ に属する。AZ をまたぐサブネットは作れないので、「AZ ごとにパブリック／プライベートの組」を作る（3 AZ なら最低 6 サブネット）
- IPv6：AWS 提供の /56 を VPC に割り当て、サブネットは /64。パブリック IPv4 の有料化（この回の「パブリック IP・Elastic IP・IPv6」の節）を受けて、IPv6 のみのサブネットも選択肢になっている
- 例：
10.0.0.0/16を、10.0.0.0/24・10.0.1.0/24・10.0.2.0/24（パブリック、AZ a/c/d）、10.0.10.0/24〜（プライベート AP）、10.0.20.0/24〜（プライベート DB）のように用途×AZ で切る
冒頭の1つ目の相談がこれです。10.0.0.0/24 の VPC を /16 に「広げる」ことはできません。できるのは、重ならない別の範囲をセカンダリ CIDR として足すことだけです。アドレスが連続しなくなり、オンプレ側の経路やファイアウォールのルールも増えるので、最初から台帳で /16 を払い出しておくのが確実です。
オンプレのサブネットの計算（連載「TCP/IP入門」第5回の「サブネットの計算手順」）では、使えないのはネットワークアドレスとブロードキャストの2つでしたが、VPC では5つです。小さな /28 のサブネットでは 16 − 5 ＝ 11 しか使えないので注意します。
サブネットとルートテーブル
サブネットの「パブリック／プライベート」は AWS の設定項目ではなく、関連付けたルートテーブルにインターネットゲートウェイ（IGW）へのルートがあるかどうかで決まります。
ルートテーブルは「宛先 CIDR → ターゲット」の一覧で、VPC 内の CIDR 宛ては local（削除不可）が最初から入っており、そこに 0.0.0.0/0 → igw-xxx（インターネット）、0.0.0.0/0 → nat-xxx（NAT 経由）、192.168.0.0/16 → vgw-xxx（オンプレ）、10.1.0.0/16 → pcx-xxx（ピアリング）などを追加します。最長一致で評価される点は、オンプレのルーターの経路選択と同じです（連載「TCP/IP入門」第7回の「ルーティングテーブルと最長一致」）。
1 つのサブネットには 1 つのルートテーブルしか関連付けられませんが、1 つのルートテーブルは複数のサブネットで共有できます。明示的に関連付けないサブネットは VPC の「メインルートテーブル」に従うので、メインは IGW なしにしておき、パブリック用は別のテーブルを明示的に付ける運用が安全です。VPC のルーターは各サブネットの .1 に存在しますが、これは仮想的なもので、利用者が設定を触ることはできません。
- パブリック／プライベートの違い＝ルートテーブルに IGW への経路があるか
localは固定で、他は宛先→ターゲット（igw／nat／vgw／pcx／tgw）を追加- メインルートテーブルは IGW なし、パブリックは明示的に別テーブル
インターネットゲートウェイと NAT ゲートウェイ
VPC とインターネットの出入り口が IGW、プライベートサブネットからの「出口だけ」を作るのが NAT ゲートウェイです。オンプレのブロードバンドルーターの NAPT（連載「TCP/IP入門」第6回の「NATとNAPT」）が、2つの部品に分かれていると考えると分かりやすいでしょう。
- IGW：VPC とインターネットの境界。冗長・スケール済みで利用者は設定不要。VPC に 1 つだけアタッチする。パブリック IP を持つインスタンスの送受信両方向の 1:1 NAT を行う（インスタンスの OS はプライベート IP しか知らない）
- NAT ゲートウェイ：パブリックサブネットに置き、プライベートサブネットからのアウトバウンド専用の NAPT を行う。外からの接続開始は不可。EIP を 1 つ持つ
- NAT ゲートウェイは AZ 単位。1 つの AZ の NAT に他 AZ のサブネットも向けると、その AZ 障害で全 AZ の外向き通信が止まり、AZ 間転送料もかかる。本番は AZ ごとに NAT を置く
- 料金：時間（東京約 0.062 USD/h ≒ 45 USD/月）＋処理量（0.062 USD/GB）（2026年9月時点）。S3・DynamoDB へは VPC エンドポイント（第7回の「DHCP オプションセットと VPC エンドポイント」）で NAT を迂回するのが、コスト・セキュリティ両面で定石
- NAT インスタンス（EC2 で自作）は旧方式。帯域・可用性・運用の面で NAT ゲートウェイに劣る
- Egress-only IGW：IPv6 用のアウトバウンド専用ゲートウェイ（IPv6 は NAT を使わない）
なお、上の「AZ 単位」は従来からのゾーン型の NAT ゲートウェイの話です。2025年11月には、ワークロードのある AZ へ自動で広がるリージョン型（Regional NAT Gateway）も加わりました。AZ ごとに置いて経路を分ける手間を減らせますが、プライベート NAT には使えないなどの制約があるので、使う前に公式の説明を確かめてください。
パブリック IP・Elastic IP・IPv6
インスタンスに付くアドレスには、いくつかの種類があります。オンプレとの大きな違いは、パブリック IP が OS からは見えないことと、パブリック IPv4 が有料になったことです。
- 自動割り当てパブリック IPv4：サブネットの設定で起動時に付与される。停止→起動で変わる。DNS（Route 53 の A レコード）に直接書くと、停止のたびに更新が必要
- Elastic IP（EIP）：固定のパブリック IPv4。インスタンスに関連付けても、外しても、2024 年 2 月から常に 0.005 USD/h の課金がされる（以前は未使用時のみ課金）。上限はリージョンあたり 5（引き上げ可）（2026年9月時点）
- パブリック IP はインスタンスの OS からは見えない。IGW が 1:1 NAT しているので、
ip addrに出るのはプライベート IP。自分のパブリック IP は IMDS（/latest/meta-data/public-ipv4。IMDS は第3回）で知る - BYOIP：自社保有のアドレスブロックを AWS に持ち込める（/24 以上）
- IPv6：グローバルユニキャストアドレスが直接インスタンスに付く（NAT なし）。SG／NACL で制御する。パブリック IPv4 の有料化以降、「内部通信は IPv6、IPv4 は ELB だけ」のような設計が増えている（連載「TCP/IP入門」第9回の「クラウドのIPv6（AWS）」）
- ENI（Elastic Network Interface）：仮想 NIC。プライベート IP・EIP・SG・MAC はインスタンスではなく ENI に付く。ENI を別インスタンスに付け替えれば IP と SG がそのまま移る（ライセンスの MAC 縛りの回避に使われる）
$ ip -4 addr # OS に見えるのはプライベート IP だけ
$ TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token \
-H "X-aws-ec2-metadata-token-ttl-seconds: 60")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/public-ipv4 # パブリック IP は IMDS で知る（IMDSv2 のトークンの取り方は第3回で扱います。）
セキュリティグループ
セキュリティグループ（SG）は ENI 単位（実質インスタンス単位）に適用するステートフルなファイアウォールで、オンプレの「ホストの手前に置いた L4 パケットフィルタ」にあたります。許可ルールしか書けず、書いていないものはすべて拒否されます（既定：インバウンド全拒否・アウトバウンド全許可）。
ステートフルなので、インバウンドで 443 を許可すれば戻りパケットはアウトバウンドの設定に関係なく通り、逆にアウトバウンドで開始した通信の戻りもインバウンド設定に関係なく通ります（ステートフルの考え方は連載「TCP/IP入門」第12回の「ステートフルファイアウォールと戻りの通信」）。
送信元・宛先には CIDR のほかに別の SG の ID を指定できるのが大きな特徴で、「DB の SG は、AP の SG を持つインスタンスからの 3306 だけ許可」と書けば、AP の台数や IP が変わっても設定変更が要りません（第7回の演習で使います）。1 つの ENI に最大 5 つ（引き上げ可）、1 つの SG に既定 60 ルール（イン・アウト各）です（2026年9月時点）。ルールの変更はすぐに反映されますが、追跡中の既存の接続（コネクショントラッキング）はすぐには切れず、タイムアウトするまで通り続けます。すぐに止めたいときは NACL で拒否します。SG は VPC に属し、他の VPC では使えません（ピアリング先の SG 参照は同一リージョンのみ可能です）。
- ENI 単位・ステートフル・許可のみ。既定はイン全拒否／アウト全許可
- 送信元に「別の SG」を指定できる → 層ごとに SG を分けて参照する
- 上限：ENI あたり 5 SG、SG あたり 60 ルール（既定）
Auto Scaling（第4回）で台数が増えると、IP を送信元に書いたルールでは新しいインスタンスが通れません。SG は IP でなく SG 参照で書くのが基本です。
セキュリティグループのルール例（3 層構成）
インターネット → ALB → Web → DB の 3 層構成での、SG のルールの例です。
| SG 名 | 方向 | プロトコル／ポート | 送信元／宛先 | 意味 |
|---|---|---|---|---|
| sg-alb | イン | TCP 443 | 0.0.0.0/0、::/0 | インターネットから HTTPS |
| sg-alb | イン | TCP 80 | 0.0.0.0/0 | HTTP（→ HTTPS へリダイレクト） |
| sg-web | イン | TCP 8080 | sg-alb | ALB からのみアプリポートを受ける |
| sg-web | イン | TCP 22 | （なし） | SSH は開けず Session Manager を使う |
| sg-db | イン | TCP 3306 | sg-web | Web 層からのみ MySQL |
| sg-db | イン | TCP 3306 | 10.0.100.0/24 | 運用用の踏み台サブネットから |
| 全 SG | アウト | すべて | 0.0.0.0/0 | 既定のまま（厳格化するなら 443 と VPC 内のみ等） |
SG 参照のルールは、CLI では次のように書きます。
$ aws ec2 authorize-security-group-ingress --group-id sg-0db --protocol tcp --port 3306 --source-group sg-0web「22 番を 0.0.0.0/0 に開ける」は、Security Hub や Config ルール（第9回・第11回）で検出される代表的な違反設定です。SSH の代わりに使う Session Manager は第3回で、SSH の踏み台との比べ方は連載「SSH入門」第10回の「クラウドの代替手段」で扱っています。
ネットワーク ACL（NACL）
SG とは別に、サブネットの境目で通信を絞るのがネットワーク ACL です。オンプレのルーターの ACL に近いものです。
- サブネット単位に適用するステートレスなパケットフィルタ。往路と復路を別々に許可する必要がある（エフェメラルポート 1024〜65535 の戻りを許可し忘れるのが典型的なハマりどころ。エフェメラルポートは連載「TCP/IP入門」第10回の「ポート番号の仕組み」）
- 許可と拒否の両方を書け、ルール番号の小さい順に評価して最初に一致したルールで決まる（
*の最終ルールは全拒否）。1 NACL あたり既定 20 ルール（2026年9月時点） - VPC 作成時の「デフォルト NACL」は全許可、自分で作った NACL は全拒否が初期値
- 1 サブネットに 1 NACL、1 NACL は複数サブネットで共有できる
- 用途：SG では書けない明示的な拒否（特定の送信元 IP をブロック、特定サブネット間の通信を遮断）、多層防御の 2 枚目。日常の制御は SG で行い、NACL はデフォルトのままという設計も多い
- ルール例（プライベートサブネットで DB のみ）：100 許可 TCP 3306 from 10.0.10.0/24、110 許可 TCP 1024-65535 to 10.0.10.0/24（戻り）、
*拒否、という構成になる
図では、この例に明示的な拒否の 120 を足しています。
| # | 方向 | プロトコル／ポート | 送信元／宛先 | 判定 |
|---|---|---|---|---|
| 100 | イン | TCP 3306 | 10.0.10.0/24 | 許可 |
| 110 | アウト | TCP 1024-65535 | 10.0.10.0/24 | 許可（戻り） |
| 120 | イン | すべて | 203.0.113.0/24 | 拒否（明示） |
| * | 両方 | すべて | 0.0.0.0/0 | 拒否 |
冒頭の2つ目の相談がこれです。NACL はステートレスなので、インバウンドの 3306 を許可しても、DB からの応答（宛先はクライアントのエフェメラルポート）をアウトバウンドで許可しなければ戻れません。SG はステートフルなので、同じ設定で通ったのです。NACL を使うときは、110 のような戻りのルールを必ず対で書きます。
SG と NACL の比較
| 項目 | セキュリティグループ | ネットワーク ACL |
|---|---|---|
| 適用単位 | ENI（インスタンス） | サブネット |
| ステート | ステートフル（戻りは自動許可） | ステートレス（戻りも明示） |
| ルールの種類 | 許可のみ | 許可と拒否 |
| 評価 | 全ルールを評価して 1 つでも許可なら通す | 番号順、最初に一致したもの |
| 送信元の指定 | CIDR、SG ID、プレフィックスリスト | CIDR のみ |
| 既定値 | イン拒否／アウト許可 | デフォルト NACL は全許可 |
| 上限（既定） | 60 ルール、5 SG/ENI | 20 ルール |
| 主な用途 | 日常のアクセス制御 | 明示的拒否、防御の追加層 |
通信が通らないときの確認順は「ルートテーブル → NACL（往路・復路）→ SG → OS のファイアウォール（firewalld／Windows Defender）」です。VPC Reachability Analyzer を使うと、この経路上のどこで止まっているかを機械的に診断できます（第7回の「VPC Flow Logs とネットワークの可観測性」）。
考えてみよう
- 本番・検証・共通基盤の3つの VPC と、オンプレの拠点（192.168.0.0/16 を使用）を、将来 VPN でつなぐ予定です。3 AZ を使い、各 AZ にパブリック・AP・DB のサブネットを置くとして、VPC ごとの CIDR とサブネットの割り当てを台帳にしてみてください。/24 のサブネットで使えるアドレスはいくつですか。
- プライベートサブネットの AP サーバーから OS のパッチを取りに行けません。ルートテーブル・NAT ゲートウェイ・SG のどこを、どの順で確かめますか。NAT ゲートウェイが 1 つの AZ にしか無い場合、どんな問題が残りますか。
- 3 層構成で、Auto Scaling で Web サーバーが 2 台から 6 台に増えても DB へつながるようにするには、sg-db の送信元に何を書きますか。また、特定の攻撃元（203.0.113.0/24）だけを止めたいとき、SG と NACL のどちらで書きますか。
ヒント：1 は「CIDR 設計と制約」、2 は「サブネットとルートテーブル」と「インターネットゲートウェイと NAT ゲートウェイ」、3 は「セキュリティグループのルール例（3 層構成）」と「SG と NACL の比較」の節を見直してください。
まとめ
- VPC はアカウント内の隔離された仮想 LAN。リージョン内で AZ をまたぎ、ブロードキャスト・マルチキャストは無い
- CIDR は /16〜/28 で、縮小・変更できない。オンプレや他 VPC と重ねないよう台帳で払い出す。各サブネットで 5 アドレスが予約される
- サブネットのパブリック／プライベートは、ルートテーブルに IGW への経路があるかで決まる
- NAT ゲートウェイは出口専用で AZ 単位。S3・DynamoDB へはエンドポイントで迂回する
- パブリック IP は OS から見えず、パブリック IPv4 は常に課金。IP・SG・MAC は ENI に付く
- SG はステートフル・許可のみで SG 参照が書ける。NACL はステートレス・番号順で拒否も書ける。戻りのエフェメラルポートに注意
次回は、VPC の DNS（Route 53 Resolver）、VPC エンドポイント、VPC 間とオンプレとの接続、Route 53、CloudFront、Flow Logs と、3 層 Web システムの VPC 設計の演習、Azure との対応を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）（この記事）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント