AWSとAzureをプライベートに結ぶマネージド相互接続サービスが登場し、これまで数週間から数ヶ月を要していたクラウド間接続の構築が、数クリックで完了する時代へと動き出しました。本記事では発表された事実を丁寧に整理したうえで、従来のDirect ConnectやExpressRouteを手組みする方式との違い、マルチクラウドで見落としやすいリスク、そして実務でのネットワーク設計とコスト最適化の勘所を、インフラエンジニアやクラウドアーキテクトの目線で解説します。

AWSとAzureのマネージド相互接続で何が変わったのか

2026年8月31日、AWSは「AWS Interconnect – multicloud」にMicrosoft Azure対応を追加し、パブリックプレビューとして提供を開始しました。あわせてMicrosoftも「Azure Multicloud Interconnect for AWS」を提供開始しており、両社の共同発表という位置づけです。AWS Interconnect – multicloud自体は2025年11月に初めてプレビュー発表されたもので、今回そのラインナップにAzureが加わった形になります。

ここで最も注意したいのが、対応クラウドごとに提供ステータスが異なる点です。Google Cloudは一般提供（GA）、Oracle Cloudも一般提供（GA）に到達しているのに対し、今回追加されたMicrosoft Azureはパブリックプレビュー段階にあります。一部の報道では3クラウドを一律にサポートと要約されていますが、GAとプレビューの差は本番採用の判断に直結するため、混同しないことが大切です。

また、Azure連携のプレビュー提供リージョンはUS East（N. Virginia）、US West（N. California）、Asia Pacific（Sydney）、Europe（Frankfurt）の4つに限られます。東京リージョン（ap-northeast-1）は現時点で対象外であり、日本国内で完結する低レイテンシ要件をお持ちの場合は、この点をあらかじめ踏まえておく必要があります。なお日本対応の時期については未発表のため、本記事では予測は述べません。

技術面での変化は明快です。従来は数週間から数ヶ月かかっていた物理接続やルーティング設定が、両クラウドのポータルやAPIから単一の論理リソースを作成するだけで済むようになりました。顧客が自らルーターを持ち込んでラッキングやパッチ適用を行う必要がなくなり、プロビジョニング、冗長性、暗号化、ライフサイクルを両クラウドが協調して管理します。

Direct ConnectやExpressRoute手組みとの違い

これまでAWSとAzureをプライベート接続するには、AWS側でDirect Connectを用意し、Azure側でExpressRouteを敷設したうえで、両者をコロケーションやNaaSなどの相互接続事業者で結線するのが一般的でした。さらにBGPによるルーティング、監視、ライフサイクル管理を複数ベンダーにまたがって個別に調整する必要があり、実装に数週間から数ヶ月かかることも珍しくありませんでした。

新方式では、この複雑さが単一の論理リソースへと集約されます。冗長性の面ではquad-redundant設計が標準で組み込まれ、物理的に分離された施設とルーターにまたがって接続ごとに4本の独立した論理パスが確保されます。単一ルーターのメンテナンスや同時発生する独立障害、さらにはサイト全損の際にもサービス継続を企図した構成です。暗号化についてもMACsecがリンク層で自動的に有効化され、クラウド間のエッジルーター間トラフィックが保護されます。

ここで誤解を避けたいのは、本サービスはDirect ConnectやExpressRouteを置き換えるものではないという点です。むしろこれらの実績ある基盤の上に構築された、クラウド⇔クラウドのマネージド接続レイヤーと理解するのが正確です。オンプレミス⇔クラウドの接続は引き続きDirect ConnectやExpressRouteが担い、今回のサービスはAWS⇔Azureというクラウド間接続を簡素化する役割を受け持ちます。加えてAWSはネットワーク相互運用のためのオープンAPI仕様をGitHubで公開しており、要件を満たせば他のプロバイダーも参加できる枠組みとなっています。

マルチクラウド接続の技術的メリットと見落としやすいリスク

メリットは大きく分けて4点あります。第一に、公衆インターネットを経由しないプライベート閉域接続により、低レイテンシと高帯域を専用線として確保できます。第二に、quad-redundant設計と4本の独立論理パスによる高い冗長性があり、Microsoft側は99.99%の可用性SLAを目標として掲げています。第三に、MACsecによるリンク層暗号化が標準かつ自動で適用される点です。第四に、数週間から数分へという運用の劇的な簡素化が挙げられます。

想定されるユースケースとしては、クラウド間のデータ移行、AWS側に蓄積したデータをAzureのAIや分析サービスで処理する分散アプリケーション、災害対策や冗長構成、そしてクラウド間の段階的移行などが考えられます。

一方でリスクも冷静に見ておく必要があります。Azure連携はパブリックプレビューであり、機能や性能目標、タイムラインがGAに向けて変わりうる点は公式にも明記されています。前述のとおり日本リージョンは対象外です。さらに、今回のサービス自体の料金は一次情報でも報道でも開示されておらず、コスト面の不確実性が残ります。

とりわけ見落としやすいのが、クラウド間のアウトバウンドデータ転送課金です。接続がプライベート化されても、クラウド間を流れるデータ転送費用は各社の料金体系に従って発生しうると考えるのが自然で、今回の発表でエグレス無料化への言及は確認できていません。これはマルチクラウドの隠れコストとして最重要のウォッチ項目です。なお帯域について報道では最大100Gbps級とされていますが、確認できたMicrosoftの技術ブログ本文では100Gbpsという明示はなく、400G-classのLAGベース設計と表現されています。実効スループットは構成やLAG本数に依存するため、報道ベースの数値を鵜呑みにしない姿勢が求められます。

実務で押さえるネットワーク設計とセキュリティ運用の観点

ネットワーク設計では、まず役割分担を明確にすることが出発点になります。オンプレミス⇔クラウドは従来のDirect ConnectやExpressRoute、クラウド⇔クラウドは本サービスと切り分けたうえで、Transit GatewayやVirtual WANとの接続点を含む全体トポロジを先に描いておくと、後工程の手戻りを減らせます。

あわせてIPアドレス設計と重複回避、BGPルーティングやルート集約の方針を固めます。ワークロードの配置は対応する4リージョンに合わせて検討し、日本要件については既存のDirect ConnectとExpressRouteをNaaSで結ぶ従来構成を代替として比較しておくと安心です。組み込みのquad-redundantに任せる部分と、アプリケーション層やマルチリージョンで担保すべき部分の切り分けも整理しておきましょう。

セキュリティ面では、MACsecの自動暗号化があるとはいえ、それだけに依存しないことが肝心です。TLSなどトランスポート層やアプリケーション層の暗号化、認証認可を別途設計する多層防御の発想が欠かせません。加えて、越境するデータの分類とデータ主権への配慮、どのリージョンを経由するかの把握、両クラウドにまたがる管理権限の分界と変更管理も重要な論点になります。

運用体制については、AWSとAzure双方のネットワークスキルを備えたチームづくりが前提となります。両クラウドが協調管理するとはいえ、障害時の責任分界点と切り分けフローは事前に定義しておくべきです。プレビューからGAへの仕様変更に追随する変更管理プロセス、そしてFinOpsの観点でのコスト継続モニタリングも運用に組み込みたいところです。フローログや経路監視を両クラウド横断で一元化し、可観測性を確保しておくと、初動対応の速度が変わります。

料金と帯域の目安と本番採用の判断ポイント

まず前提として、今回のInterconnectサービス自体の料金は一次情報でも報道でも非開示であり、現時点では未確認です。帯域の最大100Gbps級という数値も報道ベースであり、一次のMicrosoft技術ブログは400G-classのLAG設計と表現している点を踏まえ、断定は避けるのが妥当です。以下に示す既存サービスの数値は、あくまでコスト感覚をつかむための目安であり、いずれもAWSやMicrosoftの公式料金ページでの再確認を推奨します。

参考として、AWS Direct Connectの専用接続は1Gbps、10Gbps、100Gbps、400Gbpsといった帯域ラインナップを備え、Hosted接続では50Mbpsから選べます。第三者集計による米国リージョンの目安では、専用ポート料金は10Gbpsでおおむね月1,600ドル前後、100Gbpsクラスでは月1万6,000ドル台という水準が示されていますが、これは概算であり要検証です。データ転送アウトは概算で1GBあたり0.02ドル程度とされ、通常のインターネットエグレスより割安になる傾向があります。Azure ExpressRoute側は50Mbpsから100Gbpsまでの帯域オプションを持ち、データ課金は従量固定型と、インバウンド無料でアウトバウンド従量となる従量課金型を選べる形が一般的です。こちらも要検証の目安としてお考えください。

総コストは、ポートや接続の料金にデータ転送アウトを加え、コロケーションを利用する場合はクロスコネクトや回線費用が上乗せされる構造になります。マルチクラウドでは双方向のエグレス課金が試算全体を支配しやすく、月間のデータ転送量が増えるほどこの影響が効いてきます。したがって、帯域スペックだけでなくデータ転送量の見積もりを起点にコストを組み立てることが重要です。

本番採用の判断としては、プレビュー期間中は料金が未開示であることを踏まえ、GAでの料金確定を待って本番コスト計画を固めるのが安全な選択です。Ragateは、マルチクラウド接続の全体設計、エグレスを含むコスト試算、そしてMACsecと多層防御を組み合わせたセキュリティ設計まで、移行と併存フェーズのネットワーク論点を伴走支援できます。マルチクラウドの構想段階から、ぜひお気軽にご相談ください。