AWS VPC ベストプラクティス

AWS VPC（Virtual Private Cloud）を設計・運用する際のベストプラクティスを、設計・セキュリティ・接続性・運用・コストの観点から整理したものです。

---

目次

1. IPアドレス設計（CIDR）
2. サブネット設計
3. 高可用性（マルチAZ）
4. ルーティングとインターネット接続
5. セキュリティ
6. VPC間・オンプレミスとの接続
7. AWSサービスへのプライベート接続
8. DNS
9. 監視・ログ
10. マルチアカウント戦略
11. コスト最適化
12. IaCと運用管理
13. チェックリスト

---

1. IPアドレス設計（CIDR）

ポイント

• RFC 1918 のプライベートアドレス帯を使用する
  • 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16
• 将来を見越して十分な大きさのCIDRを確保する
  • 本番VPCは /16〜/20 程度を目安にする。後から拡張は可能（セカンダリCIDR）だが、設計が複雑になる
• CIDRの重複を避ける
  • 他のVPC、オンプレミス、他クラウド、将来的な合併・買収先のネットワークと重複しないようにする
  • 重複があると VPC Peering や Transit Gateway で接続できない
• 組織全体でIPアドレス計画を一元管理する
  • Amazon VPC IPAM を使い、リージョン・環境・アカウント単位でプールを切り出す
• IPv6 の採用を検討する
  • デュアルスタック構成にすることで IPv4 枯渇対策や、パブリック IPv4 アドレス課金の削減につながる

予約アドレスに注意

各サブネットでは先頭4つと最後の1つ、計5つのIPアドレスがAWSに予約される。小さすぎるサブネットは避ける。

---

2. サブネット設計

役割ごとに階層（Tier）を分ける

ポイント

• パブリックサブネットには必要最小限のリソースのみ置く。アプリケーションサーバーやDBは置かない
• サブネットサイズはワークロードに合わせる
  • EKS（Pod ごとにIPを消費）、Lambda、大規模Auto Scaling はIPを多く使うため大きめに確保する
• 将来用の空きアドレス空間を残しておく
• 命名規則を統一する（例: prod-app-private-1a）
• サブネットはAZをまたげないため、各AZに同じ構成のサブネットをセットで作る

---

3. 高可用性（マルチAZ）

• 最低2つ、推奨3つのAZを使用する
• 各階層のサブネットを全AZに対称的に配置する
• NAT Gateway はAZごとに1つ配置する
  • 1つのNAT Gatewayを全AZで共有すると、そのAZ障害時に他AZのアウトバウンド通信も止まる
  • また、AZ間のデータ転送料金も発生する
  • 開発環境などコスト優先の場合は単一NATも選択肢
• ロードバランサーやAuto Scaling グループも複数AZにまたがるよう設定する
• RDS はマルチAZ配置を有効にする

---

4. ルーティングとインターネット接続

ルートテーブル

• サブネットの役割ごとにルートテーブルを分ける
  • プライベートサブネットはAZごとのNAT Gatewayを向くよう、AZ単位でルートテーブルを作る
• メインルートテーブルは使わず、明示的に関連付ける
  • メインルートテーブルにはインターネットへのルートを入れない（新規サブネットが意図せずパブリックになるのを防ぐ）

インターネット接続

• インバウンドが必要なものは ALB/NLB/CloudFront 経由 で公開し、インスタンスへ直接パブリックIPを付けない
• サブネットの「パブリックIPv4アドレスの自動割り当て」はプライベートサブネットで無効にする
• IPv6 のアウトバウンドのみの通信には Egress-only Internet Gateway を使う
• 不要なインターネットアクセスを組織レベルで防ぐには VPC Block Public Access の利用を検討する

---

5. セキュリティ

多層防御の考え方

[インターネット]
   │  AWS WAF / Shield
   ▼
[ALB] ── セキュリティグループ
   │
[NACL] ── サブネット境界
   │
[EC2/コンテナ] ── セキュリティグループ
   │
[RDS] ── セキュリティグループ（アプリSGからのみ許可）

セキュリティグループ（SG）

• 最小権限の原則: 必要なポート・送信元のみ許可する
• 送信元にはCIDRではなく他のセキュリティグループを参照する
  • 例: DBのSGは「アプリのSGからの3306のみ許可」
• 0.0.0.0/0 からのインバウンドはロードバランサーの80/443など、本当に必要な場合に限る
• SSH(22) / RDP(3389) をインターネットに開放しない
  • 代わりに Systems Manager Session Manager や EC2 Instance Connect Endpoint を使い、踏み台サーバーを廃止する
• デフォルトセキュリティグループは使わず、ルールを空にしておく
• 用途が分かる名前と説明を付け、不要になったSGは定期的に削除する

ネットワークACL（NACL）

• ステートレスなため、戻りのトラフィック（エフェメラルポート 1024-65535）の許可を忘れない
• 基本はSGで制御し、NACLは サブネット単位の粗い制御や明示的な拒否（Deny） に使う
• ルール番号に間隔を空けておく（100, 200, …）と後から挿入しやすい

その他のセキュリティ対策

• デフォルトVPCは本番用途に使わない。不要なら削除するか、使わないよう制御する
• AWS Network Firewall でドメインベースのフィルタリングやIDS/IPSを実現する
• Route 53 Resolver DNS Firewall で悪性ドメインへの名前解決をブロックする
• Amazon GuardDuty を有効化し、VPCフローログ・DNSログから脅威を検知する
• AWS Security Hub / AWS Config でSGの過剰な開放などを継続的にチェックする
• 組織全体のSGやFirewallポリシーは AWS Firewall Manager で一元管理する

---

6. VPC間・オンプレミスとの接続

接続方式の選択

ポイント

• VPCが数個を超える見込みなら、最初から Transit Gateway を前提にする
• Transit Gateway のルートテーブルで 本番・開発・共有サービスのセグメントを分離 する
• Direct Connect は 冗長構成（2回線以上）+ VPN バックアップ を検討する
• 送信トラフィックを集約する 集中型 Egress VPC や、検査用の Inspection VPC パターンも有効

---

7. AWSサービスへのプライベート接続

• VPCエンドポイントを使い、AWSサービスへの通信をインターネット/NAT経由にしない
  • ゲートウェイエンドポイント（無料）: S3、DynamoDB → 必ず作成する
  • インターフェイスエンドポイント（有料）: ECR、CloudWatch Logs、SSM、Secrets Manager、STS など
• メリット:
  • セキュリティ向上（インターネットに出ない）
  • NAT Gateway のデータ処理料金削減
• エンドポイントポリシー でアクセス可能なリソースを制限する
  • 例: 自組織のS3バケットのみアクセス可能にする（データ持ち出し対策）
• 多数のVPCがある場合、インターフェイスエンドポイントを 共有サービスVPCに集約 してコストを抑える方法もある

---

8. DNS

• VPCの DNS解決（enableDnsSupport）とDNSホスト名（enableDnsHostnames）を有効化 する
  • インターフェイスエンドポイントのプライベートDNSに必要
• 内部名前解決には Route 53 プライベートホストゾーン を使う
• オンプレミスとのハイブリッドDNSには Route 53 Resolver エンドポイント（インバウンド/アウトバウンド） と転送ルールを使う
• 転送ルールは AWS RAM で複数アカウントに共有できる

---

9. 監視・ログ

• VPCフローログを有効化する
  • 送信先: CloudWatch Logs（リアルタイム分析）または S3（長期保存・低コスト、Athenaで分析）
  • 必要に応じてカスタムフォーマットで追加フィールド（pkt-srcaddr、tcp-flags など）を取得
• Route 53 Resolver クエリログ でDNSクエリを記録する
• Reachability Analyzer で接続トラブル時の経路を検証する
• Network Access Analyzer で意図しないネットワークアクセス経路を検出する
• NAT Gateway、Transit Gateway、VPN などのCloudWatchメトリクスにアラームを設定する
  • 例: NAT Gateway の ErrorPortAllocation、PacketsDropCount

---

10. マルチアカウント戦略

• AWS Organizations でアカウントを分離 する（本番・ステージング・開発・共有サービス・ネットワーク・セキュリティなど）
• ネットワーク専用アカウントで Transit Gateway やVPCを集中管理する
• AWS RAM による VPC共有（Shared VPC） を使うと、ネットワークは中央管理しつつ、各アカウントがサブネット上にリソースを作成できる
• SCP（サービスコントロールポリシー） でガードレールを設ける
  • 例: IGW の作成禁止、VPCフローログ削除の禁止、デフォルトVPC利用の禁止
• 環境ごとにVPCを分け、本番と開発のネットワークを直接つながない

---

11. コスト最適化

---

12. IaCと運用管理

• VPCはIaCで管理する（AWS CloudFormation、AWS CDK、Terraform など）
  • 手作業による設定ミスやドリフトを防ぐ
  • 環境間で同一構成を再現できる
• タグ付けルールを統一する（Name、Environment、Owner、CostCenter など）
• AWS Config ルール で設定の準拠状況を継続的に評価する
  • 例: vpc-flow-logs-enabled、vpc-default-security-group-closed、restricted-ssh
• ネットワーク構成図・IPアドレス台帳を常に最新に保つ（IPAMやIaCから自動生成できると理想的）
• 変更はレビューを経てから適用し、本番ネットワーク変更は影響範囲を事前に確認する

---

13. チェックリスト

設計

• CIDRが他のネットワークと重複していない
• 将来の拡張を見越したCIDRサイズになっている
• VPC IPAM などでアドレスを一元管理している
• 2つ以上（推奨3つ）のAZを使用している
• パブリック / プライベート / データ層のサブネットを分離している

ネットワーク

• NAT GatewayをAZごとに配置している（本番）
• メインルートテーブルにインターネットへのルートがない
• S3/DynamoDB のゲートウェイエンドポイントを作成している
• 必要なインターフェイスエンドポイントを作成している
• VPC間接続の方式（Peering / TGW / PrivateLink）が規模に合っている

セキュリティ

• SSH/RDPをインターネットに開放していない
• Session Manager等で踏み台サーバーを不要にしている
• セキュリティグループで他SGを参照し、最小権限になっている
• デフォルトセキュリティグループのルールが空になっている
• デフォルトVPCを本番で使っていない
• GuardDuty を有効にしている

運用

• VPCフローログを有効にしている
• Route 53 Resolver クエリログを有効にしている
• IaCで構成を管理している
• タグ付けルールが統一されている
• AWS Config で準拠状況をチェックしている

---

参考資料

• Amazon VPC ユーザーガイド
• VPC のセキュリティのベストプラクティス
• AWS Well-Architected Framework
• Building a Scalable and Secure Multi-VPC AWS Network Infrastructure（ホワイトペーパー）