インフラ担当の小林匠です。
先日のAWS Summit Japan 2026 にて、「Advanced VPC Networking - 知っておきたいAWSネットワークの最新動向」というセッションを聴講しました。
毎年AWSネットワーク関連のアップデートはスケールが大きくなっており、採用する選択肢が多くなってきたことから、実現したい要件に対して対応できる幅が広がっています。
さて、今回そのセッションの中で、AWSとGoogle Cloudを例にプライベートに直結するAWS Interconnect multicloudが紹介されておりました。2025年11月にプレビューの発表されたとき、現在AWS・GCP双方の案件を担当している身としては、まさに自分ごととして捉えるべきアップデートだと感じました。
本記事では、このサービスの仕組みと既存の接続手段との比較を整理した上で、コストシミュレーションに加え、可用性・セキュリティ・既存ネットワーク資産との統合といった技術的な観点を洗い出し、採用判断の材料とします。
検証コストの観点から実機構築は見送りましたが、料金体系や設計制約を正しく読み解くことそのものが設計判断の核心だと考えているので、その過程を共有させていただきます。
どなたかのお力になれたら嬉しいです。
AWS Interconnect multicloudとは
AWS Interconnect multicloudは、Amazon VPCを他クラウドプロバイダーのネットワークと直接接続するマネージドサービスです。2026年4月に一般提供が開始され、現在はGoogle Cloudが最初の接続先として利用可能(OCIも一部利用可能)、Microsoft Azureは2026年後半に対応予定とされています。
従来、AWSと他クラウド間でプライベート接続を構築するには、コロケーション設備でのDirect Connect構築や、サードパーティのネットワークファブリックを介した接続など、相当のリードタイムと運用負荷を伴う手段しかありませんでした。
AWS Interconnect multicloudでは、AWS側にDirect Connectゲートウェイ、Google Cloud側にCloud Routerを用意するだけで、コンソール操作のみで接続が完了します。
既存の接続手段との比較
前提として、このアップデートの良さを理解するには、既存の選択肢との違いを整理する必要があります。
| 接続手段 | 構築の手間 | データ転送料金 | 主な用途 |
|---|---|---|---|
| Cloud VPN | 低い | 通常課金 | 低帯域・低コスト優先 |
| Direct Connect + パートナー接続 | 高い（物理回線の手配が必要） | 通常課金 | オンプレミス含む複雑な構成 |
| Google Cloud Cross Cloud Interconnect | 中（冗長構成は自前で設計） | 双方向で課金（1GiBあたり0.020ドル） | 大容量・固定帯域 |
| AWS Interconnect multicloud + Partner CCI for AWS | 低い（コンソール操作のみ） | データ転送料金なし | マルチクラウドでの持続的な通信 |
ここで重要なのが、AWS Interconnect multicloud、およびGoogle Cloud側で対になるPartner Cross Cloud Interconnect for AWSは、帯域に対する時間課金のみで、データ転送量による課金が発生しないという点です。
従来のクラウド間接続の転送量が増えるほどコストが膨らむという構造とは異なり、定額パッケージのため帯域の上限まで使い切るほど単価的には下がる料金特性を持っています。
ルーティング設計のポイント
接続を実現するうえで、技術的に押さえておくべきポイントが2つあります。
Direct ConnectゲートウェイとVGWの対応関係
AWS側では、AWS Interconnectと同じAWSリージョンに仮想プライベートゲートウェイ（VGW）を用意し、Direct Connectゲートウェイに関連付けます。 既存のDirect Connect構成を持つ環境に追加する場合、インターコネクトと同じリージョンのVGWを使っているかを必ず確認する必要があります。
ここでリージョンを跨いだVGWを誤って関連付けてしまうと、ルーティングが期待通りに機能しません。
クロスリージョン接続は単一構成では不可
AWS Interconnect multicloudは、2026年6月現在は米国・欧州・アジアの6つのリージョンペアでのみ利用可能です。
たとえば東京リージョンのVPCをGoogle Cloudへ直結したい場合、単一のインターコネクトでは構成できず、対応リージョン経由でのルーティングや、AWS Cloud WANとの組み合わせを検討する必要があります。 これは見落としやすい前提制約のため、実案件で検討する際は最初に確認すべき項目だと考えます。
VPCルートテーブル側では、GCPのIPアドレス範囲へのトラフィックをVGW経由で送信するよう、ルートエントリを明示的に追加します。Google Cloud側でネットワークルーティングの追加設定が不要な点は、運用上のシンプルさに直結しています。
コストシミュレーションでどれくらいの規模から採用すべきか
ここからが本記事の核心の一つです。想定できる損益分岐点を計算することで、採用判断の材料を得られます。ここではAWS・Google Cloud公式の料金ページに基づいて算出します。
前提条件
AWS Interconnect multicloudは、帯域とリージョンペアの組み合わせで決まるTier制の時間課金です。
例えば、AWS us-east-1からGoogle Cloud us-east4への10Gbps接続はTier1料金が適用され、1時間あたり12.33ドル、730時間/月でおよそ9,000.90ドルとなるとされています。
データ転送量による課金は一切発生しません。また、各リージョン・各CSPごとに500Mbpsまでの接続を1つ無料で利用できます。
対するGoogle Cloud側のPartner Cross Cloud Interconnect for AWSも、トランスポートリソースに対する時間課金のみで、データ転送料金は発生しません。北米・欧州リージョンでは10Gbpsが1時間あたり19.00ドル、730時間でおよそ13,870ドルといったところです。
一方、従来からあるGoogle Cloud標準のCross Cloud Interconnectは、接続自体の時間課金に加えて、データ転送量に応じた課金（1GiBあたり0.020ドル）が双方向に発生します。
損益分岐点の考え方
仮に月間のAWS⇔GCP間の双方向トラフィックを想定すると、データ転送料金が発生する従来構成では転送量に比例してコストが増加する一方、AWS Interconnect multicloudは帯域使用量に関わらず固定費です。
これに対して従来のCross Cloud Interconnectは、データ転送料金が上乗せされるため、転送量が一定のラインを超えると、固定費型の新方式のほうが安くなるという構造になります。
具体的な例で計算してみます。
10Gbpsの帯域で、月間50TBのデータをAWSとGoogle Cloud間で転送するケースを想定してみます。
• AWS Interconnect multicloud + Partner CCI for AWS
帯域固定費のみで、AWS側約9,000.90ドル + Google Cloud側約13,870ドルで、合計約22,871ドル/月（転送量に関わらず一定）
• 従来のCross Cloud Interconnect（データ転送課金あり)
接続の固定費に加え、50TB（約51,200 GiB）×0.020ドル×双方向で、データ転送料金だけで約2,048ドルが上乗せされる
転送量が増えるほど従来方式との差額は拡大するため、継続的に大容量データを転送する用途では、新方式の固定費構造が活きてきます。 逆に、月数百GB程度の小規模なバッチ連携であれば、無料枠の500Mbpsで足りるケースも多く、コストをかけて大容量帯域を確保する必要はありません。
想定トラフィック特性と推奨される接続手段について、こんなイメージです。
| トラフィック特性 | 推奨される接続手段 |
|---|---|
| 低頻度・小容量のバッチ連携 | Cloud VPN |
| 持続的な中〜大容量データ連携 | AWS Interconnect multicloud |
| すでにDirect Connect環境がある複雑な構成 | Direct Connect + パートナー接続 |
| 超大容量（10Gbps以上）で確定的な帯域が必要 | Google Cloud Cross Cloud Interconnect |
AWS Interconnect multicloudは帯域をコンソールから再プロビジョニングなしで変更できるため、データ移行のような一時的な大容量転送が必要な期間だけ帯域を上げ、その後に下げるという柔軟な運用も一つの手かもしれません。
コスト以外に確認すべき技術的観点
新しいから良い、安いから良いという単純な判断ではなく、コストと並列で確認すべき技術的観点を洗い出しておきます。 これらを検討事項として確認した上で採用を判断したいところです。
1.可用性・冗長性の設計が標準モデルに収まるか
AWS Interconnect multicloudは、複数の物理ロケーションにわたる4重の冗長性が標準で組み込まれています。これは自前で冗長構成を設計する手間を省ける利点である一方、裏を返せば標準モデル以外の冗長設計を選べないという制約とも言えます。
すでにDirect Connectで独自の冗長構成（複数プロバイダー、複数ロケーションの組み合わせ）を組んでいる環境に追加する場合、標準の冗長モデルが自社の可用性要件（RTO/RPOや、特定ロケーション障害時の切替方針）に対して過不足がないかを確認する必要があります。
2.セキュリティ・暗号化方式が統制方針に合うか
通信はIEEE 802.1AE MACsecによる暗号化が標準で適用され、パブリックインターネットを経由しません。
セキュリティ観点では強みですが、暗号化方式やキー管理がAWS・Google Cloud側にお任せする形になるため、「自社で暗号鍵を管理したい」「特定の認証基盤や監査ログ要件と統合したい」といったセキュリティポリシーがある場合は、既存のVPN/Direct Connect構成との比較検討が必要になります。
3.既存のネットワーク資産（Transit Gateway、Cloud WAN）への統合パターン
Direct ConnectゲートウェイをVGWに直接アタッチする単一VPC構成のほか、Transit Gatewayによるリージョン単位の集約、Cloud WANによるグローバルなネットワーク統合という複数の参照アーキテクチャが用意されています。
すでに複数VPC・複数リージョンでTransit Gatewayベースのハブアンドスポーク構成を運用している環境では、新たに追加するルートがどのVPCまで伝播すべきか、意図しないVPCからGCPへ到達可能になっていないかといった、ルートテーブル設計とセグメンテーションの見直しが発生します。単一VPC構成への追加と比べて、設計・検証の工数は大きく変わってきます。
4.運用監視・トラブルシューティングの体制
AWS Interconnect multicloudには、CloudWatchのNetwork Synthetic Monitorが標準で付属し、レイテンシやパケットロスを監視できます。
一方で、Google Cloud側を含めたエンドツーエンドの通信経路で問題が発生した際、どちらの管轄で何を確認すべきかという運用フローを事前に整理しておく必要があります。 AWS・GCP双方の監視ツールを横断して見る体制が既にあるか、これから整備が必要かは、運用負荷に直結する大事な観点です。
5.対応リージョンの制約と今後のロードマップ
前述の通り、現時点では6つのリージョンペアに限定されています。メインの稼働リージョンがこれに該当しない場合、Cloud WAN等を介した迂回構成が必要になり、レイテンシやコストの面で当初の狙いから外れる可能性があります。
対応リージョンの拡大時期が明示されていない以上、現状の制約を前提とした上で採用を判断する必要があります。
それでも採用が難しいケースについて
ここまでの技術的検討観点をすべてクリアしたとしても、実際の採用判断では別の事情が絡むことがあります。
例えば、社内のセキュリティ統制部門が「新しいマネージドサービスは一定期間の実績を見てから採用する」というような方針を持っている場合や、すでに既存のネットワーク構成に対して大きな投資を行っており、構成変更そのものの社内承認プロセスがハードルになる場合、あるいは契約上の都合で特定ベンダーのネットワーク機器・サービスの利用が定められている場合などが考えられます。
こうした企業固有のガバナンスや既存資産への投資状況は、技術的な優劣だけでは測れない採用見送りの理由になり得ます。 技術検討を網羅した上で、最終的な採用判断には組織固有の事情も加味する必要がある、という前提は持っておきたいところです。
採用判断のフレームワーク
AWS・GCP双方の案件を担当する立場として、このサービスが効果を発揮しそうな要件をいくつか想定してみました。
1点目は、GCP上のBigQueryやAWS上のRedshiftなど、分析基盤同士のデータ連携を継続的に行う要件です。ETL処理で双方向に大容量データを転送するケースでは、データ転送料金が発生しない料金構造の恩恵が大きくなります。
2点目は、片方のクラウドで生成AIサービスを利用し、もう片方のクラウドにあるプライベートなデータソースへアクセスする要件です。データをパブリックインターネット経由でやり取りすることへのセキュリティ懸念を抱えるプロジェクトでは、プライベート接続そのものに価値があります。
3点目は、マルチクラウド戦略を前提に、特定ベンダーへの依存を避けたい要件です。構築の手間が小さいぶん、将来的な接続先の見直しや拡張にも追従しやすいという利点があります。
一方で、現状は対応リージョンが限定的なため、東京リージョンをメインとする案件では、前提としてリージョン制約が採用のハードルになる点は言うまでもありません。 もしくは、東京リージョンがGAとなる日を待つとしましょう。
まとめ
AWS Interconnect multicloudは、データ転送料金が発生しない固定費型の料金構造により、従来のクラウド間接続の常識を変えるアップデートだと感じました。
ただし、コストシミュレーションだけで採用を決めるのではなく、可用性設計が標準モデルに収まるか、セキュリティ統制方針と合うか、既存のネットワーク資産にどう組み込むか、運用監視体制をどう整えるか、対応リージョンの制約をどう乗り越えるかなど、これらを技術的観点として網羅的に洗い出した上で、最終的には企業固有のガバナンスや投資状況も踏まえて判断する、という段階を踏むのが実務における導入判断のあり方だと考えます。
私自身、AWS・GCP双方の案件に関わる中で、こうしたマルチクラウド接続の選択肢が増えていくことは、今後のアーキテクチャ設計の幅を広げてくれるはずだと思っています。
対応リージョンの拡大やその他対応クラウドサービスのサポート開始など、今後の展開も注視していきたいですね。
