はじめに：サービス対応表では見えないNW思想の違い
AWSを使っていて、AzureやGCPも学ぼうとしたとき、まずやるのは「サービス名の対応表」を見ることだと思う。Google Cloudの公式にもAWS・AzureとGoogle Cloudのサービス比較表がある。
EC2 = VM = GCE、RDS = Azure SQL = Cloud SQL、S3 = Blob Storage = Cloud Storage…こういう対応は分かりやすい。
しかし、ネットワークについてはサービス名を対応させるだけでは理解できなかった。AWSではECSタスクにENIがついてVPC内にいるのが当たり前。ところがAzureのApp ServiceはデフォルトでVNet外にいて、プライベート化するには■ PE（Private Endpoint）や▲ VNet統合が必要になる。GCPのCloud Runも同じ。この違いは、サービス名の対応表からは見えてこない。
調べていくうちに、そもそも3社ではネットワークの設計思想が根本的に異なることに気づいた。この違いを正しく理解するために、各サービスがどんなIPを持ち、どこから到達でき、どんな機能を内蔵しているかをIPレベルから積み上げて整理してみた。
結論：3社で異なる「マネージド」の意味 ~IaaS/PaaSで理解する思想の違い~
3社の設計思想
3社とも「マネージドサービスを使え」と公式に推奨しているが、その意味が根本的に異なる。
| CSP | 設計思想 | 「マネージドサービスを使え」の意味 |
|---|---|---|
| AWS：ビルディングブロック型（Primitives） | コンピュートはVPC内にENIを持つのがデフォルト。名前解決・振り分け・通信制御は別サービスを組み合わせて実現する | 「EC2に全部載せるな。RDS、SQS、S3等の専用ビルディングブロックを使え。ただし組み合わせは自分でやれ」 |
| Azure：PaaSファースト型 | PaaSはVNet外がデフォルト。名前解決・振り分けはプラットフォームに内蔵されており、プライベート化には追加設定（■ PE / ▲ VNet統合）が必要 | 「VMに全部載せるな。App Service等のPaaSに載せろ。名前解決もスケールもプラットフォームがやる」 |
| GCP：フルマネージド型（Simplicity） | Azureと同様にPaaSはVPC外がデフォルトだが、URL一つで完結する思想。プライベート化にはAzure同様の追加設定（■ PSC / ▲ VPCコネクタ/Direct VPC）が必要 | 「GCEに全部載せるな。Cloud Run等のフルマネージドサービスに載せろ。URL一つで完結する」 |
AWSの「マネージド」は部品が個別にマネージドされている（RDSはDBをマネージド、SQSはキューをマネージド）。ただし組み立ては利用者の仕事。Azure/GCPの「マネージド」は組み立て込みでマネージド。名前解決・振り分け・スケールまでサービスが内蔵している。AzureとGCPの違いは「組み立て込み」の度合いで、Azureは選択肢が多く設定項目も多い（PE、VNet統合、スロット等）。GCPは選択肢を絞って「考えなくていい」方向に振っている。
この思想の違いがIaaS/PaaS/FaaSの密度として表に現れる
各サービスのIPと機能を整理した結果、IaaS / CaaS / PaaS / FaaSの本質的な違いが、種別（そのサービスが何であるか）と機能（何を内蔵しているか）の密度として可視化された。
| 分類 | 例 | 種別密度 | ⚖️ランク | VPC/VNetとの関係 |
|---|---|---|---|---|
| IaaS | EC2、VM、GCE | 💻 | −（振り分けは外付け） | 中にいる |
| CaaS | ECSタスク、AKS、GKE | 💻 | −（振り分けは外付け） | 中にいる |
| PaaS | App Service、Cloud Run | 💻🔀📋 | ⚖️※（スティッキーあり） | 外にいる（プライベート化は追加設定） |
| FaaS | Lambda、Azure Functions、Cloud Functions | 💻🔀📋 | ⚖️※※（最小限） | 外にいる（プライベート化は追加設定） |
IaaS/CaaSは「箱だけ」。種別は💻（コンピュート）のみで、名前解決（📋）も振り分け（🔀）も持たない。オートスケール時のトラフィック制御は、ALBやCloud Mapなど外部の🔀📋サービスを組み合わせて実現する。AWSのECS + ALB + Cloud Mapという構成は、まさにこのビルディングブロック型の典型である。
PaaS/FaaSは「統合型」。種別が💻🔀📋で、名前解決・振り分け・ヘルスチェックをサービス自体が内蔵している。AzureのApp Service、GCPのCloud Run、AWSのLambdaがこれに当たる。利用者が別途LBやDNSを用意する必要がない。オートスケールで増減したインスタンスへの振り分けも、サービス内部でマネージドに行われる。
PaaSとFaaSの違いは⚖️※と⚖️※※に現れる。PaaS（App Service、Cloud Run等）はスティッキーセッション等の制御が可能（⚖️※）。FaaS（Lambda、Cloud Functions等）は「状態を持たない関数」という思想のため、スケール上限（同時実行数等）のみ制御可能でスティッキーセッションなし（⚖️※※）。
パブリックアクセスに注意
PaaS/FaaSはデフォルトでCSPマネージドのパブリックIP（☆共有）でインターネットからアクセス可能。■ PE/■ PSCでプライベートアクセスを追加しても、パブリックアクセスは自動では無効にならない。パブリックアクセスの無効化は明示的な設定が必要であり、■ PEを作成しただけでは、パブリック（☆共有）経由のアクセスが残る。これはAzure（App Service、Azure SQL、Blob Storage等）、GCP（Cloud Run、Cloud SQL等）、AWS（DynamoDB、S3等）で共通の挙動であり、「PEをつけたから安全」と思い込むと見落としやすいポイントである。
目次
1. 凡例
この表ではオートスケール（リソースの増減）自体は扱わない。個々のリソースのIPは固定であり、「スケールするとIPが変わる」のは古いリソースが消え新しいリソースが別のIPで生まれるという話で、レイヤーが異なる。オートスケール時の名前解決・振り分けの問題は、この表の「機能」列で各サービスが何を持っているかとして表現する。
1.1 種別（そのサービスは何か）
| 絵文字 | 意味 | 付与条件 |
|---|---|---|
| 💻 | コンピュート（EC2、ECSタスク、VM、App Service、Cloud Run等） | コンピュートを実行する |
| 🗄️ | DB（RDS、Azure SQL、Cloud SQL等） | DBである |
| 📦 | ストレージ（S3、Blob Storage、Cloud Storage、EFS等） | ネットワーク越しにデータを保持・配信する |
| 🔀 | ネットワーク（トラフィックを中継・振り分け・検査する） | 機能列に⚖️/⚖️※/⚖️※※/💓/🔄のいずれかがある |
| 📋 | 名前解決（配下リソースのIPを解決する） | 機能列に🌐か🏠がある |
1つのサービスが複数の種別を兼ねる場合は絵文字を並記する。AWSでは種別が分かれる傾向があり、Azureでは1サービスに同居する傾向がある（💻🔀📋）。
1.2 機能（オートスケール時の問題をどう解くか）
| 絵文字 | 意味 |
|---|---|
| 🌐 | パブリック名前解決（DNS名でパブリックIPを返す） |
| 🏠 | プライベート名前解決（DNS名でプライベートIPを返す） |
| ⚖️ | 振り分け・フル制御（利用者がターゲットを定義・登録し、振り分けルール・スティッキーセッション等を制御する。ALB、NLB、Cloud LB等） |
| ⚖️※ | 振り分け・制限付き（ターゲットはサービスが自動管理。利用者はスケール上限やスティッキーセッション等の制約を制御可能。Cloud Run、App Service、Container Apps等） |
| ⚖️※※ | 振り分け・最小限（ターゲットはサービスが自動管理。利用者はスケール上限（同時実行数等）のみ制御可能。スティッキーセッションなし。Lambda、Cloud Functions等） |
| 💓 | ヘルスチェック（異常なターゲットの自動除外） |
| 🔄 | リリース制御（異なるバージョン/リビジョン間のトラフィック分割。カナリア、B/G等。⚖️/⚖️※/⚖️※※が同一バージョン内のインスタンス振り分けであるのに対し、🔄はバージョン間の制御） |
| 🛡️ | セキュリティ（WAF、ファイアウォール、DDoS防御、認証・レート制限等のトラフィック検査・遮断）。3種類ある：①自身のIPを持ち中継・検査する（Network Firewall、Azure Firewall）→ 🔀🛡️、②他サービスにアタッチして動作する（AWS WAF、Cloud Armor）→ 🛡️のみ、③ルールセット（SG、NSG、GCP Firewall Rules）→ 🛡️のみ。いずれもIP列は自身のIPの有無を表す |
※ の付記がある場合は、利用者の制御が制限されていることを示す。※の数が多いほど制御度が低い（例：⚖️※ = スティッキーやスケール上限は制御可、⚖️※※ = スケール上限のみ制御可、🏠※ = 名前解決は別サービス依存）。
1.3 パブリックIPの選択肢
| AWS | Azure | GCP | 概念 | 備考 |
|---|---|---|---|---|
| ● EIP | ● 静的 | ● 静的 | 固定パブリックIP。リソースと独立して存在し、付け替え可能 | IGW経由でENI/NICのプライベートIPにNATされる |
| ○ 自動 | ○ 動的 | ○ 動的 | 動的パブリックIP。リソース再作成で変わりうる | IGW経由でNATされる。利用者は制御不可 |
| ☆ 共有 | ☆ 共有 | ☆ 共有 | CSPマネージド共有エンドポイント。全利用者共通のパブリックIP | DNS名はリソース固有だがIPはCSP管理。■ PE/■ PSCでプライベート化しても、パブリックアクセスの無効化は明示的な設定が必要 |
| − | − | − | パブリックIPなし |
1.4 プライベートIPの選択肢
| AWS | Azure | GCP | 概念 | 備考 |
|---|---|---|---|---|
| ● ENI | ● NIC | ● NIC | リソース自身のネットワークインターフェースにプライベートIPが固定で付与される | |
| ■ EP（VPCエンドポイント） | ■ PE（プライベートエンドポイント） | ■ PSC（Private Service Connect） | CSPマネージドサービスへのプライベート接続。エンドポイントにプライベートIPが付与される | 利用者がエンドポイントを作成すれば利用可能 |
| −（不要） | ▲ VNet統合 | ▲ VPCコネクタ / ▲ Direct VPC | PaaSからVPC/VNetへのアウトバウンド専用接続 | AWSにはない。コンピュートが最初からVPC内にいるため不要 |
| ★ 予約（VPC Lattice） | −（該当なし） | −（該当なし） | CSPマネージド予約アドレス（169.254.x.x等） | VPC Lattice固有 |
| − | − | − | プライベートIPなし |
▲がAWSにだけ存在しない理由が、3社の思想の違いを端的に表す。AWSのコンピュート（ECSタスク等）は最初からVPC内にENIを持つので、アウトバウンド専用接続という概念が不要。Azure/GCPのPaaS（App Service、Cloud Run等）はデフォルトでVNet/VPC外にいるため、VPC内リソースにアクセスするには▲が必要になる。
2. AWS：IPと機能の統合表
AWSもプライベートIPを2列（インバウンド/アウトバウンド）で表記する。大半のサービスはENI一つでイン・アウト共用だが、Lambda等はインバウンドとアウトバウンドで仕組みが異なる。
| サービス | 種別 | パブリックIP | プライベート（イン） | プライベート（アウト） | 機能 | 備考 |
|---|---|---|---|---|---|---|
| EC2 | 💻 | ● EIP / ○ 自動 | ● ENI | ● ENI | − | IP持つだけ |
| ECSタスク（awsvpc） | 💻 | ○ 自動 | ● ENI | ● ENI | − | IP持つだけ。オートスケール時の振り分けは外部の🔀📋（ALB等）が必要 |
| RDS | 🗄️ | ○ 自動 | ● ENI | − | − | 受ける側。アウトバウンドなし |
| DynamoDB | 🗄️ | ☆ 共有 | ■ EP（Gateway EP / Interface EP） | − | − | RDSと異なりVPC外のマネージドサービス。Gateway EP（無料、ルートテーブル経由、パブリックIP使用）とInterface EP（PrivateLink、プライベートIP使用、オンプレからも到達可）の2種類あり |
| S3 | 📦 | ☆ 共有 | ■ EP | − | − | |
| EFS | 📦 | − | ● ENI（マウントターゲット） | − | − | NFS。複数EC2/ECS/Lambdaから同時マウント可 |
| ALB（外部） | 🔀📋 | ○ 自動 | ● ENI | ● ENI | 🌐🏠⚖️💓 | L7振り分け。IP固定不可 |
| ALB（内部） | 🔀📋 | − | ● ENI | ● ENI | 🏠⚖️💓 | |
| NLB（外部） | 🔀📋 | ● EIP | ● ENI | ● ENI | 🌐🏠⚖️💓 | L4振り分け。IP固定可 |
| NLB（内部） | 🔀📋 | − | ● ENI | ● ENI | 🏠⚖️💓 | |
| API Gateway（パブリック） | 🔀📋🛡️ | ☆ 共有 | ■ EP | − | 🌐⚖️🛡️ | スロットリング、認証、DDoS防御内蔵 |
| API Gateway（プライベート） | 🔀📋🛡️ | − | ■ EP | − | 🏠⚖️🛡️ | |
| VPC Lattice | 🔀📋🛡️ | − | ★ 予約 | − | 🏠⚖️💓🔄🛡️ | 169.254.171.x。IAM認証内蔵。SGはプレフィックスリストで制御 |
| Service Connect | 🔀📋 | − | ● ENI（サイドカー） | ● ENI（サイドカー） | 🏠⚖️💓 | ECSタスク間のみ。同一名前空間内、VPCまたぎ可 |
| App Mesh（2026/9廃止） | 🔀 | − | ● ENI（サイドカー） | ● ENI（サイドカー） | 🏠※⚖️💓🔄 | ※📋はCloud Map依存。mTLS、サーキットブレーカーあり |
| Cloud Map（パブリック名前空間） | 📋 | ☆ 共有 | ■ EP | − | 🌐🏠 | IPを教えるだけ。中継しない。ECS連携ではプライベートIPが登録される |
| Cloud Map（プライベート名前空間） | 📋 | ☆ 共有 | ■ EP | − | 🏠 | IPを教えるだけ。中継しない |
| Route 53 | 📋 | ☆ 共有 | ■ EP | − | 🌐🏠🔄 | DNS層。加重ルーティング可 |
| NAT Gateway | 🔀 | ● EIP | − | ● ENI | − | アウトバウンド専用。📋なし |
| Amplify Hosting | 📦💻🔀📋 | ☆ 共有 | − | − | 🌐⚖️※💓 | 静的+SSR（Lambda@Edge）。CloudFront統合。プライベート化不可 |
| SageMaker エンドポイント | 💻🔀📋 | ☆ 共有 | ■ EP | ● ENI | 🌐🏠⚖️💓🔄 | 推論。複数バリアント振り分け+カナリア/B/G対応 |
| Lambda（呼ばれる側） | 💻🔀📋 | ☆ 共有 | ■ EP | − | 🌐⚖️※※ | Invoke APIはVPC設定に無関係。☆共有経由で呼ばれる。振り分けは自動。同時実行数のみ制御可 |
| Lambda（呼ぶ側・VPC内） | 💻 | − | − | ● ENI | − | Hyperplane ENI経由でVPC内リソースに到達。外に出るにはNAT GWか■ EP必要 |
| Lambda（呼ぶ側・VPC外） | 💻 | ☆ 共有 | − | − | − | AWS基盤経由で外部に到達。NAT GW不要 |
| AWS WAF | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。ALB・API GW・CloudFrontにアタッチして動作 |
| AWS Shield | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。DDoS防御。CloudFront・ALB等にアタッチ |
| AWS Network Firewall | 🔀🛡️ | − | ● ENI | ● ENI | 🛡️ | 自身のENIを持ちVPC内でトラフィックを中継・検査 |
| セキュリティグループ | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。ENIに付与するルールセット |
| AWSマネージドAPI全般 | − | ☆ 共有 | ■ EP | − | − | KMS、STS、Secrets Manager、ECR、CloudWatch、SNS、SQS、Step Functions、Bedrock等。パブリックAPIあり、VPCエンドポイントでプライベート化可能 |
3. Azure：IPと機能の統合表
AzureはプライベートIPが2列（インバウンド/アウトバウンド）。PaaSはデフォルトでVNet外のため、インバウンドは■ PE、アウトバウンドは▲ VNet統合という別々の仕組みでプライベート化する。
| サービス | 種別 | パブリックIP | プライベート（イン） | プライベート（アウト） | 機能 | 備考 |
|---|---|---|---|---|---|---|
| VM | 💻 | ● 静的 / ○ 動的 | ● NIC | ● NIC | − | IP持つだけ |
| AKSノード | 💻 | ○ 動的 | ● NIC | ● NIC | − | |
| Azure SQL、Cosmos DB等 | 🗄️ | ☆ 共有 | ■ PE | − | − | |
| Blob Storage | 📦 | ☆ 共有 | ■ PE | − | − | |
| Azure Files | 📦 | ☆ 共有 | ■ PE | − | − | SMB/NFS。EFS相当 |
| Azure LB（外部） | 🔀📋 | ● 静的 | − | − | 🌐⚖️💓 | L4 |
| Azure LB（内部） | 🔀📋 | − | ● NIC | − | 🏠⚖️💓 | |
| Application Gateway | 🔀📋🛡️ | ● 静的 | ● NIC | ● NIC | 🌐🏠⚖️💓🔄🛡️ | L7+WAF内蔵。VNet内にデプロイ |
| Front Door | 🔀📋🛡️ | ☆ 共有 | − | − | 🌐⚖️💓🔄🛡️ | グローバルL7+CDN+WAF+DDoS内蔵 |
| App Service（デフォルト） | 💻🔀📋 | ☆ 共有 | − | − | 🌐🏠⚖️※💓 | 名前解決＋振り分け内蔵。VNet外 |
| App Service + ■ PE | 💻🔀📋 | ☆ 共有（無効化可） | ■ PE | − | 🌐🏠⚖️※💓 | インバウンドをプライベート化 |
| App Service + ▲ VNet統合 | 💻🔀📋 | ☆ 共有 | − | ▲ VNet統合 | 🌐🏠⚖️※💓 | アウトバウンドをVNet経由に |
| App Service + ■ + ▲ | 💻🔀📋 | ☆ 共有（無効化可） | ■ PE | ▲ VNet統合 | 🌐🏠⚖️※💓 | 完全プライベート化 |
| Azure Functions（デフォルト） | 💻🔀📋 | ☆ 共有 | − | − | 🌐🏠⚖️※※💓 | App Serviceと同じ基盤。スティッキーセッションなし |
| Azure Functions + ■ + ▲ | 💻🔀📋 | ☆ 共有（無効化可） | ■ PE | ▲ VNet統合 | 🌐🏠⚖️※※💓 | |
| Container Apps（デフォルト） | 💻🔀📋 | ☆ 共有 | ● 環境内DNS | ▲ VNet統合 | 🏠⚖️※💓 | 環境内で名前解決自動 |
| Container Apps + Dapr | 💻🔀📋 | ☆ 共有 | ● 環境内DNS | ▲ VNet統合 | 🏠⚖️※💓🔄 | mTLS、Pub/Sub等 |
| Static Web Apps | 📦💻🔀📋 | ☆ 共有 | ■ PE | ▲ VNet統合 | 🌐⚖️※💓 | Vercel相当。静的+SSR+API統合。■ PE対応 |
| Azure ML エンドポイント | 💻🔀📋 | ☆ 共有 | ■ PE | ▲ VNet統合（マネージドVNet） | 🌐🏠⚖️💓🔄 | SageMakerエンドポイント相当。トラフィック分割対応 |
| API Management | 🔀📋🛡️ | ☆ 共有 | ■ PE | ▲ VNet統合 | 🌐🏠⚖️💓🔄🛡️ | 認証、レート制限内蔵 |
| Azure DNS | 📋 | ☆ 共有 | − | − | 🌐🏠🔄 | Route 53相当 |
| NAT Gateway | 🔀 | ● 静的 | − | − | − | アウトバウンド専用 |
| Azure Firewall | 🔀🛡️ | ● 静的 | ● NIC | ● NIC | 🛡️ | 自身のIPを持ちVNet内で中継・検査。FQDN/アプリケーションルール対応 |
| Azure WAF | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。Application Gateway・Front Doorに内蔵される形で動作 |
| Azure DDoS Protection | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。VNet全体に適用 |
| NSG | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。NIC・サブネットに付与するルールセット |
| AzureマネージドAPI全般 | − | ☆ 共有 | ■ PE | − | − | Key Vault、Service Bus、Event Hubs、Azure Container Registry、Azure OpenAI等。パブリックAPIあり、PEでプライベート化可能 |
4. GCP：IPと機能の統合表
GCPもAzureと同様にプライベートIPが2列。PaaSはデフォルトでVPC外。Azureとの違いは、Cloud Runがゼロスケール対応であること、中間の選択肢（Container Apps+Daprに相当するもの）が少なく、Cloud RunかGKE+Istioの二択に近いこと。
| サービス | 種別 | パブリックIP | プライベート（イン） | プライベート（アウト） | 機能 | 備考 |
|---|---|---|---|---|---|---|
| GCE（Compute Engine） | 💻 | ● 静的 / ○ 動的 | ● NIC | ● NIC | − | IP持つだけ |
| GKEノード | 💻 | ○ 動的 | ● NIC | ● NIC | − | |
| Cloud SQL | 🗄️ | ☆ 共有 | ■ PSC | − | − | Private Services Accessでも● NIC相当のプライベートIP付与可 |
| Cloud Storage | 📦 | ☆ 共有 | ■ PSC | − | − | |
| Filestore | 📦 | − | ● NIC | − | − | NFS。EFS / Azure Files相当。VPC内にデプロイ |
| Cloud Load Balancing（外部） | 🔀📋 | ● 静的 | − | − | 🌐⚖️💓🔄 | グローバルL7/リージョナルL4。加重ルーティング可 |
| Cloud Load Balancing（内部） | 🔀📋 | − | ● NIC | − | 🏠⚖️💓🔄 | |
| Cloud Run（デフォルト） | 💻🔀📋 | ☆ 共有 | − | − | 🌐🏠⚖️※💓 | URL一つで完結。ゼロスケール対応。VPC外 |
| Cloud Run + ingress internal | 💻🔀📋 | − | 内部LBまたは■ PSC経由 | − | 🏠⚖️※💓 | インバウンドを内部のみに制限 |
| Cloud Run + ▲ VPCコネクタ | 💻🔀📋 | ☆ 共有 | − | ▲ VPCコネクタ | 🌐🏠⚖️※💓 | アウトバウンドをVPC経由に |
| Cloud Run + ▲ Direct VPC | 💻🔀📋 | ☆ 共有 | − | ▲ Direct VPC | 🌐🏠⚖️※💓 | コネクタ不要の新方式。低レイテンシ |
| Cloud Functions（デフォルト） | 💻🔀📋 | ☆ 共有 | − | − | 🌐🏠⚖️※※💓 | Cloud Runと同じ基盤。スティッキーセッションなし |
| Cloud Functions + ▲ VPCコネクタ | 💻🔀📋 | ☆ 共有 | − | ▲ VPCコネクタ | 🌐🏠⚖️※※💓 | |
| Firebase Hosting | 📦💻🔀📋 | ☆ 共有 | − | − | 🌐⚖️※💓 | Amplify相当。静的+Cloud Run統合。プライベート化不可 |
| Vertex AI エンドポイント | 💻🔀📋 | ☆ 共有 | ■ PSC | ● NIC（VPCピアリング経由） | 🌐🏠⚖️💓🔄 | SageMaker / Azure MLエンドポイント相当。トラフィック分割対応 |
| GKE + kube-dns | 💻🔀📋 | ○ 動的 | ● NIC | ● NIC | 🏠⚖️💓 | K8s標準機能 |
| GKE + Istio | 💻🔀📋 | ○ 動的 | ● NIC | ● NIC | 🏠⚖️💓🔄 | mTLS、カナリア。運用が重い |
| Cloud DNS | 📋 | ☆ 共有 | − | − | 🌐🏠🔄 | Route 53 / Azure DNS相当 |
| Cloud NAT | 🔀 | ● 静的 | − | − | − | アウトバウンド専用 |
| Cloud Armor | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。Cloud Load Balancingにアタッチして動作 |
| GCP Firewall Rules | 🛡️ | − | − | − | 🛡️ | 自身のIPなし。VPC・VMに付与するルールセット。SG/NSG相当 |
| GCPサービスAPI全般 | − | ☆ 共有 | ■ PSC | − | − | Cloud KMS、Artifact Registry、Pub/Sub等。Private Google Access有効ならVPCからパブリックIP不要で到達可能 |
5. 3社比較で見えること
5.1 種別列の密度が思想を表す
- AWS：💻と🔀📋が別の行。ECSタスク（💻）+ ALB（🔀📋）+ Cloud Map（📋）を組み合わせる。ただしLambdaは例外で💻🔀📋を1行で持ち、App Service/Cloud Runと同じ統合型
- Azure：App Serviceが💻🔀📋を1行で持つ。1サービスで名前解決＋振り分け＋コンピュートが完結
- GCP：Cloud Runが💻🔀📋を1行で持つ。Azureと同じだがゼロスケール対応で更にシンプル
5.2 ⚖️の3ランクが設計思想を表す
- ⚖️（フル制御）：ALB、NLB、Cloud LB等。利用者がターゲットを登録し、振り分けルール・スティッキーセッション等を定義する。EC2/ECSはこれを外部に用意しないとオートスケール時の振り分けができない
- ⚖️※（制限付き）：App Service、Cloud Run、Container Apps等。ターゲットはサービスが自動管理。利用者はスケール上限やスティッキーセッション等の制約を制御可能
- ⚖️※※（最小限）：Lambda、Cloud Functions、Azure Functions等。ターゲットはサービスが自動管理。利用者はスケール上限（同時実行数等）のみ制御可能。スティッキーセッションなし
- 🔄（リリース制御）：上記3ランクとは別の軸。同一バージョン内のインスタンス振り分け（⚖️）ではなく、異なるバージョン間のトラフィック分割（カナリア、B/G等）
5.3 プライベートIP列の数が思想を表す
- AWS：2列だが、大半のサービスはイン・アウトとも● ENIで同じ値。コンピュートが最初からVPC内にいるため。ただしLambdaのようにインバウンド（☆ 共有 / ■ EP）とアウトバウンド（● ENI）が異なるサービスもある
- Azure/GCP：2列。■ PE/■ PSC（インバウンド）と▲ VNet統合/▲ VPCコネクタ（アウトバウンド）が別の仕組み。PaaSがデフォルトでVNet/VPC外にいるため
5.4 プライベート化の方向が逆
- AWS：デフォルトでVPC内（プライベート）。パブリックにするには追加設定（パブリックIP付与、IGW、ALB等）
- Azure/GCP：デフォルトでパブリック（☆ 共有）。プライベートにするには追加設定（■ PE/■ PSC、▲ VNet統合/▲ VPCコネクタ）
5.5 ▲がAWSにだけない理由
AWSのECSタスクは最初からVPC内にENIを持つので、「PaaSからVPCに接続する」という概念自体が不要。Azure/GCPのPaaSは「VPCの外に存在するサービスを、必要に応じてVPCに接続する」という逆の思想のため、▲というAWSにはない仕組みが必要になる。
5.6 🛡️の付与基準
セキュリティサービスは3種類に分かれ、IP列の値でその違いが可視化される。
- 🔀🛡️（自身のIPを持ち中継・検査する）：AWS Network Firewall、Azure Firewall。VPC/VNet内にENI/NICを持ち、トラフィックを中継しながら検査する。GCPには対応するマネージドサービスがない（Cloud Armorはアタッチ型）
- 🛡️（アタッチ型）：AWS WAF、AWS Shield、Azure WAF、Azure DDoS Protection、Cloud Armor。自身のIPを持たず、ALB・API Gateway・LB等にアタッチして動作する
- 🛡️（ルールセット）：SG、NSG、GCP Firewall Rules。自身のIPを持たず、ENI/NIC・サブネット・VPCに付与されるルール
また、API Gateway・VPC Lattice・Application Gateway・Front Door・API Managementのように、セキュリティ機能を内蔵するサービスは種別に🛡️を並記する（🔀📋🛡️等）。
5.7 📋名前解決は至るところにある
名前解決＝Route 53やCloud DNSだけだと思いがちだが、表の📋を数えると驚くほど多い。ALB、API Gateway、Lambda、App Service、Cloud Run、SageMaker、Amplify…振り分けや中継をするサービスは全て何らかの名前解決をしている。「カスタムドメインを使う」のはDNSサービス（Route 53、Azure DNS、Cloud DNS）の仕事だが、「サービスが自動で割り当てたDNS名でトラフィックを届ける」という意味での名前解決は、ほぼ全ての🔀サービスに内蔵されている。
5.8 機能列を眺めるだけで設計判断ができる
⚖️の3ランクと🔄の組み合わせパターンを見るだけで、各サービスの性格が浮かび上がる。
| パターン | 意味 | 例 |
|---|---|---|
| ⚖️💓 | フル制御LB | ALB、NLB |
| ⚖️💓🔄 | フル制御+カナリア | Cloud LB、VPC Lattice |
| ⚖️※💓 | 自動振り分け+スティッキー可 | Cloud Run、App Service |
| ⚖️※💓🔄 | 自動振り分け+カナリア | Container Apps+Dapr |
| ⚖️※※ | 全自動・最小限 | Lambda、Cloud Functions |
| − | 何もなし、箱だけ | EC2、ECS |
EC2/ECSの「−」が一番雄弁である。何も持っていないからこそ、ALBやCloud Mapを外付けする必要がある。それがAWSの「ビルディングブロック型」の本質であり、逆にLambdaやCloud Runの行に⚖️※や⚖️※※が並んでいるのは、これらがPaaS/FaaSとして「統合型」であることの証拠である。