Oracle Database@Azure, Oracle Database@AWS, and Oracle Database@Google Cloud Architecture
Common architecture
Oracle Database@Azure, Oracle Database@AWS, and Oracle Database@Google Cloud all place Oracle-managed Oracle Database services, including Exadata Database Service and Autonomous Database, in a partner cloud region. You order through the partner marketplace, Oracle operates the database platform, and you consume it privately from your partner VNet/VPC. Billing runs through the partner marketplace; support is split: partner for cloud network and identity, Oracle for the database.
Provider specifics
- Azure: provision from the Azure portal/Marketplace; attach a delegated subnet in an Azure VNet; use Azure RBAC for Azure resources and OCI IAM for Oracle resources; federate Microsoft Entra ID to OCI IAM; keep database traffic private.
- AWS: order via AWS Marketplace; connect from a VPC using private addressing; use AWS IAM for AWS resources and OCI IAM for Oracle; federate your IdP; avoid public database endpoints.
- Google Cloud: order via Google Cloud Marketplace; connect privately from a VPC; use Google Cloud IAM for cloud resources and OCI IAM for Oracle; federate workforce identity.
Worked example
An Azure App Service app needs Autonomous Database. The architect creates a VNet with a delegated subnet large enough for Oracle, adds an NSG rule allowing 1521 only from the app subnet, configures private DNS, and confirms no public IP. Entra ID groups map to OCI IAM groups with least privilege. The app connects privately; Azure Monitor and OCI Observability cover their respective layers.
Traps
Assuming you patch the Exadata OS; using public IPs; undersizing the delegated subnet; expecting all OCI services in the partner cloud; mixing marketplace billing with direct OCI billing; using partner IAM alone to control Oracle database privileges; forgetting cross-region latency and egress.