Running Oracle Database on Amazon RDS Custom for Oracle? AWS has announced that support for Amazon RDS Custom for Oracle will end on March 31, 2027. After that date, customers will no longer be able to access RDS Custom for Oracle resources, including database instances, snapshots, and custom engine versions. The longer you wait, the fewer options you’ll have.
Biju Thomas, Microsoft MVP and Oracle ACE Director
AWS’s recent end-of-service notification for Amazon RDS Custom for Oracle is not a conventional product-support milestone that can be addressed by extending maintenance or delaying the next patch cycle. It is a service-retirement deadline.
AWS’s published migration guidance focuses on moving RDS Custom for Oracle workloads to self-managed Oracle Database on Amazon EC2. However, EC2 does not have to be the only architecture evaluated. Depending on workload requirements, regional availability, Oracle licensing, operational-control requirements, and availability objectives, Oracle AI Database@AWS may also be a viable modernization target.
For customers, the key question is therefore not simply, “How do we copy the database?” The question should be: Which target gives us the right balance of control, availability, performance, licensing efficiency, operational effort, and right TCO?
A well-planned transition can create opportunities to:
- Right-size and consolidate Oracle workloads
- Reassess processor and Named User Plus licensing
- Improve monitoring and lifecycle automation
- Modernize backup, recovery, and high-availability design
- Reduce operational effort where managed database services are suitable
Those outcomes are not automatic. They require workload analysis, license validation, target-architecture modeling, and a migration plan aligned with business downtime and fallback requirements.
What Is RDS Custom for Oracle, and Why Is It Going Away?
RDS Custom occupied a deliberate middle ground. It provided more automation than a self-managed Oracle database on EC2, while preserving the operating system and database access required by legacy, packaged, and highly customized applications. That middle ground is now being retired, requiring customers to choose between greater control on EC2 and newer Oracle-managed database options available within AWS.
AWS’s published end-of-support guidance focuses on migrating RDS Custom for Oracle workloads to self-managed Oracle Database on Amazon EC2. However, customers should not assume that EC2 is the only destination worth evaluating. Depending on workload, availability, control, licensing, and regional requirements, Oracle Database@AWS may also deserve consideration as part of a broader target-platform assessment.
The migration window is now open. Until March 31, 2027, you can continue using RDS Custom for Oracle with existing features and support while you plan and execute your migration. But after that window closes, access ends.
Why This Is Actually Good News for Oracle Customers
The conversation in the market tends to focus on the disruption of a forced migration, but I’d like to reframe that conversation.
RDS Custom for Oracle was a constrained environment. Moving to Oracle Database@AWS opens up capabilities that most RDS Custom customers have been locked out of.
Oracle Database@AWS availability, supported service types, database versions, and regional coverage should be validated before selecting it as a target. For workloads outside supported regions, or those requiring unrestricted operating system access, self-managed Oracle on EC2 may remain the more practical destination.
License optimization.
Oracle Database@AWS supports Oracle Bring Your Own License (BYOL), and its architecture may allow you to consolidate database workloads in ways that reduce the total CPU count you’re licensing. A properly assessed target architecture may reduce the number of processors that require licensing, improve workload performance, or lower operational effort. The result depends on current utilization, Oracle entitlements, database options, workload characteristics, and the selected target service. In selected client assessments, Data Intensity has identified potential annual savings in the six-figure range. Actual results vary by entitlement, utilization, architecture, and contractual position.
Autonomous capabilities.
Depending on your database characteristics, you may be eligible to migrate from a traditional database architecture to Oracle Autonomous Database Serverless on AWS. Autonomous AI Database automates many routine database administration activities, including patching, tuning, backups, and scaling. Customers still retain responsibility for application compatibility, data design, access governance, workload validation, and business-level performance requirements. For the right workload, this is a significant operational cost reduction.
Your applications don’t move.
A common concern we hear: “This sounds like a big project.” For the database migration itself, it doesn’t have to be. The application tier stays exactly where it is. The database moves. Connection strings update. Teams must validate connectivity, latency, drivers, certificates, connection management, integrations, and failover behavior. A well-designed migration minimizes application change.
The Migration Path: What It Actually Looks Like
AWS prescriptive guidance offers two primary physical migration paths from RDS Custom to the target environment: RMAN Active Duplication and Oracle Data Guard.
RMAN Active Duplication is often the simpler option when the business can accommodate a planned final cutover window and does not require continuous synchronization. The source database stays online and accessible to applications throughout the duplication process. Only a brief cutover window is needed to redirect application connections to the new target. It’s lower complexity, well-understood, and proven at scale.
Oracle Data Guard is appropriate for mission-critical production workloads where even minutes of cutover downtime is unacceptable. Data Guard maintains a synchronized standby by continuously shipping and applying redo logs from the primary, and when you’re ready to complete the migration, a switchover promotes the standby to primary.
Both paths support non-CDB (traditional single-instance) and multitenant (CDB with PDBs) Oracle architectures. Both keep the source database online during migration. Both are well within the capability of an experienced Oracle DBA team – which is exactly what Data Intensity brings to every engagement.
What Data Intensity Will Do for You: A TCOT Engagement
Data Intensity has developed a structured engagement model for this exact situation. We call it a Total Cost of Ownership Transformation Assessment (TCOT), which covers:
- License savings identification. We analyze your current Oracle license position on RDS Custom and model what your footprint looks like under alternative architectures. This includes processor licensing, Named User Plus positions, and Options/Packs you may or may not be using. Many customers discover meaningful reduction opportunities they weren’t previously aware of.
- Five-year TCO. Infrastructure cost alone doesn’t tell the complete story. We model total cost over five years: licensing, compute, storage, network, backup, support, and operational labor. We compare your current RDS Custom baseline against Oracle Database@AWS options and self-managed EC2 architectures so you can make a genuinely informed decision, not just a guess.
- Autonomous Database suitability assessment. Not every database is a candidate for Oracle Autonomous Database Serverless, but many are. We evaluate your database characteristics: workload type, peak concurrency, schema complexity, and PL/SQL usage against the Autonomous feature set. Our team then flags where serverless would be a legitimate, cost-effective option.
- Migration planning. From the TCOT analysis, we produce a migration plan with an achievable timeline, defined cutover approach, and clear success criteria. Your applications stay where they are. Your database moves cleanly. We handle the Oracle-specific complexity, so your team doesn’t have to build it from scratch.
Who Should Be Reading This Right Now
If any of the following describes you, the clock is already ticking:
- You are running Oracle Database 19c Enterprise Edition on RDS Custom for Oracle in any AWS region
- You have a production database on RDS Custom with strict downtime requirements
- You’ve been deferring Oracle license reviews because the current setup “works”
- Your DBA team is spending time on RDS Custom patching and automation workarounds that a better-managed platform would eliminate
- You have Oracle applications on AWS and you’re not certain what your license exposure looks like
After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. That’s not a warning you can defer indefinitely. Complex database migrations, especially those involving license restructuring, architecture changes, and enterprise applications, need runway. Starting now gives you options. The longer you wait, the fewer options you’ll have later.
The Right Move, Made at the Right Time
Data Intensity has been delivering Oracle managed services and architecture work on AWS for years. We hold Oracle SMSP/MSP designation on OCI and deep Oracle Database expertise across EBS, RAC, Data Guard, and cloud-native Oracle architectures. We’ve completed hundreds of TCOT analyses, license negotiations, and complex database migrations for enterprise Oracle customers. We know Oracle, and this is what we do.
Reach out to our team to schedule your complimentary TCOT engagement. We’ll tell you what we find, not what you want to hear. That’s how you make the right call before March 2027.
Common Questions We’re Helping Our Clients Answer
- What should I replace Amazon RDS Custom for Oracle with?
- How do I migrate from RDS Custom for Oracle to Oracle Database@AWS?
- How much downtime should I expect during migration?
- Can moving off RDS Custom reduce Oracle licensing costs?
- Is Oracle Autonomous Database a good fit for my workload?
- Should I choose Oracle Database@AWS or Oracle on Amazon EC2?
- What is the fastest migration path from RDS Custom for Oracle?
If those are questions you need answers to, or if your organization is running Oracle on RDS Custom for Oracle, our experts would be happy to have a straightforward conversation with you about your options, what they realistically cost, and what a migration would look like for your specific environment. Let’s talk.
Frequently Asked Questions
When does Amazon RDS Custom for Oracle reach end of service?
Amazon RDS Custom for Oracle is scheduled to be retired on March 31, 2027.
What happens if I do not migrate before March 31, 2027?
After the retirement date, access to Amazon RDS Custom for Oracle resources and management capabilities will no longer be available. Customers should complete migration planning and execution before the end-of-service deadline.
What are the recommended alternatives to RDS Custom for Oracle?
AWS recommends migrating Oracle workloads to either Oracle Database@AWS or self-managed Oracle databases running on Amazon EC2, depending on business and operational requirements.
Can I migrate from RDS Custom for Oracle without significant downtime?
Yes. Most organizations can use RMAN Active Duplication or Oracle Data Guard to complete migration with limited downtime during cutover.
Will my applications need to move?
In most cases, no. The database platform changes, but the application tier typically remains where it is today.
Is Oracle Autonomous Database an option?
Some workloads may qualify for Oracle Autonomous Database Serverless on AWS, depending on workload characteristics and application dependencies.
Can moving off RDS Custom reduce Oracle licensing costs?
Potentially. Many organizations use the migration effort as an opportunity to review processor licensing, Named User Plus licensing, database consolidation opportunities, and Oracle options currently in use. Data Intensity’s Total Cost of Ownership Transformation Assessment (TCOT) is a great way to get the data you need from Oracle-certified experts.
What is included in a Data Intensity TCOT assessment?
Our Total Cost of Ownership Transformation Assessment (TCOT) evaluates licensing, infrastructure costs, operational expenses, migration approaches, and potential optimization opportunities to help organizations select the cloud that best meets their needs.
