AWS上でOracle Databaseを動かす方法は、Amazon RDS for Oracle、EC2への自前インストール、そして2025年12月に東京リージョンで提供が始まったOracle Database@AWSの3つに整理できます。どれを選ぶかは機能要件だけで決まりません。Oracleが公開しているクラウド向けライセンスポリシーの数え方によって、必要なProcessorライセンス数とインスタンスサイズの上限が変わるためです。ここでは3つの選択肢の境界線を引いたうえで、東京リージョンの実額とライセンス計算の原則を一次情報から確認します。
まとめ：3つの選択肢の使い分けと費用の要点
ExadataやOracle Real Application Clusters（RAC）が要件に入るなら選択肢はOracle Database@AWSだけです。Amazon RDS for OracleはRACに対応せず、AWSはよくある質問で「いいえ、RAC は現在サポートされていません」と明記しています。逆に、標準的な単体DBでよければRDS for Oracleが運用負荷の面で有利で、OSレベルの介入やRDSが制限する権限が必要な場合にEC2が残ります。
費用面では、ライセンスの持ち込み（BYOL）が効くかどうかが最大の分岐点です。東京リージョンのdb.m5.large（2 vCPU、8 GiB、シングルAZ）で比べると、Standard Edition 2のライセンス込みが1時間あたり0.514 USDなのに対し、同じインスタンスのBYOLは0.235 USD。月730時間換算で203.67 USDの差が出ます。そしてAWS上でBYOLする際のライセンス数は、オンプレミスのコア係数ではなくvCPU数から機械的に決まります。
AWS上でOracle Databaseを動かす3つの選択肢
3つの境界は、どこまでをOracleとAWSのどちらが管理するかで引かれます。RDS for OracleはAWSのマネージドサービス、EC2は利用者の自己管理、Oracle Database@AWSはAWSのデータセンター内に置かれたOracle管理のExadataインフラです。
| 比較軸 | RDS for Oracle | EC2上のOracle | Oracle Database@AWS |
|---|---|---|---|
| OSへのアクセス | 不可 | フルアクセス | 不可（Oracle管理） |
| Oracle RAC | 非対応 | 非対応（AWS未サポート） | 対応 |
| Exadata機能 | なし | なし | あり |
| ライセンス込み | SE2のみ | なし（BYOLのみ） | あり（EE機能パック同梱） |
| BYOL対応エディション | EE、SE2 | EE、SE2 | EE、SE2 |
| 日本の提供リージョン | 東京、大阪 | 東京、大阪 | 東京、大阪 |
| 購入経路 | AWSコンソール | AWSコンソール | AWS Marketplace |
費用設計で最初に見るのは「ライセンス込み」の行です。RDS for Oracleでライセンス込みを選べるのはStandard Edition 2だけで、Enterprise Editionは必ず自前のライセンス持ち込みになります。
Amazon RDS for Oracleの守備範囲と、できないこと
RDS for Oracleの制約は、AWSのドキュメントが理由まで含めて明示しています。「マネージドサービスエクスペリエンスを提供するために、Amazon RDS は DB インスタンスへのシェルアクセスを提供していません。また、高度な特権を必要とする、特定のシステムプロシージャやテーブルへのアクセスも制限しています」という設計方針です。つまり、SYSDBA相当の操作やOSレベルのファイル操作を前提とした運用手順、独自のカーネルパラメータ調整、Oracle純正のクラスタ構成は、いずれもRDSでは実現できません。
高可用性はRACではなくMulti-AZ配置で担保します。ここに見落としやすいコストがあり、BYOLでMulti-AZを組む場合はプライマリとスタンバイの両方にライセンスが必要です。スタンバイは待機系だから不要、という判断は成立しません。
エディションの移行方向にも制約があります。未使用のBYOLライセンスがあればスナップショット経由でStandard Edition 2からEnterprise Editionへ移せますが、Enterprise Editionから他のエディションへ戻すことはできません。BYOL運用時のライセンス使用状況は、AWS License ManagerがエンジンエディションとライセンスパックをそれぞれvCPU単位で追跡します。
EC2上にOracleを立てる判断基準
EC2を選ぶ理由は、RDSが閉じている領域が要件に含まれるとき、この一点に絞られます。具体的には、OSへの完全アクセスを前提とした既存の運用スクリプト、RDSがサポートしないOracleオプションやバージョンの利用、監査要件でOS層のログ取得が必須といったケースです。それ以外の理由でEC2を選ぶと、パッチ適用・バックアップ・フェイルオーバーの実装をすべて自前で抱え込むことになり、RDSとの差はそのまま運用工数の差になります。
EC2上のOracleにライセンス込みモデルは存在せず、BYOLだけが選択肢です。そのため次章のvCPU換算がそのままライセンス費用に直結します。ここでインスタンスタイプを大きく取りすぎると、AWSの利用料より先にOracleのライセンス費用が跳ね上がります。
Oracle Database@AWSでしか満たせない要件
Oracle Database@AWS（OCI側の現在の名称はOracle AI Database@AWS）は、AWSのデータセンター内にOCIが管理するExadataインフラを配置し、AWSのコンソール・API・CLIから操作できるようにしたサービスです。Exadataの機能とOracle RACをAWSリージョン内で使えるのは現状この経路だけで、オンプレミスのExadataからそのまま移す場合もアプリケーション側の改修を最小限に抑えられます。
提供されるのは4系統のデータベースサービスです。専有インフラ上のOracle Exadata Database Service（ExaDB-D）、Exascaleインフラ上のExaDB-XS、専有Exadataインフラ上のOracle Autonomous AI Database、そしてサーバーレスのAutonomous AI Database Serverless（ADB-S）。いずれも19cと26aiに対応します。バックアップ用途にはOracle Database Autonomous Recovery Serviceも用意されています。
Exadataインフラは論理的にはOCIリージョンに、物理的にはAWSリージョンに存在します。AWSのAZ内に置かれた「OCI子サイト」がOCIのアベイラビリティ・ドメインを延伸する形で、ハードウェアの調達と維持はOCIが担います。OCI側の全体像はOracle Cloud Infrastructure（OCI）とは？サービス構成・料金の実額とAWSとの違いを実装者目線で解説【2026年8月時点】で整理しています。
Oracle Database@AWSの提供リージョンとネットワーク構成
導入検討で最初に確認すべきなのは、使いたいAZで実際に提供されているかどうかです。このサービスはリージョン単位ではなくAZ単位で提供範囲が決まっており、日本の2リージョンでも条件が異なります。
東京は2つのAZ、大阪は1つのAZ
東京リージョンでの提供開始は2025年12月、日本市場向けの正式発表が2026年2月5日でした。大阪リージョンは2026年5月29日に8リージョンが一括追加された際に加わり、この時点で世界20リージョンに達しています。2026年9月時点のAWSドキュメントでは、対応リージョンはさらに増えて22リージョンです。
| リージョン | リージョンコード | 対応AZ | 提供開始 |
|---|---|---|---|
| アジアパシフィック（東京） | ap-northeast-1 | apne1-az1、apne1-az4 | 2025年12月 |
| アジアパシフィック（大阪） | ap-northeast-3 | apne3-az2 | 2026年5月29日 |
大阪の対応AZが1つしかない点は、DR構成を組むときに効いてきます。ODBネットワークは作成時に指定したAZに固定されるため、大阪リージョン内でAZを分けた冗長構成は現時点では組めません。国内で地理的に離れた冗長性を求めるなら、東京と大阪をまたぐ構成が前提になります。
ODBネットワークとODBピアリングの構成
Exadataインフラは、ODBネットワークと呼ばれるAWS管理の分離されたプライベートネットワークに配置されます。既定ではどのVPCにも接続されておらず、アプリケーションから到達させるにはODBピアリングを作成します。これはVPCピアリングとは別のリソースで、リソースIDの接頭辞はodbpcx-です。
1つのODBネットワークが張れる直接ピアリングは最大45本で、複数のVPCへ同時に接続できます。45本を超える場合や、複数VPCからの経路を一元管理したい場合はAWS Transit GatewayまたはAWS Cloud WANを挟み、ODBネットワークとピアリングしたVPCをハブに接続する構成を取ります。マルチクラウド接続全般の設計軸はAWS Interconnect – multicloudとは？対応リージョンと料金Tier・Direct Connectとの役割分担で扱っています。
ルーティングの初期設定には注意点があります。ODBピアリング作成時にVPCルートテーブルのIDを渡せば、ODBネットワークのCIDRがそのルートテーブルへ自動設定されます。IDを渡さない選択をした場合は、Amazon EC2のcreate-routeコマンドでVPC側のルートを手動追加しないと疎通しません。なおODBネットワーク側のルートテーブルへのVPC CIDR登録は、いずれの場合も自動で行われます。AWS Resource Access Managerを使えば、あるアカウントのODBネットワークを別アカウントのVPCとピアリングすることもできます。
サービスごとに異なる購入経路
購入方法はAWS Marketplace経由で統一されていますが、Oracleの営業担当を介す必要があるかどうかはサービスによって違います。ExaDB-DとAutonomous AI Database on Dedicated Exadata Infrastructureはプライベートオファー限定で、Oracleの営業担当に連絡して個別の価格合意を結んだうえでMarketplaceにオファーが出る流れです。一方、ExaDB-XSとAutonomous AI Database Serverlessは公開オファーがあり、営業担当を介さず直接サブスクライブできます。
特にExaDB-XSは8 ECPUと300 GBのストレージから始められ、コンピュートとストレージを独立してスケールできます。専有インフラを前払いで確保せずに済むため、検証や小規模導入の入口として現実的です。
AWS上でのOracleライセンスの数え方
BYOLを選ぶなら、ここが費用試算の中心になります。Oracleは「Licensing Oracle Software in the Cloud Computing Environment」というポリシー文書で、認定クラウド環境（Authorized Cloud Environments）でのライセンス計算方法を定めています。2026年9月4日時点の版で認定されているのは、Amazon Web Services（Amazon EC2とAmazon RDS）、Microsoft Azure Platform、Google Cloud Platformの3社です。なお同文書には教育目的であり契約を構成しないという但し書きがあるため、実際の調達時は契約書とOracleの担当に確認してください。
vCPU換算とCore Factor表の不適用
認定クラウド環境では、インスタンスタイプの最大利用可能vCPU数を数えます。EC2とRDSの場合、プロセッサコアのマルチスレッドが有効なら2 vCPUを1 Oracle Processorライセンスと数え、無効なら1 vCPUで1ライセンスです。文書自身が挙げている例では、マルチスレッドが有効な4 vCPUのインスタンス1台でEnterprise Editionを使うと、必要なProcessorライセンスは2つになります。
ここで最も見落とされるのが、認定クラウド環境ではOracle Processor Core Factor Tableが適用されないという一文です。オンプレミスのx86サーバーでは係数0.5が掛かってコア数の半分で済んでいたものが、AWS上では係数による割引が存在しません。オンプレミスの見積もりをそのまま持ち込むと、必要ライセンス数を読み違えます。
Standard Edition 2の8 vCPU上限とNamed User Plus最小数
Standard Edition系は数え方そのものが変わり、インスタンスサイズに基づくソケット換算になります。4 vCPU以下のインスタンスは1ソケットとして扱われ、これがOracle Processorライセンス1つに相当します。4 vCPUを超える場合は、4 vCPU単位に切り上げて1ソケットずつ加算します。
そして上限があります。Standard Edition 2を認定クラウド環境でライセンスできるのは最大8 Amazon vCPUまでです（旧Standard Editionは16 vCPUまで）。db.m5.2xlarge以上のインスタンスにStandard Edition 2を載せる構成は、このポリシー上成立しません。将来的なスケールアップを見込むなら、この8 vCPUの天井を先に確認しておく必要があります。Named User Plusメトリックで数える場合の最小数は、8 Amazon vCPUあたり10 NUPライセンスです。
ULAライセンスをAWSで使うときの落とし穴
Unlimited License Agreement（ULA）を締結している場合は、契約期間中に取得したライセンスを認定クラウド環境で使うこと自体は認められています。ただし同じ文書に、顧客はそれらのライセンスをULA期間終了時のcertificationに含めることができない、と明記されています。
これは実務上かなり重い制約です。ULAの終盤は、期間中に展開した本数を申告して永久ライセンスへ確定させるcertificationが最大の山場になりますが、AWS上に展開した分はその数に算入できません。ULA終了を控えた時期に「使い放題のうちにクラウドへ大量展開しておく」という判断は、certificationの観点では逆効果になります。ULA満了が近いなら、AWSへの移行はcertification完了後に設計するのが筋です。
料金の実額：東京リージョンの単価と課金モデル
ここまでの選択がコストにどう跳ね返るかを、実額で確認します。以下はAWS Price List APIから取得した東京リージョン（ap-northeast-1）のオンデマンド単価で、2026年9月4日時点の価格表に基づきます。
ライセンス込みとBYOLの時間単価差
| 構成 | エディション | ライセンス | 時間単価（USD） | 730時間換算 |
|---|---|---|---|---|
| RDS for Oracle | SE2 | ライセンス込み | 0.514 | 375.22 |
| RDS for Oracle | SE2 | BYOL | 0.235 | 171.55 |
| RDS for Oracle | EE | BYOL | 0.235 | 171.55 |
| RDS Custom for Oracle | EE | BYOL | 0.282 | 205.86 |
いずれもdb.m5.large（2 vCPU、8 GiB）のシングルAZ構成です。ライセンス込みとBYOLの差は1時間あたり0.279 USD、倍率にして約2.19倍。月あたり203.67 USDがOracleライセンスの対価としてインスタンス単価に上乗せされている計算になる。未使用のSE2ライセンスが手元にあるならBYOLへ寄せる合理性は明確で、新規調達するなら8 vCPUの上限内に収まる限りライセンス込みのほうが調達と保守の手間を含めて有利になる場合があります。
同じインスタンスタイプでもRDS Custom for Oracleは0.282 USDと、通常のRDSより20パーセント高い。OSへのアクセスを開くぶんの差です。なお表の単価はインスタンス料金のみで、ストレージ・バックアップ・AZ間のデータ転送は別途課金されます。
Oracle Database@AWSの課金とOracle Support Rewards
Oracle Database@AWSは、ExadataインフラとコンピュートをOCIの料金体系で使いながら、請求はAWSに集約されます。ストレージについては、AWSがコスト比較の目安として非圧縮のExadataで1 GBあたり0.025 USDという値を示しています（この比較表には課金の期間単位が明記されていないため、実額はAWS Marketplaceのオファー内容で確認してください）。データ転送はOracleアプリケーションとデータベースが同一AZ内なら無料で、AZをまたぐと標準料金がかかります。アプリケーションをDBと同じAZに寄せる設計は、レイテンシとコストの両方で効きます。
ライセンスはライセンス込みとBYOLの両方を選べます。ライセンス込みなら、Oracle RAC、Advanced Data Guard、Multitenant、Diagnostics and Tuning Packを含むEnterprise Editionの機能パックが追加費用なしでOCPU単価にバンドルされる構成です。BYOLの場合はコア係数0.5のOCPUベースで数えるため、Processorライセンス1つで2 OCPU（4 vCPU）をカバーできます。前章のEC2やRDSのvCPU換算とは計算式が違う点に注意してください。
Oracle Support Rewardsは、クレジットの向き先を取り違えられやすい制度です。サービスへの支出1ドルにつき0.25ドル（ULA顧客は0.33ドル）のクレジットが貯まりますが、それで相殺できるのは年間のOracleテクノロジーサポート費用であって、AWSの請求額ではありません。Oracle Database@AWSの利用分にはOCIと同等のSupport Rewardsが付くため、AWS側の値引きではなく既存のOracle保守費を圧縮する原資として試算に組み込むのが正しい扱いです。
オンプレミスのOracleからAWSへ移行する経路
移行手段は移行先によって幅が変わります。Oracle Database@AWSなら、Recovery Manager（RMAN）、Oracle Data Guard、トランスポータブル表領域、Oracle Data Pump、Oracle GoldenGate、AWS Database Migration Service、Oracle Zero Downtime Migration（ZDM）という標準ツールがそのまま使えます。移行先が同じExadataアーキテクチャなので、性能特性を含めて既存構成を維持しやすい。
RDS for OracleやEC2へ移す場合は事情が変わります。RDSはシェルアクセスを提供しないため、OS上のファイル操作を前提とするRMANのフルリストアはそのまま持ち込めません。実務ではData Pumpによる論理移行か、停止時間を抑えたい場合にAWS Database Migration Serviceでの継続レプリケーションを組み合わせる形が中心になります。AWS DMSの同種移行と異種移行の使い分けや料金体系はAWS Database Migration Service（DMS）とは？サーバーレスと同種・異種移行の使い分け・料金を実装者目線で解説にまとめています。
いずれの経路でも、移行方式より先にサイジングを固めてください。移行先のインスタンスタイプが決まらないとライセンス数は確定せず、コア係数0.5を前提にしたオンプレミスの見積もりはEC2とRDSでは成立しないためです。
よくある質問
オラクルとAWSは提携していますか？
はい。提携の成果がOracle Database@AWSで、購入・プロビジョニング・サポートを両社の協調体制で提供します。利用額はAWSの単一請求書にまとまり、AWSのコミット済み支出とOracle Support Rewardsの両方に算入されます。
Oracle Database@AWSで選べるOracle Databaseのバージョンは？
ExaDB-D、ExaDB-XS、Autonomous AI Database on Dedicated Exadata Infrastructure、Autonomous AI Database Serverlessのいずれも19cと26aiに対応しています。18cや12cといった旧バージョンは選択肢にありません。バージョン間の機能差はOracle Database 23aiの新機能とAI強化機能を徹底解説：パフォーマンス最適化とセキュリティ向上で確認できます。
Oracle Autonomous AI Database Serverlessは東京リージョンで使えますか？
2026年9月時点では使えません。AWSのドキュメントが示すADB-Sの提供AZは、米国東部（バージニア北部）のuse1-az6と米国西部（オレゴン）のusw2-az3およびusw2-az4に限られています。東京・大阪で利用できるのは専有Exadataインフラ上のサービスです。日本国内でAutonomous AI Databaseを使うなら、Dedicated Exadata Infrastructure構成を選ぶことになります。
RDS Custom for OracleはRDS for Oracleと何が違いますか？
RDS Customは、通常のRDSが閉じているOSとデータベースへのアクセスを開放したうえで、バックアップやパッチ適用などのマネージド機能を残した中間形態です。データベースソフトウェアは利用者が用意したメディアを使います。東京リージョンのdb.m5.largeでEnterprise EditionのBYOLを比べると、通常のRDSが1時間0.235 USDに対しRDS Customは0.282 USDでした。
AWS上のOracleのサポート窓口はAWSとOracleのどちらですか？
RDS for Oracleでは契約モデルによって分かれます。ライセンス込みでケースサポート付きのAWSサポートアカウントがあれば、Amazon RDSとOracle Databaseの両方についてAWSサポートへ問い合わせます。BYOLの場合は、有効なOracleサポート契約を維持したうえでOracle Databaseの問題はOracleへ直接、Amazon RDS側の問題はAWSサポートへ、と窓口が分かれます。
