Amazon RDS for SQL Server: Cross-Region Read Replicas for Disaster Recovery. Q&A with Kambiz Aghili.
“With cross-Region read replicas, customers can horizontally scale their workloads across different AWS regions to meet their growing compliance, durability, and performance objectives.”
Q1: What new feature was released and why is this feature important?
Just to start, Amazon Relational Database Service (RDS) for SQL Server is a fully-managed SQL Server database service that makes it easy for customers to set up, operate, and scale their SQL Server deployments in the cloud. Our customers trust Amazon RDS to provide an automated, scalable, and resilient architecture for their mission critical workloads.
Customers utilize our Multi-AZ solutions which synchronously replicate data across different Availability Zones (AZ) to increase availability and prevent data loss. As a natural companion, we just released cross-Region read replicas that increases resiliency and performance by asynchronously replicating data across regions. In case of a disaster scenario, a customer can promote a replica to a standalone instance in a different AWS region.
In essence, it helps our customers unpack five key value-driven advantages: 1/ Customers, such as those in Financial and Healthcare industries, often embark on a multi-region mechanism to replicate their workloads to different AWS geographic regions in order to meet regulatory or compliance obligations and enhance workload durability, throughput and performance. Our customers are now able to accomplish all these objectives, and horizontally scale their workloads, right out-of-the-box, with just a few clicks through the AWS console or AWS CLI/API. 2/ Global customers can easily place and utilize replicas at or close to where their end-users are located so to increase query performance and response times. 3/ Customers are able to benefit from asynchronous replications to maintain high performance and provide a low Recovery Point Objective (RPO) and Recovery Time Objective (RTO) in case of a disaster. 4/ Customers and their valuable DBA staff utilize our familiar fully-managed service that simplifies the setup, monitoring, administration, troubleshooting and maintenance on top of the cross-Region read replica architecture (vs a typical self-managed model). This allows them to outsource their operational complexities, challenges and rather focus on their high-value business objectives. 5/ Customers are able to choose the right architecture for their application performance irrespective of the underlying technical complexity.
Q2: What are the best practices in designing a resilient Disaster Recovery (DR) strategy?
Organizations design their Disaster Recovery (DR) solutions around three key criteria, that include: 1) Recovery Point Objective (RPO) which refers to how much data loss is tolerated by their systems, 2) Recovery Time Objective (RTO) which is the amount of time it takes to recover systems in case of a disaster, and 3) Cost. Customers can build a customized DR strategy that ranges from a cold DR (backup and restore) to a hot DR (replicating data to a live instance).
We actively collaborate with our customers to think through several factors when creating a DR strategy using Amazon RDS for SQL Server. Customers often start by first appreciating how establishing an advanced DR strategy in the AWS cloud/RDS compares with the “on-premises” environments. On-premises customers are rather accustomed to setting up failover solutions, such as “synchronous” SQL Server replication, in a single data center that is combined with either an “asynchronous” replication or database/storage snapshots in a different data center or a different site. However, a single data center architecture only prevents hardware failure and yet leaves workloads at risk of disasters such as power outages. Whereas, Multi-AZ solution on RDS mitigates those risks as it automatically replicates data synchronously across different AZs. To clarify, AZs are distinct locations, within an AWS region, engineered to be isolated from failures in other AZs, while benefiting from low-latency network connectivity to one another. Multi-AZ deployments are usually sufficient for starting a DR strategy in one region in an AWS cloud environment. RDS for SQL Server is supported in 27 AWS regions that spread across the world. Customers are accustomed to building multi-region capabilities with manual backups or leveraging Cross-Region Automated Backups to route the backups to a different region using Amazon Simple Storage Service (Amazon S3). With just the cross-Region automated backups, the RPO/RTO could typically fall short of meeting customer needs, especially those with mission critical workloads.
Customers are now able to, simply in one click, utilize a cross-Region read replica native solution that further strengthens their architectural resilience and ability to quickly recover from regional outages.
Q3: What are the benefits of using cross-Region read replicas?
Two of the most common benefits of using cross-Region read replicas are resiliency and scalability. Resiliency is a common requirement for customers with mission critical workloads to have a reliable and an effective DR strategy. This helps keep business critical applications operational with little or no disruption even if an entire AWS region becomes unavailable. Horizontal scalability allows customers to easily scale their systems in support of their business and end-user growth. They also need to address challenges that typically come along in the form of availability and performance considerations as they expand to a global footprint. Compliance, regulations, and governing laws may further require data to reside in a specific region. The simplicity of what it takes to create RDS for SQL Server cross-Region read replicas with a click of a button makes it easy for customers to address any and all of these otherwise complex requirements.
Q4: What are the existing options to build a DR strategy with RDS for SQL Server?
As mentioned earlier, DR strategies depend on the RPO, RTO, and cost considerations. However, many of these required functionalities are already built-into our fully-managed RDS for SQL Server service. We typically present three cost effective options that include a higher (longer) RPO/RTO than cross-Region read replicas, at a cheaper price point.
Option #1: Native backup and restore in RDS for SQL Server
RDS for SQL Server supports native backup and restore for SQL Server databases. It enables customers to backup individual databases from their database instance. This native backup and restore functionality is supported with the help of stored procedures. These stored procedures let customers create a differential or full backup of their RDS for SQL Server database instances, and store the backup files on Amazon S3. They can restore these backups to an existing RDS database or an on-premises instance that is running SQL Server. Alternatively, they can store and transfer backup files on Amazon S3 in the same AWS region (in-region DR) or replicate the backup files to another S3 bucket in another AWS region (multi-region DR).
Option #2: RDS automated and manual snapshots/backups for DR
Amazon RDS, by default, takes automated snapshots of customer database instances and the associated transaction logs every 5 minutes. This allows customers to perform a Point-in-Time Restore (PiTR) according to their desired retention periods (e.g. from 1 – 35 days). Automated backup storage is free up to the amount of storage provisioned on a customer database instance. To keep the snapshot of the database longer than the set retention period, customers can take “manual snapshots” of the database instance and retain those until they are deleted. With backups, customers control when they are taken, how long they are retained, and when to restore them.
Option #3: Cross-Region automated backups
For cross-Region requirements, customers can enable cross-Region automated backups on their database instance, which copies the database to their region of choice. It further captures transaction logs every 5 minutes just like the automated backups. Cross-Region automated backups are ideal for customers in need of a cost-effective cross-Region DR capability that helps save on compute and licensing costs since there is no database instance running in that target region. Customers do not have to run any live RDS instances until such time that they would need to perform PiTR operation in another region following the unlikely event of a disaster that would take down an entire primary region! This significantly reduces management overhead, enables database administrators to focus on other tasks, and ensures compliance and data integrity with a low RPO. For more information about enabling and working with cross-Region automated backups, you may refer to Replicating automated backups to another AWS region.
Q5: How does a customer deploy cross-Region read-replicas and what are the requirements?
Customers will need to utilize a Multi-AZ RDS database instance using SQL Server Enterprise Edition. It is as simple as picking the target region in the AWS console. The read replicas allow customers to have a separate endpoint for offloading read traffic closer to the site and the option to promote the replica to their own single-AZ standalone database instance. Customers can have a total of 5 read replicas across all regions per a single primary database instance.
Q6: What other closing remarks would like to share with our readers?
We appreciate that high availability, resilience, DR and performance are critical to the operations and growth of our customers. Our global team of engineers, product managers, solutions architects, and account managers continuously gather customer feedback to help us prioritize our innovations on their behalf.
RDS for SQL Server cross-Region read replicas allows customers to create a data strategy and topology set up with the ability to 1/ offload reads to other regions, 2/ failover in just minutes to satisfy their performance and DR requirements, and ultimately 3/ simplify building a resilient and scalable strategy in just a few clicks.
For more information, including technical documentations on how to get started, please visit
Kambiz Aghili is the General Manager of Relational Database Services (RDS) at AWS. He holds a Ph.D. in computer science and an MBA in general management and finance.
Sponsored by AWS.