Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 163 discussion

Encryption in transit cannot be enabled on an existing ElastiCache cluster. A new cluster must be created.

Amazon ElastiCache for Redis now supports updates to encryption in transit on existing cluster resources. You can change the TLS configuration of your Redis clusters without re-building or re-provisioning them or impacting application availability. When enabling encryption in transit, your overall solution can remain connected to Redis clusters. To get started, upgrade your Redis cluster to version 7 or above. You can then modify the encryption-in-transit property for your cluster using the Elasticache Console, API or CLI. This feature is available in all regions at no additional cost. To learn more, see the ElastiCache user guide.

The correct answer is A - Create an AUTH token, store it in Parameter Store, and create a new cluster with AUTH and in-transit encryption. Key reasons: ElastiCache doesn't allow enabling AUTH on existing clusters SSL certificates aren't used for Redis authentication Parameter Store is more cost-effective than Secrets Manager for this case Solution meets both requirements: AUTH authentication and end-to-end encryption

A or B? Option B is suggesting to update the cluster which is not feasible. Once a cluster is created without encryption in transit, it cannot be modified to enable encryption in transit.

Enabling encryption in transit on an existing ElastiCache cluster that wasn’t originally configured with this feature is not possible. Encryption in transit, as well as encryption at rest, can only be specified at the time the cluster is created. AWS Documentation on Encryption in Transit: According to AWS ElastiCache documentation, if you want to enable encryption in transit, you must set this option when creating the ElastiCache cluster. Once a cluster is created without encryption in transit, it cannot be modified to enable this feature later. The same applies to Redis AUTH. Thus, if a Redis cluster was deployed without encryption in transit, the only way to enable it is to create a new ElastiCache cluster with this setting enabled. Then, the data would need to be migrated from the existing cluster to the new one.

B=Better :-)

It seems to configure in-transit encryption in both new cluster and existing cluster, but updating is supported on Redis version 7 and later. So I will choose option A. https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/in-transit-encryption.html#in-transit-encryption-constraints

A or B? I didn't read any comparison between these 2 options... For sure we need an auth token. Both, using SSM Parameter Store or Secrets Manager will work. Both, create a new cluster or update the current one will work. I will choose B because this approach avoids the need to set up a new cluster, potentially reducing effort and costs associated with migration or duplication of resources...

Option B

Option B

B, per redis docs. EC encr in transit is a config option

b-b-b-b-b-b-b Creating an AUTH token provides a form of authentication for accessing the ElastiCache cluster. Storing the AUTH token in AWS Secrets Manager ensures secure and centralized management of the token. Configuring the existing ElastiCache cluster to use the AUTH token enables authentication for accessing the cache. Enabling encryption in transit ensures that data is encrypted when it is transferred between the client and the ElastiCache cluster. Updating the application to retrieve the AUTH token from Secrets Manager and use it for authentication ensures that only authorized users can access the cache.

Create an AUTH token. Store the token in AWS Secrets Manager.

Redis CLI has AUTH command as a feature to SET/ROTATE strategies https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html

B seems right. To enable authentication on an existing Redis server, call the ModifyReplicationGroup API operation. Call ModifyReplicationGroup with the --auth-token parameter as the new token and the --auth-token-update-strategy with the value ROTATE. After the modification is complete, the cluster supports the AUTH token specified in the auth-token parameter in addition to supporting connecting without authentication. Enabling authentication is only supported on Redis servers with encryption in transit (TLS) enabled. https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html

As per https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/in-transit-encryption.html

You have to create a new cluster, otherwise the the cluster supports the AUTH token specified and supports connecting without authentication.