FR
live

AWS Interconnect connects AWS and Oracle Cloud privately — multicloud goes native

On **July 31, 2026**, **AWS** announced general availability of **AWS Interconnect** for **Oracle Cloud Infrastructure (OCI)**. For the first time, two competing hyperscalers offer native private interconnection without traversing the public internet. A pivotal shift for multicloud architectures.

Two server racks side by side, a single fiber cable connecting them, a lone amber LED at the connection point, dark background

On July 31, 2026, AWS quietly announced the general availability of AWS Interconnect for Oracle Cloud Infrastructure (OCI). The news, buried in the AWS Weekly Roundup, went largely unnoticed in the weekend news cycle. That’s a mistake: this is the first native private interconnection between two competing hyperscalers, and it changes the calculus for enterprises running workloads split across AWS and OCI.

Until now, connecting AWS to OCI meant deploying a virtual appliance (IPSec VPN or SD-WAN), provisioning Direct Connect on one side and FastConnect on the other, then bridging them through a colocation provider. The result worked — at the cost of added latency, operational complexity, and a hand-rolled single point of failure.

AWS Interconnect removes that entire layer.

How AWS Interconnect works

The service is built on a straightforward premise: AWS and OCI have deployed shared physical interconnection points in several regions, and they expose that connectivity through their respective consoles.

On the AWS side: an administrator creates an Interconnect resource in the AWS console, selects the target OCI region, and associates the VPC that needs to communicate with the Oracle cloud.

On the OCI side: the same administrator accepts the interconnection request in the OCI console and attaches it to an existing VCN (Virtual Cloud Network).

Provisioning takes under 15 minutes according to the documentation. No hardware to deploy, no tunnel to maintain, no colocation provider to involve. Traffic flows over a private link, encrypted at the link layer by default, never touching the public internet.

The use case: why AWS + OCI?

The pairing might seem surprising: why would an enterprise want to connect AWS and OCI directly? The answer comes down to two words: Oracle Database.

Oracle Database is the most widely deployed database management system in large enterprises. Decades of critical applications — ERP, CRM, supply chain, core banking — run on Oracle DB. Migrating these applications to the cloud is often blocked by licensing costs and performance constraints.

OCI offers a licensing model optimized for Oracle Database — notably through Oracle Autonomous Database and Exadata Cloud Service — that no other hyperscaler can match. But the application consuming that database may run perfectly well on AWS, where the enterprise has already invested in skills, CI/CD pipelines, and managed services.

AWS Interconnect makes that pattern viable at scale:

  • Oracle database on OCI: optimized licensing, Exadata performance, managed backups.
  • Application on AWS: ECS, EKS, Lambda, RDS for non-Oracle data.
  • Private interconnection: sub-2 ms latency in connected regions, up to 100 Gbps throughput.

This isn’t lift-and-shift. It’s a deliberate hybrid architecture where each workload runs where it performs best and costs least.

Available regions at launch

The GA launch covers four region pairs:

AWS RegionOCI RegionAdvertised latency
us-east-1 (Virginia)us-ashburn-1~1 ms
eu-west-1 (Ireland)eu-frankfurt-1~2 ms
ap-southeast-1 (Singapore)ap-singapore-1~1 ms
ap-northeast-1 (Tokyo)ap-tokyo-1~1 ms

AWS stated that additional region pairs and cloud providers will be added “in the coming months.” The roadmap explicitly mentions Google Cloud as the next interconnection partner.

Implications for multicloud strategy

AWS Interconnect does more than simplify a technical connection. It validates a trend that hyperscalers have long resisted: deliberate multicloud.

Through 2025, the official line from the Big Three (AWS, Azure, GCP) was “migrate everything to us, it’s simpler.” Reality imposed a different pragmatism. According to the Flexera 2026 State of the Cloud report, 89% of enterprises use at least two public clouds. Half of them cite “strategic vendor dependency” as a major concern.

With AWS Interconnect, AWS implicitly acknowledges that the single-cloud battle is over. Rather than lose the Oracle workload to OCI — and potentially the rest of the workload with it — AWS prefers to provide the plumbing that keeps the application on its platform.

It’s a commercially rational decision. It’s also a signal to CIOs: multicloud is no longer an integrator’s workaround; it’s a native hyperscaler feature.

Comparison with existing alternatives

SolutionMax throughputLatencyProvisioningEstimated monthly cost
Inter-cloud IPSec VPN~1.25 Gbps+5-10 msManual (2 consoles)Compute cost
Direct Connect + FastConnect + colocation100 Gbps~2 ms2-4 weeks~USD 2,000/month
AWS Interconnect (new)100 Gbps~2 ms~15 minutes~USD 500/port + traffic

The difference isn’t just cost or latency. It’s provisioning time and the removal of intermediaries. A cloud architect can prototype an AWS + OCI architecture in a single afternoon — no purchase order, no colocation contract, no appliance to configure.

Verdict

AWS Interconnect is the missing piece for pragmatic multicloud. If your enterprise runs Oracle databases and applications on AWS, you no longer have an excuse for maintaining a hand-rolled VPN tunnel between them. Provisioning is trivial, latency is same-datacenter territory, and cost is predictable.

The real test will come in fall 2026 when Google Cloud joins as an interconnection partner. If the promise of a private mesh across the three hyperscalers materializes, the vendor lock-in argument will lose its last technical foundation.

In the meantime, enable AWS Interconnect if the AWS+OCI pairing describes your architecture. Fifteen minutes is all it takes.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

Three Pass-ta-key Attacks Bypass Google Passkeys — Chrome's Cloud Authenticator Validates Compromised Machines Without Checking the TPM

On August 3, 2026, Unit 42 (Palo Alto Networks) published three attacks dubbed Pass-ta-key that allow malware on a compromised Windows machine to hijack passkeys synced through Google Password Manager. The most severe, Golden Pass-ta-key, extracts the master encryption key from Chrome's memory and compromises all current and future passkeys on the victim's Google account.

← Back to the feed

Type at least two characters.

navigate open esc dismiss