適切に構築されたAWS VPCは、セキュリティとスケーラビリティの観点から明確なネットワーク境界を提供します。基盤レイヤーが初期段階から正しく設計されている際、トラフィックやデータ量が増えても、システムは予測可能で、コンプライアンスを満たし、運用が容易になります。

AWSにおけるVPCとは？

VPC（Virtual Private Cloud）は、AWSがアカウントごとに提供する分離された仮想ネットワークであり、AWS環境内における「専用の領域」と言えます。
この中で、ユーザーはネットワーク設計のすべてを自由にコントロールできます：

• IP レンジの決定
• サブネットの作成
• ルーティングルールの定義
• ゲートウェイの接続

オンプレミス環境のようにインフラを手作業で構築・維持する必要はなく、AWS VPCを使えば、運用負荷を抑えつつエンタープライズレベルのネットワーク境界を構築できます。

適切に設計されたVPCは、AWS上に配置されるすべてのワークロードの基盤です。VPCはトラフィックの流れ、インターネットへ接続できるコンポーネント、完全に隔離すべきレイヤーを決定します。

VPCを「計画的に区画されたデジタル上の街区」と考えると分かりやすく、各サブネットは役割・アクセス制御・接続方式が異なる独立ゾーンとなります。この構造こそが、安全でスケーラブルかつ堅牢なアーキテクチャを実現するための土台です。

実システムで使われる標準的なアーキテクチャ

VPCを設計するにあたり、まずは本番環境に共通するコアネットワーク要素を理解することが重要です。これらがトラフィックの流れ、インターネット接続の可否、ワークロード間の分離方法を決定します。この基礎が理解できれば、3種類のサブネットレイヤー（Public、Private、Database）の構成は自然と整理できます。

VPCの主要コンポーネント

• サブネット
  VPC は論理的なゾーンに分割されます：
  • パブリック（Public）: Internet Gateway 経由でインターネットに接続可能
  • プライベート（Private）: 直接インターネットアクセス不可、NAT Gateway 経由してアウトバウンドのみ可能
  • アイソレーテッド（Isolated）: インターネットルートなし（データベース向け)
• ルートテーブル
  サブネットごとにトラフィックの送信先を制御：
  • パブリックサブネット（Public） →インターネットゲートウェイ（Internet Gateway）
  • プライベートサブネット（Private） → NATゲートウェイ
  • データベースサブネット → VPC内部のローカルルートのみ
• インターネットゲートウェイ（Internet Gateway） (IGW): パブリックサブネットのインターネット入出力を許可するゲートウェイ
• NATゲートウェイ: プライベートサブネットからのアウトバウンド通信を提供（外部からの着信は不可）
• セキュリティグループ: ステートフルなリソースレベルのファイアウォール。アプリ間通信を制御
• ACLsネットワーク（Network ACLs） (NACLs): サブネット境界におけるステートレスルールによるセキュリティ強化
• VPCエンドポイント（VPC Endpoints）: パブリックインターネットを経由しないAWS サービス（S3、DynamoDB）へのプライベートアクセス

上記の各コンポーネントはそれぞれ固有の役割を持っていますが、サブネットレイヤーとして構成されて初めて意味を持ちます。

• IGWがパブリックサブネットに関連付けられて初めて意味を持つインターネットゲートウェイ
• NATゲートウェイは、プライベートサブネットがアウトバウンドアクセスを必要とする場合にのみ有効なネットワークアドレス変換ゲートウェイ
• ルートテーブルは、各レイヤーの接続性を形成するルートテーブル
• セキュリティグループは、レイヤー間（ティア間）のアクセスを制御するセキュリティグループ

このような理由から、本番環境のVPCは通常、パブリック／プライベート／データベースの3 層構成で設計されます。
それでは、各レイヤーについて詳しく見ていきましょう。

パブリックサブネット（インターネット向けレイヤー）

パブリックサブネットには、インターネットからの通信を受け取る必要があるコンポーネントを配置します。

• Application Load Balancer（ALB）
• AWS WAF（レイヤー 7 の保護）
• CloudFront（グローバルエッジ配信）
• Route 53（DNS ルーティング）

これにより、クライアントからのインバウンド通信は常に厳密に管理された入口ポイントを通過し、アプリケーション層やデータベース層へ直接到達することはありません。

プライベートサブネット（アプリケーションレイヤー）

プライベートサブネットには、パブリックIPを持つ必要のないアプリケーションサービスを配置します。主な構成要素は以下のとおりです。

• バックエンド処理用のECSFargateまたはEC2インスタンス
• Auto Scalingグループ
• データベースと通信する内部サービス

パッケージ更新や外部 API の呼び出しなど、必要なアウトバウンド通信は、パブリックサブネットに配置された NAT Gateway を経由します。
通信は内側からのみ開始されるため、このレイヤーは不要なインターネットアクセスからアプリケーションを保護しつつ、正常な動作を維持できます。

データベースサブネット（アイソレーションレイヤー）

アイソレーションレイヤーサブネットには、以下のようなデータストアを配置します。

• Amazon RDS（Multi-AZ 構成）
• その他のマネージド型データベースサービス

このレイヤーにはインターネットへの直接的なルートは存在せず、セキュリティグループのルールを通じてアプリケーションレイヤーからのみアクセス可能となります。

この厳格な分離により、外部からのトラフィックがデータベースに到達することを防ぎ、リスクを大幅に低減します。その結果、PCI DSSやGDPRなどのコンプライアンス要件への対応にも貢献します。

2025年に適用すべきAWS VPCのベストプラクティス

ベストプラクティスを適用する前に、現在のVPCがすでにアーキテクチャ上の限界を示していないかを確認することが重要です。代表的な兆候としては、CIDRアドレス空間の枯渇、アプリケーションのスケール不全、VPNや専用線接続などのハイブリッド接続の統合が困難になることが挙げられます。これらの問題が発生している場合、多くは部分的な修正ではなく、VPC全体の構造的な再設計が必要であることを示すサインです。

これらの課題に一貫して対応するため、現在の本番環境では、パブリックサブネット、プライベートアプリケーションサブネット、データベースサブネットを分離し、レイヤー間の通信を制御された一方向のトラフィックフローに限定する標準的なネットワーク構成が採用されています。

この構成は、セキュリティ境界の明確化、スケーラビリティの向上および機密性の高いワークロードに対するコンプライアンス確保を実現できるため、現在広く利用されています。

ベストプラクティス #1 ― パブリックサブネット（インターネットフェーシングレイヤー）

配置場所: 2つのアベイラビリティゾーンに分散した2つのサブネット（10.0.1.0/24、10.0.2.0/24）

主要コンポーネント

• ACMのSSL証明書を使用したApplication Load Balancer（ALB）
• レイヤー 7保護のためのAWS WAF
• エッジCDNとしてのCloudFront
• DNS解決を行うRoute 53

ルートテーブル

0.0.0.0/0 → インターネットゲートウェイ（Internet Gateway）

目的:
本レイヤーは、Webやモバイルクライアントからの外部トラフィックを受信し、TLS終端処理、悪意のあるリクエストのフィルタリング、静的コンテンツのキャッシュ配信を行います。検証済みのリクエストのみを、プライベートなアプリケーションレイヤーへ転送します。

ベストプラクティス #2 ― プライベートサブネット（アプリケーションレイヤー）

配置場所: 2つのアベイラビリティゾーンに分散した2つのサブネット (10.0.3.0/24, 10.0.4.0/24)

主要コンポーネント:

• ECS Fargateサービス:
  • バックエンドAPI（Golang）
  • フロントエンドビルドパイプライン（React）
• CPU／メモリ負荷に応じてスケールするAuto Scalingグループ

ルートテーブル:

0.0.0.0/0 →　NATゲートウェイ（NAT Gateway）

目的：
このレイヤーでは、すべてのビジネスロジックをパブリックIPを持たせずに実行します。ワークロードはNATゲートウェイ経由でアウトバウンド通信が可能ですが、インバウンドアクセスは ALBのみに制限されます。これにより、セキュリティ、スケーラビリティ、予測可能なトラフィック制御が実現されます。

ベストプラクティス #3 ― データベースサブネット（アイソレーテッドレイヤー）

配置場所: 専用の2サブネット (10.0.5.0/24, 10.0.6.0/24)

主要コンポーネント:

• RDS PostgreSQL（プライマリ + リードレプリカ構成）
• 高可用性を確保するMulti-AZ配置

ルートテーブル:

10.0.0.0/16 → Local

(インターネットルートなし)

セキュリティ設定:

• セキュリティグループ:　アプリケーションレイヤーのSGからの5432ポート通信のみ許可
• NACLルール:
  • 10.0.3.0/24および10.0.4.0/24からの5432番ポートのインバウンド通信を許可
  • パブリックサブネットからのすべてのアクセスを拒否
  • その他すべてのインバウンド通信を拒否

 

• 保存時暗号化（KMS）および通信時TLS暗号化を有効化

目的:
データベースを完全に分離し、インターネットからの直接アクセスを排除します。制御・監査可能なアプリケーションレイヤー経由の通信のみを許可することで、高いセキュリティとコンプライアンスを確保します。

ベストプラクティス #4 ― セキュアな一方向データフローの強制

• インターネットからのパケットがRDS に直接到達することは一切ない
• すべてのアプリケーションコンテナはパブリックIPを持たない
• 各通信経路（ホップ）は、セキュリティグループ、NACL ルール、IAMポリシーによって厳密に制御される

目的:
このように構造化され、予測可能な通信フローを採用することで、影響範囲（Blast Radius）を最小化し、監査性を向上させるとともに、PCI DSS、GDPR、ISO 27001などのセキュリティフレームワークへの準拠を確実にします。

Terraformによる本アーキテクチャのデプロイ（コード例）

Terraformを使用してVPC（いわゆるAWS VPC Terraform構成）を管理することで、ネットワーク設計をバージョン管理可能でレビューしやすいインフラとして扱うことができます。これにより、dev／stage／prod 環境間の一貫性を保ち、変更履歴の監査を可能にし、AWS コンソール上での手動操作による設定ドリフトを防止できます。

以下は、前述のアーキテクチャに基づき、VPCと3層サブネットを構築するTerraformの完全な構成例です。

1. VPCの作成

すべてのワークロードに対するネットワーク境界を定義します。

2. パブリックサブネット + インターネットゲートウェイ + ルートテーブル

パブリックサブネットにはインターネットゲートウェイ（Internet Gateway）を接続し、アウトバウンド通信を許可するルートテーブルを設定します。

3. プライベートアプリケーションサブネット + NATゲートウェイ

アプリケーションワークロードを外部に公開することなく、アウトバウンドのインターネットアクセスを可能にします。

4. データベースサブネット―インターネット経路なし

データベースサブネットは、ローカルルーティングのみに限定し、完全に分離された状態を維持します。

5. ECSバックエンド用Security Group

信頼されたALBからの通信のみを許可し、不要なインバウンドアクセスを制限します。

6. RDS用Security Group ― ECS のみ許可

データベースレイヤーへのアクセスをアプリケーションレイヤーのみに限定します。

7. ECS Fargate サービスへのアタッチ

正しいセキュリティ境界を持つプライベートサブネット内でアプリケーションを実行します。

よくあるVPCの設計ミス（およびその回避方法）

多くのVPCの問題は、実際の運用環境で繰り返し見られる、いくつかの基本的な設定ミスに起因しています。

1. データベースをパブリックサブネットに配置してしまう

初期の接続が容易に感じられるため、RDSインスタンスをパブリックサブネットに配置しているVPCは意外と多く存在します。しかし、この構成はデータベースを不要なリスクにさらし、ほとんどのセキュリティ要件やコンプライアンス要件に違反します。データベースは必ずインターネット経路を持たない分離サブネットに配置し、アクセスは アプリケーションレイヤーのセキュリティグループのみに制限すべきです。

2. アプリケーションインスタンスにパブリックIPを割り当てる

EC2やECSタスクにパブリックIPを付与すると、手軽にアクセスやトラブルシューティングができるように感じられます。しかし、この方法はセキュリティ境界を不明確にし、攻撃対象領域（アタックサーフェス）を大きく広げてしまいます。アプリケーションワークロードはプライベートサブネットに配置し、アウトバウンド通信は NAT Gateway 経由とし、運用アクセスは SSM やプライベートな踏み台ホストを利用するのが適切です。

3. すべてのサブネットで同一のルートテーブルを使用する

VPCの分離性を破壊してしまう最も起こりやすい原因の一つは、同一のルートテーブルをパブリック、プライベート、データベースの各サブネットに関連付けてしまうことです。

本来インターネット向けに送信されるべきトラフィックが、意図せず内部へ伝播してしまい、
ルーティングループの発生やレイヤー間の不正な接続漏れを引き起こす可能性があります。

適切な設計では、ルートテーブルを明確に分離します。

• パブリックサブネットはインターネットゲートウェイへルーティング
• プライベートサブネットはネットワークアドレス変換ゲートウェイへルーティング
• データベースサブネットはVPC内部のローカル通信のみに限定

このように構成することで、各レイヤー間の通信境界が保たれ、安全で予測可能なネットワーク構成を実現できます。

4. CIDRブロックを小さく設定しすぎる

将来的な拡張を見込まずにCIDRを小さく設定すると、サービスやサブネットの追加時にIPアドレスが枯渇してしまいます。後からVPCを拡張するのは非常に困難で、多くの場合、移行作業や複雑なピアリング構成が必要になります。最初から十分に大きなCIDR範囲を確保しておくことで、インフラの中断を伴わずにスケール可能なアーキテクチャを維持できます。

まとめ

整理され、適切に構成されたVPCは、本格的なAWSワークロードに必要なセキュリティ、スケーラビリティ、運用の明確さを提供します。3層サブネットモデルを採用し、予測可能なデータフローを強制することで、システムの成長に伴っても、環境はコンプライアンスを維持しつつ、管理しやすい状態を保てます。

これらの原則を自社インフラへ適用する方法を検討されている場合、HaposoftのAWSチームがアーキテクチャレビューを行い、最適な改善案をご提案します。
専門的なサポートをご希望の際は、ぜひお気軽にお問い合わせください。