AWS prescriptive-guidance documentation change
Summary
Refined pillar description, added minimum NCU guidance, included global database recommendation for multi-Region failover, and updated section headings
Security assessment
Changes focus on reliability best practices including capacity planning and disaster recovery. No evidence of security vulnerability fixes or security feature documentation added.
Diff
diff --git a/prescriptive-guidance/latest/neptune-well-architected-framework/reliability-pillar.md b/prescriptive-guidance/latest/neptune-well-architected-framework/reliability-pillar.md index 76be5aa50..d10c75a1c 100644 --- a//prescriptive-guidance/latest/neptune-well-architected-framework/reliability-pillar.md +++ b//prescriptive-guidance/latest/neptune-well-architected-framework/reliability-pillar.md @@ -9 +9 @@ Understand Neptune service quotasUnderstand Neptune deployment patternsManage an -The [reliability pillar](https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html) of the AWS Well-Architected Framework encompasses the ability of a workload to perform its intended function correctly and consistently when it's expected to. This includes the ability to operate and test the workload through its total lifecycle. +The [reliability pillar](https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html) encompasses the ability of a workload to perform its intended function correctly and consistently when it's expected to. This includes the ability to operate and test the workload through its total lifecycle. @@ -11 +11 @@ The [reliability pillar](https://docs.aws.amazon.com/wellarchitected/latest/fram -A reliable workload starts with upfront design decisions for both software and infrastructure. Your architecture choices will impact your workload behavior across all of the Well-Architected pillars. For reliability, there are specific patterns you must follow. +A reliable workload starts with upfront design decisions for both software and infrastructure. Your architecture choices will impact your workload behavior across all of the AWS Well-Architected pillars. For reliability, there are specific patterns you must follow. @@ -30 +30 @@ The 128 TiB quota is sufficient to store approximately 200-400 billion objects i -For any [Neptune Serverless cluster](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless-capacity-scaling.html), you set both the minimum and the maximum number of Neptune Capacity Units (NCUs). Each NCU consists of 2 gibibytes (GiB) of memory and the associated vCPU and networking. The minimum and maximum NCU values apply to any serverless instances in the cluster. The highest maximum NCU value you can set is 128.0 NCUs, and the lowest minimum is 1.0 NCUs. Optimize the NCU range that works best for your application by observing the Amazon CloudWatch metrics `ServerlessDatabaseCapacity` and `NCUUtilization` to capture the range you commonly run in and correlate undesired behavior or costs within that range. If you find that your workload doesn't scale fast enough, increase the minimum NCUs to provide enough processing for the initial surge while it scales. +For any [Neptune Serverless cluster](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless-capacity-scaling.html), you set both the minimum and the maximum number of Neptune Capacity Units (NCUs). Each NCU consists of 2 gibibytes (GiB) of memory and the associated vCPU and networking. The minimum and maximum NCU values apply to any serverless instances in the cluster. The highest maximum NCU value you can set is 128.0 NCUs, and the lowest minimum is 1.0 NCUs. Optimize the NCU range that works best for your application by observing the Amazon CloudWatch metrics `ServerlessDatabaseCapacity` and `NCUUtilization` to capture the range you commonly run in and correlate undesired behavior or costs within that range. In many workloads, 1.0 NCU is too low of a starting point and results in unreliable behavior after periods of inactivity. If you find that your workload doesn't scale fast enough, increase the minimum NCUs to provide enough processing for the initial surge while it scales. @@ -41,0 +42,2 @@ If you are using Neptune Serverless, reader and writer instances in all Availabi +If your application has a worldwide footprint or requires [multi-Region failover](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-gdb-disaster-recovery.html), consider using a [Neptune global database](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-global-database.html). An Amazon Neptune global database spans multiple AWS Regions, enabling low-latency global reads and providing fast recovery in the rare case where an outage affects an entire AWS Region. A Neptune global database consists of a primary DB cluster in one Region and up to five secondary DB clusters in different Regions. + @@ -64 +66 @@ Test how your system responds to failover events. Use the Neptune API to [force -Design your clients for reliability. Test their behavior during failover events. Implement retry logic in your client with exponential backoff logic. Code examples that implement this logic can be found in [AWS Lambda function examples for Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/lambda-functions-examples.html). +Design your clients for reliability. Test their behavior during failover events. Implement retry logic in your client with exponential backoff logic. Code examples that implement this logic can be found in the documentation under the [AWS Lambda function examples for Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/lambda-functions-examples.html). @@ -74 +76 @@ To use the Amazon Web Services Documentation, Javascript must be enabled. Please -Security +Security pillar @@ -76 +78 @@ Security -Performance efficiency +Performance efficiency pillar