AWS VPCネットワークアーキテクチャ完全ガイド：サブネット化、セキュリティグループ、ルーティングテーブル構成の実践

AWSへの移行から3か月後、ある海外のSaaS企業は深刻なセキュリティインシデントに遭遇した。RDSデータベースインスタンスが誤ってパブリックサブネットに配置され、セキュリティグループのルールが緩すぎたため、データベースポートがパブリックネットワークに公開され、データ漏洩リスクアラートが発動した。

海外のクラウドへ移行する初期段階の企業にとって、このようなケースは珍しくありません。多くのチームは移行を急いでいるため、VPCネットワークアーキテクチャに対する理解が「動いている限り」という程度にとどまり、その後のセキュリティや運用保守において潜在的な危険を生み出してしまうのです。

VPC（仮想プライベートクラウド）は、AWS上のすべてのリソースのネットワーク基盤です。この記事では、基本概念から実践的な設定まで、この基盤をしっかりと理解できるよう解説します。

AWS VPC とは何ですか?

VPCは、AWSクラウド上に構築された専用の仮想ネットワーク環境です。自社のデータセンターでネットワークを管理するのと同様に、ネットワークのIPアドレス範囲、サブネット化、ルーティングルール、ネットワークセキュリティポリシーを完全に制御できますが、物理的なハードウェアを購入する必要はありません。

各AWSアカウントは、リソースを迅速に起動できるよう、各リージョンにデフォルトのVPCを自動的に作成します。ただし、本番環境では、よりきめ細かな制御を行うために、カスタムVPCを作成することを強くお勧めします。

VPCの主要コンポーネント

サブネット化：パブリックサブネットとプライベートサブネット

適切なサブネット化は、VPCアーキテクチャ設計における最初にして最も重要なステップです。

パブリックサブネット

パブリックサブネットとは、ルーティングテーブルにインターネットゲートウェイ（IGW）への経路が含まれているサブネットのことです。パブリックサブネットに配置されたリソースは、パブリックIPアドレスを持ち、インターネットと直接通信できます。

パブリックサブネットへの配置に適したリソース：

• アプリケーションロードバランサー（ALB/ELB）
• NATゲートウェイ
• バスティオンホスト
• インターネットに直接接続するウェブサーバーが必要です（特殊なシナリオ）。

プライベートサブネット

プライベートサブネットのルーティングテーブルには、IGWへの直接ルートは含まれておらず、プライベートサブネット内のリソースにはインターネットから直接アクセスできません。プライベートサブネット内でインターネットにアクセスする必要があるリソース（ソフトウェアパッケージのダウンロードや外部APIの呼び出しなど）は、NATゲートウェイを経由する必要があります。

プライベートサブネットへの配置に適したリソース：

• アプリケーションサーバー（EC2インスタンス）
• データベース（RDS、Aurora、ElastiCache）
• 内部APIサービス
• バッチ処理タスク

標準的な3層アーキテクチャ図

インターネット ↓ [パブリックサブネット] — ロードバランサー (ALB) ↓ [プライベートサブネット] — アプリケーションサーバー (EC2) ↓ [プライベートサブネット] — データベース (RDS)

この階層型アーキテクチャにより、データベースサーバーとアプリケーションサーバーがパブリックネットワークに直接公開されることがなくなり、攻撃対象領域が大幅に縮小されます。

マルチAZプランニング

本番環境では、サブネットを少なくとも2つのアベイラビリティゾーンに展開する必要があります。AWSのアベイラビリティゾーンは独立した物理データセンターであり、ゾーンをまたいで展開することで、単一のアベイラビリティゾーンで障害が発生した場合でもサービスの継続性を保証できます。

推奨されるサブネット計画（ap-northeast-1 東京リージョンを例にとる）：

ルーティングテーブルの設定

各サブネットにはルーティングテーブルを関連付ける必要があります。ルーティングテーブルは、そのサブネット内のトラフィックがどのように転送されるかを決定します。

パブリックサブネットルーティングテーブル

パブリックサブネットのルーティングテーブルには、2つのコアルートが含まれている必要があります。

最初のルートはローカルルートで、宛先はVPCのCIDRブロック（例：10.0.0.0/16）です。宛先は「local」です。このルートはAWSによって自動的に追加され、VPC内のリソース同士の通信を可能にします。

2つ目のルートは、宛先が0.0.0.0/0（すべてのトラフィック）で、インターネットゲートウェイ（igw-xxxxxxxx）を指すインターネットルートです。このルートにより、パブリックサブネット内のリソースがインターネットにアクセスしたり、インターネットからアクセスされたりすることが可能になります。

プライベートサブネットルーティングテーブル

プライベートサブネットのルーティングテーブルには、ローカルルート（自動的に作成される）が含まれますが、直接のIGWルートは含まれません。プライベートサブネット内のリソースがインターネットにアクセスする必要がある場合は、NATゲートウェイを指すルート0.0.0.0/0を追加する必要があります。

重要な注意事項NATゲートウェイ自体はパブリックサブネットにデプロイし、Elastic IP（EIP）を割り当てる必要があります。単一障害点を回避するため、各アベイラビリティゾーンには独立したNATゲートウェイをデプロイする必要があります。

セキュリティグループを構成するためのベストプラクティス

セキュリティグループは、AWSで最も一般的に使用されているネットワークセキュリティ制御方法です。インスタンスレベルで動作し、ステートフルファイアウォールとして機能します（受信トラフィックを許可しつつ、受信トラフィックも自動的に許可します）。

最小権限の原則

セキュリティグループ設定の基本原則は、必要なポートのみを開放し、必要なソースのみを許可することです。

反例（危険な構成）：

上記の構成では、SSHポートとデータベースポートが世界中のすべてのIPアドレスに公開されるため、非常に危険です。

肯定的な例（推奨構成）：

アプリケーションサーバーのセキュリティグループ:

データベースセキュリティグループ:

IPアドレスではなくセキュリティグループIDを使用して互いを参照することで、EC2インスタンスのIPアドレスが変更された場合でも、セキュリティルールが有効であり続けることを保証できます。

セキュリティグループとネットワークACLの比較

ほとんどのシナリオでは、セキュリティグループで十分です。ネットワークACLは、特定のIPアドレス範囲を明示的に拒否する必要がある場合（既知の悪意のあるIPアドレスをブロックする場合など）や、コンプライアンス監査のレイヤーを追加する必要がある場合に主に使用されます。

VPCピアリングとトランジットゲートウェイ

企業の事業が拡大し、複数のVPC（仮想プライベートセンター）間でネットワーク接続を確立する必要が生じた場合（例えば、開発環境、テスト環境、本番環境が異なるVPCに配置されている場合）、主な解決策は2つあります。

VPCピアリング

2つのVPC間で1対1のプライベートネットワーク接続が確立され、トラフィックはインターネットを経由しないため、低遅延かつ低コストで運用できます。

適切なシナリオ：シンプルなピアツーピア接続を必要とする少数のVPC（3つ以下）。

制限事項：VPCピアリングは推移的ルーティングをサポートしていません。つまり、AとBの間、またはBとCの間でピアリングを行っても、AがCにアクセスできるとは限りません。

トランジットゲートウェイ

Transit Gatewayは、AWSが提供するネットワークハブサービスであり、複数のVPCとオンプレミスネットワークを同じ中央ノードに接続することで、完全な相互接続または制御された相互接続を実現します。

適したシナリオ：多数のVPC（4つ以上）を持つ企業、ハイブリッドクラウド（オンプレミスデータセンター＋クラウド）の要件、およびルーティングポリシーの一元管理。

VPC設定でよくある間違いとその回避方法

クラウドへの移行を支援する海外企業の経験に基づくと、VPC構成で最もよく見られるエラーは以下のとおりです。

エラー1：データベースがパブリックサブネット上に配置されています。

多くの初心者は、RDSをパブリックサブネットに配置し、簡単に接続できるように公開設定にしてしまいます。しかし、正しい方法は、RDSを常にプライベートサブネットに配置し、メンテナンス時には踏み台ホストまたはAWS Systems Manager Session Manager経由でアクセスすることです。

エラー2：本番環境でデフォルトのVPCを使用しています

デフォルトのVPCのセキュリティグループとルーティング設定は緩すぎ、すべてのサブネットがパブリックになっています。本番環境ではカスタムVPCを使用する必要があります。

エラー3：NATゲートウェイが1つしかデプロイされていません。

NATゲートウェイが1つのアベイラビリティゾーン（AZ）にのみ配置されている場合、そのAZが障害を起こすと、すべてのプライベートサブネットからの送信トラフィックが中断されます。高可用性アーキテクチャでは、各アベイラビリティゾーンにそれぞれ独立したNATゲートウェイが必要です。

エラー4：VPCストリームログを無視しています

VPCフローログは、VPCに出入りするすべてのネットワークトラフィックを記録するため、セキュリティ監査やトラブルシューティングにおいて重要なツールとなります。VPCの設定時からフローログを有効にし、CloudWatch LogsまたはS3に出力することをお勧めします。

概要：VPCアーキテクチャ設計の基本原則

堅牢なAWS VPCアーキテクチャは、以下の原則に従うべきです。

• 多層防御パブリックサブネット＋プライベートアプリケーションサブネット＋プライベートデータベースサブネット、3層分離。
• 最低限の特権セキュリティグループは、必要なポートのみを開き、その送信元はセキュリティグループIDまで指定されます。
• 高可用性少なくとも2つのアベイラビリティゾーンに展開され、各アベイラビリティゾーンに独立したNATゲートウェイが配置される。
• 観測可能VPCストリーミングログを有効にし、CloudWatchの監視とアラートを統合します。
• カスタマイズ希望デフォルトのVPCは、本番環境では使用しないでください。

VPCはAWSアーキテクチャの基盤となる要素です。事前の適切な計画は、後々の時間と労力を節約します。企業のAWSクラウドアーキテクチャを計画中の場合、または既存のVPC構成にセキュリティ上の脆弱性がある場合は、無料のクラウドアーキテクチャ評価についてお問い合わせください。

→ 無料のAWSアーキテクチャ評価をリクエストする：aws-oncloudai.com/contact

この記事は、aws-oncloudai.comのクラウドアーキテクチャチームが執筆しました。当社は、海外進出を目指す中国企業向けに、AWSクラウドサービスのコンサルティング、アーキテクチャ設計、コスト最適化サービスを提供することに注力しています。