AWS - Google Cloud 間は VPN より Interconnect の方が本当に速いのか ── 新サービス「AWS Interconnect」を使って実際に計測してみた

マルチクラウド構成の拡大に伴い、AWS と Google Cloud 間の安全・高速な接続選定が重要視されています。AWS Site-to-Site VPN は比較的容易に構築できる一方で、通信経路の一部でパブリックインターネットを利用するため、専用のプライベート接続と比較するとレイテンシやジッターが変動する可能性があります。

この課題を解決すべく、2026年4月に一般提供（以後、GA）となった新サービスが「AWS Interconnect」です。AWS と Google Cloud 間のプライベートネットワーク接続を簡素化したマネージドサービスのため、高セキュリティかつ低遅延な通信を数ステップで確立できます。

本ブログでは、これら2構成の「レイテンシ・スループット・パケットロス・ジッター」を実測比較した検証結果をお届けします。

注意:2026年6月現在、AWS Interconnect は東京（ap-northeast-1）未対応のため、本検証は米国東部（AWS:us-east-1、Google Cloud:us-east4）間で行っています。

検証環境・構成について

1. 構成概要

AWS と Google Cloud でそれぞれリソースを作成し、AWS Site-to-Site VPN または、AWS Interconnect で接続します。

構成① AWS Site-to-Site VPN ── インターネット経由で IPsec 接続
構成② AWS Interconnect ── プライベートバックボーン経由で直接接続

2. 使用リソース

AWS と Google Cloud でそれぞれ以下の構成でリソースを準備します。

3. AWS Interconnect とは

AWS Interconnect は2026年4月に GA となった、AWSと他のクラウドプロバイダーを直接プライベート接続するマネージドサービスです。

従来の接続方法との違いを整理すると以下の通りです。

対応リージョンペアは以下の通りです。（2026年6月15日時点）
東京リージョン対応は今後に期待されます。

共通リソース構築

AWS Site-to-Site VPN および AWS Interconnect の両構成で共通して使用するリソースを作成します。

1. [AWS 側] VPC・サブネット作成

以下の設定で VPC とサブネットを作成します。

2. [AWS 側] 仮想プライベートゲートウェイ（VGW）作成・アタッチ

VGW を作成し、VPC にアタッチします。Amazon ASN（自律システム番号）はデフォルトの「64512」を使用します。

3. [AWS 側] Direct Connect ゲートウェイ（DXGW）作成・VGW との関連付け

DXGW は AWS Interconnect 接続で使用します。VGW との関連付けでは許可されたプレフィックスの指定を忘れないようにしましょう。ここを忘れるとルートが伝播されず疎通できなくなります。

ポイント:DXGW・VGW ともに ASN は「64512」で問題ありません。BGP セッションを直接張る相手（Google Cloud / Cloud Router）と異なる ASN であることが重要なため、同一サービス内での重複は問題ありません。

4. [AWS 側] EC2 作成

計測用の EC2 を作成します。インスタンスタイプは帯域がボトルネックにならないよう c5n.large を使用します。
セキュリティグループには以下のインバウンドルールを追加します。

また、iperf3 をインストールします。

# iperf3 インストール
sudo yum install -y iperf3

5. [Google Cloud 側] VPC ネットワーク・サブネット作成

以下の設定でカスタム VPC とサブネットを作成します。

注意:AWS 側の VPC CIDR（192.168.0.0/16）と重複しないよう設定します。重複すると AWS Interconnect 接続時にルーティングエラーが発生します。

6. [Google Cloud 側] GCE VM 作成

計測用の GCE VM を作成する際は、サブネットを明示的に指定して作成します。ファイアウォールルールには以下を追加し、GCE VM に適用します。

また、iperf3 をインストールします。

# iperf3 インストール
sudo apt install -y iperf3

AWS Site-to-Site VPN 構築

以下の手順で AWS Site-to-Site VPN 接続環境を構築します。

1. [Google Cloud 側] Cloud HA VPN ゲートウェイ・Cloud Router 作成

Cloud HA VPN ゲートウェイを作成します。作成時に割り当てられる2つのグローバル IP アドレスを記録しておきます（後続の Customer ゲートウェイ作成で使用します）。

「高可用性（HA）VPN」を選択します。

VPN ゲートウェイの名前を入力し、「ネットワーク」で作成した VPC ネットワークを選択し、「リージョン」で「us-east4（北バージニア）」を選択します。

Cloud HA VPN ゲートウェイが作成され、グローバル IP アドレスがインターフェース欄に表示されます。

Cloud Router は BGP ルーティングに使用します。Cloud Router の ASN には AWS 側と重複しない「65000」を設定します。

2. [AWS 側] Customer ゲートウェイ（CGW）作成

Google Cloud の Cloud HA VPN ゲートウェイには2つのグローバル IP アドレスが割り当てられています。それぞれに対して CGW を作成します（計2つ）。

ポイント:Customer ゲートウェイの BGP ASN には「接続相手（Google Cloud 側）の ASN」を設定します。

3. [AWS 側] AWS Site-to-Site VPN 接続作成

VGW と各 CGW を組み合わせて2つの VPN 接続を作成します。

作成後、設定ファイルをダウンロードします。設定ファイルには Google Cloud 側のトンネル設定に必要な以下の情報が含まれています。
　・トンネルの外部 IP アドレス（Outside IP）
　・Pre-Shared Key（PSK）
　・BGP 用内部 IP アドレス（Inside IP:169.254.x.x）

4. [Google Cloud 側] ピア VPN ゲートウェイ作成

Google Cloud 側から見た対向（AWS 側）の VPN ゲートウェイ情報を登録します。
AWS 側で2つの VPN 接続を作成したため、計4つのグローバル IP アドレスがアサインされています。これらをピア VPN ゲートウェイのインターフェース（0〜3）にそれぞれ登録して作成します。

5. [Google Cloud 側] VPN トンネル作成

HA 構成のため VPN トンネルを4つ作成します。
IKE 事前共有キーは、設定ファイルに記載の PSK を指定します。

6. [Google Cloud 側] BGP セッションの構成

4つのトンネルそれぞれに BGP セッションを設定します。

ポイント:BGP アドレスの割り当ては必ず「手動」を選択し、AWS 設定ファイルに記載の IP アドレスをそのまま入力します。自動割り当てにすると AWS 側と不一致になり BGP セッションが確立しません。

7. ステータス確認・疎通確認

AWS コンソールで VPN 接続の状態が「利用可能」、トンネルのステータスが「アップ」になっていることを確認します。

双方向で ping を実施し疎通を確認します。

# 双方向で ping を実行
# AWS EC2 → Google Cloud GCE

[ec2-user@ip-192-168-0-208 ~]$ ping 10.0.0.2 -c 10
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=3.84 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=63 time=2.88 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=63 time=2.77 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=63 time=2.81 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=63 time=2.77 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=63 time=2.87 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=63 time=2.79 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=63 time=2.76 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=63 time=4.94 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=63 time=3.60 ms

--- 10.0.0.2 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9017ms
rtt min/avg/max/mdev = 2.756/3.200/4.938/0.684 ms

# Google Cloud GCE → AWS EC2
xxxxx@gce-gcp-connect-1:~$ ping 192.168.0.208 -c 10
PING 192.168.0.208 (192.168.0.208) 56(84) bytes of data.
64 bytes from 192.168.0.208: icmp_seq=1 ttl=126 time=5.62 ms
64 bytes from 192.168.0.208: icmp_seq=2 ttl=126 time=4.24 ms
64 bytes from 192.168.0.208: icmp_seq=3 ttl=126 time=4.24 ms
64 bytes from 192.168.0.208: icmp_seq=4 ttl=126 time=4.36 ms
64 bytes from 192.168.0.208: icmp_seq=5 ttl=126 time=4.21 ms
64 bytes from 192.168.0.208: icmp_seq=6 ttl=126 time=4.22 ms
64 bytes from 192.168.0.208: icmp_seq=7 ttl=126 time=4.25 ms
64 bytes from 192.168.0.208: icmp_seq=8 ttl=126 time=4.70 ms
64 bytes from 192.168.0.208: icmp_seq=9 ttl=126 time=4.22 ms
64 bytes from 192.168.0.208: icmp_seq=10 ttl=126 time=4.26 ms

--- 192.168.0.208 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 4.214/4.431/5.619/0.419 ms

ping 疎通を確認後、後述の計測を実施します。

AWS Interconnect 構築

AWS Site-to-Site VPN の計測が完了後、VPN 関連リソースを削除してから、以下の手順で AWS Interconnect 接続環境を構築します。

VPN 関連リソースの削除

以下のリソースを削除します。

注意:依存関係があるため、子リソースから順番に削除します。

AWS 側:① AWS Site-to-Site VPN 接続、② Customer ゲートウェイ（2つ）
Google Cloud 側:① VPN トンネル（4本）、② Cloud HA VPN ゲートウェイ、③ Cloud Router、④ピア VPN ゲートウェイ

1. [AWS 側] AWS Interconnect 作成

Direct Connect コンソールの「AWS Interconnect – マルチクラウド」セクションから作成します。

作成後に発行されるアクティベーションキーをコピーしておきます。このキーを Google Cloud 側の設定で使用します。

2. [Google Cloud 側] Transport Resource 作成

Transport Resource は Partner Cross-Cloud Interconnect for AWS の接続リソースです。
AWS Interconnect 作成時に発行されたアクティベーションキーを使って作成します。

作成後、設定情報を確認します。出力に含まれる peeringNetwork の値をメモしておきます。次の VPC Peering の作成で使用します。

xxxxx@cloudshell:~ ([PROJECT_ID])$ gcloud network-connectivity transports describe transport-gcp-connect-1 --region us-east4
# 出力例
advertisedRoutes:
- 10.0.0.0/24
bandwidth: BPS_1G
createTime: '2026-06-08T05:16:01.978950101Z'
name: projects/[PROJECT_ID]/locations/us-east4/transports/transport-gcp-connect-1
network: projects/[PROJECT_ID]/global/networks/vpc-gcp-connect-1
peeringNetwork: projects/xxxxxxxxxxxxx/global/networks/transport-xxxxxxxxxxxxxxxx-vpc
providedActivationKey: (省略)
remoteProfile: projects/[PROJECT_ID]/locations/us-east4/remoteTransportProfiles/aws-us-east-1
stackType: IPV4_ONLY
state: PENDING_CONFIG
updateTime: '2026-06-08T05:25:32.523081464Z'

3. [Google Cloud 側] VPC Network Peering 作成

Transport Resource と自身の Google Cloud VPC の間でルートを交換するために VPC Peering を作成します。

注意:「--import-custom-routes」と「--export-custom-routes」は両方必ず指定してください。片方でも欠けるとルートが伝播されず疎通できません。

xxxxx@cloudshell:~ ([PROJECT_ID])$ gcloud compute networks peerings create aws-interconnect-peering \
--network=vpc-gcp-connect-1 \
--peer-network=projects/xxxxxxxxxxxxx/global/networks/transport-xxxxxxxxxxxxxxxx-vpc \
--import-custom-routes \
--export-custom-routes

4. ステータス確認・疎通確認

VPC Peering の STATE が「ACTIVE」になったことを確認します。

# Peering の状態確認
xxxxx@cloudshell:~ ([PROJECT_ID])$ gcloud compute networks peerings list --network=vpc-gcp-connect-1
# 出力例
NAME: aws-interconnect-peering
NETWORK: vpc-gcp-connect-1
PEER_PROJECT: xxxxxxxxxxxxxxxxxx-tp
PEER_NETWORK: transport-xxxxxxxxxxxxxxxx-vpc
STACK_TYPE: IPV4_ONLY
PEER_MTU: 8896
IMPORT_CUSTOM_ROUTES: True
EXPORT_CUSTOM_ROUTES: True
UPDATE_STRATEGY: INDEPENDENT
STATE: ACTIVE
STATE_DETAILS: [2026-06-07T22:38:11.310-07:00]: Connected.

双方向で ping を実施し疎通を確認します。

# 双方向で ping を実行
# AWS EC2 → Google Cloud GCE

[ec2-user@ip-192-168-0-208 ~]$ ping 10.0.0.2 -c 10
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=62 time=2.69 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=62 time=1.73 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=62 time=1.66 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=62 time=1.62 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=62 time=1.68 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=62 time=1.65 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=62 time=1.66 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=62 time=1.71 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=62 time=1.65 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=62 time=1.63 ms

--- 10.0.0.2 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9016ms
rtt min/avg/max/mdev = 1.619/1.766/2.687/0.308 ms

# Google Cloud GCE → AWS EC2
xxxxx@gce-gcp-connect-1:~$ ping 192.168.0.208 -c 10
PING 192.168.0.208 (192.168.0.208) 56(84) bytes of data.
64 bytes from 192.168.0.208: icmp_seq=1 ttl=125 time=2.22 ms
64 bytes from 192.168.0.208: icmp_seq=2 ttl=125 time=1.91 ms
64 bytes from 192.168.0.208: icmp_seq=3 ttl=125 time=1.90 ms
64 bytes from 192.168.0.208: icmp_seq=4 ttl=125 time=1.91 ms
64 bytes from 192.168.0.208: icmp_seq=5 ttl=125 time=1.92 ms
64 bytes from 192.168.0.208: icmp_seq=6 ttl=125 time=1.90 ms
64 bytes from 192.168.0.208: icmp_seq=7 ttl=125 time=1.90 ms
64 bytes from 192.168.0.208: icmp_seq=8 ttl=125 time=1.96 ms
64 bytes from 192.168.0.208: icmp_seq=9 ttl=125 time=1.99 ms
64 bytes from 192.168.0.208: icmp_seq=10 ttl=125 time=1.93 ms

--- 192.168.0.208 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 1.896/1.953/2.224/0.094 ms

ping 疎通を確認後、AWS Site-to-Site VPN のときと同様に後述の計測を実施します。

計測結果

計測条件

計測ツール iperf3 とは、2台のサーバ間でデータを実際に流して、ネットワークの通信速度を計測するオープンソースツールです。

計測できる指標として、スループット、再送回数、パケットロス、ジッターなどがあります。

今回の検証では、AWS インスタンスを iperf3 サーバとし、Google Cloud インスタンスを iperf3 クライアントとし、ポート 5201 に対して通信します。

その1:レイテンシ計測（ping）

双方向から以下のコマンドを実行します。

# 計測コマンド（100パケット、0.2秒間隔）
ping [対向IP] -c 100 -i 0.2

その2:スループット計測（TCP）

基本計測（シングルストリーム、60秒）

以下のコマンドを実行します。

# AWS EC2
iperf3 -s -p 5201
# Google Cloud GCE
iperf3 -c [対向IP] -p 5201 -t 60

並列ストリーム計測（実トラフィックに近い条件、-P 8）

以下のコマンドを実行します。

# AWS EC2
iperf3 -s -p 5201
# Google Cloud GCE
iperf3 -c [対向IP] -p 5201 -t 60 -P 8

その3:UDP計測（パケットロス・ジッター）

以下のコマンドを実行します。

# AWS EC2
iperf3 -s -p 5201
# Google Cloud GCE
# AWS Site-to-Site VPN、AWS Interconnect
iperf3 -c [対向IP] -p 5201 -t 60 -u -b 1G
# AWS Interconnect（実効帯域に合わせて 500M に調整）
iperf3 -c [対向IP] -p 5201 -t 60 -u -b 500M

補足:AWS Interconnect で (-b 1G) 指定時に 51% のパケットロスが発生した原因は、送信レートが実効帯域を超過したことによる輻輳または帯域制御の影響と考えられます。(-b 500M) に調整後は 1.6% まで改善しました。

考察

レイテンシ:AWS Interconnect が約 45% 低く、最大値も安定

RTT（ラウンドトリップタイム）平均は AWS Interconnect が約 2.0 ms、AWS Site-to-Site VPN が約 3.7 ms と、AWS Interconnect が約 45% 低い結果になりました。

ただし、差の絶対値は約 1.7 ms と予想より小さい結果でした。これは今回の検証が AWS の us-east-1 と Google Cloud の us-east4 という地理的に非常に近いリージョンで実施したためと考えられます。VPN 経由のインターネットでも元々レイテンシが低く、AWS Interconnect との差が縮まった形です。

一方で RTT 最大値を見ると、AWS Site-to-Site VPN が最大 5.5 ms に達しているのに対し、AWS Interconnect は最大 3.1 ms に留まっています。インターネット経由の VPN は瞬間的な遅延スパイクが発生しやすく、AWS Interconnect はプライベートバックボーンのため一貫した低遅延を維持できるという特性が表れています。

スループット:シングルでは意外な結果、並列ではAWS Interconnect がより高いスループットを示した

シングルストリームでは AWS Site-to-Site VPN が 1,218.6 Mbps に対し、AWS Interconnect が 483.3 Mbps と、AWS Site-to-Site VPN が上回るという予想外の結果になりました。

一般的には専用ネットワークを利用する AWS Interconnect の方が高い性能を期待しがちですが、本検証では逆の結果となりました。ただし、この結果のみから AWS Site-to-Site VPN の方が高速であると結論付けることはできません。

今回の検証では、AWS 側に c5n.large、Google Cloud 側に n2-standard-4 を使用し、単一 TCP セッションで計測しています。シングルストリームのスループットは、ネットワーク経路だけでなく TCP ウィンドウサイズ、OS のチューニング状況、NIC の実装、経路制御、計測時の負荷状況など複数の要因の影響を受けます。そのため、今回の結果については追加検証が必要であり、現時点では原因の特定には至っていません。

一方で並列ストリーム（-P 8）では、AWS Interconnect が 3,297.3 Mbps、AWS Site-to-Site VPN が 2,443.9 Mbps と、AWS Interconnect が約 35% 上回りました。複数の TCP セッションを同時に利用することで、単一セッション時の制約が緩和され、より多くの帯域を活用できたものと考えられます。

実際の業務システムやデータ連携処理では、複数の TCP セッションが並行して通信するケースが一般的です。そのため、本検証結果からは、実運用に近い条件では AWS Interconnect がより高いスループットを発揮する可能性があることを確認できました。

ジッター:AWS Interconnect が明確に優れる

ジッター（遅延のばらつき）はAWS Interconnect が平均 0.004〜0.006 ms、AWS Site-to-Site VPN が 0.022 ms と、AWS Interconnect が約 4〜5 倍安定しています。

0.02 ms 台という絶対値は非常に優秀な数値ですが、リアルタイム通信（DB 同期・動画配信・音声通話など）においては安定性の差が積み重なって影響します。専用帯域のプライベートバックボーンを使う AWS Interconnect の優位性が数字に表れた結果です。

ユースケース別の選択指針

おわりに

本ブログでは、AWS と Google Cloud を繋ぐ2つの接続方式（AWS Site-to-Site VPN と AWS Interconnect）を実際に構築し、通信品質を比較検証しました。

今回の検証では、レイテンシおよびジッターの観点では AWS Interconnect が優れた結果を示し、並列ストリームによるスループット計測では AWS Interconnect が AWS Site-to-Site VPN を上回りました。一方で、シングルストリームのスループット計測では AWS Site-to-Site VPN の方が高い値となるなど、必ずしもすべての項目で AWS Interconnect が優位となる結果ではありませんでした。

このことから、接続方式の選定においては単純な性能比較だけでなく、通信パターンや求められる要件を踏まえて評価することが重要であると考えられます。特に、大量データの並列転送や通信品質の安定性を重視する場合には AWS Interconnect が有力な選択肢となる一方、導入の容易さや対応リージョンなども含めて総合的に判断する必要があります。

AWS Interconnect は 2026 年 4 月に GA となった新しいサービスであり、今後の対応リージョン拡大や機能強化も期待されています。マルチクラウド環境における接続方式の検討材料として、本ブログが参考になれば幸いです。

最後までお読みいただきありがとうございました。