Oracle Database@AWS を読み解く: Oracle ワークロードに最適な選択肢の見極め方

本記事は 2026 年 6 月 8 日 に公開された「Oracle Database@AWS decoded: Determining the right fit for your Oracle workloads」を翻訳したものです。

AWS は 15 年以上にわたり、Oracle ワークロードを実行するための豊富な選択肢を提供してきました。マネージドでシンプルな Amazon RDS for Oracle から、Amazon EBS io2 Block Express、gp3、Amazon FSx for NetApp ONTAP といった複数のストレージオプションを持つ完全に柔軟な Amazon Elastic Compute Cloud (Amazon EC2) までさまざまです。これらのサービスは、Oracle Database ベースのアプリケーション (Oracle E-Business Suite、PeopleSoft、Siebel、JD Edwards)、Oracle Database 上に構築されたカスタムアプリケーション、ミドルウェアプラットフォーム (Oracle WebLogic、Oracle Fusion Middleware)、Oracle Database をデータ層とする ISV アプリケーションなど、幅広い Oracle デプロイメントで多くの組織に活用され続けています。

2025 年 7 月に一般提供が開始された Oracle Database@AWS (ODB@AWS) は、このポートフォリオに新しい選択肢を追加し、AWS アベイラビリティゾーン内に物理的にホストされる Exadata Database Service (ExaDB) と Autonomous Database (ADB) を提供します。

本記事では、AWS 上で Oracle ワークロードを運用する組織にとって Oracle Database@AWS が有力な選択肢となる主な理由を解説します。ビジネス、技術、ライセンスの各面での利点と、Amazon RDS for Oracle や Amazon EC2 といった既存の AWS の選択肢をどのように補完するかを説明します。

ODB@AWS がワークロードに適しているかを判断する 5 つの質問

詳細に入る前に、次の 5 つの質問を確認してください。いずれかに「はい」と答えられるなら、ODB@AWS を検討する価値があります。

1. パフォーマンスと将来への備え – 現在のワークロードは Oracle Exadata プラットフォームの機能を使用していますか、または活用できる可能性がありますか？
2. 事業継続性とリスク – Oracle Real Application Clusters (Oracle RAC) は、複数のサーバーが単一のデータベースにアクセスしながら Oracle Database ソフトウェアを実行できるようにし、フォールトトレランスと水平スケーラビリティを提供します。重要な業務を維持するために、フォールトトレランスとローリングパッチによるゼロダウンタイムを実現する Oracle RAC がアプリケーションに必要ですか？
3. キャパシティとコスト効率 – 季節的な需要に合わせて、コストの不均衡な増大なしにデータベースのキャパシティをスケールする必要がありますか？
4. Oracle データベースライセンスの柔軟性 – 従来の先行ライセンス費用ではなく、ワークロード需要に応じてスケールする Enterprise Edition データベースの従量課金制ライセンスモデルをお探しですか？

注: ODB@AWS は、License Included (LI)、Bring Your Own License (BYOL)、またはワークロードごとの併用を提供しています。BYOL のお客様は、ライセンスあたり 2 倍のコアエンタイトルメントを利用できます。ODB@AWS は OCPU ベースのライセンス (コア係数 0.5) を採用しているため、Processor ライセンス 1 つで 2 OCPU (4 vCPU) をカバーでき、標準的な vCPU ベースのクラウドデプロイメントと比べてライセンス要件が半分になります。License Included では、Oracle RAC、Advanced Data Guard、Multitenant、Diagnostics & Tuning Pack を含むすべての Enterprise Edition フィーチャーパックが、追加費用なしで時間あたりの OCPU 料金にバンドルされています。

5. AWS 上の Oracle データベースでホストされる Oracle アプリケーションに対する明示的な認定 – 事業部門として、商用オフザシェルフ (COTS) アプリケーションとそれをホストする基盤インフラストラクチャを含めた Oracle の明示的な認定が必要ですか？Oracle Database@AWS は、Oracle E-Business Suite (Oracle EBS)、PeopleSoft、Siebel、JD Edwards EnterpriseOne、Oracle Enterprise Performance Management、Oracle Retail Applications、そして WebLogic や Fusion Middleware などの Oracle ミドルウェアプラットフォームを含む主要な Oracle エンタープライズアプリケーション向けの認定リファレンスアーキテクチャを提供しています。たとえば Oracle EBS 12.2 は、アプリケーション層を Amazon EC2 で、データベース層を ODB@AWS の Exadata で実行する構成で Oracle Database 26ai on Exadata の認定を受けています。この認定はこれらのデプロイパターンに対する Oracle の完全なサポートを確認するもので、COTS アプリケーションとその基盤インフラストラクチャが Oracle のサポート要件を満たしていると確信できます。詳細は Oracle AI Database@AWS FAQ を参照してください。

これらの質問は、Oracle 戦略の中で ODB@AWS がどこに位置づけられるかを評価する実践的な出発点になります。それでは、理由を詳しく見ていきましょう。

ビジネス面の利点

AWS 上で Oracle ワークロードを運用する組織にとって Oracle Database@AWS が魅力的な選択肢となる、5 つのビジネス上の利点を紹介します。

#1 – 200 以上の AWS サービスと並行して Oracle ワークロードを実行

AWS はエンタープライズ Oracle ワークロードに対して包括的な幅と深さを提供します。コンピューティング、ストレージ、ネットワーキング、分析、AI/ML、セキュリティにわたる 200 以上のネイティブ統合されたサービスがあります。Oracle Database@AWS は技術的にはサードパーティのマネージドサービスですが、AWS Management Console、AWS Command Line Interface (AWS CLI)、AWS CloudFormation、そして Amazon Redshift (zero-ETL)、Amazon Bedrock、Amazon SageMaker AI などのサービスとのネイティブ統合が非常に深く、ファーストパーティの AWS サービスとほぼ変わらない操作性を実現しています。拡大を続けるグローバルインフラストラクチャと実績あるコンプライアンスフレームワークにより、AWS はミッションクリティカルな Oracle アプリケーションが求める信頼性とデータレジデンシーの選択肢を提供します。zero-ETL 分析から生成 AI まで続く AWS の継続的なイノベーションにより、Oracle への投資は競争力を保ち、将来にも対応できます。

#2 – AI Vector Search を備えた Oracle Database 26ai

ODB@AWS は、データベースエンジンに AI Vector Search をネイティブに搭載した Oracle Database 26ai をサポートしています。AI アプリケーションを構築する組織は、別のベクトルデータベースを用意することなく、リレーショナルデータと並べてベクトル埋め込みを保存・検索できます。Exadata AI Smart Scan はベクトル処理をストレージサーバーにオフロードすることでベクトル操作を高速化し、AI ワークロードに高いパフォーマンスを提供します。詳細は Accelerate generative AI use cases with Amazon Bedrock and Oracle Database@AWS を参照してください。

• Retrieval Augmented Generation (RAG) – ドキュメントの埋め込みをトランザクションデータと同じデータベースに保存し、AI の回答をエンタープライズデータに基づかせます。
• セマンティック検索 – キーワードマッチングを超えて、意味と文脈に基づいてレコードを検索します。
• レコメンデーションエンジン – ベクトル距離計算を使った類似度ベースのレコメンデーションを構築します。
• 異常検知 – ベクトル表現を使ってトランザクションデータの異常なパターンを特定します。

大規模言語モデル (LLM) を選択できる柔軟な AI アーキテクチャ

Oracle Database 26ai のネイティブベクトル機能は AWS の包括的な AI/ML サービスと統合でき、ユースケースに合った大規模言語モデル (LLM) を柔軟に選択できます。Oracle AI Vector Search を Amazon Bedrock、Amazon SageMaker AI、Amazon Quick でホストされる LLM に接続し、セマンティック検索や Retrieval Augmented Generation (RAG) などのユースケースを実現できます。

• Amazon Bedrock – 多様な基盤モデルにアクセスして生成 AI アプリケーションを構築できます。
• Amazon SageMaker AI – オープンソース LLM を含む独自のカスタムモデルを、トレーニングデータとモデルの動作を完全にコントロールしながらデプロイ・ファインチューニングできます。
• Amazon Quick – Oracle データベースを含むエンタープライズデータソースに接続し、チームが自然言語で組織のデータを照会・活用できるようにします。

エンタープライズ AI の基盤

このアーキテクチャは、次のようなエンタープライズ AI の基盤を作ります。

• Oracle データは Exadata に留まる – ミッションクリティカルなトランザクションデータは、AI Smart Scan がベクトルデータをメモリ速度で処理する実績ある高性能インフラストラクチャに残ります。
• AI アプリケーションは AWS で実行 – AWS の伸縮自在なコンピューティング、マネージド AI サービス、グローバルインフラストラクチャを活用できます。
• ベクトル埋め込みはトランザクションデータと共存 – データ移動が不要になり、運用ワークロードと AI ワークロード間の一貫性を維持できます。
• AI スタックを自分でコントロール – ベンダーロックインなしに、要件に合った LLM、フレームワーク、ツールを選択できます。

ERP データに基づくカスタマーサービスチャットボット、取引パターンを分析する不正検知システム、インテリジェントなドキュメント処理パイプラインのいずれを構築する場合でも、ODB@AWS 上の Oracle Database 26ai がデータ基盤となります。AWS は、ビジネス目標に最も合った AI テクノロジーを選択してデプロイする柔軟性を提供します。

#3 – ライセンスオプションによる財務の柔軟性

ODB@AWS は AWS Marketplace で単一の請求書により購入でき、財務計画とベンダー管理の両方が効率化されます。

• AWS のコミット済み支出にカウント – ODB@AWS の購入は既存の AWS 商用契約に適用でき、Oracle データベースへの支出が AWS のコミットメントに寄与する可能性があります。
• Bring Your Own License (BYOL) – ODB@AWS で Exadata Database Service または Autonomous Database をデプロイする際、既存の Oracle Database ライセンス (Enterprise Edition または Standard Edition 2) を利用できます。この柔軟性により、新規プロジェクトや新環境には License Included (LI) を、既存ワークロードには BYOL を使い分けられ、ライセンス制約によるプロジェクトの順次実施の制限を回避できます。
• License Included – Oracle ライセンスをサービス料金に含めることで、Oracle サポート契約を別途維持する必要がなくなります。Oracle サポートコストの簡素化を戦略に含めているなら、このオプションが明快な道筋になります。
• Oracle Support Rewards – Oracle Database@AWS は Oracle の Support Rewards プログラムの対象で、サービスへの支出 1 ドルごとに 0.25 ドル (Unlimited License Agreement のお客様は 1 ドルあたり 0.33 ドル) のクレジットが貯まります。このクレジットは、Oracle Database、Oracle Applications、WebLogic などの製品を対象とする年間の Oracle テクノロジーサポート費用の相殺に利用できます。さらに、ODB@AWS は OCI と同等の Support Rewards が貯まるため、OCI で運用した場合と同じ特典スケジュールの恩恵を受けられます。
• 従量課金スケーリング – 従来の先行ライセンス調達に代わり、ワークロード需要に応じてスケールする Enterprise Edition データベースキャパシティを利用できます。
• 単一請求書 – 別途 Oracle インフラストラクチャの請求を照合する必要がありません。

Autonomous Database のライセンスの柔軟性:

ODB@AWS 上の Oracle Autonomous Database は、包括的な機能 (RAC、Exadata 機能、自動化) を単一のオファリングに含みます。既存の Standard Edition 2 (SE2) ライセンスを持つお客様は、Autonomous Database のデプロイ時に BYOL プログラムでそのライセンスを利用するか、License Included モデルを採用してサブスクリプションベースのライセンスにすることで、個別のライセンス管理と Oracle サポート契約の管理を不要にできます。

料金は OCI の Oracle Exadata Database Service と揃っています。既存の Oracle ライセンス投資がある組織は、BYOL によりそのエンタイトルメントを ODB@AWS で活用できます。運用のシンプルさを求める組織には、既存のエンタイトルメントを必要としない License Included モデルが効率的な調達手段となります。

#4 – クラウド移行の障壁と塩漬け資産の解消

ODB@AWS は、Oracle のお客様が今日直面している最も差し迫ったインフラストラクチャ課題の 1 つ、すなわち最近の仮想化ライセンス変更と仮想化コストの高騰によって深刻化した塩漬け資産 (stranded assets) の問題にも直接対処します。多くの組織はオンプレミスの仮想化環境内またはその周辺に大規模な Oracle ワークロードを抱えており、劇的なコスト増によって運用継続が財務的に持続不可能になりつつあります。

Oracle Exadata ワークロードにクラウドホスト型のネイティブな移行パスを提供することで、ODB@AWS はこうした組織が制約のあるインフラストラクチャから脱却し、再設計なしにワークロードを AWS に移行しながら、既存の Oracle 投資の価値を引き出せるようにします。これにより、これまで塩漬けになっていた Oracle 資産に対して明確でコスト効率の良い移行パスが生まれ、負債がクラウド活用可能な資産に変わります。

#5 – グローバルで 20 以上の AWS リージョンへ拡大中

ODB@AWS はグローバルに拡大を続けており、すでに 12 を超える AWS リージョンで利用できます。このグローバルなフットプリントにより、ユーザーとアプリケーションの近くで ODB@AWS を実行し、データレジデンシー要件を満たしながらレイテンシーを最小化できます。複数リージョンで Oracle E-Business Suite などの Oracle アプリケーションを運用する多国籍企業にとって、この拡大は世界中で一貫したアーキテクチャを可能にします。

リージョンの提供状況は Oracle Region Availability Link で確認できます。

技術面の利点

Oracle Database@AWS が AWS 環境内で高性能なデータベース運用を実現する 8 つの技術的な機能を紹介します。

#6 – Exadata と Oracle RAC の機能を AWS 内でネイティブに利用

一部の Oracle ワークロードは、Exadata プラットフォーム固有の機能に依存しています。マルチノードの耐障害性を実現する Oracle RAC、ストレージレベルのクエリオフロードを行う Exadata Smart Scan、ベクトル処理向けの Exadata AI Smart Scan、ハイブリッドカラムナ圧縮、ストレージインデックスなどです。多くのミッションクリティカルなアプリケーションにとって、これらは好みの問題ではなくアーキテクチャ上の要件です。

ODB@AWS はこれらの機能を、Oracle が管理し AWS アベイラビリティゾーン内に物理的に設置された専用 Exadata ハードウェア上で提供します。

• Oracle RAC – 複数のデータベースノードにわたる水平スケーラビリティ、最大稼働時間/ゼロダウンタイム、フォールトトレランスを提供します。
• Exadata Smart Scan – クエリ処理をストレージサーバーにオフロードし、データベース層に必要なコンピューティングを削減できる可能性があります。
• Exadata AI Smart Scan – AI Vector Search ワークロードのベクトル操作をストレージサーバーにオフロードし、ベクトルデータをメモリ速度で処理して AI アプリケーションのパフォーマンスを向上させます。
• ハイブリッドカラムナ圧縮 – 分析データとアーカイブデータの保存を最適化します。
• ストレージインデックス – ストレージ層で不要な I/O を排除します。
• Exadata X11M インフラストラクチャ – 現行モデルとして提供され、最大 32 台のデータベースサーバーと 64 台のストレージサーバーを構成できます。

#7 – Oracle Autonomous Database

ODB@AWS には Oracle Autonomous Database on Dedicated Exadata Infrastructure が含まれています。機械学習を使ってパッチ適用、チューニング、スケーリング、セキュリティを自動化する、完全に自己管理型のデータベースです。

Autonomous Database は、従来は複雑だった運用タスクを人手を介さず処理します。

• 自動インデックス作成: ワークロードを継続的にモニタリングし、インデックスの作成、削除、再構築を行います。
• Auto Scaling: 需要に応じて CPU とストレージのリソースを調整します。
• 自動パッチ適用: ゼロダウンタイムのローリングアップデートを実施します。
• 自動チューニング: SQL 実行プランをリアルタイムに最適化します。

Autonomous Database により、データベース管理者 (DBA) はビジネス価値を生む戦略的な取り組みに集中でき、定常的なメンテナンスの自動化によってチームはイノベーションとビジネス目標の達成を加速できます。また、先行のキャパシティプランニングを必要とせず、実際のワークロード需要に応じてスケールする従量課金モデルもサポートしています。

VM クラスター構成: ODB@AWS は、ExaDB-D と ADB-D のいずれかを選択できる柔軟なデプロイをサポートし、ワークロードに合わせてリソースを細かく設定できます。

• Exadata VM クラスター (Oracle Exadata Database Service 用): VM ごとに CPU コア、メモリ、ローカルストレージを設定できます。Oracle RAC と Oracle Grid Infrastructure をサポートします。ピーク容量に合わせた過剰なプロビジョニングではなく、ワークロード要件に合わせたコンピューティングの適正サイジングが可能です。
• Autonomous VM クラスター (Oracle Autonomous Database on Dedicated Exadata Infrastructure 用): VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous Container Database の最大数を設定できます。機械学習 (ML) と AI を使ってプロビジョニング、セキュリティ確保、更新、バックアップ、チューニングを自動化し、定常的なデータベース管理タスクに人手を必要としません。

#8 – 迅速なリフトアンドシフトによるクラウド移行

ODB@AWS は Oracle ネイティブのツールチェーン一式を使った移行をサポートしており、最小限のリスクと最大限のスピードでリフトアンドシフトを実現できます。移行先が正真正銘の Exadata ハードウェアであるため、再設計や機能の廃止を必要とせず、完全な機能互換性を維持したまま移行できます。

Oracle ネイティブの移行ツール:

• Oracle Zero Downtime Migration (ZDM) – Oracle 純正の自動移行ツールで、ODB@AWS への移行を完全サポートしています。
• RMAN – ブロックレベルのバックアップとリストアによる、信頼性が高く一貫した移行を実現します。
• Oracle Data Guard – フィジカル/ロジカルスタンバイによるゼロダウンタイムのカットオーバーが可能です。
• トランスポータブルテーブルスペース – 最小限のダウンタイムでスキーマレベルの高速移行を実現します。
• Oracle Data Pump – スキーマとデータの論理エクスポート/インポートによる移行を行います。
• Oracle GoldenGate – リアルタイムの双方向レプリケーションにより、ほぼゼロダウンタイムのカットオーバーが可能です。

#9 – Oracle Autonomous Recovery Service: 包括的なランサムウェア対策とイミュータブルバックアップ

Oracle Autonomous Recovery Service (ARS) は、ランサムウェアへの防御に特化した機能を備え、Oracle Database@AWS の包括的なデータ保護と事業継続を支援します。このフルマネージドサービスは、AWS ネイティブのバックアップソリューションを補完する包括的なバックアップ・リカバリ機能を提供します。

1 秒未満の RPO を実現するリアルタイムデータ保護

Autonomous Recovery Service は REDO ログをサービスに継続的にストリーミングするリアルタイムデータ保護を提供し、1 秒未満の目標復旧時点 (RPO) を実現します。データ損失のリスクをほぼゼロに抑え、壊滅的な障害やランサムウェア被害が発生しても、発生時点から 1 秒以内の状態にデータベースを復旧できます。

保持ロックによるイミュータブルバックアップ保護

ARS は保持ロック機能によるイミュータブルバックアップ保護を提供し、保持期間中のバックアップの変更や削除を防ぎます。有効化後は、保持期間が終了するまで特権ユーザーであってもバックアップを変更・削除できません。ランサムウェア、内部の脅威アクター、誤削除に対する重要な安全装置となり、ライフサイクル全体を通じてデータの安全性とコンプライアンスを確保します。

主な機能と利点:

• 自動バックアップオーケストレーション – バックアップのスケジューリング、実行、ライフサイクル管理を完全自動化し、運用負荷を軽減して一貫した保護を実現します。
• 継続的なバックアップ検証 – バックアップが改ざんされていないことを継続的に検証し、リカバリ資産が常に利用可能であるという確信を提供します。
• 最適化されたリカバリワークフロー – 効率化されたリカバリプロセスにより、最小限の手作業で任意の時点への迅速かつ予測可能なリカバリを実現します。
• ポリシーベースのライフサイクル管理 – 保護ポリシー (Bronze、Silver、Gold、Platinum、またはカスタム) で 14〜95 日の保持期間を定義でき、バックアップを AWS または OCI リージョンに柔軟に保存できます。
• 職務の分離 – バックアップ管理をデータベース管理者から分離し、バックアップデータへの不正アクセスや改ざんを防止します。
• 増分永続 (incremental forever) 戦略 – 初回のフルバックアップ以降は増分変更のみを取得し、ストレージ消費とバックアップウィンドウを最適化します。

柔軟なデプロイオプション

Oracle Database@AWS のデプロイメントでは、データベースと同じクラウドプロバイダーのロケーションにバックアップを保存するよう Autonomous Recovery Service を設定できます。保護ポリシーで Store backups in the same cloud provider as the database オプションを有効にすると、バックアップは AWS 内に留まり、データレジデンシーとコンプライアンスの要件への対応が簡素化されます。

保護ポリシー

ARS はビジネス要件に合わせた事前定義の保護ポリシーを提供します。

• Bronze: 保持期間 14 日。
• Silver: 保持期間 35 日 (デフォルト)。
• Gold: 保持期間 65 日。
• Platinum: 保持期間 95 日。
• ユーザー定義: 保持期間 14〜95 日。

ランサムウェアレジリエンス

ランサムウェア被害が記録的なペースで続く時代において、Autonomous Recovery Service は強力な防御機能を提供します。イミュータブルバックアップ、保持ロック、継続的な検証、リアルタイムデータ保護の組み合わせにより、ランサムウェア被害の後でも Oracle データベースを迅速かつ完全に復旧できることを保証します。

Autonomous Recovery Service が有力な選択肢である理由

Autonomous Recovery Service は、1 秒未満の RPO、保持ロックによるイミュータブル保護、継続的な検証、自動化されたライフサイクル管理を兼ね備えています。Oracle Database@AWS のデプロイメントに高いレベルのデータ保護、規制コンプライアンス、ランサムウェアレジリエンスを求める組織にとって有力な選択肢です。

#10 – AWS コンソールと API のネイティブ統合

ODB@AWS のリソースは使い慣れた AWS ツールでプロビジョニング・管理できるため、別の運用モデルを新たに習得する必要はありません。

• AWS Management Console – ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターを作成する専用の ODB@AWS ダッシュボード。
• AWS CLI と API – 裏側で対応する OCI API を呼び出すプログラマティックアクセス。
• AWS CloudFormation – 再現可能で監査可能なデプロイのための Infrastructure as Code。

AWS Resource Access Manager (AWS RAM) によるマルチアカウントでの Exadata インフラストラクチャ共有:

AWS Resource Access Manager (AWS RAM) を使うと、組織内の複数の AWS アカウントで単一の Exadata インフラストラクチャを共有でき、チームや事業部門をまたいだコスト削減と管理の簡素化を実現できます。AWS RAM により、Exadata インフラストラクチャと ODB ネットワークを同じ AWS Organization 内の複数の AWS アカウント間で共有できます。

• 所有者アカウントが Exadata インフラストラクチャをプロビジョニングし、信頼されたアカウントを指定したリソース共有を作成します。
• 信頼されたアカウントは共有インフラストラクチャ上に独自の VM クラスターとデータベースを作成できますが、基盤となる Exadata インフラストラクチャや ODB ネットワークは削除できません。
• 信頼されたアカウントは、共有リソースを使用する前に ODB@AWS サービスを初期化する必要があります。
• リソースは同じ AWS Organization 内、同じリージョン内で、特定の AWS アカウント ID とのみ共有できます。
• リソース共有は作成後に変更できず、リソースを別の購入者アカウントと共有することもできません。

これにより、インフラストラクチャの一元的な所有、Exadata キャパシティの共有によるコスト最適化、データベースチーム間の論理的な分離を、すべて AWS アカウントのガバナンスモデルの中で実現できます。

• AWS Identity and Access Management (IAM) – 既存の ID フレームワークを使った認証と認可。
• Amazon CloudWatch – VM クラスター、コンテナデータベース、プラガブルデータベースの AWS/ODB 名前空間のメトリクス。
• AWS CloudTrail – コンプライアンスとガバナンスのための完全な API 監査ログ。
• Amazon EventBridge – データベースライフサイクルイベントによるイベント駆動の自動化。

既存の AWS 運用ランブック、モニタリングダッシュボード、セキュリティポリシーは ODB@AWS に自然に拡張できます。クラウド運用チームは使い慣れたツールで作業できます。

クロスアカウント共有のベストプラクティスの詳細は、Best practices and architecture patterns for cross-account sharing in Oracle Database@AWS を参照してください。

ネットワーク接続パターン: ODB@AWS は、スケールとトポロジーの要件に応じて 3 つの接続パターンをサポートします。

• パターン 1: VPC 直接ピアリング (1 対多): 最もシンプルなネットワークパスです。ピアリングされた VPC がアプリケーション VPC として ODB ネットワークに接続します。Oracle データベースが主に単一 VPC 内のアプリケーションにサービスを提供する場合に最適です。現在は最大 45 の VPC 接続をサポートしています。
• パターン 2: AWS Transit Gateway による単一リージョンスケール: ピアリングされた VPC が ODB トランジット VPC として動作します。トラフィックは Transit Gateway 経由で ODB ネットワークに転送され、単一 AWS リージョン内の複数の VPC から ODB@AWS リソースにアクセスできます。
• パターン 3: AWS Cloud WAN によるマルチリージョンスケール: ピアリングされた VPC がトランジット VPC として動作します。トラフィックは AWS Cloud WAN のコアネットワーク経由で転送され、複数の AWS リージョンとオンプレミスネットワークから ODB@AWS への接続が可能になります。
• パターン 4: クロスリージョン接続のための OCI VCN ピアリング: クロスリージョンの災害復旧 (DR) やハイブリッドクラウドのシナリオでは、ODB ネットワークを Local Peering Gateway (LPG) を使って OCI Virtual Cloud Network (VCN) に接続できます。各 ODB ネットワークは、お客様のリンクされた OCI テナンシー内の OCI VCN と 1:1 でマッピングされます。これにより、OCI VCN ピアリングを介して異なる AWS リージョンの ODB@AWS デプロイメント間の接続が可能になり、複数リージョンにまたがる Oracle Data Guard 構成などのユースケースをサポートします。

技術的な考慮事項: ODB ネットワークは最大 45 の ODB ピアリング接続をサポートします。ODB ネットワークの CIDR には IP アドレス空間の計画が必要です。VPC ルートテーブルは ODB ネットワークの CIDR に合わせて手動で更新する必要があります。DNS 解決には、ピアリングされた VPC に Amazon Route 53 Resolver のアウトバウンドエンドポイントをデプロイする必要があります。Oracle アプリケーションとデータベースが同一 AZ 内にある場合、データ転送料金は発生しません。

強化されたセキュリティコントロール: IAM、Amazon CloudWatch、AWS CloudTrail、Amazon EventBridge に加えて、ODB@AWS は以下を提供します。

• SSL/TLS 暗号化 – ODB@AWS へのすべての接続は転送中に暗号化されます。
• AWS Key Management Service (AWS KMS) – AWS CloudFormation とマネージド統合を使った暗号化キー管理との統合。
• ネットワーク分離 – ODB ネットワークはプライベートでパブリックインターネットに公開されず、すべての接続は AWS ネットワークファブリック内で ODB ピアリング、AWS Transit Gateway、または AWS Cloud WAN を使用します。

ODB@AWS は AWS インフラストラクチャ層のコンプライアンス認証 (SOC、ISO、PCI DSS、HIPAA 対応) を継承し、Exadata とデータベースソフトウェア層のコンプライアンスは Oracle が維持します。

#11 – Amazon Redshift との Zero-ETL 統合

図 1: Amazon Redshift への Zero-ETL 統合

Amazon Redshift との Zero-ETL は、ETL パイプラインの構築や管理なしに、またネットワーク間のデータ転送コストなしに、Oracle のトランザクションデータを Amazon Redshift にレプリケートします。これにより以下が可能になります。

• リアルタイム分析: Amazon Redshift のカラムナエンジンを使った Oracle トランザクションデータの分析。
• ML と AI のワークロード: Amazon Redshift に接続した Amazon SageMaker AI の活用。
• クロスソース分析: Oracle データと、すでに Amazon Redshift にある他の AWS ソースのデータの結合。
• ビジネスインテリジェンス: ほぼリアルタイムの Oracle データを使った Amazon QuickSight ダッシュボード。

図 2: Zero-ETL と分析サービスの統合

Oracle E-Business Suite (Oracle EBS)、PeopleSoft、Siebel などの Oracle エンタープライズアプリケーション環境では、これが特に重要です。Oracle EBS は財務、サプライチェーン、製造、人事にわたる膨大な量のトランザクションデータを生成します。Zero-ETL により、財務チームは GL 仕訳の分析、サプライチェーンチームは在庫移動の分析、調達チームは発注支出の追跡を、別途 ETL インフラストラクチャなしでほぼリアルタイムに実行できます。

• Amazon VPC Lattice による AWS サービス接続 – AWS Glue Zero-ETL やその他の AWS 分析統合は、ODB ネットワークから AWS サービスへのネイティブアクセスを提供する Amazon VPC Lattice によって実現されます。
• VPC Lattice 経由の Amazon S3 – Oracle 管理のバックアップを、パブリックインターネットを経由せず Amazon S3 (99.999999999%、イレブンナインの耐久性設計) に直接保存できます。
• Amazon Bedrock と Amazon SageMaker AI – Oracle データが Amazon Redshift や Amazon S3 に流れることで、Amazon Bedrock の基盤モデル (FM) や Amazon SageMaker AI を使い、予知保全、需要予測、Oracle トランザクションデータに対する LLM ベースの分析といったユースケースの生成 AI・ML パイプラインを構築できます。

注: マネージド統合には標準の VPC Lattice データ処理料金が適用されます。統合自体に時間あたりの料金はかかりません。

#12 – Oracle アプリケーション向けの認定アーキテクチャ

Oracle は ODB@AWS 上に Oracle エンタープライズアプリケーションをデプロイするためのリファレンスアーキテクチャを公開しており、Oracle E-Business Suite (Oracle EBS) が最初の認定デプロイパターンです。アプリケーション層を AWS で、データベース層を Exadata で、すべて同一 AWS リージョン内で実行するサポート対象の構成です。

Oracle E-Business Suite のリファレンスアーキテクチャ:

• Amazon EC2 上の Oracle アプリケーション層 – Web、フォーム、コンカレント処理、管理サーバー。
• ODB@AWS の Exadata 上のデータベース層 – 同一アベイラビリティゾーン内の低レイテンシーネットワーキングで ODB ピアリング接続。
• AWS Transit Gateway – 複数の VPC、ODB ネットワーク、オンプレミス拠点を接続するハブアンドスポークネットワーキング。
• Amazon FSx for NetApp ONTAP – 共有 APPL_TOP ファイルシステム。SnapMirror による本番・非本番環境間のクローンをサポート。
• AWS Direct Connect – オンプレミスデータセンターへのハイブリッド接続。

Oracle EBS のアプリケーションコードは変更不要です。RAC、Data Guard、ASM、RMAN を含むデータベース機能はすべて、オンプレミスとまったく同じように動作します。Oracle EBS 12.2 は Oracle Database 26ai on Exadata の認定を受けているため、ODB@AWS で Oracle EBS を実行しながら 26ai の機能を活用できます。

その他の Oracle アプリケーションのサポート:

ODB@AWS は、PeopleSoft、Siebel、JD Edwards EnterpriseOne、Oracle Enterprise Performance Management、Oracle Retail Applications などの他の Oracle エンタープライズアプリケーションもサポートしています。これらのアプリケーションは、アプリケーション層を Amazon EC2、データベース層を ODB@AWS の Exadata とする同様のアーキテクチャパターンに従い、同じ低レイテンシー接続と AWS サービス統合の利点を維持します。

WebLogic や Fusion Middleware などの Oracle ミドルウェアプラットフォームもこのアーキテクチャと統合でき、Oracle Database 上に構築された ISV アプリケーションも同じデプロイパターンに従うことができます。

EBS を ODB@AWS にデプロイするリファレンスアーキテクチャは、Oracle EBS のアプリケーション層を AWS で、データベース層を Exadata で、すべて同一 AWS リージョン内で実行するサポート対象の構成です。

• Amazon EC2 上の EBS アプリケーション層 – Web、フォーム、コンカレント処理、管理サーバー。
• ODB@AWS の Exadata 上のデータベース層 – 同一アベイラビリティゾーン内の低レイテンシーネットワーキングで ODB ピアリング接続。
• AWS Transit Gateway – 複数の VPC、ODB ネットワーク、オンプレミス拠点を接続するハブアンドスポークネットワーキング。
• Amazon FSx for NetApp ONTAP – 共有 APPL_TOP ファイルシステム。SnapMirror による本番・非本番環境間のクローンをサポート。
• AWS Direct Connect – オンプレミスデータセンターへのハイブリッド接続。
• Amazon S3 – イレブンナインの耐久性を持つデータベースバックアップ。

Oracle EBS のアプリケーションコードは変更不要です。RAC、Data Guard、ASM、RMAN を含むデータベース機能はすべて、オンプレミスとまったく同じように動作します。Oracle EBS 12.2 は Oracle Database 26ai on Exadata の認定を受けているため、ODB@AWS で Oracle EBS を実行しながら 26ai の機能を活用できます。

#13 – Oracle ワークロードごとに適切な AWS の選択肢を選ぶ

AWS は現在、Oracle ワークロード向けに 3 つの有力な選択肢を提供しています。適切な選択は、どのサービスが「優れているか」ではなく、ワークロードの要件によって決まります。

多くの組織は、Oracle 資産全体で複数の選択肢を併用することになるでしょう。開発・テスト用データベースは Amazon RDS for Oracle で、カスタム Oracle 設定が必要なアプリケーションは RDS Custom for Oracle で、ミッションクリティカルな Oracle EBS 本番環境は Oracle Database@AWS で運用する、といった形です。これらの選択肢はポートフォリオとして連携します。

始め方

Oracle Database@AWS の検討を始めるには:

1. AWS Management Console にアクセス – AWS Management Console の Oracle Database@AWS ダッシュボードサービスページで、サービスと利用可能な構成を確認します。
2. プライベートオファーをリクエスト – AWS または Oracle のアカウントチームに連絡するか、AWS Marketplace から直接リクエストします。
3. ワークロードを評価 – Oracle AWS Optimization and Licensing Assessment (OLA) を使って、Oracle 資産、ライセンス状況、移行の準備状況を評価します。前述の判断フレームワークを適用して、各ワークロードに適した ODB@AWS のサービスティア (ExaDB または ADB) を決定します。
4. ドキュメントを確認 – Oracle Database@AWS ユーザーガイドと Oracle のドキュメントに、セットアップ、設定、移行の詳細なガイダンスがあります。
5. パートナーと連携 – AWS Oracle コンピテンシーパートナーが、ZDM ベースの移行計画と実行を含む ODB@AWS 環境の設計、デプロイ、管理を支援します。

まとめ

本記事では、Oracle Database@AWS が AWS 上で Oracle を実行するための選択肢のポートフォリオをどのように拡張するかを解説しました。このソリューションは、Exadata のパフォーマンス、RAC のフォールトトレランス、Autonomous Database の自動化、柔軟なライセンスモデルを AWS にもたらし、ネイティブなコンソール統合、zero-ETL 分析、Oracle Database 26ai による AI 機能も備えています。

Exadata の機能、事業継続性のための Oracle RAC、ストレージコストの最適化、Enterprise Edition の従量課金ライセンス、Oracle サポートコストの簡素化が必要であれば、ODB@AWS は詳しく検討する価値があります。うまく機能しているものを置き換える話ではありません。すべての Oracle ワークロードに適切な選択肢を持つということです。

Oracle Database@AWS がクラウド戦略にどう組み込めるか、また特定の Oracle ワークロード要件にどう応えられるかをぜひ検討してください。ODB@AWS の実際の効果を確認する準備はできましたか？AWS Optimization and Licensing Assessment (AWS OLA) をリクエストしてください。AWS と Oracle のエキスパートが協力して現在の Oracle 資産を評価し、最適化の機会を特定し、Oracle Database@AWS への移行・モダナイゼーションのロードマップをお客様に合わせて設計する包括的なエンゲージメントです。今すぐ AWS OLA をリクエストして、AWS 上での Oracle ワークロード最適化への道を歩み始めてください。

コメント欄でご意見をお聞かせいただくか、Oracle Database@AWS が組織のニーズをどのようにサポートできるか、私たちのチームまでお気軽にご相談ください。

著者について

この記事は Solutions Architect の 矢木 覚が翻訳しました。