AWS has the largest market share of all cloud providers, making it a common environment for companies to deploy their computing infrastructure. Companies moving from on-premises deployments can move to either (1) Database as a Service (DBaaS) using AWS RDS, or (2) Infrastructure as a Service (IaaS) using AWS EC2, along with many other service offerings that come with the AWS ecosystem.
A business critical database on Oracle Standard Edition (SE) is typically required to have high uptime, fast recovery (RTO) with minimal data loss (RPO) from any outage, and be resilient to all disaster types. This includes natural disasters, internet disruptions, user errors, power cuts, data corruption, and hardware failures.
While AWS aims for their infrastructure to achieve a 99.5% uptime with single instance deployments, this does not mean your database will be available 99.5% of the time. Why?
User error or internal actors: a user may misconfigure a service or delete a table rendering your database unavailable while the infrastructure is up.
Internet disruptions: internet backbone issues, such as damaged cables, have put entire regions out of action or significantly degraded performance for days even though the infrastructure is up.
Natural disasters: although less common, cloud hardware is still affected by natural disasters. The 2022 heatwave in Europe took Oracle and Google’s data centers offline for more than 18 hours.
So the unfortunate truth is that without Disaster Recovery (DR) your databases are not resilient and you won’t meet your RPO and RTO requirements, even in the cloud.
When deploying with AWS there are two core aspects for selecting where and how to deploy - Regions and Availability Zones.
Regions: each AWS Region is in a geographical area that's independent and separated by vast distances—across countries or even continents, from all the other regions. You can deploy applications in different regions to mitigate the risk of region-wide events, such as large weather systems and earthquakes. Each region can include multiple availability zones (AZs).
Availability Zones: an independent data center or set of data centers within a region. Each region has multiple availability zones connected by high bandwidth low latency networks.
For organizations with short RTO/RPO needs, AWS recommends deploying a standby environment in a separate region to mitigate a complete region outage.
AWS: Disaster Recovery Options in the Cloud
For Oracle SE deployments on AWS, there is currently no supported option for an out-of-region standby on RDS. However RDS Custom, which supports Oracle SE since April 2024, does enable the creation of warm Standby Databases on Oracle SE using Dbvisit StandbyMP. This means that out of region standby databases can now be created on both AWS DbaaS (RDS Custom) and IaaS (EC2) environments.
For Oracle SE, AWS RDS native capabilities for creating a more resilient environment include RDS automated backups, DB snapshots and Multi-AZ deployments. Each provides resiliency aspects, however, they do not protect against all disaster scenarios and recovery times may breach RTO requirements.
Automated Backups: RDS performs a full daily backup, within a customer-specified backup window. This backup enables point-in-time recovery. This feature is turned on by default and provides a retention period of up to 35 days.
DB Snapshots: these are user-initiated full database backups and are kept by Amazon RDS until explicitly deleted.
Multiple Availability Zones (Multi-AZ): In Oracle SE Multi-AZ deployment, the database is synchronized across multiple AWS data centers within a single region. This provides high availability in the event of a data center outage. However, since multi-AZ deployments are within a single region, it does not provide resiliency in the event of a region outage.
Multi-AZ deployments require a separate Oracle license for the additional standby instance. If you are required to purchase additional Oracle licenses then the most effective approach for resiliency is to deploy the DR environment within a separate region. This is not currently available for Oracle SE deployments on RDS.
RDS Custom delivers the automation of AWS RDS, but also enables the installation of additional third party tools to support legacy environments or third party applications. One large benefit is that with RDS Custom you can create more resilient, out-of-region Disaster Recovery environments through the use of a third party tool like Dbvisit StandbyMP.
Option 1: AWS Multi-AZ for Oracle SE:
Like RDS, RDS Custom can utilize Multi-AZ on Oracle SE providing an in-region standby database. Note this standby is not accessible.
Option 2: Create Out of Region Standby Databases:
Utilise Dbvisit StandbyMP to create and maintain an out of region standby database on Oracle SE, much like you would with Oracle Enterprise Edition's Data Guard.
Benefits of a Warm Standby compared to Multi-AZ
Just like on-premises, it's actually possible to easily create and manage a high-performance, resilient Oracle SE environment using Amazon’s EC2. You can even create out-of-region standby databases using a third-party tool such as Dbvisit StandyMP.
Backup: you can leverage standard Oracle RMAN utility for database backup or also leverage AWS native storage capabilities to take backups.
High Availability: Oracle SE customers can use paid third-party products VMWare and Flashgrid to create a high availability environment based on Standard Edition High Availability (SE2HA). (Read about the difference between SE2HA and RAC in our blog) Importantly, within region High Availability is not a standby database replacement because it is vulnerable to regional outages.
Disaster Recovery with a Standby Database: while Oracle Enterprise Edition (EE) customers can leverage Multi-AZ deployments or highly resilient multi-region deployments with Data Guard, Oracle SE customers do not have access to this technology.
Oracle SE customers can use Dbvisit StandbyMP to create and manage highly resilient standby databases across regions to create a highly resilient, high-performance database architecture.
To ensure maximum resiliency in the event of a disaster, AWS recommends deploying a warm standby database in a separate AWS Region. By having the standby database in a separate region, companies can protect themselves against even regional outages, achieve an excellent RPO/RTO, and thereby achieve a highly resilient and high-performance DR strategy.
AWS: Disaster Recovery Options in the Cloud
In today’s modern data-driven world, a DR strategy must ensure business continuity, no matter what type of event strikes the organization. A well-rounded DR strategy - what we call Gold Standard DR - encompasses much more than just the recovery aspects.
DR testing to ensure that all systems can successfully be recovered.
Continual verification of the standby database, to ensure the database will successfully failover when needed.
Planned switchover and rollback, to accommodate rolling upgrades, etc.
Automation of repeatable processes, to ensure consistency and reliability.
Monitoring and notifications, so that administrators are notified when events occur that require attention.
Fast troubleshooting tools.
Learn more about Standby MultiPlatform in our datasheet and feature sheet.
Read our cloud white paper discussing cloud myths and the importance of an out-of-region DR site.
Download and trial the product on-premises or in the cloud, or take it for a Test Drive in a two-hour environment.
If you have any questions at all or would like to see a demo of the software, you can contact us and we will be in touch!