AWS Discontinues RDS Custom for Oracle: What It Means for Oracle Database Customers

Introduction

Everyone in the industry knows the story: Oracle showed up to the cloud party later than AWS and Azure. That head start is why so many organizations built their Oracle workloads on Amazon RDS for Oracle or on Azure; the hyperscalers got there first, and enterprises followed.

But “late” doesn’t mean “behind.” I’ve come to see a pattern that many architects eventually run into: RDS for Oracle is really a wrapper around Oracle’s own tooling. RMAN, Data Pump, AWR: the engines doing the real work are still Oracle’s. You’re just triggering them through an AWS layer, with AWS’s abstractions standing between you and the tuning and backup controls a seasoned Oracle DBA actually wants direct access to.

That gap is exactly why, when Oracle finally brought its full weight into the cloud market, it didn’t try to out-AWS. It leaned into what only Oracle can do:

Autonomous Database is a genuine differentiator.

• Self-patching

• Self-tuning

• Self-securing

This isn’t a marketing label bolted onto a managed service. It’s built into the platform.

No cloud beats OCI on Oracle licensing. If you’re standardizing on Oracle, the commercial terms are hard for any other cloud to match.

Why Multi-Cloud Became the Default Strategy

At the same time, no single cloud has matured every service an enterprise needs. AWS leads in breadth of managed services; Azure leads in enterprise identity and Microsoft stack integration; OCI leads in Oracle workloads and price-performance for them. That’s precisely why multi-cloud stopped being a buzzword and became a practical architecture: organizations spread workloads across hyperscalers to get high availability and best-of-breed services from each.

The Game-Changer: Oracle Database@AWS and Oracle Database@Azure

This is where Oracle’s recent moves matter. Instead of asking customers to choose between “stay on AWS/Azure” and “get real Oracle performance,” Oracle partnered directly with the hyperscalers to put Exadata infrastructure inside AWS and Azure data centers.

That’s the headline: your applications stay put on AWS or Azure, but the database tier runs on genuine Oracle Exadata, connected over a private, low-latency network, with access to Real Application Clusters (RAC), Exadata performance benefits, Oracle Database 26ai capabilities, and tighter integration with each hyperscaler’s native services for analytics, AI, backups, observability, and provisioning.

For OLTP and OLAP workloads in particular, this is hard to argue with. Exadata’s combination of smart storage offload, RDMA-connected compute, and decades of Oracle-specific optimization is still the benchmark other platforms are measured against, and now it’s available without leaving your AWS or Azure footprint.

Services currently available under this model:

• Oracle Exadata Database Service on Dedicated Infrastructure

• Oracle Autonomous AI Database on Dedicated Exadata Infrastructure

• Oracle Autonomous AI Database Serverless

• Oracle Database Autonomous Recovery Service

(Full details: oracle.com/cloud/aws/services)

Information about available regions: https://docs.oracle.com/en-us/iaas/Content/database-at-aws/oaaws-regions.htm

The Announcement That Should Get Your Attention

Here’s where timing becomes urgent rather than theoretical. AWS has confirmed it is discontinuing Amazon RDS Custom for Oracle, with support ending March 31, 2027. It’s worth being precise about scope here, because it’s a common point of confusion. This deprecation applies specifically to RDS Custom for Oracle, the flavor of RDS built for legacy and custom applications needing OS-level and database-level access, and this change does not impact RDS for Oracle or RDS Custom for SQL Server.

Still, if RDS Custom for Oracle is part of your estate, the clock is real: from March 31, 2026 to March 31, 2027, AWS recommends migrating from RDS Custom for Oracle to running Oracle on EC2, and after March 31, 2027 you will no longer be able to use the RDS Custom for Oracle service at all. AWS’s own migration guidance outlines two supported paths RMAN active duplication and Oracle Data Guard for moving those workloads off before the cutoff.

AWS link: RDS Custom for Oracle end of support – Amazon Relational Database Service

Why This Is an Opening, Not Just a Deadline

For any organization facing this deprecation, the reflex might be “migrate to plain EC2 and self-manage.” That’s a valid path AWS itself recommends, but it’s also the moment to ask a bigger question: why rebuild a self-managed Oracle stack from scratch when Oracle@AWS now lets you get Exadata-class infrastructure, RAC, and Autonomous capabilities without leaving AWS at all?

That’s the real opportunity in this announcement. Instead of a forced migration to a lesser environment, it’s a forced decision point, one where Oracle@AWS (or Oracle@Azure, if that’s your primary cloud) gives you a landing zone that’s arguably better than what RDS Custom offered in the first place:

• You keep your applications, IAM, networking, and operational tooling on AWS or Azure.

• Your database tier runs on real Exadata, not an abstraction layer over Oracle utilities.

• You gain direct access to RMAN, Data Pump and other tools.

• You get Oracle’s licensing economics, which remain hardest to beat on OCI-adjacent offerings.

Which Option Fits Your Workload? A DBA’s Rule of Thumb

Not every Oracle workload needs the same landing zone. Based on what I typically recommend to customers, the right choice usually comes down to workload size and operational priorities:

Large workloads (roughly 20–30 TB and up): Go with Oracle Exadata Database Service. At this scale, the performance ceiling and smart storage offload of Exadata are hard to replace with anything else, and this is exactly the workload class Exadata was engineered for.

Priority is lowering operational overhead: Choose Autonomous Database. Self-patching, self-tuning, and self-securing translate directly into fewer operational hours spent on care and feeding. The best option when the goal is cost reduction through automation rather than raw horsepower.

Smaller databases: Consider migrating to Oracle Database on OCI (DBCS). Your applications can stay on AWS; you just need a network connection between AWS and OCI (via FastConnect or a similar interconnect). This gives you Oracle-grade performance without managing the underlying infrastructure yourself, plus the flexibility to scale OCPUs on demand as the organization needs more compute.

Learn more about dbcs: https://www.oracle.com/database/base-database-service/

Conclusion

Oracle arrived late to cloud, but it’s used that delay to build something the hyperscalers can’t fully replicate on their own: Exadata performance and Autonomous Database intelligence. With RDS Custom for Oracle’s sunset now on the calendar, organizations running Oracle on AWS have a natural, low-disruption on-ramp to that platform via Oracle Database@AWS (and the equivalent on Azure), rather than defaulting to a bare EC2 self-managed rebuild.

If your Oracle workloads are on RDS Custom, the next 18 months are the window to plan this deliberately rather than reactively. The destination worth evaluating isn’t just “off RDS Custom”. It’s “onto the platform built specifically to run Oracle the way Oracle is meant to run.”

For more information, check out our Oracle Database Services, or contact us today, and one of our experts will be in touch.