MicrosoftとAmazon Web Services（AWS）は2026年8月31日、AzureとAWSを両社管理のプライベート回線で結ぶサービスをパブリックプレビューとして公開した。Azure Multicloud InterconnectとAWS Interconnect – multicloudを組み合わせ、物理回線の準備からルーター、BGP、暗号化までを両クラウドが協調して設定する。発表では最大100Gbpsや99.99%の可用性が目を引くが、現時点で選べる帯域は1Gbps、対応は4地域、正式なサービスレベル契約（SLA）もない。今回先に動いたのは、クラウド間接続を調達案件からクラウド資源へ変える運用モデルである。

AD

回線工事からクラウド資源へ

Azure側から始める場合、利用者はExpressRoute回線を作り、接続先とリージョンを選んで帯域とAWSアカウントIDを指定する。そこで発行されるactivation key（両クラウドの接続要求を照合する認証キー）をAWS側で引き換えると、両社は事業者と地域を確かめ、帯域と顧客アカウントが一致するかを確認して、事前構築済みの設備から容量を割り当てる。AWS側から認証キーを発行し、Azureで受け入れる逆向きの手順も使える。

認証キーは通信を暗号化する鍵ではない。相手側の接続要求が同じ顧客と構成を指していると確認し、両クラウドの作成処理を開始するための仕組みだ。公開されているConnection Coordinator API Specification（接続調整API。クラウド間接続の作成と状態同期を調整する公開仕様）には、接続の作成から状態通知、保守予定、暗号鍵の更新、障害票までを扱うAPIが定義されている。両社の管理画面が別々でも、裏側のライフサイクルを共通の語彙で同期できる。

顧客の作業が消えるわけではない。AzureではExpressRouteの仮想ネットワークゲートウェイを介してVNetへ接続し、AWSではDirect Connect Gatewayを接続点としてVirtual Private Gateway、Transit Gateway、AWS Cloud WANのいずれかへ結ぶ。両クラウドで重複しないIPアドレス空間を用意し、どのプレフィックスを相互接続へ流すかも決める必要がある。省かれるのは、第三者回線とコロケーションの手配、顧客管理ルーターの用意である。VLANやポイント間アドレス、BGPセッションの設定も両社が引き受ける。

現行プレビューは1GbpsでSLAもない

共同発表と製品文書には、現在使える仕様と一般提供時の構想が混在している。Microsoft Learnのプレビュー制限を基準に分けると、差は次のようになる。

項目 現行パブリックプレビュー 一般提供時の構想
帯域 1Gbps 最大100Gbps
対応地域 Azure側4地域、AWS側4地域の組み合わせ 拡大方針はあるが地域一覧は未公表
可用性 Azure Multicloud InterconnectのSLAなし 99.99%を目標、正式SLAは未公表
Azure側料金 サービス料とAzure側データ送信料なし 未公表
提供時期 2026年8月31日からプレビュー 未公表

現行プレビューの帯域上限は1Gbpsで、一般提供時に掲げる最大100Gbpsの100分の1である。プレビューにはSLAがなく、99.99%は正式保証ではなく目標値である。これは選択可能な回線容量の差であり、実効転送速度やアプリケーション性能が100倍になるという比較ではない。

北米の組み合わせは、AWSの米国東部（バージニア北部）とAzureのEast US、AWSの米国西部（北カリフォルニア）とAzureのWest USである。ほかにシドニーとAustralia East、フランクフルトとGermany West Centralが対応する。Azureはプレビュー中のサービス料とAzure側データ送信料を免除する。一方、AWSの一般料金表は帯域と距離に応じた時間課金を採用し、相手クラウド側の請求は別契約としている。Azure連携プレビューに固有のAWS側免除は共同発表に書かれていないため、クラウド間経路全体を無料とは呼べない。

AD

リンク層暗号化と4重冗長の守備範囲

1つの論理Interconnectの下には、少なくとも2つの物理施設に分散した4つの論理経路が置かれる。Equal-Cost Multi-Path（ECMP）で負荷を分け、AWSは1拠点を失っても残る拠点で通信を継続できると説明する。利用者からは1つの接続資源に見えるが、設備と経路は4重化されている。

暗号化にはMACsec（IEEE 802.1AEのリンク層暗号化）を使う。AWS文書が保証する範囲は、AWSのエッジルーターと隣接する相手クラウドのルーターを結ぶ物理リンクであり、暗号化セッションが有効な時だけ顧客トラフィックを流す。公衆インターネットを通らない専用経路と合わせてクラウド境界を保護するが、アプリケーションからアプリケーションまでを一つの暗号化セッションで包む仕組みではない。利用者はTLSなど上位層の保護と、各クラウド内のアクセス制御を別に設計する。

監視にも境界がある。各InterconnectにはCloudWatch Network Synthetic Monitorが1つ追加料金なしで付き、往復遅延とパケット損失を測定し、しきい値アラームを設定できる。ただしAWSの現行文書は、障害がAWS網内にある可能性を示すNetwork Health Indicatorについて、Interconnectでは未対応としている。共同発表の「問題がどちら側にあるかを切り分ける」という説明を、現時点で自動判定まで実装済みだと読むのは早い。

2024年の発言が示す「可能」と「便利」の差

この製品化には、両社のマルチクラウド観が変わったように見える面がある。AWSは2024年7月、英国のCompetition and Markets Authority（CMA）に対し、顧客はマルチクラウドを実行でき、望む時にクラウド事業者を切り替えられると主張した。技術的障壁が競争を損なうという見方にも反論していた。

Microsoftは同じ調査で、統合マルチクラウドへの顧客関心は専門的な場面を除けば多くなく、容易でも便利でもないと説明している。今回、AWSは従来のAzure接続を「扱いにくかった」と認め、Microsoftも回線や設定の調整に数週から数カ月かかり得るとした。2024年の発言を全面撤回したというより、「技術的には可能」と「継続運用しやすい」の間に残っていた費用と手間を、両社が製品機会として扱い始めたのである。

AWSは2025年のre:InventでGoogle Cloudとの接続からこの仕組みを始め、現在はGoogle Cloud、Oracle Cloud Infrastructure、Azureという主要3クラウドを同じ運用モデルへ載せた。公開APIが揃えるのは、マネージド型レイヤー3接続の作成と状態同期から、保守、暗号鍵更新までのネットワーク下層だ。アプリケーションAPIとIDの互換性は含まれない。データ形式、データベース、ライセンスも各クラウドで別に扱う。

AD

回線がつながってもワークロードは自動で動かない

AzureとAWSの直結は、買収で異なるクラウド資産を抱えた企業、複数クラウドへ展開するソフトウェア事業者、データとAI計算資源が別環境にある組織に効く。ネットワーク担当者は物理設備の調達と保守から離れ、クラウド上の接続資源として扱える。帯域の増減は将来構想であり、1Gbpsのみの現行プレビューでは選べない。障害時の責任分界も、顧客、通信事業者、コロケーション施設、2つのクラウドを順番に回る従来構成より狭めやすい。

それでも、クラウド固有サービスへ深く組み込んだアプリケーションは回線一本で移せない。大量データを動かす時間と費用を見積もり、アドレスと経路、名前解決、ID連携を設計する。データベース複製とライセンス条件も別に詰める必要がある。プライベート経路は、データ所在地や法令順守を自動的に保証するものではない。

この接続がクラウド間競争を本当に広げるかは、一般提供の時期と100Gbpsを選べる地域で判断できる。さらに正式SLA、両クラウドを合わせた料金、実利用企業の増加も確かめたい。1Gbps・SLAなしのプレビューから、その条件がそろった時、マルチクラウドは専門家が個別に組むネットワークから、必要な期間だけ調達できる標準的な選択肢へ近づく。