AWS AmazonRDS documentation change
Summary
Updated Aurora Serverless v2 documentation by removing comparisons to Aurora Serverless v1, updating a link reference, and making editorial improvements to focus on v2 capabilities.
Security assessment
The changes are editorial and focus on feature descriptions, link updates, and removing outdated comparisons. There is no mention of security vulnerabilities, patches, incidents, or new security features. The changes describe scaling capabilities, failover mechanisms, and feature parity, which are operational and performance characteristics, not security-related.
Diff
diff --git a/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.md b/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.md index 10e468e25..8d61850d0 100644 --- a//AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.md +++ b//AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.md @@ -33,2 +32,0 @@ This type of automation is especially valuable for multitenant databases, distri - * [Migrating to Aurora Serverless v2](./aurora-serverless-v2.upgrade.html) - @@ -46 +44 @@ Aurora Serverless v2 is especially useful for the following use cases: -The granularity of scaling in Aurora Serverless v2 helps you to match capacity closely to your database's needs. For a provisioned cluster, scaling up requires adding a whole new DB instance. For an Aurora Serverless v1 cluster, scaling up requires doubling the number of Aurora capacity units (ACUs) for the cluster, such as from 16 to 32 or 32 to 64. In contrast, Aurora Serverless v2 can add half an ACU when only a little more capacity is needed. It can add 0.5, 1, 1.5, 2, or additional half-ACUs based on the additional capacity needed to handle an increase in workload. And it can remove 0.5, 1, 1.5, 2, or additional half-ACUs when the workload decreases and that capacity is no longer needed. +The granularity of scaling in Aurora Serverless v2 helps you to match capacity closely to your database's needs. For a provisioned cluster, scaling up requires adding a whole new DB instance. Aurora Serverless v2 can add half an ACU when only a little more capacity is needed. It can add 0.5, 1, 1.5, 2, or additional half-ACUs based on the additional capacity needed to handle an increase in workload. And it can remove 0.5, 1, 1.5, 2, or additional half-ACUs when the workload decreases and that capacity is no longer needed. @@ -75 +73 @@ To make it convenient to use Aurora Serverless v2 in development and test enviro -Suppose that you already have an Aurora application running on a provisioned cluster. You can check how the application would work with Aurora Serverless v2 by adding one or more Aurora Serverless v2 DB instances to the existing cluster as reader DB instances. You can check how often the reader DB instances scale up and down. You can use the Aurora failover mechanism to promote an Aurora Serverless v2 DB instance to be the writer and check how it handles the read/write workload. That way, you can switch over with minimal downtime and without changing the endpoint that your client applications use. For details on the procedure to convert existing clusters to Aurora Serverless v2, see [Migrating to Aurora Serverless v2](./aurora-serverless-v2.upgrade.html). +Suppose that you already have an Aurora application running on a provisioned cluster. You can check how the application would work with Aurora Serverless v2 by adding one or more Aurora Serverless v2 DB instances to the existing cluster as reader DB instances. You can check how often the reader DB instances scale up and down. You can use the Aurora failover mechanism to promote an Aurora Serverless v2 DB instance to be the writer and check how it handles the read/write workload. That way, you can switch over with minimal downtime and without changing the endpoint that your client applications use. For details on the procedure to convert existing clusters to Aurora Serverless v2, see [Converting a provisioned writer or reader to Aurora Serverless v2](./aurora-serverless-v2-administration.html#aurora-serverless-v2-converting-from-provisioned). @@ -83 +81 @@ Aurora Serverless v2 is intended for variable or "spiky" workloads. With such un - * **Faster and easier scaling during periods of high activity** – Aurora Serverless v2 scales compute and memory capacity as needed, with no disruption to client transactions or your overall workload. The ability to use reader DB instances with Aurora Serverless v2 helps you to take advantage of horizontal scaling in addition to vertical scaling. The ability to use Aurora global databases means that you can spread your Aurora Serverless v2 read workload across multiple AWS Regions. This capability is more convenient than the scaling mechanisms for provisioned clusters. It's also faster and more granular than the scaling capabilities in Aurora Serverless v1. + * **Faster and easier scaling during periods of high activity** – Aurora Serverless v2 scales compute and memory capacity as needed, with no disruption to client transactions or your overall workload. The ability to use reader DB instances with Aurora Serverless v2 helps you to take advantage of horizontal scaling in addition to vertical scaling. The ability to use Aurora global databases means that you can spread your Aurora Serverless v2 read workload across multiple AWS Regions. This capability is more convenient than the scaling mechanisms for provisioned clusters. @@ -87 +85 @@ Aurora Serverless v2 is intended for variable or "spiky" workloads. With such un - * **Greater feature parity with provisioned** – You can use many Aurora features with Aurora Serverless v2 that aren't available for Aurora Serverless v1. For example, with Aurora Serverless v2 you can use reader DB instances, global databases, AWS Identity and Access Management (IAM) database authentication, and Performance Insights. You can also use many more configuration parameters than with Aurora Serverless v1. + * **Greater feature parity with provisioned** – You can use many Aurora features with Aurora Serverless v2 oFor example, with Aurora Serverless v2 you can use reader DB instances, global databases, AWS Identity and Access Management (IAM) database authentication, and Performance Insights. @@ -91 +89 @@ In particular, with Aurora Serverless v2 you can take advantage of the following - * **Reader DB instances** – Aurora Serverless v2 can take advantage of reader DB instances to scale horizontally. When a cluster contains one or more reader DB instances, the cluster can fail over immediately in case of problems with the writer DB instance. This is a capability that isn't available with Aurora Serverless v1. + * **Reader DB instances** – Aurora Serverless v2 can take advantage of reader DB instances to scale horizontally. When a cluster contains one or more reader DB instances, the cluster can fail over immediately in case of problems with the writer DB instance. @@ -93 +91 @@ In particular, with Aurora Serverless v2 you can take advantage of the following - * **Multi-AZ clusters** – You can distribute the Aurora Serverless v2 DB instances of a cluster across multiple Availability Zones (AZs). Setting up a Multi-AZ cluster helps to ensure business continuity even in the rare case of issues that affect an entire AZ. This is a capability that isn't available with Aurora Serverless v1. + * **Multi-AZ clusters** – You can distribute the Aurora Serverless v2 DB instances of a cluster across multiple Availability Zones (AZs). Setting up a Multi-AZ cluster helps to ensure business continuity even in the rare case of issues that affect an entire AZ. @@ -99 +97 @@ In particular, with Aurora Serverless v2 you can take advantage of the following - * **Faster, more granular, less disruptive scaling than Aurora Serverless v1** – Aurora Serverless v2 can scale up and down faster. Scaling can change capacity by as little as 0.5 ACUs, instead of doubling or halving the number of ACUs. Scaling typically happens with no pause in processing at all. Scaling doesn't involve an event that you have to be aware of, as with Aurora Serverless v1. Scaling can happen while SQL statements are running and transactions are open, without the need to wait for a quiet point. + * **Faster, more granular, less disruptive scaling** – Aurora Serverless v2 can scale up and down faster. Scaling can change capacity by as little as 0.5 ACUs, instead of doubling or halving the number of ACUs. Scaling typically happens with no pause in processing at all. Scaling doesn't involve an event that you have to be aware of. Scaling can happen while SQL statements are running and transactions are open, without the need to wait for a quiet point.