Data residency, latency to factory floors and trading systems, and regulators who want infrastructure inside national borders have kept a stubborn share of enterprise workloads out of public cloud regions. Oracle and AWS both answer with hardware delivered to your data center, operated remotely by the vendor, and billed like cloud. That is where the similarity ends. Exadata Cloud@Customer is a database machine: Oracle's engineered system, running Exadata Database Service and Autonomous Database, managed by Oracle, inside your walls. AWS Outposts is a general purpose slice of an AWS region: EC2, EBS, ECS, EKS, and a defined subset of services on AWS hardware, tethered to a parent region. Comparing them as if they were interchangeable misses the point of both. This article is part of our series under the independent comparison of OCI, AWS, Azure, and Google Cloud.
What each box actually is
Exadata Cloud@Customer places a full Exadata system, database servers, storage servers, RDMA fabric, in your facility. Oracle owns, monitors, patches, and maintains the infrastructure; you consume Exadata Database Service and, on current generations, Autonomous Database, through the same OCI control plane used in public regions. The control plane connection runs back to OCI, but the data plane, your databases and their data, stays entirely on site. It is sold by capacity with a committed term, with OCPUs billed on consumption above the base, and BYOL applies just as it does in the public cloud.
Outposts delivers AWS designed racks or smaller form factors with EC2 instances, EBS volumes, S3 on Outposts, and a service subset that has grown but remains a fraction of the regional catalogue. The rack requires a stable link to its parent AWS region: the control plane lives there, and many services on the rack depend on regional endpoints for management and, in some configurations, data services. Pricing is a capacity commitment over a three year term covering the hardware, with usage billed on top in the familiar AWS meters.
Side by side
| Dimension | Exadata Cloud@Customer | AWS Outposts |
|---|---|---|
| Purpose | Oracle Database platform on premises | General AWS compute and storage on premises |
| Hardware | Exadata engineered system, smart storage, RDMA | Standard AWS rack hardware, Nitro based |
| Services | Exadata Database Service, Autonomous Database | EC2, EBS, S3 on Outposts, ECS, EKS, RDS subset |
| Oracle Database support | Full: RAC, all options, Data Guard, Autonomous | RDS for Oracle not supported on Outposts; self managed EC2 only |
| Region dependency | Control plane to OCI, data plane fully local | Anchored to a parent region, link outages degrade management |
| Commercial model | Committed capacity term, consumption above base, BYOL | Three year capacity commitment plus usage |
| Operations | Oracle manages infrastructure, customer manages databases or Autonomous does | AWS manages hardware, customer manages workloads |
| Best fit | Regulated Oracle estates, database consolidation on site | Local compute for latency sensitive apps in AWS architectures |
The database question decides it
If the workload that cannot leave the building is Oracle Database, the comparison is short. Outposts does not run RDS for Oracle, so Oracle on Outposts means self managed databases on EC2 instances, without RAC support, without engineered system performance, and with the same licensing mathematics that make Oracle on AWS expensive in the region. Exadata Cloud@Customer runs the full engine with RAC, Data Guard, every option, and Autonomous automation, on hardware built for it. The consolidation effect compounds the gap: one Cloud@Customer system routinely absorbs dozens of databases from aging on premises estates, which is why the per database economics surprise people who only priced the rack. We cover the regional version of this contrast in OCI vs AWS for Oracle workloads, and the same logic applies with the residency constraint added.
Where Outposts genuinely wins
Being honest in both directions: if the on premises requirement is application compute rather than Oracle data, Outposts is the stronger answer. A manufacturing site that needs containerised applications at single digit millisecond latency to machinery, run with the same EKS tooling as the rest of an AWS estate, is exactly the Outposts use case. The operational consistency argument is real, one set of AMIs, IAM policies, and deployment pipelines across region and site. Cloud@Customer has no ambition to run your general application tier. Estates that need both local Oracle data and local AWS compute do exist, and some run both boxes side by side; the interconnect design between them is ordinary networking, not magic.
Commercial structure and the term commitment
Both products are committed spend, so the procurement conversation is about utilisation risk. Outposts capacity is fixed at order time: you size the rack, commit for three years, and growth beyond the rack means another order. Cloud@Customer commits a base and meters consumption above it, with online scaling inside the installed capacity, and BYOL can cut the database service rate roughly in half for license holders. In both cases the expensive failure is the half empty rack. Sizing from measured workloads rather than vendor proposals is the single highest value hour in the whole process, and it is work we run as a fixed fee project, with the licensing position handled alongside by specialists. The wider hardware economics of dedicated infrastructure, including the regional comparison, are covered in OCI bare metal vs AWS Dedicated Hosts.
Connectivity, operations, and failure modes
Plan for the bad day on both platforms. Cloud@Customer needs its control plane connection to OCI for management operations, but databases continue running and serving locally if the link drops. Outposts tolerates short disconnections, instances keep running, but management, scaling, and some service operations need the parent region, and AWS is explicit that Outposts is not designed for disconnected operation. For genuinely isolated or sovereignty constrained sites, this difference matters more than any benchmark, and it is also where the broader OCI portfolio, Dedicated Region for a full cloud on site and Roving Edge for the extreme cases, gives Oracle more gradations than AWS offers between a rack and a region.
A decision framework
- Name the constraint precisely. Residency of data, latency to local systems, or regulator comfort are different requirements with different cheapest answers. Write the constraint down before shopping for racks.
- Classify the workload. Oracle Database points to Cloud@Customer. General application compute in an AWS shaped estate points to Outposts. Both can be true at one site.
- Count the databases honestly. Consolidation density drives Cloud@Customer economics. An inventory of every database that could move, with sizes and licenses, changes the answer more than any discount.
- Model the disconnected day. If the site must operate with the WAN down, test each vendor's documented behaviour against that requirement, not against the brochure.
- Price the term realistically. Committed capacity wants a three to five year workload forecast. Pad for growth you can evidence, not growth you hope for.
- Bring the licensing position in early. BYOL changes Cloud@Customer rates materially, and Oracle license terms on AWS infrastructure deserve specialist review before any Outposts based Oracle plan is approved.
Where each one wins
Choose Exadata Cloud@Customer when regulated or latency bound Oracle databases anchor the requirement, when consolidation of an on premises Oracle estate is overdue, or when you want Autonomous automation inside your own walls. Choose Outposts when the local need is application compute, containers, and storage operated with AWS tooling, and the data tier either is not Oracle or lives elsewhere. If the estate needs both, design them as two deliberate platforms with clean networking between them. Sizing, landing zone design, and the migration sequence for the Oracle side is the core of our Exadata practice, and the same assessment discipline applies whether the destination is a public region or a rack in your own building.
Bringing it together
Exadata Cloud@Customer and AWS Outposts share a delivery model and almost nothing else. One is the best available way to run Oracle Database on premises with cloud operations; the other is the best available way to extend an AWS architecture into your facility. The mistake we see is organisations choosing on brand familiarity rather than workload fit, then forcing the workload to cope. Classify the workloads, model the disconnected day, count the licenses, and the right rack picks itself.
Free white paper
Go deeper on this topic with The Exadata Cloud Decision Guide, Database Service vs Cloud@Customer vs Autonomous, and how to choose. An independent analyst style report with comparison tables and recommendations, free with a work email. Prefer a monthly summary instead? The OCI Brief delivers one practical OCI briefing a month.
Part of a series
This guide is part of Oracle Database on OCI — our complete pillar guide on the topic.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings.