Cloud Database Migration Costs: AWS RDS for Oracle vs. Oracle ATP

Premise

Our fundamental premise is that high-value specialist workloads such as large-scale mission-critical databases mandate a specialized combination of hardware, software, and automation. This is true for both cloud and on-premises deployments. Therefore, this research expects that a specialist cloud service with automation and with an architecture that enables ultra-low latency, high levels of consolidation, and fast recovery (e.g., Oracle ATP with Exadata on OCI*) will result in significantly lower IT budget costs and expected downtime costs when compared with general-purpose cloud architectures (e.g., AWS Single-AZ RDS for Oracle**).

Note: Wikibon has abbreviated the “official” names used in this research to improve readability.

• * The full name for the Oracle cloud service analyzed is Oracle Autonomous Transaction Processing Dedicated (ATP-D) cloud service, deployed on Exadata X8M on Oracle Cloud Infrastructure (OCI).
• ** The full names of the two AWS Oracle Database cloud services analyzed are Amazon RDS Single-AZ for Oracle on AWS & Amazon RDS Multi-AZ for Oracle on AWS.

Executive Summary

Summary of Methodology

This research examines the requirements that an enterprise with $2B in annual revenue has when moving their mission-critical Oracle Database systems of record applications from on-premises to the cloud. It compares the 5-year cost for migrating Oracle Database workloads from a well-run on-premises “best-of-breed” IT installation (the base case) to three alternative cloud architectures, and then running those same workloads on the new infrastructure:

• Oracle ATP with Exadata X8M in OCI
• AWS Single-AZ RDS for Oracle (Single Availability Zone)
• AWS Multi-AZ RDS for Oracle (Multiple Availability Zones)

The factors considered include the performance, availability, business continuity, the number and cost of virtual cores, storage, networking, Oracle Database maintenance costs, and other IT costs.

Executive Summary of 5-year costs

Figure 1 below summarizes the financial analysis of this research across multiple deployment scenarios for an enterprise with $2B in annual revenue. Enterprises with higher/lower revenue or larger/smaller IT budgets would see similar relationships between the total costs across these deployments, although the differences may not scale in a perfectly linear fashion.

The blue-colored first column in Figure 1 reflects the base case, the 5-year IT costs of remaining on On-premises “Best-of-Breed.” There are no migration costs, and the operational costs add up to $56.5M.

The orange-colored second column in Figure 1 reflects the 5-year costs of migrating to AWS Single-AZ RDS for Oracle. The total migration costs for 15 months and the operational costs add up to $55.1M.

The stippled orange-colored third column in Figure 1 reflects the 5-year costs of migrating to AWS Multi-AZ RDS for Oracle. The total migration costs for 15 months and the operational costs add up to $73.6M.

The red-colored fourth column in Figure 1 reflects the 5-year costs of migrating to Oracle ATP with Exadata on OCI. The total migration costs for 9 months and the operational costs add up to $28.7M. The detailed analysis in the Methodology section below will discuss the detailed reasons why the cost of the Oracle ATP solution is so much lower than the AWS RDS solutions.

Executive Summary of 5-year Downtime costs

Figure 2 below summarizes the expected cost of downtime across the same deployment scenarios. The actual cost of downtime will vary significantly from year to year. Extended outages are rare, but the business impact increases non-linearly with the length of the outage.

Figure 2 – 5-year Expected Cost of Downtime for Mission-critical System-of-Record running on Oracle Database on On-premises “Best-of-Breed,” AWS Single-AZ RDS  for Oracle, AWS Multi-AZ RDS  for Oracle, and Oracle ATP with Exadata X8M on OCI. Source: © Wikibon 2021.

The blue-colored first column in Figure 2 reflects the base case, the 5-year downtime costs of remaining on On-premises “Best-of-Breed,” which is $13.7M.

The orange-colored second column in Figure 2 reflects the 5-year downtime costs when running AWS RDS Single-AZ for Oracle, $11.7M. Again, this is slightly lower (better) than the on-premises solution.

The stippled orange-colored second column in Figure 2 reflects the 5-year downtime costs when running AWS RDS Multi-AZ for Oracle, 11.7M. Again, this is significantly lower (better) than the on-premises solution and AWS RDS Single-AZ solution.

The red-colored fourth column in Figure 2 reflects the 5-year downtime costs when migrating to Oracle ATP with Exadata on OCI, which is $4.2M. The detailed analysis in the downtime section below discusses why the Oracle ATP downtime costs are so much lower and better than the AWS RDS solutions.

For each scenario, Figure 1 shows the 5-year total cost of cloud migration, while Figure 2 shows the expected cost of downtime during the 5-year period. This research argues that the cost of downtime should be part of the IT budget, and savings from reducing it should be considered in all NPV, breakeven, and IRR metrics. However, we are showing these separately since not all organizations operate in this way.

Executive Summary of Financial Case for Migration

The top half of Figure 1 shows the 5-year IT Budget Cost comparisons, assuming that the budget for expected Downtime Costs is held by IT. IT recommends this approach because IT can trade-off additional expenditures on IT to offset the downtime costs to the lines of business.

Table 1 shows the total IT budget costs are $70.2M for remaining on-premises, $66.8 for migration to AWS Single-AZ RDS for Oracle, $81.8M for migration to AWS Multi-AZ RDS for Oracle, and $33.0M for migration to Oracle ATP with Exadata X8M on OCI.

The bottom half of Table 1 shows the 5-year financial analysis for the three migration alternatives. The orange-colored third column in Table 1 reflects the 5-year costs and downtime costs of migrating to AWS Single-AZ RDS for Oracle from On-premises “Best-of-Breed.” The 5-year cumulative savings are only $3.3M, the NPV is $2.6M, the breakeven is 42 months, and the IRR is -34%. The additional operational costs swamp the 5-year downtime savings of $5.5M from Single-AZ. In summary, there is no business case for migration from on-premises to AWS Single-AZ RDS for Oracle.

The business case in Table 1 for migration to AWS Multi-AZ is worse than Single-AZ. The orange-colored fourth column in Table 1 financial analysis reflects the 5-year costs and downtime costs of migrating to AWS Multi-AZ from On-premises “Best-of-Breed.” The cumulative savings are minus $11.6M; the NPV is minus $10.9M, there is no breakeven and no IRR. In summary, there is no conceivable business case for migration from On-premises to AWS Multi-AZ RDS for Oracle. The author has yet to meet a CFO who would approve this project.

Bottom Line: This means that AWS RDS Single-AZ for Oracle has a total cost (including IT and downtime costs) 2X that of Oracle ATP, and AWS RDS Multi-AZ for Oracle solutions have a total cost that is 2.5X the cost of Oracle ATP.

Executive Summary of Conclusions

Wikibon concludes that the Oracle Exadata architecture is the best available platform for mission-critical Oracle Database workloads. Therefore, Wikibon strongly recommends that IT organizations run mission-critical Oracle Database workloads using Autonomous Database on Exadata infrastructure, either in their own data centers or Oracle Cloud Infrastructure. Furthermore, given the significant financial advantages for the Oracle solution over AWS, CFOs should not hesitate in approving projects for the migration of Oracle Databases to Oracle ATP on Exadata X8M in OCI.

Wikibon’s discussions with Oracle Database users have shown a strong level of confidence in Oracle’s Exadata cloud strategy, which offers both automated Autonomous Database and less-automated Oracle Database environments on both Exadata infrastructure in OCI regions and Exadata Cloud@Customer in customers’ data centers. These users have found out (sometimes the hard way) that migrating Oracle Database to AWS is expensive, Oracle’s specialized architecture does a much more efficient, cost-effective job for database workloads, and that the AWS architecture may not provide the same level of availability as an Exadata-based solution. Recently, Deutsche Bank has publicly committed to implementing the Oracle Exadata Cloud@Customer platform worldwide to help accelerate technology modernization.

Lastly, Wikibon recommends that the “Expected Budget” for downtime costs should be held by IT, as IT engineers are in the best position to optimize spend on capabilities to reduce downtime and downtime costs.

Detailed Methodology

Methodology Introduction

General-purpose cloud computing is typically cheaper than general-purpose on-premises computing. Cloud vendors such as AWS have virtualized their CPU resources (vCPUs) using equipment specialized for low-cost general-purpose workloads. The virtualization overhead is practically zero. Because the utilization of general-purpose CPUs is poor (~20%), the cloud vendors can sell these vCPUs two to three times over and lower the price.

However, mission-critical database computing is radically different from general-purpose computing. For example, Oracle Database application suites perform better with ultra-low latency IO, high bandwidth, redundancy, and rapid recovery. Databases manage the serialization of access and database integrity by locking parts of the database. The quicker these locks are released, the faster the database operates. Wikibon has analyzed the Exadata X8M in-depth, with such features as ~20 microsecond IO performance.  These applications also run more efficiently when the IT compute, storage, and networking resources are disaggregated and fully shared.

As a result, the cost of the specialized hardware, software, and automation to drive these mission-critical systems is higher than everyday cloud computing. However, the overall database throughput and lower operations costs result in much lower costs, as this research shows.

In addition, the business cost of poor application performance is high, the business impact for failing to deliver continuous availability for the application is high, and the impact of application failure (the cost of downtime) is also high.

Methodology IT Budget Calculations

Wikibon used its extensive research to construct a standard model of a $2 billion enterprise, which runs its mission-critical systems of record applications on Oracle Database. The database systems of record run on do-it-yourself “best-of-breed” servers, storage, and networking infrastructure. From an operational perspective, enterprise IT organizations using the “best-of-breed” approach typically have different specialists dedicated to managing servers, storage, and networking. Table 2 above shows the annual budget line items for the mission-critical system-of-record in a $2B enterprise.

The “Other Database Costs” line item is estimated as 15% of all the line items except Database Maintenance. The “Database Maintenance” line item assumes the enterprise has already purchased 250 Oracle Database Enterprise Edition processor licenses with the Real Application Clusters (RAC) and Active Data Guard options.

The operational support costs include operators, database specialists (DBAs), and application developers required for maintaining the systems of record applications.

Workload Virtualization and Consolidation

Database applications are usually sensitive to any factor that can slow execution times. These factors include high CPU utilization and long (or variable) IO times, and system-of-record applications are susceptible. AWS, VMware, and Linux virtualization developers have worked hard at reducing the “virtualization tax,” which was as high as 15% in the early days. AWS introduced the Nitro card as part of its cloud architecture, and any overhead is now difficult to measure.

There is an additional benefit that virtualization brings to the table called VM oversubscription. The number of virtual machines and their allocated memory can be greater than the CPUs and Memory allocated to a VM. As a result, virtualization can offer a much lower cost for VM workloads with low compute requirements. In fact, customers deploying the Oracle ATP in OCI regions or Dedicated Region Cloud@Customer environments can also take advantage of these capabilities for their middleware and application tiers.

Oversubscription is also useful in database environments where the functionality and cost of the database are higher than the hardware costs. Examples include Microsoft SQL Server, Oracle Database, and Splunk. Oversubscription can lower the cost of compute, but even more importantly, the cost of database licenses. However, there is a trade-off in the level of Virtual Machine oversubscription. Too much and the utilization of the VMs leads to long response time, which leads to reduced utilization, higher costs, and poorer end-user response times.

Calculating On-premises Workload Consolidation

Figure 3 shows the relative number of total vCPUs needed for each environment and the utilization percentage for each. The source of the data is in Table 3 further down.

The workload is a mission-critical system of record. The first two columns of the table are in blue and reflect the consolidation capacities of a well-run on-premises DIY “best-of-breed” IT environment. VM oversubscription is assumed to reduce the number of vCPUs and memory by 25% to a total of 1,268 vCPUs (see column 1 of Table 3) from the number of 1,690 vCPUs that would be required if there was no VM oversubscription. Wikibon believes that this is a conservative reduction of cost and database licenses that will ensure it will meet the stringent SLAs of mission-critical systems of record. Wikibon modeling has calculated the overall CPU utilization of the workload as 27%, shown in column 2 of Table 3.

Table 3 below looks at the consolidation capabilities of the three platforms analyzed in this research.

Availability Considerations

It should also be noted that Multiple Availability Zones or Domains within a cloud computing region do not universally meet the minimum distance required by all customers for disaster recovery purposes. For example, disaster recovery often requires distances of 100 to 200 miles between sites (to guard against regional disasters such as hurricanes, earthquakes, etc.), while multi-AZ/AD provide much less separation (typically on the order of several kilometers). Therefore, for this paper, Multi-AZ/AD is considered to be a local standby or High Availability (HA) solution rather than being suitable for Disaster Recovery (DR) purposes.

The red-colored fourth column in Figure 1 reflects the 5-year costs of migrating to Oracle ATP with dedicated Exadata X8M infrastructure deployed in OCI regions. The total migration costs for 9 months and the operational costs add up to $28.7M, or 49% less than the operational costs for a Best-of-Breed (BoB) on-premises solution. Figure 2 shows an additional savings of $9.5M from lower levels of expected downtime. The Oracle ATP service has $26.4M lower 5-year IT costs than AWS Single-AZ RDS for Oracle, a 48% savings. The Oracle ATP service has $48.8M lower 5-year IT costs than AWS Multi-AZ RDS for Oracle, a 61% savings. Table 3 in the “Financial Analysis” section shows the NPV for the Oracle ATP on Dedicated Exadata X8M deployed on OCI is $32.9M, breakeven is 13 months, and the IRR is 156%.

Calculating AWS RDS costs for Oracle Workload Consolidation

AWS offers database software as a managed Relational Data Service (RDS), which supports AWS Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, and SQL Server. The user can choose from many instance types to suit specific database applications. AWS RDS provides industry-leading virtualization for its Relational Database Systems (RDS) instances with the use of its Arm-based “Nitro” cards to reduce the virtualization overhead for compute shapes, allowing vCPU processors to operate with the same overhead as bare-metal CPUs—albeit at half the total performance since one vCPU is one thread in a CPU.

However, there is a profound difference in how AWS manages virtual workload consolidation. In AWS RDS, each deployed database instance is managed independently. It is not possible to dynamically change an instance. If an instance size needs to be increased to meet higher workload requirements or decreased to reduce costs, the application using the database must be stopped and the database restarted, which results in about five minutes of downtime. The worst part for system and database analysts is the application-level outage created by a five-minute outage may create hours of application-level outages – something that’s almost impossible to negotiate with end-users. The result is that IT and end-users are conservative in making sure that sufficient vCPUs and memory are available to databases and applications to minimize downtime. Because each of these instances is separate, workload consolidation is impossible.

Columns 3-6 in Table 3 are orange and show the calculations for the AWS RDS vCPUs required to run the same workload as in the Best-of-Breed columns. The AWS RDS instance types used in this model are shown in column 4 and are based on organizational requirements to support a suite of mission-critical system-of-record applications with different sized instances to strike a balance between delivering predictable performance and managing costs. Each AWS RDS instance defines the number of vCPUs (shown in column 5), memory size, storage type, and networking performance. The total number of vCPUs required for AWS RDS is shown in column 6 as 1,690. The vCPU count is 33% higher than the best-of-breed on-premises count because (as stated above) there is no workload consolidation capability in RDS.

AWS has excellent virtualization technology and does not waste these vCPU cycles. Column 7 in Table 3 shows the lower utilization of the RDS implementation. AWS can reuse these cycles and makes them available to other users, including other instances from the same customer! As a result, AWS can charge for each of its server resources 2-3 times—increasing AWS revenue. In theory, this capability should allow AWS to lower prices by 50% to 67%.

When running with an AWS RDS Multi-AZ environment, the customer requests the same number of vCPUs from AWS and in the background, a standby database is created on parallel infrastructure in the second AZ. The vCPUs in the second AZ are not available for active database processing.

Wikibon believes the model described in this research makes conservative estimates of the number of AWS RDS instance types that might be selected in an actual implementation. Wikibon hopes that this will make the math behind the model easier to follow and believes it will not significantly change the modeling results.

The bottom line: AWS RDS for Oracle requires 33% more vCPUs than the original on-premises VM installation. This means higher infrastructure and database maintenance costs.

Calculating Oracle ATP with Exadata X8M on OCI for Oracle Workload Consolidation

Oracle Autonomous Transaction Processing offers converged Oracle Database software, which supports many data types and database use cases—including data warehousing, graph analytics, and embedded machine learning. Wikibon assesses Oracle as the most functional database and is one of only three Tier-1 databases.

The Exadata architecture allows complete disaggregation between vCPU, memory, storage, and networking resources. There are no instance types. A suite of mission-critical system-of-record applications can utilize the resources dynamically. ATP manages the performance and SLA achievement of all the applications and adapts dynamically, scaling up or down as needed. The tuning of the database is automated. For example, the use of secondary index tables is monitored and updated dynamically. ATP helps to allocate and optimize the resources to help achieve the SLAs.

ATP with Exadata in OCI supports virtual workload consolidation of all workloads since all resources are managed collectively. As a result, IT can dynamically change the requirements of an application without incurring application downtime. The Oracle Database Real Application Clusters (RAC) feature is fully supported, allowing dynamic scaling and local high availability, while Autonomous Data Guard enables remote redundancy for disaster recovery. The result is that IT and end-users do not have to worry about having insufficient resources, and vCPUs and memory are available to applications to minimize downtime.

The red columns in Table 3 show the calculations for the Exadata vCPUs required to run the same workload as Columns 1. Exadata has an excellent workload consolidation capability. Column 8 shows the conservative Wikibon assumption that the workload consolidation can be 50%. The number of vCPUs is therefore 845, half of the number that AWS RDS for Oracle requires.

Oracle ATP has another consolidation feature. Columns 9 and 10 split the vCPUs into base vCPUs for continuous usage and burst vCPUs for peak workloads. The model conservatively assumes that 2/3s of the vCPUs are base, but customers with highly variable workloads may choose to reduce this number to lower costs. On top of base vCPUs, burst vCPUs can add up to a maximum of 3X additional vCPUs to meet peak workloads. However, a good rule of thumb used in this model is that the expected use of burst vCPUs is about 50% of the provisioned vCPUs. However, since burst CPUs are not needed for the entire time, this works out to roughly 141 vCPUs or 17% of the 845 vCPU total. The model shows that the likely maximum number of vCPUs required at any one time is 83% of 845 vCPUs, which is shown as 705 in column 11, which leaves 140 additional vCPUs available for unexpected surges or rapid deployment of new application databases. This workload consolidation features significantly reduce the infrastructure and Oracle Database maintenance costs.

The final column in Table 3 shows the likely utilization of vCPU resources, calculated as 40%. This is roughly double the 20% utilization that we estimate for the AWS RDS scenarios. However, Wikibon believes that the model described in this research makes conservative estimates of the number of RDS instance types that might be selected in an actual implementation—meaning that the utilization may actually be lower. Wikibon believes that this will make the math behind the model easier to follow and believes it will not significantly change the modeling results.

The bottom line: AWS RDS for Oracle requires 33% more vCPUs than the original on-premises VM installation while ATP on Exadata X8M deployed in OCI  requires 33% less – only half the number needed for AWS RDS on AWS infrastructure. This means that ATP on Exadata X8M in OCI will have significantly lower infrastructure and database maintenance costs.

Calculating Expected Downtime Costs

In the world of system downtime, there are lies, dammed lies, and vendor downtime statistics. Many vendors are claiming seven 9s of availability (99.99999%). If these were true, there would be only 3 seconds of downtime a year. One Google search on major Internet outages shows a very different story, with every cloud vendor and datacenter operation having extensive planned and unplanned downtime.

Table 4 below shows the calculations for determining the expected downtime costs by platform. The first column describes a set of metrics that are used to determine expected downtime costs. The number of outages per year is a 5-year average of rare events that affect database application availability. The number of actual events will vary significantly from year to year.

Lines 1 is enterprise annual revenue assumed to be $2 billion. Line 2 is the number of hours that the mission-critical systems of record are assumed available in a (non-leap) year (24 x 365). Line 3 is revenue/hour, calculated from line 1 times line 2.

Line 4 is the percentage impact on enterprise revenue during the time of an outage. Wikibon has assumed 30%, which is conservative.

Line 5 is the cost per minute of an outage, calculated as line 3 times line 4 divided by 60, which is $1,142/minute. Enterprise IT and analysts use this metric extensively. Gartner currently assesses the average cost per outage per minute as $5,000/minute, which indicates that the value of $1,142 used in this analysis is also very conservative. Wikibon has assumed this enterprise has well-run IT operations with experienced systems and database administrators.

The next three lines (6-8) are used to calculate the number of outage hours and show the assumptions around an outage of an Oracle Database, the subsequent outage on the applications dependent on the database, and the number of outages per year. These assumptions are different for each platform.

• On-Premises – Wikibon assumes the on-premises environment has an average time to recover from DB failure and subsequent application failure of 1 hour each, with 20 outages per year. The number of outage hours is (DB recovery time + App recovery time) x Number of outages = (1 + 1) x 20 = 40 Outage Hours per year. This is about half of the Gartner average of 87 hours, as you would expect in a well-run IT department.
• AWS Single-AZ RDS for Oracle – In the RDS system, an outage of an RDS instance will lead to a restart on another instance. The restart is automatic, and the Oracle recovery allows the database admin to recover the database to the correct state. Wikibon assesses that this takes a little less time than an on-premises installation because more resources are available to complete the task (0.9 hours). The database applications will also need to be restarted, and Wikibon assesses that this will also be slightly faster than on-premises (0.9 hours). The AWS RDS system and the number of outages seen are expected to be slightly lower (18 times). Wikibon assesses that RDS will improve each factor by 10%. The number of outage hours = (0.9 + 0.9) x 18 = 32.4 Outage Hours per year.
• AWS Multi-AZ RDS for Oracle – In the RDS Multi-AZ system, a separate copy of the data is maintained (synchronously) in a second Availability Zone, and AWS can restart the instance in about 2 minutes, which is a good implementation. The restart is automatic, and the database is recovered to the correct state automatically. Wikibon assesses this takes on average 12 minutes (0.2 hours), with special cases taking longer, and administrative overhead is considered. The database applications will still need to be restarted, and Wikibon assesses that this will take about the same time as the RDS system (0.9 hours). The AWS Multi-AZ RDS for Oracle system and the number of outages seen are expected to be slightly lower than AWS Single-AZ RDS (17 times). Wikibon assesses that the number of outage hours = (0.2 + 0.9) x 17 = 18.7 Outage Hours per year.
• Oracle ATP with Exadata X8M on OCI– Oracle ATP detects a failing database processor with special monitoring in the Exadata architecture. The database fails over to another RAC processor in about 2 seconds. A slowdown of a few seconds is likely, but the applications do not timeout and will continue running. As in every recovery system, failover is not guaranteed. Wikibon assesses the average database recovery is 6 minutes (0.1 hours) for special cases. The database applications will still need to be restarted, and Wikibon assesses that this will take about the same time as the AWS RDS system (0.4 hours). Wikibon expects that the ATP machine learning features engineered into the code will reduce outages by 25% compared with the on-premises environment (15 times). Wikibon assesses the number of outage hours = (0.1 + 0.4) x 15 = 7.5 Outage Hours per year.

The formula for calculating the expected Lost Revenue per year in Table 4 is the Cost/Minute of Downtime (line 5) x 60 x Number of Outage Hours per Year (line 9). The results shown in Table 4 are:

• On-Premises – $2.7 million per year
• AWS Single-AZ RDS for Oracle – $2.2 million per year
• AWS Multi-AZ RDS for Oracle – $1.3 million per year
• Oracle ATP with Exadata X8M on OCI – $0.5 million per year
• Gartner Average – $26.1 million per year

Wikibon recommends that the budget for the expected cost of downtime should be held by IT. This will allow the IT engineers to evaluate the tradeoffs of spend on superior databases and superior platforms for different workload categories.

Wikibon concludes that the machine learning innovations of ATP and the specialized architecture of Exadata enable enterprises to lower the cost of downtime significantly for mission-critical systems of record.

Financial Analysis

Figure 4 below shows a more detailed breakdown of the IT budget line items that go into the 5-year business case. The source of information is all the previous Tables 1-5. Table 6 in the Footnotes section below show the detailed configuration and cost of the AWS Single-AZ RDS for Oracle instances used in the modeling for this research. Table 7 in the Footnotes shows the detailed configuration and costing for AWS Multi-AZ RDS for Oracle instances. Table 8 in the Footnotes section below shows the detailed calculations for Oracle Database Maintenance for On-premises, the AWS Single-AZ and AWS Multi-AZ RDS for Oracle, and for Oracle ATP with Exadata X8M on OCI.

The items that stand out in Figure 4 include:

• The operational support is significantly reduced in all the cloud scenarios due to the automated patching offering in RDS and Oracle ATP —with only ATP having fully non-disruptive online patching. ATP decreases costs further than running a standard Oracle Database software license on-premises.
• Database Maintenance is much higher for AWS scenarios due to the lack of workload consolidation. ATP on Exadata has the greatest flexibility, and by far the best workload consolidation capabilities together with the automatic vCPU burst feature.
• The AWS RDS Multi-AZ scenario uses data synchronization/mirroring to great effect to provide a 2-minute failover to another zone. However, the cost of the AWS RDS service is doubled in a Multi-AZ configuration. In addition, the ability to reduce expected downtime costs was limited since RAC is not supported on the AWS RDS service.
• Oracle ATP includes features such as Always-on Encryption, Auto-patching, and Advanced Auditing, which are important in reducing the number and scope of downtime.
• The Oracle Database maintenance calculations are shown in Table 8 in the Footnotes.

Figure 5 shows the detailed breakdown of the IT budget line items for year 3 after all migrations have been completed (after migration). This illustrates that cloud services are generally lower cost than on-premises “best-of-breed” environments. On-premises is 293% more expensive than Oracle ATP with Exadata X8M on OCI, while AWS Single-AZ RDS for Oracle is 240% and AWS Multi-AZ RDS for Oracle is 336% more expensive.

The Wikibon financial analysis shown in Table 5 below shows that the financial case for migrating Oracle Databases from on-premises to Oracle ATP with Exadata X8M on OCI is robust, with a savings of $37.2M over five years, a Net Present Value of $32.9M, a breakeven of 13 months, and an IRR of 156%. Figure 5 above shows that the year-n costs after the migration are about 1/3 the cost of the on-premises scenario and well under half of the AWS RDS for Oracle on AWS scenario. This is an excellent business case, and Wikibon believes any CFO would approve the case.

The business case for migration to AWS RDS for Oracle is not there, with an NPV of $2.6M, and breakeven of 42 months, and an IRR of -34%. Wikibon believes almost all CFOs would reject the case. Table 3 shows clearly that there is no business case for the AWS RDS Multi-AZ for this workload type.

Wikibon believes that AWS needs to have a high-availability equivalent of Oracle RAC. It also needs to create a much better vCPU reduction strategy for Oracle Database and other high cost/vCPU licenses such as Microsoft SQL Server and Splunk.

Conclusions & Recommendations

Our research compared a specialist cloud implementation from Oracle with a general-purpose cloud implementation from AWS. Our research indicates that specialized hardware and software in Oracle ATP with Exadata X8M on OCI, together with automation, can improve the price-performance of cloud migration and deployment by 2X when compared with the AWS alternative. In addition, we find that ATP can reduce the downtime costs to the business by 2.5-5X.

In recent discussions with Wikibon, Oracle Database users have shown confidence in Oracle’s Exadata and Autonomous Database strategy. These users have investigated (and in some cases tried to move) Oracle Database workloads to AWS RDS for Oracle. As a result, users have determined that doing so requires costly migrations to a general-purpose platform that does not meet their performance, scale, budget, and availability requirements.

Databases are a critical part of enterprise digital transformation strategies. Wikibon reminds senior executives of what every DBA knows – large-scale databases are difficult to architect, design, and maintain. Wikibon emphasizes that large-scale databases require a specialized platform and not a general-purpose platform such as what AWS RDS currently provides.

Deutsche Bank has made a recent strategic agreement with Oracle to implement Exadata Cloud@Customer on a worldwide basis to help them accelerate technology modernization. This agreement is a clear confirmation that companies with large-scale, mission-critical database workloads require a specialized database platform.

Wikibon concludes that Oracle ATP with Exadata X8M on OCI is the best available cloud and on-premises service for mission-critical Oracle Database workloads. The workload consolidation capabilities have dramatically reduced the number of vCPUs and the number of licenses required to be maintained, dramatically lowering costs.

Lastly, Wikibon recommends that the “Expected Budget” for downtime costs should be held by IT, as IT engineers are in the best position to optimize spend on capabilities to reduce downtime and downtime costs.

Action Item

Wikibon strongly recommends that IT organizations run mission-critical Oracle Database systems of record workloads with Oracle ATP on Exadata X8M in OCI regions. IT can also deploy these systems with Exadata Cloud@Customer in their data centers or in large colocation facilities (e.g., Equinix) in support of multi-cloud deployments. Furthermore, given the financial advantages for the Oracle solution over AWS, CFOs should encourage projects for the migration of Oracle Databases to Oracle ATP on Exadata X8M in OCI.

Footnotes

• Table 6 below shows the detailed configuration and costs of the AWS Single-AZ RDS for Oracle instances used in the modeling for this research.
• Table 7 below shows the detailed configuration and costing for AWS Multi-AZ RDS for Oracle instances.
• Table 8 below shows the detailed calculations for Oracle Database Maintenance for On-premises, the AWS Single-AZ and AWS Multi-AZ RDS for Oracle, and the Oracle ATP with Exadata X8M on OCI.