AWS Interconnect とは｜GCP・OCI 接続と Direct Connect の違い

はじめに

大規模なエンタープライズでは、特定サービスの活用やデータレジデンシー要件を背景に、複数のクラウドプロバイダーへワークロードを分散させる構成が増えています。こうしたマルチクラウド環境で AWS と他クラウドを閉域接続するには、これまで VPN トンネルの管理、コロケーション施設との調整、サードパーティ製ネットワーク機器の設定といった作業が必要でした。

2026 年 4 月 14 日に一般提供（GA）が開始された AWS Interconnect は、これらをフルマネージドサービスとして吸収し、数クリックで閉域・高速なクラウド間接続を確立できる仕組みを提供します。GA から数か月が経過し、対応クラウドや料金体系にも動きが出ています。

AWS Interconnect は、マルチクラウド接続（multicloud）とラストマイル接続（last mile）の 2 つで構成されるプライベート接続サービスです。GA 時点の multicloud 対応先は Google Cloud のみでしたが、2026 年 5 月に Oracle Cloud Infrastructure（OCI）が Preview となり、対応が広がりつつあります。 一方で、対応リージョンは米国・欧州の 5 ペアにとどまり、東京リージョンは未対応のため、国内での本格利用は今後の拡張を待つ段階です。検証目的であれば、後述の無料枠を利用して低コストで試すこともできます。

AWS Interconnect とは

登場背景と解決する課題

複数クラウドをまたぐワークロードを安全・安定的に接続するには、従来は以下のような課題がありました。

• VPN トンネルの管理負荷: 拠点数やクラウド数が増えると設定・監視コストが増大する。
• コロケーション施設との調整: 物理的な相互接続には施設側との契約や工事が伴う。
• サードパーティ製ネットワーク機器の設定: BGP・VRF・VLAN 設計などの専門知識が必要になる。
• パブリックインターネット経由のリスク: レイテンシの変動やセキュリティリスクが残る。

AWS Interconnect は、これらをフルマネージドサービスとして解消することを狙って設計されています。

2 つのケイパビリティの位置づけ

AWS Interconnect は以下の 2 つで構成され、どちらも「フルマネージド・ターンキー」という同一の設計思想に基づいています。

どちらも AWS Direct Connect コンソールの「AWS Interconnect」セクションから操作し、Direct Connect Gateway を介して VPC や Transit Gateway・Cloud WAN に接続する共通アーキテクチャを採用しています。

対応 CSP の最新状況（2026 年 7 月時点）

multicloud の対応クラウドは、GA 以降に段階的に拡大しています。現時点での対応状況は、Google Cloud が一般提供（GA）、OCI が Preview（2026 年 5 月発表）、Microsoft Azure が 2026 年後半に対応予定、という 3 段階です。

OCI 側では Oracle Interconnect for AWS として提供され、Oracle・AWS のどちらのコンソールからも接続を開始できます。Preview 時点では OCI US East（Ashburn）で限定提供され、AWS us-east-1 リージョンでの提供は年内予定とされています。本番環境での採用可否は、Preview の位置づけを踏まえて判断することが推奨されます。

この段階的な拡大を支えているのが、AWS が公開した接続仕様です。AWS は AWS Interconnect – multicloud の技術仕様を GitHub 上に Apache 2.0 ライセンスで公開しており、各クラウドプロバイダーはこの共通仕様を実装することで対応が可能になります。 OCI もこの仕様を採用したクラウドの 1 つで、マルチクラウド接続の標準化に向けた動きとして注目されています。

参考: AWS（AWS announces AWS Interconnect – multicloud connectivity with OCI in preview）
“OCI is the latest CSP to adopt the open specification that powers AWS Interconnect.”
（OCI は AWS Interconnect を支えるオープン仕様を採用した最新の CSP です。）
https://aws.amazon.com/about-aws/whats-new/2026/05/aws-announces-AWS-interconnect-multicloud-oci-preview/

AWS Interconnect – multicloud の詳細

アーキテクチャと通信経路

AWS Interconnect – multicloud は、AWS の VPC と他クラウドプロバイダーの VPC を Layer 3 のプライベート接続で結ぶサービスです。通信は AWS のグローバルバックボーンとパートナークラウドのプライベートネットワークのみを経由し、パブリックインターネットを通りません。この経路設計により、予測可能なレイテンシ、安定したスループット、インターネット輻輳からの隔離という特性が得られます。

graph LR
    A[AWS VPC] --> B[Direct Connect<br/>Gateway]
    B --> C[AWS グローバル<br/>バックボーン]
    C -. MACsec 暗号化 .-> D[パートナークラウドの<br/>プライベートネットワーク]
    D --> E[GCP VPC]

AWS コンソール側では Direct Connect Gateway を介して接続が確立され、VPC ルートテーブルへのルート追加のみで疎通が完成します。

参考: AWS News Blog（AWS Interconnect is now generally available）
“Traffic flows entirely over the AWS global backbone and the partner cloud’s private network.”
（トラフィックは AWS のグローバルバックボーンとパートナークラウドのプライベートネットワークのみを経由します。）
https://aws.amazon.com/blogs/aws/aws-interconnect-is-now-generally-available-with-a-new-option-to-simplify-last-mile-connectivity/

セキュリティ・可用性の設計

セキュリティ面では、AWS のルーターとパートナークラウドのルーター間の物理リンクに対して、IEEE 802.1AE（MACsec）暗号化がデフォルトで適用されます。ユーザー側での個別設定は不要です。ただし、各クラウドプロバイダーは自社バックボーン上の暗号化を独自に管理しているため、エンドツーエンドの暗号化要件がある場合は、デプロイ先クラウドのドキュメントを個別に確認することが推奨されます。

可用性の面では、各接続が少なくとも 2 つの物理施設にまたがる複数の論理リンクで構成され、冗長性がサービス設計に組み込まれています。従来の Direct Connect では冗長構成を自前で設計・調達する必要がありましたが、AWS Interconnect ではこの部分がマネージドで提供されます。

モニタリングは CloudWatch Network Synthetic Monitor が標準で付属し、ラウンドトリップレイテンシ・パケットロス・帯域利用率をリアルタイムで監視できます。

接続手順（AWS → GCP）

接続作業の前に、以下の準備を整えておくことが推奨されます。

• AWS VPC と GCP VPC の IP アドレス範囲に重複がないことを確認する。
• Direct Connect Gateway を作成または既存のものを用意する。
• GCP プロジェクト ID を手元に準備する。
• ゲートウェイの種別を決定する（Virtual Private Gateway・Transit Gateway・Cloud WAN のいずれか）。

まず AWS マネジメントコンソールの Direct Connect コンソールで「AWS Interconnect」を選択し、Create new multicloud Interconnect からクラウドプロバイダーとして Google Cloud を選択します。接続元の AWS リージョンと接続先の GCP リージョン、帯域幅、既存の Direct Connect Gateway、GCP プロジェクト ID を入力して進めると、アクティベーションキーが発行されます。

GCP 側では、発行されたアクティベーションキーを使ってトランスポートリソースを作成します。執筆時点では GCP のウェブコンソールから直接操作する方法は提供されていないため、gcloud コマンドを使用します。

トランスポートの作成:

gcloud network-connectivity transports create <トランスポート名> \
    --region=<GCP リージョン> \
    --activation-key=<AWS から発行されたアクティベーションキー> \
    --network=<GCP VPC 名> \
    --advertised-routes=<GCP 側でアドバタイズする CIDR>

コマンド完了後、出力に含まれる peeringNetwork の値（トランスポート VPC のリソース名）をメモしておきます。

VPC ピアリングの作成:

gcloud compute networks peerings create <ピアリング名> \
    --network=<GCP VPC 名> \
    --peer-network=<上記の peeringNetwork の値> \
    --import-custom-routes \
    --export-custom-routes

--import-custom-routes と --export-custom-routes を両方指定することで、カスタムルートの双方向交換が有効になります。GCP 側の作業が完了したら、AWS コンソールで Direct Connect Gateway のゲートウェイアソシエーションを設定し、GCP 側の CIDR レンジ宛てのルートを VPC ルートテーブルに追加すると疎通が完成します。

参考: AWS Interconnect User Guide（Getting started with AWS Interconnect）
https://docs.aws.amazon.com/interconnect/latest/userguide/getting-started.html

設定時の注意点（IP アドレス・MTU・IPv6）

IP アドレスの重複回避: AWS VPC と GCP VPC の CIDR 範囲が重複していると、接続後にルーティングが正しく機能しません。接続前に両側の IP アドレス割り当てを確認することが推奨されます。

MTU の不一致: MTU の設定は AWS 側と GCP 側で揃える必要があります。不一致のままにすると、パケットのフラグメンテーションや破棄が発生し、スループット低下や接続断の原因になります。公式ドキュメントによると multicloud の MTU は自動的に 8500 に設定されるため、GCP 側の設定と合わせて事前に確認することが推奨されます。 MTU と MSS の関係を整理したい場合は、関連記事『MTU/MSS とは｜PPPoE・IPsec で通信が止まる原因と対策』もあわせて参照してください。

IPv4 / IPv6 の設定: IPv4・IPv6 または両方を設定できますが、AWS 側と GCP 側で同一のオプションを選択する必要があります。

AWS Interconnect – last mile の詳細

AWS Interconnect – last mile は、ブランチオフィス・データセンター・リモート拠点といったオンプレミス環境から AWS への閉域・高速接続を、既存のネットワークプロバイダー経由で確立するサービスです。multicloud と同じアーキテクチャ・設計思想に基づいており、プロバイダーを選択して接続エンドポイントと帯域幅を指定すると、AWS がアクティベーションキーを発行します。ユーザーはそのキーをプロバイダー側で入力することで接続が完成します。

自動プロビジョニングされる構成要素

従来の Direct Connect 接続では、冗長構成・BGP 設定・MACsec の有効化などを個別に実施する必要がありました。last mile ではこれらが自動でプロビジョニングされます。

帯域幅は 1 Gbps〜100 Gbps の範囲でコンソールから選択でき、再プロビジョニングなしに変更できます。4 本の冗長接続は ECMP でロードバランスされ、機器障害時にも通信が継続する設計になっています。 また、Direct Connect ポートまでの 99.99% の可用性 SLA が提供されます。ルート交換の前提となる BGP の基礎を整理したい場合は、関連記事『BGP の仕組みと設計の基礎（後日公開予定）』もあわせて参照してください。

対応リージョンとパートナーの最新状況

last mile は当初、Lumen をパートナーとして US East（N. Virginia）でローンチしました。ニュージャージーのサイトから世界中の任意の AWS リージョンへ接続でき、Lumen のファブリック経由で全米から接続できます。追加パートナーとしては、AT&T が AWS Interconnect – last mile の Preview を発表し、2Q26（4〜6 月）に対象顧客への提供を予定しています。Megaport も対応準備中とされています。

参考: AT&T（AT&T, AWS Collaborate on Scalable Connectivity for Business AI）
“The preview will be available for customers in 2Q26.”
（プレビューは 2Q26 に顧客へ提供される予定です。）
https://about.att.com/story/2026/aws-collaboration-scalable-business-ai.html

従来構成との比較と選定ガイド

AWS Interconnect・従来の Direct Connect・IPsec-VPN は、いずれも AWS への接続手段ですが、マネージドの範囲・経路・冗長設計が異なります。ここでは実務での選定を前提に整理します。

主要な接続手法の比較

MACsec と IPsec の違い

暗号化の方式が異なるため、「MACsec があれば IPsec は不要か」という判断には注意が必要です。両者は保護する層と区間が異なります。

MACsec（IEEE 802.1AE）は Layer 2 の暗号化で、隣接する機器間の物理リンク単位でトラフィックを保護します。AWS Interconnect では、AWS のルーターとパートナークラウドのルーター間の物理リンクに適用されます。一方 IPsec は Layer 3 の暗号化で、IP パケットをトンネル単位でエンドツーエンドに保護し、インターネットを含む任意の経路上で機能します。

MACsec はリンク区間の保護であり、経路全体のエンドツーエンド暗号化を保証するものではありません。 各 CSP は自社バックボーン上の暗号化を独自に管理するため、エンドツーエンドの暗号化要件がある場合は、デプロイ先クラウドのドキュメントを個別に確認することが推奨されます。

CSP 別の接続方式（2026 年 7 月時点）

接続先の CSP によって、提供状況とアーキテクチャの成り立ちが異なります。

Azure の ExpressRoute は Microsoft クラウドへのプライベート接続を提供しますが、AWS や Google Cloud へのクロスクラウド接続には、コロケーション施設経由の自前ルーティングや、Megaport・Equinix などのサードパーティ接続プロバイダーが引き続き必要です。Azure 対応が加わるまでは、この違いを踏まえた設計が必要になります。

参考: AWS（AWS Interconnect – multicloud）
“including Google Cloud and Oracle Cloud Infrastructure (Preview). Microsoft Azure coming later in 2026.”
（Google Cloud と OCI（プレビュー）を含みます。Microsoft Azure は 2026 年後半に対応予定です。）
https://aws.amazon.com/interconnect/multicloud/

状況別の選定ガイド

要件別に、どの接続手段が適するかの目安を整理します。

• AWS と他 CSP のマネージド閉域接続が必要で、接続先が対応リージョン内（米国・欧州）にある場合は、AWS Interconnect – multicloud が候補になります。
• AWS とオンプレミスを接続し、既存のネットワークプロバイダーを活用したい場合（現状は米国）は、AWS Interconnect – last mile が候補になります。
• 東京リージョンを含む広範なリージョンでオンプレミス接続が必要な場合は、現状では従来の Direct Connect が選択肢になります。
• 小規模・短期利用でコストを最優先し、IPsec による暗号化で要件を満たせる場合は、IPsec-VPN が候補になります。
• 東京リージョンで他 CSP との接続が現時点で必要な場合は、AWS Interconnect が未対応のため、Megaport・Equinix などのサードパーティ経由や、Direct Connect と相互接続ポイントの組み合わせで構成することになります。

Transit Gateway・Cloud WAN との組み合わせ

AWS Interconnect は、システムの要件に合わせて複数のリファレンスアーキテクチャへ拡張できます。

 パターン 1: 単一 VPC ＋ Virtual Private Gateway（最小構成）。1 つの AWS VPC と 1 つの GCP VPC を接続する用途に適し、設定ステップが少なく検証環境の構築に向いています。

 パターン 2: Transit Gateway による複数 VPC の集約（リージョン内集約）。同一リージョン内に複数の VPC がある場合、Transit Gateway をアタッチポイントとして複数 VPC を一括接続できます。トラフィックのセグメンテーションや、AWS Network Firewall との統合が可能になります。

 パターン 3: Cloud WAN によるグローバル展開。複数の AWS リージョンと複数の GCP 環境が分散している構成では、Cloud WAN を活用することで、どのリージョンからでもルーティングできます。ただし、地理的に遠いリージョンがティア計算の基準になるため、コスト設計に注意が必要です（料金の詳細は後述）。

参考: AWS News Blog（AWS Interconnect is now generally available）
“AWS Transit Gateway gives you a centralized routing hub to connect them all through a single Interconnect attachment.”
（AWS Transit Gateway は、単一の Interconnect アタッチメントを通じてすべてを接続する集中型ルーティングハブを提供します。）
https://aws.amazon.com/blogs/aws/aws-interconnect-is-now-generally-available-with-a-new-option-to-simplify-last-mile-connectivity/

料金と対応リージョン

AWS Interconnect の料金は、multicloud・last mile ともに帯域幅に基づく時間単位の定額制で、GB 単位のデータ転送料金は発生しません。課金は接続の作成時に始まり、削除時に終了します。

料金を決定する 2 つの軸

料金は「接続の帯域幅」と「地理的な距離に基づくティア（Tier 1〜5）」の組み合わせで決まります。Tier 1 が最も安価、Tier 5 が最も高価で、地理的な経路が遠いほど高いティアが適用されます。multicloud では、VPC のトラフィックが発生する送信元 AWS リージョンと、インターコネクトのローカル AWS リージョンの組み合わせでティアが決まります。

無料の 500 Mbps 枠（2026 年 5 月開始）

GA 後の追加として、検証・評価をコストなしで始められる無料枠が用意されました。AWS と一般提供（GA）済みの CSP との間で、AWS リージョンごと・CSP ごとに 1 本、ローカル（Tier 1）の 500 Mbps インターコネクトを無料で利用できます。 有償版と同じネットワーク経路・施設・機器の冗長性を備え、CloudWatch Network Synthetic Monitor も追加費用なしで付属します。500 Mbps は 1 か月あたり約 160 TB のデータ転送に相当し、PoC や小規模な開発環境の検証に活用できます。無料枠は 1 顧客あたり 1 本で、AWS Service Terms が適用されます。

参考: AWS（AWS Interconnect – multicloud now offers a free 500 Mbps tier）
“The new Free Tier Interconnect gives customers a fully managed, 500 Mbps Interconnect to another CSP at no charge on the AWS side.”
（新しい無料枠のインターコネクトは、AWS 側で課金なしに、別の CSP への 500 Mbps のフルマネージド接続を提供します。）
https://aws.amazon.com/about-aws/whats-new/2026/05/aws-interconnect-multicloud-offers-free-500-mbps-tier/

料金試算の参考例

公式ページに掲載されている試算例です（US East（N. Virginia）を起点とした 10 Gbps 接続の場合）。

Cloud WAN を使用する場合、ティアはインターコネクトのローカルリージョンではなく、Direct Connect Gateway に関連付けられた Core Network Edge（CNE）の中で最も高いティアで決まります。 上記の例では、トポロジに Singapore の CNE が含まれるため、ローカルの Tier 1 ではなく Tier 4 が適用されます。意図しない高ティアの適用を避けるため、接続前にネットワークトポロジを確認することが推奨されます。

なお、multicloud では相手側 CSP でも接続料金が発生します（GCP の場合は Partner Cross-Cloud Interconnect の料金など）。総コストを見積もる際は、AWS 側と相手側の双方を合算して評価することが推奨されます。

参考: AWS（AWS Interconnect – multicloud Pricing）
“Your tier is determined by the highest tier CNE in your topology, not the CNE in the interconnect’s local AWS Region.”
（ティアは、インターコネクトのローカル AWS リージョンの CNE ではなく、トポロジ内で最も高いティアの CNE によって決まります。）
https://aws.amazon.com/interconnect/multicloud/pricing/

利用可能リージョンとパートナー

multicloud の対応リージョンは、GA 時点から 5 ペア（米国・欧州）で、いずれも Google Cloud との接続です。

last mile は US East（N. Virginia）で Lumen を初期パートナーとして提供され、Lumen のファブリック経由で全米から接続できます。AT&T は 2Q26 に Preview 提供を予定し、Megaport も対応準備中とされています。

なお、multicloud・last mile ともに東京リージョン（ap-northeast-1）は現時点では未対応です。 国内でマルチクラウド接続やオンプレミス閉域接続が必要な場合は、従来の Direct Connect や、Megaport・Equinix などのサードパーティ接続を組み合わせる構成が現実的な選択肢になります。今後のリージョン拡張は AWS の公式アナウンスで確認することが推奨されます。

まとめ

AWS Interconnect は、マルチクラウド接続（multicloud）とラストマイル接続（last mile）を提供するフルマネージドのプライベート接続サービスです。GA 以降も対応 CSP や無料枠の面で更新が続いており、2026 年 7 月時点では検証を低コストで始められる環境が整っています。導入検討時は、対応リージョンと相手側 CSP の料金を含めて評価することが要点になります。

• multicloud と last mile の 2 つのケイパビリティで構成されるマネージド接続サービス
• 対応 CSP は GCP が GA、OCI が Preview、Azure は 2026 年後半に対応予定
• 通信は AWS と相手 CSP のバックボーンを経由し MACsec をデフォルトで適用
• 料金は帯域と地理的ティアで決まる時間課金で GB 転送料は発生しない
• リージョンごとに 1 本の 500 Mbps 無料枠があり検証や PoC に利用できる
• 対応は米国・欧州の 5 ペアで東京リージョンは現時点では未対応

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