Beyond Self-Managed EC2: NDB on NC2 for RDS Custom for Oracle Databases

AWS has announced that Amazon RDS Custom for Oracle will reach end of support on March 31, 2027. Customers can continue using the service as-is until then; after that date, RDS Custom for Oracle database instances, snapshots, and custom engine versions will no longer be accessible. AWS's own prescriptive migration guidance recommends transitioning affected workloads to self-managed Amazon EC2.

For customers weighing that transition, the Nutanix Database Service (NDB) solution running on Nutanix Cloud Clusters (NC2) in AWS is a solid alternative worth putting on the table. It preserves the OS-level access that made RDS Custom for Oracle valuable in the first place, while keeping the database lifecycle automation that a move to bare self-managed EC2 would otherwise hand back to your team — all within your existing AWS account and VPC.

Amazon RDS Custom for Oracle existed for a specific reason. As AWS explained when launching the service, certain legacy and packaged applications — Oracle E-Business Suite, PeopleSoft, and similar industry software common in healthcare, telecom, retail, banking, and hospitality — need OS-level access and database customization that standard RDS doesn't provide. RDS Custom filled that gap with a shared responsibility model: customers get OS access, and AWS still automates a meaningful share of day-to-day database operations.

What Changes in the Shared Responsibility Model

AWS's own comparison, from that same launch post, is a useful way to see what the EC2 recommendation implies operationally:

(Excerpted from the comparison table in AWS News Blog, "Amazon RDS Custom for Oracle – New Control Capabilities in Database Environment"; the original table also includes an Amazon RDS column.)

The pattern worth noticing: everything that was Shared under RDS Custom for Oracle — scaling/HA, backups, DB software maintenance, OS maintenance — presumably will become fully Customer-owned on EC2. That's the practical effect of a straight Amazon EC2 instance migration: customers will keep the OS-level access they had, but the automation AWS previously handled on the "Shared" side will go away, and self-managed database administration — the exact overhead RDS was originally built to remove — comes back.

NDB on NC2: Keeping the Automation, Keeping the Access

NDB on NC2 targets that same gap differently:

Customers retain OS-level access — the same category AWS labels "Shared" for RDS Custom — but NDB's control plane automates the actual work behind that "Shared" label. Concretely, for Oracle workloads that means:

Provisioning — automated for both single-instance (ASM or file system) and RAC deployments.

Architecture support — CDB and non-CDB, with PDB lifecycle operations managed through NDB's CLI.

High availability & DR — RAC, and physical standby configurations (single, multiple, or cascaded), with one-click switchover and failover.

Backup & recovery — automated through NDB's Time Machine, covering scheduled backups and point-in-time recovery.

Cloning — snapshot-based and point-in-time cloning, including RAC-to-RAC.

Patching — Release Update patching for both single-instance and RAC (rolling), with maintenance-window bulk patching across a fleet.

Major version upgrades — automated upgrade workflows (currently 11g to 19c).

Security — Transparent Data Encryption support.

Storage scaling — one-click.

The operational lift doesn't shift entirely onto your team the way it would with a straight Amazon EC2 instance migration. NC2 runs on AWS bare-metal instances inside your own AWS account and VPC, so this stays within your existing AWS footprint.

Staying Connected to Your AWS Ecosystem

Many customers running Oracle databases on RDS Custom have applications tightly integrated with other AWS-native services — running on EC2, containers, or other managed offerings, using AWS networking, IAM, and service endpoints. Migrating the database doesn't have to mean re-architecting how the application tier talks to it. Because NC2 runs inside the customer's own AWS account and VPC, NDB on NC2 sits alongside these application workloads with the same network proximity the applications had with RDS Custom for Oracle.

In practice, this means the application layer can continue running on EC2 or other AWS services exactly as it does today, connecting to the Oracle database on NDB the same way it always has — while the database itself gains OS-level access and full lifecycle automation. Customers can migrate the database layer off RDS Custom for Oracle while helping minimize disruption to supported applications layered on top of it.

NDB on NC2 runs inside your existing AWS VPC — application connectivity, endpoints, and IP addresses stay exactly as they are today. Only the database management layer is new.

What a Migration Involves

AWS’s own migration guidance for RDS Custom for Oracle lays out two options based on downtime tolerance and complexity — and the same choice applies when the target is NDB on NC2 instead of EC2:

• Physical duplication (lower complexity) — the database is copied to the NC2 hosted target while the source stays online, with only a brief cutover window at the end to redirect applications. This is a lower-complexity path that may be appropriate for most workloads, especially dev/test databases or ones that can tolerate a short planned downtime.
• Replication-based migration (designed to minimize downtime) — a standby database on NC2 is kept continuously synchronized with the RDS Custom for Oracle source via redo log shipping. When ready, a switchover promotes the NC2 hosted standby to primary in seconds to minutes. This path takes more setup but is the better fit for production or mission-critical databases that can’t absorb an extended maintenance window, and it allows the customer to test and validate the target before cutover.

The diagram below illustrates the replication-based path end to end — from the RDS Custom for Oracle source, through continuous redo sync to an NC2-hosted standby, to a role-switch cutover onto NDB. We’ll cover the full step-by-step runbook for each path, including source and target configuration and cutover validation, in a follow-up post.

Migration architecture showing the replication-based path from RDS Custom for Oracle (source) to NDB on NC2 (target), with ongoing redo log sync and a role-switch cutover.

The Bottom Line

The March 31, 2027 end-of-support date gives RDS Custom for Oracle customers a clear runway to plan their next step. NDB on NC2 in AWS is a solid alternative for customers who want to keep OS-level access and offload the database lifecycle management that a bare EC2 migration would otherwise put back on their team — all while staying connected to their existing AWS application ecosystem, without leaving their AWS environment.

If you're running Oracle databases on RDS Custom and want to explore what this migration would look like for your environment, request a NDB demo or reach out to your Nutanix sales representative to get started.

Learn more:

• NDB product page
• Nutanix Cloud Clusters (NC2)

_{©2026 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned are for identification purposes only and may be the trademarks of their respective holder(s).}