セキュリティサービス部 佐竹です。
2025年11月30日（日本時間では12月1日）に発表された、マルチクラウド接続における新機能「AWS Interconnect - multicloud」について、Google Cloud 側の発表内容と合わせて「どのようなアップデートなのか」解説したいと思います。
- はじめに
- Google Cloud 側との「共同エンジニアリング」
- AWS 公式ドキュメント
- 技術的なポイントとメリット
- 接続アーキテクチャの解説
- どのような設定手順となるか確認する
- 想定されるユースケース
- 対応リージョン（Preview）
- プレビュー期間中の注意点
- 運用監視に関して
- 技術的な考慮事項
- まとめ
はじめに
AWS re:Invent 2025 がはじまったばかりですが、AWS より驚きのアップデートが発表されました。
「AWS Interconnect - multicloud」 のプレビュー公開です。名前に「マルチクラウド」の文字が入っているのが挑戦的であり、革新的です。
本アップデートを一言で説明すると、「AWS と他のクラウド事業者（CSP）を、専用線のような高品質・高セキュリティで、しかもマネージドサービスとして高速に接続する機能」です。
これまで、AWS と Google Cloud 間を閉域網で繋ごうとすると、Direct Connect や Partner Interconnect をそれぞれで契約し、回線事業者との調整や物理的な接続、VLAN ID の調整など、いわゆる「Do-it-yourself」なアプローチが必要でした。これにはネットワーク機器、物理回線の準備含めて、数週間〜数ヶ月かかることもありました。
専用線の代わりに AWS Site-to-Site VPN 等を利用してインターネット VPN 接続を CSP 間で実現する手もありましたが、閉域接続ではなくなります。
今回のアップデートは、この複雑さを解消し、数分で接続を完了させるものです。
本機能の最初のローンチパートナーは Google Cloud となっており、Microsoft Azure への対応は2026年後半が予定されています。
補足：「AWS Interconnect - last mile」も発表されましたが、本ブログでは last mile 側の話は記述していません。「last mile」については別のブログでまとめましたので、こちらも後程ご覧ください。
Google Cloud 側との「共同エンジニアリング」
この発表、他の CSP と共同のアップデートであるため、AWS 単独の発表ではありません。Google Cloud 側でも同タイミングで以下のブログが公開されています。
Google Cloud 側では 「Cross-Cloud Interconnect」 の拡張（今回は Cross-Cloud Interconnect for AWS）として発表されており、Google Cloud 側の記事では本機能開発を 「共同で設計された（jointly engineered と説明されているもの）」 ソリューションであるとも記載があります。
これまでは企業間の競争もあり、クラウド間の接続はユーザーが苦労して構築する部分でしたが、今回の協力関係によって「オープンな仕様」に基づいた相互接続が可能になりました。
AWS 公式ドキュメント
既に AWS 側ではサービス別の Web ページも用意されていました。
以下は公式ドキュメントへのリンクです。
技術的なポイントとメリット
さて、上記の AWS 公式ドキュメント（User Guide）の内容を確認すると、以下の特徴が見えてきます。Google Cloud 発表の内容とも合わせてまとめます。
1. 構築スピードの大幅な短縮
先にも記載した通り、最も大きなメリットはこの点でしょう。
これまで数日〜数ヶ月かかっていた物理的な回線調達や論理設定が、数分 に短縮されます。
ユーザーは物理的なルーターや物理接続について考える必要がありません。必要な帯域幅を選択し、接続先のリージョンを指定するだけで、AWS と Google Cloud が事前にプロビジョニングしたインフラストラクチャ上に接続が作成されます。
2. デフォルトでの高セキュリティ（MACsec）
セキュリティの観点で嬉しいのがこの点です。
2つのクラウドのエッジルーター間の接続は、IEEE 802.1AE MACsec によってデフォルトで暗号化されています。これにより、回線速度のパフォーマンスを維持したまま、物理層に近いレイヤで常時暗号化された通信が可能になります。
なお、この MACsec 暗号化はオプションではなく、「暗号化セッションがアクティブでない限り、顧客トラフィックを送信しない」という厳格な仕様になっています。これにより、設定ミスなどで誤って平文でデータが流れる事故を物理層レベルで防ぐ設計になっています。
これまでは Direct Connect の上にさらに IPsec VPN を張って暗号化する構成を取ることもありましたが、そのオーバーヘッドを気にする必要がなくなります*1。
3. 「4重」の冗長性（Quad-redundancy）
可用性については、冗長化が4重になっています。
関連した情報なのですが、以下「AWS Direct Connect の回復性に関する推奨事項」にも詳しく記載されている通り、「最大限の回復性」を担保するためには「4重」の専用線を用いた冗長化が推奨されます。
そして今回、Google Cloud と AWS のリージョン間接続には 「Quad-redundancy（4重冗長）」 が採用されます。これについては後ほど、アーキテクチャが公開されていますので、それも合わせて見ていきます。
接続アーキテクチャの解説
今回の「AWS Interconnect - multicloud」を理解する上で重要なコンポーネントと物理構成について、公開された画像を元に解説します。
抽象化された接続イメージ
まずは「論理的な」接続イメージです。
上図の通り、AWS 側と Google Cloud 側が「Cross-Cloud Interconnect」 というマネージドな土管で直結されているように見えます。ユーザーは中間の物理設備を意識する必要がありません。
4重の冗長化の実際
では、その裏側はどうなっているのでしょうか。
都合、AWS ユーザーガイド記載された図をそのまま拝借させて頂いていますが、こちらをご覧ください。中央の緑色の線がユーザーに見えている「Customer multicloud Interconnect」です。
本構成図とほぼ同じような構成で、もう少々詳細にしたバージョンが Google Cloud 側の資料にあります。これと合わせてみてみましょう。
どちらの構成図からも共通して記載されていることからもわかる通り、「Quad-redundancy（4重冗長）」 として以下が明らかです。
- 施設冗長: Facility 1 と Facility 2 に施設（ロケーション）自体が分かれている
- 機器冗長: 各施設内でルーターが二重化（冗長化）されている
- 経路: 合計4本の物理パス（Google CCI port ⇔ AWS DX port）が存在し、すべてが Encrypted (MACsec) で守られている
そしてこれらが自動的に構成されるため、（繰り返しになりますが）ユーザーが物理設計や配線管理を行う必要は一切ありません。
アタッチポイント（Attach point）
Interconnect は、両方のクラウド上の論理的なアタッチポイントに接続されます。
- AWS 側: Direct Connect Gateway がアタッチポイントとなります。
- Google Cloud 側: Cloud Router がアタッチポイントとなります。
既存の Direct Connect Gateway を流用することも可能です。これは既存の Direct Connect ユーザーにとっては導入のハードルが低くなる嬉しい仕様です。
Cloud WAN との連携もサポート
本機能は Direct Connect Gateway を介して、AWS のグローバルネットワークサービスである Cloud WAN にも対応しています。
これにより、単一のリージョンだけでなく、Cloud WAN のコアネットワークエッジ (CNE) を通じて、グローバル規模でのマルチクラウド接続が可能になる点は、大規模なグローバル展開をしている企業にとってもありがたいポイントではないでしょうか。
どのような設定手順となるか確認する
ドキュメントにある「Create your first multicloud Interconnect」の手順と「Multicloud Interconnect creation process」として掲載されている画像を眺めてみます。
ざっくりと流れを言うと、まず片方の CSP で「リクエスト」を作成し、発行されたキーを使ってもう片方の CSP で「承認（Accept）」するというフローとなっています。
設定の全体像
上図がセットアップのフロー図です。
- Customer creates new Interconnect: AWS コンソール（または Google Cloud 側のコンソール）で接続作成を開始します。
- AWS sends request: リクエストが相手側のクラウドへ送信されます。この時 「Activation Key」 が発行されます。
- Customer uses Activation key: ユーザーは発行されたキーを持って、相手側（Google Cloud）のコンソールへ行き、承認（Accept）操作を行います。
- Provisioning: 両クラウドが連携してプロビジョニングを完了させます。
Google Cloud 側の資料では、このプロセスが「Transport resource」の作成として gif 画像にてコマ送りで表現されています*2。
想定されるユースケース
どのような場面でこの機能が生きるのでしょうか。
AWS と Google Cloud で考えると、それぞれのクラウドサービスに得意サービス（売れているサービス、と言ってもいいでしょう）があります。
例えばデータ分析ではGoogle Cloud の BigQuery が有名ですね。そして、AWS にはデータレイクとして盤石な Amazon S3 があります。加えて、Amazon Aurora などのデータベースサービスも豊富です。分析においては、これらが連携する場面も多いでしょう。
上図は Google Cloud が用意した AWS との連携図です。Google Cloud としては以下のような AWS 間連携を想定しているでしょう。
- データ分析パイプライン: Google Cloud の Dataflow や BigQuery が、AWS 上の S3 バケットや Aurora からデータを直接プライベートに取得し、分析を行う構成。
- マルチクラウドアプリ: AWS 上の EC2 で動作するアプリケーションが、Google Cloud の Vertex AI の API を低遅延かつセキュアに呼び出す構成*3。
インターネットを経由せず、かつ自前で VPN や専用線を構築する手間もなく、これらが実現できるのは「マルチクラウド戦略」の敷居を大きく下げることになりそうです。
対応リージョン（Preview）
プレビュー期間中は、以下の5つのリージョンペアで利用可能です。基本的に「同じ場所（または近接した場所）」同士のリージョンがペアになっています。
| AWS Region | Google Cloud Region |
|---|---|
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 |
プレビュー期間中の注意点
最後に、プレビュー期間中の重要な注意事項です。
- コスト: プレビュー期間中、1アカウントにつき 1Gbps の接続を1つまで 無料 で利用できます。
- 本番利用: サービス規約上、本番トラフィック（production traffic）は流さないように アドバイスがあります。あくまで検証目的での利用に留めましょう。
- GA 後の扱い: 一般提供（GA）開始時に、プレビュー用の 1Gbps 接続は削除される旨の記載があります。原文では
At the time AWS Interconnect becomes Generally Available, any “preview” 1Gbps connections will be removed from your account.となっています。
特に「プレビュー用の 1Gbps 接続は削除される」については十分に念頭に入れて検証ください。
運用監視に関して
モニタリングの観点では、追加費用なしで以下の CloudWatch メトリクスが提供されます。
- ネットワークヘルス:
CloudWatch Network Synthetic Monitorが各接続に1つ含まれており、レイテンシやパケットロスを監視可能です。 - 帯域幅使用率: 使用率（Bandwidth utilization）メトリクスも提供されるため、アラームを設定してキャパシティプランニングを行うことが可能です。
技術的な考慮事項
導入や設計時に押さえておくべき技術的な制約や仕様についても、ドキュメントに記載されています。重要と思われる点だけ抜粋しています。
- 受信プレフィックスの上限: Google Cloud 側から受信できるプレフィックス（経路）数は、IPv4 で 1,000、IPv6 においても 1,000 までという制限があります。
- MTU サイズ: AWS 側の MTU（Maximum Transmission Unit）は自動的に 8500 に設定されます。AWS Direct Connect で一般的なジャンボフレーム（9001）とは異なる値となるため、設計時には注意が必要です。
- 既存 Direct Connect Gateway との共存: 既に Private VIF や Transit VIF がアタッチされている既存の Direct Connect Gateway に、今回の Multicloud Interconnect を追加でアタッチすることが可能です。既存の専用線接続環境を維持したまま、同一の Gateway を使用してマルチクラウド接続を追加できるため、柔軟な構成が可能です。
まとめ
本日は AWS と Google Cloud の大規模コラボとも言える「AWS Interconnect - multicloud」について、公式ユーザーガイドと Google Cloud ブログの図解を元に詳細を解説しました。
クラウドの活用において、ネットワークの敷設は手間と時間がかかり、また失敗が許されないプロジェクトとなることから、その準備や調達はシビアなものになりがちです。苦労された経験をお持ちの方も多いのではないでしょうか。
クラウド（CSP）間の連携において、このようなコラボレーション機能が登場することは、業界にとって非常にポジティブな前進になると私は感じます。しかも、Google Cloud は AWS re:Invent 2025 に合わせてくれているわけですから、両社の歩み寄りを感じます。
弊社グループには Google Cloud 専業の「株式会社G-gen」もございますので、今後 AWS Interconnect - multicloud を実案件で活用し、マルチクラウドアーキテクチャを作り上げる機会もあるかもしれない、と期待を寄せつつ本ブログを終わりにしたいと思います。
では、またお会いしましょう。
*1:この構成は AWS Certified Advanced Networking - Specialty 認定試験で稀に問われるポイントです
*2:gif なこともあり、こちらに転載することは避けました
*3:旧 AI Platform
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
