AWS prescriptive-guidance documentation change
Summary
Updated documentation links, fixed apostrophes, improved table formatting, corrected anchor links, and made minor text clarifications for SQL Server HA/DR architectures.
Security assessment
Changes involve documentation formatting, link corrections, and minor text clarifications without introducing security features or addressing vulnerabilities. No security terminology, vulnerability references, or security controls were added/modified.
Diff
diff --git a/prescriptive-guidance/latest/sql-server-ec2-ha-dr/dr-scenarios.md b/prescriptive-guidance/latest/sql-server-ec2-ha-dr/dr-scenarios.md index 8037a093f..8c1e47f60 100644 --- a//prescriptive-guidance/latest/sql-server-ec2-ha-dr/dr-scenarios.md +++ b//prescriptive-guidance/latest/sql-server-ec2-ha-dr/dr-scenarios.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Building a high availability and disaster recovery architecture with native and hybrid methods for Microsoft SQL Server databases on Amazon EC2](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Building a high availability and disaster recovery architecture for SQL Server on Amazon EC2](introduction.html) @@ -17 +17 @@ You can use one of the following options to recover from a single Availability Z - * Provision the application recovery by using the most recent Amazon Elastic Compute Cloud (Amazon EC2) image backup, and connect to the existing warm standby database instance through an Always On availability group deployment or log shipping. + * Provision the application recovery by using the most recent Amazon EC2 image backup, and connect to the existing warm standby database instance through an Always On availability group deployment or log shipping. @@ -19 +19 @@ You can use one of the following options to recover from a single Availability Z - * A SQL Server Always On availability group setup for DR with two or more nodes provides automatic failover to the secondary node through synchronous-commit or asynchronous-commit mode, so the database is available immediately. For an HA setup, both nodes are available for read operations. This option meets both RTO and RPO requirements comfortably. In SQL Server Standard edition, using basic availability groups is also an option, but it’s limited to two nodes, because an availability group can include only one database. However, you can set up multiple availability groups within one Region or across Regions. This setup provides cost savings, because there is no additional cost for the secondary node, which isn’t accessible for read operations. SQL Server Enterprise edition provides full functionality and failover for all databases within a single availability group. For examples of this option, see the following architecture diagrams: + * A SQL Server Always On availability group setup for DR with two or more nodes provides automatic failover to the secondary node through synchronous-commit or asynchronous-commit mode, so the database is available immediately. For an HA setup, both nodes are available for read operations. This option meets both RTO and RPO requirements comfortably. In SQL Server Standard edition, using basic availability groups is also an option, but it's limited to two nodes, because an availability group can include only one database. However, you can set up multiple availability groups within one Region or across Regions. This setup provides cost savings, because there is no additional cost for the secondary node, which isn't accessible for read operations. SQL Server Enterprise edition provides full functionality and failover for all databases within a single availability group. For examples of this option, see the following architecture diagrams: @@ -23 +23 @@ You can use one of the following options to recover from a single Availability Z - * [Three-node HA/DR architecture (single-Region, Multi-AZ)](./architecture.html#three-node-one-region) + * [Three-node HA/DR architecture (single-Region, Multi-AZ)](./architecture.html#three-node-ha-dr-architecture-single-region-multi-az) @@ -27 +27 @@ You can use one of the following options to recover from a single Availability Z - * [Three-node HA/DR architecture with single availability group (multi-Region)](./architecture.html#three-node-two-region) + * [Three-node HA/DR architecture with single availability group (multi-Region)](./architecture.html#three-node-ha-dr-architecture-with-single-availability-group-multi-region) @@ -29,3 +29 @@ You can use one of the following options to recover from a single Availability Z - * SQL Server log shipping as a DR solution requires a manual failover to a standby server and depends on the frequency of log backups. This is one of the least expensive DR options. SQL Server editions for the primary and log-shipped DR site do not need to match. This option meets the RPO (using transaction log backups every 5 minutes and RTO, but requires maintenance through manual, custom scripts. For an example of this option, see the following architecture diagram: - - * [Three-node HA/DR architecture with log shipping (multi-Region)](./architecture.html#log-shipping) + * SQL Server log shipping as a DR solution requires a manual failover to a standby server and depends on the frequency of log backups. This is one of the least expensive DR options. SQL Server editions for the primary and log-shipped DR site do not need to match. This option meets the RPO (using transaction log backups every 5 minutes and RTO, but requires maintenance through manual, custom scripts. For an example of this option, see [Three-node HA/DR architecture with log shipping (multi-Region)](./architecture.html#three-node-ha-dr-architecture-with-log-shipping-multi-region). @@ -35 +33 @@ You can use one of the following options to recover from a single Availability Z - * You can use Amazon EC2 base AMIs for the application and database server to provision the infrastructure. Databases can be restored in a new Availability Zone, depending on their size and backup frequency, from the most recent native backups (full backup, differential backup, or transaction log backups every 5 minutes) or by using EBS snapshots. This option meets the RPO and RTO requirements but requires custom scripting. You must also consider the time required to provision the infrastructure, and meeting RPO and RTO requirements can be challenging. + * You can use Amazon EC2 base AMIs for the application and database server to provision the infrastructure. Databases can be restored in a new Availability Zone, depending on their size and backup frequency, from the most recent native backups (full backup, differential backup, or transaction log backups every 5 minutes) or by using Amazon EBS snapshots. This option meets the RPO and RTO requirements but requires custom scripting. You must also consider the time required to provision the infrastructure, and meeting RPO and RTO requirements can be challenging. @@ -50 +48 @@ You can use one of the following options to recover from a single AWS Region fai - * You can use an Amazon EC2 AMI for both the application and the database server and restore it to a target in a new Region. RPO depends on the size and frequency of the backups. + * You can use Amazon EC2 AMI for both the application and the database server and restore it to a target in a new Region. RPO depends on the size and frequency of the backups. @@ -54 +52 @@ You can use one of the following options to recover from a single AWS Region fai - * RTO depends on the size and time to transfer and restore the snapshots to the new Region, if the source isn’t already in sync with the target. + * RTO depends on the size and time to transfer and restore the snapshots to the new Region, if the source isn't already in sync with the target. @@ -56 +54 @@ You can use one of the following options to recover from a single AWS Region fai - * The solution with the least downtime is to restore the application backup image and have a warm standby SQL Server node in a remote Region by using a two-node, three-node, or four-node availability group setup (basic, classic, or distributed) and to connect to the standby database server after a failover. The synchronous-commit mode replica meets the RPO requirements, whereas asynchronous-commit mode replica might be delayed depending on the volume of transactions. You can use a distributed availability group configuration to scale out database nodes in a new Region, if needed. This configuration also reduces complexity because it uses two independently availability groups instead of a single availability group spread across Regions in either synchronous-commit or asynchronous-commit mode, and meets both RTO and RPO requirements comfortably. Alternatively, using SQL Server basic availability groups in the Standard edition is also an option. However, it has limitations because it supports only up to two nodes, and only one database can be in a single availability group although multiple availability groups are supported. You can set up SQL Server Standard edition within one Region or across Regions. This edition provides cost savings because it doesn’t charge for the secondary node, which isn’t accessible for read operations. SQL Server Enterprise edition provides full functionality, and supports the failover of all databases as a single availability group failover. + * The solution with the least downtime is to restore the application backup image and have a warm standby SQL Server node in a remote Region by using a two-node, three-node, or four-node availability group setup (basic, classic, or distributed) and to connect to the standby database server after a failover. The synchronous-commit mode replica meets the RPO requirements, whereas asynchronous-commit mode replica might be delayed depending on the volume of transactions. You can use a distributed availability group configuration to scale out database nodes in a new Region, if needed. This configuration also reduces complexity because it uses two independently availability groups instead of a single availability group spread across Regions in either synchronous-commit or asynchronous-commit mode, and meets both RTO and RPO requirements comfortably. Alternatively, using SQL Server basic availability groups in the Standard edition is also an option. However, it has limitations because it supports only up to two nodes, and only one database can be in a single availability group although multiple availability groups are supported. You can set up SQL Server Standard edition within one Region or across Regions. This edition provides cost savings because it doesn't charge for the secondary node, which isn't accessible for read operations. SQL Server Enterprise edition provides full functionality, and supports the failover of all databases as a single availability group failover. @@ -63 +61 @@ You can use one of the following options to recover from a single AWS Region fai -As a sizing exercise, 80% of SQL Server applications running on Amazon EC2 that have a normal online transaction processing (OLTP) workload can be grouped into one of three categories based on how critical they are: +As a sizing exercise, 80% of SQL Server applications running on Amazon EC2 that have a normal OLTP workload can be grouped into one of three categories based on how critical they are: @@ -67 +65 @@ As a sizing exercise, 80% of SQL Server applications running on Amazon EC2 that - * AWS Backup HA/DR with SQL Server backups, using an Amazon EC2 AMI for both the application and the database, and Amazon EBS storage + * AWS Backup HA/DR with SQL Server backups, using an Amazon EC2 AMI (for both the application and the database) and Amazon EBS storage @@ -76 +74 @@ The following table provides details about each category. -| SQL Server HA/ DR with SQL Server backups | AWS Backup HA/DR with AMIs, EBS storage, and SQL Server backups | AWS Backup HA/DR with AMIs, EBS snapshots, and SQL Server backups +Category| SQL Server HA/ DR with SQL Server backups | AWS Backup HA/DR with AMIs, EBS storage, and SQL Server backups| AWS Backup HA/DR with AMIs, EBS snapshots, and SQL Server backups @@ -78 +76 @@ The following table provides details about each category. -**Restore process in case of a disaster** | +Restore process in case of a disaster| @@ -94 +92 @@ The following table provides details about each category. - * Restore EBS snapshots (if any) + * Restore EBS snapshots (if any). @@ -100 +98 @@ The following table provides details about each category. -**Primary resources** | +Primary resources| @@ -103 +101 @@ The following table provides details about each category. - * Amazon EC2 backup space on Amazon Simple Storage Service (Amazon S3) + * Amazon EC2 backup space on Amazon S3 @@ -108 +106 @@ The following table provides details about each category. - * One SQL Server license (any edition). + * One SQL Server license (any edition) @@ -115 +113 @@ The following table provides details about each category. - * One SQL Server license (any edition). + * One SQL Server license (any edition) @@ -117 +115 @@ The following table provides details about each category. - * SQL Server backups (differential and log files) on Amazon S3 + * SQL Server backups (differential or log files) on Amazon S3 @@ -121,9 +119,9 @@ The following table provides details about each category. -**HA/DR** | Offers HA and DR | Offers DR only | Offers DR only -**RPO** | Failover is handled by SQL Server availability group (DR is manual) | Manual or custom scripted | Manual or custom scripted -**RTO** | Seconds to minutes | Minutes to hours | Multiple hours -**Risk of missing SLAs** | Low | Medium | High -**Manageability** | Simple | Medium | Medium -**Scaling** | Simple | Medium | Medium -**File size limitations for uploads to Amazon S3 or cross-Region transfer** | N/A – Handled in synchronous-commit mode or asynchronous-commit mode to a warm standby | Yes | Yes -**Data loss** | Near zero (depends on the workload and infrastructure provisioned) | Depends on the frequency of Amazon EC2 backup images and SQL Server backups | Depends on the frequency of Amazon EC2 backup images or EBS snapshots and SQL Server backups -**Cost** | Medium | Low – medium | Low – medium +HA/DR| Offers HA and DR| Offers DR only| Offers DR only +RPO| Failover is handled by SQL Server availability group (DR is manual)| Manual or custom scripted| Manual or custom scripted +RTO| Seconds to minutes| Minutes to hours| Multiple hours +Risk of missing SLAs| Low| Medium| High +Manageability| Simple| Medium| Medium +Scaling| Simple| Medium| Medium +File size limitations for uploads to Amazon S3 or cross-Region transfer| N/A - Handled in synchronous-commit mode or asynchronous-commit mode to a warm standby| Yes| Yes +Data loss| Near zero (depends on the workload and infrastructure provisioned)| Depends on the frequency of Amazon EC2 backup images and SQL Server backups| Depends on the frequency of Amazon EC2 backup images or EBS snapshots and SQL Server backups +Cost| Medium| Low - medium| Low - medium @@ -139 +137 @@ HA/DR options and considerations -SQL Server on Amazon EC2 architecture diagrams +Architecture diagrams