BLOG

結論

AWS は2026年8月31日、Microsoft Azure との直接接続を「AWS Interconnect - multicloud」のプレビューとして発表しました。同じ発表文のなかで、Oracle Cloud Infrastructure と Google Cloud への接続は一般提供と書かれています。Azure だけが、まだプレビューです。

使えるリージョンは4つ。米国東部（バージニア北部）、米国西部（北カリフォルニア）、アジアパシフィック（シドニー）、欧州（フランクフルト）です。東京も大阪も入っていません。

ニュースの見出しに乗ったのは、別の数字でした。「最大100Gbps」です。ただしこれを書いた Microsoft のブログの原文は「一般提供の初日から最大100Gbps」で、一般提供に移ってからの数字として書かれています。いまのプレビューで選べる帯域は、Microsoft の公式ドキュメントによれば1Gbpsの一択です。止まらないことをどこまで約束するかの取り決め、つまり SLA も、プレビュー中は付きません。

この発表でインフラ運用の担当者に回ってくるのは、100Gbpsを前提に構成図を描き直す仕事ではないと筆者は考えます。この直接接続がいまどの提供段階にあり、どのリージョンで引けて、料金とSLAがどう決まっているのかを確かめ、確認した日付と一緒に1枚に書き出す仕事です。構成図はもう描けます。手順書はまだ書けません。

根拠

1. 対象は4リージョンで、日本は入っていません

先に挙げた4つが、AWS の発表文に書かれているプレビュー対象のリージョンです。Azure 側は Australia East、East US、Germany West Central、West US の4つで、公式ドキュメントは「プレビュー中はリージョンの提供状況が変わりうる」と断っています。接続の作成は、マネジメントコンソールでも CLI でも API でもできます。

日本の案件で効くのはここです。東京リージョンに本番環境を置いている客先で「AWSとAzureが直接つながるらしい」という話が出ても、いまその構成は組めません。検証環境をシドニーかバージニア北部に建てて試すなら、測った遅延は本番の数字になりません。

では、どれくらい待つことになるのか。AWS がこのサービスを一般提供にしたのは2026年4月14日で、そのときの対象は5リージョン、接続先は Google Cloud の1社だけでした。約4か月半で、接続先は3社に増えています。ただし地域の拡大について、公開された予定表はありません。

2. いま選べる帯域は1Gbpsの一択で、SLAはありません

Microsoft の公式ドキュメントは、プレビュー中の条件を3つ書いています。帯域は1Gbpsのみ。SLAはなし。そしてプレビューの間は、Azure 側ではこの接続の料金も、外へ出ていく通信の料金も発生しません。

3つはいずれも、一般提供に移るときに変わりえます。無料なのは期間限定の扱いで、料金表ではありません。SLAがないということは、止まったときに客先へ示せる約束が、こちらの手元にないという意味です。

客先に出す資料の帯域欄に「最大100Gbps」と書く前に、申し込み画面の選択肢を自分の目で見る。

3. 構成図から消えた作業は、手順書では消えません

Azure 側に作るものは、公式ドキュメントによれば3つです。マルチクラウド用のポート種別を選んだ ExpressRoute の回路、Azure Multicloud Interconnect のリソース、そして Azure へ入ってくる通信を受ける ExpressRoute の仮想ネットワークゲートウェイ。

AWS 側については、ネットワークエンジニアの Simon Painter 氏が2026年9月19日に公開した実機の記録があります。仮想プライベートゲートウェイを付けた VPC を用意し、Direct Connect のゲートウェイを作り、Azure 側で発行された鍵を受け入れる。そのうえでゲートウェイを関連付けるときに許可するアドレス範囲を指定し、最後にルートテーブルで経路の伝播を有効にする、という流れです。

この一覧を見渡すと、何が減って何が残ったかがはっきりします。これまで2つのクラウドを閉域でつなぐには、データセンターでの回線手配から始まりました。その手配が消えました。残ったのは、どの経路をどちらへ流すかを決める作業です。許可するアドレス範囲に何を書き、どのルートテーブルで伝播を有効にするか。人が決めます。

同じ記録によれば、自分の側に BGP の設定はありません。BGP は、ネットワークどうしが「この宛先はこちらへ」という経路情報を交換する手順のことです。経路に見えるのは Microsoft 側と AWS 側の AS 番号だけで、調整のつまみは渡されていません。設定を間違える可能性が減るのは利点です。そのかわり、つながらないときに自分で動かせるものも減ります。

4. 無料の枠には条件が付いています

AWS は2026年5月29日から、500Mbpsのインターコネクトを無料で提供しています。条件は、1顧客あたり1本、AWSリージョンごと、接続先クラウドごと。しかも対象はローカル（Tier 1）の範囲に限られ、AWSとの接続が一般提供になっている相手だけです。Azure はいまプレビューなので、この枠では引けません。

料金の形も押さえておくとよいでしょう。公式ドキュメントは、選んだ帯域と、接続先クラウドへの地理的な範囲という2つの入力で決まる単一料金と説明しています。請求は1時間単位で、流した通信量に対する課金はありません。つまり、使わない時間も帯域ぶんは払います。

5. プレビューのうちは、見積りに書ける数字がありません

ここまでの条件を並べ直すと、料金・SLA・帯域・リージョンの4つが、いずれも「プレビュー中は」という留保つきです。Microsoft のブログが100Gbpsを「一般提供の初日から」と書いたのは、この機能の数字が段階によって変わることを、提供する側が最初から示していたということでもあります。

実務でやることは決まっています。客先に出す資料には、確認した日付と、見た公式ドキュメントの名前を添える。提供段階が動いている機能では、これを書かないと資料の寿命が数週間で切れます。

行動提案

6. 触っていない側のクラウドについて、3つを言えるようにする

ここまでは、いま出ている機能そのものを確かめる話でした。もう1つ、別の軸の準備があります。マルチクラウドの運用に入るために、両方のクラウドを同じ深さで触った経験が要るわけではありません。要るのは、自分が触っていない側について次の3つを言えることです。

• 相手側の閉域接続サービスは何という名前で、課金はどの単位で決まるのか
• 相手側から来る経路情報はどこで受け取り、そこで何を許可するのか
• 障害のとき最初に見る画面はどれで、その画面を見る権限は誰が持っているのか

抜けやすいのは3つめです。両方のクラウドの権限を1人が持っている現場は、あまりありません。

7. 面談では、つなぎ方と権限の2つを聞く

マルチクラウド構成の案件として話が来たら、面談で2つ聞くと仕事の実体が見えます。1つめは「両方のクラウドの間は、いま何でつながっていますか」です。インターネット経由の VPN か、通信事業者の回線を挟んだ閉域か、クラウド同士の直接接続か。答えによって、自分が触る範囲は大きく変わります。

2つめは「権限は両方ありますか」です。片方しか渡されない現場では、切り分けが相手チームとの往復になります。これは技術ではなく体制の話で、入ってからでは変えられません。面談でなら聞けます。

クラウド同士の直接接続が減らしたのは、回線を手配する仕事でした。減らなかったのは、どの経路を流し、誰が権限を持ち、どの数字を客先に約束するかを決める仕事です。この3つは、まだ現場で決めることになります。