Migration of mission-critical Oracle databases to AWS, Azure, or Google Cloud – comparing platform options

When migrating mission-critical Oracle databases from an on-premises data center to a public cloud, organizations must choose from several platform options for on-cloud database architecture. This article compares all practical options available for migrating to AWS, Azure, and Google Cloud, while highlighting the key strengths, limitations, and usage scenarios for each option. Its purpose is to provide reference material to help Database and Cloud Architects design new database architectures in the cloud.

The article covers the following options:

• Self-managed database on cloud-native compute instances
• Oracle Database@ AWS / Azure / Google Cloud
• FlashGrid Cluster
• FlashGrid Server Amazon RDS for Oracle
• Amazon RDS Custom for Oracle

Notes:

• The article does not cover the following platform options due to apparent lack of customer traction and/or vendor endorsement: VMware Cloud on AWS, Azure VMware Solution, Google Cloud VMware Engine, Google Cloud Bare Metal Solution.
• The article assumes that the reader’s intention is to continue using Oracle Database. It does not cover options for migrating to other database engines.
• Oracle Database licensing questions are out of this article’s scope due to large differences between various licensing arrangements that Oracle customers have.

Self-managed database on cloud-native compute instances

With this approach, the customer is responsible for deployment, validation, and maintenance of Oracle databases on AWS EC2 instances, Azure VM instances, Google Compute Engine instances, or similar compute instances in any other public cloud. It is the most similar to having an on-premises Oracle database setup on standard (non-Exadata) servers.

Key strengths:

• No dependency on any advanced services or infrastructure beyond the basic cloud-native compute instances and storage.
• Full control of the database home, grid home, and the operating system.
• Portability between any clouds and on-premises.

Key limitations:

• Customer has responsibility for properly configuring, validating, and maintaining the cloud instances, the operating system, and the database and grid home software.
• Self-managed database HA, DR, and backup.
• Self-managed software updates.
• Higher risk of misconfiguration and unexpected failures, especially with mission-critical systems that require high availability.
• Performance is limited by the storage throughput of a single cloud instance.
• Implementing Oracle RAC for high availability is overly complex unless using an engineered software solution for shared storage and specific network capabilities.

Key usage scenarios:

• Non-critical databases
• Legacy (end of support) database versions
• Highly customized systems

Oracle Database@AWS / Oracle Database@Azure / Oracle Database@Google Cloud

The Oracle Database@ family of services brings Exadata capabilities to AWS, Azure, and Google clouds by placing Oracle Cloud Infrastructure (OCI) “child sites” within AWS, Azure, and Google Cloud data centers. The services include Exadata Database Service on Dedicated Exadata Infrastructure, Exadata Database Service on Exascale Infrastructure, Autonomous AI Database Serverless, Autonomous AI Database Dedicated, and Base Database Service. These range from mostly self-managed database and infrastructure to fully managed DBaaS. The exact list of available services varies by cloud and may change over time.

Key strengths:

• Broad range of database service options
• All performance features of Exadata systems, especially for extra-large data warehouse scenarios.
• Full database management automation with Autonomous AI Database.
• AI capabilities, such as natural language processing, with Autonomous AI Database.
• On-demand Oracle Database licensing is available

Key limitations:

• Extra complexity and effort for connecting and maintaining two clouds (the primary cloud + OCI).
• Risk of deeper vendor lock-in through the increased dependency on proprietary Exadata and OCI features.
• Higher exposure to data center outages because the Oracle Database@ services do not allow spanning an Oracle RAC cluster across AZs. Resilience to AZ loss with zero RPO requires provisioning a standby Oracle RAC cluster in a second AZ (if available) of the same region.
• Limited HA and DR configuration options due to limited service availability by cloud regions and AZs (in some regions available in a single AZ only)

Key usage scenarios:

• Extra-large (100’s of TB) data warehouses on Dedicated Exadata Infrastructure.
• Consolidation of multiple smaller databases on shared Exadata Exascale Infrastructure.
• Simplified management of non-critical and test/dev databases with Autonomous AI Database.
• Lift-and-shift of databases whose performance heavily relies on proprietary Exadata features (Smart Scan, HCC, etc.)
• Lift-and-shift of Oracle RAC databases

FlashGrid Cluster

While not a separate cloud platform per se, FlashGrid Cluster enhances the storage and network capabilities of the native cloud compute instances to enable Oracle RAC and Failover HA clustering. It is an open virtual clustered database appliance that provides Infrastructure-as-Code deployment automation, interoperability and reliability validation, and technical support for the entire infrastructure stack. This puts FlashGrid Cluster in between the self-managed database and DBaaS models.

Key strengths:

• The simplest solution for running Oracle RAC on cloud-native compute instances
• Protection against data center outages with Multi-AZ RAC clustering
• Customer has full control of the database home, grid home, OS
• Available in all regions of AWS, Azure, Google Cloud

Key limitations:

• Self-managed DR and database backup
• Self-managed software updates

Key usage scenarios:

• Lift-and-shift of Oracle RAC databases
• Mission-critical databases with uptime SLA requirements of 99.99% or higher (achievable with FlashGrid architecture, not a contractual SLA by FlashGrid).

FlashGrid Server

FlashGrid Server is a virtual appliance for running Oracle databases in the cloud. It simplifies single-instance Oracle database deployment on cloud compute instances by providing a packaged solution with Infrastructure-as-Code automation, OS and infrastructure configuration best practices, and 24/7 support of the entire infrastructure stack. This puts FlashGrid Server in between the self-managed database and DBaaS models.

Key strengths:

• Infrastructure-as-Code automation of the deployment process
• Implements best practices for OS and infrastructure configuration
• Rapid failure isolation for Data Guard Fast-Start Failover (FSFO) configurations
• Customer has full control of the database home, grid home, OS
• Available in all regions of AWS, Azure, Google Cloud

Key limitations:

• Self-managed HA (typically Oracle Data Guard replication with FSFO)
• Self-managed DR and database backup
• Self-managed software updates
• Limited to single-instance databases

Key usage scenarios:

• Lift-and-shift of single-instance Oracle databases
• Non-critical databases that do not require HA
• Enhanced reliability and HA in Data Guard FSFO configurations

Amazon RDS for Oracle

Amazon RDS for Oracle is a fully managed Database-as-a-Service (DBaaS) offering that simplifies running Oracle databases on AWS by automating deployment and offloading routine maintenance tasks to AWS.

Key strengths:

• The simplest option with the lowest entry barrier
• Routine maintenance tasks offloaded to AWS: database backup, patching, HA replication

Key limitations:

• Available on AWS only
• AWS-specific management API with no portability to other clouds or to on-premises
• Throughput limited by a single compute instance
• Some Oracle Database features unsupported, e.g. Oracle RAC and Flashback Database
• No access to the OS and to certain database system procedures and tables

Key usage scenarios:

• Non-critical databases on AWS
• Fast implementation with minimal resources

Amazon RDS Custom for Oracle

Amazon RDS Custom for Oracle offers a middle ground between a self-managed Oracle and a fully managed Database-as-a-Service (DBaaS). It combines the automation of Amazon RDS with access to the OS, to the database home, and to database system procedures and tables.

Key strengths:

• Routine maintenance tasks offloaded to AWS: database backup, patching, HA replication
• Customizations (within operational guardrails) that are not allowed with regular Amazon RDS

Key limitations:

• Available on AWS only
• AWS-specific management API with no portability to other clouds or to on-premises
• Throughput limited by a single compute instance
• Some Oracle Database features unsupported, e.g. Oracle RAC and Flashback Database

Key usage scenarios:

• Non-critical databases on AWS
• Legacy, custom, and packaged applications that require access to the underlying operating system and database environment