【2026年8月版】AWS / Google Cloud / Azure / Cloudflare 徹底比較#

第0部 この記事の読み方#

0-1 なぜこの記事を書いたか#

クラウド比較記事は世の中に無数にある。しかしその大半は、次のいずれかの問題を抱えている。

1. 3社比較で止まっている — AWS / Google Cloud / Azure の3社を比べ、Cloudflare を「CDN の会社」として除外している。2026年現在、Cloudflare はサーバーレス実行環境・オブジェクトストレージ・SQL データベース・Iceberg カタログ・分散クエリエンジン・シークレット管理・コンテナ実行までを提供する、独立した第4のクラウドである。比較対象から外す理由はもうない。
2. 「ある/ない」しか書いていない — サービス名を並べた対応表は作れても、「対応するものがない」ときに何をすればいいかが書かれていない。実務で困るのは、まさにその「ない」ケースである。
3. 組織設計とネットワーク設計が抜けている — 実際のエンタープライズ導入で最も揉めるのは、どのマネージド DB を選ぶかではない。アカウントをどう分けるかと、閉域網をどう作るかである。ここを扱った比較記事はほとんど存在しない。
4. 情報が古い — 2024〜2026年はサービスの改称・統廃合・方針転換が異常に多かった時期である。AWS CodeCommit は一度「終了」と announced されてから GA に復帰し、QuickSight は2回改称し、Azure CDN は提供元の倒産で消滅し、マルチクラウド閉域接続は2026年にネイティブサービス化した。古い記事を読むと確実に事故る。

この記事は、この4点すべてを埋めることを目的としている。

0-2 スコープ#

0-3 表の凡例#

本記事のすべての対応表は、以下の記号で統一している。

「❌」には必ず代替手段を併記する。これが本記事の設計方針である。「Cloudflare に KMS はない」で終わらせず、「だから Workers から AWS KMS / Google Cloud KMS を呼ぶか、Secrets Store（🟡）で代替する」まで書く。

0-4 情報の鮮度と検証方法#

• 基準日: 2026年8月17日
• 一次情報として以下を使用した。二次情報（技術ブログ・まとめ記事）は、一次情報で裏が取れたものだけを採用している。
  • Google Cloud 公式「Compare AWS and Azure services to Google Cloud」サービス対応表
  • Microsoft Learn「Azure for AWS Professionals」サービス対応表（更新日 2026-08-04）
  • AWS ドキュメント「AWS services by category」
  • Cloudflare Developer Docs「Products」および各プロダクトの Changelog
  • 各社 What's New / Release Notes / 公式 FAQ
• GA / Preview の判定は、該当プロダクトの公式ドキュメントまたは What's New の記述に基づく。

免責: クラウドのサービス状況は週単位で変わる。特に Preview → GA の遷移と、リージョン展開状況は変動が激しい。本番の意思決定に使う際は、必ず該当日時点の公式ドキュメントで再確認してほしい。第7部に、本記事で参照した URL の一覧を確認日つきで掲載している。

第1部 4クラウドの立ち位置（2026年8月時点）#

1-1 それぞれの「出自」がアーキテクチャを決めている#

4社の違いは、機能の多寡ではなく どこから来たか に起因する。ここを理解すると、後述する組織階層や閉域構成の差が「そういう設計思想だからそうなっている」と腑に落ちる。

AWS — 「計算資源を切り売りする」から始まった#

2006年の S3 / EC2 から始まり、プリミティブな部品を大量に提供し、組み合わせは利用者に任せるというスタンスを一貫して取っている。

その結果として、

• サービス数は4社中最多で、粒度が細かい（キューだけで SQS / SNS / EventBridge / MQ / MSK / Kinesis がある）
• AWS アカウントは ID を一切持たない。ユーザーディレクトリは AWS の関心事ではなかった。これが後に、環境分離の自由度が最も高いという結果につながる
• 逆に、統制・ガバナンスの仕組み（Organizations、Control Tower）は後付けであり、思想が薄い

Google Cloud — 「自社インフラの外販」#

Borg（→ Kubernetes）、Spanner、Dremel（→ BigQuery）、Colossus、B4 ネットワーク。Google が社内で使っていたものを、そのまま外に出したのが Google Cloud である。

その結果として、

• 他社に同等物が存在しないサービスがある（Spanner、BigQuery、VPC Service Controls、TPU）
• VPC がグローバル（AWS / Azure はリージョン単位）。Google の社内ネットワークがそういう作りだったため
• プロジェクトが使い捨て可能で、リソース階層（組織 → フォルダ → プロジェクト）が最初から設計に組み込まれている
• 一方で、社内で使わなくなったものは容赦なく畳む（Cloud Source Repositories、Cloud Domains など）

Azure — 「Windows と Office のエンタープライズ資産の延長」#

Azure の設計は、Active Directory と Office の延長線上にある。

その結果として、

• Microsoft Entra ID テナント = Microsoft 365 テナント。ID がクラウドの最上位境界であり、これが第3部で扱う制約のすべての源になる
• オンプレ AD、Windows Server、SQL Server、M365 との統合は他社の追随を許さない
• 一方で、テナント境界の硬直性と、Entra ID を閉域化できないという構造的な穴を抱える（第4部）

Cloudflare — 「エッジネットワークにコンピュートを載せた」#

CDN / DDoS 防御のために世界348都市にサーバーを置いた結果、リージョンという概念のないクラウドが生まれた。

その結果として、

• Workers は「エッジで動く付加機能」ではなく プラットフォームの本体である（AWS の Lambda@Edge、Azure の Front Door Rules とは位置づけが違う）
• エグレス課金がない（R2）。CDN 事業者として帯域を持っているため
• VM も VPC もブロックストレージも KMS もない。IaaS ではないので、従来型のリフト&シフトの受け皿にはならない
• Durable Objects という、他社に同等物のない「状態を持つサーバーレス実行単位」を持つ

1-2 スケールの比較（2026年8月時点・各社公式）#

※ Azure は公式ページで「リージョン総数」を単一の数値として掲示していない。「他のどのクラウドプロバイダーよりも多いリージョン数」という表現を採っている。二次集計では 70 前後とされることが多いが、この数字には他社が AZ として数える単位が含まれている点に注意。リージョン数の単純比較は各社で数え方が違うため、あまり意味がない。

読み方の注意: 「リージョン数が多い = 優れている」ではない。AWS の1リージョンは複数の物理データセンター（AZ）で構成され、AZ 間で同期レプリケーションが可能な設計になっている。Azure の一部リージョンには AZ がない。日本国内に限れば、AWS は東京・大阪の2リージョン、Google Cloud は東京・大阪、Azure は東日本・西日本で、実質的な選択肢は同じである。

1-3 2026年の3大トピック#

この記事全体を貫く縦串として、2026年に起きた3つの大きな変化を先に示しておく。

トピック1: AI エージェント基盤への全面移行#

2025年までの「基盤モデルを API で叩く」フェーズは終わり、2026年は エージェント（自律実行）の実行基盤 をどこが取るかの競争になっている。

Cloudflare の立ち位置が明確に違う点に注目してほしい。Cloudflare は「賢いモデル」ではなく「エージェントが安全にコードを実行し、状態を持ち、Web をブラウズする場所」を売っている。Dynamic Workers（isolate ベースのサンドボックス）や Sandboxes（永続 Linux 環境）はその文脈の製品である。

トピック2: Apache Iceberg への全社収斂#

データ基盤のロックインが崩れた。4社すべてが、独自フォーマットではなく Apache Iceberg を軸に据えた。

• AWS: S3 Tables（オブジェクトストレージに Iceberg を組み込んだ最初のクラウド。2026年に Iceberg V3 / Variant 型対応）
• Google Cloud: BigQuery + BigLake（BigQuery のマネージド Iceberg テーブル）
• Azure: Microsoft Fabric / OneLake（Delta Lake が主だが Iceberg 相互運用に対応）
• Cloudflare: R2 Data Catalog（Iceberg REST カタログ）+ R2 SQL（独自分散クエリエンジン）+ Pipelines（取り込み）

これは実務的に大きい。データを持ったままクエリエンジンだけ差し替えることが原理的に可能になったからである。第2部 2-7 で詳述する。

トピック3: マルチクラウド閉域接続のネイティブ化（2026年最大の変化）#

これが本記事で最も伝えたい変化である。

2025年まで、「AWS と Azure をインターネットを経由せず閉域で繋ぐ」には、コロケーション施設に自社ルータを置くか、Megaport / Equinix のような中立ファブリック事業者を挟むしかなかった。

2026年、これが変わった。

• 2026年4月: AWS が AWS Interconnect - multicloud を GA。Google Cloud との間で、AWS Direct Connect コンソールから数分でマネージドなプライベート L3 接続を張れるようになった。経路は双方向に自動伝播する。500Mbps（月約160TB相当）の接続が、顧客ごと・リージョンごと・クラウドプロバイダごとに1回線無料。
• 2026年5月: OCI 対応をパブリックプレビューで提供開始。2026年7月に GA。
• Azure 対応は2026年後半予定。
• AWS はこの仕様を Apache 2.0 ライセンスで GitHub に公開しており、事実上の業界標準化を狙っている。

ただし日本では、この新方式はまだ使えない。 AWS Interconnect - multicloud（Google Cloud 側の呼称は Partner Cross-Cloud Interconnect for AWS）の対応ロケーションは 8ペア（シンガポール / シドニー / ストックホルム / ロンドン / フランクフルト / バージニア北部 / オレゴン / 北カリフォルニア）で、東京・大阪は含まれない。

日本で AWS ⇔ Google Cloud を閉域接続するなら、従来型の Cross-Cloud Interconnect（東京・大阪に対応。ただし開通に1〜4週間、エグレス転送料が別途課金）か、Megaport / Equinix Fabric を使うことになる。「新しくて速くて安いほう」はまだ日本に来ていないというのが2026年8月時点の実情である。第5部 5-2-0 で両方式を詳しく比較する。

一方 Google Cloud は2023年から Cross-Cloud Interconnect で AWS / Azure / OCI / Alibaba Cloud に対応済みである（AWS・OCI 向けは 10/100/400 Gbps、Azure・Alibaba 向けは 10/100 Gbps）。

結果として、2026年8月時点でネイティブなクラウド間閉域接続を持たないのは Azure だけ（OCI 向けを除く）という状況になっている。第5部で、この状況を前提にした設計方法を詳述する。

1-4 4社を1枚にまとめると#

次章から、これを分解していく。

→ 第2部 マネージドサービス全対応表

第2部 マネージドサービス全対応表（2026年8月）#

凡例は 第0部 0-3 を参照。✅ GA / 🟡 Preview・Beta / 🔒 Closed Beta / ⚠️ 縮退・移行推奨 / ❌ 該当なし / △ 部分的

すべての表で、Cloudflare 列に「❌」が付く場合は、その下の「❌ の埋め方」に代替手段を記載している。

2-1 コンピュート（サーバー / 仮想マシン）#

❌ の埋め方（Cloudflare）: Cloudflare は VM を提供しない。「リフト&シフト」は原理的に不可能である。Cloudflare を使う場合、VM が必要なコンポーネントは他クラウドかオンプレに置き、Workers VPC（🟡）や Cloudflare Tunnel で接続する構成になる。VM に近いのは Containers（✅ 2026/04 GA、Linux コンテナを Worker から起動）と Sandboxes（永続 Linux 環境）だが、いずれも常駐サーバーではない。

注目ポイント

• 2026年は Arm の本格普及年。Google Axion N4A は同世代 x86 比で最大2倍の価格性能を公称。AWS Graviton は世代を重ね、Azure Cobalt も追随した。新規ワークロードは Arm を第一候補にすべき段階に入った。
• Lightsail に相当する「月額固定・全部込み」の簡易 VPS は AWS にしかない。Google / Azure でこれをやるなら、e2-micro / B1s + 予約インスタンスで近似する。

2-2 コンテナ / Kubernetes#

❌ の埋め方（Cloudflare）: Kubernetes は提供されない。Cloudflare Containers は Durable Object から起動・制御される短命コンテナであり、常駐 Pod・Service・Ingress といった K8s の概念は存在しない。K8s が必要なら他クラウドを併用する。

注目ポイント

• GKE は依然として4社中最も成熟している。Kubernetes の originator であること、Autopilot の完成度、GKE のエージェントサンドボックス（Next '26 で発表、クラスタあたり毎秒300サンドボックス）など、K8s に賭けるなら Google Cloud が有利。
• ECS は AWS 独自であり、他社に移植できない。**「マルチクラウドの可能性を1%でも残すなら ECS ではなく EKS」**という判断は依然として有効。
• Cloudflare Containers の GA（2026/04）では、実際に消費した CPU サイクルのみ課金する active-CPU 課金と、アカウントあたり数千の同時コンテナへのスケールが導入された。

2-3 サーバーレスコンピュート#

❌ の埋め方

• 「状態を持つ実行単位」が AWS / Google Cloud にない問題: Durable Objects は「特定のキーに対して世界で1インスタンスだけが存在し、そのインスタンスがメモリとストレージを持つ」という実行モデルである。AWS でこれを再現するには Lambda + DynamoDB 条件付き書き込み + オプティミスティックロック、あるいは ECS の常駐プロセス + Redis で分散ロックという構成になる。リアルタイム協調編集、ゲームのルーム、チャットのセッション管理、レートリミッタといった用途では、Durable Objects の生産性は他社と桁が違う。
• Cloudflare 以外にエッジ実行がない問題: AWS の Lambda@Edge / CloudFront Functions は CDN の付属機能であり、実行時間・メモリ・利用可能ランタイムに厳しい制約がある。Google Cloud には該当機能がない（Cloud Run はリージョン単位）。「全リクエストをエッジで処理する」設計は、実質 Cloudflare 一択である。

注目ポイント

• Workers for Platforms は「自社の顧客が書いたコードをホストする」ための製品で、他社に同等物がない。SaaS のカスタマイズ機能（顧客がスクリプトを書く）を実装するなら、これが最短経路になる。
• Cloudflare は 2026年8月に Workers Access Protection を追加し、Worker 単位／組織全体で認証ポリシーをかけられるようになった。内部向け Worker の保護が容易になっている。

2-4 ストレージ#

❌ の埋め方（Cloudflare）: R2 以外のストレージ形態は存在しない。ブロック・ファイル・NAS が必要なワークロードは Cloudflare では動かせない。R2 は S3 互換 API を持つため、S3 SDK からそのまま使える点は移行時の大きな利点。

注目ポイント: エグレス課金が構造を変える

EU の Data Act 対応により、2024年以降 AWS / Google / Azure は 「他社へ完全移行する場合のエグレス無償化」 を制度化したが、これは 移行時のみ であり、日常のクロスクラウド転送には適用されない。マルチクラウドでデータを頻繁に往復させる設計なら、データ置き場を R2 にするだけでコスト構造が根本的に変わる。これは第5部のマルチクラウド設計に直結する論点である。

2-5 リレーショナルデータベース（SQL）#

❌ の埋め方（Cloudflare）: D1 は SQLite ベースであり、データベースあたりのサイズ上限があるため、汎用の本番 RDBMS の代替にはならない。テナントごとに小さな DB を大量に作る設計（マルチテナント SaaS の1テナント1DB）には向くが、単一の巨大 DB には向かない。Cloudflare 上のアプリから他社の RDBMS に接続する場合は Hyperdrive を使う（コネクションプーリングとクエリキャッシュをエッジで行い、リージョン跨ぎのレイテンシを吸収する）。

注目ポイント: 分散 SQL の三つ巴

Aurora DSQL は GA 時点で AWS Backup / PrivateLink / CloudFormation / CloudTrail / KMS CMK に対応し、2026年2月と5月にリージョンを拡大、2026年7月に CDC が GA になった。「AWS でグローバル強整合の RDBMS」という長年の空白が埋まったのが2025〜2026年の変化である。

注目ポイント: Azure HorizonDB

2026年6月の Microsoft Build で public preview。Rust 製ストレージエンジン + DiskANN ベクトル検索で、最大 128TB / 3,072 vCore、Microsoft Foundry と統合。まだ preview であり、本番採用は時期尚早。現時点で Azure の PostgreSQL 本命は依然として Azure Database for PostgreSQL Flexible Server である。

2-6 NoSQL / KVS / インメモリ / ベクトル#

❌ の埋め方（Cloudflare）: Cloudflare のデータストアは KV（結果整合・読み取り最適化）/ Durable Objects（強整合・単一インスタンス）/ D1（SQL）/ R2（オブジェクト）/ Vectorize（ベクトル） の5種類のみ。グラフ DB や時系列 DB が必要なら他社を使う。ただし Durable Objects の SQLite ストレージにより、「テナントごとに小さな強整合ストア」という用途はかなりカバーできる。

注目ポイント

• S3 Vectors が2026年に GA。インデックスあたりの容量が40倍の20億ベクトルに拡大した。「ベクトル DB を別途立てる」のではなく「オブジェクトストレージにベクトル検索を内蔵する」という storage-first アプローチで、大規模 RAG の TCO を最大90%削減すると公称している。専用ベクトル DB の存在意義が問い直される段階に入った。
• Azure DocumentDB が2025 Ignite で GA。MongoDB 互換であり、Cosmos DB for MongoDB とは別サービスである点に注意。

2-7 データ利活用基盤（DWH / レイクハウス / ETL / ストリーミング / ガバナンス）#

このカテゴリは4社すべてが2024〜2026年に大規模な再編を行っており、古い記事の情報がまったく使えない領域である。

❌ の埋め方（Cloudflare）: Cloudflare Data Platform（Pipelines + R2 Data Catalog + R2 SQL）は 「イベントを取り込み、Iceberg で貯め、SQL で読む」というパスに特化している。ETL のオーケストレーション、データ品質、カタログ UI、BI は存在しない。実務では 「Cloudflare で貯めて、Snowflake / BigQuery / Spark から Iceberg を読む」 というハイブリッドが現実解になる（R2 Data Catalog は標準の Iceberg REST カタログを公開しているため、Spark / Snowflake / PyIceberg から直接繋がる）。エグレス無料なので、この構成はコスト面で強い。

執筆上の重要ポイント: 名称と統廃合の整理

意思決定への影響: Azure でこれから新規にデータ基盤を作るなら Fabric 一択である。Synapse は EOL こそ宣言されていないが、機能追加は止まっており、2026年8月には trusted services access が廃止されて構成変更を強いられた。「Synapse で作って後から Fabric に移す」は二重投資になる。

2-8 マネージド BI#

❌ の埋め方（Cloudflare）: BI は存在しない。R2 Data Catalog の Iceberg テーブルを、Power BI / Looker / Tableau / Metabase など外部 BI から読む構成になる。

注目ポイント: BI はライセンス体系がアーキテクチャを縛る

これは第3部と直結する重要な論点である。

• Power BI は Microsoft 365 のライセンス体系に組み込まれている。Power BI Pro ライセンスはユーザーに紐づき、ユーザーは Entra ID テナントに属する。したがって 「Azure リソースは別サブスクリプションに分けたが、BI だけは本番テナントで見る」 という運用が発生する。BI を環境ごとにテナント分離することは実質不可能である。
• Looker はプラットフォーム課金であり、LookML というコードでモデルを管理するため、dev / prod の分離が Git ワークフローとして自然に成立する。BI の環境分離という観点では Looker が最も素直。
• Amazon Quick はユーザー単位課金で、AWS アカウント単位に閉じるため、アカウント分離とそのまま整合する。

2-9 AI / ML#

❌ の埋め方（Cloudflare）: Cloudflare は「大規模モデルの訓練」も「フルマネージド ML パイプライン」も提供しない。Workers AI は推論のみである。Cloudflare の価値は AI Gateway（複数プロバイダのモデル呼び出しを一元的に観測・制御・キャッシュ・レート制限する）と、エージェントの実行環境にある。2026年8月には Workers AI と AI Gateway の課金が統一され、単一クレジットで複数プロバイダを跨げるようになった。

注目ポイント

• AI Gateway は他社に同等物がない。「Bedrock も Vertex AI も OpenAI も使うが、コストとレイテンシとエラー率を一箇所で見たい」という要求は極めて一般的だが、これを標準で提供しているのは Cloudflare だけである。他社では LiteLLM / Portkey などの OSS・SaaS を自前で運用することになる。
• コーディング支援は AWS が Kiro（自律エージェント型。セッションを跨いで文脈を保持し、PR とフィードバックから学習、バグトリアージとカバレッジ改善を複数リポジトリに跨って実行）で差別化を図っている。

2-10 メッセージング / イベント / API 管理#

❌ の埋め方（Cloudflare）: Pub/Sub 型のファンアウトは Queues + Workers で自作するか、Durable Objects でトピックを実装する。API 管理（開発者ポータル、プラン、マネタイズ）が必要なら Apigee / API Management / Kong を併用する。

注目ポイント

• Apigee は API 管理として頭一つ抜けている。API のマネタイズ（従量課金の請求まで）、開発者ポータル、API hub（ポートフォリオ管理）まで揃っているのは Apigee のみ。AWS の API Gateway には開発者ポータルもマネタイズもない。
• Cloudflare は 2026年に Email Service を追加し、Workers からトランザクションメールを送れるようになった。従来は Email Routing（受信・転送のみ）だったところに送信が加わった形。

2-11 CDN / エッジ / WAF / DDoS#

❌ の埋め方

• 待機列（Waiting Room）が Cloudflare にしかない: チケット販売やセール開始時のアクセス集中制御。他社では ALB + Lambda + DynamoDB でトークン発行キューを自作するか、Queue-it などの SaaS を使う。
• Azure Media Services が消えた: Microsoft は Azure に動画エンコード / ストリーミングのマネージドサービスを持たなくなり、公式にパートナー製品を案内している。Azure で動画配信をやるなら、AWS Elemental か Cloudflare Stream か、Bitmovin / Mux のような SaaS を使うことになる。これは Azure の明確な穴である。

注目ポイント: Azure の CDN 再編は移行必須事項

Azure で CDN を使っているなら、Azure Front Door Standard / Premium への移行が必須である。これはオプションではない。

注目ポイント: DDoS 防御のコスト構造が根本的に違う

Cloudflare は DDoS 防御を「有償オプション」ではなく「前提機能」として提供している。大規模 DDoS のリスクがあるサービスで、コストを抑えたいなら Cloudflare を前段に置くというのは、他クラウドを使っていても十分成立する選択である。

2-12 DNS#

注目ポイント

• Route 53 Resolver Rule は AWS RAM で組織横断共有できる。これが実務上とても効く。アウトバウンドエンドポイントを共有サービスアカウントに1つ作り、ルールを Organizations 全体に共有すれば、全アカウント・全 VPC でオンプレの名前解決が効く。Azure の DNS Private Resolver ルールセットも VNet にリンクする形で同様のことができるが、AWS の RAM 共有のほうが組織横断の運用は素直である。
• Cloudflare Registrar は原価提供（レジストリへの卸値そのまま、マークアップなし）。年間数十〜数百ドメインを持つ企業ではこれだけで無視できない差になる。ただし対応 TLD に制限があり、.jp など一部は扱えない。
• Internal DNS が2026年に GA したことで、Cloudflare は「社内 DNS そのもの」を担えるようになった。第4部で詳述する。

2-13 ネットワーク#

❌ の埋め方

• VPC Service Controls に相当する機能が AWS / Azure にない。これは Google Cloud の明確な優位点である。AWS では SCP + VPC エンドポイントポリシー + aws:PrincipalOrgID 条件キーの組み合わせで近似するが、「BigQuery のデータを組織外にコピーさせない」ような、サービス API レベルでの境界を宣言的に作ることはできない。Azure も同様で、Private Endpoint + ファイアウォール規則の積み上げになる。規制産業で「データが境界を越えないことを証明せよ」と言われたとき、Google Cloud が最も説明しやすい。
• Cloudflare には VPC がない。ただし Workers VPC（🟡Beta） により、Workers から AWS / Azure / GCP / オンプレのプライベートリソースへ到達できる。VPC Services（ホスト・ポート単位で登録し、HTTP と TCP をバインド。DB は Hyperdrive 経由）と VPC Networks（Tunnel / Mesh / WAN のネットワークごとバインドし、fetch() と connect() で任意到達）の2方式がある。ベータ期間中は全 Workers プランで無料。

注目ポイント: VPC のスコープの違いが設計を変える

Google Cloud のグローバル VPC は、マルチリージョン構成の複雑さを劇的に下げる。「東京と大阪とシンガポールに展開する」を1つの VPC で表現できるのは Google Cloud だけである。一方で、障害の影響範囲（blast radius）が広がるという指摘もあり、大規模組織では意図的に VPC を分けることも多い。

2-14 IAM / ディレクトリ / CIAM#

注目ポイント: この表が第3部の前提になる

ここで押さえておくべき決定的な違いは、「クラウドリソースの認可」と「従業員 ID」の結合度である。

• AWS: IAM は AWS アカウント内部で完結する。IAM Identity Center は「外部 IdP と AWS を繋ぐアダプタ」に過ぎない。AWS アカウントを何個作っても、社員の ID には一切影響しない。
• Google Cloud: Cloud IAM の主体（プリンシパル）は Google アカウントであり、それは Cloud Identity / Workspace アカウントに属する。1つの Cloud Identity アカウント = 1つの組織リソースという結合がある。
• Azure: Azure RBAC の主体は Entra ID のユーザー / グループ / サービスプリンシパルであり、Entra ID テナントは M365 テナントと同一物である。サブスクリプションは必ず1つのテナントに属する。
• Cloudflare: Cloudflare 独自のユーザー DB。外部 IdP と SSO 連携できるが、アカウント構造は ID から独立している。

この違いが、次章（第3部）で扱う「環境分離の自由度」をそのまま決めている。

2-15 シークレット / 認証情報 / 鍵管理#

❌ の埋め方（Cloudflare）: Cloudflare には KMS（データ暗号化鍵の管理）がない。これは実務上かなり効く欠落である。

• R2 に保存するデータをアプリ側で暗号化したい → 鍵をどこに置くか問題が発生する
• 回避策1: Workers から AWS KMS / Google Cloud KMS の API を呼ぶ（レイテンシとコストが乗る）
• 回避策2: Secrets Store（🟡 open beta） にマスターキーを置き、Workers 内で暗号化する（Web Crypto API が使える）。ただし beta であり、Workers と AI Gateway の2つの統合しかまだない
• 回避策3: そもそもアプリ層暗号化をやめ、R2 のサーバーサイド暗号化に任せる

注目ポイント: Secrets Manager vs Parameter Store のコスト設計

AWS では、シークレット管理を全部 Secrets Manager でやるとコストが跳ねる。

Google Cloud の Secret Manager と Azure の Key Vault は、この2階層の区別を持たない（Azure は App Configuration が近いが、シークレットは Key Vault に置くのが原則）。AWS だけ「使い分けの設計」が必要という点は、移行時に見落とされやすい。

注目ポイント: Cloudflare の Keyless SSL / Geo Key Manager

他社にない機能として、TLS の秘密鍵を Cloudflare に渡さずに CDN を使う（Keyless SSL）、秘密鍵の保管地域を EU / US などに限定する（Geo Key Manager）がある。金融・公共で「鍵を国外に出せない」要件があるときの解になる。

2-16 ソースコード / アーティファクト / ライブラリ管理 / CI/CD#

❌ の埋め方（Cloudflare）: Git ホスティングもパッケージレジストリもない。Cloudflare Artifacts は「ファイルシステムのアーティファクトをバージョン管理して Workers / API / Git 互換ツールから共有する」という位置づけで、npm レジストリの代替ではない。GitHub / GitLab を併用するのが前提である。

執筆上の重要ポイント: AWS CodeCommit の「復活」を正しく書く

この件は、2026年時点で日本語情報がほぼ古いままになっている。時系列を正確に押さえる。

一方で、AWS は Amazon CodeCatalyst、AWS Proton、S3 Object Lambda を縮退・sunset フェーズに入れている。「AWS の DevOps サービスは全体として整理が進み、CodeCommit / CodeBuild / CodeDeploy / CodePipeline という基本4点セットに回帰した」というのが2026年の正しい理解である。

注目ポイント: アップストリームプロキシは閉域構成で必須

第4部で詳述するが、インターネットに出ない環境でアプリを動かすには、npm / PyPI / Maven の外部リポジトリをどうするかが必ず問題になる。3社とも「外部リポジトリをミラー・プロキシする」機能を持っており（CodeArtifact upstream / Artifact Registry remote repository / Azure Artifacts upstream sources）、これが閉域構成の生命線になる。Cloudflare にはこれがないため、Cloudflare 上のビルドで閉域要件を満たすのは困難である。

2-17 IaC / ガバナンス / ポリシー / コスト管理#

❌ の埋め方（Cloudflare）: ガバナンス機能は他3社に比べて明確に弱い。「この設定を組織全体で禁止する」という宣言的なポリシーエンジンがない。Enterprise の Organizations（🟡beta）でアカウント横断のポリシー共有が始まったばかりである。Cloudflare を大規模組織で使うなら、Terraform + CI での統制（コードレビューで防ぐ）に頼ることになる。

注目ポイント: ガードレールの思想の違い

Azure Policy の自動修復（remediation）は他社にない強みである。「既存の非準拠リソースを一括で直す」ができるのは Azure だけ。一方 AWS の SCP は「そもそも API を叩けなくする」という強制力の強さがあり、思想が違う。AWS は予防、Azure は予防 + 是正、Google は予防と整理するとわかりやすい。

2-18 監視 / ログ / トレース / セキュリティ運用#

❌ の埋め方

• AWS には統合 SIEM/SOAR がない。Security Lake は「セキュリティログを OCSF 形式で集約する基盤」であって、SIEM ではない。実務では Security Lake + Splunk / Sentinel / Sumo Logic / Datadog という構成になる。**SIEM をクラウドベンダーから買いたいなら Google（Security Operations、旧 Chronicle + Siemplify）か Microsoft（Sentinel）**である。
• Cloudflare には分散トレースも APM もない。Workers のオブザーバビリティは Logpush + Workers Analytics Engine + Tail Workers で構成し、Datadog / Baselime / Sentry などに送るのが定番。

注目ポイント: Workers Analytics Engine の存在価値

「無制限カーディナリティの時系列データを、Workers から書き込んで SQL で読む」というサービスは他社にない。CloudWatch カスタムメトリクスはディメンションが増えると急激に高額になるが、Workers Analytics Engine は設計思想からして高カーディナリティ前提である。マルチテナント SaaS で「テナントごとのメトリクス」を取りたいときの選択肢になる。

2-19 ハイブリッド / エッジ / 移行#

注目ポイント: Azure Arc は「他クラウドを Azure で管理する」唯一の実用解

Azure Arc は、オンプレ・AWS・Google Cloud 上のサーバーや Kubernetes クラスタを Azure Resource Manager のリソースとして登録し、Azure Policy / Defender for Cloud / Azure Monitor / Update Manager を適用できるようにする。「マルチクラウドを1つのガバナンス面で管理したい」という要求に対して、4社の中で最も完成度が高い。

ただし注意点がある。Arc エージェントは Microsoft Entra ID への到達性を必要とするため、完全閉域環境では Arc Private Link Scope を使っても Entra ID 向けの経路だけは残さなければならない（第4部 4-4 参照）。

2-20 「そのクラウドにしかない」サービス一覧#

比較表を見るときに最も価値があるのは、「他社にない」列である。以下は、実質的に代替が存在しないサービスをまとめたものである。

AWS にしかない#

Google Cloud にしかない#

Azure にしかない#

Cloudflare にしかない#

2-21 第2部のまとめ#

カテゴリ別に「どこが強いか」を1枚にすると次のようになる。

← 第1部 ｜ → 第3部 組織階層と環境分離

第3部 組織階層・マルチアカウント・環境分離#

クラウド導入プロジェクトで最も揉めるのは、どのマネージド DB を選ぶかではない。アカウントをどう分けるかである。そしてこの設計は、後から変更するコストが極端に高い。

本章では、4クラウドの階層モデルを構造から比較し、「dev / stg / prod / 他社向け開発」をどう分離するか、そして Microsoft 365 テナントとの一致がなぜ限界を持つのかを解剖する。

3-1 階層モデルの構造比較#

3-1-1 全体像#

AWS                     Google Cloud            Azure                        Cloudflare────────────────        ────────────────        ────────────────────         ──────────────Organization            Organization            Microsoft Entra ID テナント   Tenant（パートナー専用） └ Root                  └ Folder                └ Root 管理グループ            └ Organization   └ OU                    └ Folder                └ 管理グループ                  （Enterprise, 1階層）     └ OU（ネスト可）         （最大10階層）            （Root 配下 最大6階層）        └ Account       └ Account             └ Project              └ Subscription                └ Zone（ドメイン）         └ Resource            └ Resource             └ Resource Group                                                        └ Resource

3-1-2 定量比較#

3-1-3 AWS の制約で見落とされがちな点#

AWS Control Tower には、あまり知られていない組み合わせ上限がある。

管理アカウント数 × ガバナンス対象リージョン数 ≦ 150,000

これは CloudFormation StackSets の上限に由来する。たとえば 17リージョンをガバナンス対象にすると、アカウント数の実質上限は約8,800 になる。大規模組織では、ガバナンス対象リージョンを絞る（日本企業なら東京・大阪・バージニア北部の3つに限定するなど）という設計判断が必要になる。

また、OU あたり1,000アカウントという上限は「オプションのコントロールを15個有効にした場合」の目安であり、コントロールを増やすほど登録可能なアカウント数は減る。

3-1-4 Google Cloud のフォルダ階層が最も柔軟な理由#

フォルダは最大10階層まで作れる。これは実務上、次のような複雑な組織構造を素直に表現できることを意味する。

Organization: example.com├── Folder: 事業部A│   ├── Folder: prod│   │   ├── Project: a-prod-web│   │   └── Project: a-prod-batch│   ├── Folder: stg│   └── Folder: dev│       └── Project: a-dev-<開発者名>   ← 一人1プロジェクトで配れる├── Folder: 事業部B├── Folder: 共通基盤│   ├── Project: shared-network      ← 共有 VPC のホストプロジェクト│   ├── Project: shared-logging│   └── Project: shared-secops└── Folder: 受託開発    ├── Folder: 顧客X    └── Folder: 顧客Y

プロジェクトが軽いことが決定的に効く。AWS でアカウントを一人1個配るのは（作成・クローズのコスト、ルートユーザー管理の観点から）躊躇するが、Google Cloud なら開発者一人1プロジェクトを配って、不要になったら消す運用が現実的に回る。

3-1-5 Cloudflare の階層は「ない」に等しい#

Cloudflare には、他3社のような多階層の組織構造がない。

• Account: 課金とリソースの単位。Zone（ドメイン）、Workers、R2 バケットなどが所属する
• Organization（🟡 Enterprise beta）: 複数の Account を1つのダッシュボードで管理する単一階層の仕組み。サブ組織やネストされたコンテナは作れない
• Tenant（✅ GA）: パートナー（リセラー・MSP）向け。Tenant は「他のアカウントとリソースを含む特別な Cloudflare アカウント」であり、パートナー契約を締結した企業に Cloudflare が作成する

つまり、Cloudflare で環境分離をするなら 「環境ごとに Account を作る」 一択である。統制をかけたければ Terraform と CI のレビューで担保するしかない。

3-2 環境分離（dev / stg / prod / 他社向け）の実装パターン#

3-2-1 AWS#

AWS の公式推奨は明快で、**「環境ごとにアカウントを分ける」**である。

Root├── Security OU│   ├── Log Archive アカウント│   └── Audit アカウント├── Infrastructure OU│   ├── Network アカウント（Transit Gateway, Direct Connect）│   └── Shared Services アカウント（Route 53 Resolver, AD, CI/CD）├── Workloads OU│   ├── Prod OU│   │   ├── app-a-prod│   │   └── app-b-prod│   ├── NonProd OU│   │   ├── app-a-stg│   │   ├── app-a-dev│   │   └── app-b-dev│   └── 受託 OU│       ├── 顧客X-prod│       └── 顧客X-dev├── Sandbox OU          ← 個人検証用、SCP で強めに制限、予算アラート必須└── Suspended OU        ← 廃止予定アカウントの隔離（SCP で全 API 拒否）

SCP の当て方の定石:

• Prod OU: 削除保護（CloudTrail の停止禁止、KMS キーの削除禁止）、リージョン制限
• NonProd OU: 高額インスタンスタイプの禁止、リージョン制限
• Sandbox OU: さらに強い制限（Direct Connect・VPN 作成禁止、特定サービスのみ許可）
• Suspended OU: Deny *（証跡の保全だけ残す）

3-2-2 Google Cloud#

フォルダで環境を切り、プロジェクトでアプリを切る。

Organization├── Folder: bootstrap        ← Terraform の state、CI/CD のサービスアカウント├── Folder: common           ← ログ集約、セキュリティ、課金エクスポート├── Folder: network          ← 共有 VPC のホストプロジェクト├── Folder: prod│   └── Project: <app>-prod├── Folder: nonprod│   ├── Project: <app>-stg│   └── Project: <app>-dev└── Folder: development      ← 個人サンドボックス    └── Project: sandbox-<user>

共有 VPC（Shared VPC） が AWS / Azure に対する明確な優位点である。ネットワークをホストプロジェクトに集約し、サービスプロジェクトから借りる形にすると、プロジェクトを増やしてもネットワーク設計が増殖しない。AWS で同等のことをするには VPC 共有（RAM）または VPC ピアリング／TGW が必要で、設定量が段違いに多い。

3-2-3 Azure#

Azure Landing Zones（ALZ）が公式のリファレンス実装である。

Root 管理グループ├── Platform│   ├── Identity        ← ドメインコントローラー等│   ├── Management      ← Log Analytics, Automation│   └── Connectivity    ← Hub VNet, ExpressRoute, Azure Firewall, Private DNS Zone├── Landing Zones│   ├── Corp            ← 閉域（オンプレ接続あり）のワークロード│   └── Online          ← インターネット公開のワークロード├── Sandbox             ← 検証用、Azure Policy で強めに制限└── Decommissioned      ← 廃止予定

環境分離は サブスクリプションで行う。app-a-prod / app-a-stg / app-a-dev をそれぞれ別サブスクリプションにし、管理グループで束ねて Azure Policy をかける。

ここまでは AWS / Google Cloud と大差ない。問題は、これらすべてが同一の Entra ID テナント配下でなければならない、という点である。 次節で詳述する。

3-2-4 Cloudflare#

Organization（Enterprise, 🟡beta）├── Account: example-prod       ← 本番ドメイン、本番 Workers/R2/D1├── Account: example-stg├── Account: example-dev└── Account: example-sandbox

Workers の環境分離は、アカウント分離 と 同一アカウント内の環境（wrangler.toml の [env.production]） の2通りがある。後者は手軽だが、権限分離はできない。本番と非本番でアカウントを分けるのが安全側の設計である。

3-3 ID 基盤との結合度 — なぜ Azure だけ窮屈なのか#

これが本章の中核である。3-1 の表で「ID との結合」の列を再掲する。

3-3-1 AWS: 最も自由#

• 1つの IdP（Entra ID でも Google Workspace でも Okta でも）から、いくつでも独立した AWS Organization を運用できる
• 顧客Xの案件用に別 Organization を作り、社員はそこにも同じ ID でログインする、といった運用が普通にできる
• アカウントを作るたびに「ルートユーザーのメールアドレス」が必要になるのが唯一の面倒。エイリアス（[email protected]）を使うか、専用のメーリングリストを用意するのが定石
• IAM Identity Center は 組織あたり1インスタンス（+ アカウント単位インスタンス）という制約はあるが、環境分離を妨げるものではない

3-3-2 Google Cloud: 「1ドメイン = 1組織」という単純明快なルール#

Google 公式の記述はこうである。

Your Google Workspace or Cloud Identity account is associated with exactly one organization resource. Each Google Workspace or Cloud Identity account is also associated with a primary domain, such as example.com.

つまり、

• example.com の Workspace アカウント → 組織リソース example.com が1つ
• 別の組織リソースが欲しければ → 別のドメインで Cloud Identity / Workspace アカウントを作る

そして重要なのは、Google Cloud のために Workspace は必要ないという点である。Cloud Identity Free を使えば、Workspace（Gmail や Drive）を契約せずに、Google Cloud 用の ID 基盤だけを無料で立てられる。

これにより、次のような分離が公式にサポートされている。

example.com          → Google Workspace（社内 IT。Gmail, Drive, Meet）                       └── 組織リソース example.com（Google Cloud も使うならここ）gcp.example.com      → Cloud Identity Free（開発専用）                       └── 組織リソース gcp.example.com（本番と完全分離）

Google 公式の推奨と注意点:

• 「ほとんどのユースケースでは、1つの組織リソースの下でフォルダを使うことを推奨する」
• 複数の組織リソースを使うべきなのは、「あるアカウントのユーザーに、別のアカウントのユーザーが作ったリソースへアクセスさせたくない場合」
• 実務でよく挙がる理由: 完全な分離が必要、本番と非本番でサポート契約レベルを変えたい、M&A、子会社の独立採算

制約（これを知らずに設計すると詰む）:

• フォルダを別の組織リソースへ移動することはサポートされていない
• 組織ポリシーは各組織リソースに複製が必要
• 全リソースを横断した可視性・統制が失われる
• ドメイン設計の注意: 2つの Cloud Identity / Workspace アカウントを作る場合、一方が他方のサブドメインになる構成は避けるほうが無難（Google Cloud 用のサブドメイン（gcloud.example.com）を使うという別のガイダンスも存在するため、ここは自社のドメイン運用と照らして慎重に決める）

3-3-3 Cloudflare#

Cloudflare のユーザーは Cloudflare 独自のアカウントである。SSO（SAML / OIDC）で外部 IdP と連携できるが、アカウント構造と ID は独立している。したがって環境分離に ID の制約は入らない。

一方で、統制機能が弱い（3-1-5 参照）ため、「分離はできるが、分離されたものを一元管理する仕組みが乏しい」という別種の課題がある。

3-4 M365 テナントとの一致の限界 — 本章の核心#

3-4-1 構造的事実の確認#

まず、動かせない事実を列挙する。

1. Microsoft Entra ID テナントと Microsoft 365 テナントは同一の物である。 分離できない。
2. Microsoft 公式ガイダンス: 「1つの Microsoft Entra テナント内に、複数の Microsoft 365 環境を持つことは避けるべき」
3. Azure サブスクリプションは必ず1つのテナントに属する。 複数のテナントに同時に属することはできない。
4. サブスクリプションはテナント間で移動できるが、移動すると Azure RBAC のロール割り当てがすべて失われる（同一テナント内での移動では失われない）。マネージド ID も作り直しになる。
5. B2B テナントや Azure AD B2C テナントへサブスクリプションを移動することはできない。
6. 課金の所有権とテナントは別軸である。 課金所有権だけを移し、テナントは移動しないという選択が可能。したがって「請求は1本のまま、テナントは複数」という構成は成立する。

3-4-2 何が困らないか（先にこちらを明確にする）#

多くの議論が混乱するのは、「Azure の環境分離ができない」と「M365 の環境分離ができない」を混ぜてしまうからである。Azure リソースの環境分離は、サブスクリプション分離で十分に足りる。

ここまでは AWS / Google Cloud と何ら変わらない。

3-4-3 何が困るか#

困るのは、Entra ID そのもの、または M365 のサービスを触る開発である。

3-4-4 なぜ「同期した開発環境」が作れないのか#

「本番 M365 テナントと同期した dev テナント」が作れない理由は、次の3点である。

1. M365 のデータ（メール、SharePoint サイト、Teams、OneDrive）を別テナントに複製するマネージド機能が存在しない。 テナント間移行ツール（サードパーティ含む）は「移行」のためのものであり、継続同期には向かない。
2. ユーザーの同期は可能だが、限定的である。 Entra ID の cross-tenant synchronization はユーザーを B2B ゲストとして他テナントへ同期できるが、
   • 両テナントに Entra ID P1 または P2 ライセンスが必要
   • 同期は約40分周期
   • デバイスと連絡先は同期されない
   • ハイブリッド ID から変換された B2B ユーザーは対象外
   • クロスクラウド同期では manager 属性が非対応
3. ライセンスが同期されない。 dev テナントのユーザーに Teams / SharePoint を使わせるには、そのテナントで別途ライセンスが必要になる。

つまり「本番と完全に同じ状態の dev テナント」は原理的に作れない。作れるのは「似た構成の別テナント」だけである。この事実を最初にステークホルダーと合意しておかないと、プロジェクト後半で必ず揉める。

3-4-5 Microsoft 365 Developer Program の実態#

「開発用テナントは Microsoft が無料でくれる」という認識は 2024年以降、正しくない。ここは担当者の理解が最も追いついていない領域なので、公式 FAQ に基づいて正確に整理する。

何がもらえるのか#

• Microsoft 365 E5 が有効なサンドボックステナントが無償で提供される
• インスタントサンドボックスとして提供され、数分で使える状態になる
  • Teams / SharePoint / Outlook / Office が事前構成済み
  • 25ユーザーライセンス（管理者1 + テストユーザー24。うち16は事前作成済み）
  • Microsoft Graph のユーザー / メール / カレンダーのサンプルデータ、Teams サンプルデータパックが投入済み

誰がもらえるのか（2026年8月時点の資格要件）#

最も踏まれる罠: Visual Studio の月額サブスクリプション（Professional monthly / Enterprise monthly）は対象外である。「standard」タイプの年間サブスクリプションでなければならない。調達部門が月額プランで契約してしまうと、この特典が使えない。

制約（本番的な検証には向かない理由）#

2026年7月の変更#

2026年7月以降に発行される、対象となる新規エンタープライズ顧客向けインスタントサンドボックスには、アドオン購入機能（commerce capability）が有効化される。サンドボックス内から Microsoft 365 Copilot などの有償ライセンスを直接購入できる。

ただし重要な制約がある。既存の開発者テナント（commerce capability を持たないもの）を、後から commerce 有効なテナントに変換することはできない。必要な場合は新規にプロビジョニングする必要がある。

実務上の結論#

チームで M365 開発をする場合の現実的な選択肢は3つである。

C を推す理由:

• 90日ごとの再作成という不安定さがない
• 25ユーザー / 300GB という制約がない
• 本番と同じライセンス構成を再現できる（Developer Program は E5 固定なので、本番が E3 の企業では検証にならない）
• 会社としての予算計上が数千円〜であり、承認のハードルが低い
• Entra ID P1 / P2 が必要な条件付きアクセスの検証も、必要な分だけ買える

Developer Program は「個人の学習用」と割り切り、チーム開発・受託開発では有償テナントを用意するのが2026年時点の正しい判断である。

3-4-6 複数テナントを運用するための道具と、その限界#

複数テナント運用を余儀なくされた場合に使える機能を整理する。

設計上の重要な帰結: Azure Lighthouse は管理グループを委任できない。したがって「顧客テナントの管理グループ階層ごと自社から管理する」ことはできず、サブスクリプション単位での委任を積み上げる運用になる。受託開発・MSP 事業では、これが運用負荷の主要因になる。

3-5 Google Workspace と Google Cloud — 同期と分離の柔軟さ#

Azure と対比すると、Google の構造がいかに柔軟かがわかる。

3-5-1 3つのパターン#

パターン②が実務上とても重要である。日本企業の多くは社内 IT が M365 だが、Google Cloud を使いたいケースがある。このとき Cloud Identity Free（無償、上限50ユーザーまで無償枠）を別ドメインで立て、外部 IdP として Entra ID を SAML 連携させるという構成が取れる。これにより、

• 社員は Entra ID の認証情報のまま Google Cloud にログインできる
• Google Cloud の組織リソースは M365 テナントから独立している
• Google Workspace のライセンスは1つも買わなくてよい

Azure ではこの逆（M365 テナントとは別の Entra テナントで Azure だけ使う）が、B2B ゲストを介さずには成立しない。

3-5-2 複数組織を作るときの代償#

3-3-2 で述べた制約を、設計判断の観点で再掲する。

推奨: 明確な理由（サポート契約レベルの分離、規制上の完全分離、M&A）がない限り、1組織 + フォルダにすべきである。

3-6 「他社向け開発」の分離設計（受託・SI 事業者向け）#

顧客ごとに環境を分ける必要がある場合の設計を、4クラウドで比較する。

3-6-1 顧客リソースの所有形態は2通り#

3-6-2 クラウド別の実装#

3-6-3 AWS のクロスアカウントアクセスが最も楽な理由#

AWS では、顧客のアカウントに IAM ロールを1つ作ってもらい、自社アカウントの ID を信頼するように設定すれば終わりである。

自社アカウント (111111111111)  └─ IAM ユーザー / IAM Identity Center のユーザー       │  sts:AssumeRole       ▼顧客アカウント (222222222222)  └─ IAM ロール "PartnerAccess"       信頼ポリシー: arn:aws:iam::111111111111:root                    条件: sts:ExternalId = "<顧客ごとの秘密値>"

• 社員は自社の ID のままログインし、ロールを切り替えるだけ
• 顧客が10社あっても、ログインは1回
• 権限の剥奪は顧客側でロールを消せば即座に完了する
• External ID により「混乱した代理人問題（confused deputy）」を防げる

Azure でこれに相当するのが Lighthouse だが、Lighthouse は Azure リソースに限定され、M365 / Entra ID の管理は別途 GDAP（Granular Delegated Admin Privileges）が必要になる。この二重構造が Azure の受託運用を複雑にしている。

3-7 まとめ: 階層と分離の柔軟性#

実務向けの判断フローチャート#

Q1. Microsoft 365 / Entra ID そのものを開発対象にするか？    ├─ YES → 別テナントが必須。Developer Program ではなく    │         有償の小規模テナントを用意する（3-4-5 の選択肢C）    │         テナント間の連携は MTO / cross-tenant sync で最低限を繋ぐ    └─ NO  → Azure リソースの分離はサブスクリプションで十分。テナントは1つでよいQ2. 本番と非本番でサポート契約レベルや監査要件を分ける必要があるか？    ├─ YES → AWS: 別 Organization / GCP: 別組織リソース / Azure: 別テナント    └─ NO  → 単一の組織 + OU / フォルダ / 管理グループQ3. 顧客ごとの完全分離が必要か（受託開発）？    ├─ YES → AWS ならクロスアカウントロールが最も楽    │         Azure なら Lighthouse（Azure）+ GDAP（M365）    │         Cloudflare なら Tenant API    └─ NO  → 自社組織内のフォルダ / OU で分けるQ4. 開発者に個人サンドボックスを配るか？    ├─ YES → GCP が圧倒的に楽（1人1プロジェクト）    │         AWS は Account Factory で自動化、予算アラート必須    │         Azure は Sandbox 管理グループ + サブスクリプション    └─ NO  → 共有 dev 環境で RBAC を分ける

← 第2部 ｜ → 第4部 閉域構成

第4部 閉域構成 — インターネットに出ないクラウドの作り方#

金融・公共・医療・製造の基幹系では、「クラウドを使うが、インターネットには一切出さない」という要件が当たり前に出てくる。具体的には、

クラウドベンダーのネットワーク空間と、自社のイントラネットだけが接続されており、グローバルなインターネットとはインターフェースしない

という構成である。本章では、これを4クラウドでどう実現するか、そしてどこまで実現できて、どこができないのかを明確にする。

4-1 まず「閉域」の定義を固める#

「閉域」という言葉は、話す人によって指すものが違う。議論を始める前に、以下の5段階で定義しておくと、要件のすり合わせが劇的に楽になる。

ユーザーが「閉域」と言うときに求めているのは、通常 L3 〜 L4 である。

そして本章の結論を先に述べておくと、

L3 は AWS / Google Cloud / Azure のいずれでも実現可能である。しかし L4 を完全に達成できるクラウドは存在しない。特に Azure は Microsoft Entra ID が構造的に閉域化できないため、L4 に到達できない。

この「どこに穴があるか」を正確に把握することが、閉域プロジェクトの成否を分ける。

4-2 AWS での閉域構成#

4-2-1 基本構成#

オンプレミス                             AWS┌──────────────┐                    ┌────────────────────────────────┐│ イントラネット  │                    │ Network アカウント               ││              │  Direct Connect     │  ┌──────────────────────┐     ││ ┌──────────┐ │◄──────────────────►│  │ Transit Gateway       │     ││ │ DNS      │ │  (Transit VIF)      │  └──────────┬───────────┘     ││ │ Server   │ │                     │             │                  ││ └────┬─────┘ │                     └─────────────┼──────────────────┘│      │       │                                   │└──────┼───────┘                     ┌─────────────┼──────────────────┐       │                             │ Shared Services アカウント      │       │  条件付きフォワーダ            │  ┌──────────▼───────────┐     │       └────────────────────────────►│  │ Route 53 Resolver     │     │                                      │  │  Inbound Endpoint     │     │                                      │  │  Outbound Endpoint    │     │                                      │  └───────────────────────┘     │                                      └────────────────────────────────┘                                      ┌────────────────────────────────┐                                      │ Workload アカウント             │                                      │  VPC（IGW なし・NAT なし）      │                                      │  ┌──────────────────────┐     │                                      │  │ VPC Endpoints        │     │                                      │  │  - Gateway: S3, DDB  │     │                                      │  │  - Interface: 各種    │     │                                      │  └──────────────────────┘     │                                      └────────────────────────────────┘

4-2-2 実装要素#

4-2-3 AWS の設計上の勘所#

① Resolver を共有サービス VPC に集約し、RAM で共有する

Route 53 Resolver のルールは AWS Resource Access Manager (RAM) で組織全体に共有できる。これが実務上とても効く。

Shared Services アカウント└─ Outbound Endpoint（AZ 冗長で 2 IP）   └─ Resolver Rule: "corp.example.com → 10.0.0.53, 10.0.1.53"      └─ RAM で Organization 全体に共有         └─ 各アカウントの各 VPC に関連付け

これにより、全アカウント・全 VPC でオンプレの名前解決が効く状態を、エンドポイント1組で実現できる。各 VPC にエンドポイントを作る必要はない。

② エンドポイントポリシーを必ず書く

VPC エンドポイントはデフォルトで「全許可」である。これを放置すると、インターネットに出られなくても、S3 経由で他社アカウントのバケットにデータを送れてしまう。

{  "Statement": [{    "Effect": "Allow",    "Principal": "*",    "Action": "s3:*",    "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],    "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" } }  }]}

③ Interface エンドポイントのコストに注意

Interface 型エンドポイントは、AZ あたり時間課金 + データ処理課金である。サービスを増やすほど、AZ を増やすほど、リニアに増える。「とりあえず全部作る」と月額が数十万円になることがある。実際に使うサービスだけを作り、必要なら共有サービス VPC に集約して PrivateLink で各 VPC に配るという設計が有効。

4-2-4 AWS で L4 に届かない部分#

4-3 Google Cloud での閉域構成#

4-3-1 3つの経路の使い分け#

Google Cloud には、Google API へプライベートに到達する方法が3つある。この違いを理解することが最初の関門である。

閉域構成では restricted.googleapis.com + VPC Service Controls の組み合わせが定石である。オンプレの DNS で *.googleapis.com を 199.36.153.4/30 に向け、Cloud Router のカスタム経路広報でこのレンジをオンプレへ広報する。

4-3-2 VPC Service Controls — 他社にない機能#

VPC Service Controls（VPC-SC）は、サービス境界（perimeter） を定義し、その境界を越えるデータの流れを API レベルで遮断する。

┌─ サービス境界 "prod-perimeter" ────────────────────┐│                                                    ││  プロジェクト: prod-data, prod-app                  ││  保護対象サービス: BigQuery, Cloud Storage, KMS ...  ││                                                    ││  境界内 → 境界内: 許可                              ││  境界内 → 境界外: ✕ 遮断（データ持ち出し不可）        ││  境界外 → 境界内: ✕ 遮断（Ingress ルールで例外可）   ││                                                    │└────────────────────────────────────────────────────┘

これにより、「正しい認証情報を持った内部犯行者が、本番の BigQuery データを自分の個人プロジェクトにコピーする」を技術的に阻止できる。IAM だけでは防げない攻撃である。

AWS / Azure には同等の機能が存在しない。 Google 公式のサービス対応表でも、VPC Service Controls の AWS 列・Azure 列は「N/A」と記載されている。規制産業で「データが境界を越えないことを証明せよ」と求められたとき、Google Cloud は他社にない説明力を持つ。

運用上の注意: VPC-SC は強力すぎるため、設定ミスで自分自身が締め出される（Terraform の CI サービスアカウントが境界外にいて apply が失敗する、など）事故が頻発する。必ず dry-run モードで数週間運用し、違反ログを確認してから enforce に切り替えること。

4-3-3 Private Service Connect#

PSC には3つの用途がある。

オンプレから PSC エンドポイントに到達させるには、

1. PSC エンドポイントを作る
2. Cloud Router のカスタム経路広報でエンドポイント IP をオンプレへ広報する
3. Cloud DNS のインバウンド転送ポリシーを有効化し、オンプレ DNS からそのエンドポイントの FQDN を解決できるようにする

という3ステップが必要である。PSC の DNS 設計が Google Cloud 閉域構成で最も複雑な部分であり、ここでつまずくケースが多い。

4-3-4 Cloud DNS の構成要素#

重要: インバウンド転送のエントリポイントは リージョンごとに作られる。オンプレ DNS の条件付きフォワーダは、VLAN アタッチメント（Interconnect）または Cloud VPN トンネルと同じリージョンのエントリポイントを向ける必要がある。

4-4 Azure での閉域構成 — と、構造的な穴#

4-4-1 基本構成（Hub-Spoke）#

オンプレミス                          Azure┌──────────────┐                 ┌──────────────────────────────────────┐│              │  ExpressRoute   │ Hub VNet（Connectivity サブスクリプション）││ ┌──────────┐ │◄───────────────►│  ┌────────────────┐                   ││ │ DNS      │ │  (Private       │  │ ER Gateway     │                   ││ │ Server   │ │   Peering)      │  ├────────────────┤                   ││ └────┬─────┘ │                 │  │ Azure Firewall │  ← 強制トンネリング  ││      │       │                 │  ├────────────────┤                   │└──────┼───────┘                 │  │ DNS Private    │                   │       │                         │  │  Resolver      │                   │       │ 条件付きフォワーダ         │  │  - Inbound EP  │◄──────────────────┘       └────────────────────────►│  │  - Outbound EP │                                 │  └────────────────┘                                 │  Private DNS Zones                                 │   privatelink.blob.core.windows.net                                 │   privatelink.database.windows.net ...                                 └───────────┬──────────────────────────┘                                             │ VNet Peering                                 ┌───────────▼──────────────────────────┐                                 │ Spoke VNet（Landing Zone）            │                                 │  Private Endpoint × N                │                                 └──────────────────────────────────────┘

4-4-2 実装要素#

4-4-3 【最重要】Microsoft Entra ID は閉域化できない#

これが Azure 閉域構成における最大の構造的制約である。

事実:

• Microsoft 公式 FAQ: 「Microsoft Entra ID はサービスエンドポイントをネイティブにサポートしていない」
• login.microsoftonline.com に対するプライベートエンドポイントは提供されていない
• Azure Arc のドキュメントでも明記されている: 「Azure Connected Machine エージェントから Microsoft Entra ID（login.windows.net, login.microsoftonline.com, pas.windows.net）および Resource Manager（management.azure.com）へのネットワークトラフィックは、引き続きパブリックエンドポイントを使用する」

帰結:

Entra ID 認証を使うすべての Azure サービス・エージェントは、Entra ID のパブリックエンドポイントへの経路を必要とする。したがって Azure では L4（管理プレーンを含む完全閉域）が構造的に達成できない。

実務上の回避策:

この事実を、閉域プロジェクトの要件定義フェーズで必ず共有すること。 プロジェクト後半で「完全閉域と言ったのに外に出ている」と指摘されると、設計をやり直すことになる。

4-4-4 その他の Azure 側の穴#

4-4-5 trusted services access の廃止 — Synapse と Data Factory で日付が違う#

「信頼されたサービス（trusted services）」とは、ストレージアカウントのファイアウォールをバイパスして、Microsoft の特定サービスからのアクセスを許可する仕組みである。これが廃止されると、閉域構成への移行が事実上強制される。

この2つは日付が違うため、混同しないこと。 ネット上の情報では「2026年8月」と「2027年8月」が入り混じっているが、原因はこの2サービスの取り違えである。

Azure Data Factory 側で廃止される具体的な機能（2027年8月）#

Microsoft の公式回答によれば、廃止対象は「レガシーの信頼されたサービス機能」であり、具体的には次の3つの利用パターンである。

1. セルフホステッド統合ランタイム（SHIR） が、システム割り当てマネージド ID を使って Azure Storage にアクセスするパターン
2. Azure-SSIS 統合ランタイム が、Storage Connection Manager を経由してアクセスするパターン
3. REST リンクサービス / Web アクティビティ が、trusted service のファイアウォール例外を通じて Azure Storage または Azure Key Vault にアクセスするパターン

移行先: Modern mode for trusted service firewall bypass#

代替となる「Modern mode」がサポートするアクセスパターンは次の3つである。

• IP 許可リスト
• マネージド仮想ネットワーク（Data Factory のマネージド VNet + マネージドプライベートエンドポイント）
• 顧客所有の仮想ネットワーク

閉域構成の観点では、マネージド VNet または顧客所有 VNet を選ぶことになる。 IP 許可リストは閉域要件を満たさない。

移行の進め方#

Microsoft は 2027年8月より十分前に移行を完了することを推奨しており、まず非本番の Data Factory から移行して疎通を検証し、その後に本番環境を更新する手順を案内している。

押さえるべきこと: 「2026年8月1日」は Synapse の話であり、Data Factory には2026年8月の廃止日は存在しない。Synapse を使っていない組織が、この日付を見て慌てて Data Factory の構成を変更する必要はない。逆に Synapse を使っているなら、その対応はすでに期限を過ぎている。

4-5 Cloudflare での「閉域相当」構成 — 発想が違う#

Cloudflare には VPC がない。したがって「VPC をインターネットから切り離す」という発想自体が成立しない。Cloudflare のモデルはこうである。

オンプレと各クラウドを Cloudflare のネットワークに接続し、Cloudflare の内側でのみ到達可能にする。

4-5-1 構成要素#

4-5-2 Workers VPC の2方式#

Workers からのリクエストは Cloudflare Gateway を経由するため、既存の DNS / HTTP / ネットワークポリシーがそのまま適用される。ベータ期間中は全 Workers プランで無料。

4-5-3 Cloudflare の閉域における位置づけ#

正確に言えば、Cloudflare は「閉域網の代替」ではなく「閉域網へのゼロトラストアクセス層」である。

• オンプレ ⇔ AWS の L3 閉域接続そのものは、Direct Connect / ExpressRoute のような専用線が担う
• Cloudflare が担うのは、「誰が / どの端末が / どのアプリに到達してよいか」の制御と、その通信経路の暗号化・最適化
• Cloudflare のネットワークを経由する以上、厳密な意味での「自社イントラとクラウドだけが繋がっている」状態ではない（Cloudflare という第三者のネットワークを通る）

したがって、監査要件が「通信が第三者のネットワークを一切経由しないこと」である場合、Cloudflare は要件を満たさない。一方、「インターネットに公開されたエンドポイントが存在しないこと」「認証されたアクセスのみが到達すること」が要件なら、Cloudflare Tunnel は極めて有効である（受信ポートを1つも開けないため、ポートスキャンで発見されることすらない）。

4-6 オンプレ DNS との統合パターン集#

閉域構成における最大の実装課題は、ネットワークではなく DNS である。ここを設計し損ねると、「疎通はするのに名前が引けない」という状態で数日溶ける。

4-6-1 パターン1: 条件付きフォワーダ方式（最も一般的）#

オンプレの DNS サーバー（Windows DNS / BIND / Infoblox）に、クラウドのドメインに対する条件付きフォワーダを設定する。

Azure の注意点: privatelink.* のゾーンはサービスごとに別々である。Blob、SQL、Key Vault、App Service、AKS…と、使うサービスの数だけ条件付きフォワーダが必要になる。実務では privatelink.* の親ドメインごとフォワードするか、Azure 側の全ゾーンをまとめてフォワードする設計にする。

4-6-2 パターン2: ゾーン委任方式#

社内ドメインのサブドメインをクラウドに委任する。

corp.example.com          → オンプレの DNS が権威├── aws.corp.example.com  → NS レコードで Route 53 Inbound Endpoint に委任├── gcp.corp.example.com  → Cloud DNS に委任└── az.corp.example.com   → Azure DNS に委任

利点: フォワーダの数が増えない。名前空間が整理される。 欠点: PaaS のサービス固有 FQDN（*.blob.core.windows.net 等）はこの方式では扱えないため、パターン1との併用になる。

4-6-3 パターン3: 双方向フォワード#

クラウド → オンプレの方向も設定する。これがないと、クラウド上のアプリから社内 AD やオンプレ DB の名前が引けない。

4-6-4 パターン4: Hub 集約方式#

DNS 機能を共有サービス VPC / Hub VNet に集約し、全 spoke から参照する。

Hub（共有サービス）├── Route 53 Resolver Inbound / Outbound Endpoint│   （または DNS Private Resolver / Cloud DNS）└── プライベート DNS ゾーンを集中管理Spoke A ──┐Spoke B ──┼─→ Hub の DNS を参照（Azure なら VNet の DNS サーバー設定、Spoke C ──┘    AWS なら Resolver Rule の関連付け、GCP なら DNS ピアリング）

Azure での定石: すべての privatelink.* ゾーンを Hub（Connectivity サブスクリプション）に置き、**Azure Policy で「Private Endpoint 作成時に Hub のゾーンへ A レコードを自動登録する」**を強制する。これをやらないと、開発者が Private Endpoint を作るたびに DNS レコードが漏れて名前が引けない、という事故が起きる。

4-6-5 パターン5: マルチクラウド3方向（第5部に接続）#

オンプレ + 3クラウドで、名前空間をどう割るか。

corp.example.com          ← オンプレ（権威）├── aws.corp.example.com  ← AWS├── gcp.corp.example.com  ← Google Cloud└── az.corp.example.com   ← Azure

クラウド間のフォワードをメッシュにすると N×N になって破綻する。 オンプレの DNS をハブにして、すべてのクラウドがオンプレへフォワードし、オンプレが各クラウドへ振り分ける ハブ&スポーク型にすること。詳細は第5部 5-4 で扱う。

4-6-6 障害時の挙動を必ず検証する#

• フォワード先がダウンしたとき、フォールバックするか、タイムアウトするか
• 条件付きフォワーダのタイムアウト値（Windows DNS のデフォルトは短すぎることがある）
• リゾルバエンドポイントの冗長化（AWS は IP あたり約10,000 QPS。多くの組織では エンドポイントあたり 2 IP で十分）
• DNS キャッシュの TTL 設計（Private Endpoint の IP を変更したときの反映時間）

4-7 閉域構成の落とし穴チェックリスト#

閉域構成が失敗する原因の9割は、ネットワーク設計ではなく 「思わぬところでインターネットが必要になる」 ことである。以下は実際に踏まれるものを網羅したチェックリストである。

4-7-1 OS・ミドルウェア#

4-7-2 アプリケーション依存#

4-7-3 クラウドエージェント#

各社の管理エージェントは、それぞれ通信先を持つ。すべてがプライベートエンドポイントに対応しているとは限らない。

4-7-4 IdP・管理プレーン#

共通の結論: 管理コンソールへのアクセスは、閉域網の外（社内 PC からプロキシ経由など）で行うという運用が現実的である。「クラウド上の VM から管理コンソールを開く」ことを前提にしない。

4-7-5 SaaS 型の運用ツール#

• 監視 SaaS（Datadog、New Relic、Splunk Cloud）→ エージェントの送信先がインターネット
  • 対策: 各社が PrivateLink / Private Service Connect 対応のエンドポイントを提供している場合がある。契約前に確認する
• CI/CD の SaaS runner（GitHub Actions、CircleCI）→ 閉域内にセルフホストランナーを置く
• 脆弱性スキャン、SBOM 生成 → 脆弱性データベースの更新経路が必要

4-8 閉域構成のやりやすさ比較#

総括#

• 「データを絶対に外に出さない」が最優先なら Google Cloud。VPC Service Controls は他社にない。
• 「実装が枯れていて情報が多い」なら AWS。PrivateLink の網羅性、Resolver の RAM 共有、事例の豊富さ。
• Azure は、Entra ID の穴を許容できるかを最初に確認する。許容できるなら（そして多くの場合は FQDN 許可リストで実務上許容される）、Private Endpoint + DNS Private Resolver で L3 は問題なく構築できる。
• Cloudflare は閉域網そのものではないが、「公開エンドポイントをゼロにする」という別解を提供する。オンプレとクラウドのハイブリッド環境で、VPN の代替として極めて有効。

← 第3部 ｜ → 第5部 マルチクラウド閉域接続

第5部 マルチクラウド閉域接続 — 2026年の最重要アップデート#

「AWS と Azure を、インターネットを経由せずに接続したい」。この要求は、マルチクラウドを採用したほぼすべての組織が直面する。そして2025年まで、その答えは常に「自分で作るしかない」だった。

2026年、この状況が変わった。本章では、何が変わって、何が変わっていないのかを正確に整理し、非対応の組合せを独自構築する方法を実装レベルで示す。

5-1 2026年8月時点の対応状況マトリクス#

5-1-1 ネイティブサービスによる相互接続#

※ Google Cloud の Cross-Cloud Interconnect は Alibaba Cloud（10/100 Gbps）にも対応。 ※ AWS ⇔ Google Cloud には方式が2つある（従来型 / Partner 型）。日本で使えるのは従来型のみ。詳細は 5-2-0。

5-1-2 読み解き方#

この表から読み取るべきことは3つある。

① Google Cloud は2023年から全方位に対応している

Cross-Cloud Interconnect は AWS / Azure / OCI / Alibaba Cloud のすべてに対応する。Google Cloud を含むマルチクラウドなら、Google 側から回線を引くだけで閉域接続が完成する。 これは2026年以前から変わらない Google Cloud の優位点である。

② AWS が2026年に自前のネイティブサービスを持った

2026年4月14日、AWS は AWS Interconnect - multicloud を GA した。従来の Direct Connect が「AWS ⇔ オンプレ」だったのに対し、これは 「AWS ⇔ 他クラウド」 のためのマネージドサービスである。

提供リージョンペア

このサービスは AWS 側では「AWS Interconnect - multicloud」、Google Cloud 側では「Partner Cross-Cloud Interconnect for AWS」という名前で、同じ1本の接続を両側から呼んでいる。したがってロケーションのペアも共通である。

2026年4月の GA 時点では5ペアだったが、2026年8月時点で 8ペアに拡大している（Google Cloud 公式のペア設定済みロケーション一覧）。

🇯🇵 日本のユーザーにとって最重要の事実#

asia-northeast1（東京）と asia-northeast2（大阪）は、このペア一覧に含まれていない。 つまり2026年8月時点で、日本国内で AWS Interconnect - multicloud / Partner Cross-Cloud Interconnect for AWS は使えない。

ただし、日本で AWS ⇔ Google Cloud の閉域接続ができないわけではない。 従来型の Cross-Cloud Interconnect（Dedicated）は東京・大阪に対応している。次節で両者の違いを整理する。

Forrester のアナリストは、この GitHub 公開を マルチクラウド接続のデファクトスタンダードを取りにいく動きと評価している。

③ Azure だけが取り残されている

2026年8月時点で、Azure がネイティブに閉域接続できる相手は OCI のみである。AWS 向け・Google Cloud 向けのネイティブサービスは存在しない。

Microsoft 自身の公式ブログでも、AWS / Google Cloud への接続については Azure Virtual WAN + サードパーティの SD-WAN / VPN ソリューションを使う方法が案内されている。つまり Azure を含むマルチクラウド閉域は、依然として独自構築が必要である。

ただし、AWS Interconnect - multicloud の Azure 対応が2026年後半に予定されているため、AWS ⇔ Azure については、AWS 側から張る形で近く解決する見込みである。Google Cloud ⇔ Azure は既に Cross-Cloud Interconnect で解決済み。残る真の空白は「Azure が主役で、Azure 側から張りたい場合」だけになる。

5-2 ネイティブサービスの詳細#

5-2-0 【必読】Cross-Cloud Interconnect には2つの方式がある#

ここが最も混乱しやすいポイントである。Google Cloud の「Cross-Cloud Interconnect」には、性質のまったく異なる2つの方式が存在する。日本での採用可否は、どちらを指しているかで正反対になる。

注記: AWS 側が GA、Google 側ドキュメントが公開プレビューという非対称な表記になっている（2026年8月時点）。Google 側は「公開プレビュー期間中は料金は請求されません」と記載しているため、実質的に Google 側の transport 費用が無料の期間である可能性がある。導入前に両社に課金条件を確認すること。

実務上の判断:

AWS ⇔ Google Cloud を閉域接続したい├─ 拠点が 日本（東京・大阪）│   └─→ ① 従来型 Cross-Cloud Interconnect（10/100 Gbps、1〜4週間、エグレス課金あり）│        または 方式B（Megaport / Equinix Fabric）│├─ 拠点が シンガポール / シドニー / 米国 / 欧州（8ペアのいずれか）│   └─→ ② Partner CCI for AWS（数分で開通、冗長組み込み、エグレス課金なし）★圧倒的に有利│└─ Azure / OCI / Alibaba が相手    └─→ ① 従来型 Cross-Cloud Interconnect のみ（② は AWS 専用）

②が使えるロケーションなら、②を選ばない理由はほぼない。 開通が数分、冗長が組み込み済み、そしてエグレス転送料が発生しない。大容量のクラウド間転送があるなら、エグレス課金の有無だけで年間数百万円の差になる。

5-2-1 ① Cross-Cloud Interconnect（従来型 / Dedicated）#

仕組み: Google が物理回線を手配し、Google Cloud のポートと相手クラウドのポート（AWS Direct Connect / Azure ExpressRoute / OCI FastConnect）を物理的に接続する。利用者はコロケーション施設での物理作業をしなくてよい。

手順:

1. 対応ロケーションを特定する（特定のロケーションでのみ提供される）
2. Google 側と相手クラウド側の両方でポートを購入する
3. Google が両ポートを物理的に接続する
4. Cloud Router で BGP セッションを確立する

所要期間: 典型的には 1〜4週間

帯域:

冗長構成の要件（SLA を得るために必須）:

コスト感:

• 10 Gbps の冗長構成（2接続）で月額 約 12,304 USD + トラフィック費用という試算がある
• Google Cloud ⇔ Azure の場合、Cross-Cloud Interconnect 約 8,200 USD + ExpressRoute 約 6,800 USD = 約 15,000 USD/月 という試算もある

従来型のマルチクラウド閉域接続は、月額150〜200万円規模の投資であるという感覚を持っておくこと。PoC で気軽に試せるものではない。この点でも、②の Partner 方式（無料枠あり・エグレス課金なし）が使えるロケーションかどうかは決定的な差になる。

5-2-2 ② AWS Interconnect - multicloud / Partner Cross-Cloud Interconnect for AWS#

Direct Connect との違い:

評価: 「数分で開通する」「経路が自動伝播する」という点で、運用の複雑さが劇的に下がっている。従来のマルチクラウド接続で最大の負担だった BGP 設計と物理手配の両方が消える。

注意点: 提供は8リージョンペアのみで、東京・大阪は対象外（5-1-2 参照）。日本のプロジェクトでは、従来型の Cross-Cloud Interconnect か方式Bを使うことになる。

同時に発表された「AWS Interconnect - ラストマイル」#

2026年4月の GA では、multicloud と併せて AWS Interconnect - ラストマイルという別オプションも提供開始された。これは「AWS ⇔ 他クラウド」ではなく、オンプレミス拠点から AWS までのラストマイル回線の手配を、AWS コンソールから完結させるためのものである。

従来、Direct Connect の「拠点からコロケーションまでの回線」は利用者が通信事業者と個別に契約する必要があった。それを AWS のコンソールから選択できるようにしたものである。日本での提供は未定だが、方向性としては「専用線の調達が Direct Connect のコンソール内で完結する」世界に向かっている。

5-2-3 Azure ⇔ OCI#

Azure と Oracle Cloud の間には、Azure ExpressRoute と OCI FastConnect を直結する専用のインターコネクトが提供されている。さらに Oracle Database@Azure により、Azure のデータセンター内で Oracle Exadata が動作する形態もある。

これは Microsoft と Oracle の戦略的提携によるものであり、他クラウドには適用されない。

5-3 独自構築 — ネイティブがない組合せの実装#

ネイティブサービスがない組合せ（主に Azure ⇔ AWS、Azure ⇔ Google Cloud を Azure 側主導で張る場合）では、以下の5方式のいずれかを選ぶことになる。

方式A: コロケーション + 自前ルータ（王道・最も自由）#

            Equinix TY / AT TOKYO / コムスペース 等        ┌────────────────────────────────────────────┐        │  自社ラック                                  │        │  ┌──────────────────────────┐              │   AWS  │  │  ルータ #1（例: ASR / MX） │              │◄───────┼──┤   ├─ AWS DX Dedicated Port │              │ DX     │  │   ├─ Azure ER Direct Port  ├──────────────┼───────► Azure        │  │   └─ オンプレ向け回線        │   ExpressRoute│        │  └──────────────────────────┘              │        │  ┌──────────────────────────┐              │        │  │  ルータ #2（冗長）          │              │        │  └──────────────────────────┘              │        └────────────────────────────────────────────┘

構成手順:

1. AWS と Azure の両方が接続ポイントを持つコロケーション施設に、自社ラックを借りる
2. AWS Direct Connect（Dedicated Connection）と Azure ExpressRoute（Direct または Provider 経由）のポートを引く
3. 自前のルータで両者を L3 で中継する

BGP 設計の要点:

冗長設計:

• 2つの異なるコロケーション施設 × 各2回線（計4本）が理想
• BFD（Bidirectional Forwarding Detection）で障害検知を高速化（BGP のデフォルトのホールドタイム 90秒では長すぎる）
• ECMP で負荷分散するか、Active/Standby にするかを決める

MTU の設計（見落とされやすい）:

重要: 経路上の最小 MTU が Azure の 1500 になるため、AWS 側でジャンボフレームを有効にしていると PMTUD ブラックホールが発生し、「ping は通るが大きなデータ転送が固まる」という典型的な障害になる。ルータで TCP MSS クランプ（MSS = 1460 など）を必ず設定すること。

暗号化:

• 専用線は物理的に分離されているが、暗号化はされていない
• 要件があれば MACsec（AWS DX / ExpressRoute Direct が対応）または上位で IPsec を張る

コスト構成:

適する場面: 大容量（10Gbps 超）、長期運用、ネットワーク設計を完全に自社で制御したい、既にコロケーションに設備がある。

方式B: インターコネクトファブリック（実務で最も現実的）#

Megaport Cloud Router (MCR) または Equinix Fabric Cloud Router を使う。

            Megaport / Equinix Fabric        ┌────────────────────────────────┐   AWS  │  仮想ルータ（MCR / Fabric Router）│◄───────┤   ├─ Virtual Cross Connect ─────┼───────► Azure DX     │   ├─ Virtual Cross Connect ─────┼───────► Google Cloud        │   └─ Virtual Cross Connect ─────┼───────► オンプレ        └────────────────────────────────┘

仕組み: ファブリック事業者のネットワーク上に仮想ルータを作り、そこから各クラウドへ仮想クロスコネクトを張る。自社ラックも物理ルータも不要。

利点:

• 自社ラック不要、機器調達不要
• ポータル / API から数分〜数日で開通
• 帯域の変更が容易（50Mbps から 10Gbps まで、月単位で変更可能）
• L3 でのピアリングを仮想ルータが担うため、BGP 設定はポータル上で完結
• 同一メトロ内なら、クラウド間のレイテンシは 往復3〜4ms 程度

欠点 / 注意点:

• ファブリック事業者のネットワークを通る。厳密に「自社とクラウドベンダーだけ」という要件には抵触する可能性がある。暗号化が必要なら上位で IPsec を張る
• 事業者の障害が単一障害点になりうる（2事業者を使う、または2メトロで冗長化する）
• 従量的なコストが積み上がる（ポート + 仮想クロスコネクト × クラウド数 + データ転送）

コスト削減効果: プライベート相互接続はエグレス課金を大幅に下げる。AWS Direct Connect 経由のエグレスは インターネット経由の約 1/5 程度になる（インターネット egress 約 0.09 USD/GB に対し、DX 経由は 0.02 USD/GB 程度）。大容量のクラウド間転送があるなら、専用線のコストは egress 削減で回収できることが多い。

適する場面: ほとんどの企業でこれが最適解。中規模（1〜10Gbps）、複数クラウド、早期の立ち上げが必要。

方式C: IPsec VPN over Internet（暫定策・厳密には閉域ではない）#

AWS Site-to-Site VPN ⇔ Azure VPN Gateway を、インターネット経由の IPsec トンネルで接続する。

明確に述べる: これは 「グローバルネットワークにインターフェースしない」という要件を満たさない。パケットはインターネットを通る。暗号化されているだけである。

要件が「暗号化されていればよい」であれば有効だが、「インターネットを経由しないこと」が要件なら不可である。この区別を、要件定義の段階で必ず確認すること。

それでも使ってよい場面:

• 検証環境・PoC
• 専用線のバックアップ経路（プライマリ = 専用線、セカンダリ = VPN）
• 帯域が小さい管理通信のみ
• 予算が確保できるまでの暫定

実装上の注意:

• 両側の IKE/IPsec パラメータ（DH グループ、暗号化アルゴリズム、PFS）を合わせる
• MTU / MSS: IPsec のオーバーヘッドで実効 MTU が下がる。MSS クランプ必須
• BGP over VPN（AWS は BGP 必須、Azure は BGP オプション）
• スループット上限（AWS VPN は1トンネルあたり約 1.25Gbps。ECMP で複数トンネルを束ねる）

方式D: SD-WAN / NVA 経由#

各クラウドに仮想アプライアンス（NVA: Network Virtual Appliance）を配置し、ベンダーのオーバーレイで接続する。

代表的な製品: Cisco Catalyst SD-WAN、Fortinet SD-WAN、Palo Alto Prisma SD-WAN、Aviatrix、Arista CloudEOS

AWS VPC                    Azure VNet┌─────────────┐           ┌─────────────┐│ Transit GW  │           │ Virtual WAN ││   │         │           │   │         ││ ┌─▼───────┐ │           │ ┌─▼───────┐ ││ │  NVA    │◄┼───────────┼─►│  NVA    │ ││ └─────────┘ │  オーバーレイ │ └─────────┘ │└─────────────┘           └─────────────┘        ▲                        ▲        └────── 下回りは専用線 or インターネット ──┘

利点:

• ポリシー・可視化・暗号化が統合される。全クラウドで同じ FW ルール、同じ可視化ダッシュボード
• 経路制御が製品のコントロールプレーンで一元管理される
• クラウド間だけでなく、拠点・リモートワーカーも同じ枠組みに載る

欠点:

• ライセンス費用が高額
• NVA 自体の運用（パッチ、冗長化、スケール）が必要
• NVA がボトルネックになりうる（インスタンスサイズに依存）

重要: NVA はオーバーレイであり、下回り（アンダーレイ）が何であるかとは独立している。アンダーレイをインターネットにすれば方式Cと同じ（閉域ではない）、アンダーレイを専用線にすれば閉域になる。「SD-WAN を入れたから閉域」ではない。

Azure での実装: Azure Virtual WAN は多数の SD-WAN ベンダーの NVA をマネージドで統合できる（Virtual WAN Hub 内に NVA をデプロイ）。Microsoft が公式に案内している AWS / Google Cloud 接続の方法がこれである。

方式E: Cloudflare をハブにする（2026年の新しい選択肢）#

                  Cloudflare のグローバルネットワーク        ┌──────────────────────────────────────────────┐        │                                              │   AWS ─┤ WAN オンランプ（GRE / IPsec / CNI）           ├─ Azure        │                                              │  GCP ──┤ Gateway（DNS/NW/HTTP ポリシーの一元適用）      ├─ オンプレ        │                                              │        │ Multi-Cloud Networking（🔒 closed beta）:     │        │  VPC / サブネット / VM / ルートテーブルを自動探索 │        │  クラウド網と Cloudflare WAN 間の VPN を自動構築 │        └──────────────────────────────────────────────┘

構成要素:

• Cloudflare WAN（旧 Magic WAN）: GRE / IPsec トンネル、または CNI（Network Interconnect） による直結で、各クラウドの VPC / VNet を Cloudflare に接続
• Multi-Cloud Networking（🔒 closed beta、Enterprise 限定）: AWS / GCP / Azure のリソース（VPC、サブネット、VM、ルートテーブル）を自動探索し、クラウドネットワークと Cloudflare WAN の間の VPN トンネルを自動構築する
• Workers VPC（🟡 beta）: アプリケーション層のマルチクラウド。Workers から各クラウドのプライベートリソースを呼ぶ

利点:

• 設定が圧倒的に簡単（リソース探索とトンネル構築が自動）
• Gateway のポリシーが全クラウドに一律で適用される
• Cloudflare の網は世界348都市にあるため、地理的に離れたリージョン間でも経路が最適化される

注意点:

• Multi-Cloud Networking は closed beta（2026年8月時点）。本番採用には申込と審査が必要
• Cloudflare という第三者のネットワークを経由する。「自社とクラウドベンダーだけ」という厳密な閉域要件には抵触しうる。CNI（直結）を使えば公衆網は経由しないが、Cloudflare の網内は通る
• 大容量のクラウド間バルク転送には向かない（そういう設計思想の製品ではない）

適する場面: 中小規模、アプリケーション層の連携が主、ゼロトラストを併せて導入したい、早く動かしたい。

5-3-6 方式の選択フローチャート#

Q1. 「インターネットを一切経由しない」が厳密な要件か？    ├─ NO → 方式C（IPsec VPN）で十分。最も安い    └─ YES ↓Q2. 接続する組合せは？    ├─ AWS ⇔ Google Cloud    │   ├─ 8ペアの対象ロケーション（シンガポール/シドニー/米国/欧州）    │   │    → ✅ **Partner CCI for AWS**（数分で開通・冗長組み込み・エグレス課金なし）    │   └─ **日本（東京・大阪）**    │        → ✅ **従来型 Cross-Cloud Interconnect**（Google 側から発注、1〜4週間）    │          または方式B    ├─ Google Cloud ⇔ Azure → ✅ 従来型 Cross-Cloud Interconnect（10/100 Gbps）    ├─ AWS ⇔ Azure → 🟡 2026年後半に AWS Interconnect - multicloud で対応予定    │                  （ただし日本での提供時期は別問題）それまでは方式A / B    └─ その他 ↓Q3. 必要帯域は？    ├─ 10Gbps 超、長期運用 → 方式A（コロケーション + 自前ルータ）    └─ 10Gbps 以下 ↓Q4. 統合的なセキュリティポリシーが必要か？    ├─ YES → 方式D（SD-WAN / NVA）    └─ NO  → **方式B（Megaport / Equinix Fabric）** ← 多くの場合これが最適

5-4 マルチクラウド閉域における DNS 設計#

ネットワークが繋がっても、名前が引けなければアプリは動かない。マルチクラウド閉域における DNS は、単一クラウドの場合より一段複雑になる。

5-4-1 根本的な課題#

PrivateLink / Private Service Connect / Private Endpoint の FQDN は、そのクラウド内でしか正しく解決されない。

例:

• Azure の mydb.privatelink.database.windows.net は、Azure の Private DNS Zone を参照する VNet 内でのみ、プライベート IP に解決される
• AWS の VPC エンドポイントの vpce-xxx.s3.ap-northeast-1.vpce.amazonaws.com も同様
• Google Cloud の PSC エンドポイントも同様

AWS の VM から Azure の Private Endpoint に到達したい場合、AWS 側の DNS がその名前を解決できなければならない。 ネットワーク的には TGW → 専用線 → Azure で到達可能でも、名前解決が失敗すれば通信は始まらない。

5-4-2 推奨: オンプレをハブにしたハブ&スポーク型#

                       ┌──────────────────────────┐                       │  オンプレ DNS（ハブ）      │                       │  corp.example.com の権威   │                       │                          │   ┌───────────────────┤  条件付きフォワーダ:       ├──────────────────┐   │                   │   privatelink.*      → Azure Private Resolver │   │                   │   *.amazonaws.com    → R53 Inbound Endpoint   │   │                   │   *.googleapis.com   → Cloud DNS Inbound      │   │                   └──────────┬───────────────┘                    │   │                              │                                     │   ▼                              ▼                                     ▼AWS VPC                      Azure VNet                          GCP VPCR53 Resolver Outbound        DNS Private Resolver                Cloud DNS → corp.example.com           Outbound → corp.example.com         転送ゾーン   をオンプレへ転送             をオンプレへ転送                    → オンプレへ転送

設計ルール:

1. 各クラウドは、自クラウド外の名前をすべてオンプレ DNS へ転送する（アウトバウンド1本のみ）
2. オンプレ DNS が、各クラウドのドメインを各クラウドのインバウンドエンドポイントへ振り分ける
3. クラウド間で直接フォワードしない

なぜメッシュにしないのか: クラウドが N 個あると、フォワード設定は N×(N-1) 本になる。3クラウド + オンプレなら12本。1つ増えるごとに設定が爆発し、ループの危険も上がる。ハブ&スポークなら 2N 本で済む。

ハブの冗長化: オンプレ DNS が単一障害点になる。最低2台、可能なら2拠点に配置し、各クラウドのフォワード先に両方を登録する。

5-4-3 名前空間の設計#

example.com                  ← 外部公開（パブリック DNS）corp.example.com             ← 社内（オンプレ権威）├── aws.corp.example.com     ← AWS のプライベートホストゾーン│   ├── prod.aws.corp.example.com│   └── dev.aws.corp.example.com├── gcp.corp.example.com     ← Cloud DNS プライベートゾーン└── az.corp.example.com      ← Azure Private DNS Zone

アンチパターン: 各クラウドで同じドメイン名（internal.example.com など）のプライベートゾーンを作ると、名前が衝突して解決結果が環境によって変わる。デバッグが極めて困難になる。必ずクラウドごとにサブドメインを分ける。

5-4-4 サービス固有 FQDN の扱い#

自社で命名できるレコードとは別に、クラウドが強制する FQDN がある。

Azure の privatelink.* が最も面倒である。使う PaaS の数だけゾーンが増える。Azure Policy で Private Endpoint 作成時に Hub のゾーンへ A レコードを自動登録する設定を最初に入れておくこと。

5-4-5 逆引きと Kerberos#

Windows / AD 統合環境では、逆引き（PTR）が必要になるケースがある。Kerberos の SPN 解決、SQL Server の Windows 認証、一部の監視ツールなど。

• 各クラウドのプライベート IP レンジについて、オンプレ DNS に逆引きゾーンを作るか、各クラウドの逆引きをオンプレへ委任する
• AWS の VPC は自動的に <region>.compute.internal の逆引きを持つが、これはオンプレからは引けない。必要なら自前で逆引きゾーンを作る

5-5 IP アドレス設計#

マルチクラウド閉域で最も後戻りしにくいのが IP 設計である。

5-5-1 全社 CIDR 計画#

10.0.0.0/8 を全社で使う場合の例10.0.0.0/12    オンプレ（既存）10.16.0.0/12   AWS  10.16.0.0/16   東京 / prod  10.17.0.0/16   東京 / stg  10.18.0.0/16   東京 / dev  10.24.0.0/16   大阪 / prod10.32.0.0/12   Azure  10.32.0.0/16   東日本 / prod  ...10.48.0.0/12   Google Cloud  10.48.0.0/16   asia-northeast1 / prod  ...10.64.0.0/12   予約（M&A、新規クラウド）

原則:

• クラウドごとに大きなブロックを割り当て、その中で環境・リージョンを切る
• 将来の拡張分を必ず予約する（M&A で他社のレンジが入ってくる）
• 172.16.0.0/12 の一部はクラウドの内部で使われていることがある（Docker のデフォルトブリッジ 172.17.0.0/16 など）。避けるか、意識的に使う
• Kubernetes の Pod CIDR / Service CIDR も全社計画に含める（ここを忘れて後から衝突する事故が多い）

5-5-2 CIDR が重複してしまった場合#

M&A や、部門が勝手に作った環境を統合するときに必ず起きる。

PrivateLink 系のサービスが「CIDR 重複を許容する」という性質は、実務上とても強力である。 L3 のフルメッシュを諦めて、「必要なサービスだけを PrivateLink で公開する」という設計に切り替えると、IP 設計の問題の多くが消える。

5-6 アンチパターン集#

実際のプロジェクトで繰り返し観測される失敗を挙げる。

❌ アンチパターン1: 「とりあえず全部 Transit Gateway に繋ぐ」#

症状: TGW のアタッチメント課金とデータ処理課金が想定の数倍になる。障害の影響範囲（blast radius）が全社に及ぶ。

対策: 「本当に L3 で到達する必要があるか」を通信パターンごとに問う。多くは PrivateLink / PSC / Private Endpoint でサービス単位に絞れる。

❌ アンチパターン2: インターネット VPN を「閉域」と呼ぶ#

症状: 監査で指摘され、設計をやり直すことになる。

対策: 第4部 4-1 の L0〜L4 の定義を、要件定義の最初に関係者と合意する。「暗号化されていること」と「インターネットを経由しないこと」は別の要件である。

❌ アンチパターン3: DNS を各チームが個別に設定する#

症状: 同じ名前が環境によって違う IP に解決される。フォワードループが発生する。障害時に原因が特定できない。

対策: DNS はプラットフォームチームが一元管理する。開発チームには「このゾーンにレコードを作る API」だけを提供する。Azure なら Azure Policy で自動登録を強制する。

❌ アンチパターン4: ExpressRoute の Microsoft Peering で M365 を閉域化しようとする#

症状: M365 のパフォーマンスが劣化する。Microsoft のサポートが得られない。

理由: Microsoft は M365 のトラフィックをインターネット経由（ローカルブレークアウト）とすることを公式に推奨している。ExpressRoute Microsoft Peering に M365 を載せるのは、特定の要件（規制など）がある場合の例外的な構成である。

対策: M365 は Microsoft の推奨に従いインターネット経由とし、Azure リソースへの接続だけを Private Peering で閉域化する。

❌ アンチパターン5: MTU / MSS を確認しない#

症状: 「ping は通るが、大きなファイル転送やデータベースの大きなクエリ結果が固まる」。最も診断が難しい障害の一つ。

対策: 5-3 方式A の MTU 表を参照し、経路上の最小 MTU に合わせて MSS クランプを設定する。構築直後に、大きなペイロード（ping -s 1472 -M do など）で疎通確認する。

❌ アンチパターン6: 冗長化を「後でやる」#

症状: 専用線が1本しかない状態で本番稼働し、キャリア工事で全断する。

対策: SLA を得るための冗長要件（Cross-Cloud Interconnect なら 99.99% で2メトロ×2エッジドメイン = 4本）を最初から予算に入れる。冗長化は後付けが最も高くつく領域である。

❌ アンチパターン7: 帯域だけ見てレイテンシを見ない#

症状: クラウド間で同期的な API 呼び出しをする設計にしたが、レイテンシで性能が出ない。

対策: 同一メトロなら往復3〜4ms だが、東京 ⇔ 米国西海岸なら往復100ms を超える。クラウド間の通信は非同期（キュー経由）を基本とし、同期呼び出しは同一メトロ内に限る設計にする。

5-7 コスト試算の考え方#

マルチクラウド閉域の総コストは、次の4要素で決まる。

総コスト = 回線費 + クラウド側ポート費 + データ転送費 + 運用工数

判断の目安:

忘れられがちなコスト: 運用工数。BGP を理解し、障害時に切り分けられる要員を確保・維持するコストは、回線費より高くつくことがある。方式B（ファブリック）や AWS Interconnect - multicloud のようなマネージドサービスは、このコストを削減するために存在している。

5-8 第5部のまとめ#

結論:

1. マルチクラウド閉域が要件なら、AWS + Google Cloud の組合せが2026年時点で最も楽である。 ネイティブサービスが両方向から存在する。
2. ただし日本では「新しくて速くて安いほう」（Partner 方式）はまだ使えない。 東京・大阪は8ペアに含まれない。日本の案件では 従来型 Cross-Cloud Interconnect（Google 側から発注、1〜4週間、10/100 Gbps、エグレス課金あり）か、**方式B（Megaport / Equinix Fabric）**を使う。「AWS がネイティブ対応した」というニュースを、そのまま日本の案件に持ち込まないこと。
3. Azure を含む場合は、AWS Interconnect - multicloud の Azure 対応（2026年後半予定）を待つか、方式B（Megaport / Equinix Fabric）で構築する。
4. どの方式を選んでも、DNS 設計（5-4）と IP 設計（5-5）は自分でやらなければならない。 ここがマルチクラウド閉域の本当の難所である。
5. 月額200万円規模の投資になることを前提に、本当に L3 のフル到達性が必要かを問い直す。多くの場合、PrivateLink / PSC でサービス単位に絞れば、より安く・より安全に要件を満たせる。

← 第4部 ｜ → 第6部 シナリオ別ガイド・付録

第6部 シナリオ別の選定ガイド#

ここまでの分析を、実際の意思決定に落とし込む。

6-1 シナリオ1: 日本の大企業（M365 導入済み・オンプレ AD あり・閉域必須）#

典型的な条件: 社員数千〜数万人、M365 E3/E5 を全社導入、オンプレに AD とファイルサーバー、基幹系は閉域必須、情シスは Windows 中心。

推奨: Azure を主、AWS を従#

設計上、最初に合意すべきこと#

1. Entra ID は閉域化できない（第4部 4-4-3）。「完全閉域」という言葉を使わず、「L3 閉域 + Entra ID 向けの限定的な FQDN 許可」 という表現で要件を確定させる
2. M365 を開発対象にするなら別テナントが必要（第3部 3-4）。Developer Program ではなく 有償の小規模テナントを予算化する
3. Azure リソースの環境分離はサブスクリプションで足りる。テナントを分ける必要はない
4. ExpressRoute の Microsoft Peering に M365 を載せない（第5部 5-6 アンチパターン4）

構成の骨子#

Entra ID テナント（= M365 テナント。1つ）└── Root 管理グループ    ├── Platform    │   ├── Identity        （AD DS / Entra Connect）    │   ├── Management      （Log Analytics / Sentinel）    │   └── Connectivity    （Hub VNet / ExpressRoute / Azure Firewall    │                        / DNS Private Resolver / privatelink.* ゾーン）    ├── Landing Zones    │   ├── Corp    （閉域ワークロード。0.0.0.0/0 は Azure Firewall へ）    │   └── Online  （インターネット公開。Front Door + WAF）    └── Sandbox別途:  AWS Organization（別途 IAM Identity Center を Entra ID と SAML 連携）  Cloud Identity Free（gcp.example.com）→ Google Cloud 組織（データ分析用）

6-2 シナリオ2: SaaS スタートアップ（Web/API 中心・グローバル配信・コスト重視）#

典型的な条件: 数十人、日本と海外にユーザー、エンジニア主導、コスト感度が高い、閉域要件なし。

推奨: Cloudflare を前段 + AWS または Google Cloud をバックエンド#

コスト設計のポイント#

• 画像・動画・静的アセットは R2 に置く。エグレス無料の効果は、月間数 TB 配信するだけで数十万円/年の差になる
• Workers でエッジキャッシュとレスポンス整形をやると、オリジンへのリクエスト数が減り、バックエンドのサイズを落とせる
• Hyperdrive で、エッジから他クラウドの PostgreSQL への接続をプールする
• DB は最初から Aurora Serverless v2 / Cloud SQL Enterprise Plus で自動スケールさせる

将来の分岐点#

• 状態を持つリアルタイム機能（協調編集、ゲーム、チャット）が必要になったら → Durable Objects が他社にない生産性を発揮する
• データ分析が必要になったら → BigQuery か、R2 Data Catalog + 外部エンジン（エグレス無料なので Snowflake などから直接読める）

6-3 シナリオ3: 受託開発 / SI（顧客ごとの完全分離が必要）#

典型的な条件: 顧客ごとに環境を分離、顧客の契約下で作るケースと自社契約下で作るケースが混在、開発者は複数案件を掛け持ち。

推奨: AWS（顧客の指定がない限り）#

実装の要点#

自社 AWS Organization├── 自社業務 OU└── 案件 OU    ├── 顧客X OU（自社契約の場合）    │   ├── x-prod    │   └── x-dev    └── 顧客Y OU顧客契約の場合:  顧客の AWS アカウントに IAM ロールを作ってもらう  信頼ポリシー: 自社アカウント + sts:ExternalId（顧客ごとの秘密値）  → 社員は IAM Identity Center から自社アカウントに入り、AssumeRole

必ず設定すること:

• External ID（混乱した代理人問題の防止）
• 案件終了時のロール削除手順を契約に明記
• CloudTrail を顧客側で有効にし、自社の操作が監査できる状態にする（信頼関係の構築）

6-4 シナリオ4: データ利活用が主目的#

典型的な条件: 全社のデータを集約し、分析・ML・BI に使いたい。データガバナンスと持ち出し防止が重要。

推奨: Google Cloud#

判断の実際#

Q. BI は何を使っているか / 使いたいか？   ├─ Power BI が全社標準 → Microsoft Fabric（BI とデータ基盤を一体化）   ├─ Looker / Tableau / 未定 → Google Cloud（BigQuery）   └─ Amazon Quick → AWSQ. データはどこにあるか？   ├─ 大半が AWS → AWS（egress を避ける）   ├─ 大半がオンプレ / SaaS → どこでもよい → 上の BI 基準で決める   └─ 複数クラウドに分散 → **Iceberg で相互運用**（第2部 2-7）Q. 「データが境界を越えないこと」を証明する必要があるか？   ├─ YES → **Google Cloud（VPC Service Controls）が唯一の明確な解**   └─ NO  → 上の基準で決める

6-5 シナリオ5: マルチクラウド閉域が要件#

推奨: AWS + Google Cloud#

2026年8月時点で、ネイティブに閉域相互接続できる唯一の組合せである（OCI を除く）。

• AWS 側から: AWS Interconnect - multicloud（Direct Connect コンソールから数分、経路自動伝播）
• Google Cloud 側から: Cross-Cloud Interconnect（10/100/400 Gbps）

⚠️ 日本での注意: 新方式（Partner CCI）は東京・大阪で使えない#

AWS ⇔ Google Cloud の閉域接続には2つの方式があり、日本で使えるのは片方だけである（第5部 5-2-0）。

Partner 方式の対応ロケーションは 8ペア（シンガポール / シドニー / ストックホルム / ロンドン / フランクフルト / バージニア北部 / オレゴン / 北カリフォルニア）で、asia-northeast1（東京）・asia-northeast2（大阪）は含まれない。

したがって日本国内の案件では、

「AWS がマルチクラウド閉域接続をネイティブ対応した」というニュースを、そのまま日本の案件に持ち込まないこと。速くて安い新方式は、まだ日本に来ていない。

Azure を含めざるを得ない場合:

• Google Cloud ⇔ Azure は Cross-Cloud Interconnect で既に解決済み
• AWS ⇔ Azure は 2026年後半の AWS Interconnect - multicloud 対応を待つか（ただし日本での提供時期は別問題）、Megaport MCR / Equinix Fabric Cloud Router（第5部 方式B）で構築する

6-6 総合判断チャート#

【最初の問い】Microsoft 365 を全社導入しているか？├─ YES ─→ ID 統合のコストを考えると Azure が第一候補│         ただし「Azure でしかできないこと」は M365 統合だけである│         ワークロードごとに最適なクラウドを選ぶ余地は大きい└─ NO  ─→ 用途で選ぶ          ├─ Kubernetes 中心         → Google Cloud          ├─ データ分析中心           → Google Cloud          ├─ サービス網羅性・事例重視  → AWS          ├─ Web/API・グローバル配信  → Cloudflare + (AWS or GCP)          └─ エッジ・ステートフル      → Cloudflare【次の問い】閉域要件はあるか？├─ L3 まで  → AWS / Google Cloud / Azure いずれも可├─ L4 まで  → **Azure は不可**（Entra ID）。AWS / Google Cloud を検討└─ データ持ち出し防止も必要 → **Google Cloud（VPC-SC）が唯一の明確な解**【最後の問い】組織・環境分離の要件は？├─ M365 を開発対象にする      → 別テナント必須。有償テナントを予算化├─ 顧客ごとの分離が必要        → AWS（クロスアカウントロール）├─ 開発者に個人環境を配りたい   → Google Cloud（1人1プロジェクト）└─ 上記なし                   → どれでも可

第7部 付録#

7-1 名称変更・統廃合 年表（2024 → 2026）#

意思決定に影響する変更のみを抜粋。

AWS#

Google Cloud#

Azure / Microsoft#

Cloudflare#

7-2 用語対訳表#

7-3 「該当なし」早見表#

第2部で「❌」が付いたもののうち、実務で影響が大きいものを再掲する。

7-4 参照した一次情報（確認日: 2026-08-17）#

サービス対応表#

• Google Cloud「Compare AWS and Azure services to Google Cloud」
  https://docs.cloud.google.com/docs/get-started/aws-azure-gcp-service-comparison
• Microsoft Learn「Azure for AWS Professionals」（ms.date: 2026-05-06 / 更新: 2026-08-04）
  https://learn.microsoft.com/en-us/azure/architecture/aws-professional/services
• AWS「AWS services by category」
  https://docs.aws.amazon.com/whitepapers/latest/aws-overview/amazon-web-services-cloud-platform.html
• Cloudflare Developer Docs「Products」
  https://developers.cloudflare.com/products/
• Cloudflare「Changelogs」
  https://developers.cloudflare.com/changelog/

マルチクラウド接続#

• AWS「AWS announces general availability of AWS Interconnect - multicloud」（2026/04/14）
  https://aws.amazon.com/about-aws/whats-new/2026/04/aws-announces-ga-AWS-interconnect-multicloud/
• AWS「AWS Interconnect - multicloud connectivity with OCI in GA」（2026/07）
  https://aws.amazon.com/about-aws/whats-new/2026/07/aws-announces-AWS-interconnect-multicloud-OCI-GA/
• AWS Japan Blog「AWS Interconnect が一般提供され、ラストマイル接続を簡素化する新しいオプションが追加されました」（提供リージョンペアの一覧はここ）
  https://aws.amazon.com/jp/blogs/news/aws-interconnect-is-now-generally-available-with-a-new-option-to-simplify-last-mile-connectivity/
• Publickey「AWS、他クラウドと500Mbpsまでの接続が無料に」（無料枠の詳細）
  https://www.publickey1.jp/blog/26/aws500mbpsaws_interconnect_-_multicloud.html
• Google Cloud「Cross-Cloud Interconnect overview」
  https://docs.cloud.google.com/network-connectivity/docs/interconnect/concepts/cci-overview
• Google Cloud「AWS 向け Partner Cross-Cloud Interconnect の概要」
  https://docs.cloud.google.com/network-connectivity/docs/interconnect/concepts/partner-cci-for-aws-overview?hl=ja
• Google Cloud「Partner Cross-Cloud Interconnect for AWS — paired locations」（8ペアの一覧。東京・大阪なし）
  https://docs.cloud.google.com/network-connectivity/docs/interconnect/how-to/partner-cci-for-aws/paired-locations
• G-gen Tech Blog「Cross-Cloud Interconnect を徹底解説！」（東京・大阪対応、料金の実例）
  https://blog.g-gen.co.jp/entry/cross-cloud-interconnect-explained
• G-gen Tech Blog「Partner Cross-Cloud Interconnect for AWS を解説」（従来型との違い、日本未対応）
  https://blog.g-gen.co.jp/entry/partner-cross-cloud-interconnect-for-aws
• InfoQ「AWS Interconnect Reaches General Availability with Managed Multicloud and Last-Mile Connectivity」（2026/04）
  https://www.infoq.com/news/2026/04/aws-interconnect-multicloud-ga/
• Microsoft Azure Blog「Azure multicloud networking: Native and partner solutions」
  https://azure.microsoft.com/en-us/blog/azure-multicloud-networking-native-and-partner-solutions/

組織階層・テナント#

• Google Cloud「Manage multiple organization resources」
  https://docs.cloud.google.com/resource-manager/docs/managing-multiple-orgs
• Microsoft Learn「Secure resource isolation in a single tenant in Microsoft Entra ID」
  https://learn.microsoft.com/en-us/entra/architecture/secure-single-tenant
• Microsoft Learn「Limitations in multitenant organizations」
  https://learn.microsoft.com/en-us/entra/identity/multi-tenant-organizations/multi-tenant-organization-known-issues
• Microsoft Learn「What is cross-tenant synchronization in Microsoft Entra ID?」
  https://learn.microsoft.com/en-us/entra/identity/multi-tenant-organizations/cross-tenant-synchronization-overview
• Microsoft Learn「Transfer an Azure subscription to a different Microsoft Entra directory」
  https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription
• Microsoft Learn「Cross-tenant management experiences - Azure Lighthouse」
  https://learn.microsoft.com/en-us/azure/lighthouse/concepts/cross-tenant-management-experience
• Microsoft Learn「Organize your resources with management groups」
  https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
• AWS「Limitations and quotas in AWS Control Tower」
  https://docs.aws.amazon.com/controltower/latest/userguide/limits.html
• Cloudflare「Organizations for Enterprise」
  https://developers.cloudflare.com/fundamentals/organizations/for-enterprise/
• Cloudflare「Tenant」
  https://developers.cloudflare.com/tenant/

Microsoft 365 Developer Program#

• Microsoft Learn「Microsoft 365 Developer Program FAQ」（ms.date: 2026-07-30 / 更新: 2026-08-03）
  https://learn.microsoft.com/en-us/office/developer-program/microsoft-365-developer-program-faq
• Microsoft Learn「Join the Microsoft 365 Developer Program with a Visual Studio Professional or Enterprise subscription」
  https://learn.microsoft.com/en-us/office/developer-program/join-with-visual-studio

閉域構成#

• Microsoft Learn「Azure Private Link frequently asked questions (FAQ)」（ms.date: 2026-03-30）
  https://learn.microsoft.com/en-us/azure/private-link/private-link-faq
• Microsoft Learn「Use Azure Private Link to connect servers to Azure Arc by using a private endpoint」
  https://learn.microsoft.com/en-us/azure/azure-arc/servers/private-link-security
• Microsoft Learn「Azure DNS Private Resolver」
  https://learn.microsoft.com/en-us/azure/dns/dns-private-resolver-overview
• Microsoft Learn「Private Link and DNS Integration at Scale」
  https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale
• Microsoft Q&A「Clarification Needed: Azure Data Factory Trusted Service Retirement Date (Aug 2026 vs Aug 2027)」（ADF は2027年8月、2026年8月は Synapse の話であるという Microsoft の公式回答）
  https://learn.microsoft.com/en-us/answers/questions/5956508/clarification-needed-azure-data-factory-trusted-ser
• Microsoft Learn「マネージド仮想ネットワークとマネージド プライベート エンドポイント - Azure Data Factory」
  https://learn.microsoft.com/ja-jp/azure/data-factory/managed-virtual-network-private-endpoint
• AWS「Hybrid Cloud DNS Options for Amazon VPC」
  https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/route-53-resolver-endpoints-and-forwarding-rules.html
• Google Cloud「Cloud DNS overview」
  https://docs.cloud.google.com/dns/docs/overview
• Cloudflare「Workers VPC」
  https://developers.cloudflare.com/workers-vpc/
• Cloudflare「Multi-Cloud Networking」
  https://developers.cloudflare.com/multi-cloud-networking/

個別サービス#

• AWS「Amazon Aurora DSQL is now generally available」（2025/05）
  https://aws.amazon.com/about-aws/whats-new/2025/05/amazon-aurora-dsql-generally-available/
• AWS「Reimagine business intelligence: Amazon QuickSight evolves to Amazon Quick Suite」
  https://aws.amazon.com/blogs/business-intelligence/reimagine-business-intelligence-amazon-quicksight-evolves-to-amazon-quick-suite/
• InfoQ「Amazon S3 Vectors Reaches GA」（2026/01）
  https://www.infoq.com/news/2026/01/aws-s3-vectors-ga/
• InfoQ「AWS CodeCommit returns to General Availability」（2025/12）
  https://www.infoq.com/news/2025/12/aws-codecommit-ga
• Microsoft Learn「About Azure CDN from Microsoft (classic) to Azure Front Door migration」
  https://learn.microsoft.com/en-us/azure/cdn/tier-migration
• Microsoft Community Hub「Announcing Azure HorizonDB」
  https://techcommunity.microsoft.com/blog/adforpostgresql/announcing-azure-horizondb/4469710
• Azure Blog「Azure at Microsoft Ignite 2025」
  https://azure.microsoft.com/en-us/blog/azure-at-microsoft-ignite-2025-all-the-intelligent-cloud-news-explained/
• Google Cloud Blog「Google Cloud Next 2026 Wrap Up」
  https://cloud.google.com/blog/topics/google-cloud-next/google-cloud-next-2026-wrap-up
• Cloudflare Blog「Announcing the Cloudflare Data Platform」
  https://blog.cloudflare.com/cloudflare-data-platform/

インフラ規模#

• AWS Global Infrastructure
  https://aws.amazon.com/about-aws/global-infrastructure/
• Google Cloud locations
  https://cloud.google.com/about/locations
• Cloudflare Network
  https://www.cloudflare.com/network/

7-5 この記事の限界#

正直に書いておく。

1. GA / Preview の判定は執筆時点のスナップショットである。 特に Cloudflare は変化が速く、本記事で「🟡 beta」としたものが読者の閲覧時には GA になっている可能性が高い。必ず公式ドキュメントで再確認すること。
2. リージョン数などの規模の数字は、各社で数え方が違う。 単純比較には意味がない。
3. コストの試算は概算である。 実際の見積もりは各社の営業・パートナー経由で取得すること。特に専用線・マルチクラウド接続は、ロケーションと契約形態で大きく変わる。
4. 「該当なし（❌）」の判定は、筆者の調査範囲での判断である。 特定の機能を別のサービスの一部として提供している場合を見落としている可能性がある。
5. 提供リージョンは拡大し続ける。 本記事では AWS Interconnect - multicloud の提供リージョンペアを2026年8月時点の5組として記載したが、AWS は追加リージョン展開を予定している。日本での採用を検討する際は、最新の提供状況を確認すること。

← 第5部 ｜ 目次に戻る