Amazon VPCを設計するときは、サービス名を覚えるより先に、通信の要件を整理する必要があります。誰が、どの宛先へ、どの経路で接続し、その通信をどこで制限して記録するのか。この五つを決めると、構成を説明しやすくなり、障害時の切り分けも速くなります。
本記事では、Amazon VPCを中心に、Google Cloud VPCとAzure Virtual Network（VNet）を比較します。三つのクラウドには似た機能がありますが、適用範囲やルーティングの考え方まで同一ではありません。名称の対応表をそのまま設計へ置き換えず、アドレス、経路、境界、アクセス制御、観測の順に判断します。
- アドレス：将来接続するネットワークと重複しないか
- 経路：どの通信を直接つなぎ、どの通信をハブへ集めるか
- 境界：受信と送信をどこで制御するか
- アクセス制御：送信元、宛先、プロトコル、ポートをどう許可するか
- 観測：通信記録と設定変更をどこへ保存し、誰が確認するか
VPCを理解するための基本用語
VPCは、クラウド上のリソースを配置する論理的に分離されたネットワークです。物理的な社内LANをそのまま再現する機能ではありません。IPアドレスの範囲、サブネット、経路、通信ルールを組み合わせて、必要な到達性だけを作ります。
- CIDR
- ネットワークで使うIPアドレスの範囲を表す記法です。たとえば
10.64.0.0/16は一つの範囲を示します。 - サブネット
- VPC内のアドレス範囲を用途や配置先に合わせて分割した単位です。アプリ、データ、管理などの役割を分けると、経路と権限を説明しやすくなります。
- ルート表
- 宛先ごとに次の転送先を決める規則です。通信を許可する機能ではなく、パケットをどこへ送るかを決めます。
- 受信と送信
- 受信（Ingress）は外部から対象へ入る通信、送信（Egress）は対象から外部へ出る通信です。両者は別の要件として設計します。
AWS、Google Cloud、Azureの対応関係
次の表は、同じ名前の機能を示すものではなく、設計上の役割が近い機能を並べたものです。製品ごとの適用範囲、制約、料金は別途確認してください。
| 設計上の役割 | AWS | Google Cloud | Azure |
|---|---|---|---|
| 仮想ネットワーク | Amazon VPC | VPC network | Virtual Network（VNet） |
| サブネットの範囲 | Availability Zone単位 | リージョン単位 | VNet内のリージョン資源 |
| ワークロード周辺の通信制御 | Security Group | VPC firewall rules、firewall policies | Network Security Group |
| インターネット向け送信のNAT | NAT Gateway | Cloud NAT | NAT Gateway |
| サービスへのプライベート接続 | VPC endpoint、AWS PrivateLink | Private Service Connectなど | Private Endpoint、Private Link |
| 複数ネットワークの集約 | Transit Gateway | Network Connectivity Centerなど | Virtual WAN、ハブVNetなど |
大きな違いはネットワークの範囲です。Amazon VPCとAzure VNetはリージョンを意識して設計します。一方、Google CloudのVPC networkはグローバル資源であり、その中にリージョン単位のサブネットを作ります。この差は、アドレス管理、組織分割、障害範囲を考えるときに効いてきます。
アドレス計画は接続予定から逆算する
CIDRは大きければ安全というものではありません。広すぎる範囲を各環境へ機械的に割り当てると、オンプレミス、買収先、別クラウドとの接続時に重複し、経路を素直に設定できなくなることがあります。必要なアドレス数、環境数、接続予定、増設単位を先に洗い出します。
- 現在使っているオンプレミスとクラウドのCIDRを台帳に集める。
- 本番、検証、開発など、分離する環境を決める。
- Availability Zoneまたはリージョンごとの増設単位を決める。
- アプリ、データ、管理、接続用といったサブネットの役割を決める。
- 未使用範囲を予約し、割り当てと変更の申請方法を決める。
たとえば 10.64.0.0/16 を使う場合でも、すべてを直ちにサブネットへ割り当てる必要はありません。private-app、private-data、public-ingressのように用途が分かる名前を付け、将来分を未割り当てで残します。この値は例であり、すべてのVPCに適した推奨値ではありません。
接続構成は三つの型から選ぶ
単一VPCの分散構成
VPCが少ない段階では、各VPCに必要な受信、送信、監視を配置する方が経路を追いやすくなります。アプリケーション向けロードバランサーは、通常、そのワークロードとの到達性と運用責任が明確になる場所へ置きます。中央ハブへ集めること自体を目的にしません。
複数VPCのハブアンドスポーク構成
ネットワーク数が増え、オンプレミス接続、ファイアウォール、DNS、送信監査を共通化したい場合は、ハブアンドスポークを検討します。AWSではTransit Gateway、Google CloudではNetwork Connectivity Center、AzureではVirtual WANやハブVNetが候補になります。
ただし、中央集約には追加の経路、処理料金、障害範囲が生まれます。AWSでNAT Gatewayを集中させる場合も、Transit Gatewayのデータ処理料金とAvailability Zoneをまたぐ通信を含め、分散配置と比較します。通信量が多いVPCでは、NATを各VPCへ置く方が費用と経路の両面で合理的な場合があります。
オンプレミスや他クラウドとの接続
Site-to-Site VPNはインターネット上に暗号化トンネルを作る接続です。Direct Connect、Cloud Interconnect、ExpressRouteは、閉域または専用接続の要件がある場合の候補です。いずれも、帯域だけでなく冗長経路、経路交換、監視、障害時の切り戻しを合わせて設計します。
公開、送信、プライベート接続を分ける
インターネットからの受信
WebサイトやAPIを公開する場合は、CDN、WAF、ロードバランサー、APIゲートウェイのうち、必要な層だけを組み合わせます。すべてのシステムにCDNが必要なわけではありません。静的コンテンツの配信やオリジン保護が課題なら、Amazon CloudFront、Cloud CDN、Azure Front Doorの比較も判断材料になります。
VMやデータベースへパブリックIPを付ける構成は、運用上の理由が説明できる場合に限定します。直接公開を禁止するだけでは不十分です。TLS終端、WAF、ヘルスチェック、管理アクセス、ログの担当をどのサービスが受け持つかを決めます。
インターネットへの送信
プライベートサブネットから外部へ出るIPv4通信では、NATを使う構成が一般的です。NATは受信防御の代替ではなく、送信元アドレスを変換する仕組みです。許可する宛先を絞る必要がある場合は、ファイアウォール、プロキシ、DNS制御などを別に組み合わせます。
IPv6では、IPv4用NATの考え方をそのまま当てはめません。直接到達性、送信専用の境界、ファイアウォール、戻り経路を確認し、IPv4とIPv6の両方で同じセキュリティ要件を満たすように設計します。IPv6を採用するかどうかは、接続先、運用ツール、監視体制を含めて判断します。
クラウドサービスへのプライベート接続
AWSでは、S3とDynamoDBへ接続するGateway Endpointと、対応サービスへプライベートIPで接続するInterface Endpointがあります。Google CloudのPrivate Service Connect、AzureのPrivate Endpointも、公開インターネットを経由しない接続を作るときの候補です。
エンドポイントを作るだけで情報流出を防げるわけではありません。接続先、名前解決、ルート、セキュリティルール、エンドポイントポリシーやサービス側の権限を一緒に確認します。S3を含むオブジェクトストレージの権限設計は、Amazon S3、Google Cloud Storage、Azure Blob Storageの比較で詳しく整理しています。
アクセス制御の役割を混同しない
| 機能 | 適用単位 | 性質 | 主な用途 |
|---|---|---|---|
| Security Group | 対応するネットワークインターフェースやリソース | ステートフル、許可ルール | アプリ層ごとの必要な通信を許可する |
| Network ACL | サブネット | ステートレス、許可と拒否 | サブネット境界で追加の制御を行う |
| AWS Network Firewall | ルーティングした通信 | ステートフル検査を含む | 複数VPCの送信検査やネットワーク境界を集約する |
Security Groupは「IDによる認可」そのものではありません。ルールではCIDR、プレフィックスリスト、別のSecurity Groupなどを送信元または宛先として指定できます。たとえばロードバランサーのSecurity Groupを、アプリ側Security Groupの受信元に指定すれば、固定IPに依存せず役割間の通信を表現できます。
Google CloudのファイアウォールルールとAzureのNetwork Security Groupは、Security Groupと役割が近くても設定モデルは異なります。クラウドを移行するときは、ルールを一対一で翻訳せず、「どのワークロード間に、どの通信が必要か」という要件へ戻して作り直します。
DNSとハイブリッド接続は一つの設計にする
IP経路が通っていても、名前を解決できなければアプリケーションは接続できません。社内DNSとクラウドDNSのどちらが名前を管理するか、問い合わせをどちらへ転送するか、同じFQDNを内外で分けるかを決めます。
Split-horizon DNSを使う場合は、同じ名前が接続元によって異なるアドレスを返します。切り替え時にはTTLとキャッシュが影響するため、変更手順と確認方法をRunbookへ含めます。AWSのDNS機能とトラフィック制御は、Amazon Route 53、Cloud DNS、Azure DNSの比較も参照してください。
ログは目的ごとに集める
通信ログと設定変更ログは答えられる問いが異なります。Flow Logsは、送信元、宛先、ポート、許可または拒否などの通信メタデータを確認するために使います。パケットの内容そのものを記録する仕組みではありません。設定を誰がいつ変更したかは、CloudTrailなどの監査ログで追います。
- 平常時：拒否数、外向き通信量、想定外の宛先、ログ欠落を確認する。
- 変更時：IaCの差分と監査ログを関連付ける。
- 障害時：DNS、Security Group、Network ACL、ルート表、NATまたはファイアウォール、接続先の順に切り分ける。
- 詳細調査：必要な対象と期間を絞ってTraffic Mirroringなどを使う。
Azureの新規構成ではVNet flow logsを使い、既存のNSG flow logsには移行計画を持たせます。保存先はワークロード運用者だけで削除できない権限構成を検討し、保持期間は調査と監査の要件から決めます。監視項目の設計は、Amazon CloudWatch、Cloud Monitoring、Azure Monitorの比較で補えます。
コストは通信経路で見積もる
ネットワーク費用は、部品の個数だけでは決まりません。NAT、Transit Gateway、ファイアウォール、エンドポイント、Availability Zone間通信、リージョン間通信、インターネット転送、ログ保存を一つの経路として見積もります。
- NATを集中させた場合と各VPCへ置いた場合を、時間料金とデータ処理料金の両方で比較する。
- AWSサービス向け通信が多い場合は、VPC endpointを使う経路とNAT経由を比較する。
- 同じAvailability Zone内で完結できる経路を確認し、意図しないAZ間通信を探す。
- Flow Logsは対象、項目、保存期間、集計方法を決め、収集量を定期的に見直す。
- CDNは転送費だけでなく、キャッシュ率、オリジン負荷、運用要件を含めて評価する。
設計レビューで確認する10項目
- CIDR台帳にオンプレミス、全クラウド、予約範囲が載っているか。
- サブネット名から環境、配置先、用途を判断できるか。
- 受信、送信、ネットワーク間通信の経路を別々に説明できるか。
- デフォルトルートの次の転送先と、その理由が明記されているか。
- Security Groupなどのルールに業務上の根拠と管理者があるか。
- パブリックIPを持つリソースを列挙し、必要性を説明できるか。
- プライベート接続のDNS、経路、権限をまとめて試験したか。
- IPv4とIPv6の両方で受信と送信の制御を確認したか。
- 通信ログと設定変更ログを検索でき、時刻を突き合わせられるか。
- 単一障害点、切り戻し手順、連絡先をRunbookへ記録したか。
障害時の切り分け手順
- 影響範囲を固定する：接続元、接続先、プロトコル、ポート、発生時刻、成功する経路を記録します。
- 名前解決を確認する：期待するIPアドレスが返るか、接続元ごとの差がないかを調べます。
- アクセス制御を確認する：Security Group、Network ACL、クラウドファイアウォールの順に、往路と復路を確認します。
- 経路を確認する：サブネットのルート表、Transit Gatewayなどの経路表、NAT、VPNまたは専用接続を追います。
- 変更履歴と照合する：直前のIaC差分と監査ログを調べ、必要なら承認済みの手順で切り戻します。
よくある質問
Security GroupとNetwork ACLはどちらを中心に使いますか
ワークロード間の通常の許可はSecurity Groupを中心に設計し、サブネット境界で明示的な拒否などが必要な場合にNetwork ACLを加えます。両方を同じルールで二重管理すると、障害時に判断しにくくなります。
NAT Gatewayはハブへ集約すべきですか
一律には決められません。統制点を集めたいVPC数、通信量、Transit Gatewayの処理料金、Availability Zone間通信、可用性を比較します。小規模なら分散配置の方が経路を追いやすい場合があります。
Transit GatewayとVPC Peeringはどう使い分けますか
少数のVPCを直接つなぐだけならVPC Peeringが候補です。接続数が増え、経路分離、オンプレミス接続、共通サービスへの集約が必要ならTransit Gatewayを検討します。将来像だけで複雑なハブを先に作らず、現在の運用要件も判断材料にします。
IPv6はすぐ有効にすべきですか
接続先と運用が対応しているなら有力な選択肢です。ただし、アドレスを追加するだけでは運用できません。受信と送信の制御、DNS、ログ、脆弱性診断、障害対応がIPv6へ対応しているかを確認します。
まとめ
Amazon VPCの設計は、CIDR、ルート表、Security Group、NAT Gatewayといった部品の一覧から始めると、構成が先行しがちです。通信の主体、宛先、経路、制御、記録を先に定義し、必要な機能だけを割り当てます。
Google Cloud VPCやAzure VNetとの比較でも、名称の似た機能をそのまま置き換えるのではなく、ネットワークの範囲と運用モデルを確認します。設計図、CIDR台帳、ルールの根拠、監視、Runbookが同じ方針を示していれば、構成変更や障害対応で迷いにくいネットワークになります。
この記事に関連する株式会社greedenの取り組み
クラウド基盤は、通信経路、権限、監視、障害対応を要件として整理することが出発点です。株式会社greedenは、要件定義から設計、実装、テスト、リリース、保守運用まで、Webシステム開発を一気通貫で支援します。