Databases are at the heart of many business‑critical applications and services. They underpin essential functions such as order processing, billing, inventory management, customer portals, analytics, and much more. When a database becomes unavailable, the consequences are immediate: users lose access to vital information, business operations are disrupted, and reputational damage can quickly ensue.
To ensure business continuity, organizations set strict recovery point objectives (RPO) and recovery time objectives (RTO) for their most critical databases. Having a backup alone isn’t enough; you must be able to restore swiftly to a recent point in time. Achieving these demanding recovery targets for self-managed databases on Amazon Web Services (AWS) becomes increasingly difficult as the environment expands in scale.
By using Amazon FSx for NetApp ONTAP as the backbone of your data infrastructure, you can optimize platforms such as SQL Server, Oracle DB, MongoDB, SAP HANA, and others. For many demanding workloads with strict SLAs, FSx for ONTAP is often the only service that enables these databases to run reliably and at scale on the AWS Cloud. In this post, I am going to explain how this is achieved.
Here’s what we’ll cover:
- Navigating database resilience challenges: Meeting strict objectives at scale on AWS
- How FSx for ONTAP optimizes resilience for self-managed databases
- What this means for your team: Benefits in practice
- Summary and next steps
Navigating database resilience challenges: Meeting strict objectives at scale on AWS
Protecting a single database is one thing, but the task changes dramatically when you’re responsible for a large-scale environment. A typical mission-critical deployment can involve hundreds of databases, several hundred terabytes or more of data, and multiple environments dedicated to development, testing, pre-production, and other purposes.
Within such a landscape, you must meet a range of requirements simultaneously: High availability to ensure that business-critical workloads withstand both component failures and disruptions to Availability Zones (AZs), strict backup recovery objectives, robust disaster recovery (DR) architecture to maintain business connectivity during major incidents, and diligent cost control given the significant expenses associated with database licences, compute resources, and storage capacity.
Traditional designs that rely solely on database-level replication and periodic backups to block storage or object storage often struggle to address all these demands at scale. As a result, backup windows can expand, restore processes might take longer, and disaster recovery deployments can become increasingly complex and costly to maintain.
How FSx for ONTAP optimizes resilience for self-managed databases
Let’s take a closer look at the standard architecture of self-managed databases on AWS and then discuss how FSx for ONTAP can optimize it. For this example, we will focus on a SQL Server.
Initial architecture: AOAG SQL Server running on Amazon EC2 and Amazon EBS
I recently worked with a financial customer managing hundreds of databases and over 500 TB of data across multiple environments, including development, test, pre-production, and others. This deployment required high availability across AZs, RPO of 10 minutes and RTO of 1 hour, and an effective DR site to protect against large-scale events and maintain business continuity. The following diagram illustrates the SQL Server architecture the customer chose, with Amazon Elastic Block Store (Amazon EBS)—a common solution for running a SQL Server on AWS:
In this design:
- Two Amazon Elastic Compute Cloud (Amazon EC2) instances running SQL Server are deployed in different AZs within an AWS Region.
- Each instance uses multiple Amazon EBS volumes for database files, log files, and other data.
- SQL Server replication, such as AOAG, keeps the databases synchronized between the instances.
- Amazon EBS snapshots are used for volume-level backups, with snapshot data stored in Amazon Simple Storage Service (Amazon S3).
This architecture delivers high availability by distributing SQL Server instances across two separate AZs, while ensuring data durability and recoverability through SQL-level replication and Amazon EBS snapshots stored in Amazon S3. It provides flexible scaling, clear separation of compute and storage, and protection against outages within the Region.
However, it has several implications:
- Licensing. AOAG often requires SQL Server Enterprise licensing, which can significantly increase costs when you have many cores and multiple replicas.
- Backup and restore times. As data volumes grow, the time required to create and restore from volume-level snapshots and copies increases. Meeting the 1-hour RTO across hundreds of databases becomes difficult.
- Storage and cost. Multiple Amazon EBS volumes, frequent snapshots, and long retention periods increase storage consumption.
- DR site. Building a DR site using this design typically involves additional infrastructure, extra replicas, more storage, and complex orchestration to meet the RPO and RTO targets.
At this stage, companies are seeking an alternative architecture to overcome these challenges and optimize resilience. In many cases, as was the case with this customer, the solution lies in the choice of storage service.
Optimized architecture: SQL Server FCI running on Amazon EC2 and FSx for ONTAP
Now let’s look at an architecture for a SQL Server failover cluster instance (FCI) using FSx for ONTAP as the underlying storage, which the abovementioned customer eventually moved to:
With this approach, backup and recovery workflows change. Instead of relying only on host-based backups, you use storage-level snapshots as the primary mechanism for protecting data. Creating a snapshot is a fast operation and restore workflows can be built around reverting or cloning from those snapshots.
Because FSx for ONTAP provides high availability across AZs, it can be used as a shared block storage for both Amazon EC2 instances. With this capability, the customer can move away from an AOAG architecture to FCI, while achieving the same or even better availability. For this architecture, a Standard SQL licence can be used, substantially reducing licensing costs.
Additionally, because this architecture requires only a single copy of data, it reduces storage capacity and costs and eliminates cross-AZ charges. And without the need for SQL-level replication, Amazon EC2 instance resources are freed up.
FSx for ONTAP backup operations are based on NetApp incremental Snapshot™ technology. Stored locally on the file system, These Snapshots are created rapidly, require minimal storage due to their space-efficient design, and enable quick recovery from logical failures. Their efficient use of space also keeps backup costs low and ensures performance remains unaffected during creation.
Thanks to an integrated free tool called NetApp SnapCenter® that synchronizes these Snapshot copies with the SQL Server, they become database-aware and require no log forwarding as part of the restoration process.
Adding disaster recovery to the mix
Now let’s add another layer of protection. To further safeguard against physical failures, the design extends to a secondary FSx for ONTAP file system, which can be air-gapped and deployed in another Region. Using NetApp SnapMirror®, data is replicated asynchronously and efficiently, ensuring the latest backups are always available for DR without the overhead of full data copies.
The following diagram shows the SQL Server DR architecture with FSx for ONTAP:
In this setup, the primary FSx for ONTAP file system replicates data incrementally and asynchronously to a secondary FSx for ONTAP file system in a separate Region, providing protection against site-wide or physical failures.
A disaster recovery SQL Server instance can swiftly attach to replicated volumes or space-efficient thin clones, enabling rapid failover and recovery. DR tests and failovers rely on these storage-level copies, eliminating the need for time-consuming full data restores.
This approach aligns easily with demanding recovery objectives, such as a 10-minute RPO and 1-hour RTO, because both replication and restoration are handled efficiently at the storage layer.
Outcomes of the revised architecture
Compared to the initial architecture, FSx for ONTAP streamlines resilience with high availability across AZs. Backup happens in seconds and restore in minutes, and an effective disaster recovery site is provided.
For the customer, this meant:
- Meeting its RPO and RTO requirements.
- Achieving high availability across AZs using a storage‑centric design.
- Reducing backup operations to seconds and restore operations to minutes by using application-aware, lightweight snapshots.
- Building an efficient DR site backed by storage replication.
- Transitioning to a SQL Server Failover Cluster Instance (FCI) design that provided an approximately 40% reduction in licensing and maintenance costs, along with additional savings on compute and storage.
What this means for your team: Benefits in practice
This strategy delivers significant benefits for teams managing their own databases on AWS.
Database administrators enjoy quicker and more reliable backup and restore processes, even when working with hundreds of databases. Regular testing of recovery and disaster recovery procedures becomes more straightforward, because snapshot-based clones allow for the rapid creation of temporary environments.
Storage administrators benefit from a solution built for efficient snapshots, thin clones, and replication—naturally supporting database protection. They can set storage policies once and apply them consistently across multiple databases and environments.
Cloud architects can implement an architecture that meets stringent RPO and RTO objectives, while optimizing licensing, compute, and storage expenses. Additionally, this approach makes it easier to scale as more databases, environments, and Regions are introduced.
In short, FSx for ONTAP empowers each team to focus on strategic improvements rather than routine maintenance, enhancing both productivity and resilience.
Summary and next steps
Protecting self‑managed databases on AWS at scale is challenging. You need high availability, fast recovery capabilities, and a robust DR strategy, while keeping an eye on cost and operational complexity.
By adopting FSx for ONTAP as the storage layer and optimizing the architecture, companies can meet strict SLA requirements, achieve high availability across AZs, build efficient DR sites, while gaining substantial savings on licensing costs and additional cost savings on compute and storage.
If you’re running self-managed databases on the AWS Cloud today, this architecture is worth evaluating. Start by assessing your current RPO and RTO targets, backup times, and disaster recovery design, and consider how FSx for ONTAP can help you protect your databases more efficiently.
To deepen your understanding and explore practical guidance:
- Watch the explainer demo video, showing 3.1 TB of SQL data backed up in just 9 seconds and restored in 8 minutes.
- Read about how FSx for ONTAP optimizes database performance and reduces costs by up to 50% and how to protect your SQL Server workloads using NetApp SnapCenter in our blogs.
- Check out the how-to guides and documentation to help you get started.