クラウドの「壁」VPC入門！AWS,Google Cloud,Azureの設計思想を基礎から徹底比較
対象読者
- これからクラウドを学びたいインフラエンジニア、アプリケーションエンジニアの方
- オンプレミスのネットワーク知識はあるけど、各クラウドの違いがよく分からない方
- AWS、GC、Azure、それぞれのネットワーク設計の思想と最新のベストプラクティスを知りたい方
TL;DR
- VPCはクラウド上に作る自分だけのプライベートなネットワーク空間。全てのサービスの土台になります。
- まずはサブネット、ルートテーブル、ゲートウェイといった基本部品の役割をしっかり理解していきましょう。
- ネットワークの範囲が AWS/Azureはリージョン単位、GCはグローバル単位 という点が根本的に違います。
- 複数ネットワークを繋ぐ現代的な方法は、AWSはTransit Gateway、AzureはVirtual WAN、GCはNetwork Connectivity Center です。
第1章: VPCの基礎知識 - クラウドの「土地」を理解しよう
クラウドを触り始めると、まず間違いなく登場するのが「VPC (Virtual Private Cloud)」。これを理解せずにクラウドを使いこなすことはできません。なぜなら、VPCはこれから作るシステム全ての「土地」や「土台」になるからです。
1-1. VPCって、そもそも何？
一言でいうと、VPCは**「巨大なパブリッククラウドの中に、論理的に隔離された自分専用のプライベートネットワークを構築する仕組み」**のことです。
現実世界で自社のオフィスを構えるのを想像してみてください。誰でも入れてしまう広場ではなく、壁と鍵で区切られた安全な専有スペースを借りますよね。VPCは、まさにそのクラウド版です。AWSの公式ドキュメントでは、VPCを次のように説明しています。
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。
Azureではこの機能を「Virtual Network (VNet)」と呼びますが、基本的な概念は同じです。
1-2. なんでVPCが必要なの？
VPCという「壁」を設けることで、主に3つの大きなメリットがあります。
- セキュリティの向上: 外部から意図しないアクセスを防ぎ、サーバーやデータベースといった大切なリソースを安全に保護できます。
-
IPアドレスの自由な設計:
10.0.0.0/16のようなプライベートIPアドレス範囲を自由に割り当て、自社のネットワークポリシーに合わせた管理が可能です。 - オンプレミスとの連携: 自社のデータセンターとVPNなどで安全に接続し、両者を一体のネットワークとして扱うハイブリッドクラウドを構築できます。
1-3. VPCを構成する主要な部品たち
VPCは、いくつかの部品を組み合わせて作られます。ここでは代表的なものを紹介します。
- サブネット: VPCという大きな土地を、目的ごとに区切った小さな「区画」です。「Webサーバーを置く区画」「データベースを置く区画」のように分けます。
- ルートテーブル: サブネットから出ていく通信を、どこに向かわせるかを定義する「交通標識」です。「インターネット向けの通信はこの門へ」「社内向けの通信はこのトンネルへ」といったルールを書き込みます。
- インターネットゲートウェイ: VPCとインターネットを繋ぐための「正面玄関」です。これがないと、外の世界と一切通信できません。
- NATゲートウェイ: プライベートな区画（サブネット）にあるサーバーが、外のインターネットにだけ出ていきたい（例: OSのアップデートなど）場合に使う「裏口」のようなものです。外からは入れませんが、中からは出られます。
- セキュリティ機能 (セキュリティグループ/NSG/ファイアウォール): サーバー単位で「このポートからの通信だけ許可する」といった制御を行う、きめ細やかなファイアウォールです。各部屋の「鍵」や「警備員」のような役割を担います。
これらの関係性を図にすると、以下のようになります。
第2章: 各クラウドの設計思想の違い - ここが面白い！
VPCの基本がわかったところで、いよいよ本題の3社比較です。似ているようで、実は設計の根幹となる思想が大きく異なります。
2-1. ネットワークの「広さ」が全然違う！ (スコープの話)
これが各クラウドの最大の違いと言っても過言ではありません。
-
AWS (VPC) と Azure (VNet): リージョン単位
AWSとAzureのネットワークは、リージョンに閉じたリソースです。東京リージョンで作ったVPC/VNetと、大阪リージョンで作ったVPC/VNetは完全に別物です。もしリージョンをまたいでプライベート通信をしたい場合は、「VPCピアリング」や後述する「Transit Gateway」のような特別な仕組みが追加で必要になります。 -
Google Cloud (VPC): グローバル単位
一方、Google CloudのVPCは最初からグローバルなリソースです。これは非常にユニークな特徴です。VPC ネットワークはグローバル リソースであり、リージョンやゾーンに限定されません。
VPCを1つ作ると、そのネットワークは世界中の全てのリージョンに論理的に広がっています。そのグローバルなVPCの中に、「東京リージョン用のサブネット」や「ロンドン用のサブネット」を配置していくイメージです。これにより、追加設定なしでリージョン間のプライベート通信が可能になります。
この違いを図にすると以下のようになります。
2-2. 「パブリック/プライベート」の定義が違う！ (サブネットの話)
サブネットをインターネットに接続できる「パブリック」にするか、できない「プライベート」にするかの考え方も各社で異なります。
-
AWS: ルートテーブルで決まる、教科書的な分かりやすさ
AWSは非常にシンプルです。サブネットに関連付けられたルートテーブルに、インターネットゲートウェイ(IGW)への経路 (0.0.0.0/0 -> igw-xxxx) があるかどうかで明確に区別されます。- パブリックサブネット: IGWへの経路がある。
- プライベートサブネット: IGWへの経路がない。インターネットに出るにはNATゲートウェイが別途必要。
パブリックサブネットのルートテーブルには、インターネットゲートウェイへのルートが含まれています。
-
Azure: 「出口はあるが、入口はない」デフォルト状態
Azureは少し独特です。サブネット内のリソースは、デフォルトで**「送信（外向き）」通信は可能**です。これはAzureのインフラがSNAT（送信元アドレス変換）を自動で提供してくれるためです。既定では、仮想ネットワーク内のすべてのリソースで、インターネットへの送信接続が可能です。
しかし、「受信（内向き）」通信はできません。インターネットからアクセスできるようにするには、仮想マシンなどにパブリックIPアドレスを明示的に割り当て、さらにNSG(Network Security Group)でポートを開ける必要があります。
-
Google Cloud: ファイアウォールルールが全てを決める
GCには、サブネット自体にパブリック/プライベートという明確な概念はありません。VMに外部IPアドレスを割り当てればインターネットと通信する準備はできますが、実際の通信可否はすべてVPCファイアウォールルールによって制御されます。デフォルトでは全ての受信(内向き)通信が拒否されているため、必要なポート（SSHの22番やHTTPSの443番など）を明示的に許可する必要があります。
第3章: 複数ネットワークの接続 - モダンなハブ＆スポークアーキテクチャ
実際のシステムでは、複数のVPCや、自社のデータセンター（オンプレミス）を接続したいケースが頻繁に発生します。その際のベストプラクティスも、各社で進化しています。
3-1. AWS: Transit Gatewayによるシンプルな集約
かつてAWSでは「Transit VPC」という、ハブ役のVPCに仮想ルーターを立てる構成が主流でしたが、今はこの AWS Transit Gateway (TGW) がベストプラクティスです。これは特定のVPCに属さない、リージョン単位のマネージドな仮想ルーターです。
AWS Transit Gateway は、VPC とオンプレミスネットワークを 1 つのゲートウェイに接続するネットワークトランジットハブです。
各VPCやオンプレ拠点をTGWにアタッチするだけで、ネットワーク間の推移的なルーティング（A→TGW→Bのような通信）が可能になり、管理が劇的に楽になります。
3-2. Azure: Virtual WANによるマネージドハブ
Azureのモダンな答えが Azure Virtual WAN です。考え方はAWSのTGWとよく似ており、Microsoftが管理する「Virtual Hub」に各ネットワークを接続します。
Azure Virtual WAN は、さまざまな接続サービスを 1 つの運用インターフェイスにまとめたネットワーク サービスです。
大規模でグローバルなネットワークも簡単に構築できるのが強みです。
3-3. Google Cloud: Network Connectivity Centerでハブを強化
GCでは、Network Connectivity Center (NCC) を使ったハブアンドスポークがベストプラクティスです。GCの場合、ハブとして機能するVPCは今でも活用しますが、その管理と推移的なルーティングをNCCが担ってくれます。
Network Connectivity Center を使用すると、スポークとして VPC ネットワークとオンプレミス ネットワークを接続し、それらの間でデータ転送を行うことができます。
GCPの強みであるグローバルVPCと組み合わせることで、世界中の拠点をシンプルかつ効率的に接続できます。
第4章: まとめ
最後に、各クラウドのVPCの思想をもう一度おさらいしましょう。
-
AWS: 機能が豊富で実績多数。 ネットワークの構成要素が細かく分かれており、一つ一つを理解して組み立てていくスタイル。情報量が多く、ベストプラクティスが確立されている安心感があります。
-
Google Cloud: シンプル＆グローバル。 最初からグローバルなネットワークが提供されるなど、特に大規模・分散システムの構築をシンプルにするための工夫が随所に存在します。
-
Azure: オンプレミスとの親和性を重視した柔軟な設計。 送信がデフォルトで可能だったり、ハブ＆スポーク構成に複数の選択肢があったりと、既存のエンタープライズ環境からの移行や連携を意識した柔軟な作りが特徴です。
どのクラウドが絶対的に優れているという話ではありません。それぞれの設計思想の違いを理解し、自分たちのシステム要件やチームのスキルセットに最も合ったクラウドを選択することが、成功への鍵となります。（実際は今までの採用実績等で決まっちゃう部分も多く感じますが...）
この記事が、皆さんのクラウドネットワークへの理解を深める第一歩となれば幸いです！