はじめに
2026 年 4 月 14 日、AWS は「AWS Interconnect」の一般提供（GA）を発表しました。マルチクラウド接続を担う AWS Interconnect – multicloud と、オンプレミスや拠点からの閉域接続を簡素化する AWS Interconnect – last mile の 2 つのケイパビリティで構成される、フルマネージドのプライベート接続サービスです。
これまでマルチクラウド環境のネットワーク設計では、VPN トンネルの管理・コロケーション施設との調整・サードパーティ製ネットワーク機器の設定といった複雑な作業が避けられませんでした。AWS Interconnect はこうした「差別化につながらない重労働」をマネージドサービスとして吸収し、数クリックで閉域・高速なクラウド間接続を確立できる仕組みを提供します。
本記事では、AWS Interconnect の概要と仕組みを整理した上で、従来の Direct Connect や IPsec-VPN との違い、Transit Gateway・Cloud WAN を組み合わせたアーキテクチャ設計のポイントをインフラエンジニアの視点で深く考察します。
- AWS Interconnect の登場背景と 2 つのケイパビリティの位置づけ
- multicloud の通信経路・セキュリティ・可用性の設計
- GCP との接続手順と設定時の注意点（IP アドレス・MTU 等）
- last mile の仕組みと自動プロビジョニングされる構成要素
- 従来構成（Direct Connect / IPsec-VPN）との違いと設計上の考察
- Transit Gateway・Cloud WAN との組み合わせ方
- 料金体系と利用可能なリージョンペア
AWS Interconnect とは
登場背景と解決する課題
大規模エンタープライズでは、特定サービスの活用・データレジデンシー要件・チームごとの標準化といった理由から、複数のクラウドプロバイダーにワークロードを分散させるケースが増えています。こうしたマルチクラウド環境を安全・安定的に接続するには、これまで以下のような課題がありました。
- VPN トンネルの管理負荷: 拠点数やクラウド数が増えると設定・監視コストが増大する
- コロケーション施設との調整: 物理的な相互接続には施設側との契約・工事が伴う
- サードパーティ製ネットワーク機器の設定: BGP・VRF・VLAN 設計など専門知識が必要
- パブリックインターネット経由のリスク: レイテンシの変動・セキュリティリスクが残る
AWS Interconnect はこれらの課題をフルマネージドサービスとして解消することを目的に設計されています。
参考: AWS News Blog（AWS Interconnect is now generally available）
“The result is that your networking team spends time on undifferentiated heavy lifting instead of focusing on the applications that matter to your business.”
（その結果、ネットワークチームはビジネスにとって重要なアプリケーションではなく、差別化につながらない重労働に時間を費やすことになります。）
2 つのケイパビリティの位置づけ
AWS Interconnect は以下の 2 つのケイパビリティで構成されており、どちらも「フルマネージド・ターンキー」という同一の設計思想に基づいています。
| ケイパビリティ | 接続先 | 主なユースケース |
| AWS Interconnect – multicloud | 他のクラウドプロバイダー（Google Cloud 等） | クラウド間のプライベート通信・データ連携 |
| AWS Interconnect – last mile | オンプレミス・拠点・データセンター | 既存ネットワークプロバイダー経由の閉域 AWS 接続 |
どちらのケイパビリティも AWS Direct Connect コンソールの「AWS Interconnect」セクションから操作し、Direct Connect Gateway を介して VPC や Transit Gateway・Cloud WAN に接続する共通アーキテクチャを採用しています。
参考: AWS News Blog（AWS Interconnect is now generally available）
“Both capabilities are built on the same principle: a fully managed, turnkey experience that removes the infrastructure complexity from your team.”
（どちらのケイパビリティも同じ原則に基づいて構築されています。インフラの複雑さをチームから取り除く、フルマネージドなターンキー体験です。）
AWS Interconnect – multicloud の詳細
アーキテクチャと通信経路
AWS Interconnect – multicloud は、AWS の VPC と他クラウドプロバイダーの VPC を Layer 3 のプライベート接続で結ぶサービスです。GA 時点では Google Cloud との接続に対応しており、Microsoft Azure および Oracle Cloud Infrastructure（OCI）は 2026 年後半に対応予定です。
トラフィックの流れ
通信は AWS のグローバルバックボーンとパートナークラウドのプライベートネットワークのみを経由します。パブリックインターネットを一切経由しないため、以下の特性が得られます。
- 予測可能なレイテンシと安定したスループット
- インターネット輻輳の影響を受けない通信品質
- 物理インフラを自前で管理する必要がない
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, so it never traverses the public internet.”
（トラフィックは AWS のグローバルバックボーンとパートナークラウドのプライベートネットワークのみを経由するため、パブリックインターネットを通過することはありません。）
セキュリティ・可用性の設計
- セキュリティ: MACsec 暗号化がデフォルトで有効
-
AWS Interconnect – multicloud では、AWS のルーターとパートナークラウドのルーター間の物理リンクに対して IEEE 802.1AE（MACsec）暗号化がデフォルトで適用されます。ユーザーが別途設定する必要はありません。ただし、各クラウドプロバイダーは自社バックボーン上の暗号化を独自に管理しているため、エンドツーエンドの暗号化要件についてはデプロイ先クラウドのドキュメントを個別に確認することが推奨されます。
- 可用性: 冗長設計がビルトイン
-
各接続は少なくとも 2 つの物理施設にまたがる複数の論理リンクで構成されます。単一デバイスや建物の障害が発生しても通信が継続できるよう、冗長性がサービス設計に組み込まれています。従来の Direct Connect では冗長構成を自前で設計・調達する必要がありましたが、AWS Interconnect ではこの部分がマネージドで提供されます。
参考: AWS News Blog（AWS Interconnect is now generally available）
“Resiliency is also built in: each connection spans multiple logical links distributed across at least two physical facilities, so a single device or building failure does not interrupt your connectivity.”
（可用性もビルトインされています。各接続は少なくとも 2 つの物理施設に分散した複数の論理リンクにまたがっているため、単一のデバイスや建物の障害が接続を中断させることはありません。）
- モニタリング: CloudWatch との統合
-
各接続には CloudWatch Network Synthetic Monitor が標準で付属し、ラウンドトリップレイテンシ・パケットロス・帯域利用率をリアルタイムで監視できます。別途モニタリングツールを構築する必要がなく、既存のアラームとの統合も容易です。
AWS Interconnect – multicloud の接続手順（AWS → GCP）
事前準備
接続作業を始める前に、以下の準備を整えておくことが推奨されます。
- VPC 間の IP アドレス重複がないことを確認する
- Direct Connect Gateway を作成または既存のものを用意する
- GCP プロジェクト ID を手元に準備する
- ゲートウェイの種別を決定する（Virtual Private Gateway・Transit Gateway・Cloud WAN のいずれか）
参考: AWS Interconnect User Guide（Getting started with AWS Interconnect）
https://docs.aws.amazon.com/interconnect/latest/userguide/getting-started.html
AWS コンソールで Interconnect を作成する
AWS マネジメントコンソールの Direct Connect コンソールにアクセスし、左側のナビゲーションメニューから AWS Interconnect を選択します。
Create new multicloud Interconnectを選択- クラウドプロバイダーとして Google Cloud を選択
- 接続元の AWS リージョンと接続先の GCP リージョンを選択
- 帯域幅・既存の DXGW・GCP プロジェクト ID を入力して進む
- 内容を確認して
Finishを選択すると、アクティベーションキーが発行されます
参考: AWS Interconnect User Guide（Getting started with AWS Interconnect）
https://docs.aws.amazon.com/interconnect/latest/userguide/getting-started.html
GCP 側でトランスポートと VPC ピアリングを作成する
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を両方指定することで、カスタムルートの双方向交換が有効になります。
参考: AWS News Blog（AWS Interconnect is now generally available）
“Routes propagate automatically in both directions, and my workloads can start exchanging data shortly after.”
（ルートは双方向に自動的に伝播し、ワークロードはしばらくするとデータ交換を開始できます。）
AWS 側でゲートウェイアソシエーションとルートテーブルを設定する
GCP 側の作業が完了したら、AWS コンソールに戻り最終設定を行います。
- ゲートウェイのアソシエーション
-
Direct Connect Gateway の
Gateway associationsから、事前に作成しておいた Virtual Private Gateway（VGW）などをアタッチします。 - VPC ルートテーブルへのルート追加
-
GCP 側の CIDR レンジ宛てのトラフィックを VGW 経由で転送するルートエントリを追加します。GCP 側のルーティングは自動設定されるため追加の手動設定は不要です。
設定時の注意点（IP アドレス・MTU・IPv6）
- IP アドレス重複の回避
-
AWS VPC と GCP VPC の CIDR 範囲が重複していると接続後にルーティングが正しく機能しません。接続前に必ず両側の IP アドレス割り当てを確認することが推奨されます。
- MTU の不一致に注意
-
MTU の設定は AWS 側と GCP 側で揃える必要があります。不一致のままにするとパケットのフラグメンテーションや破棄が発生し、スループット低下や接続断の原因になります。公式ドキュメントによると multicloud の MTU は自動的に 8500 に設定されるため、GCP 側の設定と合わせて事前に確認することが推奨されます。
参考: AWS Interconnect User Guide（What is AWS Interconnect?）
“Mismatched MTU sizes between peered VPCs cause packet drops or fragmentation, leading to silent data loss, degraded throughput, and broken connections across the interconnect.”
（ピアリングされた VPC 間の MTU サイズの不一致は、パケット破棄やフラグメンテーションを引き起こし、サイレントなデータ損失・スループット低下・接続断につながります。）
https://docs.aws.amazon.com/interconnect/latest/userguide/what-is.html
- IPv4 / IPv6 の設定
-
IPv4・IPv6 または両方を設定できますが、AWS 側と GCP 側で同一のオプションを選択する必要があります。
AWS Interconnect – last mile の詳細
仕組みと接続フロー
AWS Interconnect – last mile は、ブランチオフィス・データセンター・リモート拠点といったオンプレミス環境から AWS への閉域・高速接続を、既存のネットワークプロバイダー経由で確立するサービスです。
multicloud と同じアーキテクチャ・設計思想に基づいており、プロバイダーを選択し、接続エンドポイントと帯域幅を指定すると AWS がアクティベーションキーを発行します。ユーザーはそのキーをプロバイダーのコンソールで入力することで接続が完成します。
参考: AWS News Blog（AWS Interconnect is now generally available）
“Based on the same architecture and design as AWS Interconnect – multicloud, AWS Interconnect – last mile provides the ability to connect your on-premises or remote location to AWS through a participating network provider’s last-mile infrastructure, directly from the AWS Management Console.”
（AWS Interconnect – multicloud と同じアーキテクチャ・設計に基づき、AWS Interconnect – last mile は、参加しているネットワークプロバイダーのラストマイルインフラを通じて、オンプレミスまたはリモートロケーションを AWS に接続する機能を、AWS マネジメントコンソールから直接提供します。）
自動プロビジョニングされる構成要素
従来の Direct Connect 接続では、冗長構成・BGP 設定・MACsec の有効化などの手順を個別に実施する必要がありました。AWS Interconnect – last mile ではこれらが自動でプロビジョニングされます。
| 自動設定される構成要素 | 内容 |
| 冗長接続（4 本） | 2 つの物理拠点にまたがる 4 本の冗長接続を自動構成 |
| BGP ルーティング | BGP セッションの確立・ルート交換を自動設定 |
| MACsec 暗号化 | デフォルトで有効化 |
| ジャンボフレーム（Jumbo Frames） | デフォルトで有効化 |
| CloudWatch 監視 | 接続ヘルス監視（Synthetic Monitor）が標準バンドル |
帯域幅は 1 Gbps〜100 Gbps の範囲で選択でき、再プロビジョニングなしにコンソールから変更することが可能です。また、Direct Connect ポートまでの 99.99% の可用性 SLA が保証されています。
参考: AWS News Blog（AWS Interconnect is now generally available）
“AWS Interconnect – last mile automatically provisions four redundant connections across two physical locations, configures BGP routing, and activates MACsec encryption and Jumbo Frames by default.”
（AWS Interconnect – last mile は、2 つの物理拠点にまたがる 4 本の冗長接続を自動でプロビジョニングし、BGP ルーティングを設定し、MACsec 暗号化とジャンボフレームをデフォルトで有効化します。）
従来構成との比較・アーキテクチャ設計の考察
Direct Connect / IPsec-VPN との違い
インフラエンジニアの視点で、主要な接続手法との違いを整理します。
| 比較項目 | AWS Interconnect | AWS Direct Connect（従来） | IPsec-VPN（FortiGate 等） |
| 接続形態 | フルマネージド・ターンキー | 半マネージド（物理回線は要調達） | セルフマネージド |
| 経路 | AWS ＋ 相手 CSP バックボーン | AWS バックボーン（相手への接続は別途） | パブリックインターネット経由 |
| 冗長設計 | ビルトイン（2 拠点 × 4 リンク） | 自前で冗長構成を設計・調達 | 自前でトンネル冗長を設計 |
| MACsec 暗号化 | デフォルトで自動有効 | オプション（手動設定が必要） | 不要（IPsec で暗号化） |
| BGP 設定 | 自動（ルート自動伝播） | 手動設定が必要 | 手動設定が必要 |
| 開通リードタイム | 数分 | 数週間〜数ヶ月（物理回線） | 比較的短期間 |
| 帯域変更 | コンソールから変更可 | 回線変更を伴う場合あり | トンネル設定変更で対応 |
| コスト構造 | 時間課金・従量制（帯域 × ティア） | 専用線費用 ＋ 接続時間課金 | VPN 機器 ＋ インターネット回線費用 |
インフラ設計の観点からの考察
従来の Direct Connect を使ったマルチクラウド接続では、「AWS ↔ コロケーション施設 ↔ 他クラウドの相互接続ポイント」という物理的な経路と手配が必要でした。AWS Interconnect ではこの物理的な調達フェーズが不要になり、設計・申請から疎通確認まで数分〜数時間で完結することが期待できます。
参考: AWS News Blog（AWS Interconnect is now generally available）
“You can configure resilient, end-to-end connectivity with ease in a few clicks through the AWS Console by selecting your location, partner, or cloud provider, preferred Region, and bandwidth requirements, removing the friction of discovering partners and the complexity of manual network configurations.”
（ロケーション、パートナーまたはクラウドプロバイダー、希望するリージョン、帯域幅要件を選択するだけで、AWS コンソールから数クリックで回復力のあるエンドツーエンド接続を設定でき、パートナーを探す手間やネットワーク設定の複雑さが解消されます。）
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 との統合が可能になります。
参考: 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. You can segment traffic between environments, apply consistent routing policies, and integrate AWS Network Firewall if you need to inspect what crosses the cloud boundary.”
（AWS Transit Gateway は、単一の Interconnect アタッチメントを通じてすべてを接続する集中型ルーティングハブを提供します。環境間のトラフィックをセグメント化し、一貫したルーティングポリシーを適用し、クラウド境界を越えるものを検査する必要がある場合は AWS Network Firewall を統合することができます。）
- パターン 3: Cloud WAN によるグローバル展開
-
複数の AWS リージョンと複数の GCP 環境が分散している構成では、AWS Cloud WAN を活用することで、世界中のどのリージョンからでもルーティング可能になります。ただし、地理的に遠いリージョンがティア計算の基準となるため、コスト設計には注意が必要です。
マルチクラウド設計のメリット・デメリット
メリット:
- 運用工数の削減: BGP 設定・冗長設計等の反復作業がマネージドで提供される
- 接続の標準化: プロバイダー選定や調達工程が不要になり、接続パターンを統一しやすい
- スケールアップの容易さ: 帯域変更が再プロビジョニングなしで可能
- セキュリティの向上: パブリックインターネットを排除した閉域経路を利用できる
デメリット・注意点:
- GA 時点での対応 CSP は Google Cloud のみ（Azure・OCI は 2026 年後半対応予定）
- Cloud WAN 利用時のティア計算に注意（意図せず高ティアが適用される場合がある）
- 利用可能なリージョンペアが現時点では限定的（東京リージョンは未対応）
料金と利用可能リージョン
料金体系
AWS Interconnect – multicloud・last mile ともに、時間単位の定額制を採用しています。GB 単位のデータ転送料金は発生しません。
料金を決定する 2 つの軸: 帯域幅 × 地理的ティア
料金は「接続の帯域幅」と「地理的な距離に基づくティア（Tier 1〜5）」の組み合わせで決まります。近距離ほど低ティア（安価）、遠距離ほど高ティア（高価）になります。
料金試算の参考例（公式ページより）
| 構成 | 帯域 | ティア | 時間単価 | 月額概算（730 時間） |
| US East（N. Virginia）↔ GCP N. Virginia / VGW 構成 | 10 Gbps | Tier 1（ローカル） | $12.33 / 時間 | 約 $9,001 |
| 同上 ＋ Cloud WAN（CNE に Singapore を含む） | 10 Gbps | Tier 4（ロングホール） | $51.78 / 時間 | 約 $37,799 |
Cloud WAN を使用する場合、Direct Connect Gateway に関連付けられた Core Network Edge（CNE）の中で最も遠いリージョンに基づいてティアが決定されるため、ネットワークトポロジをよく確認することが推奨されます。
参考: 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.”
（ティアは Interconnect のローカル AWS リージョンの CNE ではなく、トポロジ内で最も高いティアの CNE によって決定されます。）
利用可能リージョンとパートナー
AWS Interconnect – multicloud（GA 時点）
| AWS リージョン | GCP リージョン |
| US East（N. Virginia） | Google Cloud N. Virginia |
| US West（N. California） | Google Cloud Los Angeles |
| US West（Oregon） | Google Cloud Oregon |
| Europe（London） | Google Cloud London |
| Europe（Frankfurt） | Google Cloud Frankfurt |
※東京リージョン（ap-northeast-1）は現時点では未対応です。
AWS Interconnect – last mile（GA 時点）
| 提供リージョン | パートナー |
| US East（N. Virginia） | Lumen（ローンチパートナー） |
| 追加リージョン | AT&T・Megaport（準備中） |
参考: AWS News Blog（AWS Interconnect is now generally available）
“AWS Interconnect – last mile is launching in US East (N. Virginia) with Lumen as the initial partner. Additional partners, including AT&T and Megaport, are in progress, and additional regions are planned.”
（AWS Interconnect – last mile は、Lumen を初期パートナーとして US East（N. Virginia）でローンチします。AT&T と Megaport を含む追加パートナーも準備中であり、追加リージョンも予定されています。）
まとめ
- AWS Interconnect は、マルチクラウド接続（multicloud）とラストマイル接続（last mile）の 2 つのケイパビリティで構成されるフルマネージドのプライベート接続サービスである。
- multicloud は AWS VPC と他クラウド（GA 時点は Google Cloud のみ）を Layer 3 の閉域ネットワークで結ぶ。
- MACsec 暗号化・冗長設計・BGP 自動伝播がビルトインで提供され、手動構成と比べて設計・開通工数が大幅に削減される。
- last mile はオンプレミスからプロバイダー経由で AWS に接続し、冗長接続やジャンボフレームなどが自動プロビジョニングされる。
- 料金は時間課金（GB 転送料なし）で、帯域幅と地理的ティア（Tier 1〜5）の組み合わせで決まる。Cloud WAN 利用時はティア変動に留意することが推奨される。
- GA 時点の対応リージョンは 5 ペア（米国・欧州）。東京リージョンは未対応のため、国内での利用は今後の拡張を待つ必要がある。
以上、最後までお読みいただきありがとうございました。
