Oracle Database@AWS の利用に向けて

はじめに

2025年7月8日にOracle Database@AWS（以下Oracle@AWS）が米国東部（バージニア北部）と米国西部（オレゴン）リージョンでリリースされました。

• Oracle Database@AWS の一般提供を開始(By AWS)
• Oracle Database@AWS の一般提供開始(By Oracle)

2025年6月に行われたAWS Summitでも「まもなくGAされる」というようなお話が出ていましたが、結構速いな、という感じを受けました。このニュースリリースでも、OracleのリリースはOracleの機能を前面に出しているのに対し、AWSのリリースはAWSのサービスとの統合を前面に出している、といった特徴が見えますね。

GAとなったので、いったん私自身も整理しておこう、という意味も含めてこちらでご紹介します。どちらかというとRDS for Oracleユーザが Oracle Database@AWS を利用したい時に参照してもらえるような内容にしたいと考えてます。

• AWSの「Oracle Database@AWS」ドキュメント
• OCIの「Oracle Database@AWS」ドキュメント

AWS・Oracleの両方にドキュメントがあるので、どちらを参照したらよいか、という点に迷ってしまうことがあるかもしれません。個人的な感覚になりますが、AWSサービスとの連携の部分は AWS のドキュメントを、それ以外は OCI のドキュメントを参照すると良いと考えてます。具体的には、CloudWatchや(AWSの)IAM、LatticeなどのAWSサービスとの連携部分はAWSのドキュメントを、そうでない部分は OCIのドキュメントを参照すると良いでしょう。OCI側のドキュメントには リファレンスアーキテクチャやチュートリアル も参照することができます。

Oracle@AWSの概要

Oracle@AWSは AWS のデータセンター内に配置された OCI(Oracle Cloud Infrastructure) の Oracle Exadata Infrastructure を利用することができる、というサービスになります。

OCI上でOracle Exadata Infrastructureを利用したサービスは幾つかありますが、Oracle＠AWSとして利用できるのは次の二つになります(2025年7月時点)。

• Oracle Exadata Database Service on Dedicated Infrastructure(以下、ExaDB-D)
• 専用Exadataインフラストラクチャ上のOracle Autonomous Database(以下、ADB-D)

どちらのサービスもExadataを丸ごと利用する、占有モデルという形の提供になります。
Oracle@AzureやOracle@Google Cloudでは Autonomous Database Serverless (ADB-S) といったいわゆる 共用タイプ のモデルが利用できるのに対して、AWSでは 専用タイプのみが提供、というのには、やはり AWS では RDS for Oracle が提供されているから、というのがあるかもしれません。

ADB-DはOSへのアクセスが制限されているため、RDS for Oracle に似ているフルマネージドサービスになります。
もう片方のExaDB-DBはOSへのrootアクセスが行えるため、RDS Custom for Oracle に類似する、のように考えるとわかりやすいのではと思います。OCIの用語だと Automated という形で表現されます。

また、後ほど詳しく説明しますが、ExaDB-DやADB-Dなど占有モデルの課金構成はいわゆる 二階建て モデルになります。筐体部分（1階）と、コア課金と呼ばれるVM部分(2階)に分かれ、1階部分は基本的にデプロイしたら課金が発生します。そして、今回Oracle@AWSで利用できるExaDB-DやADB-D（筐体占有モデル）は1階部分の最低利用期間が 48時間 と定められており、個人で試しに利用しよう、という場合でも 10万円程度 は必要になりますのでご注意ください。

アーキテクチャ・ネットワーク構成

Oracle@AWSは次図のようにAWS内のあるアベイラビリティゾーン(AZ)内に限定されたサービスになります。

（引用：Oracle Database@AWSのアーキテクチャ）

そのため、物理的なAZに紐づいて提供されるサービスになります。具体的には 2025年7月現在、以下の物理的なAZでのみ提供されます。

• US East (N. Virginia):
  • use1-az4, use1-az6
• US West (Oregon)
  • usw2-az3, usw2-az4

（出典：Supported Regions for Oracle Database@AWS、リージョンごとの可用性）

Oracle＠AWSは物理的なAZに紐づいて提供されるサービスになります。Oracle@AWSは ODB Network というVPCのようなプライベートに分離されたネットワークが必要になります。
このODB NetworkはOCI Infrastructureを直接ホストするため、OCI Chile Siteに直接マッピングされます。

また、この ODB NetworkはVPCと 1:1 でODBピアリングを行うことができます。

（出典：ODB Peering）

ODB NetworkとVPCは1:1での直接ピアリングのみがサポートされるため、複数のVPCと接続したい場合にはトランジットゲートウェイを利用する必要があります。

（出典：トランジットゲートウェイ）

オンプレなどと接続したい場合には AWS Cloud WANなどと連携が可能です。

（出典：AWS Cloud WAN）

ODB Networkはネットワーク要件などもありますので、事前にご確認ください。特に ExaDB-DはIPアドレスを多く消費するため、本番で利用する場合にはネットワーク設計を行っておきましょう。

• ODBネットワーク設計

ネットワーク構成についてはOracle側も設計資料を公開しているため、そちらも参考にすると良いでしょう。

• Learn about network topologies for Oracle Database@AWS

オンボーディング

オンボーディング、とはつまるところ 購入 になります。
基本的には「プライベートオファーのリクエスト」を行い「マーケットプレイスで購入」という流れになります。アーキテクチャ図のようにOCIリージョンと紐づいてAWS内のOCI Child Siteで提供されるため、OCIのアカウント(テナンシ)も必要になります(OCIのアカウント(テナンシ)は事前に準備しておく必要はありませんが、既存のOCIのアカウント(テナンシ)を利用することも可能です)。

AWS、Oracle双方のガイドに記載がありますが、現時点ではOracleのガイドの方が画面イメージなどもあり、わかりやすいでしょう。

• オンボードBy AWS
• オンボードBy Oracle

また、Oracleのガイドには ExaDB-Dのチュートリアル も準備されています。

可用性

Oracle@AWSは簡潔に言うと三段階の可用性を提供することが可能です（筆者の定義です、Oracleの MAA(Maximam Available Architecture) に沿った定義で提供することも可能です）。

1. Oracle RAC技術を利用したAZ内部の可用性
2. Oracle Data Guard技術を利用したマルチAZの可用性
3. Oracle Data Guard技術を利用したマルチリージョンの可用性

それぞれ解説していきます。

1. Oracle RAC技術を利用したAZ内部の可用性

Oracle@AWSで提供されるExaDB-D、ADB-DはいずれもExadata Infrastructure上のサービスとなり、RACが採用されています。RACでは複数のインスタンス（仮想サーバ）が Active-Active 構成で利用できるため、一つの仮想サーバがダウンしても継続的にデータベースを利用することが可能となります。

（出典：Oracle RAC入門）

2．Oracle Data Guard技術を利用したマルチAZの可用性

同一リージョンの別AZ間で ExaDB-D もしくは ADB-D のData Guard構成を組むことで、マルチAZでの可用性を担保する形になります。
注意しないといけない点としては、RDS for Oracle などのマルチAZ構成の場合にはアプリケーション側からの接続先の変更は不要ですが、Oracle@AWSの場合には接続元のVPC側も別になるため、アプリケーション側も別のAZを利用する必要があります。
継続的に利用するためにはDBの切り替わりを検知してAZを切り替えるような仕組みが必要になります。そのため、Exadata Infrastructureのハードウェアの障害、というターゲットを絞って同一AZでの Data Guard 構成、という案を採用する場合があると考えています。

（出典：AWS re:Invent 2024-Transform your data with Oracle Database@AWS, featuring State Street (DAT246-NEW)）

3．Oracle Data Guard技術を利用したマルチリージョンの可用性

上述のData Guardの構成をリージョン跨ぎで利用する形になります。
筆者の経験上は 東京-大阪間 のリージョン跨ぎで DR の構成をとる形は非常に多いです。Autonomous Database は Autonomous Data Guardを利用することでフルマネージドの DR 構成を構築することができるので、利用しやすい構成であると考えています。

（出典：MAA Gold: リモート・スタンバイ）

なお、FSFO(Fast-Start Failover)の利用有無については各システムで整理されると良いでしょう。

おススメ可用性構成

Oracle@AWSが発表された初期から情報を追っていますが、Oracle@AWS自体は低レイテンシでのアプリケーションとデータベースでの接続を重視している構成となります。
その場合、AWSでは標準構成となるマルチAZの恩恵を受けることが難しくなります。
そのため、あえてシングルAZ・マルチリージョンの構成で可用性を高めていくのが良いと考えています。
(Oracle@AWSは利用していませんが)2024年の re:invent の Goldman Sachsの事例紹介でも、シングルAZ・マルチリージョンでレジリエンスを高めつつ低レイテンシを確保する、というような発表もあり、AZ障害はDR(マルチリージョン)で対応、という整理もアリと考えてます。

（出典：AWS re:Invent 2024 - Replatforming for reinvention: Modernizing mainframes at Goldman Sachs (FSI312)）

パフォーマンス

パフォーマンスについては最大CPUコア数とかストレージサイズ、IOPSなどについて記載するのが通常だとは思いますが、ExaDB-D/ADB-D は Exadataインフラストラクチャ 自体を並列で並べることが可能となりますので、1,000vCPU、1PBなども実装することができます。
一方でそのCPU毎にライセンスコストも必要になるため、あまりここで雑多な背景を元に有意な議論は展開できないと考えてます。

特長的な点としては、幾つか制限はありますがオンラインでCPUもストレージも増減が可能、という点になります（オートスケールはADB-Dの機能）。
そのため、必要に応じて必要なリソースを準備するような運用が可能となります。

セキュリティ

セキュリティは次の三つで説明されています。また、以下とは別にOCIのOracle Data Safeの機能を利用して管理することも可能ですが、今回は割愛します。

1. Identity and Access Management（IAM）
2. データ保護
3. コンプライアンス

それでは順に確認していきます。

1. Identity and Access Management（IAM）

AWS側とOCI側、それぞれでIAMがありますので、ごっちゃにならないようにしましょう。ここではそれぞれ AWS IAM、OCI IAM として表現します。
どちらも、基本的にはリソースそのもののデプロイやアクセスについて管理するための許認可となるため、Oracle Databaseそのものについてのアクセスなどの管理には現時点では関係しません。

AWS IAM

AWS IAMは Identity and access management for Oracle Database@AWS で説明されています。
基本的にはAWS側でリソースを作成したり変更したり、といった権限を制御する形になります。

OCI IAM

OCI IAMは アイデンティティおよびアクセス管理 で説明されています。
OCI側でのリソースの制御を担う形になります。

2．データ保護

基本的には Oracleネイティブ の仕組みで「データ暗号化」、「ネットワーク暗号化」を行うことが可能です。
AWS側のKMSなどを利用して暗号化することは現時点ではサポートされていません。
Oracleネイティブの暗号化では、OCI側の鍵管理の仕組み、OCI Vaultと統合して管理することも可能です。

• データ暗号化
  • TDE（Transparent Data Encryption）の仕組みを利用して表領域を暗号化することができます。デフォルトではOracle管理のキーにて暗号化されており、基本的には解除はできません。
• ネットワーク暗号化
  • Oracle Netのネイティブ暗号化がデフォルトでONになっています。ExaDB-Dでは解除することが可能です。また、ExaDB-Dでは別のSSL暗号化なども利用することが可能です。

3．コンプライアンス

AWS側、Oracle側双方で説明されています。

• AWS側のコンプライアンス
• Oracle側のコンプライアンス

Oracle側のドキュメントには OracleとAWS間の責任の共有 という節がありますので、一読しておくと良いかと思います。

コスト

まず、利用料金は Oracle@AWS をラリーが発表したときにも 同一価格 を強調されていた通り、OCI上での利用と 同一価格 で利用することが可能です。
BYOLやOracle Support Rewardsなども利用できるため、条件をよく確認することでお得に利用できる場合もあります。

価格の一覧は Oracle Database@AWS Pricing で参照することができます。
「どのリージョンだとどの価格なの？」という疑問がAWSユーザからは出てきそうですが、基本的にOCIは全てのリージョンで同一価格なので、このページを参照するだけで確認することが可能です。

課金体系は次のような二階建ての構成となっており、筐体部分は基本的にデプロイしている間は費用が発生します。一方で Exadata ECPU¹の部分は基本的に仮想サーバとして起動している時間だけ費用が発生する形になります(基本的にADB-Dも同じです)。

（出典：ExaDB-D 価格体系）

また、Oracle@AWSは OCI のObject Storageの他に Amazon S3 にもバックアップを取ることが可能ですが、現時点では S3 の方が二倍くらいの価格設定ですね。

	価格($/GB/Month)
Object Storage	0.0255
Amazon S3	0.051

また、請求についてはAWSに一元化され、AWSコンソール側から参照することが可能です。AWS側でタグなどを利用することで、少し細かく費用の詳細などを見ることもできるようです。

• 原価配賦タグの使用

メンテナンス

メンテナンスの部分は ExaDB-D と ADB-D で大きく異なります。
イメージとしては、ExaDB-Dはユーザ、つまり我々がメンテナンスの責任を多く持っており、適用タイミングや適用内容を決めることが可能です（スキップできないものなどもそれなりにあります）。
一方でADB-Dは（ADB-Sほどではないですが）基本的にはOracleのメンテナンスに任せる形となります。

基本的に Oracle@AWS 固有のものではないため、ExaDB-D、ADB-Dのマニュアルを参照ください。

• ExaDB-Dのメンテナンス
• ADB-Dのメンテナンス

特に ExaDB-D はレイヤとタイミングが非常に複雑ですので、どのようなメンテナンスがあるか、下図を参照ください。

（出典：ExaDB-Dのメンテナンスの種類）

バックアップ

バックアップの Oracle@AWS 固有の設定は Amazon S3 への自動バックアップの仕組みになります。この設定が デフォルト の設定になっており、そのほかにOCIの Object Storage などにもバックアップすることが可能です。

Amazon S3へのバックアップを行うためには Oracle@AWS が Amazon S3 へのアクセスを行うことができる必要があります。ODB Networkの作成時にネットワークアクセスを自動で設定 してくれます。
上述の設定がなされていることにより、expdp/impdp などを Amazon S3 経由で実施することが可能となります。
ここで、適切なポリシー（AWS IAM）を設定しないと Amazon S3 側への不要な権限が割り当てられてしまう場合もありますのでご注意ください。

バックアップの設定自体は OCI側のコンソールから設定する必要がありますのでご注意ください。こちらのドキュメントで設定方法などは解説されています。

• EBD-Dのバックアップ
• ADB-Dのバックアップ

モニタリング

大きく以下の四つのカテゴリでモニタリングを実施可能です。

1. リソースモニタリング
   • AWS の CloudWatch と統合されており、CloudWatch 側でメトリクスを確認 することが可能です
2. イベントモニタリング
   • AWS の EventBridge を利用することで、イベントをモニタリングすることが可能です。AWSのイベント、OCIの双方を EventBridgeでモニタリングすることが可能です。基本的には通常運用時にはOCIからのイベントをモニタリングすることになると想定しています
     • AWS側のドキュメント
     • OCI側のドキュメント
3. ログモニタリング
   • AWS側から監視する場合には、Enterprise Managerなどを経由してモニタリングを行う必要があります。OCI側の機能を利用するのであれば、OCI LoggingやOCI Database Managementを活用してモニタリングを行うことが可能です
4. 性能モニタリング
   • Statspackを始め、EDB-DやADB-Dなら追加料金不要で利用できる AWR や ADDM などはもちろん利用できます。OCI側の機能なら、Ops Insightなども利用することが可能です。一方で、AWS側の CloudWatch Database Insights は2025年7月時点では利用することはできません

監査

監査の観点は次の二点があると考えています。

• リソースへのアクセスに対する監査
  • AWS側のすべてのAPI呼び出しはAWSのCloudTrailにて一元的に収集・記録されます
    • AWS CloudTrailとの統合
  • OCI側のAPI呼び出しは OCI の監査（Audit）にて一元的に収集・記録されます
• データベースへのアクセスに対する監査
  • 基本的には Oracle Database の統合監査の機能を利用することになります。統合監査自体は Oracle Data Safe などとも統合されているので、そちらで管理することも可能です

トラブルシューティング

基本的にどのようなサポートについてはどちらに問い合わせるのか、というような情報は Oracle Database@AWS のトラブルシューティング に記載されています。
RDS for OracleをBYOLで利用されていた方はある程度分かると思いますが、基本的にOracle Database内部の問題についてはOracle側に、そうでないネットワークとかについての問題についてはAWS側にケースをあげるような形になるようです。

ZeroETL統合

Oracle@AWSの特長の一つとして、AWSのサービスとのZeroETL統合があげられます。
2025年7月現在、Oracle@AWSのZeroETL統合のあて先は Redshift のみとなっており、また ExaDB-D は 19c のみ(23ai不可)となっていたりするため、利用時によく確認する必要があります。

• Amazon Redshift とのゼロ ETL 統合

まとめ

Oracle Database@AWSがGAされたのを機に、今までキャッチアップしてきた情報などをまとめてみました。通常のAWSのサービスはマニュアルを参照すればよいことも多いですが、Oracle@AWSサービスは AWS のマニュアルだけでなく、OCIのマニュアル、また特にExaDB-Dは ExaDB-D 固有のマニュアルなどを参照する必要がある事も多いため、ある程度リンクとしても利用できることをイメージして記載してみました。

一部OCI側の機能については深堀していない点もありますので、その点は各自ご確認ください。また、そうはいってもこれは載せておいてほしい、とかの情報がありましたらリクエストいただければ可能な範囲で載せていきたいと考えてます。

1. Exadata X11MからExaDB-Dでも採用された、いわゆるOracleの論理CPUの単位で 1OCPU＝2vCPU＝4ECPU という形で定義されています（OCPUというのは物理コア、vCPUはスレッドのイメージになります） ↩