Considerations for modernizing Microsoft SQL database service with high availability on AWS

The core technical choice here is not simply where to run SQL Server, but how much of the database stack an organization is willing to keep operating itself as it moves to AWS. The options span three distinct responsibility models: EC2 preserves full OS and database control, RDS removes much of the day-to-day administration while retaining SQL Server semantics, and Aurora replaces the SQL Server runtime altogether in favor of a different storage-and-compute architecture. That distinction matters because high availability is implemented differently in each case, and those differences affect failover behavior, replication latency, and the amount of application change required. On EC2, availability depends on familiar SQL Server mechanisms such as log shipping, database mirroring, Always On availability groups, and failover cluster instances. Practitioners gain maximum control, but they also inherit the operational burden of patching, backups, replication management, and restoration. RDS narrows that burden and makes failover operationally cleaner in a single Region because the standby uses the same endpoint, but cross-Region resilience still depends on continuous replication and manual promotion. Aurora goes further by decoupling compute from storage and synchronously distributing data across multiple AZs, with global databases extending read-only replicas across Regions. The practical implication is that modernization is less about a single โ€œbestโ€ platform than about matching recovery objectives and administrative tolerance. The promotional claim that managed services reduce total cost of ownership is credible only if the organization can actually retire enough operational complexity to offset the migration and conversion work, especially when moving away from SQL Server-native compatibility.
Many organizations have applications that requireย Microsoftย ย SQL Server to run relational database workloads: some applications can be proprietary software that the vendor mandatesย Microsoftย SQL Server to run database service; the other applications can be long-standing, home-grown applications that includedย Microsoftย SQL Server when they were initially developed. When organizations migrate applications toย AWSย , they often start with lift-and-shift approach and runย Microsoftย SQL database service onย Amazon Elastic Compute Cloud (Amazon EC2). The reason could be this is what they are most familiar with. In this post, I share the architecture options to modernize Microsoft SQL database service and run highly available relational data services on Amazon EC2,ย Amazon Relational Database Service (Amazon RDS),ย andย Amazon Aurora (Aurora).

Running Microsoft SQL database service on Amazon EC2 with high availability

This option is the least invasive to existing operations models. It gives you a quick start to modernize Microsoft SQL database service by leveraging the AWS Cloud to manage services like physical facilities. The low-level infrastructure operational tasksโ€”such as server rack, stack, and maintenanceโ€”are managed by AWS. You have full control of the database and operating-systemโ€“level access, so there is a choice of tools to manage the operating system, database software, patches, data replication, backup, and restoration. You can use any Microsoft SQL Server-supported replication technology with your Microsoft SQL Server database on Amazon EC2 to achieve high availability, data protection, and disaster recovery. Common solutions includeย log shipping,ย database mirroring,ย Always On availability groups, andย Always On Failover Cluster Instances.

High availability in a single Region

Figure 1 shows how you can use Microsoft SQL Server on Amazon EC2 across multiple Availability Zones (AZs) within single Region.ย The interconnects among AZs that are similar to your data center intercommunications are managed by AWS. The primary database is a read-write database, and the secondary database is configured with log shipping, database mirroring, or Always On availability groups for high availability. All the transactional data from the primary database is transferred and can be applied to the secondary database asynchronously for log shipping, and it can either asynchronously or synchronously for Always On availability groups and mirroring.
High availability in a single Region with Microsoft SQL Database Service on Amazon EC2

Figure 1. High availability in a single Region with Microsoft SQL database service on Amazon EC2

High availability across multiple Regions

Figure 2 demonstrates how to configure high availability for Microsoft SQL Server on Amazon EC2 across multiple Regions. A secondary Microsoft SQL Server in a different Region from the primary is configured with log shipping, database mirroring, or Always On availability groups for high availability. The transactional data from primary database is transferred via the fully managed backbone network of AWS across Regions.
High availability across multiple Regions with Microsoft SQL database service on Amazon EC2

Figure 2. High availability across multiple Regions with Microsoft SQL database service on Amazon EC2

Replatforming Microsoft SQL Database Service on Amazon RDS with high availability

Amazon RDSย is a managed database service and responsible for most management tasks. It currently supports Multi-AZ deployments for SQL Server using SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs) as a high-availability, failover solution.

High availability in a single Region

Figure 3 demonstrates the Microsoft SQL database service that is run on Amazon RDS is configured with a multi-AZ deployment model in single region.ย Multi-AZ deployments provide increased availability, data durability, and fault tolerance for DB instances. In the event of planned database maintenance or unplanned service disruption, Amazon RDS automatically fails-over to the up-to-date secondary DB instance. This functionality lets database operations resume quickly without manual intervention. The primary and standby instances use the same endpoint, whose physical network address transitions to the secondary replica as part of the failover process. You donโ€™t have to reconfigure your application when a failover occurs. Amazon RDS supports multi-AZ deployments for Microsoft SQL Server by using either SQL Server database mirroring or Always On availability groups.
High availability in a single Region with Microsoft SQL database service on Amazon RDS

Figure 3. High availability in a single Region with Microsoft SQL database service on Amazon RDS

High availability across multiple Regions

Figure 4 depicts how you can useย AWS Database Migration Service (AWS DMS)ย to configure continuous replication among Microsoft SQL Database Service on Amazon RDS across multiple Regions. AWS DMS needs Microsoft Change Data Capture to be enabled on the Amazon RDS for the Microsoft SQL Server instance. If problems occur, you can initiate manual failovers and reinstate database services by promoting the Amazon RDS read replica in a different Region.
High availability across multiple Regions with Microsoft SQL database service on Amazon RDS

Figure 4. High availability across multiple Regions with Microsoft SQL database service on Amazon RDS

Refactoring Microsoft SQL database service on Amazon Aurora with high availability

This option helps you to eliminate the cost of SQL database service license. You can run database service on a truly cloud native modern database architecture. You can useย AWS Schema Conversion Toolย to assist in the assessment and conversion of your database code and storage objects. Any objects that cannot be automatically converted are clearly marked so they can be manually converted to complete the migration. Theย Aurora architectureย involves separation of storage and compute. Aurora includes some high availability features that apply to the data in your database cluster. The data remains safe even if some or all of the DB instances in the cluster become unavailable. Other high availability features apply to the DB instances. These features help to make sure that one or more DB instances are ready to handle database requests from your application.

High availability in a single Region

Figure 5 demonstrates Aurora stores copies of the data in a database cluster across multiple AZs in single Region. When data is written to the primary DB instance, Aurora synchronously replicates the data across AZs to six storage nodes associated with your cluster volume. Doing so provides data redundancy, eliminates I/O freezes, and minimizes latency spikes during system backups. Running a DB instance with high availability can enhance availability during planned system maintenance, such as database engine updates, and help protect your databases against failure and AZ disruption.
High availability in a single Region with Amazon Aurora

Figure 5. High availability in a single Region with Amazon Aurora

High availability across multiple Regions

Figure 6 depicts how you can set upย Aurora global databasesย for high availability across multiple Regions. An Aurora global database consists of one primary Region where your data is written, and up to five read-only secondary Regions. You issue write operations directly to the primary database cluster in the primary Region. Aurora automatically replicates data to the secondary Regions using dedicated infrastructure, with latency typically under a second.
High availability across multiple Regions with Amazon Aurora global databases

Figure 6. High availability across multiple Regions with Amazon Aurora global databases

Summary

You can choose among the options of Amazon EC2, Amazon RDS, and Amazon Aurora when modernizing SQL database service on AWS. Understanding the features required by business and the scope of service management responsibilities are good starting points. When presented with multiple options that meet with business needs, choose one that will allow more focus on your application, business value-add capabilities, and help you to reduce the servicesโ€™ โ€œtotal cost of ownershipโ€.
https://aws.amazon.com/blogs/architecture/considerations-for-modernizing-microsoft-sql-database-service-with-high-availability-on-aws/

Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.