Azure Local の実態：データセンターに置かれた Azure なのか？

By Mirko Peters · 2026-08-27

ブログへようこそ。最近、エンタープライズ IT のリーダーやクラウドアーキテクト、システムエンジニアと話をしていると、インフラストラクチャの考え方が大きく変わってきていることに気づくはずです。長い間、業界の定説は単純でした。すべてをパブリッククラウドに移行し、物理的なデータセンターは手放す、というものです。しかし現実はそれほど単純ではありません。パブリッククラウドは拡張性や俊敏性の面で優れていますが、あらゆる課題を解決できるわけではないと、企業はすぐに気づきました。厳格なコンプライアンス要件のためにデータをローカルに保持しなければならない場合もあります。パブリッククラウドのリージョンとの往復を許容できないほど、超低遅延を求めるアプリケーションもあります。工場、病院、支店では、ネットワーク障害が起きてもコンピューティング機能を維持できることが求められることがよくあります。

Automatically translated with AI from the original post. Read the English original

ブログへようこそ。最近、エンタープライズ IT のリーダーやクラウドアーキテクト、システムエンジニアと話をしていると、インフラストラクチャの考え方が大きく変わってきていることに気づくはずです。長い間、業界の定説は単純でした。すべてをパブリッククラウドに移行し、物理的なデータセンターは手放す、というものです。しかし現実はそれほど単純ではありません。パブリッククラウドは拡張性や俊敏性の面で優れていますが、あらゆる課題を解決できるわけではないと、企業はすぐに気づきました。厳格なコンプライアンス要件のためにデータをローカルに保持しなければならない場合もあります。パブリッククラウドのリージョンとの往復を許容できないほど、超低遅延を求めるアプリケーションもあります。工場、病院、支店では、ネットワーク障害が起きてもコンピューティング機能を維持できることが求められることがよくあります。

Azure Local は、その点を埋めるための有力なコンセプトです。オンプレミスのインフラストラクチャとクラウド管理の橋渡しを約束しています。しかし同時に、多くの混乱も生んでいます。単に名前を変えた仮想化クラスターなのでしょうか。それとも、自社の物理サーバー上で動く Azure パブリッククラウドの完全なコピーなのでしょうか。このハイブリッドクラウドの複雑な状況を整理するため、最近ポッドキャストで Microsoft MVP の Christoffer Klarskov Jakobsen 氏と、とても有意義な対話を行いました。技術的な詳細やアーキテクチャ戦略を深く知りたい方は、エピソード全編をぜひご覧ください：Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP]。本記事では、そこで得た知見を掘り下げ、Azure Local の実態を明らかにし、適切なハイブリッドクラウドの構築方法を考えていきます。

Azure Local の実態とは？

Azure Local を理解するには、まず誇張された宣伝文句を取り除く必要があります。「Azure」と聞くと、サーバーラックの中でパブリッククラウドのサービスカタログすべてが使えると考えてしまう人が多くいます。しかしそれは明らかに誤りです。Azure Local は、おなじみの物理インフラストラクチャ技術と、クラウドベースの管理、ガバナンス、セキュリティ機能を組み合わせたものです。

Azure Local の核となるのは、従来型の仮想マシンや、Kubernetes による最新のコンテナ化ワークロード、さらには Azure Virtual Desktop や SQL Managed Instance といった特殊なワークロードを、ローカルのハードウェア上で直接実行できることです。ただし、本当の価値はローカルで VM を動かせることそのものではありません。そうした機能は、従来の仮想化で何十年も前から実現してきました。本当の差別化要因は、そのローカルインフラストラクチャを包み込む Azure の管理体験です。工場の生産現場、医療機器、現地のユーザーの近くにワークロードを置きながら、Azure のツールを使って環境の管理、監視、保護を行えます。

Azure Local は、データセンターに置かれた Azure にすぎないのか？

よくある誤解は、Azure Local を導入すると、自社の建物の中に小型で自己完結型の Azure リージョンが手に入る、というものです。確かに選択されたいくつかの Azure サービスと管理機能は利用できます。しかし、基盤となるアーキテクチャは、パブリッククラウドのデータセンターとは本質的に異なります。

Azure を利用する場合、利用するのは Microsoft が完全に管理する、大規模なハイパースケールのマルチテナント基盤です。一方、Azure Local を利用する場合は、自社の施設やコロケーションスペースに設置されたハードウェアを運用することになります。コントロールプレーンや管理体験は Azure と同じように見え、操作感も Azure に近いものの、物理的な環境、電源、冷却、そしてハードウェアのライフサイクルについては自社が責任を負います。

この違いがあるため、Azure Local をパブリッククラウドの 1 対 1 の代替として扱うと、誤ったアーキテクチャ上の判断につながりかねません。Azure Local は、むしろ橋渡しとして理解するのが適切です。パブリッククラウドへのアクセスが制限されている、あるいは現実的でない場合に、クラウドの運用モデルをエッジや従来型のデータセンターにまで広げる手段なのです。

Azure Local は自社にとって適切なのか？

すべての組織に Azure Local が必要なわけではありません。ワークロードが完全にクラウド対応済みで、信頼性が高く高速なインターネット接続があるなら、パブリッククラウドのみを利用するのが通常は最も抵抗の少い道です。ただし Azure Local が非常に効果を発揮する特定のシナリオはいくつかあります：

• 規制とデータ所在地の要件: 金融、行政、医療などの業界では、特定のデータを地理的または物理的な境界内にとどめることを義務付ける厳格な法規制が適用される場合があります。
• 超低遅延のワークロード: 産業オートメーション、製造現場、金融取引システムでは、わずかなネットワーク遅延の急増さえ許容できません。コンピューティング リソースをローカルに置くことで、即時の応答時間を確保できます。
• 切断時の運用: 外部インターネット接続が切断された場合でも、中核となる業務機能を維持する必要がある環境では、ローカル インフラストラクチャの恩恵が大きくなります。
• ローカルの AI とエッジ分析: AI ワークロードの普及に伴い、組織は中央のクラウドに要約やテレメトリを送信する前に、大量のローカル データ ストリームをリアルタイムで処理する必要があることがよくあります。

Azure Local をローカル クラウドとして扱う

Christoffer との議論から得た最も重要なアーキテクチャ上の教訓の 1 つは、Azure Local を通常のスタンドアロン サーバー数台のように扱ってはいけないということです。これまで多くの組織では、オンプレミスのインフラストラクチャを後回しにしてきました。誰も触りたがらないレガシー VM の置き場所のような扱いです。

Azure Local には、異なる考え方が必要です。複数のインフラストラクチャ レイヤー、ネットワーク構成、ストレージ プール、Azure に接続されたコントロール プレーンが関係します。そのため、従来のハードウェア インフラストラクチャと最新のクラウド管理の両方を理解したチームが必要です。単に仮想化クラスターを構築しているのではなく、実質的にはローカル クラウドを運用しているのです。

Azure Local と Azure Landing Zone の統合

戦略なしにワークロードをハイブリッド環境へ移行すると、技術的負債が増えるだけです。ここで登場するのが Azure Landing Zone です。Azure Landing Zone は、スケール、セキュリティ、ガバナンス、ネットワークを適切に考慮した基盤環境を構築するための、体系化されたアーキテクチャ アプローチを提供します。

これまで Azure Local 環境は、より広範なクラウド ガバナンスの枠組みから切り離されていることが多くありました。しかし、新しい機能により、複数のサブスクリプションとリソース グループを使って Azure Local を構成できるようになりました。これにより、ローカル インフラストラクチャを企業全体の Landing Zone 戦略にシームレスに統合できるようになります。

適切なサブスクリプションの境界で環境を整理し、開発、テスト、本番のワークロードを分けることで、ローカルのワークロードが管理されていないサイロに存在しない状態を確保できます。代わりに、組織全体のガバナンス モデルに直接組み込まれます。

サブスクリプションと管理グループの設計

サブスクリプションを、組織が構築するすべてのものを何でも入れる巨大な容器として扱うべきではありません。Christoffer は、意図的なサブスクリプション設計の重要性を強調しています。開発には専用のサブスクリプションを割り当てます。本番ワークロードは分離します。ネットワーク、ID、ログ記録などの共有プラットフォーム サービスには、専用の境界を作成します。

サブスクリプションの上位には管理グループがあります。管理グループを使うと階層構造を構成でき、複数のサブスクリプションに対して、ポリシーとロールベースのアクセス制御をまとめて適用できます。Azure Local の進化に伴い、これらの管理グループとローカル スコープによって、ハイブリッド資産を一貫して管理することがこれまで以上に容易になりました。

Azure Policy によるガバナンスの適用

ドキュメントと期待だけでインフラストラクチャを安全に保とうとしても、うまくいきません。Azure Policy は、最新の Landing Zone アーキテクチャにおける究極のガードレールとして機能します。ポリシーは、環境を自動的に監査し、非準拠のリソースを特定し、設定ミスをその場で修復し、承認されていない、または安全でないリソースの作成を完全に拒否できます。

特定のリージョン構成を強制する場合でも、適切な暗号化なしにパブリック公開のストレージ アカウントの展開を防ぐ場合でも、必須のタグ付けルールを適用する場合でも、Azure Policy はガバナンス ルールをプラットフォームの基盤に直接組み込みます。

ID、RBAC、ゼロ トラスト

ハイブリッド クラウド環境のセキュリティは、ゼロ トラストの原則に従う必要があります。ロールベースのアクセス制御 (RBAC) を使うことで、組織は最小特権の原則を適用できます。アプリケーション オーナーが基盤となるネットワーク インフラストラクチャに管理者アクセスを持つことはあってはならず、サポート担当者がログ記録システムに対して無制限の権限を持つべきではありません。

Azure Local と構造化された Landing Zone を組み合わせると、ワークロードを論理的なセキュリティ階層に分けられます。例えば次のようになります。

• Tier 0: ドメイン コントローラーなど、機密性の高いコア インフラストラクチャです。極めて厳格なアクセス制限を設けた専用のサブスクリプションに配置します。
• Tier 1: エンタープライズのメンバー サーバーと、重要なバックエンド データベースです。
• Tier 2: Azure Virtual Desktop インスタンスなど、エンド ユーザー向けのワークロードです。

このように階層化しておけば、ある領域で侵害や構成ミスが発生しても、ローカル インフラストラクチャ スタック全体が自動的に危険にさらされることはありません。

Azure Arc によるハイブリッド インフラストラクチャの管理

最新のハイブリッド クラウド アーキテクチャを支える大きな技術の一つが Azure Arc です。従来、パブリック クラウドのデータセンター外のリソースを管理するには、分断されたサードパーティ製の監視ツール、単独のパッチ管理ユーティリティ、そして相互に連携しないセキュリティ ダッシュボードを使い分ける必要がありました。

Azure Arc は、Azure の制御プレーンをほぼあらゆるインフラストラクチャに拡張します。サーバーが Azure Local 上でオンプレミス稼働していても、他社のハイパーバイザー上にあっても、あるいは他のクラウド プロバイダーでホストされていても、Azure Arc はそれらを Azure の管理下に取り込みます。

Arc で接続すると、Microsoft Defender for Cloud、Azure Update Manager、Azure Policy といった Azure のネイティブ サービスを、分散した環境全体で利用できます。ハードウェアの物理的な設置場所は、レイテンシー、コンプライアンス、可用性の面で今も重要です。しかし、それによって運用管理モデルが完全に別々になる必要はもうありません。

Infrastructure as Code による Azure Local の自動化

今もグラフィカル ユーザー インターフェイスにサインインして、ウィザードの画面を順にクリックしてインフラストラクチャを展開しているなら、そろそろ見直す時期です。最新のクラウド エンジニアリングの基本原則はシンプルです。同じ作業を二度以上行うなら、自動化しましょう。

Infrastructure as Code (IaC) はパブリック クラウドのリソースだけのものではありません。Azure Local のインフラストラクチャとワークロードにも IaC の原則を適用できますし、適用すべきです。テンプレートを書く初期投資には時間がかかりますが、一貫性、災害復旧の速度、再現性という面での長期的な効果は、他に比べるものがありません。

なぜ Bicep なのか

Microsoft のエコシステムで IaC 言語を選ぶとき、多くのエンジニアにとって Bicep はすぐにお気に入りの選択肢になりました。PowerShell のバックグラウンドを持つ Christoffer は、Bicep への移行がスムーズで自然だと感じたそうです。Visual Studio Code の拡張機能のおかげで、最新のツールは豊富な構文検証、入力補完、Azure デプロイ パイプラインとの深い統合を提供します。

Terraform のようなツールはマルチクラウド環境で優れていますが、Bicep は Azure Resource Manager テンプレートや継続的デプロイのワークフローとシームレスに統合される、簡潔でネイティブな操作性を備えています。そのため、Azure Local のデプロイを自動化する際の理想的な選択肢になります。

まとめ: 正しい方法でハイブリッド クラウドを構築する

Azure Local を正しく理解するには、それが何であり、何ではないかを把握することに尽きます。パブリック クラウドの大規模な機能を、お使いのサーバー ルームに詰め込もうとするものではありません。むしろ、ローカルのコンピューティング能力と、クラウド規模の管理、ガバナンス、セキュリティを組み合わせた、高度なハイブリッド プラットフォームです。

Azure Local を Azure Landing Zones と組み合わせ、Azure Arc で統合的な制御を実現し、Bicep などのツールによる Infrastructure as Code を取り入れることで、組織は回復力が高く、安全で管理しやすいハイブリッド クラウド アーキテクチャを構築し、長く使い続けられるものにできます。ローカル インフラストラクチャの統制とクラウドの俊敏性のどちらかを選ぶ必要はもうありません。正しい方法で構築すれば、両方を手に入れられます。

Christoffer Klarskov Jakobsen との対談の全編を聴き、ハイブリッド アーキテクチャについてさらに専門的な知見を得るには、ぜひポッドキャスト エピソードをお聴きください: Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP].