【アップデート】AWS Interconnect - multicloud に 500 Mbps の無料枠が登場しました！
ウィスキー、シガー、パイプをこよなく愛する大栗です。
先日 AWS Interconnect - multicloud が GA になった際にお伝えしていた、500 Mbps の無料枠が提供開始されました！ GA 時点では「予定」とされていた無料枠が、実際に使えるようになった続報となります。
AWS Interconnect - multicloud のおさらい
AWS Interconnect - multicloud は、Amazon VPC と他のクラウドプロバイダー（CSP）のネットワークをプライベートな高速接続で直結するサービスです。従来の Direct Connect やサードパーティのファブリックを経由した接続に比べて、物理的なプロビジョニングが不要で、接続の作成と承認だけで済むため、セットアップと運用の負荷が大幅に削減されます。
サービスの全体像や、GA で何が変わったか、実際の接続手順については以下のエントリにまとめていますので、あわせてご確認ください。
対応する CSP
AWS Interconnect - multicloud が接続できる CSP は以下のとおりです。
| CSP | ステータス |
|---|---|
| Google Cloud | GA（一般提供） |
| Oracle Cloud Infrastructure（OCI） | パブリックプレビュー |
| Microsoft Azure | 2026 年後半に対応予定 |
GA 済みなのは Google Cloud のみで、OCI はパブリックプレビュー、Azure は 2026 年後半の対応予定です。後述する 500 Mbps の無料枠は、GA 済みの Google Cloud との接続が対象となります。OCI はパブリックプレビュー中のため、プレビュー期間中の 1 Gbps 接続自体は別途無料で利用できますが、GA に伴って提供される 500 Mbps の無料枠とは枠組みが異なる点にご注意ください。
500 Mbps の無料枠
今回のアップデートで、GA 済みの Google Cloud との接続を対象に 500 Mbps までの Interconnect を AWS 側無料で利用できる枠 が提供されました。500 Mbps はデータ転送量に換算すると月あたり約 160 TB が目安となり、検証用途であれば十分な帯域です。
無料枠といっても品質が落ちるわけではなく、有料の枠と 同一のパス・施設・デバイス冗長性 で提供されます。AWS Interconnect - multicloud は 2 つ以上の物理施設と 4 台のルーターによる冗長構成を備えていますが、無料枠でもこの信頼性がそのまま享受できるということとなります。
さらに、接続の品質を可視化する Amazon CloudWatch Network Synthetic Monitor も追加料金なしで付いてきます。無料枠で接続しつつ、レイテンシーやパケットロスのモニタリングまでできるのは嬉しいポイントです。
無料枠の条件・注意点
無料枠を利用するうえで、いくつか押さえておきたい条件があります。
- 1 顧客・1 AWS リージョン・1 CSP あたり、ローカル（Tier 1）Interconnect 1 本まで が無料の対象です。同一リージョン・同一 CSP に対して 2 本目以降を引いたり、より広いスコープの接続を利用したりする場合は通常料金の回線が必要です。
- 無料になるのは AWS 側の Interconnect 料金のみ です。接続先となる Google Cloud など、相手 CSP 側の料金は独立して発生します。
- Google Cloud の Partner Cross-Cloud Interconnect の料金ページには 500 Mbps の記載はありませんが 1 Gbps の半額の料金となっています。そのため以下のようになります。
- 北米：$1.75 / h
- ヨーロッパ：$1.75 / h
- APAC：$2.50 / h
- 南アメリカ：$3.80 / h（未提供）
- Google Cloud の Partner Cross-Cloud Interconnect の料金ページには 500 Mbps の記載はありませんが 1 Gbps の半額の料金となっています。そのため以下のようになります。
- 無料枠の Interconnect は帯域を変更できません。1Gbps 以上の帯域が必要な場合には、別途 Interconnect を作成する必要があります。
- 無料枠の利用は AWS Service Terms に準拠します。
対応リージョン
対応リージョンを確認したところ、GA 時点では米国・欧州を中心とした 5 ペアでしたが、いつの間にか AWS シンガポール（ap-southeast-1）↔ Google Cloud シンガポール（asia-southeast1） が追加されていました！ アジアパシフィックで初の対応ペアです。Google Cloud との接続で対応しているロケーションは以下のとおりです。
| AWS リージョン | Google Cloud のロケーション |
|---|---|
| us-east-1 米国（バージニア北部） | us-east4（北バージニア） |
| us-west-1 米国（北カリフォルニア） | us-west2（ロサンゼルス） |
| us-west-2 米国（オレゴン） | us-west1（オレゴン） |
| eu-west-2 欧州（ロンドン） | europe-west2（ロンドン） |
| eu-central-1 欧州（フランクフルト） | europe-west3（フランクフルト） |
| ap-southeast-1 アジアパシフィック（シンガポール） | asia-southeast1（シンガポール） |
なお、OCI との接続は AWS バージニア北部（us-east-1）↔ OCI アッシュバーン（us-ashburn-1）で対応しています。
アジアパシフィックに対応ペアが増えたのは大きな前進ですが、残念ながら日本リージョン（東京・大阪）はまだ対応していません。シンガポールまで来たので、東京・大阪への対応も期待したいところです。
最新の対応状況は以下のドキュメントでご確認ください。
料金のイメージを整理すると、以下のようになります。
| 項目 | 500 Mbps 無料枠 | 有料枠 |
|---|---|---|
| AWS 側 Interconnect 料金 | 無料 | 帯域幅・地理的スコープに応じて課金 |
| 帯域幅 | 500 Mbps（Tier 1 ローカル 1 本） | 1 Gbps 〜 100 Gbps |
| パス・施設・冗長性 | 有料枠と同一 | 同一 |
| CloudWatch Network Synthetic Monitor | 追加料金なし | 追加料金なし |
| 相手 CSP 側の料金 | 別途発生 | 別途発生 |
やってみる
無料枠で実際に接続してみます。AWS Interconnect - multicloud は AWS / Google Cloud のどちらからでも接続を開始できるフローになっています。今回は AWS 側から開始 してみます。流れは「AWS 側で Create してアクティベーションキーを取得 → Google Cloud 側でそのキーを使って Accept」となります。
今回はシンガポールリージョン（ap-southeast-1）から Google Cloud のシンガポール（asia-southeast1）へ接続を開始します。
事前準備（AWS 側の Direct Connect Gateway、Google Cloud 側の Cloud Router・VPC など）は前回記事と同様ですので適宜リージョンをシンガポールに読み替えて準備してください。
本記事では AWS マネジメントコンソールでの Interconnect 作成のポイントに絞ってご紹介します。
マルチクラウド Interconnect の作成
AWS マネジメントコンソールを開き、上部の検索欄で Direct Connect 入力して出てくる Direct Connect のリンクをクリックして画面を移動します。
AWS Interconnect - multicloud - Free Tier を選択します。
ここで注意ですが Interconnect と検索して AWS Interconnect - multicloud のページに直接移動して Create Multicloud Interconnect をクリックすると 1Gbps 以上の有料枠しか選択できないため注意です。（こちらを見ていたので 500Mbps が使えるようにならないとずっと待っていました）
接続先の CSP を選択します。無料枠の対象は Google Cloud しか無いので、それを選択して Next をクリックします。
ソースとなる AWS リージョンと、接続先となる CSP 側のリージョンを選択します。ここではソースを ap-southeast-1（シンガポール）、接続先を Google Cloud の asia-southeast1（シンガポール）とします。選択した AWS リージョンが Interconnect が配置されるローカルリージョンになります。
接続の名前や説明を入力し、必要な帯域幅・アタッチポイントとなる Direct Connect Gateway・相手 CSP 側の ID を指定します。無料枠の帯域幅は 500 Mbps 固定 になっています。相手 CSP 側の ID は、Google Cloud の場合はプロジェクト ID を入力します。Next をクリックします。
| 項目 | 値 | 備考 |
|---|---|---|
| Description | <任意の内容> | 有効な文字は、a～z、0～9、ハイフン (–) |
| Bandwidth | 500Mbps | Free Tier の導線の場合は 500 Mbps 固定 |
| Direct Connect gateway | <既存の DXGW を指定> | この画面から新規作成も可能 |
| Google Cloud project ID | <接続先のプロジェクト ID> |
確認画面が表示されるので、内容を確認して Finish をクリックします。
接続のリクエストが Google Cloud に送信され、アクティベーションキーが表示されます。このキーを Google Cloud 側でのアクティベーションに使用するため、控えておきます。
Google Cloud 側でアクティベート
AWS で表示されたアクティベーションキーを使って、Google Cloud 側でアクティベートします。
Google Cloud の Partner Cross-Cloud Interconnect のコンソールで Create transport をクリックします。
Initialization location で Remote Cloud Service Provider を選択します。コピーしていたアクティベーションキーを入力して Validate をクリックします。Continue をクリックします。
Tranport profile で Amazon Web Services Oregon (ap-southeast-1) を選択して Continue をクリックします。
Tranport name を入力して、Bandwidth で 500 Mb/s を指定して Continue をクリックします。
Connectivity method で VPC peering を選択して Network で VPC を選択し、Advertised routes にサブネットの CIDR を入力して Create をクリックします。
数分待つとトランスポートが作成されます。
Google Cloud 側でピアリングの設定
ここでは Cloud Shell 上で gcloud コマンドを使用して設定します。
ピアリングを設定する前に VPC ネットワークの MTU を Partner Cross-Cloud Interconnect で設定されている 8896 に変更しておきます。
$ gcloud compute networks update interconnect-vpc --mtu=8896
This might cause connectivity issues when there are running VMs attached.
Do you want to continue (y/N)? y
ネットワーク名を取得します。peeringNetwork の内容を確認します。
$ gcloud network-connectivity transports describe to-aws-transport --region asia-southeast1
advertisedRoutes:
- 10.1.0.0/20
bandwidth: BPS_500M
createTime: '2026-05-30T11:50:40.426592715Z'
name: projects/project-name/locations/asia-southeast1/transports/to-aws-transport
network: projects/project-name/global/networks/interconnect-vpc
peeringNetwork: projects/123456789012/global/networks/transport-1234567890123456-vpc
providedActivationKey: 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567=
remoteProfile: projects/project-name/locations/us-west1/remoteTransportProfiles/aws-ap-southeast-1
stackType: IPV4_ONLY
state: ACTIVE
updateTime: '2026-05-30T12:01:17.504829485Z'
VPCネットワークピアリングを確立するために gcloud compute networks peerings create コマンドを実行します。--peer-network には先程確認した peeringNetwork の内容を設定します。
$ gcloud compute networks peerings create "to-aws-transport" \
--network="interconnect-vpc" \
--peer-network="projects/123456789012/global/networks/transport-1234567890123456-vpc" \
--stack-type=IPV4_ONLY \
--import-custom-routes \
--export-custom-routes
Updated [https://www.googleapis.com/compute/v1/projects/oguri-hajime/global/networks/interconnect-vpc].
---
autoCreateSubnetworks: false
creationTimestamp: '2026-05-30T03:21:55.030-07:00'
description: ''
id: '1234567890123456789'
kind: compute#network
mtu: 8896
name: interconnect-vpc
networkFirewallPolicyEnforcementOrder: AFTER_CLASSIC_FIREWALL
・
・
・
あとは AWS 側でルーティングの設定を行います。詳細は GA 時のブログをご参照ください。
接続の確認
AWS と Google Cloud に仮想マシンを立てておき ICMP の通信を許可しておきます。
AWS から接続
Amazon Linux 2023 で実行しています。
$ uname -a
Linux ip-10-0-10-189.ap-southeast-1.compute.internal 6.1.172-216.329.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Wed May 20 06:31:34 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 06:dd:15:7e:fd:15 brd ff:ff:ff:ff:ff:ff
altname enp0s5
altname eni-049dfdc3c7e0e6e90
altname device-number-0.0
inet 10.0.10.189/20 metric 512 brd 10.0.15.255 scope global dynamic ens5
valid_lft 3085sec preferred_lft 3085sec
inet6 fe80::4dd:15ff:fe7e:fd15/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
対向の Google Cloud の仮想マシンへアクセスします。シンガポールリージョンでは概ね 3ms 未満のようです。
$ ping -c 10 10.1.0.2
PING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.
64 bytes from 10.1.0.2: icmp_seq=1 ttl=62 time=3.08 ms
64 bytes from 10.1.0.2: icmp_seq=2 ttl=62 time=2.70 ms
64 bytes from 10.1.0.2: icmp_seq=3 ttl=62 time=2.67 ms
64 bytes from 10.1.0.2: icmp_seq=4 ttl=62 time=2.67 ms
64 bytes from 10.1.0.2: icmp_seq=5 ttl=62 time=2.67 ms
64 bytes from 10.1.0.2: icmp_seq=6 ttl=62 time=2.71 ms
64 bytes from 10.1.0.2: icmp_seq=7 ttl=62 time=2.67 ms
64 bytes from 10.1.0.2: icmp_seq=8 ttl=62 time=2.65 ms
64 bytes from 10.1.0.2: icmp_seq=9 ttl=62 time=2.67 ms
64 bytes from 10.1.0.2: icmp_seq=10 ttl=62 time=2.66 ms
--- 10.1.0.2 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9016ms
rtt min/avg/max/mdev = 2.653/2.714/3.079/0.122 ms
traceroute を実行します。以下のようになってしまいます。
$ traceroute 10.1.0.2
traceroute to 10.1.0.2 (10.1.0.2), 30 hops max, 60 byte packets
1 169.254.68.90 (169.254.68.90) 1.023 ms * *
2 142.250.230.234 (142.250.230.234) 1.769 ms 142.250.215.52 (142.250.215.52) 1.781 ms 172.253.53.65 (172.253.53.65) 0.663 ms
3 172.253.53.65 (172.253.53.65) 0.651 ms 142.250.230.234 (142.250.230.234) 1.746 ms 142.250.215.52 (142.250.215.52) 1.991 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
80/tcp で traceroute してみると 4 ホップでした。
$ sudo traceroute -T -p 80 10.1.0.2
traceroute to 10.1.0.2 (10.1.0.2), 30 hops max, 60 byte packets
1 169.254.229.242 (169.254.229.242) 1.185 ms 169.254.45.130 (169.254.45.130) 0.822 ms 169.254.229.242 (169.254.229.242) 1.146 ms
2 142.250.215.33 (142.250.215.33) 0.646 ms 172.253.53.65 (172.253.53.65) 0.671 ms 142.250.215.33 (142.250.215.33) 0.642 ms
3 142.250.215.52 (142.250.215.52) 1.718 ms 1.707 ms 172.253.53.65 (172.253.53.65) 0.657 ms
4 ip-10-1-0-2.ap-southeast-1.compute.internal (10.1.0.2) 3.937 ms 10.750 ms 3.623 ms
Google Cloud から接続
Debian GNU/Linux 12 で実行しています。
$ uname -a
Linux instance-20260530-135800 6.1.0-49-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.174-1 (2026-05-26) 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: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8896 qdisc mq state UP group default qlen 1000
link/ether 42:01:0a:01:00:02 brd ff:ff:ff:ff:ff:ff
altname enp0s4
inet 10.1.0.2/32 metric 100 scope global dynamic ens4
valid_lft 84000sec preferred_lft 84000sec
inet6 fe80::4001:aff:fe01:2/64 scope link
valid_lft forever preferred_lft forever
対向の AWS の仮想マシンへアクセスします。シンガポールリージョンでは概ね 3ms 未満のようです。
$ ping -c 10 10.0.10.189
PING 10.0.10.189 (10.0.10.189) 56(84) bytes of data.
64 bytes from 10.0.10.189: icmp_seq=1 ttl=125 time=2.91 ms
64 bytes from 10.0.10.189: icmp_seq=2 ttl=125 time=2.90 ms
64 bytes from 10.0.10.189: icmp_seq=3 ttl=125 time=2.90 ms
64 bytes from 10.0.10.189: icmp_seq=4 ttl=125 time=2.95 ms
64 bytes from 10.0.10.189: icmp_seq=5 ttl=125 time=2.97 ms
64 bytes from 10.0.10.189: icmp_seq=6 ttl=125 time=2.96 ms
64 bytes from 10.0.10.189: icmp_seq=7 ttl=125 time=2.94 ms
64 bytes from 10.0.10.189: icmp_seq=8 ttl=125 time=2.91 ms
64 bytes from 10.0.10.189: icmp_seq=9 ttl=125 time=2.91 ms
64 bytes from 10.0.10.189: icmp_seq=10 ttl=125 time=2.92 ms
--- 10.0.10.189 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 2.902/2.926/2.967/0.023 ms
traceroute を実行します。3 ホップで到達します。
$ traceroute 10.0.10.189
traceroute to 10.0.10.189 (10.0.10.189), 30 hops max, 60 byte packets
1 142.250.215.33 (142.250.215.33) 3.557 ms 142.250.215.52 (142.250.215.52) 3.509 ms 172.253.53.65 (172.253.53.65) 3.486 ms
2 169.254.135.42 (169.254.135.42) 4.317 ms 169.254.68.90 (169.254.68.90) 3.438 ms 169.254.45.130 (169.254.45.130) 3.569 ms
3 10.0.10.189 (10.0.10.189) 3.802 ms 4.083 ms 3.671 ms
80/tcp で traceroute してみると、やはり 3 ホップでした。
$ sudo traceroute -T -p 80 10.0.10.189
traceroute to 10.0.10.189 (10.0.10.189), 30 hops max, 60 byte packets
1 142.250.215.33 (142.250.215.33) 3.292 ms 142.250.230.234 (142.250.230.234) 2.705 ms 142.250.215.33 (142.250.215.33) 3.449 ms
2 169.254.45.130 (169.254.45.130) 3.624 ms * *
3 10.0.10.189 (10.0.10.189) 3.849 ms * *
500 Mbps の無料枠でも、有料枠と同じようにシンプルな手順で接続できました。
無料枠の帯域変更
無料枠の場合は帯域の変更ができません。
AWS では Interconnect の編集画面で Bandwidth がグレーアウトされていて変更できません。
Google Clooud では Interconnect の編集中は変更可能ですが、保存時にエラーが発生します。
さいごに
GA のタイミングで予告されていた 500 Mbps の無料枠が、予定どおり 5 月中に提供開始されました。AWS 側のコストをかけずにマルチクラウド接続を試せるようになったため、PoC や中小規模な開発環境でマルチクラウド構成を検証するハードルが大きく下がります。しかも品質は有料枠と同等で、CloudWatch Network Synthetic Monitor によるモニタリングまで無料で付いてくるので、まずは無料枠で接続を試してから本番の帯域を検討する、という進め方がしやすくなりました。
あとはやはり日本リージョンへの対応が待ち遠しいところです。国内のお客様がこの無料枠で気軽にマルチクラウド接続を試せるよう、日本リージョン対応を心待ちにしています！
