Database@Azure設計実践｜東京大阪Live全7サービスと費用設計

1. この記事について — AWSにもGCPにも書けないOCI最大の独自路線

Oracle Database@Azureは、Oracle純正のExadata・Autonomous Databaseのハードウェアを、Microsoft Azureのデータセンター内に物理的に設置し、Azureのネイティブサービスとしてポータル・課金・ネットワークから利用できるようにしたサービスです。AWSやGCPには存在しない、Oracleが自社製品をハイパースケーラーのデータセンターに直接持ち込む形態のマルチクラウド連携であり、2026年時点でOracleが最も力を入れている戦略領域のひとつです。本記事は、この「Oracle Database@Azure」と、それを東京リージョンからAWSやオンプレミス経由で接続するための「Interconnect for Azure」を対象に、コンソールで到達できる範囲(Marketplaceのオファーページ・オンボーディングフロー・料金構造・アーキテクチャ設計・Interconnectセットアップの流れ)を実践的に解説します。

1-1. 本記事のゴール — 全体スコープの宣言

本記事は、次の構成で§2から§9までを1本の記事として一気通貫に扱います。

• §2: 「名称の罠」— ODSA・Interconnect for Azure・Oracle Database@Azureの3層整理
• §3: Oracle Database@Azureのサービス概観(2026年現況の全7サービスとリージョン提供状況)
• §4: Marketplace Public Offerのオンボーディングフロー設計
• §5: Interconnect for Azureの接続設計とAWS実務者向けの戦略対比
• §6: 費用設計の非対称性(FastConnect/ExpressRoute費用対比)
• §7: 東京・大阪2拠点を活かした東阪DR設計
• §8: 落とし穴チェックリスト
• §9: まとめ

この記事を読み終えると、Oracle Database@Azureが提供する2026年現況の全7サービスと、東京・大阪それぞれの提供状況を正確に把握できます。また、Interconnect for Azureの接続アーキテクチャを、AWSのDirect Connect/ExpressRoute相当のサービスとして理解し、FastConnectとExpressRouteの費用構造の非対称性(ポート課金のみか、回線月額+従量課金か)を踏まえた費用試算の勘所をつかめます。さらに、東京のみ対応というInterconnectの非対称性を逆手に取った、東京・大阪2拠点でのディザスタリカバリ(DR)設計の考え方まで到達します。実際にPublic Offerからテナンシを作成し、Exadataを起動する一歩手前までの意思決定材料を、本記事だけで揃えられる状態を目指します。

1-2. 読者像

想定読者は、AWSでのマルチアカウント運用・Direct Connect設計・RDSやAuroraの運用経験を持ち、既存のOracleワークロードをAzure上で近代化したい、あるいは複数クラウドにまたがるデータベース戦略を検討しているインフラ設計者・アーキテクトです。特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• 「ODSA」「Interconnect for Azure」「Oracle Database@Azure」という似た名前のサービスは何が違うのか
• FastConnectとExpressRouteでは、どちらが費用面で有利になるのか、その分岐点はどこにあるのか
• 東京のみInterconnectが対応しているという制約の中で、大阪リージョンをどう活かせばよいのか
• Public Offerで新規テナンシが作られると聞いたが、既存のOCI運用にどう影響するのか

OCIの基礎用語(テナンシ・コンパートメント・IAM・VCN)は既に理解している前提で進めますので、初めてOCIに触れる方は後述の委譲リンクから入門シリーズを先にご覧ください。Azure側のネットワーク基礎(ExpressRoute・Virtual Network)についても、本記事では設計比較に必要な範囲のみ扱います。

1-3. 差別化軸 — 本記事が既存の解説記事と一線を画す5点

日本語圏では、Database@AzureのMarketplace作成手順やPAYG(従量課金)の概要をまとめた記事、ベンダーのサービス紹介記事は既に存在します。一方で、AWS実務者が意思決定に必要とする設計観点(ExpressRoute/FastConnect費用対比・東京限定という制約を踏まえたDR設計・費用の損益分岐)まで踏み込んだ実践記事は、2026年8月時点で見当たりませんでした。本記事は次の5点で差別化します。

1-4. 設計ガイド型で執筆する理由 — 無課金到達範囲の宣言

Oracle Database@Azureの実体はExadata専用ハードウェアであり、Public Offerからの利用開始には新規のOCIテナンシ作成とAzure Marketplaceでのサブスクリプション購入が必須です。Exadata系の課金は高額であり、かつ本ブログの既存検証テナンシとは別のテナンシ作成が前提となるため、実機を起動してオンボーディングを完走するハンズオン形式では執筆できません。この制約自体が、AWS実務者が意思決定前に必ず直面する落とし穴(§8で詳述)でもあるため、本記事ではコンソールの無課金到達範囲(Marketplaceのオファーページ表示・オンボーディングフローの画面構成・料金試算ツール・アーキテクチャドキュメント)までを設計解説の材料とし、実機の起動・接続確立の実演は行いません。

言い換えると、本記事は「実際に手を動かして構築する記事」ではなく、「導入を検討する際に必要な設計判断の材料を揃える記事」です。実機での検証結果ではなく公式ドキュメント・公式料金ページに基づく設計解説であることを前提に読み進めてください。

1-5. 前提とする知識・環境

本記事は、OCI側のテナンシ・コンパートメント・IAM・VCNといった基礎用語を理解済みであることを前提とします。未読の場合は、後述の委譲リンクから「OCI入門」シリーズを先にご覧ください。Azure側についても、Virtual Network・リソースグループといった基礎概念は既知として進めます。両クラウドの基礎を未習得の場合、本記事内の設計判断は理解できても、実際にコンソールを操作する段階でつまずく可能性があるため、まず基礎シリーズで土台を作ることをお勧めします。

なお、本記事で扱うMarketplace Public Offerのオンボーディングフロー(§4)・接続アーキテクチャ(§5)・費用試算(§6)は、いずれも公式ドキュメント・公式料金ページを一次情報として執筆しており、実機での検証結果ではありません。数値や仕様は執筆時点(2026年8月6日)のものであり、Oracle・Microsoft双方のサービスは更新が活発なため、実際の導入検討時には必ず最新の公式情報を確認してください。

1-6. 用語整理 — 本記事で使う略語

本記事全体で頻出する略語を、先にまとめて整理しておきます。

1-7. 本記事の情報源 — 一次情報リスト

本記事の記述は、次の公式一次情報を主な情報源としています(取得日: 2026年8月4日〜8月6日)。数値・仕様は執筆時点のものであり、Oracle・Microsoft双方が頻繁にアップデートを行っているため、実際の導入検討時には必ず最新情報を確認してください。

一部の公式ページは自動化ツールからのアクセスが制限されており、料金の具体的な数値がリージョン・帯域を選択して初めて動的に表示される形式のページも存在しました。このようなページについては、本記事の該当箇所(§6)で「動的表示のため確定取得できず、公式の料金計算ツールでの確認を前提とする」旨を明記しています。数値を断定できない箇所を断定調で書かないことは、本記事全体を通じて徹底しています。

1-8. 既刊との役割分担 — 委譲リンク

本記事はOCIの基礎知識やFastConnectの接続手順そのものを一から解説しません。以下の既刊に役割を委譲し、本記事は「Database@Azure特有の設計判断」に集中します。

→ OCI入門 Vol1: テナンシ・コンパートメント・リージョンとAlways Free枠
→ OCI入門 Vol3: VCN・サブネット・ゲートウェイ・セキュリティ
→ OCIネットワーク実践(Production編) Vol1: FastConnect接続実践
→ OCI Autonomous Database実践 Vol1: Always Free作成からAPEX・オートスケール設計まで

それでは、まず「名称の罠」の整理から見ていきましょう。

2. 名称の罠 — ODSA / Interconnect for Azure / Oracle Database@Azureの3層整理

Oracle × Azureのマルチクラウド連携は、これまでに複数の名称・世代を経て進化してきました。日本語の紹介記事でも名称が混同されがちなため、まず整理します。

2-1. 世代整理表

第1世代のODSAは、データベース本体は引き続きOCI側にあり、Azure側からは「Interconnect for Azureのトンネルを通してOCIのポータルを疑似的にAzureへ統合表示する」という構成でした。これに対し第2世代のOracle Database@Azureは、Exadataなどのハードウェア自体がAzureのデータセンター内に物理的に設置されるという、根本的に異なるアーキテクチャです。同じ「Oracle×Azure連携」という括りで語られるため紛らわしいですが、両者は別サービスです。

2-2. ODSAの現況 — 公式一次情報での確認結果

ODSAが正式に廃止・非推奨となっているかどうかは、本記事執筆にあたり公式一次情報(docs.oracle.com)で確認を試みました。2026年8月6日時点で、ODSA(OracleDB for Azure)の概要ページ(docs.oracle.com/en-us/iaas/Content/multicloud/odsa-overview.htm)は引き続き公開されており、サービスモデルの基本概念・クラウド間ネットワーク・IDフェデレーション・メトリクス・ポータルについての説明が掲載されています。ページ内に廃止予告・提供終了・Database@Azureへの強制移行を指示するNoteボックスなどの明示的な記述は確認できませんでした。

一方で、Oracleの現在のマーケティング・製品ページの重心は明確にOracle Database@Azure側へ移っており、ODSAの新規プロビジョニングが現時点でも案内なく可能なのか、既存利用者向けのメンテナンスのみの位置づけなのかは、公開ドキュメントの記述だけでは断定できませんでした。ドキュメントが今も公開されていることは、サービスが停止していない一つの根拠になりますが、積極的な新規採用の推奨を意味するわけではありません。

したがって本記事では、ODSAの正式な廃止時期・新規受付可否は「不明」として扱います。新規に構成を検討する場合は、後述するとおりOracle Database@Azureを選択するのが2026年時点の合理的な判断ですが、既存にODSA環境が稼働している場合は、移行の要否も含めてOracleサポートへの直接確認を推奨します。断定的な廃止時期を独自に記載することは、事実誤認のリスクがあるため本記事では行いません。

2-3. Interconnect for Azureの役割 — 両世代に共通する接続基盤

Interconnect for Azureは、OCIとAzureのバックボーンネットワークをOracle管理のトンネル接続(パブリックインターネットを経由しない専用線相当の経路)で直結する接続基盤です。ODSA・Oracle Database@Azureのどちらの構成でも、OCI側とAzure側のリソースが通信する際にはこの接続基盤を経由します。

AWSに例えると、Direct ConnectやTransit Gatewayに相当する「土台のネットワーク層」であり、この上にODSAやDatabase@Azureという「サービス層」が乗る、という2階建ての構造として理解すると整理しやすくなります。Interconnect for Azureは、顧客自身がAzure側のExpressRoute回線とOCI側のFastConnect仮想回線をペアリングして単体で構成できる接続基盤です(公式ドキュメントにセットアップ6手順が案内されています)。一方ODSAの構成では、Oracle管理のトンネルとして自動的に利用されるため、単体契約の存在に気づきにくい点も、名称が独立したサービスであるかのように見えて誤解を招きやすいポイントです。

2-4. Oracle Database@Azureの役割 — Azureネイティブなサービス層

Oracle Database@Azureは、この接続基盤の上に構築された、Azureのポータル・請求・IAM(Microsoft Entra ID)と統合されたデータベースサービスです。Azureの管理者・開発者は、OCIのコンソールやOCIの認証情報を新たに学ぶことなく、Azure Marketplaceからサブスクリプションを購入し、Azureの操作感でExadataやAutonomous Databaseを利用できます。

裏側ではOracleが管理するOCIリージョンのインフラが動いていますが、利用者からはAzureのネイティブサービスとして見える、という設計思想です。この「裏側はOCI、表側はAzure」という二重構造は、障害切り分けやサポート窓口の判断にも影響します。Azureポータル上の操作に起因する問題はMicrosoftサポート、Exadata基盤そのものに起因する問題はOracleサポートというように、問い合わせ先が事象によって分かれる可能性がある点も、運用設計時に押さえておく必要があります。

2-5. なぜこの整理が実務上重要か

AWS実務者がOracle社の紹介記事や日本語ブログを読むと、「ODSA」「Interconnect for Azure」「Database@Azure」という3つの名称が並記され、どれが現在推奨される選択肢なのかが分かりにくい場面に遭遇します。特に、2022年から2024年にかけて書かれた記事はODSAを前提にしており、2024年以降に書かれた記事はDatabase@Azureを前提にしているため、検索結果に両方の世代の記事が混在して表示される点が混乱の主因です。

本記事の結論として、2026年に新規でOracleワークロードをAzure連携させる場合は、Exadata等のハードウェアをAzure側に物理配置できるOracle Database@Azure(第2世代)を軸に検討するのが妥当です。Interconnect for Azureという接続基盤の名称は、Database@Azureのオンボーディングフロー(§4)や東京限定のリージョン制約(§3-2)を語るうえで今後も登場するため、「接続基盤の名称」として区別して読み進めてください。

2-6. 英語表記・略称の対照表

社内資料や見積もり作成の際に略称が混在しないよう、正式名称と略称の対照も整理しておきます。

2-7. タイムラインで見る提供の経緯

3世代の関係を時系列で整理すると、次のようになります(いずれも公式発表・公式ドキュメントに基づく、取得日2026年8月4日〜6日)。

• 2019年6月5日: OracleとMicrosoftがクラウド相互接続パートナーシップを発表、Interconnect提供開始(Ashburn/Azure US East)
• 2022年7月20日: Oracle Database Service for Azure(ODSA)がGA
• 2023年12月13日: Oracle Database@Azure(第2世代)が米国East USリージョンでGA
• 2025年2月13日: Oracle Database@Azureの日本提供開始(日本オラクル公式プレスリリース)
• 2025年11月時点: Oracle Database@Azureが全世界31リージョンに展開
• 2026年5月: 競合にあたるOracle Database@AWSが20 AWSリージョンへ拡大(§5-2で比較)

この時系列からも分かる通り、Database@Azureは日本提供開始から本記事執筆時点までまだ1年半程度であり、Oracleのマルチクラウド戦略の中でも展開が活発なサービスです。今後もリージョン追加・機能拡張の継続が見込まれるため、本記事の数値・提供状況は執筆時点のスナップショットとして扱ってください。

2-8. よくある誤解Q&A

3世代の名称が混在することで生じやすい誤解を、Q&A形式で整理します。

2-9. 新規導入時にどちらを検討すべきか

2026年8月時点で新規にOracle×Azure連携を検討する場合の判断材料を整理します。既にODSA環境を運用中の場合は、既存環境を維持しながら移行時期を計画的に検討するのが基本方針になりますが、新規導入であれば次の観点で判断できます。

いずれの場合も、公式ドキュメントの更新頻度が高い領域であるため、意思決定の直前には必ず最新の公式情報を再確認することをお勧めします。

2-10. サポート窓口の分岐 — 「裏側はOCI、表側はAzure」が運用に与える影響

§2-4で触れた「裏側はOCI、表側はAzure」という二重構造は、平時の操作性だけでなく、障害発生時のサポート窓口の判断にも直結します。あらかじめ運用チーム内で問い合わせ先の切り分けルールを整理しておくと、実際の障害対応時に迷いが少なくなります。

この切り分けは、単一ベンダーで完結するAWSネイティブサービスの障害対応に慣れているAWS実務者にとって、特に意識しておくべき運用差分です。契約前に、SLA・サポート範囲の分担がどちらの契約書(Oracle側/Microsoft側)に明記されるのかを確認しておくことをお勧めします。

2-11. 3層整理を実務に当てはめる — 見積もり・稟議作成時のチェック観点

ここまでの整理を、実際に社内で見積もりや稟議資料を作成する際のチェックリストとして落とし込みます。名称が3層に分かれているために、見積もり作成の担当者が異なる部署・異なるベンダー窓口に問い合わせを分散させてしまい、結果として重複した見積もりや矛盾する回答を受け取ってしまうケースが実務上発生しがちです。

これらのチェック観点は、いずれも本記事の§3以降で詳しく扱う内容の前置きです。名称の整理という一見地味な作業が、実際の見積もり・稟議プロセスの手戻りを防ぐ最初の一歩になります。

2-12. 参考 — Oracleのマルチクラウド接続戦略はAzureだけではない

Oracleは、Azureに限らずGoogle Cloudに対しても「Interconnect for Google Cloud」という同種の接続基盤を提供しています。命名パターンとしては「Interconnect for [他社クラウド名]」という接続基盤に対し、各社クラウド向けの統合サービス層(AzureであればDatabase@Azure)が乗るという、本記事で整理した2階建て構造が共通しています。つまり本記事の3層整理の考え方は、Azure固有のものではなく、Oracleがハイパースケーラー各社と結ぶマルチクラウド連携全般に共通する構造として理解しておくと、将来Google Cloud連携を検討する際にも応用できます。ただし、Google Cloud向けの構成・リージョン対応状況はAzure向けとは別物であるため、本記事の数値(東京限定など)をそのままGoogle Cloud側に当てはめることはできません。この点は必要になった時点で別途公式情報を確認してください。

2-13. Azure Marketplaceでの検索時の注意点

実際にAzure Marketplaceで検索する際にも、名称の混同がそのまま検索結果の混乱につながります。「Oracle Database Azure」といった曖昧なキーワードで検索すると、ODSA関連の古い記事・ドキュメントと、Database@Azureの最新情報が区別なく混在して表示されることがあります。社内で検索・比較する担当者には、「Oracle Database@Azure」または「Oracle AI Database@Azure」という第2世代の正式名称を明示して検索するよう周知しておくと、情報収集段階での手戻りを減らせます。また、Azure Marketplace上のオファー名は時期によって表記ゆれが生じることもあるため、最終的な契約前には必ずオファーの詳細ページで対象サービス(§3の全7サービスのどれに該当するか)を確認することをお勧めします。

2-14. 導入までのリードタイムの考え方(一般論)

専用線接続を伴うサービスは、クラウド事業者間の設定だけで完結するとは限りません。Interconnect for Azureのようなキャリア相当の接続基盤は、双方のクラウド事業者の承認プロセスや、既存のネットワーク構成との整合性確認を経て確立されるのが一般的です。Database@Azure導入プロジェクト全体で見ると、Azure Marketplaceでのサブスクリプション作成自体は短時間で完了しますが、新規OCIテナンシの初期設定、IAMフェデレーション設定、Interconnect for Azureの接続確立、そして実際のExadataリソースのプロビジョニングまでを含めると、企画立案から本番稼働まで一定の期間を要するプロジェクトとして計画する必要があります。具体的な所要日数は契約形態やリージョンの混雑状況によって変わるため、本記事では一般的な留意点の提示にとどめますが、社内のプロジェクト計画には「オンボーディングフローは6手順(§4-1)に分かれており、各手順に承認・設定作業が伴う」という前提を織り込んでおくことをお勧めします。

2-15. オンプレミスOracle経験者向けの補足

オンプレミスでOracle Databaseを運用してきたエンジニアがこの整理を読む場合、もう1つ補足しておくべき視点があります。オンプレミス版Oracle Databaseのライセンス(BYOL: Bring Your Own License)を、Database@Azure上でそのまま活用できるかどうかは、契約形態(Public Offer/Private Offer)や既存のOracleライセンス契約の内容によって扱いが変わる領域です。本記事はネットワーク・費用設計を主眼とした設計ガイドであり、ライセンス移行の詳細な可否判定までは扱いませんが、オンプレミスからの移行を検討している場合は、ネットワーク・費用の設計と並行して、既存のOracleライセンス契約担当者にBYOLの適用可否を確認しておくことをお勧めします。この点は名称の罠とは別軸の論点ですが、混同されやすいため触れておきます。

2-16. レイテンシ設計の観点(概論)

Interconnect for Azureが東京のみに対応している事実は、単に「大阪では使えない」という制約情報にとどまらず、レイテンシ設計にも影響します。OCI東京リージョンとAzure東京リージョンの物理的な距離が近いことは、専用線接続におけるレイテンシの低さに直結しやすい一方、仮に東京拠点を経由して大阪側のリソースにアクセスする迂回構成(§7-1のパターンB相当)を取る場合は、その分の追加レイテンシが発生します。オンラインでの厳密なミリ秒単位の性能はワークロードの特性によって異なるため本記事では具体的な数値を断定しませんが、レイテンシに敏感なワークロード(同期レプリケーション等)を設計する際は、経由拠点が増えるほど遅延要因が積み重なるという一般原則を踏まえ、可能な限り経由拠点を減らす構成を優先的に検討することをお勧めします。

2-17. 監視・運用ダッシュボードの分断という論点

「裏側はOCI、表側はAzure」という二重構造(§2-10)は、日常運用の監視設計にも影響します。Azureポータル中心でDatabase@Azureを運用していても、Exadata基盤そのものの詳細なメトリクスや監査ログは、OCI側のコンソール・監視サービスで確認しなければならない場面があります。既存のAzure Monitor中心の運用ダッシュボードに、OCI側の監視情報をどう統合するか(あるいは統合せずに2つのダッシュボードを併用するか)は、導入前に検討しておくべき運用設計の論点です。この点も、名称の3層整理と同じく「どちらか一方だけを見ていれば済む」という発想では見落としが生まれやすい部分であり、運用チームの体制設計時に意識しておくことをお勧めします。

2-18. セキュリティ境界の考え方

二重構造のもう一つの側面として、セキュリティ境界の設計があります。Azure側のネットワークセキュリティグループ・ファイアウォールポリシーと、OCI側のセキュリティリスト・Network Security Groupは別々に管理される設定であり、Interconnect for Azureを経由する通信であっても、双方でアクセス制御を意図通りに揃えて設定しない限り、片方だけ厳格でもう片方は緩い、といった設定の非対称が生じかねません。特にDatabase@Azureの管理用トラフィックとアプリケーションからのデータアクセス用トラフィックを同じ接続経路に混在させる構成では、双方のクラウドでポリシーをレビューする運用が重要になります。

2-19. 本章の参照関係マップ

ここまで扱ってきた論点が本記事のどの章と結びつくかを、章末に一覧としてまとめておきます。読み進める中で該当箇所に戻りたくなったときの目印として活用してください。

2-20. 既刊入門シリーズとの接続

OCI側のテナンシ・コンパートメント・IAMといった基礎用語がこの先の説明にも登場します。未読の場合は、次の既刊を先にご覧いただくことをお勧めします。

→ OCI入門 Vol2: Identity Domains・ポリシー・グループ・ダイナミックグループ

2-21. §2のまとめ — §3以降への橋渡し

ここまでで、ODSA・Interconnect for Azure・Oracle Database@Azureという3つの名称の関係、ODSAの現況、そして実務上の判断材料を整理しました。次の§3では、いよいよDatabase@Azure本体のサービス構成(全7サービス)と、東京・大阪それぞれのリージョン提供状況を具体的に見ていきます。

3. Oracle Database@Azure サービス概観 — 2026年現況の全7サービスとリージョン

3-1. 全7サービス一覧(2026年現況)

Oracle Database@Azureは、単一のサービスではなく、Exadata系からGoldenGateまでを含む7サービス群として提供されています。

3-2. 東京・大阪リージョンの提供状況とInterconnectの非対称

Oracle Database@Azureは、Azure側の東京リージョン(Japan East)・大阪リージョン(Japan West)の両方で、上記の全7サービスがLive提供されています(docs.oracle.comのDatabase@Azureリージョン表、取得日2026年8月4日時点)。一方で、これらのリージョンとOCI側を結ぶInterconnect for Azureは、東京(NRT↔Azure Tokyo)のみが対応ペアとして案内されており、大阪の対応ペアは公式リージョン表に記載がありません(docs.oracle.comのInterconnect for Azureページ、同時点取得)。つまり「Database@Azureのサービス自体は東京・大阪ともLive」だが「OCI側と専用線的に結ぶInterconnectは東京のみ」という非対称が存在します。この非対称は、後述する東阪DR設計(§7)を考えるうえで最も重要な制約です。

3-3. Public OfferとPrivate Offerの違い

Oracle Database@Azureの購入経路には、Azure Marketplaceから誰でもセルフサービスで購入できる「Public Offer」と、Oracle・Microsoftの営業担当者を介して契約する「Private Offer」の2種類があります。Public Offerを選択する場合、既存のOCIテナンシへの連携ではなく、新規のOCIテナンシ作成が前提条件になります。既に本番運用中のOCIテナンシを持つ企業が、それとは別に新規テナンシを作らなければならない点は見落としやすい落とし穴であり、§8で改めて整理します。

4. Marketplace Public Offerのオンボーディングフロー設計

4-1. オンボーディングフロー6手順の設計解説

Public Offerでの利用開始は、大まかに次の6手順で進みます。実機の起動を伴う手順のため本記事では実演しませんが、事前に流れを把握しておくことで、社内稟議や見積もり作成時の論点を洗い出せます。

4-2. 新規テナンシ要件が意味すること

③の新規テナンシ作成は、既存のOCI運用ルール(コンパートメント設計・IAMポリシー・タグ付け規約など)をゼロから再設計する必要があることを意味します。オンプレミス版OracleデータベースをAWSに移行する場合と異なり、Database@Azure導入は「OCIテナンシがもうひとつ増える」プロジェクトでもあります。既存のOCI運用チームがいる場合は、テナンシ間の統合監視・請求の一元管理をどう設計するかを事前に検討しておく必要があります。

5. Interconnect for Azure 接続設計 — AWS実務者のための対比

5-1. 接続アーキテクチャの全体像

Interconnect for Azureは、OCI側のDRG(Dynamic Routing Gateway)とAzure側のExpressRoute Gatewayを、Oracle管理のトンネルで結ぶ構成を取ります。OCI側から見ると、DRGに新しいタイプのアタッチメント(Azureへの仮想回線)が追加される形であり、既存のFastConnect・VPN・VCNピアリングと同列の接続手段のひとつとして扱われます。FastConnectの基本的な接続方式・DRGアタッチメントの種類そのものについては、既刊のネットワーク実践Vol1で詳しく解説していますので、そちらをご参照ください。

→ OCIネットワーク実践(Production編) Vol1: FastConnectによる接続実践・DRGアタッチメント設計

5-2. AWS実務者対比 — Database@AWSとの戦略対比

AWS実務者にとって直感的に理解しやすい比較対象は、AWSが2025年に開始した「Oracle Database@AWS」です。Database@AWSは2026年5月時点で20 AWSリージョンへ拡大しており、対するOracle Database@Azureは東京・大阪の2リージョンでLive、Interconnectの専用接続は東京の1リージョンのみという状況です。リージョン展開の広さでは現時点でAWS側が先行していますが、これは裏を返すと「日本国内でマルチクラウドDB戦略を検討する企業にとって、Azure連携は東京拠点への集中投資、AWS連携は多リージョン分散という、狙いの異なる選択肢」であることを意味します。単純な機能比較ではなく、自社のリージョン戦略のどちらに近いかで選ぶべき軸です。

5-3. 接続設計時の論点

Interconnect for Azureを新規に設計する場合、OCI側のDRGルートテーブル設計・Azure側のExpressRoute Gatewayのピアリング設定・双方のIPアドレス空間の重複回避が主な論点になります。特にDRGのルートテーブル設計は、既存のFastConnect・VCNピアリングと合わせて経路の優先順位を整理する必要があり、この設計原則自体は既刊のDRG設計実践の章がそのまま適用できます。

6. 費用設計の非対称性 — FastConnect/ExpressRoute費用対比と試算の勘所

6-1. FastConnectの料金構造

OCI公式のFastConnect料金FAQによれば、FastConnectはプライベートピアリングを利用する限り、契約した帯域(1Gbps・10Gbps等)に応じたポート時間課金のみが発生し、データ転送量に対する課金は方向を問わず発生しません(oracle.com/cloud/networking/fastconnect/pricing/ 記載の課金モデル。2026年8月6日確認)。具体的な1ポートあたりの時間単価はOCI公式のCost Estimatorが提供リージョン・帯域ごとに動的に算出する形式のため、本記事では概算レンジの提示に留め、契約前には必ずOCI公式のCost Estimatorで最新の単価を確認してください。

6-2. ExpressRouteの料金構造 — Metered/Unlimitedの損益分岐

Azure ExpressRouteの料金ページ(azure.microsoft.com/en-us/pricing/details/expressroute/、2026年8月6日確認)には、Meteredプラン(従量課金)のoutboundデータ転送料金がゾーン別に明記されています。

Unlimitedプランを選択した場合、これらのoutbound従量課金は発生せず、固定の月額回線料金にすべてのデータ転送が含まれます。回線自体の月額料金(Standard/Premium・帯域別)は、Azure公式サイト上でリージョン・帯域を選択すると動的に表示される形式で、自動取得ツールでは数値を確定取得できなかったため、本記事では正確な月額数値の記載を避け、Azure公式の料金計算ツールでの確認を前提とします。目安として、outbound転送量の少ない用途(管理トラフィック中心・バッチ転送が主体等)であればMeteredプラン、常時大量のデータをAzure外へ転送する用途であればUnlimitedプランが有利になる、という損益分岐の考え方自体は固定的に成り立ちます。実際の分岐点は月間の想定転送量とZoneの組み合わせで変わるため、契約前に両プランでの試算比較を必ず行ってください。

6-3. Oracle Database@Azure本体の料金

Oracle公式のDatabase@Azure料金ページの記載によれば、Database@Azureの料金はOCI上で提供されるExadata Cloud Service等の同等サービスと同一水準に設定されており、Azure MarketplaceでのMACC(Microsoft Azure Consumption Commitment)への計上が可能です。この記載はoracle.com/cloud/azure/oracle-database-at-azure/pricing/ の趣旨に基づき、2026年8月6日に確認したものです。なお同ページは自動取得ツールでの直接アクセスがブロックされたため、検索エンジンのキャッシュ経由での確認となります。つまり、Database@Azure自体の課金体系を新たに学ぶ必要はなく、OCI側のExadata価格表を土台に試算できる点は、既存のOCI利用者にとって有利です。

6-4. MACC計上の考え方

Azure中心の予算管理をしている企業にとって、Database@AzureがMACCへ計上できる点は重要な意思決定材料です。ExpressRouteの回線費用・データ転送費用もAzureの請求に統合されるため、Oracle側とAzure側で請求が分断されず、既存のAzure予算管理プロセスへそのまま組み込める設計になっています。一方でFastConnectの費用はOCI側の請求に計上されるため、テナンシをまたいだ費用の全体像を把握するには、OCI側とAzure側の請求を突き合わせる運用が必要になります。

7. 可用性・DR設計 — 東京・大阪2拠点を活かした東阪DR

7-1. Interconnect非対称を踏まえたDR設計の考え方

§3-2で整理したとおり、Database@Azure自体は東京・大阪ともLiveですが、OCI側とAzureを直結するInterconnectは東京のみです。この制約下で東阪DRを設計する場合、「Azure側の東京・大阪リージョン間でDatabase@Azureのレプリケーションを組み、OCI側との接続点は東京の1拠点に集約する」という構成が現実的な出発点になります。大阪側のDatabase@AzureとOCI側を直接専用線接続したい場合は、2026年8月時点でInterconnect単体では実現できないため、インターネット経由のVPN接続や、東京拠点を経由した迂回構成を検討する必要があります。

7-2. アーキテクチャパターンの整理

パターンAは、Interconnectの東京限定という制約をそのまま前提にできるため設計の複雑度が低く、多くのケースで最初の検討対象になります。パターンBはOCI大阪側の運用に既に習熟している組織向けの選択肢であり、既刊のAutonomous Database実践Vol1で扱った操作知識が土台になります。

→ OCI Autonomous Database実践 Vol1: Database ActionsとAPEXの操作詳細

8. 落とし穴チェックリスト

導入検討時に見落としやすい3点を、必ず確認してください。

9. まとめ — Oracle Database@Azureをどう位置づけるか

Oracle Database@Azureは、AWS・GCPのいずれにも存在しない「Oracle純正ハードウェアをハイパースケーラーのデータセンターに物理設置する」という独自路線であり、既にAzure中心の運用をしている組織にとっては、Oracleワークロードを近代化する現実的な選択肢です。本記事では、ODSA・Interconnect for Azure・Database@Azureという紛らわしい3つの名称を整理したうえで、東京・大阪の非対称なリージョン提供状況、FastConnectとExpressRouteの費用構造の違い、そして東阪DR設計の考え方までを設計ガイドとして解説しました。実際の導入検討では、本記事で挙げた3つの落とし穴(Interconnectの東京限定・新規テナンシ必須・ExpressRoute従量課金)を起点に、自社のAzure予算管理プロセスや既存OCI運用体制との整合性を確認することをお勧めします。

→ OCIネットワーク実践(Production編) Vol1を読む