I’ve sat through two Exadata Cloud@Customer rollouts now, both from the customer side of the table, and both times the project team had the same reaction: this isn’t “cloud” the way people picture it. Nobody logs into a portal and clicks a button and a database appears. Oracle ships you a rack. An actual, physical rack. Somebody rolls it into your data center, bolts it to the floor, cables it up — and only after all that does the cloud part start to mean anything.
Get that straight early and the rest of this makes a lot more sense.
Why anyone bothers with this instead of plain OCI
Most of my client base over the years has been banking, telecom, and a fair bit of government work — Sri Lanka, but also engagements in Bangladesh, Kenya, Mozambique, Mongolia. In every one of those, the same tension shows up: compliance wants Oracle’s automation and patching and managed-service polish, but nobody’s getting sign-off to move customer data outside the building. Exadata Cloud@Customer (C@C, once you’ve said it a few times) is Oracle’s answer. They own and patch the hardware, they run the infrastructure lifecycle, but the box itself sits on your floor, behind your own badge readers.
Once it’s running, honestly, it feels close to identical to Exadata Database Service on OCI’s dedicated infrastructure. What’s different is where the metal physically lives, and everything that has to happen networking-wise to make that work.
That networking piece eats more of my time than the actual database provisioning does, every single time.
The five networks, and where people mix them up
I’d guess this is where I see the most confusion in design workshops — engineers assume it maps cleanly onto an OCI VCN, and it just doesn’t.
Start with the Client Network. Application connections, SQL*Net, DBA logins, whatever a normal app or user touches day to day. Here’s the bit that throws OCI-native folks: no VPN, no FastConnect circuit, no Internet Gateway sitting in the middle. It plugs straight into your corporate LAN. I’ve had two separate architects ask me, mid-workshop, “okay so where’s the FastConnect for this,” and there isn’t one — the rack’s already inside your network, so it doesn’t need one.
Then the Backup Network, which carries RMAN traffic and talks to Object Storage. Small detail that trips people up later: it lives inside the VM Cluster Network rather than sitting in an OCI VCN like you’d expect.
The VM Cluster Network itself replaces the whole idea of client subnets living inside a VCN. Instead you build a network that bundles your client and backup subnets together, and it maps one-to-one to a VM Cluster. Nothing stopping you from running several side by side if you’ve got workloads you want kept apart.
Control Plane Network is the quiet one nobody thinks about until it breaks. It’s Oracle’s secure VPN tunnel back to their console — patching, monitoring, REST API calls, all riding over it, without Oracle ever getting anywhere near your actual data. You need TCP 443 outbound, two Control Plane servers, and an HTTPS proxy if your org runs one.
Administration Network stays fully internal — database servers, storage servers, switches, PDUs, all talking to each other on it. It never touches your corporate network directly, though it reaches out to DNS and NTP through the Control Plane servers. This is the one I harp on in every planning call: do not let this IP range overlap anything on your corporate side. Had a deployment once where someone reused a /24 that was already live elsewhere in the org, and it cost the better part of a week to untangle.
And RoCE — RDMA over Converged Ethernet, which is what modern racks use instead of InfiniBand for the RAC interconnect, Smart Scan traffic, storage communication, all of it. Non-routable, dual switches for redundancy, and same rule as Administration: no overlap with corporate LAN or with the Admin network either.
How provisioning actually plays out
Once the network design is locked — and I mean actually locked, because revisiting IP ranges mid-install is miserable — the sequence goes something like this.
You open the OCI Console, create an Exadata Cloud@Customer Infrastructure resource, and feed in the networking parameters you’ve already worked out. That produces an Infrastructure Configuration File: IP addresses, DNS entries, NTP servers, hostnames, the works. That file goes to Oracle.
From there it’s on Oracle. Engineers arrive, deliver the rack, cable everything, connect power, run validation. Quietly, behind the scenes, they’re also standing up the Control Plane servers, the Administration Network, RoCE, and the VPN tunnel back to OCI.
Once that’s done, you get an Activation File. Upload it through the Console, and that’s genuinely the moment the infrastructure comes alive — able to host Exadata Database Service VM Clusters and Autonomous VM Clusters from here on.
Only after activation does anything database-shaped actually get built: the VM Cluster Network, client and backup subnets, DNS, NTP, CPU allocation, storage, and finally the VM Cluster. Oracle’s automation handles Grid Infrastructure, RAC, Clusterware, and ASM from there without anyone hand-editing config files.
What I make sure is ready before Oracle shows up
Client and backup network ranges defined, Control Plane IPs and gateway and netmask worked out, one to three DNS servers, one to three NTP servers, every hostname assigned and written down somewhere, and proxy details if the org uses one for outbound HTTPS. I’ve had this list save an on-site visit from turning into a wasted day more than once.
On DNS specifically — Oracle needs registration for the database servers, the SCAN listeners, and both client and backup interfaces. Miss this and you’ll spend the week the cluster goes live chasing listener resolution problems instead of doing anything useful.
NTP matters more than people expect, too. Database servers, storage servers, switches, Control Plane servers — all of it needs to stay synced, and Oracle recommends up to three NTP servers for redundancy. Cheap insurance against clock drift causing weird RAC behavior down the line.
What’s actually sitting inside the rack
Two Control Plane servers running the VPN back to OCI. Database servers doing RAC, ASM, your actual databases. Storage servers running Exadata’s storage software, Smart Scan, storage indexes. Ethernet switches carrying client and Administration traffic. Separate RoCE switches for the interconnect and storage traffic. And the PDUs, which Oracle looks after entirely on its own — you never touch those.
Things I’d tell someone doing this for the first time
Treat your IP range planning like you won’t get a second shot at it, because you mostly won’t. Keep Administration and RoCE well clear of your corporate address space — don’t get clever with subnetting to save addresses, it isn’t worth it. Get every hostname into corporate DNS before Oracle arrives, not the week of. Run more than one DNS and NTP server; this really isn’t where you cut corners. Confirm TCP 443 outbound is actually open from the Control Plane servers before install day, not after someone’s already on site waiting. Test gateway reachability yourself instead of trusting that the network team already did. And write every network assignment down somewhere that’ll still exist in six months, because when you’re troubleshooting a connectivity issue at two in the morning, that document is the only thing between you and a genuinely bad night.
Versus plain OCI, in short
In public OCI your client network sits inside a VCN and usually needs FastConnect. With C@C the VM Cluster Network takes that role instead, and FastConnect drops out of the picture entirely because you’re already on-prem. Data residency stays with you rather than Oracle. Oracle still manages the infrastructure in both cases — that part’s unchanged. The one real shift is that the Control Plane now reaches OCI over a secure VPN rather than sitting natively inside it.
Where that leaves you
Cloud@Customer gets you Oracle’s managed database experience without asking you to move sensitive workloads off your own floor, but the price is a much heavier planning phase up front — five distinct networks, careful IP segmentation, DNS and NTP discipline, all before you’ve provisioned a single VM Cluster. Get that part right and the rest, from activation file through to a running RAC cluster, tends to go about as smoothly as anything in the Oracle Cloud world ever does.
