Oracle DatabaseをAWS上で利用したい企業にとって、Oracle Database@AWSは有力な選択肢です。一方で、AWSのマネージドサービスだけで完結する仕組みではなく、AWSとOCIの両方にまたがる契約、アカウント、IAM、ネットワーク設計が必要になります。
特に注意したいのは、データベースをプロビジョニングする前に決めるべき事項が多いことです。購入者となるAWSアカウント、利用するオファー経路、OCIテナンシとのリンク方法、両クラウドの権限設計、組織のSCPとの整合性を後回しにすると、導入途中で作業が止まったり、責任分界が曖昧になったりします。
本稿では、Oracle Database@AWSのオンボーディングを、実務で確認すべき5つのステップに分けて整理します。
1. 最初にサービスと調達経路を決める
まず、どのデータベースサービスを利用するかを決定します。代表的な選択肢には、Autonomous Database on Dedicated Exadata Infrastructure（ADB-D）、Autonomous Database on Shared Exadata Infrastructure（ADB-S）、Exadata Database Service on Dedicated Infrastructure（ExaDB-D）、Exadata Database Service on Exascale Infrastructure（ExaDB-XS）などがあります。
ここで重要なのは、サービスによって調達経路が異なる点です。ADB-SとExaDB-XSはパブリックオファー経路、ExaDB-DとADB-Dはプライベートオファー経路が基本となります。調達方式が異なれば、見積もり、契約、購入承認、利用開始までの関係者も変わります。
購入前には、次の項目を明確にしておくとよいでしょう。
- 必要なデータベース性能、可用性、拡張性
- 専有インフラが必要か、共有インフラで要件を満たせるか
- AWS Marketplaceなどを利用したパブリックオファーで進めるか
- Oracleまたは販売パートナーとのプライベートオファーが必要か
- Oracleライセンスの持ち込みや契約条件との整合性
- 購入者、利用者、運用管理者となる組織・アカウント
特に購入者アカウントは、後から変更する前提で決めないことが重要です。請求を集約する管理アカウントと、実際にデータベースを配置するメンバーアカウントを分ける場合、どのアカウントで契約・購読し、どのアカウントに利用権限を委譲するのかを事前に整理します。
2. AWSアカウントとOCIテナンシの関係を設計する
Oracle Database@AWSは、AWS上で利用できるサービスでありながら、Oracle Cloud Infrastructure（OCI）のテナンシやリージョンとの連携が前提になります。そのため、AWS側のアカウント設計だけでなく、OCI側のテナンシ構成も導入計画に含める必要があります。
ここでの実務上のポイントは、AWSアカウントとOCIテナンシを誰が所有・管理するかです。企業によっては、AWSはクラウド基盤部門、OCIはデータベース部門やOracle専門チームが管理していることがあります。この場合、テナンシのリンク作業や承認作業の責任者が曖昧になりやすくなります。
事前に以下を決めておきます。
- 使用するAWSアカウントとAWSリージョン
- 連携対象となるOCIテナンシとリージョン
- AWSアカウントとOCIテナンシの管理責任者
- テナンシのリンクやサービス有効化を実行する担当者
- 本番、検証、開発環境を同一テナンシに置くか分離するか
- 障害対応時にAWSチームとOCIチームがどのように連携するか
AWS側のアカウント構成だけを先に確定し、OCI側の利用単位や管理者を後から決めると、環境分離や権限設計をやり直すことになりがちです。
3. AWSとOCIのIAMを別々に設計する
Oracle Database@AWSでは、AWS IAMだけ設定すればよいわけではありません。AWS上の操作権限と、OCI上のリソース操作権限は別の管理体系に基づきます。
AWS側では、購入、サブスクリプション、ネットワーク、サービス起動、ログ確認などに必要なIAM権限を整理します。一方、OCI側では、テナンシ、コンパートメント、ネットワーク、データベース関連リソースに対する権限やポリシーを設計します。
実務では、管理者権限を一時的に付与して導入を進め、そのまま恒久運用に移行してしまうケースに注意が必要です。オンボーディング用の権限と、日常運用用の権限を分け、導入完了後に不要な権限を削除する運用が望まれます。
IAM設計のチェックポイントは次のとおりです。
- 購入担当者とプロビジョニング担当者を分離するか
- AWS側で必要なサービス操作権限を特定しているか
- OCI側で必要なコンパートメント権限を定義しているか
- 本番環境への変更権限を限定しているか
- 人による直接操作と自動化ジョブの権限を分離しているか
- 監査ログをAWS、OCIの両方で確認できるか
- 導入時の一時権限を終了後に見直す手順があるか
AWSのIAMロールとOCIのポリシーを同じものとして扱うのではなく、それぞれの責任範囲を明確にすることが重要です。
4. ネットワークと接続方式をプロビジョニング前に確定する
データベースを作成してからネットワークを考えると、アプリケーション接続や運用アクセスの設計変更が発生しやすくなります。VPC、サブネット、ルート、セキュリティグループ、名前解決、接続元の制御を、データベース作成前に確認します。
特に確認したいのは、アプリケーションが稼働するサブネットとデータベースの接続要件です。業務システム、バッチ、監視、バックアップ、運用端末など、接続元ごとに必要な通信を洗い出し、許可するポートや宛先を最小限に抑えます。
また、AWSのVPC設計だけでなく、OCI側のネットワークやサービス境界も関係します。ネットワーク担当者がAWSだけを確認し、OCI側の接続条件を確認していない場合、プロビジョニング後に接続できない問題が発生する可能性があります。
最低限、次の情報を設計書に記載しておきます。
- 配置するAWSリージョンとVPC
- データベース用サブネットのアドレス範囲
- アプリケーションからの接続経路
- 管理・監視・バックアップに必要な通信
- セキュリティグループやネットワークACLの方針
- DNS名の解決方法
- オンプレミスや他リージョンからの接続要件
- 将来のデータベース追加を考慮したアドレス設計
AWSネイティブなデータベースサービスの感覚で、AWS側の設定だけを見て判断しないことがポイントです。Oracle Database@AWSでは、AWSとOCIの境界をまたぐ設計確認が必要になります。
5. SCP、ジョブ分離、運用フローを確認する
AWS Organizationsを利用している企業では、Service Control Policy（SCP）が導入の障害になることがあります。リージョン制限、特定サービスの拒否、IAM操作の制限、ネットワーク変更の制限などが、Oracle Database@AWSの購入やプロビジョニングに影響する可能性があります。
SCPは権限を付与する仕組みではなく、組織全体で許可できる操作の上限を定める仕組みです。そのため、IAMポリシーで必要な権限を与えていても、SCPで拒否されていれば操作は失敗します。
導入前には、対象アカウントに適用されるSCPを確認し、次のような制約がないかを調査します。
- 利用予定リージョンが許可されているか
- 必要なAWSサービスやAPI操作が拒否されていないか
- IAMロール作成やサービスリンクロールに制限がないか
- ネットワーク関連のリソース作成が制限されていないか
- Marketplaceや契約関連の操作が管理アカウントに限定されていないか
加えて、導入処理を実行するジョブと、日常運用のジョブを分離します。購入・リンク・初期プロビジョニングと、バックアップ確認、監視、パッチ適用、スケール変更などを同じロールや自動化基盤に集約すると、権限過多や誤操作のリスクが高まります。
推奨される分離例は以下です。
- 購入・契約確認用の担当者またはロール
- 初期オンボーディング専用のロール
- データベース運用専用のロール
- 監視・参照専用のロール
- 変更・破棄を承認する管理者ロール
導入方式ごとの比較
パブリックオファーは、標準化された条件で比較的スムーズに調達しやすい一方、企業固有の契約条件や大規模な購入設計には向かない場合があります。対象サービスの要件が明確で、標準的な調達プロセスに適合する組織に向いています。
プライベートオファーは、契約期間、価格、利用規模などを個別に調整しやすい反面、Oracleや販売パートナー、調達部門、AWS管理者など複数の関係者との調整が必要です。契約締結から利用開始までのリードタイムも考慮し、検証環境と本番環境を同じタイミングで進めるかを検討します。
どちらを選ぶ場合でも、価格だけでなく、次の観点で比較することが大切です。
- 調達完了までの期間
- 契約変更のしやすさ
- 利用量の見通し
- 請求と予算管理の方法
- サポート窓口と障害時の責任分界
- 本番・検証環境の追加時に必要な手続き
プロビジョニング前チェックリスト
最後に、導入開始前の確認事項をまとめます。
調達
- [ ] 利用するデータベースサービスを決定した
- [ ] パブリックオファーかプライベートオファーか確認した
- [ ] 購入者となるAWSアカウントを決定した
- [ ] 契約、請求、利用部門の責任者を決めた
AWS・OCI連携
- [ ] AWSアカウントとOCIテナンシを決定した
- [ ] 利用リージョンと環境分離方針を決めた
- [ ] AWS側とOCI側の管理責任者を明確にした
- [ ] 障害対応時の連絡経路を定義した
IAMとガバナンス
- [ ] AWS IAMの導入・運用権限を分離した
- [ ] OCIのコンパートメントとポリシーを設計した
- [ ] 一時的な高権限の利用方法を決めた
- [ ] SCPによる拒否条件を確認した
- [ ] 自動化ジョブごとの権限を分離した
ネットワーク
- [ ] VPC、サブネット、ルートを決定した
- [ ] アプリケーション、運用、監視の通信要件を確認した
- [ ] セキュリティグループと名前解決を設計した
- [ ] 将来の拡張用アドレスを確保した
まとめ
Oracle Database@AWSの導入で難しいのは、データベースを作成する操作そのものではありません。AWSの調達・アカウント・IAM・SCPと、OCIのテナンシ・ポリシー・ネットワークを一つの導入計画として整合させることが重要です。
特に、パブリックオファーとプライベートオファーの違い、購入者アカウントの選定、AWSとOCIの責任分界、SCPによる制約、導入ジョブと運用ジョブの分離は、購入前に決めておくべき主要事項です。
AWS上でOracle Databaseを使えることだけに注目するのではなく、誰が購入し、誰が権限を持ち、どのネットワークから接続し、障害時にどのチームが対応するのかまで設計しておくことで、導入後の手戻りと運用リスクを大きく減らせます。
出典： AWS公式ブログ