6.72 ElastiCache LAB AWS

In this lab we create our first ElastiCache cluster from the AWS console. After searching for ElastiCache in the search bar, we open the dedicated menu. The console lets you create either a Redis-based or a Memcached-based cluster from the same interface. Here we pick Redis without enabling cluster mode and we keep most defaults. We name the cluster (for example mon-redis) with a short description, keep the latest engine version, leave the default port 6379 and the default parameter group.

For the node type, we deliberately avoid the expensive cache.r4.large family, which is overkill for a demo, and instead pick cache.t2.micro with about 0.5 GB of RAM and low-to-moderate network performance. We set the number of replicas to zero: Multi-AZ is not available with a single node, but spinning up a full cluster right now is not necessary and would cost more for nothing. We then define a subnet group called mon-reseau-redis based on the default VPC and choose the Availability Zones — either explicitly or by letting AWS pick.

Security, backups and creation

  • Encryption: at rest with the default key, in transit, or both. With encryption in transit you can set an auth password so applications authenticate before talking to Redis.
  • Import: optionally seed the cluster from an S3 location.
  • Backups: define retention days and a backup window — this option is not available for Memcached, which does not support backups.
  • Maintenance window: leave at default; notifications can be added later via another module.

Once the cluster is created (single-node setup, which is by definition not really a cluster), we click into it to see the connection endpoints and configuration details. Real testing happens at the application level: you would build an app that talks to Redis, which is more involved than this lab needs. What matters here is knowing how to provision a Redis ElastiCache cluster on demand at the request of a manager. Creating a Memcached cluster follows the same path with a few differences — no backup options — that we already covered earlier. That wraps up the section on ElastiCache cluster creation.

Summary

This lab demonstrates how to create an ElastiCache cluster using AWS Console, selecting Redis as the caching technology. The instructor walks through configuring essential parameters including instance type (t2.micro), enabling encryption in transit, setting passwords for security, and defining replica counts and availability zones. The lab focuses on the cluster setup process rather than application-level testing, as full integration testing would require developing a client application that interacts with Redis.

Key points

  • Access ElastiCache via AWS Console search and choose between Redis or Memcached technologies for cluster creation
  • Configure instance specifications: select appropriate node type (t2.micro for lab), set version to latest Redis, and define port (6379 standard)
  • Enable encryption in transit and set authentication passwords to secure cluster communication between client applications and the cache
  • Define subnet groups, availability zones, backup retention policies, and maintenance windows during cluster setup
  • Understand that Redis supports snapshots/backups while Memcached does not, and replicas enable multi-AZ deployment for higher availability

FAQ

What are the key differences between Redis and Memcached in AWS ElastiCache?

Redis supports data persistence with snapshots and backup retention, while Memcached is in-memory only without persistence. Redis also allows multiple replicas across availability zones, whereas Memcached has different scaling characteristics. The choice depends on whether you need durability and replication features for your caching layer.

Why should we enable encryption for ElastiCache clusters?

Encryption in transit protects data flowing between your application and the cache server. In production, you should also require password authentication (AUTH) so that only authorized clients can connect to the cluster, preventing unauthorized access to cached data.

How do you test if the ElastiCache cluster is working correctly?

Testing requires an application client that connects to the Redis cluster using its endpoint and credentials. The lab focuses on infrastructure setup; actual validation involves writing application code that stores and retrieves data from the cache to verify connectivity and performance.