Hello and welcome to this lecture covering the encryption options available for Amazon ElastiCache.

Amazon ElastiCache is a service that makes it easy to deploy, operate, and scale open-source, in-memory data stores in the cloud. This service improves the performance through caching, where web applications allow you to retrieve information from fast managed in-memory data stores instead of relying entirely on slower disk-based solutions.

ElastiCache supports both Memcached and the Redis engines, so existing applications can be easily moved to ElastiCache. But what is Memcached and Redis and what are the key differences between each cache engine?

Amazon ElastiCache for Memcached is a high-performance sub-millisecond latency Memcached-compatible in-memory key store service that can either be used as a cache in addition to a data store. 

Amazon ElastiCache for Redis is purely an in-memory data store designed for high performance and again providing sub-millisecond latency on a huge scale to real-time applications.

For more information on Amazon ElastiCache, take a look at our existing course here: https://cloudacademy.com/course/database-fundamentals-part-one-1064/amazon-elasticache/

At the time of writing this course, ElastiCache for Memcached does NOT support encryption, however, Redis does, so let me take a look at the encryption available for the Redis engine. 

The encryption options available to you depend on the version of Redis that you are running. For both encryption at rest and in transit you will need to ensure your cluster or replication group are running at least Redis 3.2.6, 4.0.10, or later.  

From an in-transit encryption perspective, your data is protected each time it moves between nodes in your cluster or between your application and your cluster.  When it comes to encryption at-rest, ElastiCache encrypts your data-on-disk, and during both sync and backup operations on your replication groups.

As you can see, encryption at-rest can be disabled or enabled via the tick box during the creation of your ElastiCache cluster.  If enabled, you have the option of accepting the default encryption key (AWS managed keys), or you can select a customer-managed CMK and supply the ARN of the key.  

You can also see from this image that you can also implement Encryption in-transit via a tick-box as well.  When enabled, you are able to protect your data using TLS as it moves between your ElastiCache cluster components, for example between your primary node and a read replica node, in addition to this you also have the following protection benefits:

• Connections to and from the ElastiCache server and client will use SSL to communicate
• Server authentication, allowing your clients to authenticate to the correct server within your cluster
• When using the Redis AUTH feature, clients can be authenticated by the server

Redis AUTH can be selected as an access control option when you activate encryption in-transit and allow authentication via a defined token (password).  If the token is a successful match then the client can run commands against the ElastiCache cluster.  This provides an additional layer of protection. These tokens must comply to specific requirements, such as the following:

• Tokens must be 16–128 printable characters
• Non Alphanumeric characters are restricted to (!, &, #, $, ^, <, >, -)

An alternative to using Redis AUTH which gives all users the same permissions if the Token provided is a match, you can use the ‘User Group Access Control List’ as the Access Control Option. This allows you to authenticate users on a Role Based Access Control method (RBAC).

Using RBAC allows you to create different groups, each containing different users.  Each group is created to segregate levels of permissions, usually, this relates to a job role. The group is granted different permissions based on an access string, and this allows you to enforce different levels of security across your ElastiCache deployments for different users.