![[プレビュー] AWS Interconnect - multicloud で AWS と Microsoft Azure のネットワークを接続してみる](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-a25fe53c4e0e62cddd4b3619d3e7b27d/ca05eb372480507504b0ea6d9d0bfbe9/aws-direct-connect?w=3840&fm=webp)
[プレビュー] AWS Interconnect - multicloud で AWS と Microsoft Azure のネットワークを接続してみる
ウィスキー、シガー、パイプをこよなく愛する大栗です。
2026 年 8 月 31 日に AWS Interconnect - multicloud の Microsoft Azure 対応がパブリックプレビューとして発表されました！ AWS re:Invent 2025 での発表時から「2026 年に Azure にも対応予定」と予告されていたものが、ついに使えるようになりました。Azure 側は Azure Multicloud Interconnect という新しいサービスとして提供されます。本エントリでは AWS と Azure のネットワークを実際に接続してみます。
- AWS announces AWS Interconnect - multicloud connectivity with Microsoft Azure in preview
- AWS and Microsoft Azure collaborate to expand multicloud networking | Networking & Content Delivery
- Introducing Azure Multicloud Interconnect for AWS | Microsoft Azure Blog
- Simpler, private connectivity between Azure and AWS with Azure Multicloud Interconnect | Microsoft Community Hub
- Getting started with AWS Interconnect - multicloud - AWS Interconnect
- What is Azure Multicloud Interconnect Preview? | Microsoft Learn
AWS Interconnect - multicloud の Microsoft Azure サポート
AWS Interconnect - multicloud は、Amazon VPC と他のクラウドサービスプロバイダーのネットワークをプライベートな高速接続で直結するサービスです。AWS 側は Direct Connect Gateway 経由で接続し、作成と承認の 2 ステップだけで、物理接続やルーター、BGP を一切意識せずに接続を確立できます。物理インフラは AWS と相手 CSP が事前にプロビジョニングしており、2 箇所以上の物理施設と 4 台のルーターに分散した 4 重冗長で、ルーター間は MACsec で暗号化されています。
サービスの全体像や Google Cloud との接続手順は、以下の過去エントリにまとめていますのであわせてご覧ください。
今回の Azure 対応により、AWS Interconnect - multicloud は主要な 3 CSP に対応したことになります。
| CSP | ステータス（2026 年 9 月 5 日時点） | 備考 |
|---|---|---|
| Google Cloud | GA | 2025 年 11 月 30 日にプレビュー、2026 年 4 月 14 日に GA。Google Cloud 側は Partner Cross-Cloud Interconnect for AWS |
| Oracle Cloud Infrastructure（OCI） | GA | 2026 年 5 月 15 日にプレビュー、2026 年 7 月 29 日に GA。OCI 側は Oracle Interconnect for AWS |
| Microsoft Azure | パブリックプレビュー | 2026 年 8 月 31 日にプレビュー。Azure 側は Azure Multicloud Interconnect |
Azure Multicloud Interconnect とは
Azure Multicloud Interconnect は、AWS Interconnect - multicloud の Azure 側に相当する新しいサービスで、Azure と対応 CSP（プレビュー時点では AWS のみ）の間にプロバイダー管理のプライベート接続を提供します。基盤技術は Azure ExpressRoute で、ExpressRoute circuit を作成する際にポートタイプとして Azure Multicloud Interconnect を選択します。ユーザーが管理するのは従来の ExpressRoute circuit ではなく、Azure Multicloud Interconnect リソースになります。Azure 側では 4 台の Azure Microsoft Enterprise Edge（MSEE）ルーター、AWS 側では 4 台のルーターで 4 重冗長を構成し、リンク層は MACsec で暗号化されています。
(https://learn.microsoft.com/en-gb/azure/multicloud-interconnect/overview)
従来 AWS と Azure をプライベート接続する場合は、ExpressRoute と Direct Connect をコロケーションや接続プロバイダー経由で自前でつなぎ込む必要がありました。今回のサービスでは、ExpressRoute circuit の作成、Interconnect リソース、プロバイダーセットアップ、ワークロード接続の4段階で設定できます。
Azure 側のブログでは、GA 時点で最大 100 Gbps の帯域幅を提供し、需要に応じて動的に容量を拡張できるとしています。また設計目標として IPv6 対応、APIPA アドレッシング対応、99.99 % の可用性 SLA が挙げられています。プレビュー中は後述のとおり 1 Gbps のみで SLA もありませんが、GA 時の姿がある程度見えているのは嬉しいポイントです。
対応リージョン
パブリックプレビュー時点で対応しているリージョンペアは以下の 4 組です。
| AWS リージョン | Azure リージョン |
|---|---|
| us-east-1 米国東部（バージニア北部） | East US（eastus） |
| us-west-1 米国西部（北カリフォルニア） | West US（westus） |
| eu-central-1 欧州（フランクフルト） | Germany West Central（germanywestcentral） |
| ap-southeast-2 アジアパシフィック（シドニー） | Australia East（australiaeast） |
Interconnect は選択した AWS リージョンにローカルなものとして作成されます。仮想プライベートゲートウェイや Transit Gateway はローカルリージョンの Interconnect にしか到達できないため、他リージョンの VPC から利用したい場合は Cloud WAN と組み合わせる構成になります。残念ながら日本リージョン（東京・大阪）と Japan East / Japan West の組み合わせはまだ対応していません。
プレビュー中の制限
AWS 側と Azure 側のドキュメントに記載されているプレビュー中の制限をまとめます。
| 項目 | AWS 側 | Azure 側 |
|---|---|---|
| 帯域幅 | 1 Gbps のみ | 1 Gbps のみ |
| 作成できる本数 | 1 顧客あたり対応リージョンごとに 1 本 | 記載なし |
| 料金 | プレビュー期間中は無料 | サービス料金・Azure 送信（egress）料金とも無料。ただし ExpressRoute Gateway に料金がかかります。 |
| SLA | プレビューのため対象外 | なし |
| GA 前の扱い | GA に近づくとプレビューの 1 Gbps 接続はアカウントから削除され、その間は新規作成不可 | プレビュー規約に準拠 |
| ピアリング | 該当なし | プライベート接続のみ（Microsoft peering は対象外） |
| 接続先 CSP | Azure（Google Cloud と OCI は GA 済み） | AWS のみ |
なお料金が無料なのは Interconnect 本体だけで、Azure 側の ExpressRoute 仮想ネットワークゲートウェイや、検証に使う仮想マシン、EC2 インスタンスなどの料金は通常どおり発生します。GA 後の AWS 側の料金体系については、GA 時の情報をご確認ください。
やってみる
それでは実際に接続してみます。AWS Interconnect - multicloud は AWS と Azure のどちらからでも接続を開始できる Create / Accept フローです。今回は Azure 側で Interconnect の回線を作成してアクティベーションキーを生成し、AWS 側でそのキーを使って承認する流れで進めます。
ここではシンプルな構成にするため、AWS と Azure でそれぞれ VPC / 仮想ネットワーク（VNet）を 1 個ずつ用意し、バージニア北部と East US で接続します。
| 項目 | AWS | Azure |
|---|---|---|
| リージョン | us-east-1 米国東部（バージニア北部） | East US（eastus） |
| ネットワーク | VPC interconnect-vpc（10.0.0.0/16） |
VNet vnet-interconnect（10.1.0.0/16） |
| サブネット | パブリック 10.0.0.0/20、プライベート 10.0.128.0/20 | default 10.1.0.0/24、GatewaySubnet 10.1.255.0/27 |
| ゲートウェイ | 仮想プライベートゲートウェイ + Direct Connect Gateway | ExpressRoute 仮想ネットワークゲートウェイ |
Azure 側の前提条件として、Microsoft Learn には Azure サブスクリプション、接続先 CSP のアカウント、ExpressRoute 仮想ネットワークゲートウェイ、そして Azure と CSP 側のネットワークでアドレス空間が重複しないことが挙げられています。上記の構成では AWS 側を 10.0.0.0/16、Azure 側を 10.1.0.0/16 として重複を避けています。
事前準備
Interconnect を接続するための準備を AWS と Azure で実施します。AWS 側は Direct Connect Gateway、Azure 側は ExpressRoute 仮想ネットワークゲートウェイと接続するため、事前に作成しておきます。Azure 側の ExpressRoute 仮想ネットワークゲートウェイは作成に最大 45 分程度かかるので、先に作成を始めておくのがおすすめです。
Azure の事前準備
まずは仮想ネットワークを作成します。
| 項目 | 値 |
|---|---|
| 仮想ネットワーク名 | vnet-interconnect |
| リージョン | (US) East US |
| アドレス空間 | 10.1.0.0/16 |
| サブネット | default（10.1.0.0/24） |
次に ExpressRoute 仮想ネットワークゲートウェイ用のゲートウェイサブネットを追加します。仮想ネットワークの サブネット から + ゲートウェイ サブネット を選択すると、名前が GatewaySubnet で固定されたサブネットを作成できます。アドレス範囲は /27 以上が必要です。なお、ゲートウェイサブネットにネットワークセキュリティグループ（NSG）を関連付けることはサポートされていないので、NSG は仮想マシンを配置するサブネット側にだけ設定します。
| 項目 | 値 |
|---|---|
| サブネットの目的 | Virtual Network Gateway |
| 名前 | GatewaySubnet（固定） |
| アドレス範囲 | 10.1.255.0/27 |
ExpressRoute 仮想ネットワークゲートウェイを作成します。リソースの作成 から 仮想ネットワーク ゲートウェイ を検索して作成します。ゲートウェイの種類は必ず ExpressRoute を選択してください。SKU はプレビューの帯域幅 1 Gbps に見合う最小の性能ティアで、可用性ゾーン対応の ErGw1AZ を選択しています。非 AZ の SKU から AZ 対応の SKU への変更はゲートウェイの再作成が必要になるため、最初から AZ 対応にしておくと GA 後に上位 SKU へオンラインで変更できます。パブリック IP アドレスは ExpressRoute ゲートウェイでは Standard SKU のものが自動的に割り当てられます。
| 項目 | 値 |
|---|---|
| 名前 | ergw-interconnect |
| リージョン | East US |
| ゲートウェイの種類 | ExpressRoute |
| SKU | ErGw1AZ |
| 仮想ネットワーク | vnet-interconnect |
ゲートウェイのデプロイには最大 45 分程度かかります。デプロイ中に残りの準備を進めます。
AWS の事前準備
接続する AWS の VPC は interconnect-vpc という名称で作成して、以下のサブネットを構成します。
| Public / Private | Subnet Name | Availability Zone | CIDR |
|---|---|---|---|
| Public | interconnect-subnet-public1-us-east-1a | us-east-1a | 10.0.0.0/20 |
| Private | interconnect-subnet-private1-us-east-1a | us-east-1a | 10.0.128.0/20 |
Direct Connect Gateway を作成します。Amazon 側の ASN はプライベート ASN の範囲（64512〜65534）から任意の値を指定します。
| 項目 | 値 | 備考 |
|---|---|---|
| 名前 | interconnect-dxgw | |
| Amazon 側の ASN | 64512 | 64512 〜 65534 か 4200000000 〜 4294967294 |
仮想プライベートゲートウェイを作成し、VPC にアタッチします。
作成した仮想プライベートゲートウェイを VPC にアタッチします。
Direct Connect Gateway の詳細画面の ゲートウェイの関連付け タブから、仮想プライベートゲートウェイとのゲートウェイの関連付けを行います。
作成したゲートウェイを選択します。
Azure 側で Interconnect を作成する
Azure portal で Hybrid connectivity を検索して開き、左側のメニューで Azure Multicloud Interconnect を展開して Set up Azure Multicloud Interconnect で Create Multicloud Interconnect Circuit を選択します。
Configuration タブで以下の内容を入力します。Azure Multicloud Interconnect は ExpressRoute を基盤としているため、作成するのは ExpressRoute 回線ですが、ポートタイプに Azure Multicloud Interconnect を選択する点が通常の ExpressRoute 回線と異なります。ポートタイプを選択すると、マルチクラウドプロバイダー、リージョン、帯域幅を選択する欄が表示されます。View region mapping を選択すると、プロバイダーとリージョンの対応表を確認できます。アクティベーションキーの欄では Generate を選択し、Account ID には接続先の AWS アカウント ID（12 桁）を入力します。
| 項目 | 値 | 備考 |
|---|---|---|
| サブスクリプション / リソース グループ | 任意 / rg-interconnect | |
| ポートの種類 | Azure Multicloud Interconnect | |
| 回復性 | 最大回復性 | Azure Multicloud Interconnect では固定 |
| 回路名 | erc-interconnect-aws | 任意 |
| マルチクラウド プロバイダー | AWS | プレビュー時点では AWS のみ |
| Azure リージョン | useast | |
| 帯域幅 | 1 Gbps | プレビュー中は 1 Gbps のみ |
| アクティブ化キー | 生成 | Azure 側でキーを生成する |
| アカウント ID | AWS アカウント ID | AWS 側で承認するアカウント |
| 課金モデル | 従量制課金 | Azure Multicloud Interconnect では固定 |
確認および作成 で内容を確認し、作成 をクリックします。
作成された回線の詳細を確認して、Activation Key の •••••••••••••••• の右のアイコンをクリックしてアクティブ化キーをコピーします。AWS 側へ登録するのでメモしておきます。
なおアクティブ化キーは BASE64 エンコードされており、デコードすると以下のような JSON になっていました。
{
"version": 1,
"destinationEnvironmentUri": "https://partner-interconnect.us-east-1.api.aws/providers/azure/environments/aws-azure-env-1-eastus",
"sharedConnectionUuid": "12345678-a123-b123-c123-123456789012",
"connectionSizeMbps": 1000,
"destinationAccountId": "123456789012"
}
AWS 側で Interconnect を承認する
Azure 側で生成したアクティブ化キーを使って、AWS 側で Interconnect を承認します。AWS Direct Connect コンソールを開き、左側のナビゲーションペインから AWS Interconnect — マルチクラウド に移動して マルチクラウド相互接続を承諾 を選択します。
Azure 側で取得したアクティベーションキーを入力して Next をクリックします。
Interconnect の名前と、Direct Connect ゲートウェイを指定して 次へ をクリックします。
| 項目 | 値 | 備考 |
|---|---|---|
| 相互接続の説明 | interconnect-azure-01 | 任意 |
| 帯域幅 | 1Gbps | 固定 |
| Direct Connect ゲートウェイ | interconnect-dxgw | 事前準備で作成したもの |
Azure 側からの要求内容を確認して 相互接続を受け入れる をクリックすると、承認が完了し両クラウドでプロビジョニングが開始されます。
数分するとステータスが available になります。
仮想ネットワークに接続する
Azure 側では、Interconnect の回線を ExpressRoute 仮想ネットワークゲートウェイに接続することで仮想ネットワークから利用できるようになります。回線の Settings にある Connections を開き、+ Add を選択します。
Basics タブでは接続の種類を選択します。Microsoft Learn の手順では「ExpressRoute接続を作成します」と書かれていますが、ポータルの接続の種類には Multicloud Interconnect（マルチクラウド相互接続） という専用の選択肢が用意されているので、こちらを選択します。
| 項目 | 値 | 備考 |
|---|---|---|
| サブスクリプション / リソース グループ | 回線と同じ / rg-interconnect | |
| 接続の種類 | Multicloud Interconnect |
次に設定の画面です。この画面には不具合があるようで、そのままでは ExpressRoute circuit に作成したものを選択できません。前の画面（基本）の 接続の種類 で一度 ExpressRoute を選択し本画面（設定）の 回復性 で 高い回復性 を選んだ状態で前の画面（基本）に戻り、再度 接続の種類 で一度 Multicloud Interconnect を選択して画面を進めると ExpressRoute circuit が選択可能になります。（この不具合により、Interconnect の作成を AWS 起点から Azure 起点でやり直したり 3 回作り直して試したりして 1 日以上の時間が溶けました。。。。。。）
| 項目 | 値 | 備考 |
|---|---|---|
| 回復性 | 最大回復性 | Azure Multicloud Interconnect では固定 |
| 仮想ネットワーク ゲートウェイ | ergw-interconnect | 作成した仮想ネットワーク ゲートウェイ |
| 名前 | conn-interconnect-aws | 任意 |
| ExpressRoute 回線 | erc-interconnect-aws | 作成した Interconnect |
| ルーティングの重み | 0 | デフォルト |
Monitoring タブでは接続モニターを有効にしませんでしたが、必要に応じて設定してください。
内容を確認し、作成 をクリックします。接続オブジェクトの作成には数分かかります。
作成後、接続の概要で状態が Succeeded になっていることを確認します。
ルーティングの設定
AWS 側は、VPC のルートテーブルで仮想プライベートゲートウェイからのルート伝播を有効化します。対象のルートテーブルで ルート伝播の編集 を選択します。
伝播を有効にして保存します。
ルート伝播を有効化すると、ルートテーブルに Azure 側の仮想ネットワークのアドレス空間（10.1.0.0/16）が伝播されます。
Azure 側の仮想ネットワークは、ExpressRoute 仮想ネットワークゲートウェイが広報された経路をサブネットに自動的に反映するようです。
通信確認
AWS と Azure にそれぞれ EC2 インスタンスと仮想マシンを起動しておきます。
AWS 側から確認
AWS の EC2 インスタンスで操作します。
$ uname -a
Linux ip-10-0-143-14.ec2.internal 6.18.44-99.149.amzn2023.x86_64 #2 SMP PREEMPT_DYNAMIC Tue Aug 25 21:16:03 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
IP アドレスを確認します。
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 12:8e:ea:95:7d:a9 brd ff:ff:ff:ff:ff:ff
altname enp0s5
altname eni-0c5daa4f51f859bc7
altname device-number-0.0
inet 10.0.143.14/20 metric 512 brd 10.0.143.255 scope global dynamic ens5
valid_lft 2524sec preferred_lft 2524sec
inet6 fe80::108e:eaff:fe95:7da9/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
ping で Azure の仮想マシンへアクセスします。アメリカ東部での接続は平均 4.316ms でした。
$ ping -c 10 10.1.0.4
PING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.
64 bytes from 10.1.0.4: icmp_seq=1 ttl=62 time=7.59 ms
64 bytes from 10.1.0.4: icmp_seq=2 ttl=62 time=5.40 ms
64 bytes from 10.1.0.4: icmp_seq=3 ttl=62 time=3.36 ms
64 bytes from 10.1.0.4: icmp_seq=4 ttl=62 time=5.21 ms
64 bytes from 10.1.0.4: icmp_seq=5 ttl=62 time=4.04 ms
64 bytes from 10.1.0.4: icmp_seq=6 ttl=62 time=3.48 ms
64 bytes from 10.1.0.4: icmp_seq=7 ttl=62 time=3.73 ms
64 bytes from 10.1.0.4: icmp_seq=8 ttl=62 time=3.83 ms
64 bytes from 10.1.0.4: icmp_seq=9 ttl=62 time=3.26 ms
64 bytes from 10.1.0.4: icmp_seq=10 ttl=62 time=3.25 ms
--- 10.1.0.4 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 3.254/4.316/7.592/1.311 ms
traceroute も確認してみます。Azure の仮想マシンまで 3 ホップでした。
$ sudo traceroute 10.1.0.4
traceroute to 10.1.0.4 (10.1.0.4), 30 hops max, 60 byte packets
1 169.254.255.9 (169.254.255.9) 0.772 ms 169.254.255.1 (169.254.255.1) 0.643 ms 169.254.255.5 (169.254.255.5) 0.784 ms
2 * * *
3 ip-10-1-0-4.ec2.internal (10.1.0.4) 3.466 ms 3.424 ms *
Azure 側から確認
Azure の 仮想マシンで操作します。
$ uname -a
Linux vm-2 6.17.0-1022-azure #22-Ubuntu SMP Mon Jul 27 17:24:03 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
IP アドレスを確認します。
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 70:a8:a5:93:d8:51 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.4/24 metric 100 brd 10.1.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::72a8:a5ff:fe93:d851/64 scope link
valid_lft forever preferred_lft forever
3: ens1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master eth0 state UP group default qlen 1000
link/ether 70:a8:a5:93:d8:51 brd ff:ff:ff:ff:ff:ff
altname enp0s0
ping で AWS の EC2 インスタンスへアクセスします。アメリカ東部での接続は平均 5.861ms でした。
$ ping -c 10 10.0.143.14
PING 10.0.143.14 (10.0.143.14) 56(84) bytes of data.
64 bytes from 10.0.143.14: icmp_seq=1 ttl=125 time=9.07 ms
64 bytes from 10.0.143.14: icmp_seq=2 ttl=125 time=6.36 ms
64 bytes from 10.0.143.14: icmp_seq=3 ttl=125 time=5.17 ms
64 bytes from 10.0.143.14: icmp_seq=4 ttl=125 time=4.14 ms
64 bytes from 10.0.143.14: icmp_seq=5 ttl=125 time=5.19 ms
64 bytes from 10.0.143.14: icmp_seq=6 ttl=125 time=4.75 ms
64 bytes from 10.0.143.14: icmp_seq=7 ttl=125 time=4.40 ms
64 bytes from 10.0.143.14: icmp_seq=8 ttl=125 time=7.42 ms
64 bytes from 10.0.143.14: icmp_seq=9 ttl=125 time=7.35 ms
64 bytes from 10.0.143.14: icmp_seq=10 ttl=125 time=4.77 ms
--- 10.0.143.14 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 4.142/5.861/9.074/1.537 ms
traceroute も確認してみます。AWS の EC2 インスタンスまで 3 ホップでした。
$ sudo traceroute 10.0.143.14
traceroute to 10.0.143.14 (10.0.143.14), 64 hops max
1 10.1.255.4 8.254ms 3.813ms 1.888ms
2 169.254.255.1 2.505ms 1.986ms 3.801ms
3 10.0.143.14 3.892ms 3.875ms 3.873ms
さいごに
AWS re:Invent 2025 で Google Cloud との接続が発表されたときに 2026 年には Azure も利用可能になると予告されていましたが、予告どおり Azure との接続がプレビューで使えるようになりました。これで AWS Interconnect - multicloud は Google Cloud、OCI、Azure の主要 3 CSP すべてに対応し、どの CSP と接続する場合でも AWS 側は同じ Create / Accept の操作で済むようになったのは大きな進歩だと思います。
Google Cloud との接続ではプレビュー当初、Google Cloud 側の操作が gcloud コマンドのみでしたが、Azure Multicloud Interconnect は最初から Azure portal で完結します。ただ Azure Portal で ExpressRoute connections の設定時に ExpressRoute circuit が選択不能になる不具合は通常の操作が行えないため早急な対応を望みます。
そして毎回書いていますが、早く日本のリージョンにも来てください！
