Azure Multicloud Interconnectとは？AWSとAzureをネイティブ直結する仕組みや料金、従来経路との違いを解説

Azure Multicloud Interconnect（アジュール・マルチクラウド・インターコネクト、以下AMI）は、Microsoft AzureとAWSを共同マネージドの単一リソースで直結する新しいマルチクラウド接続サービスです。
2026年8月31日にPublic Previewとして発表され、AWS側の「AWS Interconnect – multicloud」と対になって同時提供が開始されました。

これまでAzureとAWSを跨いだプライベート接続はMegaport／Equinix FabricなどのNNIパートナー経由が代表的な選択肢で、自己構築型のNNI構成では物理配線・BGP設定・両クラウドでのプロビジョニングを個別に束ねる必要がありました。AMIはこの物理層・下位レイヤーの複雑さをCSP側で吸収し、ユーザー側はExpressRoute circuitとAMIリソースの作成、activation keyの交換、VNet gateway・connectionの設定を行うだけで、両クラウドがマネージドに繋がる設計です。

本記事では、Provider-managedアーキテクチャの中身、Preview時点の対応リージョン・帯域・SLA、ExpressRoute／Direct Connectとの住み分け、Megaport／Equinix Fabric経由との比較、Preview中無料とGA後の料金構造、実際の開始手順、そして日本リージョン未対応下での導入判断軸までを、2026年9月時点の一次情報で体系的に整理します。

Azure Multicloud Interconnectとは何か

Azure Multicloud Interconnect（アジュール・マルチクラウド・インターコネクト、以下AMI）は、Microsoft AzureとAWSを共同マネージドの単一リソースで直結する、マルチクラウド接続サービスです。

MicrosoftとAWSは2026年8月31日にAMIのPublic Previewを同時発表し、AWS側の対応サービス「AWS Interconnect – multicloud」と対になる形で提供を開始しました。

AMIが従来のマルチクラウド接続と根本的に違うのは、物理接続・下位レイヤーのルーティング・冗長化・MACsec暗号化・ライフサイクル管理といった裏方部分を両CSPが担うProvider-managed設計になった点です。

AWSのOpen APIスペックをMicrosoftが採用した経緯

AMIを理解するうえで押さえておきたいのが、これがMicrosoft単独設計の新サービスではなく、AWSが先に公開した相互運用仕様の上に構築されている、という点です。

AWS Interconnectのイメージ

AWSは2025年11月にAWS Interconnect – multicloudをPreviewで発表し、re:Invent 2025で相互運用のOpen APIスペックをApache 2.0ライセンスでGitHub公開しました。2026年4月にはこの仕組みを使ってGoogle Cloud接続がGAし、その後Oracle Cloud Infrastructure（OCI）もGA、今回8月末にMicrosoft Azureが第3のパートナーCSPとして仕様採用を発表した流れになります。

つまりAMIはAzure側の「AWSと繋がる窓口」ですが、内部で使う相互運用APIは他のCSPと共通で、事実上のマルチCSP規格になりつつあります。AWSのNetwork Services VPであるRobert Kennedy氏はAzure公式ブログ内で「MACsecセキュリティ・four-nines availability・ワンクリックでのスケーラビリティを両側が同じ水準でコミットしたのが今回の意義」とコメントしています。

---

Azure Multicloud Interconnectが解決するAWS↔Azure接続の複雑さ

ここからは、AMI登場によってAWS↔Azure接続のどこが具体的にどう変わったのかを、従来経路との対比で整理します。

Microsoft AzureとAWSはそれぞれ独立した基幹サービスを提供しているため、両クラウドを跨いで動くワークロード（ハイブリッドAIや基幹DBレプリケーション、M&A後の統合環境）を扱う企業は、これまで別々のプロビジョニング・別々の運用管理・別々のサポート窓口という三重苦を抱えていました。

従来のマルチクラウド接続で発生していた手順

AMIが登場する前、AWS↔Azureをプライベート接続で結ぶ代表的な選択肢はMegaport／Equinix FabricなどのNNIパートナー経由でした。

同じNNIパートナー経由でも、Megaport Cloud RouterやEquinix Fabric Cloud Routerのように物理クロスコネクトなしで仮想接続を組める構成もありますが、自己構築型のNNI構成では以下のような複数プロセスを個別にコーディネートする必要がありました。

• 物理相互接続の確保（自己構築型構成の場合）
  NNIパートナーのデータセンター内で両クラウドの物理ポートを確保し、キャリア間クロスコネクトを敷設
  
  

• 両CSPでの回線プロビジョニング
  Azure側でExpressRoute回線を、AWS側でDirect Connect回線をそれぞれ個別に発注し、両CSP・パートナー・自社の3者で調整
  
  

• BGPセッション設定
  両クラウド境界でBGPピア設定・AS番号設計・ルート広告制御を手動で実施
  
  

• 冗長化・障害設計
  物理経路の二重化・BGPフェイルオーバー・監視の仕組みをすべて自社で組む
  
  

• 接続事業者との調整
  障害時はAzure・AWS・NNIパートナー・自社NW部隊のどこにチケットを切るかを個別に判断

Microsoft Azureの公式ブログは、こうした従来方式全般について「AWSとAzureを繋ぐ意思決定から実装完了まで数週間〜数ヶ月がかかっていた」と説明しています。

仮想接続型のCloud Router構成では物理手配部分の負荷は下がりますが、両CSP側の設定・BGP・監視は依然としてユーザー側の責任範囲でした。

AMIが吸収する複雑さ

AMIは上記のうち、物理接続・下位レイヤー設定・冗長化・暗号化を両CSP側に寄せる設計です。

ユーザーが引き続き自分で管理するのは、両クラウド内のアドレス設計・ルート意図・ファイアウォール・アクセスポリシー・ワークロード暗号化・アプリケーションレイヤーのレジリエンスといった、自社ポリシーが絡む上位レイヤーです。

以下の表で、自己構築型NNI構成とAMIで「誰が何をするか」がどう変わるかを整理しました。

工程	従来（自己構築型NNI経由）	AMI Preview
物理回線	自社＋NNIパートナーで手配	両CSPのマネージド共通インフラを利用
Azure側プロビジョニング	ExpressRoute回線を個別発注	AMIポートタイプでcircuit＋AMIリソース作成
AWS側プロビジョニング	Direct Connect回線を個別発注	activation key redeemで自動プロビジョン
BGPセッション設定	自社で設計・投入	両CSPが下位レイヤーで自動管理
MACsec暗号化	個別設定・要件次第	物理リンクでデフォルト有効
冗長構成	自社で二重化設計	単一論理リソースの背後で四重冗長
接続事業者との調整	3者間で個別調整	第三者接続事業者との調整が減る

比較で分かるのは、AMIが「単に手続きを簡素化した」のではなく、物理層・下位レイヤーの責任分界点そのものをCSP側に大きく寄せたという点です。

従来自社が抱えていたBGP設計・冗長化・物理回線調整・暗号化設定が、両CSP側の自動処理に集約されます。

その結果、両クラウドを跨いで動く基幹ワークロードを持つ企業にとっては、「実装が速い」以上に第三者接続事業者との調整レイヤーが減ったことのほうが実務価値としては大きい変化になります。

---

Azure Multicloud InterconnectのProvider-managedアーキテクチャ

AMIの内部設計は、両CSPが共同で運用する「Provider-managed」モデルに基づいています。

Azure↔AWS両側の構成要素と主要特徴（Single logical resource／MACsec／99.99% availability／quad-redundant）を1枚に集約（出典：Microsoft Tech Community）

Microsoft側の公式サマリ図では、Azure側のVirtual Network＋ExpressRoute Gateway＋4基のMSEE（Microsoft Enterprise Edge）と、AWS側のVirtual Private Cloud＋Direct Connect Gateway＋4基のRoutersが、真ん中の「Managed private path（4×400G・quad-redundant）」で繋がる構成が示されています。

下部の4つのバッジ「Single logical resource（単一論理リソース）」「MACsec encrypted by default」「99.99% availability target」「Elastic bandwidth・IPv6-ready」がAMIの中核特性です。

ここからは、ユーザーが直接触らないがサービスの信頼性を決めている裏側の仕組みを、この構成に沿って整理します。

単一論理リソース＋四重冗長のプロビジョニング設計

AMIの中心にあるのは、Azure側で作成する1つのMulticloud Interconnectリソースです。

このリソースは、AWS側の対応リソースとactivation keyでペアリングされ、両側で同じ顧客の相互接続リソースとして対応付けられます。

Azure Multicloud Interconnectの四重冗長設計（Partners Edge×4↔Microsoft Enterprise Edge×4）（出典：Microsoft Learn）

パートナーCSP側の物理エッジ機器「Partners Edge」が4基、Azure側の「Microsoft Enterprise Edge」が4基、両者を4本の物理リンク（Link 1〜4）で接続する構成がMicrosoft Learnの公式内部図で明示されています。

これは同FAQの「redundant infrastructure across physically separate locations」の記述を視覚化したもので、ユーザーは冗長構成を意識せず1リソースだけを監視し、両CSPが物理層の障害監視と復旧を担当する設計になっています。

Azure公式ブログでは、GA時にday oneから最大100 Gbpsまで接続できると明言されており、AWSのRobert Kennedy氏コメントにある「four-nines availability」（99.99%可用性）が両CSPの可用性目標として掲げられています。

MAC Securityを物理リンクでデフォルト有効化

AMIのもう一つの特徴は、MAC Security（MACsec）が物理リンクでデフォルト有効な点です。

MACsecは、物理イーサネットリンク層でフレームを暗号化する規格で、上位のIPsecやTLSと組み合わせて多層暗号化を構成するときの土台になります。従来のNNI経由接続でMACsec相当を有効にするには、両側のキャリア機器で個別にMACsec対応を確認し、鍵管理を自社で設計する必要がありましたが、AMIではオプトアウトなしで最初から暗号化された物理リンクが引かれます。

Microsoft LearnはFAQ内で「MACsec is enabled by default on the physical links」と明記しつつ、「ワークロードレベルの暗号化（TLS・IPsec等）は必要に応じてユーザー側で追加する」責任分界を示しています。物理層は両CSPが担保し、アプリケーション層はユーザーが担保する、という設計です。

activation key・BGP自動管理・ExpressRoute gateway要件

AMIのプロビジョニングは、Azure・AWSどちらから開始してもよい対称設計になっています。片方の管理コンソールでactivation keyを生成し、もう片方でredeem（引換）することで、CSP・リージョン・帯域・アカウントの4項目が一致するかが自動検証され、一致した場合のみプロビジョニングが開始されます。

BGP・vLAN・point-to-point addressingといったルーティング下層の設定は両CSPが自動管理するため、ユーザーはBGPセッション設定を1行も書く必要がありません。従来のExpressRoute利用でよくあった「AS番号設計」「ルート広告制御」「Route Filter調整」といった作業自体が消えています。

AWS↔Azure両側のSite/Device冗長構成とBGP/ECMPによるSingle Multicloud Interconnect（出典：Microsoft Tech Community）

AWS Interconnect Locations側のSite A・Site Bにそれぞれ2基のDevice（Device A〜D）が配置され、対応するAzure Peering Locations側でも同構成でミラーされる様子が物理レイヤー図で示されています。両側の物理エッジ機器はBGPとECMP（Equal-Cost Multi-Path）で束ねられ、ユーザーからは「Single Multicloud Interconnect」という論理リソース1本として扱われます。

この設計により、片側のSite障害でも別Siteの経路で通信が継続する構造です。

ただし、AMI経由でAzureに入ってきたトラフィックを実際のVNetに届ける入口として、Azure ExpressRouteのvirtual network gateway（ゲートウェイ）は引き続き必要です。

ExpressRoute gatewayは受信側パスにのみ関与し、Azureから外向きに出るパスには入らない、という非対称構成である点も、FAQで明示されています。

---

Azure Multicloud Interconnectの対応リージョン・帯域・SLA

AMIは発表当日からPublic Previewで開放されていますが、Preview中はいくつかの明示的な制限が設けられています

。導入検討する場合は、この制限が自社の想定用途にはまるかをまず確認する工程が必須です。

Preview対応リージョン——4リージョンに限定

Microsoft LearnのAvailability and limitsによれば、Preview時点でAMIが利用できるAzureリージョンは以下の4つに限定されています。

• Australia East（オーストラリア東部）
• East US（米国東部）
• Germany West Central（ドイツ中西部）
• West US（米国西部）

対応するAWS側リージョンは、AWSのプレスリリースによれば US East（N. Virginia）／US West（N. California）／Asia Pacific（Sydney）／Europe（Frankfurt）の4つで、Azure側4リージョンと1対1対応でペアリングされる構成です。

注目すべきは、Japan Eastを含む日本リージョンがPreview対象に入っていない点です。

日本国内のワークロードをAMIで直接繋ぐには、GA時点でのリージョン拡張を待つか、Preview期間はAsia Pacific（Sydney）経由で検証環境を組む形になります。

Preview中の帯域上限——1 Gbps

Preview中の帯域は1 Gbpsに固定されており、複数帯域からの選択はできません。Azure公式ブログはGA時に最大100 Gbpsまで拡張予定と説明していますが、Preview中はこの上限がハードキャップとして働きます。

さらに、Microsoft Learnによればカスタマー1社あたりPreviewリージョンごとに1本のみという本数制限もあります。

1本のAMI論理リソース自体は物理的に分離された4本のリンクによる四重冗長構成ですが、Preview中は同一リージョン内で独立した2本目のAMIを追加することはできません。

SLAはPreview中は非提供

AMIはPreview中、Service Level Agreement（SLA）が明示的に非提供とMicrosoft LearnのFAQで宣言されています。

GA時に「four-nines availability」（可用性目標として両CSPが掲げる水準）が正式なSLAとして提示されるかは現時点で公表されておらず、Preview中は当然ベストエフォート扱いです。

以下の表で、Preview時点の主要制限とGA時の想定値を整理しました。

項目	Preview（2026年9月時点）	GA時の想定
対応Azureリージョン	4リージョン（Australia East／East US／Germany West Central／West US）	拡張予定・詳細未公表
帯域上限	1 Gbps固定	day oneから最大100 Gbps
同時本数	カスタマー×リージョンあたり1本	未公表
SLA	なし	GA時の正式SLA数値は未公表（可用性目標は「four-nines availability」）
対応CSP	AWSのみ	追加CSP拡張予定

この整理から言えるのは、Preview時点のAMIは技術検証・単一系統のPoC・移行判断用の1系統確保に適したフェーズであり、本番基幹系の全面移行を担うにはGA・日本リージョン対応・複数本冗長という3つの節目を待つ必要がある、ということです。

---

Azure Multicloud InterconnectとExpressRoute・Direct Connectの関係

AMIは新サービスといっても、既存のAzure ExpressRouteやAzure VNetを置き換えるものではなく、それらを基盤技術として使う「上位の管理レイヤー」です。ここではExpressRouteとの住み分けを、公式FAQの記述に沿って整理します。

AMIはExpressRouteを基盤にしたManaged Cloud-to-Cloud接続

Microsoft LearnのFAQは、AMIとExpressRouteの関係を「Azure Multicloud Interconnect uses ExpressRoute as its underlying connectivity technology」と説明しています。つまりAMIの内部では、Azure側の物理接続としてExpressRoute回線が引かれ、その上に「マルチクラウド専用のManaged experience」がラップされている構造です。

ユーザーはまずExpressRoute circuitを作成する際にAMI用のポートタイプ「Azure Multicloud Interconnect」を選択し、その後AMIリソースをAzure Portalから作成してcircuitと紐付けます。

circuitとAMIリソースの管理はユーザー側で行いますが、BGPピアリング・vLAN・point-to-point addressing等の下位レイヤー設定は両CSPが自動処理するため、従来のExpressRoute利用と比べて手動運用の範囲は大幅に狭くなります。

一方AWS側では、AMIの対応リソースであるAWS Interconnect – multicloudが同じ位置づけで、AWS Direct ConnectをunderlyingとしてManaged experienceを提供する構造になっています。

ExpressRoute・Direct Connect・AMIの使い分け

Microsoft LearnはFAQで、接続要件に応じたサービス選択の指針を以下のように示しています。

• オンプレミス・コロケーションからAzureへの接続
  Azure ExpressRoute。自社データセンター・コロケーションから直接Azureへ引くパターン
  
  

• Azureから対応CSP（Preview時点はAWSのみ）への接続
  Azure Multicloud Interconnect。両側のクラウド間を直結する用途
  
  

• AWSから対応CSP（Google Cloud／OCI／Azure Preview）への接続
  AWS Interconnect – multicloud。AWSを起点にする視点で同じことを実現
  
  

• キャリア経由・Microsoft peeringが必要な特殊要件
  引き続きExpressRoute。マルチクラウドではない一般的なプライベート接続用途

実務観点でまとめると、Azure ↔ オンプレは従来通りExpressRoute、Azure ↔ AWSはAMIという2軸の切り分けが基本です。

Direct Connect側も同様に、AWS ↔ オンプレは従来のDirect Connect、AWS ↔ Azure／Google／OCIはAWS Interconnect – multicloudという棲み分けになります。

以下の表で、3つのサービスの位置関係を整理しました。

サービス	接続対象	基盤技術	主な用途
Azure ExpressRoute	Azure ↔ オンプレ・コロケーション	自社／キャリア	従来型のプライベート接続、Microsoft peering
AWS Direct Connect	AWS ↔ オンプレ・コロケーション	自社／キャリア	従来型のAWS向けプライベート接続
Azure Multicloud Interconnect	Azure ↔ 対応CSP（Preview中はAWS）	ExpressRoute（内部）	クラウド間Managed接続
AWS Interconnect – multicloud	AWS ↔ 対応CSP（Google Cloud／OCI／Azure Preview）	Direct Connect（内部）	クラウド間Managed接続

比較から見えるのは、AMIはExpressRouteの後継ではなく、「クラウド間接続」というレイヤーを新たに切り出したサービスである、という設計思想です。既にExpressRouteを引いてオンプレとAzureを繋いでいる企業も、AMIを追加すれば同じAzureテナントから両クラウドへの接続を並列に管理できます。

---

Azure Multicloud InterconnectとMegaport・Equinix Fabric経由の比較

これまでAWS↔Azureをプライベート接続していた企業の多くは、MegaportやEquinix Fabricといった第三者のマルチクラウド接続サービス経由で構成してきました。

ここでは、AMIと従来経路の機能・運用・コスト面での差分を整理します。

従来経路の位置づけ

MegaportやEquinix Fabricは、両クラウドが直接支援しない領域（クラウド間接続、キャリア間接続、複数拠点集約）を吸収する第三者のNNIレイヤーとして発展してきました。ユーザーは各パートナーの管理ポータル上でクラウド間の仮想回線を発注し、その裏側でパートナーが両CSPと物理相互接続を維持しています。

物理クロスコネクトを自前で敷設する自己構築型構成と、Megaport Cloud RouterやEquinix Fabric Cloud Routerのように物理クロスコネクトなしで仮想接続を組める構成の両方が存在します。

契約形態は構成次第で変わりますが、いずれの方式でも自社・パートナー・両CSPの複数関係者と個別に料金体系・SLA・障害切り分け・パートナー費用の管理を並行して回す必要がありました。

AMIと従来経路の機能比較

以下の表で、AMIと従来経路の代表的な差分を整理しました。数値は本稿執筆時点で公開されている情報に基づきます。

観点	AMI（Preview）	Megaport／Equinix Fabric経由
契約先・関係者	各CSP（Microsoft／AWS）と個別。第三者接続事業者との契約・調整は不要	自社・パートナー・両CSPの複数関係者と個別調整が必要
プロビジョニング	Azure/AWSのポータル操作＋activation key交換	パートナー管理ポータル＋両CSP側発注
BGP設定	両CSP自動管理	自社設計・投入が基本
MACsec暗号化	物理リンクでデフォルト有効	パートナー機器・要件次第
対応地域	Preview 4リージョン、日本未対応	Megaport等は日本含む200超のPoP対応
帯域	Preview 1 Gbps／GA時最大100 Gbps	パートナーによっては50 Mbps〜100 Gbps以上
コスト（AMI側）	Preview中無料、GA時の料金体系は未公表	パートナー月額＋両CSPのポート料金＋データ転送
マルチCSP対応	AMIはAzure視点、AWS視点はAWS Interconnect–multicloud	1つのパートナーで複数CSP集約可

ここから読み取れる実務的なポイントは、AMIは第三者接続事業者との調整レイヤーを減らせる強みがあるが、地域カバー・柔軟な集約構成では従来経路が依然として優位という点です。特に日本国内リージョンからのプライベート接続、複数拠点・複数CSP集約、パートナーポータルでの一元発注といった用途では、Megaport／Equinix Fabricの守備範囲がAMIより広い状態が続きます。

一方、AMI対応リージョンでAzure↔AWS 1対1の接続を新規に組む用途では、AMIの方が第三者接続事業者との調整工数・BGP設計コストを抑えられます。既存のパートナー契約と併存させて、地域・用途別に使い分ける構成が現実解になるケースが多いでしょう。

---

Azure Multicloud Interconnectの料金

AMIの料金は、Preview中はAzure側・AWS側とも接続そのものが無料で、GA後は両CSPそれぞれで料金体系が適用される構造になります。

関連リソース（VM・ストレージ・ExpressRoute gatewayやAWS側VPC等）の実行時料金はPreview中も従来通り発生します。

Preview中はAzure側もAWS側も接続料金なし

Microsoft Learnのoverviewによれば、Preview中はAzure Multicloud Interconnectのサービス料金と、AMI経由のAzure egress（外向き通信）料金の両方が無料です。

通常のAzure→インターネット egressが数十円／GB発生するのと比べると、Preview中は事実上「AMI経由の通信料金がゼロ」で検証できます。

AWS側もAzure向けAMI PreviewはPreview期間中の接続料金・データ転送料が無料として扱われます（AWS Interconnect – multicloudのAzureペア接続は現在Public Preview中）。VPC内のリソース利用料金・AMI経由でないAWS側egressなど、従来のAWS利用料金は別途発生します。

つまりPreview期間中は両CSPともAMI「接続そのもの」の料金はゼロで、関連リソース料金のみが従来通り課金される、と整理するのが正確です。

GA済みCSP向けAWS Interconnect – multicloud料金（参考情報）

Azure向けAMIのGA後料金は現時点で未公表ですが、AWS側は既にGoogle Cloud／OCI向けでGAしており、それらの料金体系が参考情報として公開されています。

AWSのプレスリリースによれば、GA提供中のAWS Interconnect – multicloudには以下2階の料金構造があります。

• 無料枠（Free Tier）
  2026年5月29日追加。500 Mbps接続を無料で1本利用でき、月あたり約160TBのデータ転送が可能。GA済みクラウドプロバイダ（Google Cloud／OCI）向け接続で1顧客・1リージョン・1本まで適用される
  
  

• 有償帯域・地理Tier
  500 Mbpsを超える帯域や複数本の構成では、帯域と接続先クラウドの地理範囲による5階層のTier料金（Tier 1〜Tier 5）が適用される。各Interconnectは最も高いTierに割り当てられ、経由するすべてのTierに個別課金されるのではない設計

Azure向けGA時の料金体系・Free Tier適用可否・帯域Tier割り当ては未公表のため、上記はあくまでGA済みCSP向けの参考情報として押さえておき、Azure向けGA発表時点で最新の公式料金表を見て判断する必要があります。

料金判断の実務ポイント

Preview中は両CSPとも接続料金がゼロで、検証用途では追加コストがほぼ発生しません。ただしGA後にどの料金が適用されるかで実運用コストは変わるため、以下の3点を事前に押さえておくと切替判断が滑らかになります。

• AMI側GA料金の公開タイミングを追う
  Microsoft LearnのFAQでは「Preview中はAMIサービス料金なし、GA時に料金体系を公表」と明記されている。GA発表と同時に見積り直せる体制を作る
  
  

• GA済みCSP向け料金を参考情報として押さえる
  Google Cloud／OCI向けGAで確立された5階層Tier料金と500 Mbps Free Tierは参考情報として把握しておき、Azure向けGA時に公表される正式な料金体系で見積り直せる準備をしておく
  
  

• 既存Megaport／Equinix Fabric契約との比較軸を持つ
  現行のパートナー料金（月額＋ポート料金＋データ転送料）を分解して、AMI GA時の料金と単純比較できる形にしておく。「安いから移行」ではなく「運用集約による工数削減も含めて再計算する」という視点が重要

Preview期間は料金比較を精密にやる時期ではなく、GA後の料金構造が公開された段階で本試算する前提の検証枠として使うのが実務的です。

---

Azure Multicloud Interconnectの開始手順

AMIのPreviewは、Microsoft Learnに公開されている4ステージのプロビジョニングフローで構築します。

ユーザー側の作業はExpressRoute circuit作成・AMIリソース作成・activation key交換・VNet gateway/connection設定に集約され、物理配線や下位レイヤーのBGPピアリング・vLAN設定は両CSPが自動処理します。

Azure Multicloud Interconnectのプロビジョニング4ステージ（出典：Microsoft Learn）

4ステージの流れを追うと、以下の順番で進めます。

• ①ExpressRoute circuit作成
  「Azure Multicloud Interconnect」ポートタイプを選択してcircuitを作成
  
  
• ②Azure Multicloud Interconnectリソース作成
  Azure側でAMIリソース本体を作成
  
  
• ③Provider setup
  activation keyを生成または引換
  
  
• ④Connected workloads
  Azure・パートナークラウド双方のApps・Data・AI/MLワークロードを接続

ユーザー側の作業はこの4ステージのAzure/AWS操作に集約され、物理配線・下位レイヤーのBGPピアリング・vLAN設定は両CSP側で自動処理されるのがAMI設計上のポイントになります。

前提条件

Preview利用にあたっての前提を、Microsoft LearnのFAQとoverviewから整理すると以下のとおりです。

• 対応リージョン確認
  Australia East／East US／Germany West Central／West USのいずれかで、Azure側とAWS側のペア対応リージョンを選ぶ
  
  

• AWS側アカウント準備
  Preview対象のAWS Interconnect – multicloudが有効なAWSアカウントを保有し、対応リージョンでVPCを準備
  
  

• アドレス設計
  Azure VNetとAWS VPCで重複しないIPアドレス空間を計画。両クラウドを跨ぐルート意図（route intent）と、AMI経由で流すワークロードプレフィックスを整理
  
  

• ExpressRoute gateway準備
  Azure側で受信トラフィックを受けるためのExpressRoute virtual network gatewayを計画

4ステージのプロビジョニングフロー

Microsoft Learnによれば、AMI Previewの構築は以下4ステージで進みます。

1. ExpressRoute circuit作成
   ExpressRoute circuitを作成し、ポートタイプとして「Azure Multicloud Interconnect」を選択。従来のExpressRoute用ポートタイプではなく、AMI用の専用タイプを指定するのがポイント
   
   

2. Azure Multicloud Interconnectリソース作成
   上記circuitに紐付けて、AMIリソース本体をAzure Portalから作成。この時点でAzure側の準備は完了
   
   

3. Provider setup（activation key交換）
   Azure側でactivation keyを生成してAWS側でredeemするか、逆にAWS側で生成したkeyをAzure側でredeemする。両側のCSP・リージョン・帯域・アカウントが一致すれば自動プロビジョニング開始
   
   

4. Connected workloads（VNet接続）
   プロビジョニング完了後、Azure VNetをExpressRoute gateway経由でAMIに接続し、AWS VPC側も同様に接続。両クラウド間でトラフィックが流れる状態にする

Microsoft LearnのFAQによれば、activation validationに失敗した場合はプロビジョニングそのものが始まらず、不一致項目を修正してから再開始する設計です。

「途中で止まる」ではなく「開始条件を満たすまで待たされる」タイプのバリデーションになっています。

開始時に押さえておく実務ポイント

Preview利用開始時に見落としやすい実務ポイントを3つ挙げておきます。

• ExpressRoute gatewayのSKU選定
  AMI経由のトラフィックはExpressRoute gatewayを通るため、想定帯域に合ったSKUを事前選定する必要がある。Preview 1 Gbpsに対してgateway SKUがボトルネックにならない構成を選ぶ
  
  

• Azure Portal・CLI・PowerShell経由での操作可否
  現時点でMicrosoft Learnに公開されている手順は主にAzure Portal経由。CLI・IaC対応の公式ドキュメントが順次公開される見込みだが、Preview中はまずPortal手順で流すのが確実
  
  

• 障害検証はPreview範囲内で完結させる
  Preview中はSLAがなく、Azure側・AWS側どちらの障害でも復旧時間の保証はない。基幹系ワークロードでの本番切替は行わず、検証用ワークロードで実施する

---

Azure Multicloud Interconnectの導入判断で押さえる論点

AMIは魅力的な新サービスですが、Preview段階の制限を踏まえるとすべての企業が今すぐ本番採用すべきわけではありません。ここでは、AI総研の導入支援経験を踏まえたケース別の判断軸を整理します。

日本リージョン未対応の影響を先に整理する

AMI Previewは日本リージョンを対象としていませex
ん。国内ワークロードでAWS↔Azureを結ぶ場合、Preview中の選択肢は以下の3パターンに絞られます。

• Asia Pacific（Sydney）経由で検証環境を構築
  日本国内ワークロードから物理的に距離があるものの、Preview触感の確認・APIやコンソール操作の検証には使える
  
  

• 既存Megaport／Equinix Fabric経由を継続
  Japan Eastで本番運用中の企業は、日本リージョン対応GAを待つほうが手戻りが少ない
  
  

• GAと日本リージョン対応を待つ
  本番切替を前提とする場合、両方の節目を待って料金・SLA・リージョンの3条件が揃ってから判断

特に金融・製造・公共などデータ主権や国内転送要件が強い業種は、日本リージョン対応前にAMIを本番系に組み込むのは現実的でありません。国内ワークロードは既存経路を維持し、非国内系の海外拠点連携から検証を始めるのが順序として無理がありません。

Preview段階で先行検証するメリットがあるケース

一方、以下のような条件に当てはまる企業は、Preview段階で先行検証する価値があります。

• AMI対応4リージョンに既存ワークロードがある
  US East・US West・Germany West Central・Australia Eastのいずれかで既にマルチクラウド運用している企業は、Preview 1 Gbpsでも十分に触感が掴める
  
  

• 既存Megaport／Equinix Fabric契約の見直しを予定している
  契約更新のタイミングに合わせてAMI GA時の候補として比較検討する準備を始められる
  
  

• ハイブリッドAI・大規模データレプリケーションを企画中
  両クラウドを跨ぐAmazon BedrockやAzure OpenAIワークロード、S3↔Azure Blobレプリケーション等の検証環境を非本番系で先に組む
  
  

• 社内ネットワークチームのマルチクラウド運用経験を蓄積したい
  BGP自動管理・activation key設計・両CSP協調の障害切り分けなど、AMI固有の運用スキル獲得を先取りできる

GA前の本番採用を控えるべきケース

逆に、Preview段階での本番採用は控えるべきケースも明確です。

• SLAが必須の基幹系ワークロード
  Preview中はSLAが提供されず、両CSPからの復旧保証もない。決済系・受発注系・医療系など可用性要件が厳しい用途は不可
  
  

• 冗長構成が必要な用途
  Preview中はカスタマー×リージョンあたり1本のみで、独立した2本目のAMIを追加できない。1本のAMI自体は四重冗長構成だが、独立系統での二重化が必要な場合はGA後の複数本対応を待つ
  
  

• 日本リージョン内で完結させる必要がある要件
  データ主権・法令要件で国内リージョン限定運用が必要な場合、AMIは選択肢に入らない

実務的には、Preview期間中はAMI対応リージョンで非本番系ワークロードを対象に「触感の獲得」と「GA後の判断材料集め」に用途を絞るのが現実解です。GAと日本リージョン対応・複数本冗長・SLA提供が揃った段階で、本番系での切替を再検討する2段階アプローチが安全です。

既存Megaport／Equinix Fabric契約をどう扱うか

現在Megaport／Equinix Fabric経由でAWS↔Azureを結んでいる企業にとって、AMI GA後の判断はゼロサムではありません。AMI対応リージョンかつ1対1接続に該当する部分はAMIに寄せ、複数拠点集約や日本国内起点の接続は既存パートナー経由を維持する併存構成が、当面の現実解になる見通しです。

パートナー経由の集約管理・複数CSP同時接続・国内PoP対応といった強みは短期間で失われるものではないため、契約更新時に両方の見積を並べて用途別に配分する運用設計が有効です。

---

AWSとAzureをつないだあと、業務のAIエージェントをどこで動かすか

AMIは物理接続やBGP、冗長化を両CSP側に寄せましたが、アクセスポリシーやアプリケーションといった上位レイヤーは、引き続き自社が管理する範囲です。Preview中にAmazon BedrockとAzure OpenAIをまたぐハイブリッドAIを検証するなら、AIエージェントをどちらのクラウドで動かし、誰がどのデータを使えるようにするかも、接続の検証と並行して決めておく必要があります。

その置き場所として考えられるのが、業務エージェントの実行と管理をAzure側の自社テナントにまとめる構成です。AI総合研究所のAI Agent Hubは、この構成をAzure Managed Applicationsとして構築し、社員がTeamsから呼び出す業務エージェントを1つのダッシュボードで管理します。

• AWS側のBedrockやS3も前提に設計
  AWSで検証中のBedrockや、S3に置いたデータを使う業務も、要件に応じて接続の設計から構築まで支援します。
  
  
• データに触れる人をAgent単位で決める
  どのAgentを誰が使えるかをアクセス権限で設定できるため、両クラウドのデータにAgent経由で触れられる人を、業務ごとに限定できます。
  
  
• データ主権の要件がある業種でも
  業務データもAgentの実行記録も自社の管理下に残るため、金融や公共のように外部のSaaSへデータを預けられない業務にも使えます。

AI総合研究所の専任チームが、AMIのGAを待つあいだに、両クラウドのどのデータをどの業務のAgentで使うかを決めるところから伴走します。

---

まとめ

本記事では、Azure Multicloud Interconnect（AMI）を「AzureとAWSを共同マネージドの単一リソースで直結する接続サービス」として整理し、仕組み・Preview時点の制限・既存の接続方式との使い分け・料金・開始手順・導入判断の論点を解説しました。

2026年9月時点で押さえておくべきポイントは次の3つです。

• 実務で大きく変わるのは第三者接続事業者との調整が減ることで、AWSとAzureの接続を両CSPとの契約だけで組めるようになった
• Megaport／Equinix Fabric経由は地域カバーと集約でまだ優位なため、対応リージョンの1対1接続からAMIに寄せる併存構成が当面の基本になる
• Preview中はSLAがなく、日本リージョンも対象外のため、本番基幹系への採用はGAとリージョン拡張を待って判断するのが安全
  
  

Preview段階での向き合い方として、AI総合研究所が導入支援の現場で勧めているのは、検証と本番採用を2段階に分ける進め方です。

まずは接続料金がかからないPreview期間のうちに、AMI対応リージョンの非本番系ワークロードで接続を組み、activation keyの交換やBGP自動管理の挙動を確かめます。
続いて、GAで料金・SLA・対応リージョンが公表されたら、既存のMegaport／Equinix Fabric契約の更新時期に合わせて両方の見積を並べ、本番系の載せ先を用途別に決めるのが、手戻りの少ない順序です。

AMIの登場が示しているのは、クラウド間接続そのものがCSP共通の仕様に乗り始めたという変化です。

AWSとAzureを併用する企業にとってAMIは、GA後の接続方式を見直すときに外せない比較候補です。