AWS AmazonElastiCache documentation change
Summary
Clarified TLS migration process details, updated DNS record terminology, and emphasized not hardcoding endpoints
Security assessment
Changes focus on TLS encryption migration best practices but do not indicate a specific security vulnerability being addressed. The updates improve documentation around security-related TLS configuration.
Diff
diff --git a/AmazonElastiCache/latest/dg/enable-python-best-practices.md b/AmazonElastiCache/latest/dg/enable-python-best-practices.md index 5053e1a34..5f84b61ad 100644 --- a//AmazonElastiCache/latest/dg/enable-python-best-practices.md +++ b//AmazonElastiCache/latest/dg/enable-python-best-practices.md @@ -15 +15 @@ We are changing and deleting old endpoints during this process. Incorrect usage -While the cluster is being migrated from no-TLS to TLS-preferred, the old per-node DNS records are kept and the new per-node DNS records are being generated in a different format. TLS-enabled clusters use a different format of DNS records than non-TLS-enabled clusters. ElastiCache will keep both DNS records when a cluster is configured in encryption mode: Preferred so that Applications and other Valkey or Redis OSS clients can switch between them. The following changes in the DNS records take place during the TLS-migration process: +While the cluster is being migrated from no-TLS to TLS-preferred, the old cluster configuration endpoint DNS record is kept and the new cluster configuration endpoint DNS records are being generated in a different format. TLS-enabled clusters use a different format of DNS records than TLS-disabled clusters. ElastiCache will keep both DNS records when a cluster is configured in `encryption mode: Preferred` so that Applications and other Valkey or Redis OSS clients can switch between them. The following changes in the DNS records take place during the TLS-migration process: @@ -23 +23 @@ When a cluster is set to ‘transit encryption mode: preferred’: - * The original cluster endpoints for non-TLS enabled cluster will remain active. There will be no downtime when cluster is re-configured form TLS encryption mode ‘none’ to ‘preferred’. + * The original cluster configuration endpoint for no-TLS cluster will remain active. There will be no downtime when cluster is re-configured form TLS encryption mode ‘none’ to ‘preferred’. @@ -67 +67 @@ When replication group is set to ‘transit encryption mode: required’: - * Use the cluster configuration endpoint instead of per-node DNS records in your application’s code. Using per-node DNS names directly is not recommended because they might change when adding or removing shards. + * Use the cluster configuration endpoint instead of per-node DNS records in your application’s code. Using per-node DNS names directly is not recommended because during migration they will change and the application code will break connection to the cluster. @@ -69 +69 @@ When replication group is set to ‘transit encryption mode: required’: - * Don't hardcode cluster configuration endpoint in your application as it will change during this process. + * Don't hardcode a cluster configuration endpoint in your application, as it will change during this process. @@ -71 +71 @@ When replication group is set to ‘transit encryption mode: required’: - * Having the cluster configuration endpoint hardcoded in your application is a bad practice since it can be changed during this process. After the in-transit encryption is completed, query the cluster configuration endpoint with the `describe-replication-group` API (as demonstrated above (in bold)) and use the DNS you get in response from this point on. + * Having the cluster configuration endpoint hardcoded in your application is a bad practice, since it can be changed during this process. After the in-transit encryption is completed, query the cluster configuration endpoint with the `describe-replication-group` API (as demonstrated above (in bold)) and use the DNS you get in response from that point on.