この記事の概要
2026年4月にGAとなった AWS Interconnect – multicloud を使うと、AWS VPCとGoogle Cloud VPCをマネージドなプライベート接続で結べます。VPNもコロケーションも不要で、コンソール操作と数行のCLIだけで数分以内に接続が確立します。本記事では仕組みと設定手順、注意点を一通り解説します。
AWSとGCPをプライベート直結できる時代が来た
「AWSとGCPを安全に繋ぎたいけど、やり方が複雑すぎて……」という悩みは多くのインフラSEが感じてきたはずです。
これまでのマルチクラウド接続は、VPNトンネルを自前で張るか、コロケーション経由の物理クロスコネクトを手配するかのどちらかで、どちらも「ネットワーク専門チームが週単位で対応する」案件でした。
AWS Interconnect – multicloud はその状況を変えます。
AWSコンソールとGCPのCLI操作だけで、10分以内にプライベートで暗号化された専用回線が確立できます。
なぜVPN方式ではもう限界なのか
従来のマルチクラウド接続の課題は3点に集約されます。
① VPNは公衆インターネットを経由するためレイテンシが不安定
② BGP・IPsec等の設定が複雑で属人化しやすい
③ Direct Connect経由で他クラウドに接続するにはコロケーション施設でのクロスコネクトが必要でリードタイムが数ヶ月に及ぶ
こういった状況です。
AWS Interconnect – multicloud はこれらをまるごと解決します。
トラフィックはAWSとGCP双方のプライベートバックボーンのみを通り、公衆インターネットには出ません。
物理リンクにはMACsec暗号化が自動適用され、4重冗長構成でルート伝播も自動です。
実際にAWS VPC ↔ Google Cloud VPCを接続してみる
それでは実際の設定手順を追ってみましょう。
前提として、AWSにDirect Connect Gateway（DXGW）が作成済みで、両VPCのCIDRが重複していないことを確認してください。
アーキテクチャ全体像
graph LR
subgraph AWS
VPC[AWS VPC\n172.31.0.0/16]
VGW[Virtual Private Gateway]
DXGW[Direct Connect Gateway]
IC[AWS Interconnect]
end
subgraph GCP
Transport[Transport VPC\n自動生成]
GCPVPC[Google Cloud VPC\n10.156.0.0/20]
end
VPC --> VGW
VGW --> DXGW
DXGW --> IC
IC <--> Transport
Transport --> GCPVPCSTEP 1: AWSコンソールでInterconnectを作成する
AWSマネジメントコンソールで Direct Connect → AWS Interconnect → Create を開きます。
- クラウドプロバイダーとして Google Cloud を選択
- AWSリージョンとGCPリージョンを選択（例：`ap-northeast-1` と `asia-northeast1`）
- 帯域幅・Direct Connect Gateway・GCPプロジェクトIDを入力して確定
完了すると アクティベーションキー が払い出されます。このキーをGCP側の設定に使います。
**注意：** 2026年5月時点では米国・欧州5リージョンペアのみ対応。**東京リージョンは未対応**です。
STEP 2: GCP側でトランスポートリソースを作成する
アクティベーションキーを使い、GCPのCLIでTransportとVPC Peeringを作成します。
# トランスポートの作成
gcloud network-connectivity transports create my-aws-transport \
--region=asia-northeast1 \
--activation-key=${ACTIVATION_KEY} \
--network=default \
--advertised-routes=10.156.0.0/20
# VPC Peeringの設定（上記コマンドの出力に含まれるpeeringNetworkを使用）
gcloud compute networks peerings create my-aws-peering \
--network=default \
--peer-network=projects/<PROJECT_ID>/global/networks/transport-xxxxxx-vpc \
--import-custom-routes \
--export-custom-routes数分後にGCPコンソールのVPC Network Peeringに ACTIVE ステータスが表示されれば成功です。
STEP 3: AWSのVPCルートテーブルを更新する
AWSコンソールでDXGWにVirtual Private Gateway（VGW）を関連付けた後、AWS VPCのルートテーブルにGCP向けルートを追加します。
送信先: 10.156.0.0/20
ターゲット: <Virtual Private Gateway ID>GCP側のルート伝播は自動ですので、追加作業は不要です。
設定前に必ず確認したい3つの落とし穴
① CIDRの重複は絶対NG
AWS VPCのデフォルト 172.31.0.0/16 とGCP VPCのデフォルト 10.156.0.0/20 はたまたま重複しませんが、カスタムVPCでは要注意です。
接続前に必ず両サイドのCIDR範囲を確認してください。
② MTUの不一致に注意
AWSとGCPではデフォルトのMTUが異なります。
不一致のままだとパケットの断片化が起き、スループット低下や切断の原因になります。接続確立後はMTU設定を合わせましょう。
③ 暗号化はリンク単位
MACsecはAWSとGCPの物理接続点のみに適用されます。
各クラウドの内部バックボーン上の暗号化は各社の仕様に依存するため、コンプライアンス要件がある場合はTLS等の追加暗号化も検討してください。
実務でどう使うか：3つのユースケース
ユースケース1：データ分析基盤のハイブリッド構成
AWS S3にデータを蓄積しつつ、BigQueryの機械学習機能も活用したいチームに最適です。
プライベート接続なのでデータ転送コストを抑えながら安定したスループットを確保できます。
ユースケース2：DR（災害対策）構成
AWS東京をメインに、GCPの別リージョンをDR先にする構成で使えます。
が保証されるためRPOの精度が上がります。
現時点では東京リージョン未対応のため、シンガポール等を経由する暫定構成が必要です。
ユースケース3：組織横断のマルチクラウド環境
インフラチームがAWS、データサイエンスチームがGCPを使うなど、組織的経緯でマルチクラウドになっているケースのバックプレーンとして機能します。
AWS Interconnectを今すぐ試すための3ステップ
- 利用可能リージョンの確認 — 現時点では米国・欧州の5ペアのみ。東京リージョン対応は公式発表待ち
- コスト試算 — 帯域幅×稼働時間のフラット課金。GBあたり転送料金なし。料金ページで事前に見積もりを
- 小さなPoC環境から — 500Mbps接続からスタートし、実際のレイテンシと帯域を計測した後にサイジングを決めるのがおすすめ
まとめ
AWS Interconnect – multicloud は、これまで「ネットワーク専門チームが週単位で格闘していた」マルチクラウド接続を、インフラSEが自分で数十分で設定できる作業に変えたサービスです。
暗号化・冗長化・監視がデフォルトで組み込まれており、運用負荷も大幅に下がります。
Azureサポートは2026年後半に予定されており、東京リージョン対応もそう遠くないはずです。
今のうちにアーキテクチャの検討を始めておくと、対応リージョンが増えた瞬間にすぐ動けます。
コメント