Amazon ElastiCache for Redis Tutorial: Create a Cluster and Connect from EC2

Amazon ElastiCache for Redis is a managed in-memory data store that runs inside your VPC. Applications connect to a DNS primary endpoint on port 6379 (unless you change it) instead of installing and patching Redis on EC2.

AWS now offers both Redis OSS and Valkey in ElastiCache. This tutorial uses Redis OSS because the search intent is specifically Redis, but the basic VPC and security-group connection pattern is similar for Valkey.

In this guide, we'll use the AWS Management Console to create a cache subnet group, security groups, and a small Redis OSS cache named demo-redis. A Linux EC2 instance in the same VPC then runs valkey-cli to confirm PING, SET, and GET. At the protocol level, applications still use a Redis-compatible client when you move from a self-hosted cache such as install Redis on Ubuntu; the hostname, TLS and auth settings, and cluster behavior depend on your ElastiCache configuration.

Key takeaways

• ElastiCache node-based caches are reached through VPC networking, not by exposing the cache on the public internet. Create a cache subnet group with subnets in multiple Availability Zones so ElastiCache has placement options; that layout is the normal setup if you add replicas or Multi-AZ later.
• The console shows a primary endpoint hostname on the cache details page. Use that value in application Redis clients.
• In ElastiCache, AWS may label the resource a cache or cluster even when this tutorial uses only one primary node with cluster mode disabled and zero replicas. That single-node layout has no replica and no automatic failover—do not treat it as a production high-availability design.
• Production designs often add replicas, Multi-AZ, or cluster mode enabled for scale and resilience.
• ElastiCache also supports Memcached and Valkey; this page focuses on Redis OSS.
• Billing includes cache node hours and optional backup storage. Delete tutorial resources when finished.

ElastiCache engines at a glance

Redis clients that talk to a local Redis server usually work with ElastiCache when networking and security groups are correct.

           EC2 client (same VPC)
                     ↓
              TCP port 6379
                     ↓
           EC2 client security group
                     ↓
      allowed as inbound source on
                     ↓
           Redis cache security group
                     ↓
        ElastiCache primary endpoint
                     ↓
           In-memory keys (demo:key)

What you need

Provisioning can take several minutes. Charges apply for cache nodes and the EC2 client until you delete them.

Step 1: Create a cache subnet group

In the AWS console, open ElastiCache → Subnet groups → Create subnet group. Point the group at your VPC and select subnets in multiple Availability Zones (for example one subnet in ap-south-1a and one in ap-south-1b).

Choose Create and confirm the new group appears under Subnet groups.

Step 2: Restrict Redis with security groups

Open VPC → Security groups in the same Region. Create two groups in the cache VPC (names below are examples):

• EC2 client security group (demo-redis-ec2-sg) — allow SSH (port 22) from your admin IP if you use SSH, or rely on EC2 Instance Connect / Session Manager without opening SSH to the world.
• Redis security group (demo-redis-sg) — allow TCP 6379 with source type Security group and select the EC2 client group—not 0.0.0.0/0.

Using the EC2 security group as the source means any instance with that client security group can reach Redis, even if its private IP changes. You do not have to hard-code an EC2 IP address.

ElastiCache is designed to be reached through VPC networking. For this tutorial, the EC2 client and cache are in the same VPC, and the cache security group allows port 6379 only from the EC2 client's security group. Other valid patterns include an EC2 client in a peered VPC or on-premises hosts connected with VPN or Direct Connect, as long as routing and security groups permit the connection.

Step 3: Create the Redis cache

Open ElastiCache → Redis caches → Create Redis cache. For this first example, choose Design your own cache with Cluster mode disabled, then match the settings in the table.

On Network settings (or the connectivity step in the wizard), attach the subnet group and Redis security group from the earlier steps. This tutorial disables in-transit encryption only to keep the first connectivity test simple. For production workloads, evaluate TLS and authentication based on your security requirements.

Choose Create. The Redis caches list shows Creating while AWS provisions nodes. Refresh until the status is Available. Provisioning can take several minutes.

Step 4: Copy the primary endpoint

Open the cache name to view details. Under Connectivity, copy the Primary endpoint hostname and note port 6379.

Paste the hostname into a notepad or your application configuration. The Region code appears inside the DNS name (for example aps1 for ap-south-1).

Step 5: Launch a Linux EC2 client in the same VPC

Open EC2 → Instances → Launch instances. Use the same VPC as the cache subnet group and attach the EC2 client security group from Step 2.

After the instance is Running, connect with EC2 Instance Connect, Session Manager, or SSH.

Step 6: Test Redis with valkey-cli

On the EC2 instance, install a Redis-compatible client. On RHEL 10, valkey-cli speaks the Redis protocol:

sudo dnf install -y valkey

Set the endpoint from Step 4 (replace with your primary endpoint hostname):

export REDIS_HOST=demo-redis.abc123.ng.0001.aps1.cache.amazonaws.com
export REDIS_PORT=6379

Send a PING to confirm connectivity:

valkey-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" PING

Sample output:

PONG

Write and read a test key:

valkey-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" SET demo:key "hello-from-elasticache"

SET returns OK when the command succeeds.

Read the value back:

valkey-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" GET demo:key

Sample output:

hello-from-elasticache

If PING times out, return to the console and confirm the Redis security group allows port 6379 from the client instance security group and that both resources share the VPC.

Clean up

In the console, delete resources in this order to avoid dependency errors:

1. ElastiCache → Redis caches — select demo-redis and delete the cache.
2. EC2 → Instances — terminate the client instance.
3. ElastiCache → Subnet groups — delete demo-redis-subnets after the cache is gone.
4. VPC → Security groups — delete demo-redis-sg and demo-redis-ec2-sg when nothing references them.

Troubleshooting

Summary

Amazon ElastiCache for Redis hosts Redis-compatible engines in your VPC so applications get a managed primary endpoint instead of self-managed cache servers. The console steps built a cache subnet group, restricted port 6379 to the EC2 client security group, created demo-redis on a small node type, and copied the primary endpoint before testing from EC2 with valkey-cli.

Most first-connection failures come from VPC or security group mismatch, not from Redis itself. For production, plan replicas, backups, and encryption before you depend on a single-node cache.

For a managed relational store in the same AWS portfolio, compare with the AWS RDS tutorial.

References

• What is Amazon ElastiCache?
• Creating a Redis cluster
• ElastiCache subnet groups
• Amazon ElastiCache pricing