AWS・Azure・GCP — 類似サービスと設計の違い

前提: 三社の導入章を読み、学習ポータルの構成図をそれぞれ作っていること。

1. 対応表の読み方

ここでの対応は「似た目的を扱う候補」であり、API、料金、可用性、権限、性能の互換性を示さない。 Google Cloudの公式サービス比較表も、similar or comparableなサービスを対応付ける資料として使う。公式比較表にも更新日があるため、採用する機能は個別サービスの現行資料で確認する。

2. 用途別対応表

用途	AWS	Azure	GCP
仮想マシン	EC2	Virtual Machines	Compute Engine
VMのグループ管理・伸縮	EC2 Auto Scaling	VM Scale Sets	Managed Instance Groups
Kubernetes	EKS	AKS	GKE
マネージドなコンテナ実行	ECS + Fargate	Container Apps	Cloud Run
イベントからの関数実行	Lambda	Functions	Cloud Run functions
オブジェクト保存	S3	Blob Storage	Cloud Storage
PostgreSQLのマネージド運用	RDS for PostgreSQL	Azure Database for PostgreSQL	Cloud SQL for PostgreSQL
仮想ネットワーク	VPC	VNet	VPC
DNS	Route 53	Azure DNS	Cloud DNS
メトリクス・ログ	CloudWatch	Azure Monitor	Cloud Monitoring / Cloud Logging
操作監査	CloudTrail	Activity Logなど	Cloud Audit Logs
秘密情報管理	Secrets Manager	Key Vault	Secret Manager

これは最初に覚える範囲。サービス全件の暗記より、上の表から三組を選んで仕様の違いを説明する。 Cloud Run functionsは関数実行を学ぶ項目であり、Cloud Runのコンテナ実行と別の汎用VMサービスという意味ではない。公式の関数実行の概要

3. 特に混同しやすい四つの違い

IDと管理階層

AWSアカウント、Azureサブスクリプション、GCPプロジェクトは、いずれも資源を整理する手掛かりだが同じ境界ではない。 AzureはEntra IDテナントとの関係、GCPは組織・フォルダと請求先の関係を別に描く。権限移植では「管理者ロール」という名前を移すより、必要な操作と適用先を列挙して最小権限に組み直す。

ネットワークのスコープ

観点	AWS	Azure	GCP
仮想ネットワーク	リージョン	リージョン	グローバル
サブネット	一つのAZ	VNet内。AZに固定されない	一つのリージョン。複数ゾーンで利用
図の描き直し	AZごとのサブネットを描く	サブネットとゾーン配置を分ける	VPC内にリージョンごとのサブネットを描く

この違いはアドレス計画、リージョン追加、障害範囲の説明に影響する。同じCIDRを使えば同じ設計になるわけではない。

実行基盤とスケール

FargateはECS/EKSと組み合わせて使う実行基盤。Container AppsやCloud Runのサービスモデルとは抽象化の境界が異なる。比較するときはHTTP入口、常駐・ジョブ、同時実行、最小稼働数、ネットワーク接続、デプロイ切替を項目にする。「コンテナを実行できる」だけでは既存アプリの実行条件を満たすと判断できない。

DBとメッセージング

DynamoDB、Cosmos DB、Firestoreは、NoSQLという分類だけで互換と扱わない。キー・パーティション、クエリ、トランザクション、整合性、課金単位を再検討する。同じPostgreSQLでも拡張機能、バージョン、管理権限、バックアップと認証方式が異なり得る。

キュー・イベント配信では、AWSのSQS/SNS/EventBridge、AzureのService Bus/Event Grid、GCPのPub/SubやEventarcなどを用途から絞る。順序、再配信、重複、保持期間、失敗時の扱いを確認してから候補を決め、一列の置換表で済ませない。

4. 移植演習 — 学習ポータルを別クラウドへ

AWS版をAzureまたはGCPへ移す。サービス名の対応だけでなく、次を一枚にまとめる。

維持する要件: 認証、非公開教材、進捗の整合性、RTO/RPO。
書き換える設計: 管理階層、実行ID、権限、サブネットとゾーン。
修正候補: ストレージSDK、署名付きアクセス、秘密情報取得、イベント形式。
移すデータ: PDF、進捗DB、ユーザー識別子と参照関係。
切替と復旧: データ同期、書込停止の必要性、DNS、証明書、戻す条件。
検証: 正常な閲覧、権限外アクセスの拒否、進捗更新、バックアップからの復旧。

解答例: アプリのHTTP APIや業務ロジックは維持できる可能性がある。 S3用の読取処理は移行先のストレージAPIや認証に合わせて修正し、アプリの実行IDも作り直す。 DBのエクスポート・インポートに加えて、切替中の更新をどう扱うかを決める。同じコンテナが起動することと、利用者が以前の進捗を読めることは別の試験として確認する。

5. 理解度チェック

問い	解答の要点
EKS、AKS、GKEなら変更なく移せるか	Kubernetesの共通部分は使えるが、ID、LB、ストレージ、監視などは確認が必要
S3とCloud StorageならSDKも同じか	ネイティブAPIや認証は異なる。互換機能の利用範囲は別途確認
三社ともPostgreSQLなら運用手順も同じか	管理権限、接続、復元、メンテナンスなどを見直す
VM単価が最小の会社を選べば最安か	転送、保存、周辺資源、契約、運用工数を含めて比較する
マルチクラウドを選ぶ理由は何か	具体的な要件上の利益と、追加の運用・同期負担を比較して答える

公式根拠: AWS VPC、Azure VNet、GCP VPC。

次: Cloudflare・ニフクラとその他のクラウド