Oracle Database@AWS Architect Professional cheat sheet

Oracle Database@AWS runs Exadata infrastructure inside AWS Availability Zones, with Oracle-managed Exadata and database software and AWS-managed networking, compute, and storage underneath.

The service is delivered through a private connection between the customer VPC and the Oracle-managed VPC; no public internet path is required for database traffic.

A single Exadata infrastructure resource can host multiple VM clusters; each VM cluster maps to one or more Oracle databases and consumes a defined number of database and storage servers.

Design decision: choose the number of Exadata database servers and storage servers up front because infrastructure shape is fixed at provisioning and resizing requires additional infrastructure or migration.

RAC is supported on Exadata VM clusters, so an HA design places RAC instances across database servers within the same Exadata infrastructure in one AZ.

Cross-AZ resilience requires a Data Guard standby on separate Exadata infrastructure in a second AZ or Region; the primary and standby do not share a single Exadata failure domain.

ODB@AWS is an Oracle-managed service: patching of Exadata infrastructure and the grid infrastructure is performed by Oracle, while database and application changes remain the customer's responsibility.

Sizing rule: aggregate peak IOPS and throughput across all databases on the VM cluster, then confirm the selected Exadata shape provides headroom, because storage performance is shared across databases on the same infrastructure.

Licensing: Oracle Database@AWS supports bring-your-own Oracle license (BYOL) and license-included models; the choice affects cost and must be fixed per database at provisioning time.

Provisioning sequence: create the ODB network, then the Exadata infrastructure, then the VM cluster, then the Oracle database; each step depends on the previous resource being available.

The ODB network is created in a specific AWS AZ and is associated with the customer VPC through a private connection; the VPC and ODB network must be in the same AWS Region.

Exadata infrastructure provisioning requires selecting shape (for example, quarter, half, or full rack equivalents), number of database servers, and number of storage servers.

VM cluster creation requires selecting the Exadata infrastructure, the ODB network, the grid infrastructure version, the Oracle Grid Infrastructure software image, and SSH key pairs.

Database creation on a VM cluster requires a database name, unique name, Oracle home, database edition, character set, and storage size; these parameters cannot be changed after creation without recreating the database.

Oracle-managed maintenance runs during a customer-selected maintenance window; the window applies to infrastructure and grid infrastructure patching and must be set at VM cluster or infrastructure level.

Tagging: AWS tags on ODB resources are used for cost allocation and access control; Oracle-side tags are separate, so a consistent tagging scheme must be applied on both sides.

Deployment validation: confirm the private connection status is Available, the VM cluster is Available, and the database is Open before handing the environment to application teams.

Network path: application subnet in the customer VPC reaches the ODB network through a private connection; the ODB network has its own CIDR that must not overlap with the VPC CIDR or any peered network.

Security groups in AWS control traffic at the VPC and ODB network boundary; Oracle Database listener ports (for example 1521) must be allowed from application security groups only.

The ODB network CIDR is assigned at creation and is used for the client and backup subnets; plan it large enough for RAC VIPs, SCAN VIPs, and node IPs.

Identity: AWS IAM controls who can call the ODB APIs (create, delete, tag infrastructure), while Oracle database users and roles control data access; the two planes are independent.

For centralized database authentication, integrate Oracle Database with AWS Managed Microsoft AD or an on-premises AD through Oracle Enterprise User Security or Centrally Managed Users.

Encryption: data at rest is encrypted by default using AWS KMS keys associated with the ODB resources; customer-managed keys can be selected at provisioning for control over rotation and revocation.

Auditing: Oracle Unified Auditing policies are configured inside the database; AWS CloudTrail records ODB API calls, so both must be enabled for a complete audit trail.

Network isolation rule: do not attach an internet gateway route to the ODB network; all database client traffic should originate from the associated VPC or connected networks via private routing.

High availability within an AZ uses Oracle RAC on the Exadata VM cluster; RAC provides instance-level failover but does not protect against AZ failure.

Cross-AZ or cross-Region disaster recovery uses Oracle Data Guard; the standby database runs on separate Exadata infrastructure in a different AZ or Region.

Backup: use Oracle Recovery Manager (RMAN) to back up to object storage or to a backup destination reachable from the ODB network; AWS Backup integration may be available depending on the current service release.

Monitoring: Oracle Enterprise Manager or Cloud Control can monitor databases on ODB@AWS; AWS CloudWatch receives infrastructure metrics exposed by the service.

Patching: Oracle applies Exadata infrastructure and Grid Infrastructure patches during the maintenance window; database patches are applied by the customer or through automation.

Migration options: use Oracle Data Pump, RMAN restore, or Data Guard switchover from on-premises or from another cloud; GoldenGate supports ongoing replication with minimal downtime.

Scaling: adding database servers to an existing Exadata infrastructure requires a maintenance action; adding storage servers changes capacity but not compute, so plan compute and storage scaling separately.

Decommissioning order: drop or migrate databases first, then delete the VM cluster, then the Exadata infrastructure, then the ODB network; deleting a parent resource before its children fails.