Oracle Database@AWS を始める: オンボーディング完全ガイド

本記事は 2026 年 9 月 8 日 に公開された「Getting started with Oracle Database@AWS: A complete onboarding guide」を翻訳したものです。

Oracle Database@AWS (ODB@AWS) は、Oracle Exadata Database Service と Oracle Autonomous Database を AWS データセンター内でネイティブに提供します。Oracle ワークロードは専用設計の Exadata インフラストラクチャ上で動作し、Amazon Bedrock、Amazon Redshift、AWS Key Management Service (AWS KMS)、Amazon CloudWatch、AWS CloudTrail といった AWS サービスに低レイテンシーでアクセスできます。同時に、Oracle データベースエンジン、Exadata のパフォーマンス特性、そしてチームが現在使っている DBA ツールもそのまま維持できます。

本記事では、Oracle Database@AWS のオンボーディングを、サービスの選定からプロビジョニング可能な環境が整うまで通して解説します。必要なサービスに応じて、簡略化されたパブリックオファーの経路と、5 ステップからなるプライベートオファーの経路のどちらかをたどります。どちらの経路も解説します。

Autonomous Database Serverless (ADB-S) と Exascale Infrastructure (ExaDB-XS) 上の Exadata Database Service については、AWS Marketplace でパブリックオファーが提供されており、事前の調達手続きは要りません。サブスクライブすれば数分でプロビジョニングを始められます。ステップ 1 のサービス選定表で、適切な出発点がわかります。

オンボーディングの全体像

サービスの選定からプロビジョニング可能な環境が整うまでの流れは、2 つのフェーズに分かれます。

• 調達 (ステップ 1〜2): サービスを選び、オファー (パブリックまたはプライベート) を確保し、AWS Marketplace で承諾します。
• オンボーディング (ステップ 3〜5): アカウントの前提条件を確認し、OCI テナンシをリンクし、両クラウドで ID とアクセス許可を設定します。

ここまで終われば、プロビジョニングの準備が整います。ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターの作成は「次のステップ」で扱います。

2 つのフェーズに対応する 5 つのステップは次のとおりです。

1. サービスを選定し、オファーを確保する。
2. オファーを承諾する。
3. 前提条件を確認する。
4. OCI テナンシをリンクする。
5. AWS Identity and Access Management (IAM) のグループとロールを設定する。

次の図は、5 つのステップを 2 つのフェーズにグループ分けしたものです。

図 1: 調達フェーズとオンボーディングフェーズに分けた 5 つのオンボーディングステップ

ステップ 1: サービスを選定し、オファーを確保する

まず、ワークロードに適した Oracle Database@AWS のサービスを見極めます。選んだサービスによって、使える機能とたどる調達経路の両方が決まります。

サービスと調達経路を選ぶ

ワークロードが ExaDB-XS または ADB-S に合っていて、パブリックオファーで要件を満たせるなら、インフラストラクチャのサイジングや Oracle との事前調整は要りません。Oracle Database@AWS の AWS Marketplace ページからサブスクライブし、ステップ 3 に進んでください。パブリックオファーで提供されるサービスの最新のリージョン対応状況は、Regional Availability for Oracle AI Database@AWS を参照してください。

ExaDB-D または ADB-D をデプロイする場合、あるいは交渉価格やコミット条件が必要な場合は、以降のセクションのプライベートオファーのプロセスに進みます。

プライベートオファーをリクエストする

プライベートオファーは、ワークロード要件に合わせて自社と Oracle の間で結ぶ交渉ベースの契約です。手順は次のとおりです。

• AWS Management Console の Oracle Database@AWS 製品ページで Request private offer を選びます。OCI にリダイレクトされ、AWS リージョン、ワークロード要件、連絡先情報を入力します。
• あるいは、Oracle のアカウントチームか AWS チャネルパートナーに直接依頼してリクエストを開始することもできます。
• 最初に AWS アカウント ID を伝えます。Oracle が正しいアカウント向けにオファーを生成するために必要です。

ヒント: AWR Miner や Oracle 提供のサイジングユーティリティ (Cloud Premigration Advisor Tool (CPAT)、ORAchk) を、移行元データベースに対して早い段階で実行しておきましょう。出力はそのままサイジング作業に使えるため、最初から精度の高いオファーを組み立てられます。

購入者アカウントを選ぶ

ODB@AWS を調達すると、エンタイトルメントは購入者アカウント (buyer account) と呼ばれる単一の AWS アカウントに紐付きます。マルチアカウント環境では、組織の管理アカウントである必要はありません。AWS のベストプラクティスとしては、商用契約を保持する専用の購入者アカウントを推奨します。購入者アカウントは AWS Resource Access Manager (AWS RAM) を使い、同一 AWS Organization 内のワークロードアカウントとエンタイトルメントを共有します。調達のガバナンスとインフラストラクチャのデプロイを分離でき、監査証跡も明確に保てます。単一ワークロードのデプロイなら、購入者アカウントとワークロードアカウントを同じにしても構いません。

重要: 購入者アカウントは、オンボーディング後に OCI テナンシと恒久的にリンクされます。後から変更するには再オンボーディングが必要です。

オファーをリクエストする前に、概念実証 (PoC) の段階であってもアカウントの選定を済ませておきましょう。本番で使う予定の購入者アカウントで PoC を始めれば、プライベートオファーをその場で追加するだけで本番へ移行できます。OCI テナンシのリンク、ネットワーク構成、既存のインフラストラクチャはそのまま引き継がれます。オンボーディング後に購入者アカウントを変更すると、再オンボーディングを一からやり直すことになり、OCI テナンシの再マッピング、ネットワークの再構築、場合によってはデータ移行まで必要になります。

マルチアカウント構成の組織では、AWS License Manager を使い、購入者アカウントから同一 AWS Organization 内のワークロードアカウントへ ODB@AWS のサブスクリプションを共有できます。アカウント間のリソース共有には AWS Resource Access Manager (AWS RAM) を使います。オファーをリクエストする前に、購入者アカウントの方針を決めておきましょう。

• シンプル構成: 購入者アカウントとワークロードアカウントが同一。単一ワークロードや PoC のデプロイに向いています。
• エンタープライズ構成: 専用の購入者アカウントまたは調達アカウントを用意し、License Manager でエンタイトルメントを共有します。複数のワークロードアカウントを持つランディングゾーンのパターンに向いています。

詳細な手順は Request Offer for Oracle AI Database@AWS を参照してください。マルチアカウントでの共有については Subscription Sharing for Oracle AI Database@AWS を参照してください。

ターゲットアーキテクチャとサイジングを決める (ExaDB-D と ADB-D)

専用インフラストラクチャのサービスでは、サイジングによって SKU の数量が決まり、それがそのままオファーに反映されます。サイジングは Oracle、AWS、そしてチャネルパートナーが関わる場合はパートナーも含めた共同作業です。移行元データベースの AWR Miner の出力を Oracle に提供します。そのデータをもとに、ワークロードの特性を Exadata の構成 (シェイプ、ECPU の割り当て、ストレージ容量、環境数) に落とし込む作業を Oracle が支援します。

データベース層では、次の点を計画します。

• Exadata インフラストラクチャの配置 (アベイラビリティーゾーンの選定)。
• VM クラスターの構成。一般には本番クラスター、マルチ AZ Data Guard 用の DR クラスター、1 つ以上の非本番クラスターです。
• Oracle のマルチテナントアーキテクチャを使った CDB/PDB の統合方針。
• Autonomous Recovery Service (ARS)、Amazon Simple Storage Service (Amazon S3)、またはその両方を使ったバックアップ方針。Navigating backup and recovery options for Oracle Database@AWS を参照してください。
• クライアントサブネットとバックアップサブネットの CIDR を含む ODB ネットワークの設計。

アプリケーション層では、次の点を計画します。

• app-to-DB のレイテンシーを 200 マイクロ秒未満にするため、ODB@AWS のプレイスメントグループ内に EC2 インスタンスを配置する。高性能ネットワーキングのプレイスメントグループを参照してください。
• Virtual Private Cloud (VPC) の設計、サブネット、セキュリティグループ、ODB ピアリングの接続構成。
• ロードバランシング (Application Load Balancer または Network Load Balancer) と Auto Scaling グループ。
• コンテナ化したアプリケーションコンポーネント向けの Amazon Elastic Kubernetes Service (Amazon EKS) または Amazon Elastic Container Service (Amazon ECS)。
• Amazon Elastic File System (Amazon EFS) による共有ストレージ、Amazon CloudWatch によるモニタリング、Terraform または AWS CloudFormation による Infrastructure as Code。

オファーの種類を選ぶ

Oracle のプライベートオファーには、調達チャネルに応じて 2 種類あります。

• すでに Oracle と直接取引があるなら MPPO を選びます。
• チャネルパートナー経由で調達する場合、またはそのパートナー経由で請求をまとめたい場合は CPPO が適しています。
• 請求モデルを最初に確認しておきます。自社の AWS アカウントへの直接請求 (MPPO) か、パートナー経由 (CPPO) かです。

オファーの前提情報を揃える: アカウント ID、SKU、契約条件

Oracle またはチャネルパートナーがオファーを生成する前に、次の情報を揃えます。

• AWS 購入者アカウント ID: オファーを承諾する 12 桁の AWS アカウント ID。
• 検討対象の SKU:
  • Exadata Cloud Infrastructure X11M および X11MV (データベースサーバーとストレージサーバーを含む固定インフラストラクチャコスト)。
  • Exadata Database ECPU、License Included または BYOL (変動するコンピュートコスト)。
  • Autonomous Database を使う場合は Autonomous AI Database ECPU (LI または BYOL)。
  • パブリックオファーのサービスを使う場合は ExaDB-XS または ADB-S (従量課金、最小コミットメントなし)。
  • バックアップ要件に応じて Autonomous Recovery Service または Zero Data Loss Recovery。
  • OCI 側のストレージを追加で必要とする場合は OCI Object Storage。
• 契約期間: 通常は 1 年、3 年、またはカスタム期間。
• SKU ごとのライセンスモデル: License Included (LI) または Bring Your Own License (BYOL)。

各環境 (本番、DR、非本番) を、具体的な SKU の数量と使用時間に対応付けます。ECPU コストを最適化するため、非本番環境の稼働時間を決めておきます。非本番環境では月 264 時間が一般的な目安です。

Oracle がオファーを生成する

前提情報がすべて確定した後、最終的な入力からオファーが利用可能になるまでの目安は 2〜5 営業日です。流れは次のとおりです。

• Oracle の営業担当が、指定された購入者アカウントを対象に AWS Marketplace 上でプライベートオファーを作成します。
• オファーには、合意した SKU、数量、価格、契約期間が含まれます。
• CPPO の場合、Oracle はチャネルパートナーから提供された情報をもとにオファーを生成します。
• オファーは AWS Management Console の Oracle Database@AWS に表示されます。View private offer を選んで内容を確認し、承諾します。

詳細な手順は Purchase Oracle AI Database@AWS を参照してください。

ステップ 2: オファーを承諾する

Oracle からプライベートオファーが提示されたら、AWS Management Console で承諾し、Oracle Database@AWS のサブスクリプションを有効化します。

オファーを承諾する手順は次のとおりです。

1. AWS Management Console で Oracle Database@AWS に移動し、View private offer を選びます。
2. オファーの条件、価格、EULA を確認します。
3. Create contract を選び、画面の指示に従って承諾します。
4. 承諾後、コンソールに表示されるアクティベーションリンク、またはメールで届いたリンクから OCI アカウントを有効化します。
5. Oracle Cloud アカウントを新規作成するか、既存のアカウントをリンクするかを選びます。
6. アクティベーションを完了します。完了が確認されるとダッシュボードが使えるようになります。

マルチアカウント構成の組織では、次の対応が可能です。

• AWS License Manager を使い、AWS Organization 内のアカウント間で ODB@AWS のサブスクリプションを共有する。
• 調達を単一の支払いアカウントに集約しつつ、プロビジョニングはワークロードアカウントで行う。

注: Oracle Database@AWS のダッシュボードは、プライベートオファーを承諾する (またはパブリックオファーでサブスクライブする) までは使えません。オンボーディングが完了するまで、プロビジョニングの API 呼び出しは失敗します。

オンボーディングが完了すると、AWS アカウントが OCI テナンシとリンクされ、サポート対象のリージョンに複製されます。OCI コンソールから使いたいリージョンを有効化すれば、サブスクリプションの手続きを繰り返さずに、サポート対象の AWS リージョンで Oracle Database@AWS を使えます。

ステップ 3: 前提条件を確認する

OCI テナンシのリンクと AWS Identity and Access Management (IAM) の設定に進む前に、AWS アカウント環境の準備が整っているか確認します。次のチェックリストが主な確認項目です。

ネットワーク計画の詳細

• クライアントサブネットの CIDR: ODB ピアリング経由でアプリケーションがデータベースに接続するために使います。
• バックアップサブネットの CIDR: OCI Autonomous Recovery Service または Amazon S3 へのバックアップトラフィックに使います。
• どちらの CIDR も /24 以上が必要で、既存の VPC のアドレス空間と競合してはいけません。
• アプリケーション VPC と ODB ネットワークの間の ODB ピアリング接続も計画しておきます。

Service Control Policy (SCP) に関する考慮点

リージョンを制限する SCP を適用している組織では、ODB@AWS のオンボーディング時に特有の注意点があります。主なデプロイ先がどこであっても、次の 2 つのリージョンを許可する必要があります。

• 米国東部 (バージニア北部) us-east-1: AWS License Manager のエンタイトルメント付与、AWS Marketplace のサブスクリプション承諾、グローバルサービス (IAM、AWS Organizations、STS) に必要です。SCP でこのリージョンを制限したままワークロードを別リージョンにデプロイすると、エンタイトルメントの共有が失敗します。
• 対象の ODB@AWS リージョン: Exadata インフラストラクチャ、ODB ネットワーク、VM クラスターをプロビジョニングするリージョンです。

重要: 組織レベルの AWS Service Control Policy (SCP) や権限境界はユーザーの権限を上書きし、オンボーディングの失敗につながることがあります。作業を進める前に AWS Organization の管理者に確認してください。

ステップ 4: OCI テナンシをリンクする

Oracle Database@AWS はコントロールプレーンが分かれています。ネットワークや Exadata などのインフラストラクチャリソースは AWS 側で管理し、DB Home、PDB、パッチ適用といったデータベース管理は OCI 側が担います。そのため、インフラストラクチャには慣れた AWS のツールを使いながら、データベースのライフサイクル層は Oracle が管理します。OCI テナンシのリンクは、2 つのコントロールプレーンをつなぐクラウド間の接続を確立する作業です。

OCI テナンシは、対象の AWS リージョンとペアになる OCI リージョンにサブスクライブされている必要があります。たとえば米国東部 (バージニア北部) は OCI の US East (Ashburn) と、アジアパシフィック (シドニー) は OCI の Australia East (Sydney) とペアになります。現在のペアリングの一覧は Supported Regions for Oracle Database@AWS を参照してください。

リンクしたテナンシでは、日々のデータベース運用を次のように行います。

• データベースのコントロールプレーン: OCI コンソールまたは API から DB Home、CDB、PDB を作成・管理します。
• Data Guard: 高可用性と DR のためにスタンバイデータベースを構成します。
• バックアップ管理: OCI Object Storage または Amazon S3 への自動バックアップ。
• パッチ適用: データベース、Grid Infrastructure、OS のパッチを自社のスケジュールで適用します。
• モニタリング: OCI 側のパフォーマンスメトリクスと診断情報。

注: オンボーディング時にテナンシを新規作成した場合、オンボーディングを実施したユーザーが自動的に OCI テナンシの管理者になります。

ステップ 5: グループとロールを設定する

ODB@AWS では、AWS 側と OCI 側の両方で IAM の権限設定が必要です。2 つのクラウドにまたがるガバナンスモデルでは、最小権限と職務の分離を保つために入念な計画が求められます。

AWS IAM の権限

ODB@AWS では、プロビジョニング権限を付与する出発点として AmazonODBFullAccess という AWS 管理ポリシーが用意されています。インフラストラクチャチームが使う IAM ロールまたは許可セットにアタッチしてください。このポリシーは、ODB ネットワークと VM クラスターの作成に必要な odb:* の主要アクションと EC2 ピアリング操作を含みます。

次の例は、ネットワーク、プレイスメントグループ、DNS に関して追加することが多い権限をまとめたものです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ODBFullAccess",
            "Effect": "Allow",
            "Action": ["odb:*"],
            "Resource": "*"
        },
        {
            "Sid": "NetworkingForODB",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVpc", "ec2:CreateSubnet",
                "ec2:CreatePlacementGroup", "ec2:DescribePlacementGroups",
                "ec2:CreateTags",
                "route53resolver:CreateResolverEndpoint",
                "route53resolver:CreateResolverRule"
            ],
            "Resource": "*"
        }
    ]
}

重要: この例の odb:* は Oracle Database@AWS のすべての API アクションへのアクセスを許可するもので、初期セットアップや PoC デプロイの出発点として想定しています。本番環境では、odb:* をワークロードに必要なアクションだけ (たとえば odb:CreateOdbNetwork、odb:CreateCloudExadataInfrastructure、odb:CreateCloudVmCluster) に置き換え、Resource 要素も特定の ARN に絞り込んでください。アクションの全一覧は Actions, resources, and condition keys for Oracle Database@AWS を、最小権限のガイダンスは AWS managed policies for Oracle Database@AWS を参照してください。

管理ポリシーには、アーキテクチャの選択に依存する権限があえて含まれていません。次の権限はカスタマー管理ポリシーで追加します。

必要なアクションをすべて含む完全なポリシー JSON は、AWS managed policies for Oracle Database@AWS を参照してください。

DNS 計画に関する注意: プロビジョニング後、アプリケーション VPC から ODB ネットワーク内の Oracle データベースのホスト名 (SCAN リスナー) を解決できるようにする必要があります。そのためには、Amazon Route 53 のアウトバウンドエンドポイントと、ODB ネットワークの DNS リスナーを宛先とする転送ルールが必要です。IAM 権限 (route53resolver:*) とサブネットの配置は、この段階で計画しておきましょう。設定は ODB ネットワークを作成した後に行います。詳細は Configuring DNS for Oracle Database@AWS を参照してください。

OCI IAM の権限

OCI テナンシの管理者でないユーザーは、対象コンパートメントで次のポリシーステートメントを持つグループに所属する必要があります。

# Broad admin access (simplest)
Allow group <group_name> to manage database-family in compartment <compartment_name>

# Narrower least-privilege policies
Allow group <group_name> to use cloud-vmclusters in compartment <compartment_name>
Allow group <group_name> to manage db-homes in compartment <compartment_name>
Allow group <group_name> to manage databases in compartment <compartment_name>
Allow group <group_name> to manage db-backups in compartment <compartment_name>

職務の分離

各ロールに必要な範囲だけにアクセスを絞れるよう、ペルソナとクラウドごとの権限を対応付けます。

注:「Missing permissions: P[DB_HOME_CREATE], P[DATABASE_CREATE]」というエラーが出る場合、マッピングされたコンパートメントの OCI IAM ポリシーに「manage db-homes」と「manage databases」が不足しています。AWS 側ではなく OCI 側の権限の問題です。

AWS と OCI 間の ID フェデレーション

ODB@AWS では運用の境界が明確です。VM クラスターまでのインフラストラクチャとネットワーク層は AWS が担い、その内側のデータベースライフサイクル層は OCI が担います。ID は両方のクラウドをまたいで使えるため、個別の認証情報は不要で、OCI 側で新しいユーザー、ロール、グループを作る必要もありません。

オンボーディング時に、OCI が必要な ID 構成を自動的に作成します。具体的には、テナンシのリンク、AWS アカウントと 1 対 1 で対応するコンパートメント、そしてマルチクラウドサービスがユーザーに代わって操作することを認可する IAM ポリシーとユーザーグループのセットです。ユーザーは引き続き IAM か、IAM Identity Center 経由で社内の ID プロバイダーで認証します。OCI 側の認可はクラウド間の信頼関係が透過的に処理します。

日々のインフラストラクチャ作業では、AWS コンソールから離れる必要はありません。CDB/PDB の作成、Data Guard の構成、パッチ適用といったデータベースのライフサイクル操作では、AWS コンソールの Manage in OCI ボタンから OCI コンソールを開きます。SAML フェデレーションを構成しておけば、別途ログインせずに認証済みの状態で OCI コンソールに移動できます。

注: AWS 側の「コンソール」は AWS Management Console を指します。OCI 側の「コンソール」は、Manage in OCI ボタンからアクセスする Oracle Cloud Console を指します。SAML フェデレーションを構成していれば、OCI に別途ログインする必要はありません。

オプション: SAML フェデレーションを設定する

データベース運用のために OCI コンソールへアクセスする必要があるチームでは、SAML フェデレーションを構成すれば既存の社内 ID プロバイダーでシングルサインオンできます。SAML フェデレーションの構成はオンボーディング後のオプション作業で、AWS 側・OCI 側の操作を妨げるものではありません。OCI 専用のユーザー認証情報を作成・管理する手間もなくなります。作業内容は、ID プロバイダー (IAM Identity Center、Okta、Azure AD、または SAML 2.0 対応の IdP) を OCI Identity Domains に登録し、グループをオンボーディング時に自動作成された OCI グループにマッピングすることです。手順の詳細は Federation for Oracle AI Database@AWS and Federating with SAML 2.0 Identity Providers を参照してください。

ID 管理の姿を整理すると、OCI のユーザー作成もグループ管理もロールの割り当てもパスワードのローテーションも不要です。自動作成されるポリシーとフェデレーションがすべてを引き受けます。セキュリティチームは 1 つの ID 基盤を維持すればよく、運用チームは主に AWS コンソールで作業し、OCI 側のデータベース操作は ID 管理の負担なく SSO でアクセスできます。

次のステップ

5 つのステップが完了すれば、環境のオンボーディングは終わり、プロビジョニングを始められます。次のような作業が可能です。

• プレイスメントグループの自動プロビジョニングを伴う ODB ネットワークの作成。
• ExaDB-D 向けの Oracle Exadata インフラストラクチャ (Quarter、Half、Full Rack) のデプロイ。
• 高可用性のための RAC 構成の Exadata VM クラスターの作成。
• アプリケーション VPC と ODB ネットワークの間の ODB ピアリングの確立。
• app-to-DB のレイテンシーを 200 マイクロ秒未満にするため、プレイスメントグループ内での EC2 インスタンスの起動。

プロビジョニングの手順は、AWS ドキュメントの Getting started with Oracle Database@AWS を参照してください。

まとめ

本記事では、Oracle Database@AWS のオンボーディングを一通り解説しました。パブリックオファーのサービス (ADB-S と ExaDB-XS) なら、AWS Marketplace のサブスクリプションとアカウントの前提条件を満たすだけで始められます。専用インフラストラクチャのサービス (ExaDB-D と ADB-D) では、オファーの調達、テナンシのリンク、2 つのクラウドにまたがる IAM 設定を 5 つのステップで進めます。サービスの選定、サイジング、購入者アカウントの方針、IAM を事前にしっかり計画しておくことが、プロビジョニングを滞りなく進める鍵になります。

オンボーディングが済んだら、次は ODB ネットワークの作成、Exadata インフラストラクチャのプロビジョニング、最初の VM クラスターのデプロイに進みます。次のリソースが役立ちます。

• プロビジョニングのガイドと API リファレンスは Oracle Database@AWS のドキュメント。
• マルチアカウントのパターンは Best practices for cross-account sharing in Oracle Database@AWS。
• 料金、リージョン、機能の概要は Oracle Database@AWS の製品ページ。

まずは AWS Marketplace の Oracle Database@AWS にアクセスしてみてください。ADB-S と ExaDB-XS はパブリックオファーで直接サブスクライブできます。専用インフラストラクチャのサービスは、AWS Management Console からプライベートオファーをリクエストしてください。

著者について

この記事は Solutions Architect の 矢木 覚 がレビューしました。