AWS×Oracle Cloud閉域網直結プレビュー解説｜Interconnect-multicloud OCI対応の技術的意義とコスト試算【2026年5月版】

「AWSとOracle Cloudをマルチクラウドで使いたいが、回線をどう引くかで毎回詰まる」
オンプレでルーターとL2スイッチを触ってきた感覚で考えると、クラウド間接続は「インターネット経由は遅延と漏えいリスクが怖い」「VPNはスループットが頭打ち」「Direct ConnectとFastConnectを2本立てるとコロケーション契約と運用が二重化する」の3点で進まなくなります。

この記事では、2026年5月15日にAWSがプレビュー公開した「AWS Interconnect – multicloud」のOracle Cloud Infrastructure（OCI）対応を一次情報ベースで整理し、閉域網直結が技術的に何を変えるか、既存のVPN／インターネット経由／Direct Connect＋FastConnect併用と比べてコストと運用がどう動くかを、AWS／OCIを併用する現場の視点で解説します。執筆時点（2026年5月）の公開情報に基づくため、本番採用前にAWS／Oracle双方の最新ドキュメントで再確認してください。

2026年5月、AWS×OCI閉域網直結プレビューで何が発表されたか

まず一次情報を整理します。憶測や伝聞ではなく、AWS公式とOracle公式の発表内容のみを並べます。

AWSは2026年4月14日、マルチクラウド接続専用サービス「AWS Interconnect – multicloud」を一般提供（GA）として開始しました。先行GA対象はGoogle Cloudで、米国・欧州の5リージョンペア（US East (N. Virginia)、US West (N. California)、US West (Oregon)、Europe (London)、Europe (Frankfurt)）で利用可能です。続いて2026年5月15日、Oracle Cloud Infrastructure（OCI）向けのプレビュー提供を発表し、AWS側の対応リージョンは US East (N. Virginia)（us-east-1）からスタートしています。Microsoft Azure対応は2026年後半に追加予定とされています。

Oracle側は2026年4月16日のプレスリリースで、OCIの「Oracle Interconnect」とAWS Interconnect – multicloudを組み合わせ、エンタープライズ向けの高性能なプライベート接続をAWS とOCI間で提供する方針を発表しました。設計の特徴は3点です。
・物理回線の二重契約が不要: 従来は Direct Connect（AWS）と FastConnect（OCI）を別々に契約・運用する必要があった
・マネージドな閉域網: コロケーション事業者経由の物理結線をAWSがマネージする形に集約
・OCI側の対向は Oracle Interconnect: OCI内のVCN（Virtual Cloud Network）に対して、AWS側からプライベート経路で到達できる

AWS Interconnect – multicloudの設定は3ステップで完結します。
・ステップ1: 接続先クラウドプロバイダーを指定（OCI/Google Cloud/将来Azure）
・ステップ2: 対向側のリージョンを選択
・ステップ3: 必要な帯域を選択

これだけで4-way冗長構成のプライベート接続が自動構成され、BGPルーティング・MACsec暗号化・Jumbo Framesがデフォルトで有効になります。Last-mile接続側のSLAは99.99%可用性で公開されています（multicloud側の個別SLA値は公式ページ上明示なし、本番採用前に最新のSLAドキュメント確認を推奨）。

執筆時点で公開されていない情報も明確にしておきます。multicloud側の具体的な時間単価、OCI側の対向リージョン名、東京リージョン（ap-northeast-1）対応時期、プレビュー参加の細則は公式ページ上で明示されていません。本記事のコスト試算は公開済みのLast-mile側料金構造（時間あたりフラット課金）と一般的なクラウド間データ転送料金の傾向から組み立てたレンジで、実額の見積りは公式料金ページとAWSアカウントチームへの問い合わせで確認してください。

閉域網直結が技術的に何を変えるか（インターネット経由・VPN・Direct Connect併用との比較）

「閉域網直結」と書くと曖昧ですが、AWS Interconnect – multicloudが解決するのは「マルチクラウド間トラフィックを、インターネット網に出さず、物理層も二重契約せずに、マネージドサービスとして引く」という3点です。実際にAWSとOCIを組み合わせる現場で選択肢になる4方式を、表で並べます。

インフラエンジニア視点で押さえるべき差分は3つです。

1つ目は、物理層の二重契約が不要になる点です。従来構成では、AWS側に Direct Connect用のコロケーション契約、OCI側に FastConnect用のコロケーション契約を別々に維持する必要がありました。請求書・運用窓口・障害対応の窓口が分かれ、回線増設のたびに両ベンダーへの調整が走ります。AWS Interconnect – multicloudは、この二重契約をAWS側に集約し、OCI側からは Oracle Interconnect として見える構成に置き換えます。

2つ目は、暗号化と冗長化が「組み込み」になる点です。MACsec暗号化はデフォルトで有効、4-way冗長が built-in で構成されるため、「暗号化を有効にし忘れる」「シングルパスで運用していて回線片寄せで止まる」といったヒューマンエラーが構造的に発生しません。Last-mile仕様の99.99%可用性SLAも公開済みで、運用設計のSLO線が引きやすくなります。

3つ目は、プライベート経路でAWSの主要ネットワークサービスに繋ぎ込める点です。AWS Interconnect – multicloud側からは Amazon VPC、AWS Transit Gateway、AWS Cloud WAN の3つに対してプライベートで到達できる設計です。複数リージョン・複数VPCへの配線も Transit Gateway／Cloud WAN を経由して一括で扱えるため、PoCから本番拡張へのスケールパスが直線的になります。

逆に、インターネット経由やVPNが残る場面もあります。検証フェーズで一時的にAPI疎通だけ取りたい場合や、トラフィック量が小さく専用回線のコストが正当化できない場合は、インターネット経由＋TLS、または Site-to-Site VPN の方が初期費用と運用負荷の両面で適しています。マルチクラウド接続の判断は「常に閉域網直結が正解」ではなく、トラフィック量・遅延要件・データ機密度の3軸で選択するのが現実的です。

代表ユースケース：既存OracleDB×AWSサービスのハイブリッド3パターン

AWS×OCI閉域網直結が刺さるユースケースは、すでにOCI上でOracle Databaseを動かしていて、AWS側のサービス（生成AI、データ分析、マネージドアプリ基盤など）と組み合わせたい現場です。Oracle Database@AWS のような同居型構成とは別軸で、「OCIにOracleDBを残したまま、AWS側のサービスから読みに行く」型を中心に整理します。

1. OCIのOracle DatabaseをAWS側の分析・生成AI基盤から参照する

OCI上の Oracle Exadata / Autonomous Database をマスターとして残し、AWS側の Amazon Athena / Amazon Redshift / Amazon SageMaker / Amazon Bedrock から読み取り専用で参照する構成です。閉域網直結により、機密データを含むクエリ結果がインターネット網に出ません。
・連携経路: AWS Interconnect – multicloud → AWS Transit Gateway → 各VPC → Athena/Redshift/SageMaker等
・転送量の鉄則: 生データ全件転送ではなく、OCI側でビュー・集計・サニタイズを通したデータのみ転送
・権限境界: OCI側のDB権限をAWS側に持ち込めないため、IAMロール・接続ユーザー・参照可能ビューの対応表を最初に文書化

2. ハイブリッド災害対策（OCIで本番、AWSでDR）

本番系をOCI（Exadata/Autonomous Database）に置きつつ、AWS側を災害対策（DR）サイトとして待機させる構成です。日常時はLast-mile経由でレプリケーションが流れ、フェイルオーバー時はAWS側のEC2・RDSにアプリが切り替わります。
・レプリケーション: Oracle GoldenGate / Data Pump 等を閉域網経由で流す
・RPO/RTO設計: 帯域選択時に、ピーク時のレプリ流量＋業務トラフィックを試算
・監査要件: 金融・公共系でDR要件がある業界は、暗号化方式（MACsec＋アプリ層）の二重化を要件定義に明記

3. 既存OracleアプリのAWS段階移行

OCI上のOracle E-Business Suite / JD Edwards / PeopleSoft 等の既存アプリを、AWS側に段階的に切り出していくシナリオです。アプリは段階移行、データベースはOCI側に残置という構成が現実的で、閉域網直結によりアプリとDBの分離運用が可能になります。
・段階1: フロント・ミドル層をAWS（ECS/EKS/EC2）に展開、DBはOCI側のまま
・段階2: トラフィック分析でAWS側へ寄せられる機能から個別マイグレーション
・段階3: 機密性・ライセンス条件で残すDBはOCIに残置、それ以外はAWS側DBへ集約

このパターンで重要なのは、ライセンス条件です。Oracle Database のクラウド利用ライセンス（BYOL／License Included）はクラウドベンダーごとに条件が異なるため、移行設計と並行してOracleのライセンスチームへの確認が必須です。

設定パスとコスト試算（2026年5月時点の公開情報ベース）

設定の流れと、月額コストの目安レンジを整理します。コストはAWS側の公開情報と一般的なクラウド間データ転送傾向から組み立てたレンジで、実額は本番採用前に必ず公式料金ページとAWSアカウントチームで確認してください。

設定パスの概要

AWS Interconnect – multicloudの構成は、AWSマネジメントコンソール・AWS CLI・AWS APIから3ステップで作成できます。
・ステップ1: マネジメントコンソールで Interconnect – multicloud を選択し、ターゲットを OCI に指定
・ステップ2: 対向リージョン（プレビュー時点は us-east-1）を選択
・ステップ3: 帯域を選択し、Transit Gateway / Cloud WAN / VPCのいずれかにアタッチ

OCI側は、Oracle Interconnect for AWS を有効化し、対向のAWS Interconnect IDを紐づける形になります。OCIコンソールの「Interconnect」セクションから、対象VCNに対してアタッチを実施します。BGPルーティングは双方向で自動構成され、4-way冗長が組み込みで構成されます。

以下は公式ドキュメントの記載ベースで起こしたCLI操作の参考例です。実構築時は最新の公式リファレンスを参照してください。

# AWS CLI（Interconnect - multicloud作成・例示）
aws interconnect create-multicloud-connection \
  --target-provider OCI \
  --target-region us-ashburn-1 \
  --bandwidth 1Gbps \
  --attach-target arn:aws:ec2:us-east-1:<account>:transit-gateway/<tgw-id>

# 状態確認
aws interconnect describe-multicloud-connections --connection-id <conn-id>

OCI側はOCI CLIで Oracle Interconnect for AWS のアタッチを実行する形になります。具体的なサブコマンドは執筆時点で正式リファレンスが公開され始めた段階のため、必ず最新の Oracle Cloud Documentation を参照してください。

コスト試算の目安レンジ

執筆時点（2026年5月）の公開情報に基づく、月額レンジの試算です。AWS Interconnect – multicloud側の単価は公式に明示されていないため、Last-mile仕様の料金構造（時間あたりフラット課金、帯域選択）と、AWS Direct Connect・Amazon VPCのクラウド間データ転送料金傾向を組み合わせたレンジで示します。

比較対象として、インターネット経由の場合は通信費自体は安価ですが、機密データを扱う場合の暗号化・WAF・IDS等の周辺コスト、遅延に起因するアプリ側の待機時間コストが乗ります。Site-to-Site VPNはトンネルあたり1.25Gbps程度が上限で、本番トラフィックには帯域不足になりがちです。Direct Connect＋FastConnect併用は、コロケーション契約料・物理クロスコネクト料が二重で発生するため、トラフィック量が中規模を超えると AWS Interconnect – multicloud の方がトータルで安価になる傾向があります。

コスト試算で外しやすい3点を補足します。
・egress（下り）料金: AWS→OCI方向のデータ転送に料金が発生（インターネット経由より単価が下がる傾向だが、量で総額が動く）
・稼働時間: 時間課金のため、検証目的で立てたまま放置すると無駄が出る（停止・削除運用を整備）
・運用要員コスト: マネージドサービスでも、ネットワーク設計者・DBA・セキュリティ担当の人件費は別途必要

導入検討の進め方とFAQ

ここまでの内容を踏まえて、AWS Interconnect – multicloud（OCI Preview）を検討する場合の進め方を整理します。

検討段階で押さえるべきポイントは5つです。
・トラフィック量と機密度の把握: 1か月のクラウド間転送量、機密データの割合、暗号化要件を最初に整理
・対向リージョンの確認: 現時点ではAWS側 us-east-1 から開始。東京リージョン対応時期は未公開のため、業務要件と整合するか確認
・プレビュー段階の運用リスク: 本番採用は GA 移行後を基本に、プレビュー期間は検証・PoC用途で活用
・ライセンス整合性: Oracle Database のクラウド利用ライセンス条件をOracleのライセンスチームと突合
・既存Direct Connect/FastConnectからの移行設計: 既存回線がある場合、切替期間中の冗長構成・切戻し手順を計画

姉妹サイト LinuxMaster.JP ではAWS EC2上のLinuxサーバー運用、SecurityMasters.TOKYO ではIAM・VPCのセキュリティ設計を扱っています。マルチクラウド接続を実装する際は、認証境界・ネットワーク境界の設計も合わせて進めることをおすすめします。

FAQ

Q1. プレビューはどう申し込めば良いですか

AWS公式の発表では、AWSマネジメントコンソール・AWS CLI・AWS APIから作成可能とされており、専用の申込フォームURLは公式ページに明示されていません。詳細手順は AWS Interconnect – multicloud のドキュメントとAWSアカウントチームへの問い合わせで確認してください。

Q2. 東京リージョン（ap-northeast-1）には対応していますか

執筆時点で、AWS Interconnect – multicloud のOCI Preview対応リージョンはAWS側が US East (N. Virginia)（us-east-1）です。東京リージョン対応時期は公開情報に明示されていません。日本国内のOCI ⇔ AWS閉域接続は、当面 Direct Connect ＋ FastConnect の併用構成が現実的です。

Q3. Microsoft Azureとの接続はいつから使えますか

AWS公式では「2026年後半（later in 2026）」予定とされています。OCIプレビューと同様、Microsoft Azure側の対応も含めて段階的に追加される見込みです。

Q4. Direct Connect / FastConnect とは何が違いますか

Direct Connect は AWS とユーザー拠点（オンプレ・コロケーション）を結ぶ単一クラウド向けの専用接続です。FastConnect は OCI 側の同等サービスです。AWS Interconnect – multicloud は、これら2つのクラウド間を直接結ぶ専用サービスで、ユーザーが両方のコロケーション契約を持つ必要がありません。マネージドサービスとして AWS が物理層・暗号化・冗長化を組み込みで提供します。

Q5. 既存のVPNからの移行はどう進めますか

既存のSite-to-Site VPNを使っている場合は、AWS Interconnect – multicloud を別経路として並行構築し、BGPで段階的にトラフィックを寄せる方法が安全です。切戻し手段としてVPN経路を一定期間残し、切替後のレイテンシ・スループットを実測してから完全切替するのが定石です。

Q6. プレビュー期間の障害対応はどうなりますか

プレビュー期間中はGA時のSLA水準が保証されない場合があります。AWS公式のプレビュー条件・サポート範囲を契約時に確認し、PoC・検証用途に限定して運用するのが安全です。本番採用は GA 移行を待つ判断が一般的です。

本記事のまとめ

2026年5月15日にプレビュー公開された AWS Interconnect – multicloud のOCI対応は、AWSとOCIをマルチクラウドで併用する現場にとって、回線構築の難易度を大きく下げる発表です。Direct ConnectとFastConnectの二重契約から、AWSマネージドの閉域網サービスへの集約という構造変化で、暗号化・冗長化・BGPルーティングがデフォルトで組み込まれます。

一方で、執筆時点ではAWS側のus-east-1のみ対応、東京リージョン対応時期は未公開、multicloud側の具体的な料金単価も非開示という状態です。本番採用は GA 移行を待ち、プレビュー期間は PoC・検証用途で「実際にどのトラフィックが閉域網に乗るか」「コストレンジが見立てと合うか」を測る期間として使うのが現実的な進め方です。

オンプレ経験のあるインフラエンジニアにとって、マルチクラウド接続は「物理回線×2＋運用窓口×2＋障害対応窓口×2」が長く悩みの種でした。マネージドサービスへの集約はその構造を変える発表で、今後Azure対応・日本リージョン展開が進めば、マルチクラウドの設計選択肢が一段増えることになります。

あわせて読みたい本