AWS AmazonElastiCache documentation change
Summary
Replaced all instances of 'self-designed cluster' with 'node-based cluster' terminology to clarify cluster types
Security assessment
The changes are purely terminological updates (self-designed → node-based) without altering technical guidance. No security vulnerabilities, mitigations, or new security features are introduced. The updates maintain existing recommendations for Multi-AZ configurations and node distribution without security implications.
Diff
diff --git a/AmazonElastiCache/latest/dg/disaster-recovery-resiliency.md b/AmazonElastiCache/latest/dg/disaster-recovery-resiliency.md index 691a92c60..bb1df4734 100644 --- a//AmazonElastiCache/latest/dg/disaster-recovery-resiliency.md +++ b//AmazonElastiCache/latest/dg/disaster-recovery-resiliency.md @@ -43 +43 @@ When running the Memcached engine, you have the following options for minimizing -Serverless caches automatically mitigate node failures with a replicated Multi-AZ architecture so that node failures are transparent to your application. To mitigate the impact of a node failure in a self-designed cluster, spread your cached data over more nodes. Because self-designed clusters do not support replication, a node failure will always result in some data loss from your cluster. +Serverless caches automatically mitigate node failures with a replicated Multi-AZ architecture so that node failures are transparent to your application. To mitigate the impact of a node failure in a node-based cluster, spread your cached data over more nodes. Because node-based clusters do not support replication, a node failure will always result in some data loss from your cluster. @@ -53 +53 @@ Serverless caches automatically mitigate availability zone failures with a repli -To mitigate the impact of an Availability Zone failure in a self-designed cluster, locate your nodes in as many Availability Zones as possible. In the unlikely event of an AZ failure, you will lose the data cached in that AZ, not the data cached in the other AZs. +To mitigate the impact of an Availability Zone failure in a node-based cluster, locate your nodes in as many Availability Zones as possible. In the unlikely event of an AZ failure, you will lose the data cached in that AZ, not the data cached in the other AZs. @@ -73 +73 @@ When running a Valkey or Redis OSS engine, you have the following options for mi -Serverless caches automatically mitigate node failures with a Multi-AZ architecture so that node failures are transparent to your application. Self-designed clusters must be configured appropriately to mitigate the failure of an individual node. +Serverless caches automatically mitigate node failures with a Multi-AZ architecture so that node failures are transparent to your application. Node-based clusters must be configured appropriately to mitigate the failure of an individual node. @@ -75 +75 @@ Serverless caches automatically mitigate node failures with a Multi-AZ architect -To mitigate the impact of Valkey or Redis OSS node failures on self-designed clusters, you have the following options: +To mitigate the impact of Valkey or Redis OSS node failures on node-based clusters, you have the following options: @@ -151 +151 @@ Serverless caches automatically mitigate availability zone failures with a repli -To mitigate the impact of an Availability Zone failure in a self-designed cluster, locate your nodes for each shard in as many Availability Zones as possible. +To mitigate the impact of an Availability Zone failure in a node-based cluster, locate your nodes for each shard in as many Availability Zones as possible. @@ -163 +163 @@ For more information on regions and Availability Zones, see [Choosing regions an -We recommend creating serverless caches over self-designed clusters, as you automatically obtain better fault tolerance without additional configuration. When creating a self-designed cluster, however, there are two types of failures you need to plan for: individual node failures and broad Availability Zone failures. The best failure mitigation plan will address both kinds of failures. +We recommend creating serverless caches over node-based clusters, as you automatically obtain better fault tolerance without additional configuration. When creating a node-based cluster, however, there are two types of failures you need to plan for: individual node failures and broad Availability Zone failures. The best failure mitigation plan will address both kinds of failures. @@ -169 +169 @@ To minimize the impact of a node failure when using Valkey or Redis OSS, we reco -For self-designed clusters on Valkey or Redis OSS, we recommend that you enable Multi-AZ on your replication group so that ElastiCache will automatically fail over to a replica if the primary node fails. +For node-based clusters on Valkey or Redis OSS, we recommend that you enable Multi-AZ on your replication group so that ElastiCache will automatically fail over to a replica if the primary node fails.