ブログ

はじめに

新規の開発案件のお打ち合わせの中でお客様からこんなご要望をいただきました。

「AWS 上で Oracle 使いたいんだけど」

Amazon Aurora（以下、Aurora）やAmazon DynamoDB（以下、DynamoDB）といったクラウドネイティブなデータベースが第一選択肢となることが多い昨今、正直なところ、最初は「えっ、あえてOracleですか？」と戸惑ってしまいました。

ライセンスはどうするのか、RDSでいくのか、EC2にインストールするのか、コスト感はどうなるのか……。

AuroraやDynamoDBなら数クリックで済む話が、一気に複雑なパズルに見えてきます。

今回、悩みながら調査・検討し、最終的な意思決定に至るまでのプロセスを整理しました。「普段はクラウドネイティブだけど、急にOracle案件が降ってきて途方に暮れている」 そんなかつての私と同じ境遇の方の道しるべになればと思います。

▼ この記事の対象読者

• 普段は Aurora や DynamoDB をメインで利用している AWS エンジニア
• 要件により AWS 上での Oracle 採用を検討しなければならないが、どこから着手すべきか悩んでいる方

▼ 本記事で取り扱わないこと

• Oracle Database 自体の詳細なパフォーマンスチューニング
  • SQL の最適化やインデックス設計など、純粋な DBA 領域の技術論は扱いません。
• オンプレミスからの具体的なデータ移行手順
  • AWS DMS や SCT の詳細な操作方法は対象外とし、あくまで「構成の意思決定」にフォーカスします。

Oracle on AWSの主要な選択肢

AWS 上で Oracle データベースを利用する場合、主要な選択肢として以下の3つのサービスが挙げられます。

サービス名	運用 負荷	柔軟性	コスト	代表的なユースケース例
Amazon RDS for Oracle	★☆☆	★☆☆	★☆☆	中小規模の基幹システム：在庫管理、顧客管理システムなど、特殊なカスタマイズが不要なシステム
Amazon RDS Custom for Oracle	★★☆	★★☆	★★☆	特殊運用の継続：カスタムバックアップ/メンテナンススクリプト実行やキャラクタセット変更、独自パッチ適用など、OS・DB レベルの介入が欠かせないケース
Oracle on EC2	★★★	★★★	★★★	レガシーなOracleバージョンの継続利用：RDSでサポートされていない古いOracleバージョンを使用する必要がある基幹システム

責任共有モデル

各サービスで AWS とユーザーがどこまでを担当するのかを視覚的に示した「責任共有モデル」は次のように図示することができます。

図からもわかる通り、運用負荷が最も低いのはAmazon RDS for Oracleです。ただし、運用負荷と柔軟性は表裏一体であり、柔軟性ではEC2上での構築が勝ります。

Amazon RDS Custom for Oracleはその中間に位置するサービスでOSレイヤへのrootアクセスが可能なため標準RDSでは要件を満たせなくともマネージドの恩恵を受けることができる場合があります。オンプレからの移行時に利用することが多いかと思います。

ただし、いずれの選択肢であっても「オンプレミスやOracle Cloud Infrastructure（以下、OCI）の環境と全く同じ」ではないため、全てのユースケースに対応しているわけではありません。

たとえばEC2上に構築する場合でもOracle Real Application Clusters（RAC）はサポートされていません¹。そのため、単にOracleを選択するだけでは高拡張性や高可用性が要求されるワークロードの要件を満たせない可能性があります。

ここまで見てきた選択肢では「AWSインフラをベースとした構築が大前提」となっており、機能制約を完全に排除することはできず、結果としてクラウド移行を見送るケースやOracleそれ自体の選択を避けるケースが多いのではないかなと思います。

Oracle Database@AWS がもたらす新しいユースケース

2025 年 7 月に一般提供が開始された Oracle Database@AWS は、単なるマネージドサービスではなく、AWS のデータセンター内に Oracle のクラウドインフラ（OCI）が物理的に設置される提供モデルです。

ExadataがAWS内で利用可能となり、オンプレミスと同様にRACをネイティブにサポートすることで、極めて高い可用性とスケーラビリティを実現することができます。また、OCIと「同じ機能、同じ価格」で提供されること、AWSエコシステムとの統合も大きな特徴です。

Oracle Database@AWS の登場により以下のようなユースケースも視野に入るようになりました。

▼ ユースケース例

• Exadata からの移行：オンプレミスで Exadata を利用している企業が、性能やアーキテクチャを変更することなく AWS へ移行できるようになりました。アプリケーションの変更を最小限に抑えつつ、クラウドのメリットを享受できます。
• ミッションクリティカルなワークロード：極めて高い性能と可用性を求めるミッションクリティカルなシステムに対して、RDS や EC2 では実現困難だった性能レベルを提供できます。
• Oracle RAC が必須のシステム：これまで EC2 では実現できなかった Oracle RAC が必要なシステムを、AWS エコシステム内でシンプルに構築できます。

データベース 選定プロセス 

冒頭のお客様の案件は、中規模以上の業務システム開発であり、完全な新規開発案件でした。データの一貫性が重要で、複雑なクエリも必要になることからリレーショナルデータベースが前提となります。

さらに、お客様からは「データの可用性をより高めたいが、運用費（AWS費）を可能な限り抑えたい」というご要望が背景にあり、それが冒頭の「AWS 上で Oracle 使いたいんだけど」に繋がります。

3つのサービス比較：1．Aurora、2．RDS for Oracle、3．Oracle Database@AWS

一般的に可用性を高めればコストも増加するため、お客様の事業継続計画（BCP）と総所有コスト（TCO）の両面から最適な選択肢を見極めることが重要です。

今回、Oracle固有の機能に依存するご要望はなかったため、Auroraを含めた以下の3つのサービス間で性能とコストを比較することにしました。

• Aurora
• RDS for Oracle
• Oracle Database@AWS

性能と可用性の比較

無停止運用を目指すケースではOracle Database@AWSが有力な選択肢になりますが、Auroraであっても1つ以上のAuroraレプリカがある場合には、通常30秒でフェイルオーバーが完了します。ミッションクリティカルではないワークロードにおいては、まずAuroraを検討すべきでしょう。

Aurora	RDS for Oracle	Oracle Database@AWS
マルチAZ標準対応、最大15の低レイテンシリードレプリカ、99.999%の高可用性保証。 自動フェイルオーバーあり。	Multi-AZ対応、自動フェイルオーバーあり。 Oracle固有の高可用性機能は制限あり（RAC非対応）。	Exadataプラットフォーム＋Oracle RAC対応で無停止クラスター運用可能。 高スループット・低レイテンシの大規模ワークロードに対応。

その他 比較詳細はこちら

項目	Aurora	RDS for Oracle	Oracle Database@AWS
耐障害性	プライマリインスタンスのみでデータを3つのAZにかけて6個のレプリケーションを作成。	（Multi-AZ 配置前提）障害発生時点までデータの復旧ができる。（多重障害を除く）	Exadata基盤上でデータを複数AZ、複数ノードに同期レプリケーション。自動バックアップ・障害復旧機能も豊富。RACクラスタによる高い耐障害性。
可用性	1つ以上のAuroraレプリカがある場合には、通常30秒でフェイルオーバーが完了し再接続できる。	通常1～2分でフェイルオーバーが完了し再接続できる。	Oracle RAC/Exadata構成による無停止運用、複数AZ構成と自動フェイルオーバーで非常に高い可用性。ダウンタイム最小化。
拡張性	Auroraレプリカ（最大15台）	RDS リードレプリカ（最大5台）	Exadataスケールアウトアーキテクチャにより、ノード/ストレージの水平方向拡張が可能（大規模ワークロード対応）。RACによる複数ノード分散処理。

最小構成でのコスト試算

次にコスト試算です。

AuroraおよびRDS for OracleについてはMulti-AZの最小構成で、Oracle Database@AWSは公式記載の最小データベース、ストレージ数で試算しました。

AuroraとRDS for Oracleの料金差はライセンス費用の有無が大半を占めているため、既存ライセンスを持ち込める場合はほぼ差がないと言えます。一方でOracle Database@AWSはExadataを利用しているため、かなり高額になることがわかりました。

	Aurora	RDS for Oracle	Oracle Database@AWS
年間費用	$5,000〜6,000	$9,000〜$10,000（License Included）	$120,000〜130,000（License Included）
課金モデル	使用したvCPU時間、ストレージ、I/Oリクエスト（これはAurora特有）に基づいた従量課金。	I/Oリクエスト以外は左に同じ。ライセンス費用については「ライセンス込み」モデルと「BYOL」モデルがある。	OCIのExadata Database Serviceと同等の課金体系。主にECPU（仮想CPU）時間単位課金＋専用Exadataストレージ＋バックアップ・ネットワーク量。
特徴	運用自動化が進んでおりバックアップやパッチ管理も自動、運用負担が少ないため人的コストも低減可能。	BYOLはAuroraより数%安いですが、可用性・拡張性を考慮するとAuroraの方が安くなる傾向があります。	エンタープライズ向けの高付加価値機能を含むため高額。

以上の結果を踏まえて再度お客様と議論した結果、Auroraでも十分要件を満たすことができることがわかったため、Auroraを採用する結論に至りました。

まとめ

本記事では、「AWS上でOracleを利用したい」という顧客要望に対し、可用性とコストの最適なバランスを見極める意思決定プロセスを整理しました。

今回の案件では、Oracle Database@AWSは高性能ですが、今回の案件規模に対してはオーバースペックかつコスト過多でした。

お客様の「Oracleを使いたい」という言葉の裏には、「システムを止めたくない」という真のニーズがありました。それを紐解き、Auroraの可用性とコストメリットを提示することで、納得感のある合意形成ができました。

「Oracleか、AWSネイティブか」。 この選択に正解はありません。重要なのは、お客様の事業規模、予算、そして「本当に守りたいもの（可用性なのか、資産なのか）」を見極めるプロセスです。 もしデータベース選定でお悩みの際は、ぜひ私たちＫＹＯＳＯにご相談ください。豊富な実績から最適な解をご提案します。

1. VMware Cloud on AWSも技術的には Oracle RAC をサポートしていますが、2024 年 4 月 30 日以降、AWS による再販が終了し、Broadcom を通じての提供に変更されました。調達プロセスの複雑化、サポート体制の不透明性、長期的なロードマップの不確実性から、新規導入は推奨されません。 ↩︎