Amazon Web Services ブログ
Oracle Database@AWS のクロスアカウント共有のベストプラクティスとアーキテクチャパターン
本記事は 2026 年 4 月 23 日 に公開された「Best practices and architecture patterns for cross-account sharing in Oracle Database@AWS」を翻訳したものです。
Oracle Database@AWS (ODB@AWS) は、Amazon Web Services (AWS) データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャにアクセスできるサービスで、Oracle Cloud Infrastructure (OCI) と AWS の間で統一された体験を提供します。オンプレミスデプロイメントと同等の機能、アーキテクチャ互換性、パフォーマンスを維持しながら、Oracle Exadata ワークロードの AWS クラウドへの移行を簡素化します。
Oracle Database@AWS は現在、以下の OCI サービスを提供しています。
- Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)
- Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D)
- Oracle Database Autonomous Recovery Service (ARS)
Oracle Database@AWS は、環境のライフサイクル管理とガバナンスを改善しながら、ビジネスユニット間で Oracle データベースを運用するモデルを定義する複数の方法を提供します。本記事では、AWS アカウント間で Oracle Database@AWS (ODB@AWS) リソースを共有するためのオプションを解説します。あわせて、一般的なクロスアカウントアーキテクチャパターン、ベストプラクティス、重要な考慮事項も紹介します。これにより、AWS アカウント全体で効率的な ODB@AWS アーキテクチャを設計できます。本記事で使用する主要な用語の確認は、記事末尾の「主要な概念」セクションを参照してください。
クロスアカウントのリソース共有とデプロイオプション
パート 1: リソース共有オプション
同一 Organization 内のアカウント間で ODB@AWS リソースと Marketplace サブスクリプションを共有するための大まかなアプローチは以下のとおりです。
- AWS Resource Access Manager (AWS RAM) によるリソース共有。
AWS Resource Access Manager (AWS RAM) 共有では、同じ AWS Organization 内の複数の AWS アカウント間で Exadata インフラストラクチャと ODB ネットワークリソースを共有できます。
- AWS License Manager を使った AWS Marketplace エンタイトルメント共有によるサブスクリプションの他アカウントとの共有。
エンタイトルメント共有では、購入者アカウント (グランター アカウント) が、同じ AWS Organization 内の複数の AWS アカウント (グランティー アカウント) に Oracle Database@AWS のエンタイトルメントを共有できます。各グランターまたはグランティーアカウントは、集中管理されたサブスクリプションを利用しながら、自身の AWS アカウント内で ODB@AWS をプロビジョニング・運用し、独立したネットワーキング、セキュリティ境界、運用管理を維持します。
パート 2: リソース共有のデプロイパターン (リソースモデリング)
同一 Organization 内の単一または複数の AWS アカウントにリソースをモデリング・デプロイする際に使える一般的なアーキテクチャパターンは以下のとおりです。
- 単一アカウント (購入者アカウントのみ) のデプロイ
- Exadata インフラストラクチャまたは ODB ネットワークのクロスアカウントリソース共有
- リソース分離のためのクロスアカウントサブスクリプション共有
- サブスクリプション共有とリソース共有を組み合わせたクロスアカウントハイブリッドモデル
- クロスアカウントハイブリッドモデル – グランティーアカウントが RAM 共有を実施
- クロスアカウントハイブリッドモデル – 信頼されたアカウントとグランティーアカウントの両方を兼ねるアカウント
AWS Resource Access Manager (AWS RAM) によるリソース共有
Oracle Database@AWS は AWS Resource Access Manager (AWS RAM) を使い、安全で制御されたリソース共有を実現します。チームやビジネスユニット間でガバナンスとセキュリティ境界を維持しながら Oracle データベースインフラストラクチャのコストを最適化したい組織に有用です。このオプションでは、AWS 購入者アカウントがプロビジョニング済みの Exadata インフラストラクチャまたは ODB ネットワークを他の信頼された AWS アカウントと共有できます。信頼されたアカウントは、自身のアカウント内で VM クラスターまたは Autonomous VM クラスターと CDB/PDB を作成できます。信頼されたアカウントは Exadata インフラストラクチャや ODB ネットワークを作成できません。信頼されたアカウントはトランジット Amazon Virtual Private Cloud (Amazon VPC) を作成し、共有された ODB ネットワークとピアリングできます。次のアーキテクチャパターンでは、購入者アカウントが ODB ネットワークと Exadata インフラストラクチャの両方をプロビジョニングし、信頼されたアカウント 1 と 2 に共有しています。信頼されたアカウントは共有インフラストラクチャ上に VM クラスターを作成し、アプリケーション VPC とピアリングできます。
購入者アカウントと信頼されたアカウント間のリソース共有を有効にする手順は以下のとおりです。
AWS License Manager による Marketplace エンタイトルメント共有
AWS Marketplace のセラープライベートオファー機能を使うと、Oracle から Oracle Database@AWS の料金と EULA 条件を受け取ることができます。AWS Marketplace での ODB@AWS のリクエストと購入の手順はオンボーディングセクションを参照してください。Marketplace エンタイトルメント共有オプションでは、同じ AWS Organization 内の AWS アカウント間で Oracle Database@AWS のサブスクリプションとエンタイトルメントを共有できます。購入者 (グランター) AWS アカウントが AWS License Manager を通じてグランティー AWS アカウントにエンタイトルメントを共有します。グランティーアカウントは、自身のアカウント内で独自の ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター、Autonomous VM クラスター、データベースをプロビジョニングします。
次のアーキテクチャ図では、グランター (購入者) アカウントがグランティーアカウント 1 と 2 にエンタイトルメントを共有し、グランティーアカウントが独自の ODB ネットワークと Exadata インフラストラクチャを作成できるようにしています。
グランターアカウントとグランティーアカウント間のエンタイトルメント共有を有効にする手順は以下のとおりです。
リソースモデリングのユースケース
- 単一アカウント (購入者アカウントのみ) のデプロイ
このケースでは、単一の AWS アカウントに Oracle Database@AWS リソースをデプロイします。マルチクラウドリンク設定の一環として、各 AWS アカウントはリンクされた OCI テナンシー内に専用のコンパートメントを持ちます。購入者アカウントは任意の Oracle Database@AWS サービスをデプロイできます。
次のアーキテクチャパターンでは、ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター、データベースを含む ODB@AWS リソースが、Marketplace オファーを受諾した購入者アカウントによってデプロイ・所有されています。図 1 では、Oracle データベースに接続するアプリケーションは同一アカウント内の複数の VPC にあり、ODB ピアリングで直接ピアリングされています。
図 1: 同一アカウント内の複数アプリケーション VPC との直接 ODB ピアリング
次のアーキテクチャ図では、Oracle データベースに接続するアプリケーションは、AWS Transit Gateway を経由するハブアンドスポークアーキテクチャで接続しています。図 1 と図 2 のアーキテクチャは、アプリケーション、データベース、ODB@AWS Marketplace オファーが単一アカウントにあるユースケース向けの最もシンプルなパターンです。
図 2: 同一アカウント内で Transit Gateway を経由した複数 VPC から ODB@AWS への接続
- Exadata インフラストラクチャまたは ODB ネットワークのクロスアカウント共有
このパターンでは、AWS RAM を使って複数の AWS アカウント間で Exadata インフラストラクチャと ODB ネットワークを共有します。信頼された各 AWS アカウントは、データベースをデプロイするための専用 VM クラスターまたは AVM クラスターを持てます。単一の Exadata インフラストラクチャまたは ODB ネットワークを複数の信頼された AWS アカウントと共有できます。複数の事業部門やチームで Exadata インフラストラクチャを共有することで、コストを削減できます。次の図のように、購入者 AWS アカウント (アカウント 1) はコンパートメント A を持つ OCI テナンシーにリンクされています。Exadata リソースは購入者アカウントから信頼されたアカウント 2 と信頼されたアカウント 3 に共有されています。信頼された各アカウントは、同じ OCI テナンシー配下の OCI 側に対応するコンパートメントを持ちます。
ODB ネットワークとアプリケーション/トランジット VPC 間のクロスアカウントピアリングでは、次の図のように、購入者アカウントから信頼されたアカウントに ODB ネットワークを共有し、信頼されたアカウント内の VPC とピアリングできます。
注: 購入者アカウントの ODB ネットワークを、信頼されたアカウントから AWS RAM で共有された VPC サブネットと直接ピアリングすることはできません。
次の図のように、ODB ネットワークに加えて Exadata インフラストラクチャも信頼されたアカウントと共有できます。非本番と本番のワークロードを別々の AWS アカウントに分離するのに適したアプローチです。
- リソース分離のためのクロスアカウント Marketplace サブスクリプション
次のパターンでは、同一 Organization 内の複数の AWS アカウントに Oracle Database@AWS を分離しつつ、各アカウントが独立して独自の Oracle Database@AWS リソースをプロビジョニングし、そのライフサイクルを完全に管理できるようにします。アカウント A は License Manager を使ってアカウント B とアカウント C にサブスクリプションのエンタイトルメントを共有します。このアプローチは、複数の事業部門にまたがる大規模なデータベースデプロイメントの管理や、ソフトウェア開発ライフサイクル (SDLC) 間でインフラストラクチャを共有しないというコンプライアンスやガバナンスの要件への対応に役立ちます。
- サブスクリプション共有とリソース共有を組み合わせたクロスアカウントハイブリッドモデル
このパターンは、AWS License Manager によるサブスクリプション共有と AWS Resource Access Manager によるリソース共有を組み合わせたクロスアカウントハイブリッドモデルです。次の図では、AWS グランター (購入者) アカウントが AWS License Manager を使ってグランティーアカウントにサブスクリプションを共有しています。購入者アカウントとグランティーアカウントの両方が独自の Exadata インフラストラクチャと ODB ネットワークを作成します。購入者アカウントはさらに、Exadata インフラストラクチャと ODB ネットワークを複数の信頼されたアカウントに共有し、各アカウントは本番/非本番ワークロードのホスティングやアプリケーションごとの分離のために独自の VM クラスターを持ちます。
- クロスアカウントハイブリッドモデル – グランティーアカウントが AWS RAM 共有を実施
次のパターンは、前のパターンを発展させた複雑なクロスアカウントハイブリッドモデルで、グランターとグランティーの両アカウントが AWS RAM を使って自身の信頼されたアカウントに ODB@AWS リソースを共有します。次のアーキテクチャ図のように、グランターとグランティーの両アカウントが独自の Exadata インフラストラクチャと ODB ネットワークをデプロイし、これらの ODB@AWS リソースを複数の信頼されたアカウントに共有しています。サブスクリプション共有と AWS RAM 共有を組み合わせることで、インフラストラクチャ・ODB ネットワークレベルと VM クラスターレベルの 2 段階で分離できます。
- クロスアカウントハイブリッドモデル – 信頼されたアカウントとグランティーアカウントの両方を兼ねるアカウント
次のパターンは、1 つの AWS アカウントが信頼されたアカウントとグランティーアカウントの両方の役割を担う構成です。このユースケースでは、購入者アカウント A が AWS アカウント 2 に対して AWS RAM 共有とサブスクリプション共有の両方を有効にします。アカウント 2 は、アカウント 1 から共有された Exadata と ODB ネットワーク上にリソースをデプロイできます。同時に、アカウント 2 はアカウント 1 から分離された独自の Exadata と ODB ネットワークもデプロイできます。本番ワークロード用に専用 Exadata を持ち、非本番ワークロード用に Exadata を共有するシナリオで有用なパターンです。
次の表は、各 AWS アカウントタイプが実行できる操作をまとめたものです。
✓
✓✓✓
| AWS RAM 共有 | エンタイトルメント共有 | ODB ネットワークの作成 | Exadata インフラストラクチャの作成 | Exa-VMC/AVMC の作成 | |
| 購入者/グランター | ✓ | ✓ | ✓ | ✓ | ✓ |
| 信頼されたアカウント | |||||
| グランティー | ✓ |
考慮事項
ODB@AWS で AWS RAM 共有とエンタイトルメント共有の機能を使い始める前に考慮すべきベストプラクティスは以下のとおりです。あわせて、ODB@AWS のエンタイトルメント共有と AWS RAM 共有の制限事項も参照してください。
- AWS RAM でアカウント間のリソースを共有する場合、リソース所有者アカウントがリソースのライフサイクルを完全にコントロールします。
- 信頼されたアカウントは、付与された権限に基づいて共有リソースを使用できますが、削除はできません。
- 購入者アカウントには、管理アカウントではなく AWS メンバーアカウントの使用を推奨します。
- 信頼されたアカウントは、1 つの購入者アカウント (1 つのオファー) からの共有リソースのみ使用できます。したがって、2 つの購入者アカウントが同じ信頼されたアカウントにリソースを共有することはできません。
- グランティーアカウントは、1 つのグランター (購入者) アカウントからのみライセンス (エンタイトルメント) 付与を受諾でき、同時に有効な付与は 1 つだけです。
- エンタイトルメントは、同じ AWS Organization 内の AWS アカウントとのみ共有できます。
- 組織単位 (OU) 全体や Organization 全体とエンタイトルメントを共有することはできません。
- グランターまたは購入者アカウントは、別のグランターまたは購入者アカウントとエンタイトルメントを共有できません。
- AWS License Manager でのエンタイトルメント付与操作は、バージニア北部 (us-east-1) AWS リージョンからのみ実行できます。ODB@AWS のアクティベーションは OCI テナンシーのホームリージョンで行われ、us-east-1 とは異なる場合があります。
主要な概念
本記事で使用した主要な概念を振り返ります。
AWS Organizations: AWS Organizations は、AWS リソースの成長とスケールに合わせて環境を一元管理・統制するのに役立ちます。Organizations を使うと、アカウントの作成とリソースの割り当て、ワークフローを整理するためのアカウントのグループ化、ガバナンスのためのポリシー適用、アカウントの支払い方法の一本化による請求の簡素化ができます。Organizations は他の AWS サービスと統合されているため、組織内のアカウント全体で中央設定、セキュリティメカニズム、監査要件、リソース共有を定義できます。
購入者アカウント (Buyer account): AWS Marketplace のサービスオンボーディング、AWS アカウントとサービスのリンク、リソースのプロビジョニング、信頼されたアカウントとのリソース共有を担当する AWS アカウントです。Oracle Database@AWS のプライベートオファーをリクエストして受諾するアカウントです。このアカウントは AWS Organization のメンバーアカウントである必要があります。
所有者アカウント (Owner account): 特定のリソースを作成した AWS アカウントは、そのリソースの所有者アカウントとみなされます。たとえば、Exadata インフラストラクチャリソースを作成したアカウントは、そのリソースの所有者アカウントです。通常、Oracle Database@AWS の初期デプロイでは、購入者アカウントが最初の Exadata インフラストラクチャリソースをデプロイするため、そのリソースの所有者アカウントにもなります。2 番目のアカウントがそのインフラストラクチャリソースを使って Exadata VM クラスターを作成した場合、2 番目のアカウントがその VM クラスターの所有者アカウントです。インフラストラクチャリソースの所有者アカウントは、VM クラスターのプロビジョニングに使用する 2 番目のアカウントに対して、リソースへのアクセスを明示的に許可する必要があります。
信頼されたアカウント (Trusted account): IAM ロールを通じて別のアカウント (「信頼する」アカウント) のリソースへのアクセスや操作の実行を許可されたアカウント、または AWS Organization 内で組織を代表してサービスが動作することを許可するアカウントを指します。所有者アカウントから特定のリソースへのアクセスを付与されたアカウントです。Oracle Database@AWS では、所有者アカウントが Exadata インフラストラクチャや ODB ネットワークなどのリソースを、同じ AWS Organization のメンバーである他の AWS アカウントと共有できます。
グランターアカウント (Grantor account): Oracle Database@AWS のサブスクリプションを所有し、AWS License Manager を通じてグランティーアカウントに共有する AWS アカウントです。グランターアカウントは通常、AWS Marketplace で Oracle Database@AWS のプライベートオファーを受諾したアカウントです。AWS License Manager でグラントを作成することで、グランターアカウントは同じ AWS Organization 内の 1 つ以上の AWS アカウントに Oracle Database@AWS サブスクリプションを共有できます。
グランティーアカウント (Grantee account): AWS License Manager を通じてグランターアカウントから Oracle サブスクリプションのグラントを受け取る AWS アカウントです。グラントが受諾・有効化されると、グランティーアカウントは共有サブスクリプションを使って、独立して Oracle Database@AWS リソースのプロビジョニング、管理、更新、削除ができます。グランティーアカウントは、自身が作成したリソースのライフサイクルを完全にコントロールします。グランティーアカウントは、一度に 1 つのグランターアカウントからのみサブスクリプショングラントを受諾できます。
Exadata インフラストラクチャ: Oracle Exadata インフラストラクチャは、Oracle データベース実行用に設計された高性能で統合されたハードウェア・ソフトウェアシステムです。Oracle Exadata データベースを実行するデータベースサーバーとストレージサーバーの基盤アーキテクチャで、AWS アベイラビリティゾーン (AZ) 内に存在します。
ODB ネットワーク: ODB ネットワークは、AWS アベイラビリティゾーン (AZ) 内で OCI インフラストラクチャをホストするプライベートな分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI Child Site 内のネットワークに直接マッピングされ、AWS と OCI 間の通信手段となります。
トランジット Virtual Private Cloud (VPC): ODB ネットワークと直接ピアリングされ、Transit Gateway を通じて他の VPC への接続を仲介する VPC です。
OCI マルチクラウドリンクコンパートメント: クラウドプロバイダーのエンティティに対応する OCI コンパートメントです。リンクされたコンパートメントのデフォルト名はパートナークラウドによって異なります。AWS のコンパートメントには AWS アカウント ID のプレフィックスが付きます。
まとめ
本記事では、AWS アカウント間で ODB@AWS リソースを共有するためのさまざまなオプションを解説しました。あわせて、一般的なクロスアカウントアーキテクチャパターン、ベストプラクティス、重要な考慮事項も紹介しました。ご質問やフィードバックがあれば、コメント欄にお寄せください。
著者について
この記事は Solutions Architect の 矢木 覚 が翻訳しました。