NRI xPalette Advent Calendar 2025

株式会社野村総合研究所

【re:Invent2025】AWS Interconnectを早速触ってみた！【マルチクラウド】

Last updated at 2025-12-15Posted at 2025-12-15

この記事は「NRI xPalette Advent Calendar 2025」の17日目です。

はじめに

今年もアドベントカレンダーの季節がやってきました。
昨年に引き続き、ネットワークネタを取り上げます。

今回触ってみたのは、2025/11/30にプレビュー版として公開されたAWS Interconnectです。

AWS Interconnectは、他のクラウドサービスプロバイダ (CSP)へのシンプルで耐障害性に優れた高速なプライベート接続を提供する新サービスです。

この記事の内容は、プレビュー期間中の2025/12/10に検証したものです。
最新の情報は公式ドキュメントのご確認をお願いいたします。

AWS Interconnectとは？

AWS Interconnectは、他CSPへの閉域接続をシンプルかつ簡単に構築できる、新しいネットワークサービスです。

従来、AWSから他CSPへ閉域接続を利用する場合は、Direct Connectを利用した上でネットワークプロバイダや自前のネットワーク機器を介して接続する必要がありました。
しかし、AWS Interconnectを利用することで、そのようなネットワーク機器の用意が不要になり、コンソール画面からリージョンと帯域を選択するだけで簡単に閉域接続を構築できます。

Interconnectを利用した構成として、上記のような構成が挙げられます。(公式ドキュメントより引用)

Interconnectを利用するには、AWS側と他CSP側の両端にて接続ポイントが必要です。AWSの接続ポイントはDirect Connect Gateway, プレビュー版で利用可能なGoogle Cloudの接続ポイントはCloud Routerになります。

Interconnectは、2つの物理施設に分散された高可用な構成でプロビジョニングされます。
また、AWSと他CSPのルータ間の通信はMACsecで暗号化され、暗号化セッションがアクティブな場合のみ顧客のトラフィックが流れる仕組みになっています。

利用可能なリージョン

現在は一部リージョンのみで提供されています。

AWSリージョン	Google Cloudリージョン
US East (N. Virginia) us-east-1	N. Virginia (us-east4)
US West (N. California) us-west-1	Los Angeles (us-west2)
US West (Oregon) us-west-2	Oregon (us-west1)
Europe (London) eu-west-2	London (europe-west2)
Europe (Frankfurt) eu-central-1	Frankfurt (europe-west3)

AWS側の接続ポイントはDirect Connect Gatewayなので、VGWやTransit Gateway、Cloud　WANと組み合わせて利用することが可能です。
ただし、VGWとTransit Gatewayは、Interconnectを作成するリージョンと同一のリージョンである必要があります。

Virtual gateways or Transit Gateways in a specific AWS Region, through a Direct Connect gateway, can only reach an Interconnect that provides connectivity to the paired Google Cloud Region. This Interconnect is considered "local" to that AWS Region. For example, a Transit Gateway in the AWS Region N. Virginia (us-east-1) can only reach an Interconnect that connects to the Google Cloud N. Virginia (us-east4) Region.

(公式ドキュメントより引用)

AWS Interconnectでマルチクラウドネットワークやってみた

早速AWS Interconnectを利用して、AWSのEC2とGCPのVM間で疎通確認をしてみました！
プレビュー期間中は、AWS Interconnect部分のAWS側利用料は無料になります。

今回の構成は以下の通りです。

AWS Interconnectを作成する際、以下の2パターンで作成することができます。

AWSのコンソール画面でInterconnectを作成し、他CSPで承認する
他CSPでInterconnectを作成し、AWSのコンソール画面で承認する

今回は、AWSのコンソール画面でInterconnectを作成する手順で進めたいと思います。

Google CloudでInterconnectを作成する場合は、以下のドキュメントをご覧ください。

手順概要

AWSのコンソール画面からInterconnectを作成する場合、手順は大きく以下の通りです。
(VPCやDirect Connectの作成等は省略しています)

AWSのコンソール画面でInterconnectを作成し、アクティベーションキーを払い出す (下図①)
Google CloudのCloud Shellで、アクティベーションキーを利用してtransportとVPCネットワークピアリングを作成する (下図③)
AWSのコンソール画面で、Interconnectが有効化されたことを確認する (下図④)

(公式ドキュメントより引用)

早速、各手順を見ていきます。

AWSのコンソール画面でInterconnectを作成し、アクティベーションキーを払い出す

公式ドキュメントでは、以下のページに手順が記載されています。

Direct Connectのコンソール画面の左側にAWS Interconnectのメニューが追加されていることが確認できます。ここから、Create Multicloud Interconnectを押下して、Interconnectの作成画面に進みます。

ProviderはGoogle Cloudを選択して次へを押下。

AWS側のリージョンを選択します。現在はプレビュー版ということで、対応している5リージョンのみが選択可能になっています。
今回はus-east-1を選択しました。

次にGoogle Cloud側リージョンを選択します。
利用可能なリージョンで記載したように、AWSリージョンとGoogle Cloudリージョンは1:1対応しています。
AWSリージョンを選択すると、それに対応したGoogle Cloudリージョンのみが選択肢に表示されるようになりました。

リージョンを選択後は、帯域、Direct Connect GatewayとGoogle CloudのProject IDを入力します。
帯域の選択肢は1Gbpsのみでした。

確認画面。問題なければFinishを押下。

Interconnectを作成すると、アクティベーションキーが発行されます。
Google Cloud側の設定で利用するので、忘れずに保存しておきましょう。

Google CloudのCloud Shellで、アクティベーションキーを利用してtransportとVPCネットワークピアリングを作成する

公式ドキュメントでは、以下のページに手順が記載されています。

Cloud Shellを起動し、transportリソースを作成する以下のコマンドを実行します。

curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://networkconnectivity.googleapis.com/v1beta/projects/PROJECT/locations/LOCATION/transports?transportId=TRANSPORT_ID \
--data '
{
"bandwidth": "BANDWIDTH",
"network": "NETWORK",
"advertisedRoutes": ["IP_RANGE"],
"providedActivationKey": "ACTIVATION_KEY",
"stackType": "STACK_TYPE"
}'

各変数は、以下の値で置き換えました。

PROJECT: Interconnect作成時に指定したGoogle CloudのProject ID
LOCATION: Googe Cloud側のリージョン。今回はus-east4を使用
TRANSPORT_ID: 任意のリソース名称
BANDWIDTH: 1GbpsでInterconnectを作成したので、BPS_1G
NETWORK: Google CloudのVPC名
IP_RANGE: Google CloudからAWSへ広報するネットワークセグメント。今回は作成したサブネットの10.0.1.0/24としました
ACTIVATION_KEY: 前手順で発行されたアクティベーションキー
STACK_TYPE: オプション項目。デフォルトではIPV4_ONLY。省略可ですが、一応IPV4_ONLYを指定しました

コマンドを実行してtransportを作成したら、VPCピアリングを作成します。

gcloud compute networks peerings create "TRANSPORT_NAME" \
    --network="VPC_NETWORK" \
    --peer-network="PEERING_NETWORK" \
    --stack-type="STACK_TYPE" \
    --import-custom-routes
    --export-custom-routes

公式ドキュメントに記載のコマンドは、--network="VPC_NETWORK"の後のバックスラッシュが抜けていてエラーになったので注意です。

各変数は、以下の値で置き換えました。

TRANSPORT_NAME: transport作成時に指定したTRANSPORT_ID
VPC_NETWORK: Google CloudのVPC名
PEERING_NETWORK: transportリソースによって提供されるVPCネットワークの名前
STACK_TYPE: transport作成時のSTACK_TYPEと揃える必要があります。今回はIPV4_ONLY

PEERING_NETWORKは、transport作成時に確認できると思いますが、私は見逃してしまったので以下のコマンドで再確認しました。

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://networkconnectivity.googleapis.com/v1beta/projects/PROJECT/locations/LOCATION/transports"

# レスポンス
{
  "transports": [
    {
      "name": "projects/PROJECT/locations/LOCATION/transports/TRANSPORT_ID",
      "createTime": "timestamp",
      "updateTime": "timestamp",
      "remoteProfile": "projects/PROJECT/locations/LOCATION/remoteTransportProfiles/AWS_REGION",
      "providedActivationKey": "ACTIVATION_KEY",
      "bandwidth": "BANDWIDTH",
      "stackType": "STACK_TYPE",
      "state": "ACTIVE",
      "network": "TRANSPORT_ID",
      "advertisedRoutes": [
        "IP_RANGE"
      ],
      "peeringNetwork": "xxxxxxx" # ここがPEERING_NETWORK
    }
  ]
}

VPCピアリングの作成が完了したら、Google Cloud側の作業は完了です。

AWSのコンソール画面でInterconnectが有効化されたことを確認する

最後に、AWSのコンソール画面で、Interconnectが有効化されたことを確認します。
Interconnectの状態がavailableになったらOKです！

せっかくなので、EC2からVMにpingを飛ばしてみると...

無事に疎通確認できました！

CloudWatch Network Synthetic Monitor 使えます

Interconnectでは、CloudWatch Network Synthetic Monitorが各Interconnectで使うことができます。(しかも追加料金なし！)

All Interconnects include a single CloudWatch Network Synthetic Monitor at no extra cost. You can use this active synthetic probe to produce round trip latency and packet loss metrics. You can configure CloudWatch alarms on your set thresholds. Refer to the CloudWatch Network Synthetic Monitor user guide for configuration. Note that the Network Health Indicator feature is not yet supported with Interconnects. Latency and packet loss metrics are fully supported.

(公式ドキュメントより引用)

CloudWatch Network Synthetic Monitorで取得可能なメトリクスのうち、レイテンシーとパケットロス値は取得可能ですが、Network Health Indicatorは未対応のようです。(2025/12/10時点)

Google CloudのVM宛にICMPを飛ばし続けるモニターを作成してみました。

いい感じにメトリクスを収集できていますね。
レイテンシーやパケットロスの値を利用してCloudwatch Alarmを仕掛けておくと、クラウド間の通信障害時に気付きやすくなるでしょう。

さいごに

今回は、re:Invent2025でプレビュー版として公開されたAWS Interconnectを触ってみました。
普段Direct Connectをメインで触っている身としては、こんなに簡単にクラウド間の閉域接続を構築できてしまうのかととても驚きました。触る前まではInterconnect上にVIFを作成するのかと思っていたのですが、ユーザ目線ではInterconnectリソースしか見えず、まるッとCSP側で構築・管理してもらえるようです。便利ですね。

まだGoogle Cloudのみの対応ですが、2026年後半にはAzureでも提供が予定されているようです。
AWS Interconnectの発展がこれから楽しみです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up