Oracle Database@AWS Provisioning, Deployment, and Configuration
This domain covers the end-to-end build: ordering through AWS, the linked OCI tenancy, Exadata infrastructure, VM clusters, container databases and PDBs, and the configuration choices that are hard to reverse.
Ordering flow
Provisioning starts in AWS. An authorized AWS identity orders Oracle Database@AWS from the AWS Management Console or Marketplace, which creates a linked OCI tenancy and compartments. Everything afterwards - Exadata infrastructure, VM clusters, DB homes, PDBs - is configured in the OCI Console, while billing stays on the AWS invoice. Use a delegated admin role, not the AWS root account.
Configuration sequence
- Pick the AWS region and AZ that match the application footprint.
- Define an OCI VCN with a client subnet and a backup subnet; CIDRs must not overlap the AWS VPC.
- Create Exadata infrastructure: base system shape, storage, maintenance preferences.
- Create the VM cluster: grid infrastructure version, number of database nodes, SSH keys, license type (BYOL or license-included).
- Create the container database - DB home, CDB name, TDE keystore choice - then application PDBs.
Decisions that bite later
- License type is not cosmetic: BYOL requires eligible on-premises licenses.
- The TDE keystore choice (local wallet versus OCI Vault/HSM) is set at CDB creation and drives key management and restore procedures.
- Maintenance windows belong to the Exadata infrastructure, so every VM cluster on it shares one schedule.
Worked example
A team needs a production CDB plus a dev PDB. They order an Exadata base system in us-east-1 AZ-a, create a VCN 10.10.0.0/16 with client 10.10.1.0/24 and backup 10.10.2.0/24, build a two-node VM cluster with BYOL, create CDB PRODCDB with TDE keys in OCI Vault, then add PDBs APP and DEV. Reasoning: two nodes enable RAC, the separate backup subnet isolates backup traffic, and vault-held keys satisfy the policy that keys stay in managed KMS.
Traps
Overlapping VPC/VCN CIDRs; forgetting SSH keys are required at VM cluster creation; assuming the linked tenancy can be swapped later; ignoring that Exadata client VIPs and SCAN addresses consume addresses in the client subnet.