はじめに

オラクルとAWSがついにタッグを組みましたね！AWSのデータセンターの中であの「OracleExadata」が動いちゃう「Oracle Database@AWS（通称ODB@AWS）」、もう試しましたか？

今回は実際に環境を作ってみて分かったことや、正直な使い心地をレポートしちゃいます！

コンパートメント作成と、「待ち時間」の話

ODB@AWSを使い始めるには、まずAWSのアカウントとOCI（Oracle Cloud Infrastructure）のテナンシーを紐づける必要があります。

その最初の一歩が、リソースを入れるための「コンパートメント」作りです。
テナンシーとコンパートメントについては、別記事[【OCIの基礎知識】 テナンシとコンパートメント]をご参照ください。

コンパートメント作りといっても実際には自動的に作成されます。
Oracle Database@AWSを利用するためにはオラクル社から提供された「サブスクリプション」を有効化する必要があります。
その有効化を行うと、テナンシー配下に自動的にODB＠AWSを利用するためのコンパートメントと子コンパートメントが作られる、という流れになります。

OCIの中はどうなってるの？

今回作ったOCI側の構成をイメージ図にしてみました。
Rootの下にプロジェクト用の箱を作って、さらにその中にODB＠AWS専用の場所を確保する、といった綺麗な整理整頓がポイントです。

待ち時間、結構かかる

ここで一つ、正直に言っておきたいのが「待ち時間」のこと。
裏側でどんな処理が走っているのか正確にはわかりませんが、OCIのテナンシーとAWSアカウントを連結する処理のためか正直
、結構時間がかかります！
ケースによってはサブスクリプションを有効化してから子コンパートメントが作られるまで数日かかるなんてこともあるようです。
子コンパートメントができるとようやくODB@AWSのコンソールでODB NetworkやExadata Infrastructureを作れるようになりますが、こちらも裏でVCNを作ったり、本格的なデータベースのインフラをデプロイしたりと、AWSのネットワークと連携してかなり重厚な処理が走っています。
そのため、セットアップ完了までも数時間かかります。
「あれ？フリーズした？」と不安になるかもしれませんが、これはAWSの中に最強のオラクル環境を物理的に準備している証拠。
ここは焦らず、コーヒーでも飲みながらゆっくり待つのが正解ですよ！
普段クラウドを使っていると忘れてしまいがちですが、数時間でAWSとOCIをネットワークで接続してExadataが作れると思うとすごい話です。

DBだけじゃない！OCIのサービスがいろいろ使えちゃう衝撃

Oracle Database@AWSは単にAWSのデータセンターにExadata Infrastructureが置かれているだけではありません。
きちんとOCIと繋がっています。
つまり、ただデータベースが使えるだけじゃないんです。
OCIが持っている便利なサービスが、AWSからまるごと使えるようになります！

OCIのカタログが全部手の届くところに！

Exadataはもちろんですが、バックアップサービスのZRCV(Zero Data Loss AutonomousRecovery Service)、Object Storageなど、OCIの全ラインナップをAWSのすぐ隣で運用できちゃいます。

「AWSのVPC内」にいるような使い心地

これまでの「クラウド同士を頑張って繋いで、遅延を気にして......」という苦労が嘘みたい。
AWSのEC2から、まるで同じ部屋にあるサーバーを叩く感覚でオラクルに触れます。
これにより例えばデータベースのバックアップをAWSに持つことも、OCIに持つことも可能です。
どちらに持つべきか、はシステム全体のバックアップ戦略やRTO/RPO、DR戦略と合わせて考えるのがベストかなと思います。このAWSでもOCIでも選べるというのがすごいところですね。

爆速！「隣のラック」にいるような低遅延

これまでのマルチクラウド接続とは、次元が違いますね。
AWSのVPCとOCIのVCNがマネージドなネットワークで接続している仕組みなので、通信の遅延（レイテンシ）は驚くほど小さいです。
ODB Peeringで直接接続したVPCからアクセスした感覚としては、物理的な距離を全く感じないレベル。
VPC内での通信とほとんど変わらないレスポンスが返ってくるので、リアルタイム性が大事なシステムでも安心して使えますね。
現状ではODB NetworkとVPCは1対1の関係で接続する必要があります（※）。
そのため、実際にはシステムを構成しようとするとTransit Gatewayの接続がほぼ必須になると思います。
Transit Gateway経由で接続するとやはり多少レイテンシは生じますが、たとえばオンプレとAWSを接続したときなどに比べれば遥かに小さいです。

※2026年2月にマルチODB Peeringの機能がリリースされ、1対多のVPC、ODB Networkを接続できるようになりました。この機能についての詳細は、[Oracle Database@AWSに待望のアップデート！Multiple ODB Peeringで柔軟なマルチAZ構成が可能に ！]を参照ください。

ちなみにAWSではリージョンによりファシリティの規模が違うので、単にリージョン内の通信といってもリージョンごとにレイテンシは変わります。
リアルタイム性が大事なシステムであれば、同一リージョンで計測することをお勧めします。

導入の流れはたったの3ステップ！

導入の手順をザックリまとめると、こんな感じです。

1. AWS Marketplaceでポチる: まずはAWS側で手続きして、OCIとの連携をスタートさせます。
※現状、ODB@AWSを利用するためには事前にオラクル社の営業への依頼が必要です。
そのあたりの営業的な手続きに関しては別記事にて記載していますのでそちらをご参照ください！

2. OCIでサブスクリプションの有効化: ここでコンパートメントが自動で作られてAWS側と連結されます。
時間がかかることもあるので、エラーがなければ気長に待ってみてください。
（ちなみにサポートに問い合わせたかんじだと毎回時間がかかるというものでもないようです...）

3. データベースを作る: 準備ができたら、AWSの画面からODB Network、Exadata Infrastructure、VMクラスターをデプロイ。裏で連携されてOCI側にVCNやExadataが作られている、という不思議な体験をすることができます。

まとめ：正直、待つ価値は十分にあります！

正直まだまだできたばかりのサービスで待ち時間がかかることもあったり安定しない部分もありますが、一度できてしまえば最強の環境が手に入ります。
AWSの柔軟さと、オラクルの圧倒的なパワーがこれ以上ない密度で融合しています。
「オラクルを使いたいけど、アプリがAWSにあるからどうしよう......」「RDS for Oracleでは要件に合わない......」と悩んでいた皆さん、これは間違いなくゲームチェンジャーですよ！

次回は実際にOracle Database@AWSを構成して、OCIのサービスと連携してみたレポートをしてみたいと思います。
お楽しみに！