AWS AmazonRDS documentation change
Summary
Updated documentation for SQL Server Multi-AZ deployments to include block level replication support, limitations, and operational recommendations. Changes include edition restrictions, metric availability notes, replication scope expansion for user roles, and command usage warnings.
Security assessment
The changes document security-related replication behavior (user-defined server roles and login parameters) when using block level replication, ensuring administrators understand security configuration consistency across replicas. However, there is no evidence of addressing a specific vulnerability.
Diff
diff --git a/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.Recommendations.md b/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.Recommendations.md index ae6abe35e..c01e79139 100644 --- a//AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.Recommendations.md +++ b//AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.Recommendations.md @@ -18,0 +19,2 @@ The following are some limitations when working with Multi-AZ deployments on RDS + * Multi-AZ with block level repcation is currently only supported for SQL Server Web Edition instances. + @@ -30,0 +33,2 @@ If you need a higher limit, request an increase by contacting Support. Open the + * Volume metrics are not available for the secondary host of the instance using block level replication. + @@ -46 +50 @@ The following are some notes about working with Multi-AZ deployments on RDS for - * Multi-AZ with DBM or AGs supports a single standby replica. + * Multi-AZ with DBM, AGs, or block level replication supports a single standby replica. @@ -48 +52 @@ The following are some notes about working with Multi-AZ deployments on RDS for - * Users, logins, and permissions are automatically replicated for you on the secondary. You don't need to recreate them. User-defined server roles are only replicated in DB instances that use Always On AGs for Multi-AZ deployments. + * Users, logins, and permissions are automatically replicated for you on the secondary. You don't need to recreate them. User-defined server roles are replicated in DB instances that use Always On AGs or block level replication for Multi-AZ deployments. @@ -77 +81 @@ The following are some recommendations for working with Multi-AZ deployments on - * For best performance, don't enable Database Mirroring or Always On AGs during a large data load operation. If you want your data load to be as fast as possible, finish loading data before you convert your DB instance to a Multi-AZ deployment. + * For best performance, don't enable Database Mirroring, Always On AGs, or block level replication during a large data load operation. If you want your data load to be as fast as possible, finish loading data before you convert your DB instance to a Multi-AZ deployment. @@ -110 +114 @@ The following are some recommendations for working with Multi-AZ deployments on - * Don't use the `Set Partner Off` command when working with Multi-AZ instances. For example, don't do the following. + * Don't use the `Set Partner Off` command when working with Multi-AZ instances using DBM or AGs. This command is not supported on instances using block level replication. For example, don't do the following. @@ -122 +126 @@ The following are some recommendations for working with Multi-AZ deployments on - * Don't use the `DEFAULT_DATABASE` parameter when creating new logins on Multi-AZ DB instances, because these settings can't be applied to the standby mirror. For example, don't do the following. + * Don't use the `DEFAULT_DATABASE` parameter when creating new logins on Multi-AZ DB instances unless using block level replication for high availability, because these settings can't be applied to the standby mirror. For example, don't do the following.