「オンプレに置けるクラウド」が多すぎるので、整理してみた（前編） ─ Outposts / Alloy / GDC、結局なにが違うの？

これは前後編の前編です。

• 前編（この記事）：外部との接続を保ったまま主権を手元に寄せるタイプ（①延伸・接続型 / ②独立運営型）。3大クラウド＋Oracleが揃って出している「独立運営型」を中心に。
• 後編：接続を切って自律する世界（③遮断型 / ④自前）。完全閉域（air-gapped）が要件の人はこちら。→「オンプレに置けるクラウド」が多すぎるので、整理してみた（後編)

「うちは本当にネットを切る必要があるのか？」がこの領域の最初の分岐です。切らなくていい人は前編で足ります。切る必要がある人は後編へ。

はじめに

Outposts、Azure Local、GDC connected、GDC air-gapped、Alloy、Dedicated Region、Isolated Region……。

最近、この手の「クラウドをオンプレに持ってくる系」の製品名が増えてきました。「Distributed Cloud」でひとくくりにされがちですが、違いを説明できる人は意外と少ない気がします。

なので一回、自分の頭の整理も兼ねてまとめてみました。ガチめに書きますが、覚え方はゆるくいきます。各社の一次情報（公式ドキュメント）にあたりつつ2軸で確認しました。この観点が、実は一番の分かれ目だからです。

この記事は特定製品の推奨をするものではありません。分類の考え方の共有が目的です。なお本記事の分類（4タイプ・2軸）は、各社の公式ドキュメントをもとにした筆者の整理であって、各社の公式見解ではありません。仕様は変わりやすい領域なので、採用検討時は必ず各社の最新ドキュメントを確認してください（本記事は2026年7月時点の公開情報に基づきます）。

そもそも、なんでこんなに増えたのか

分類の前に、「なぜこの手の製品が急に増えたのか」を押さえておくと、以降の整理がスッと入ります。

きっかけは、相反する2つの欲求が同時に強まったことだと思います。

• 自分で握りたい（主権side）：データを自組織の管理下に置きたい。ネットが切れても動いてほしい。運用を外部任せにせず自分で決めたい。規制やデータ所在の要件も満たしたい。
• でも楽はしたい（利便性side）：とはいえ、昔ながらのオンプレに全部戻って、クラウドの快適さ──マネージドサービス、API一発で作れる手軽さ、スケール、モダンな開発体験──を捨てるのは、もう無理。一度クラウドの便利さを知ってしまった。

昔はこの2つがトレードオフでした。自前で握る＝オンプレで手作り、楽をする＝パブリッククラウドに預ける。どっちかを選ぶしかなかった。

この製品群は全部、「主権は欲しい、でもクラウドの使い勝手も手放したくない」という、一見わがままな両取りの要求に応えようとして生まれています。「クラウドの体験をそのままに、置き場所と管理権限だけ自分側に寄せる」——これが共通の狙いです。

結論：製品名で覚えるのは大変なので、2つの問いで分類してみる

製品名を一個ずつ暗記するのはキツイです。名前は増えるし、改称するし、同じ名前でも構成で挙動が変わる（後述するAzure Localがまさにそう）。

だから製品名ではなく、2つの問いで考えてみましょう。

1. コントロールプレーン（司令塔）が自律して動くか？ ── 管理・オーケストレーションの頭脳が、外部（クラウドや遠隔の運用者）への接続なしで管理操作を続けられるか、それとも接続前提か。技術的な自律性を決める軸。（司令塔が物理的にどこにあるかは別問題です。ローカルに置かれていても、運用のため外部接続が前提なら"自律"はしていません。この点は後でOracleの例で効いてきます。）
2. それを誰が運営・管理するのか？ ── クラウド事業者か、現地のパートナーか、自組織自身か。運用の主体を決める軸。

試しにこの2軸で見てみると、製品が二次元にきれいに並びます。新しい製品が出てきても「切っても自律管理できるか、運営は誰か」を聞けば位置づけられる。逆にこの2軸を無視すると違いが分からなくなります。

コントロールプレーン（control plane）という言葉に馴染みがなければ、ざっくり「インスタンスの起動・停止・スケール・構成変更といった"管理操作"を受け付けて実行する司令塔」くらいに捉えてもらえれば十分です。ワークロード自体を動かす data plane（実行層）とは別のレイヤーにいます。

そしてこの問1は、もう一つの実務的な問い「外部のネット接続を切っても管理操作を続けられるのか？」とほぼ同じことを聞いています。司令塔が自律していれば、切っても管理できる。接続前提なら、切ると管理操作は止まる。つまり切断時の挙動は問1そのものです。

大分類：4タイプ

上の2軸で切ると、だいたい4タイプに分かれます。

タイプ	司令塔は自律してるか	運営するのは誰か	（結果）切断したら	代表例
① 延伸・接続型（前編）	接続前提（自律しない）	クラウド事業者	管理操作が止まる（動作中は動く）	Outposts (AWS), GDC connected (Google), Dedicated Region (Oracle) ※3, Azure Local (Microsoft) ※1
② 独立運営型（前編）	接続前提（自律しない）	現地の独立法人・パートナー（自組織の場合も）	製品による（例：GCDは切断後も最大12ヶ月継続）	Alloy (Oracle), GCD (Google), European Sovereign Cloud (AWS) ※2, National Partner Clouds (Microsoft)
③ 遮断型（後編）	自律（接続不要）	自組織（パートナー運営も可）	動く（そもそも切断が前提）	GDC air-gapped (Google), Isolated Region (Oracle), Azure Local (Microsoft) ※1
④ 自前（後編）	自律（接続不要）	自組織	動く（自分で全部握る）	OpenShift (Red Hat), Nutanix

この前編では、上2つ（①延伸・接続型 / ②独立運営型）を扱います。 どちらも「外部との接続を保ったまま、主権や管理権限を手元に寄せる」タイプです。下2つ（③遮断型 / ④自前）＝接続を切って自律する世界は、後編でじっくり扱います。

※1 Azure Localが①と③の両方にいるのは間違いではありません。この製品は選んだ構成（通常運用か切断運用か）で司令塔の所在が変わり、①にも③にもなります。詳しくは前編後半の「境界はにじむ」の節で触れ、後編で深掘りします。なおMicrosoftはこのAzure Localを「Sovereign Private Cloud」というブランドで束ねていますが、中身はAzure Localなので、2軸で見れば位置づけは変わりません（上位ブランド名が付いても構造は同じ、という好例）。

※2 AWSの運営主体は第三者パートナーではなくAWS自身の欧州法人（後述）。

※3 Oracleの Dedicated Region は、司令塔（コントロールプレーン）が実はローカルに置かれています。ただしOracleが遠隔運用するため接続が前提で、切断すると管理が止まる点はOutpostsと同じ。「司令塔がクラウド側にあるから止まる」Outpostsと、「司令塔はローカルだが運用者が入れないから止まる」Dedicated Regionは、理由は違っても結果は同じ①です。だからこの記事は問1を"物理的にどこにあるか"ではなく"自律して動くか"で見ています。

②と③④の違いに注目してください。司令塔が接続前提か自律かで①②と③④が分かれ、①②の中では"誰が運営するか"でさらに分かれます。③④が自組織で運用を背負うのに対し、②は現地パートナーが運用を丸ごと担ってくれる。この「主権は手元に寄せたいけど、運用は自分で抱えたくない」への答えがタイプ②です。2つ目の軸（運営主体）を立てて初めて、②が独立したタイプとして見えてきます。

（なお②の中でも、切断時にどこまで動き続けるかは製品差があります。たとえばGCDは「Googleと切れても最大12ヶ月継続動作するよう設計」と公式に明言しています¹。②だからといって一律に「切っても動く」とは決めつけず、切断耐性が要件なら製品ごとに最新の公式情報を確認するのが安全です。）

なお①の中には、規模の違いがあります。数ラック単位で既存リージョンの"一部を延伸"するもの（Outposts、GDC connected）と、リージョンまるごと一式を敷地内に置くもの（Oracle Dedicated Region、AWS AI Factories）です。ただしこの違いは2軸（司令塔＝接続前提／運営＝クラウド事業者）では同じマスに落ちるので、大きくは同じ①として扱います。

以下、①と②を順に見ていきます。

タイプ①：延伸・接続型 ── 「オンプレに置く」けど制御はクラウド

まず一番よく誤解されるところ。AWS OutpostsもGDC connectedも、機材は自分のデータセンターに置きますが、コントロールプレーンはクラウド側（親リージョン）にあります。だから「オンプレに置いた＝自律して動く」ではありません。

AWS Outpostsの公式FAQは、かなりはっきり書いています。Outpostは親リージョンへの接続を前提としており、切断運用や接続が乏しい環境向けには設計されていないとされています²。サービスリンク（親リージョンへの暗号化トンネル）が切れると、既存のインスタンスやEBSは動き続けるしローカルゲートウェイ経由でアクセスもできますが、インスタンスの起動・停止・終了といった管理操作(mutating requests)は失敗します²。メトリクスやログはローカルに最大7日間キャッシュされ、接続が戻ると親リージョンに送られます²。

GDC connectedも位置づけは同じです。公式ドキュメントによれば、connectedはGoogleが提供・保守する専用ハードウェアを顧客拠点に設置し、Cloud VPNでGoogle Cloudに接続、クラスタのプロビジョニングはGoogle CloudコンソールやCLIから行います³。管理の入り口がクラウド側にある、つまりクラウドの延伸です。

要するにタイプ①は、「クラウドの一部を、物理的にこちら側へ引き込んだもの」。データの所在とレイテンシの問題は解決しますが、司令塔はあくまでクラウド側にあり、切断すれば管理操作は止まります。

なお①の代表格として、Oracleの Dedicated Region（OCI Dedicated Region）も挙げておきます。これはOracleの完全な公開クラウドを、顧客のデータセンター内でOracleが運営・提供するもので、1組織が自分のワークロードのために使います⁴。司令塔（コントロールプレーン）自体はローカルに置かれますが、Oracleが遠隔運用するため接続が前提で、切断すると管理が止まります——Outpostsとは理由が違う（あちらは司令塔がクラウド側）が、切断で止まる結果は同じなので、まとめてタイプ①です⁴。ついでに伏線を張っておくと、この同じ箱を「Oracleではなくパートナーが運営する」版が、次のタイプ②で出てくるAlloyです。箱は同じ、違うのは運営主体だけ——この対比は②で効いてきます。

タイプ②：独立運営型 ── インフラは①と同じ。違うのは「誰が運営するか」

先駆けはOracleの Alloy。①で伏線を張ったとおり、AlloyはDedicated Regionと同じインフラのフットプリント・同じ成長モデル（3ラックから開始して拡張）を使います⁴。違うのは運営主体だけ——パートナー（や企業）自身が独立して運営するのがAlloyです。パートナーは商用モデルや顧客体験をコントロールし、ブランドを付けて、自分が地域のクラウドプロバイダになれます⁵。Alloyを導入したパートナーは、実質的に地域クラウド事業者になるわけです⁶。

同じ箱でも、Oracleが運営すればDedicated Region（①）、パートナーが運営すればAlloy（②）。「箱の中身」ではなく「箱を誰が動かすか」がタイプを分けています。データ主権や運用主権の議論で「運営主体が誰の法域にあるか」が効いてくるのは、まさにこの層の話です。（AlloyにはさらにReserved Regionという派生があり、これはパートナーが特定顧客専用に運営するもの。同じくパートナー運営なので②です。）

なおこの型は、業界では「パートナークラウド」という呼び名で語られることも多いです。直感的で良い名前ですが、運営主体がパートナーとは限らない例（自組織による運営、後述するAWSの自社欧州法人）もあるため、本記事では軸に沿って「独立運営型」で通します。

ユーザー目線での強みは一言で言えます。タイプ③④が切断耐性と引き換えに運用を自分で背負うのに対し、②はクラウドの使い勝手を保ったまま、24/7運用やパッチ適用といった重い部分を運営主体に委ねられる。その運営主体が国内の事業者なら、データとコントロールプレーンを国内法域に置いたまま、運用人材を自前で抱えずに済みます（もちろん運営主体の独立度や契約条件の確認は前提です）。

独立運営型は、Oracleだけの話じゃない ── GCD、AWS、そしてMicrosoftも

この 「パートナーが独立して運営する」型は、いまや主要クラウドが揃って出しています。名前が違うだけで、概念はほぼ同じです。

Google Cloud Dedicated（GCD）

⚠️ ここで紛らわしいのが略語。前半で出てきた GDC は Google Distributed Cloud（オンプレ設置型、connected / air-gapped）。ここで出てくる Google Cloud Dedicated は別製品で、本記事では便宜上 GCD と略します。

GoogleもGCDという形で、Alloyとほぼ同じ構図の製品を出しています。GCDは独立した現地パートナーが運営し、グローバルなパブリッククラウドから物理的・論理的に隔離された、完全にスタンドアロンなGoogle Cloudのインスタンスをデプロイできます⁷。

具体例が分かりやすいです。フランスではS3NS（独立した法人）がGCD上に PREMI3NS を提供し、フランスのANSSIによるSecNumCloud 3.2認証を取得しています⁷。ドイツではThalesが、法的にも運用的にもGoogleから独立した新しいドイツ法人を設立し、現地スタッフが運営する形で提供します（2026年7月時点でプレビュー、GAは2026年末予定）⁸。この独立法人には、非欧州の事業者を含む第三者がデータにアクセスできないよう設計されています⁸。

AWSも同じ枠にいる

AWSも European Sovereign Cloud を、欧州の法人が運営する独立クラウドとして立ち上げています。ただし正確に言うと、AWSの運営主体は第三者パートナーではなく、AWS自身が欧州に設立した法人です。S3NSやThalesのような独立事業者が運営するAlloy/GCDと比べると、運営主体の独立性は一段弱い。それでも「グローバル本体から切り離された現地法人が、現地の法域の下で運営する」という構造は同型なので、本記事では同じタイプ②として扱います。

Microsoftも同じ枠にいる ── National Partner Clouds

そしてMicrosoftも、Sovereign Cloud戦略の一部としてNational Partner Cloudsを持っています。これは承認された国内/地域のパートナーが、国内法の下で独立して運営し、AzureやMicrosoft 365の機能を提供するモデル⁹。前述のAzure Local（Sovereign Private Cloud）が「自組織が運用する」型なのに対し、こちらは「現地パートナーが運用する」型で、まさにタイプ②です。

具体例もはっきりしています。フランスではBleu（OrangeとCapgeminiの合弁）がSecNumCloud要件に沿った「信頼できるクラウド」を、ドイツではDelos Cloud（SAP子会社）が独 BSI のクラウド要件に沿ったものを、それぞれ運営します¹⁰。Microsoftは技術スタックを提供するが、運営は現地法人が国内法の下で担う——構造はAlloyやGCDと同型です。

これでタイプ②は、Oracle・Google・AWS・Microsoftの4社が揃ったことになります。名前は「Alloy」「GCD」「European Sovereign Cloud」「National Partner Clouds」とバラバラですが、構造で見ると全部同じ独立運営型です。

ここで大事なのは、これが「各社がたまたま似た製品を出した」ではなく、同じ構造の要求に対する、同じ形の答えだということ。地政学的な事情や規制（域外適用法からデータを守りたい）で「運営主体を自国/自地域の法人にしたい」という要求が世界的に強まり、各社がそれに応えた結果、同じ型の製品が4つ並びました。名前でなく構造で捉える意味が、ここに一番よく出ています。

境界はにじむ ── そして後編（切って自律する世界）へ

ここまで①②をきれいに分けて説明してきましたが、実際の製品はそこまで行儀が良くありません。構成やレイヤーによって、タイプの境界をまたぐ製品があります。そして面白いことに、その"にじみ"の多くは**「①②（接続前提）の製品が、実は③（切って自律）側にも顔を出す」**という形で現れます。つまり境界事例は、前編と後編をつなぐ蝶番なんです。代表的な3つを見ておきましょう。

Azure Local ── 同じ名前で、接続型にも遮断型にもなる

Azure Localは、通常はAzure(クラウド)をコントロールプレーンとして使う接続型（タイプ①）に見えます。ところが 「Disconnected Operations（切断運用）」というモードを持っていて、これを使うとローカルコントロールプレーンで完全に切断された状態で動きます¹¹——つまりタイプ③になる。

同じ製品名でも、選んだ構成で司令塔の所在が変わり、タイプが動く。「Azure Localだから接続型」と製品名では決めつけられない、ということです。（切断運用モードの中身──ハードウェア要件やクラスタ数の制約など──は、後編で扱います。）

Outposts上のEKS local cluster ── レイヤーで司令塔が変わる

タイプ①で見たとおり、Outposts本体は切断非対応です。ところがその上で動かすEKSには "local cluster" というモードがあって、Kubernetesのコントロールプレーンごとローカル(Outpost上)で動きます¹²。この構成なら、リージョンと切断してもKubernetesのクラスタ操作を継続できます¹²。

つまり「Outposts＝切断で全部止まる」と単純化すると不正確で、どのレイヤーのコントロールプレーンの話をしているのかで答えが変わります。インフラ層の司令塔はクラウド側でも、その上のKubernetes層は手元に司令塔を持てる。1つの環境の中に、タイプ①と③が層をなして同居しうるわけです。

GCD ── 独立運営型でありながら、遮断型の性質も併せ持つ

②で見たGCDには、もう一つ面白い性質があります。Googleとの接続が断たれると、GCDは切断後にキーローテーションを行い、Googleはそのインスタンスにアクセスできません。そして接続が切れても、パートナーは最大12ヶ月間、運用を継続できるよう設計されています¹。②でありながら、③に近い切断耐性を備えているわけです。

これは偶然ではなく、2軸の必然でもあります。「司令塔がパートナー側にあり（問1）、運営もパートナー（問2）だから、Googleと切れても動き続けられる」——2つの軸がそのまま因果としてつながっています。

前編のまとめ、そして後編へ

3つの境界事例に共通するのは、製品名や型のラベルでは答えが出ないということです。Azure Localは構成で、Outpostsはレイヤーで、GCDは設計で、それぞれ境界をまたぐ。でも、どのケースも「この構成は切っても自律するか？誰が運営する？」と問い直せば、正確に位置づけられます。境界がにじむ製品ですら2軸で読める——むしろ、にじむ製品でこそ、この2軸の問いが効きます。

前編で分かったことを一言でまとめると、こうです。「接続を保ったまま主権を手元に寄せる」という一つの狙いに、①（クラウドを延伸する）と②（運営主体を現地に移す）という2つの答えがあり、②では3大クラウド＋Oracleが同じ構造に到達している。

そして境界事例が示したとおり、これらの製品の一部は 「接続を切る」側にも足を伸ばせます。次はいよいよ、その世界——接続を切って自律する③遮断型と④自前です。完全閉域（air-gapped）が本当に必要なのはどんな時か、その代わりに何を背負うことになるのか。後編で扱います。

▶ 後編：接続を切って自律する ── 遮断型（air-gapped）と自前（OpenShift/Nutanix）
→「オンプレに置けるクラウド」が多すぎるので、整理してみた（後編)

---

参考（一次情報）

1. Delivering a secure, open, and sovereign digital world | Google Cloud Blog（GCDは切断後にキーローテーション、最大12ヶ月運用継続）. https://cloud.google.com/blog/products/identity-security/delivering-a-secure-open-sovereign-digital-world ↩ ↩²

2. AWS Outposts racks FAQs — Outpostは親リージョンへの接続を前提とし、切断運用向けには設計されていない旨。https://aws.amazon.com/outposts/rack/faqs/ ↩ ↩² ↩³

3. Overview of connected deployments of Google Distributed Cloud（connectedはCloud VPNでGoogle Cloudに接続し、Cloudコンソール/CLIからクラスタをプロビジョニングする＝クラウドの延伸）. https://docs.cloud.google.com/distributed-cloud/connected/latest/docs/overview ↩

4. Oracle Alloy Overview（Alloy と Dedicated Region は同じフットプリント、違いは運営モデル）. https://docs.oracle.com/en-us/iaas/Content/dedicated/alloy/oracle-alloy-overview.htm ↩ ↩² ↩³

5. Alloy | Oracle（パートナーがクラウドプロバイダになる）. https://www.oracle.com/cloud/alloy/ ↩

6. Oracle Alloy Overview（Alloy 導入で実質的に地域クラウド事業者になる）. https://docs.oracle.com/en-us/iaas/Content/dedicated/alloy/oracle-alloy-overview.htm ↩

7. Dedicated | Google Cloud（GCDは現地パートナーが運営する独立インスタンス／S3NS・PREMI3NSのSecNumCloud 3.2）. https://cloud.google.com/products/dedicated ↩ ↩²

8. Thales Announces Strategic Partnership with Google Cloud to Launch a New Sovereign Cloud in Germany（Google から法的・運用的に独立したドイツ法人が運営、プレビュー〜2026年末GA予定）. https://www.googlecloudpresscorner.com/2026-05-20-Thales-Announces-Strategic-Partnership-with-Google-Cloud-to-Launch-a-New-Sovereign-Cloud-in-Germany ↩ ↩²

9. National Partner Clouds — Microsoft Learn（承認された国内/地域パートナーが国内法の下で独立運営し、Azure/M365機能を提供）. https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/partner/overview-national-partner-clouds ↩

10. Announcing comprehensive sovereign solutions empowering European organizations — The Official Microsoft Blog（Bleu＝Orange×Capgemini／SecNumCloud、Delos Cloud＝SAP子会社／独BSI要件）. https://blogs.microsoft.com/blog/2025/06/16/announcing-comprehensive-sovereign-solutions-empowering-european-organizations/ ↩

11. Disconnected operations for Azure Local overview — Microsoft Learn（ローカルコントロールプレーンで切断運用、最小HW要件が上がる）. https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-overview ↩

12. Deploy Amazon EKS on-premises with AWS Outposts（local cluster はコントロールプレーンをOutpost上で動かす）. https://docs.aws.amazon.com/eks/latest/userguide/eks-outposts.html ↩ ↩²