AWS Interconnect – multicloudは、Amazon VPCと他社クラウドのVPCをマネージドなプライベート接続で直結する仕組みです。2026年4月14日に一般提供が始まり、8月24日時点でGoogle Cloud向け8リージョンペア、OCI向け1ペアが提供されています。本記事では対応リージョンの実態、Tier構造の時間課金と500Mbpsの無料枠、Direct Connect gatewayとの役割分担、東京・大阪が対象外である現況の扱いを公式ドキュメントに沿って整理します。
まとめ：日本国内の案件で今すぐ採用できるかの結論
結論から書きます。2026年8月24日時点で東京（ap-northeast-1）と大阪（ap-northeast-3）は対応リージョン一覧になく、国内のVPCと他クラウドを閉域で直結する用途には選べません。AWS Cloud WANを挟めば東京から米国のInterconnectへ到達できますが、課金Tierが上がり物理距離ぶんの遅延も乗ります。
一方、米国東西・ロンドン・フランクフルト・ストックホルム・シンガポール・シドニーのいずれかにワークロードがあるなら、判断は前向きでよいはずです。数週間かかっていた回線調達とBGP設定が数分のコンソール操作に置き換わり、帯域は1Gbpsから100Gbpsまで後から増減できます。一般提供済みのクラウドごとにローカル500Mbpsが1本無料で使えるため、まずつないで測るのが安いのです。
役割分担も押さえておきます。この機能はAWS Direct Connectを置き換えません。AWS側のアタッチポイントは常にDirect Connect gatewayで、既存の閉域網設計の上に接続方式が1つ増えたと捉えるのが正確です。
マネージドL3接続としての位置づけとDirect Connectとの役割分担
物理ルータもクロスコネクト発注もBGP設定も不要になる作業範囲
AWS Interconnectは、AWSリージョン・必要な帯域・接続先を選ぶだけで、AWSと接続先の事業者が冗長構成の機器上に回線をプロビジョニングする仕組みの総称です。ユーザーガイドは、物理ルータや仮想ルータの設定、クロスコネクトの発注、BGPピアリング管理がいずれも不要になると明記します。
プロビジョニングは通常数分で完了し、開通後の帯域変更もコンソールから行えます。従来は両クラウドの相互接続拠点を調べ、通信事業者と個別契約し、VLAN IDを突き合わせ、双方でBGPを組む工程が必要でした。この一連がサービス側に吸収されています。
アタッチポイントがDirect Connect gatewayに固定される構成上の意味
AWS側のアタッチポイントは、常にDirect Connect gateway（DXGW）です。DXGWはデータ経路の外側に置かれるグローバルな論理オブジェクトで、その先にVirtual Private Gateway、Transit Gateway、AWS Cloud WANのいずれかをぶら下げます。専用線そのものの仕組みと料金体系はAWS Direct Connectの専用線接続とVPNとの違いを整理した解説で扱っているため、ここでは重複を避けます。
分かれ目は到達範囲にあります。Virtual Private GatewayとTransit Gatewayはリージョナルなサービスのため、Interconnectと同じローカルリージョンからしか使えません。Cloud WANだけがグローバルで、同じDXGWに紐づく世界中のInterconnectへ到達できます。複数VPCを束ねる設計の考え方はAWS Transit GatewayとVPC Peeringの違いを解説した記事と共通です。
multicloudとlast mileという2つのオファリングの使い分け
AWS Interconnectは2種類あります。multicloudはAWSのVPCと他社クラウドのVPCをつなぐもの、last mileは支社やデータセンターをパートナー事業者の既設回線経由でAWSにつなぐものです。後者は2026年8月時点でLumenとの提供がus-east-1（バージニア北部）で始まり、AT&TとMegaportは準備中とされています。オンプレミス側の回線を引き直す話なら後者、クラウド間だけをつなぐ話なら前者を選びます。
対応リージョンペアと接続先クラウドの現況、東京・大阪リージョンの扱い
Google Cloud向け8ペアとOCI向け1ペアの対応リージョン一覧
AWSのユーザーガイドが公開しているRegional Availabilityは以下のとおりです（2026年8月24日時点）。
| 接続先 | AWSリージョン | 接続先リージョン |
|---|---|---|
| Google Cloud | us-east-1 | us-east4（バージニア北部） |
| Google Cloud | us-west-1 | us-west2（ロサンゼルス） |
| Google Cloud | us-west-2 | us-west1（オレゴン） |
| Google Cloud | eu-west-2 | europe-west2（ロンドン） |
| Google Cloud | eu-central-1 | europe-west3（フランクフルト） |
| Google Cloud | eu-north-1 | europe-north2（ストックホルム） |
| Google Cloud | ap-southeast-1 | asia-southeast1（シンガポール） |
| Google Cloud | ap-southeast-2 | australia-southeast1 |
| OCI | us-east-1 | us-ashburn-1（アッシュバーン） |
提供開始は段階的でした。全体の一般提供が2026年4月14日、OCIは同年5月15日にパブリックプレビュー、7月29日に一般提供という順です。Google Cloud向けは5ペアから8ペアに増えており対応範囲は動くため、要件定義の時点でユーザーガイドを見直してください。OCI側のデータベースをAWSから使う話なら、閉域接続とは別にOracle Database@AWSでExadataやAutonomous Databaseを利用する選択肢も比較対象に入ります。
東京・大阪が対象外という現況とCloud WAN経由で到達する回避策
一覧のとおり、ap-northeast-1とap-northeast-3は含まれていません。国内のAWSリージョンから他クラウドの国内リージョンへ、この機能で閉域接続を張ることは現時点でできません。
回避策は1つあります。Cloud WANのCore Networkに東京のCore Network Edge（CNE）を置き、同じDXGWにus-east-1のInterconnectを紐づける構成です。ユーザーガイドはこの形をサポート構成として説明しています。
ただし代償があります。後述のTier課金が上がり、太平洋を往復する物理距離ぶんの遅延も乗るのです。ユーザーガイド自身が「ローカルのTransit Gatewayだけに紐づく1Gbps接続は、東京にプロビジョニングしてus-east-1のCNEに到達する構成より安い」という例を挙げています。国内向けの応答時間要件がある本番系には向きません。
Azureの提供予定とプレビュー中クラウドに課される1Gbps制約
Microsoft Azureは2026年後半の提供予定とアナウンスされており、8月24日時点では対応リージョン一覧に登場しません。Azureとの閉域接続が必須の案件は、今期の設計にこの機能を織り込まないでください。
プレビュー段階のクラウドを試す場合の制約も明文化されています。プレビュー中は顧客あたり・対応リージョンあたり1本まで、帯域は1Gbps固定、期間中の利用料は無償です。そして一般提供が近づくとプレビューの1Gbps接続はアカウントから削除され、その期間は当該クラウド向けの新規作成もできません。検証には使えますが、この上に運用を組み立てると必ず作り直しになります。
Tier課金と500Mbps無料枠から逆算する帯域とコストの設計
帯域と地理的スコープの2入力で決まる時間課金と、データ転送の非課金
課金は、選んだ帯域と接続の地理的スコープという2つの入力だけで決まります。1時間単位で計算され、転送データ量への別料金はありません。オンプレミス接続で悩みがちなアウトバウンド転送量の見積もりが、料金計算から外れる形です。
帯域の選択肢はリージョンと接続先の組み合わせごとに決まり、Google Cloud向けは1Gbpsから100Gbpsまでの事前承認済みの刻みが用意されています。開通後もコンソールから増減できるため、ピーク期だけ引き上げ平常時は落とす運用が成立します。
Tier1からTier5まで自動昇格する仕組みと設計上の落とし穴
地理的スコープはTierという5段階で表されます。Tier1がローカル、Tier2が同一地域内のリージョナル、Tier3が大陸内、Tier4が大陸をまたぐロングホール、Tier5が最大スコープです。
注意すべきは、Tierが「利用者の宣言」ではなく「到達しうる経路の実態」で決まる点です。Interconnectは、ワークロードのあるリージョンとの間の全経路を含むもっとも低いTierへ自動的にサブスクライブされます。
ユーザーガイドの例が分かりやすいでしょう。オレゴンにInterconnectを置きバージニア北部にもCNEがあるとTier2、ここにフランクフルトのCNEを足すと接続全体がTier3へ上がります。ネットワーク担当以外の誰かがCore Networkにリージョンを1つ足しただけで既存Interconnectの単価が変わるため、用途の異なる接続はDXGWを分けて設計しておくのが安全側の判断です。
500Mbps無料枠の3つの適用条件と、相手クラウド側に残る課金
一般提供済みのクラウドごと・AWSリージョンごとに、ローカル（Tier1）の500Mbps接続を1本、無料で使えます。コンソールの「AWS Interconnect – multicloud – Free Tier」から作成でき、速度は500Mbpsが選択済みの状態で作成フローに入ります。
ただし条件が3つあります。無料枠の接続は後から有料接続に変換できません。無償なのはAWS側だけで、接続先クラウドは自社の料金体系で独立に課金します。さらに500Mbpsが相手クラウド側のクォータ対象になっている場合があるため、作成前に残枠の確認が要ります。それでもPoCの入口としては使い得でしょう。
Google Cloud側の対応名称と従来方式から変わった6つの点
Cross-Cloud Interconnectとの差分に見る、開通期間と帯域刻みの違い
Google Cloud側での名称はPartner Cross-Cloud Interconnect for AWSです。Google Cloudのドキュメントは、これを従来のCross-Cloud Interconnectの発展形と位置づけ、次の差分を挙げます。
| 観点 | Cross-Cloud Interconnect | Partner CCI for AWS |
|---|---|---|
| 物理プロビジョニング | 必要 | 不要 |
| 物理ポートの手配 | 必要 | 不要 |
| 帯域の刻み | 10Gbpsまたは100Gbps | 1Gbpsから100Gbps |
| 開通までの期間 | 1週間から4週間 | 数分 |
| 発注の起点 | Google Cloud側のみ | 双方向 |
| 冗長構成 | 手動で構成 | 製品に組み込み済み |
実務でいちばん効くのは帯域の刻みです。従来は10Gbps単位でしか買えず、数百Mbpsで足りるバッチ連携でも過剰な容量を抱える必要がありました。1Gbps刻みなら、小さく始めて実測値に合わせて広げる進め方が取れます。クォータはプロジェクトあたり・リージョンあたり1トランスポートリソースが既定です。
Apache-2.0で公開されたAPI仕様と、接続先クラウド拡大の見通し
AWSはこの仕組みの土台となる仕様を、GitHubのaws/Interconnectリポジトリで公開しています。マネージドなL3接続を調停する対称APIをOpenAPI 3.0で記述したもので、ライセンスはApache-2.0です。
ここから読み取れるのは、接続先の拡大が個別提携の交渉ごとではなく、仕様を実装してAWSの運用要件を満たせるかで決まる設計だという点です。Azure待ちの案件なら、提携報道より仕様準拠のアナウンスを追うほうが実装時期の見通しは立てやすいでしょう。
アクティベーションキー方式の作成フローと冗長・暗号化の内部構造
AWSコンソールでの作成手順と、アクティベーションキーの交換フロー
作成はDirect Connectコンソールから始めます。
- 接続先クラウドを選ぶ（プレビュー中はカードにPreviewタグが付く）
- 送信元のAWSリージョンと宛先リージョンを選ぶ
- 帯域とDXGWを指定し、相手クラウドでの自社IDを入力する
- 要求を送り、表示されたアクティベーションキーを受け取る
- 相手クラウド側でそのキーを使い、作成を完了させる
相手クラウドでのIDは事業者ごとに形式が違います。Google Cloudは6文字から30文字の英数字とハイフンからなるプロジェクトID、OCIはocid1.tenancy.oc1形式のTenancy OCIDです。相手クラウド側から作成された接続を受け入れる場合は、コンソールの受入フローにキーを貼り付けてDXGWを指定します。プレビュー中の事業者では、受入操作にCLIが必要になるとされています。
4本のリンクとECMPで構成される冗長性と、2施設分散という前提
冗長構成は利用者が設計する対象から外れています。すべてのInterconnectは、独立した電源とネットワークを持つ物理的に別々の2施設以上にまたがる冗長デバイス上へプロビジョニングされ、multicloudとlast mileはいずれも4接続モデルとEqual-Cost Multi-Path（ECMP）で負荷分散します。計画メンテナンス中でも最低1本のリンクが生きている状態が保たれ、コンソールには抽象化された単一のInterconnectオブジェクトだけが見える構成です。
MACsecによる既定の暗号化とアカウント単位のクォータ上限
AWSの機器と隣接するパートナー機器の間の接続は、すべて既定で暗号化されます。方式はIEEE 802.1AE、いわゆるMACsecです。機器は暗号化セッションが有効なときだけ顧客トラフィックを転送する設定のため、暗号化なしで通信が流れる状態そのものが存在しません。
クォータは4種類あります。アカウントあたりの作成済み接続が最大10、requested状態で滞留できる接続が最大4、multicloud接続とlast mile接続はいずれもプロバイダあたり2です。プロバイダあたり2という上限は、同じ相手クラウドに用途別の接続を並べる設計に効くため、初期設計で数えておきたい部分です。なお経路交換は自動化されていますが、DXGW配下の経路数にはDirect Connect側の制約が引き続き効きます。設計上の上限はAWS Direct Connectの100ルート問題とBGP経路数の回避策で扱った内容がそのまま当てはまります。
マルチクラウド案件で採用してよい条件と、見送るべき場面の具体的な線引き
ここまでの事実を発注判断に落とします。
採用してよい条件は、対応リージョンペアと可変帯域と自社テナント管理
次の3つがそろっているなら、採用してよいと判断します。第一に、双方のワークロードが前掲の9ペアのどれかに収まっていること。第二に、必要帯域が1Gbpsから100Gbpsの範囲で、しかも変動が見込まれること。第三に、接続先クラウドのテナントを自社が管理し、プロジェクトIDやTenancy OCIDを即座に用意できることです。
この条件下では従来数週間かかっていた工程が数分に縮み、500Mbpsの無料枠で先に疎通と実効スループットを測れます。判断材料を揃えるコストがほぼゼロなのだから、迷うより一度つないだほうが早いのです。
見送るべき場面：国内レイテンシ要件・Azure必須・既設10Gbps超
逆に、次の4条件に当てはまる案件では採用しません。
- 東京・大阪のVPCと国内の他クラウドを閉域で結ぶ要件。Cloud WAN迂回は遅延とTier昇格の二重の代償を払う
- Azureとの閉域接続が必須で今期中に本番稼働させる要件。提供は2026年後半予定で確定日は未公表
- すでにコロケーションで専用線を敷き終え、10Gbps超を恒常的に流している構成。置き換えの利得が薄い
- 接続先が対応クラウド一覧にない場合。従来のCross-Cloud Interconnectのほうが接続先は広い
とりわけ1つ目は、国内のクラウド間連携を検討する事業会社にとって現実的な結論です。検証工数を積むより対応リージョンの拡大を待つほうが健全でしょう。複数クラウドをまたぐネットワーク設計の判断は、AWS・Google Cloud・Azureのインフラ構築としてご相談を受けています。
移行時に見落としやすいIPアドレス重複とゲートウェイ選択の確認点
採用を決めた場合、着手前の確認事項が3つあります。順序はユーザーガイドの「Plan your network architecture」に沿います。
1つ目はゲートウェイの選択で、グローバルに到達したいならCloud WANを選ぶ必要があります。2つ目は既存のIPアドレス割り当ての棚卸しです。両クラウドのCIDRが衝突していないことを事前に確認します。マネージドとはいえアドレス設計だけは肩代わりされません。3つ目はDXGWを新規作成するか既存を再利用するかで、Tier自動昇格を踏まえると用途ごとに分ける設計に分があります。
コンテナ基盤を複数クラウドにまたいで運用しているなら、管理面の統合も論点になるはずです。この領域はGKE Enterpriseへ統合されたマルチクラウドKubernetes管理の全体像で扱っています。
よくある質問
要件定義の場で問われる5点をまとめます。
AWS Interconnect – multicloudは東京リージョンで使えますか？
2026年8月24日時点のRegional Availabilityには、東京（ap-northeast-1）も大阪（ap-northeast-3）も掲載されていません。国内のAWSリージョンを起点にした閉域接続は作成できないということです。Cloud WANのCore Network Edgeを東京に置けば米国のInterconnectへ到達はできますが、課金Tierが上がり物理距離ぶんの遅延も加わります。国内向けの応答時間要件がある本番系では避けてください。
AWS Direct Connectは不要になりますか？
なりません。AWS側のアタッチポイントは常にDirect Connect gatewayで、Interconnectはその上に載る接続方式の1つです。オンプレミス拠点とAWSを結ぶ専用線の役割はDirect Connectが引き続き担い、Interconnect – multicloudが担当するのはクラウド間の区間です。両者は同じDXGWを共有できます。
料金はデータ転送量でも課金されますか？
されません。課金は帯域と、地理的スコープを表すTierの組み合わせで決まる時間課金のみで、転送データ量への別料金は設定されていません。ただしTierは到達しうる経路の実態で自動的に決まるため、Cloud WANにリージョンを追加すると既存Interconnectの単価が上がる場合があります。相手クラウド側の課金はAWSとは独立に発生します。
無料枠の500Mbpsだけで本番運用できますか？
技術的には接続として成立しますが、運用の前提には向きません。無料枠は一般提供済みのクラウドごと・AWSリージョンごとに1本、ローカル（Tier1）の500Mbpsに限られ、後から有料接続へ変換できない仕様です。疎通確認と実効スループットの実測に使い、本番は必要帯域で新規に作成する使い方が現実的でしょう。
Azureとの接続はいつから使えますか？
Microsoft Azureは2026年後半の提供予定とアナウンスされていますが、8月24日時点で提供開始日と対応リージョンペアは公表されていません。AWSは接続を調停する対称APIの仕様をOpenAPI 3.0形式でGitHubのaws/Interconnectに公開しており、ライセンスはApache-2.0です。仕様に準拠した事業者が順次加わる構造のため、提携報道よりも提供開始のアナウンスを追うほうが確実でしょう。
関連記事
- AWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断【2026年版】：アタッチ先となる専用線サービスの仕組みと料金を解説しています。
- AWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金を解説：DXGWの先に置くハブの設計とVPC Peeringとの使い分けを扱っています。
- AWS Direct Connectの100ルート問題｜BGP経路数の上限とセッション断の回避策：経路交換が自動化されても残る経路数の制約を詳述しています。
- Oracle Database@AWSとは？AWSでOracle Exadata/Autonomous Databaseを利用できるマルチクラウドサービス：OCI連携を閉域接続ではなくサービス統合で解決する選択肢です。
- Anthosとは？GKE Enterpriseへ統合されたマルチクラウドKubernetes管理の全体像：複数クラウドをまたぐ運用管理面の論点です。
