AWS は 2026 年 5 月 15 日、マネージドな閉域接続サービス「AWS Interconnect - multicloud」に Oracle Cloud Infrastructure（OCI）との接続をパブリックプレビューで追加しました。2025 年 11 月末の Google Cloud 対応に続く 2 例目の対応で、2026 年後半には Microsoft Azure 接続も予定されています。年内には主要 3 大クラウドとの閉域接続が AWS マネージドの形で揃う見通しで、マルチクラウドアーキテクチャの設計指針が大きく変わろうとしています。本記事ではインフラエンジニアやアーキテクト、CIO／CTO に向けて、サービスの位置づけ、技術アーキテクチャ、AWS リソースとの連携、想定ユースケース、導入時の注意点までを実装目線で整理します。
AWS Interconnect - multicloud の位置づけと OCI 対応プレビューの意味
AWS Interconnect は、AWS と外部ロケーションを高速プライベート回線で結ぶマネージド接続サービスのファミリーです。「Interconnect - last mile」が拠点・データセンター・支社などをパートナー回線経由で AWS に取り込むのに対して、「Interconnect - multicloud」は Amazon VPC を他のパブリッククラウドの VPC と直接結ぶことを目的にしています。AWS のグローバルバックボーンで搬送し、CSP に直接ハンドオフされるため、従来必要だった物理ルータの調達、クロスコネクト発注、BGP セッションの構成といった手間がマネージド側に統合されました。
今回プレビューに加わったのが OCI 接続で、米国東部（バージニア北部、us-east-1）リージョンで提供開始されました。AWS Management Console、AWS CLI、API のいずれからもプロビジョニング可能です。2025 年 11 月末の Google Cloud プレビューに続く 2 例目で、2026 年後半には Microsoft Azure 接続も予定されています。年内には Google Cloud、Oracle Cloud、Microsoft Azure と主要 3 社の閉域接続が出揃う見込みで、「マルチクラウドを AWS のコンソールから組む」という選択肢が現実的な構成として視野に入ってきました。
これまで複数クラウド間の閉域網は、データセンター事業者の専用線やキャリアのクラウド接続を組み合わせる DIY 型が一般的でした。回線契約、ルータ調達、BGP 設計、運用監視まで自社責任で組み立てるため、構築に数週間から数か月かかることも珍しくありません。AWS Interconnect - multicloud はこの複雑さをマネージドサービスに再パッケージし、コンソール操作だけで分単位の規模で閉域接続を立ち上げられる世界を提示しています。
技術アーキテクチャと Direct Connect Gateway を起点とする閉域接続
AWS Interconnect - multicloud は、いくつかのコア概念で構成されています。中心になるのが「Interconnect」と呼ばれる接続オブジェクトで、AWS と CSP の間に張られた論理的な接続を表します。利用者は AWS コンソール上では 1 つの抽象オブジェクトとして Interconnect を扱いますが、その背後では複数の物理ルータと拠点に分散した冗長接続が動いています。AWS 側の接続点は常に Direct Connect Gateway（DXGW）です。すでに Direct Connect を運用している組織であれば、既存の DXGW をそのまま再利用してマルチクラウド接続を取り込めるため、ネットワーク設計の延長線上で計画を進められます。
接続のセットアップは「Create / Accept フロー」で進みます。一方の当事者が Create アクションを実行すると Activation Key が発行され、もう一方がこのキーで Accept を実行することで、AWS と CSP の双方で自動プロビジョニングが開始されます。当事者間で齟齬のない接続を確実に確立できる設計です。プロビジョニング自体は分単位で完了し、運用開始後も帯域はコンソールから動的に増減できます。ピーク時のスケールアップと通常時のコスト最適化を柔軟に両立できます。
仕様面では、AWS Interconnect は業界標準のオープン仕様に基づいて設計され、Google Cloud や Lumen が同等のインターフェースを採用しています。GitHub の aws/Interconnect リポジトリで仕様が公開されており、マルチクラウド接続のインターフェース統一は今後のマネージド接続サービスの方向性を左右するポイントです。
セキュリティと可用性を支える MACsec 暗号化と冗長モデル
マルチクラウド構成で最も気になるのが、回線レベルのセキュリティと可用性です。AWS Interconnect は、AWS ルータと CSP ルータ間の物理接続を IEEE 802.1AE MACsec によりデフォルトで暗号化します。暗号化セッションが確立していなければトラフィックを通さない設定になっており、運用上「暗号化を有効にし忘れる」という事故を構造的に防いでいます。アプリケーション層の TLS と組み合わせることで、レイヤ 2 とレイヤ 7 の二重の保護を担保できます。
可用性面では、各 Interconnect が少なくとも 2 つの離れた物理施設にまたがる冗長接続を自動プロビジョニングする「4-connection model」を採用しています。ECMP（Equal-Cost Multi-Path）ロードバランシングが適用され、計画停止時でも最低 1 リンクは維持される設計です。デバイス・クロスコネクト・施設レベルの単一障害点を排除する考え方がサービス標準で組み込まれている点は大きな価値といえます。
監視機能も標準で備わっています。各 Interconnect には CloudWatch Network Synthetic Monitor が追加料金なしで付属し、往復遅延とパケットロスをアクティブプローブで取得できます。閾値ベースのアラームを設定すれば SLO 観点でクラウド間の品質を可視化可能です。帯域利用率メトリクスも提供されており、輻輳兆候の早期検知と事前増強の判断に活用できます。
VPC・Transit Gateway・Cloud WAN との連携で広がる設計の幅
AWS Interconnect - multicloud は、AWS 側のさまざまなネットワーキングサービスと組み合わせて使えます。最もシンプルな構成は、VPC ごとの Virtual Private Gateway（VGW）から DXGW を経由して Interconnect に接続する形です。単一 VPC と OCI の VCN を 1 対 1 で結ぶ用途に向いています。複数 VPC を集約したい場合は、リージョン内の Transit Gateway（TGW）を DXGW にアタッチすることで、TGW 配下のすべての VPC が同じ Interconnect 経由で OCI 側に到達できる構成を取れます。リージョン単位の集約点として、運用負荷を抑えつつスケーラビリティを確保したい組織に向いた設計です。
グローバル規模で複数リージョンを跨ぐ場合は AWS Cloud WAN との組み合わせが強力です。Cloud WAN ではグローバルネットワークを定義し、各 AWS リージョンに Core Network Edge（CNE）を配置します。ネイティブの Direct Connect アタッチメントを使えば、どの CNE からでも同じ DXGW にアタッチされた Interconnect へ到達できるため、たとえばアジア圏のリージョンから OCI の米国リージョンへ、AWS グローバルバックボーン経由で閉域到達するといった広域構成も比較的シンプルに描けます。CNE と Interconnect の組み合わせは、グローバルなマルチクラウド広域網を AWS 中心で設計したい組織にとって有力な選択肢になります。
VGW か TGW か Cloud WAN かに関わらず、Interconnect は常に 1 つの抽象オブジェクトとして扱えます。設定箇所が局所化され、構成図がシンプルに保てるのは実務上のメリットです。
想定ユースケースとマルチクラウド設計の意思決定ポイント
OCI 接続で最も恩恵を受けるのは、Oracle Database をはじめ OCI 上のミッションクリティカルなデータ基盤と、AWS 上のアプリ群を組み合わせるアーキテクチャです。データベース層はライセンス・既存資産の事情から OCI、アプリ層や分析基盤、生成 AI は AWS という構成は日本企業からも関心が高い領域で、閉域でレイテンシの安定した接続を組めるかが構成の可否を左右します。
もうひとつはクラウド間の大量データ移動シナリオです。OCI 上の業務データを Amazon Redshift や Amazon SageMaker、Amazon Bedrock 配下の生成 AI に取り込み、結果を OCI に書き戻すといった往復連携です。インターネット経由ではセキュリティ・帯域・コストいずれも限界がありました。マネージドな閉域接続を素早く立ち上げられることは、データ活用の意思決定を後押しします。
規制・データ主権・セキュリティ要件が厳しい金融、医療、公共、製造などの業界でも、クラウド間を安全に結ぶ閉域接続の選択肢は重要です。日本のハイブリッドクラウド市場は 2025 年の 50 億米ドル規模から 2034 年には 198 億米ドルへ、年平均 16.43% で拡大すると予測されており、マネージドな閉域接続の整備は実装面でのキードライバーになります。
導入時のチェックポイントとプレビュー利用上の留意点
実際にプレビュー段階で AWS Interconnect - multicloud（OCI）を検証するにあたって押さえておきたいポイントを整理します。まずリージョン制約として、現時点で利用できるのは us-east-1（バージニア北部）のみです。本番ワークロードの主要リージョンが他にある場合は、PoC 用途の構成として位置づけ、GA 時の対応リージョン拡大を待つのが現実的な進め方になります。Cloud WAN を活用すれば他リージョンの CNE からの到達は可能ですが、レイテンシ要件は事前に CloudWatch Network Synthetic Monitor で実測しておくべきでしょう。
OCI 側の準備も重要です。AWS 側がマネージドであっても、OCI 側のネットワーク設計やルーティングは利用者が責任を持って構成する必要があります。OCI の FastConnect や Dynamic Routing Gateway（DRG）との整合性、サブネット設計、ルートテーブル、セキュリティリストの整理を事前に行っておくと、Activation Key の Accept 後にスムーズに疎通確認まで進められます。
運用面では、コンソールから帯域を変更できる特性を活かし、初期は控えめな帯域でスタートして CloudWatch の利用率メトリクスを見ながら段階的に増強するアプローチが取りやすくなっています。Network Synthetic Monitor のアラームを Amazon SNS や Slack 連携につなげば、品質劣化の早期検知体制も作れます。プレビュー期間中は仕様変更が入る可能性もあるため、本番投入のタイミングは GA 後を見据えるのが安全です。
マルチクラウドの実装はこれまで「やる価値はあるが、ネットワーク基盤の構築が重い」という壁が常にありました。AWS Interconnect - multicloud が OCI、Google Cloud、やがて Microsoft Azure までを射程に収めることで、この壁は確実に低くなっていきます。OCI 上の業務システムや Oracle Database 資産を活かしつつ AWS の幅広いサービスと組み合わせたい組織にとって、いまはアーキテクチャ再評価を始めるよい機会です。プレビュー段階から検証を進め、GA 後の本番展開に向けて自社の構成標準を磨いておく価値は十分にあります。
