Oracle Interconnect for AWS and GCP is the catch-all label for the cross-cloud connectivity options enterprise customers use to connect OCI-resident Oracle Database deployments to AWS-resident and Google Cloud-resident application tiers. The architecture is less standardised than the Oracle Interconnect for Azure model — Oracle and Google Cloud operate a managed peering at specific region pairs, Oracle and AWS rely on customer-established Direct Connect cross-connects at shared metro facilities. The economic profile and the licensing rules track closely to the Azure model; the operational and contractual mechanics are different on each.
This piece works the AWS and GCP cross-cloud connectivity options the way an Oracle insider sizing a multi-cloud commercial proposal would work them: connectivity architectures first, pricing model second, licensing rules third, and the use case framework last. For the Azure equivalent see Oracle Interconnect for Azure. For the broader Oracle multi-cloud BYOL framework see multi-cloud Oracle BYOL rules.
Oracle and Google Cloud — the managed Interconnect
The Oracle-Google cross-cloud peering
Oracle and Google Cloud operate a managed cross-cloud Interconnect at specific OCI-to-Google Cloud region pairs. The peering is established through Oracle FastConnect on the OCI side and Google Cloud Partner Interconnect or Dedicated Interconnect on the Google Cloud side, with both providers operating dedicated edge connectivity inside the same physical metro carrier-hotel facility. Traffic between an OCI virtual cloud network and a Google Cloud VPC paired through the Interconnect routes over the dedicated peering — never traversing the public internet.
The supported region pairs
The Oracle-Google managed Interconnect supports specific OCI-to-Google Cloud region pairs. The pairs include OCI Ashburn ↔ Google Cloud us-east4, OCI London ↔ Google Cloud europe-west2, OCI Frankfurt ↔ Google Cloud europe-west3, OCI Tokyo ↔ Google Cloud asia-northeast1, OCI Sydney ↔ Google Cloud australia-southeast1, and several additional regional pairs. The pair list expands over time as both providers extend the cross-cloud peering infrastructure. The customer's deployment topology must align to one of the supported pairs — pairs outside the supported list require customer-supplied private connectivity through a carrier exchange or public internet routing.
The Database@Google Cloud overlay
The Oracle Database@Google Cloud architecture (Exadata physically deployed inside Google Cloud regions) coexists with the managed Interconnect. The Interconnect serves customers who want to keep their Oracle Database in OCI while their application tier migrates to Google Cloud; Database@Google Cloud serves customers who want the database tier deployed natively inside Google Cloud alongside the application tier. The two architectures coexist in the Oracle commercial portfolio.
Oracle and AWS — the customer-established connectivity
The architecture pattern
Oracle and AWS do not operate the same managed cross-cloud peering structure that Oracle has with Microsoft Azure and Google Cloud. Customers connecting OCI-resident Oracle Database deployments to AWS-resident application tiers typically establish private connectivity through three patterns: (1) OCI FastConnect to a colocation facility that also hosts AWS Direct Connect, with the BGP peering established by the customer's network team; (2) a third-party network provider (Equinix, Megaport, PacketFabric) providing the cross-cloud connectivity layer through their network-as-a-service offering; or (3) the customer's MPLS or SD-WAN backbone routing OCI-to-AWS traffic through the customer's existing wide-area network.
The Database@AWS overlay
The Oracle Database@AWS architecture (Exadata physically deployed inside AWS regions) bypasses the cross-cloud connectivity question for Database@AWS workloads. The database tier and the application tier are inside the same AWS region; the intra-region private endpoint provides the connectivity. Customers running a hybrid model with some Oracle Database workloads in OCI and others in AWS use the customer-established cross-cloud connectivity for the OCI-to-AWS application paths. For the Database@AWS architecture see Oracle Database@AWS guide.
The carrier-hotel approach
The most common AWS-OCI cross-cloud architecture uses a shared metro carrier-hotel facility (Equinix DC2 in Ashburn, Equinix LD5 in Slough, Interxion FRA15 in Frankfurt, Equinix SY3 in Sydney, and similar major colocation hubs) where both OCI FastConnect and AWS Direct Connect are present. The customer provisions FastConnect to an OCI on-ramp, Direct Connect to an AWS on-ramp, and a physical cross-connect between the two on the carrier-hotel meet-me-room. The combined connectivity is functionally equivalent to a managed Interconnect but operationally managed by the customer's network team.
The absence of an Oracle-AWS managed Interconnect is frequently positioned by Oracle account teams as a justification for choosing Database@AWS over a cross-cloud architecture. The reality is that customer-established carrier-hotel connectivity to AWS is well-understood, operationally stable, and economically competitive with a managed Interconnect. The buyer-side defence is to model both options before accepting the Oracle account team framing — the cross-cloud architecture is frequently the right answer when the customer's database tier is already in OCI and the application migration is to AWS.
The pricing model — connectivity costs across AWS and GCP
OCI-to-AWS connectivity pricing
OCI-to-Google Cloud connectivity pricing
The rates above are indicative published list at the time of writing. The customer's specific commercial position on FastConnect, Direct Connect, and Partner Interconnect is frequently negotiated as part of the broader cloud commercial commitments — the published rates are the input to the negotiation, not the final position.
The licensing rules — Oracle Database on AWS and GCP under cross-cloud Interconnect
Standard Oracle Cloud Computing Policy applies on both clouds
Customer-deployed Oracle Database on AWS EC2 or Google Cloud Compute Engine under cross-cloud connectivity to OCI is treated as Authorized Cloud Environment deployment under the standard Oracle Cloud Computing Policy. AWS vCPUs map at 2 vCPUs per Processor for Enterprise Edition; Google Cloud vCPUs map similarly. The customer must supply on-premise Processor or NUP licences from their inventory to cover the AWS or GCP-side vCPU count. The Interconnect itself does not change the licensing requirement — it provides the network connectivity, not licensing relief.
The BYOL inventory requirement
Customer-deployed Oracle Database on AWS or Google Cloud under cross-cloud Interconnect requires the customer to inventory the BYOL-eligible Processor licences from their on-premise environment, confirm the licences are on active SULS, allocate the licences to the AWS or GCP-side workload, and document the allocation in a defensible audit position. The compliance gap that most frequently triggers a back-licence claim is BYOL allocation that exceeds the customer's actual licence inventory — common when departmental teams spin up AWS or GCP Oracle workloads without engaging the central commercial governance function.
The Oracle option licence position
The Oracle Database options activated on the AWS or GCP-side workload (Real Application Clusters, Partitioning, Advanced Compression, Advanced Security, Active Data Guard, Database Vault) require matching option licences from the customer's on-premise inventory. The most frequent option-licence compliance gap on AWS and GCP-side workloads is Advanced Security TDE — frequently enabled by default in cloud-best-practice security configurations without the customer verifying the option licence coverage. The buyer-side defence is an explicit option-activation policy that requires commercial sign-off before any non-bundled option is enabled.
The audit exposure profile
Cross-cloud audit scope
LMS audit scope on cross-cloud Oracle deployments extends to the AWS or Google Cloud-side compute running customer-deployed Oracle Database, under the standard Oracle Cloud Computing Policy. The audit population frequently includes both the OCI-resident deployment and the AWS or GCP-resident deployment as one unified audit scope, particularly when the architecture establishes a tightly-coupled cross-cloud relationship through the Interconnect. The compliance gap to defend is the AWS or GCP-side workload that was treated as outside Oracle audit scope by the customer but is treated as in scope by LMS.
The cloud subscription discovery problem
AWS and Google Cloud-side Oracle Database deployments are not metered by Oracle — the customer is responsible for self-reporting the vCPU count and the option activation. LMS audit teams routinely use the customer's AWS and Google Cloud subscription billing records, instance metadata, and AMI/image inventory to identify Oracle workloads outside the Oracle commercial governance view. The discovery typically surfaces 10 – 30% more Oracle compute than the customer's commercial team was tracking. For the broader hyperscaler audit framework see audit risk in Oracle Database@Hyperscaler.
The defence position
The buyer-side defence on cross-cloud Oracle deployments is to maintain a continuous inventory of every AWS and Google Cloud-side Oracle workload, the supporting Processor and option licence allocation, the SULS status of the supporting licences, and the cross-cloud audit scope mapping. The inventory should be reviewed quarterly, updated against any cloud subscription changes, and held ready for LMS audit notice — not constructed reactively when the audit notice arrives.
Deploying Oracle Database across AWS, GCP and OCI — request a confidential cross-cloud licensing review.
We deliver the forensic cross-cloud architecture review, the AWS and GCP-side Oracle licence allocation analysis, the audit scope mapping, the BYOL inventory verification, and the buyer-side commercial provisions to cap exposure. Independent of Oracle and hyperscaler commercial motions.
Engage Oracle cloud advisory →The buyer-side use case framework
Use case 1 — OCI Database with AWS application tier (cross-cloud Interconnect)
Customer has an existing OCI-resident Oracle Database deployment on Exadata Cloud Service. The application tier migrates to AWS as part of a broader cloud strategy. The buyer-side recommendation is customer-established cross-cloud connectivity through a shared metro carrier-hotel facility. Combined connectivity cost at 10 Gbps is $3k – $4.5k per month; the existing OCI Universal Credits commitment is preserved; the AWS-side application tier connects at low-millisecond latency to the OCI database tier.
Use case 2 — OCI Database with Google Cloud application tier (managed Interconnect)
Customer has an existing OCI-resident Oracle Database deployment. The application tier migrates to Google Cloud, frequently as part of a Google Cloud-native analytics or AI platform strategy. The buyer-side recommendation is the Oracle-Google managed Interconnect at a supported region pair. Combined connectivity cost at 10 Gbps is $2.7k – $3.7k per month through the managed peering; the architecture is operationally simpler than the AWS carrier-hotel pattern; the existing OCI Universal Credits commitment is preserved.
Use case 3 — Multi-hyperscaler deployment with mixed Oracle workloads
Customer has Oracle Database workloads across OCI, AWS, and Google Cloud (and/or Azure). The architecture combines Oracle Database@AWS for AWS-native workloads, Oracle Database@Google Cloud for Google-native workloads, OCI ExaCS for the workloads that remain in OCI, and cross-cloud connectivity for the hybrid traffic patterns. The buyer-side commercial model aggregates all Oracle consumption against a single Universal Credits commitment with BYOL inventory carrying forward where appropriate.
"Oracle's cross-cloud connectivity story has lagged the cloud-native database story, but the operational reality is well-understood. Customers connecting OCI Oracle Database to AWS and Google Cloud application tiers have done it for years through Direct Connect and Partner Interconnect at shared carrier-hotel facilities. The buyer-side defence is to model the connectivity layer as a commercial input, not as an architectural barrier — the cross-cloud Oracle deployment is a defensible architecture when the strategic intent justifies it."
An anonymised case study — global retailer, cross-cloud Oracle architecture
A global apparel retailer with $720m of Oracle Database workloads operated a long-standing OCI deployment of Oracle Retail Merchandising System on Exadata Cloud Service in OCI Ashburn. The company's broader analytics platform migrated to Google Cloud in 2024 to consume Google BigQuery and Vertex AI, and the new analytics workflows needed read access to the OCI-resident merchandising database.
The buyer-side architecture review compared three options. Option A was a full migration of the merchandising database to Oracle Database@Google Cloud in us-east4. Option B was a managed Oracle-Google cross-cloud Interconnect at the OCI Ashburn ↔ Google Cloud us-east4 region pair, keeping the database tier in OCI. Option C was a Google Cloud BigQuery federated query architecture pulling the merchandising data on-demand from the OCI Exadata deployment.
The buyer-side recommendation was Option B. The managed Interconnect provisioning cost was $42k annually (10 Gbps combined FastConnect and Dedicated Interconnect at the Ashburn ↔ us-east4 pair), the architecture preserved the existing OCI commercial commitment ($18m remaining on the Universal Credits commitment), and the migration timeline was four weeks rather than the eight-month timeline for Option A. The Google Cloud analytics workflows connected at single-digit-millisecond latency to the OCI database tier, the BigQuery federated query patterns continued to work over the dedicated peering, and the cu