ElastiCache Cluster Modes and Failover

Build multi-region ElastiCache architectures with failover and Global Datastore.

Introduction

30 Second Summary

Imagine your app stores frequently used data (like user sessions or product prices) in a super-fast temporary memory called a cache. If that cache suddenly crashes at 2 AM, your app either switches to a backup copy or goes completely offline. The setup you choose ahead of time decides which outcome you get.

In this project, you will build four different ElastiCache setups (AWS's managed caching service), break them on purpose, add capacity while they're running, and see firsthand how each one behaves. By the end, you'll know exactly which setup to pick for any caching question on the SAA-C03 exam.

What You'll Build

Picture yourself on exam day, reading a caching question, and instantly knowing the answer because you already built each option in your own AWS account and saw exactly how it behaves when things go wrong.

By the end of this project, you'll have:

A Valkey cache with backup copies that you crash on purpose, then watch it automatically recover in seconds by promoting a backup to take over (this is called Multi-AZ failover).
A cluster mode enabled setup where you split your data across multiple groups (called shards), then add a new group to a live cluster and watch data spread itself out automatically with zero downtime.
A side-by-side Valkey vs Memcached comparison where you run the same operations on both engines and see Memcached fail at things Valkey handles easily. This locks in the exam rule for choosing between them.
Secret Mission: Check real performance metrics from your running clusters using CloudWatch and figure out if you're paying for more capacity than you need.

Are there any prerequisites?

This project builds on Project 1 (where you created a basic ElastiCache Valkey cluster with a database). You need your EC2 instance (a virtual computer in AWS) from Project 1 still running, with Python and the redis-py library installed. You'll also reuse the VPC subnet group (the network setup) from Project 1.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters.

This project builds four distinct ElastiCache architecture patterns that the SAA-C03 exam tests. Understanding when to choose each one is what separates a guess from a confident answer.

Create a Cluster Mode Disabled Replication Group with Multi-AZ

To test how ElastiCache handles a crash, you first need a cache that has backup copies ready to take over. Think of it like having understudies in a play. If the lead actor (the primary node) gets sick, an understudy (a replica) steps in immediately.

In this step, you will create a "cluster mode disabled" cache (meaning all your data lives in one group) with 1 main node and 2 backup copies spread across different data centers (called Availability Zones). You're using cache.m5.large nodes (a medium-sized server type) because a later step requires this size or bigger.

In this step, get ready to:

Create a Valkey cache with 1 main node and 2 backup copies, spread across different data centers for safety.
Start a second cache (with data splitting enabled) in the background to save time later.
Verify your first cache is ready and look at its connection addresses.

Create the CMD Valkey cluster

A "cluster mode disabled" cache keeps all your data in one group. There's one main node that handles all writes (saving data), and up to 5 backup copies (replicas) that keep copies of everything for safety and to handle read requests.

Sign in to the AWS Management Console and open the ElastiCache console at https://console.aws.amazon.com/elasticache/.
Confirm you are in the same region you used in Project 1 (check the region selector in the upper-right corner).
Choose Valkey cache from the left navigation, then click Create Valkey cache.
Under Cluster settings, choose Configure and create a new cluster.
Set Cluster mode to Disabled.
For Name, enter saa-cmd-cluster.
For Engine version, select 7.2 (Valkey).
For Node type, click the dropdown and choose cache.m5.large from the M5 instance family.

Why cache.m5.large instead of a smaller, cheaper size?

In Step 5, you'll set up Global Datastore (which copies your cache to another region). That feature only works with certain server sizes (M5, M6g, R5, etc.) at size "large" or bigger. If you used a tiny server like cache.t3.micro now, you'd have to delete everything and start over later.

Set Number of replicas to 2.
Ensure Multi-AZ is Enabled (it should be on by default when replicas are present).
Ensure Auto-failover is Enabled.
Under Connectivity, for Subnet groups, select the subnet group you created in Project 1.
Under Encryption in transit, check the box to enable it.
Leave all other settings at their defaults and click Create.

The cluster status changes to "Creating." Provisioning takes approximately 8 minutes.

Don't see your subnet group in the dropdown?

Make sure you are in the same region where you created the subnet group in Project 1. Subnet groups are region-specific and will not appear in a different region's console.

help me find my ElastiCache subnet group from Project 1

Start the CME cluster in parallel

While your first cache is being created (it takes about 8 minutes), you can save time by starting the second cache that splits data across multiple groups. This one runs in the background while you wait.

Open a new browser tab and navigate to the ElastiCache console.
Choose Valkey cache, then click Create Valkey cache.
Choose Configure and create a new cluster.
Set Cluster mode to Enabled.
For Name, enter saa-cme-cluster.
For Engine version, select 7.2 (Valkey).
For Node type, choose cache.t3.micro.
Set Number of shards to 2.

What are shards?

Think of shards like filing cabinets. Instead of stuffing all your data into one cabinet (one group), you split it across multiple cabinets. Each cabinet (shard) has its own main copy and backups. This means more cabinets = more space and faster writes, because multiple cabinets can accept new data at the same time.

Set Replicas per shard to 1.
Ensure Multi-AZ is Enabled.
Under Connectivity, select the same subnet group from Project 1.
Leave other settings at defaults and click Create.

This CME cluster will continue provisioning in the background. You will use it in Step 3.

Why use a tiny server for this second cache?

This second cache doesn't need to support Global Datastore (that's only for the first cache). So you can use the smallest, cheapest server type (cache.t3.micro) to keep your AWS bill low.

Verify the CMD cluster and examine its endpoints

Return to your first browser tab where the CMD cluster is being created. You need to wait for it to become available before moving on.

In the ElastiCache console, click on saa-cmd-cluster to open its details page.
Wait until the Status changes from "Creating" to "Available." This typically takes about 8 minutes.

Before you check the details, think about this: you created 1 main node and 2 backups with Multi-AZ turned on. Multi-AZ means AWS spreads your nodes across different data centers. How do you think the 3 nodes will be distributed?

Once available, look at the Nodes tab. You should see 3 nodes total: 1 primary and 2 replicas.
Check the Availability Zone column. The nodes are distributed across different AZs for fault tolerance.
Note which node is currently the primary. Record its AZ. You will need this in Step 2 when you trigger failover.
Find the Primary Endpoint in the cluster details. This is a single DNS name that always points to the current primary node for writes.
Find the Reader Endpoint. This endpoint distributes read traffic across all replicas.

Why are there two separate connection addresses?

The Primary Endpoint is like a phone number that always reaches the current boss node. If the boss changes (after a failover), the phone number stays the same but now connects to the new boss. Your app never needs to update its settings.

The Reader Endpoint spreads read requests across all backup copies so no single backup gets overloaded. Your app uses one address for writing data and a different address for reading data. This separation is a key concept tested on the SAA-C03 exam.

Confirm that Multi-AZ shows Enabled in the cluster details. Your cache is now live with automatic failover ready to kick in. In the next step, you'll intentionally break it and watch the magic happen.

Cluster stuck in Creating status for over 15 minutes?

Check the Events tab in the left navigation panel for any error messages. The most common cause is a subnet group with insufficient IP addresses in its CIDR range. If you see a subnet-related error, you may need to add a larger subnet to your subnet group.

help me troubleshoot my ElastiCache cluster stuck in Creating status

Your first cache is live and your second cache (the one that splits data) is being created in the background. Next up, you'll trigger a failover on this first cache and watch ElastiCache automatically promote a backup copy to become the new main node.

Test Automatic Failover and Observe Replica Promotion

Your cache is now running with a main node and two backup copies spread across different data centers. You turned on automatic failover, but you've never actually seen it work.

In this step, you will simulate a crash and watch ElastiCache automatically promote a backup to become the new main node within seconds. This proves the key difference: Valkey can recover automatically within a region, Memcached cannot recover at all, and Global Datastore (cross-region) requires you to manually switch over.

In this step, get ready to:

Trigger a test failover (simulate a crash) and watch the events that happen.
Verify that the main node role moved to a different backup in a different data center.
Connect from your EC2 instance and prove the cache still works after the switch.

Trigger the test failover and watch events

ElastiCache has a built-in "test failover" button that simulates a main node crash without actually breaking anything. Your cache stays online the entire time. It's like a fire drill for your cache.

In the ElastiCache console, navigate to Valkey in the left navigation pane.
Click the cluster name saa-cmd-cluster to open its details.
Select the Nodes tab.
Click Failover Primary.
In the confirmation dialog, click Continue.

The console status remains "Available" during the failover process.

In the left navigation pane, click Events.
Watch for the following events in order:

Test Failover API called for node group 0001 (replication group message).
Failover from primary node to replica node completed (cache cluster message).
Finished recovery for cache nodes (cache cluster message).

Why does it say node group 0001?

A "cluster mode disabled" cache only has one group of data (one shard). That single group is always numbered 0001. If you had cluster mode enabled, you'd see multiple groups (0001, 0002, etc.). For now, just know that 0001 is your only group.

🙋‍♀️ Not seeing events appear?

Events can take 30-60 seconds to appear. Refresh the Events page if nothing shows up immediately. If the Failover Primary button was greyed out, confirm that Multi-AZ is enabled on the cluster.

help me troubleshoot why my ElastiCache test failover isn't showing events

Observe replica promotion and endpoint behaviour

After the recovery events appear (about 1-2 minutes), a backup copy has been promoted to become the new main node. The old main node is now just a backup.

Return to saa-cmd-cluster by clicking its name in the cluster list.
Select the Nodes tab.
Observe that the primary role has moved to a different node in a different AZ than the one you recorded in Step 1.
Confirm the old primary is now listed as a replica.

Here's the important thing: the Primary Endpoint address did not change. It's the same address as before, but now it automatically points to the new main node. Your app doesn't need to change anything.

What is async replication and why does it matter?

ElastiCache copies data from the main node to backups with a tiny delay (asynchronously). This means if the main node crashes, any writes from the last fraction of a second that hadn't been copied yet are lost forever.

Compare this to RDS databases (Multi-AZ), which copy data instantly (synchronously) so nothing is ever lost. ElastiCache trades a small risk of data loss for faster write speed. This trade-off is tested on the exam.

Verify cluster health from EC2

The console shows the failover succeeded, but the real proof is connecting to the cache and confirming it still accepts writes and reads using the same address as before.

SSH into your EC2 instance from Project 1.

Before you run this command, make a prediction: do you think the cache will accept writes using the same Primary Endpoint address you noted earlier, even though the main node physically changed to a different server?

Verify the cluster is serving traffic post-failover by running this command:

python3 -c "import redis; r = redis.Redis(host='[[CMD_PRIMARY_ENDPOINT="your CMD cluster primary endpoint"]]', port=6379, ssl=True); r.set('failover-test', 'survived'); print(r.get('failover-test'))"

What does this command do?

This one-liner connects to your cache using the same Primary Endpoint address from Step 1. It saves a piece of data (the key failover-test with value survived), then immediately reads it back.

If you see b'survived' printed, it proves the cache is working perfectly through the same address, even though the main node is now a completely different server in a different data center.

You should see b'survived' printed in your terminal. This confirms the connection address automatically pointed to the new main node and your cache is healthy.

Seeing a connection error?

If you see a timeout or connection refused error, the DNS may not have propagated yet. Wait 30 seconds and try again.

Make sure your EC2 instance's security group allows outbound traffic on port 6379 to the ElastiCache subnet. This should already be configured from Project 1.

help me debug my EC2 connection to ElastiCache after a failover test

You just proved that ElastiCache automatically promotes a backup to become the new main node and updates the connection address without any changes to your app. Next up, you'll scale your second cache by adding a new data group (shard) and watching data spread itself out in real time.

Create Cluster Mode Enabled and Scale Shards Dynamically

Your CMD cluster just survived a primary node failure and automatically promoted a replica. That proves ElastiCache handles intra-region failover without manual intervention.

However, CMD is limited to a single shard. If write throughput exceeds what one primary can handle, or your dataset outgrows a single node's memory, you need data partitioning. Cluster Mode Enabled (CME) distributes data across multiple shards, each with its own primary. In this step, you will examine the CME cluster you provisioned earlier and scale it from 2 shards to 3 with zero downtime.

In this step, get ready to:

Examine the CME cluster's Configuration Endpoint and shard structure.
Scale the CME cluster from 2 to 3 shards via online resharding.
Verify hash slot distribution and understand the CMD vs CME decision framework.

Examine the CME cluster details

CMD clusters expose a single Primary Endpoint for writes and a Reader Endpoint for reads. CME clusters work differently. They expose a Configuration Endpoint that lets clients automatically discover all shards without needing to know their individual addresses.

In the ElastiCache console, choose Valkey clusters in the left navigation pane.
Click the name saa-cme-cluster (not the checkbox to its left).
On the cluster details page, locate the Configuration endpoint field. Copy this value and save it somewhere you can reference later.
Scroll down to the shards list. You should see 2 shards, each with its own primary node and 1 replica.

What is the Configuration Endpoint?

In a CME cluster, data is partitioned across shards using hash slots (0-16383 divided among shards). The Configuration Endpoint is a single DNS address that lets clients discover all shards automatically. Clients connect once to this endpoint and receive a slot map telling them which shard owns which hash slot range.

This is different from CMD, which has a Primary Endpoint (for writes) and a Reader Endpoint (for reads) pointing at one shard.

You should see each shard has a slot range assigned. With 2 shards, the slots are split roughly in half (e.g., 0-8191 and 8192-16383). Each shard has its own primary that accepts writes for its slot range.

Scale from 2 to 3 shards via online resharding

Online resharding lets you add or remove shards while the cluster continues serving requests. ElastiCache redistributes hash slots across the new shard count with zero downtime.

On the saa-cme-cluster details page, click Add shard.
For Number of shards to be added, enter 1.
For Availability zone(s), choose No preference.
Click Add.

The cluster status remains Available during resharding. ElastiCache is moving hash slots to the new shard in the background. This operation takes 2-5 minutes.

What happens during online resharding?

ElastiCache takes the 16384 hash slots that were split across 2 shards and redistributes them across 3 shards. It migrates keys from existing shards to the new shard one slot range at a time. Your cluster continues accepting reads and writes throughout this process.

🙋‍♀️ Don't see the Add shard button?

Make sure you clicked the cluster name (the link text), not the checkbox beside it. The Add shard option only appears on the cluster detail page.

If the button is greyed out, the cluster may still be in a modifying state from a previous operation. Wait for the status to return to Available.

Help me troubleshoot the Add shard button in ElastiCache.

Verify 3 shards and understand the CMD vs CME decision framework

Before you check the result, predict what the hash slot distribution will look like across 3 shards. If the total range is 0-16383, how would ElastiCache divide them evenly?

Wait for the resharding operation to complete (the cluster status returns to Available).
Click on saa-cme-cluster and scroll to the shards section.
Confirm you now see 3 shards listed, each with its own primary and 1 replica.
Note the hash slot ranges. They should be distributed roughly as: 0-5461, 5462-10922, 10923-16383.

You now have 3 shards, each owning approximately one-third of the hash slot space. Each shard has its own primary that accepts writes for its range.

When do you use CMD vs CME?

Use CMD when your workload is read-heavy. You scale CMD by adding replicas (up to 5) to handle more read traffic. All writes still go to a single primary.

Use CME when your workload is write-heavy or your dataset exceeds a single node's memory. You scale CME by adding shards (up to 500), each with its own write-capable primary. Data is partitioned across shards automatically.

Cluster mode can only change from disabled to enabled. You cannot go back from CME to CMD.

Your CME cluster is now running 3 shards with evenly distributed hash slots and zero downtime during the scaling operation. Next up, you will compare Valkey and Memcached side by side to see firsthand why Valkey wins for almost every SAA-C03 scenario.

Compare Valkey vs Memcached Engines

You have seen how Valkey handles replication, automatic failover, and shard scaling across the previous steps. Now a natural question surfaces: when would you choose Memcached instead?

The SAA-C03 exam tests whether you can identify the right engine for a scenario. In this step, you create a Memcached cluster and run the same operations on both engines side by side. The gap between them will be impossible to miss.

In this step, get ready to:

Create a Memcached cluster and observe what options are missing from the creation form.
Run a comparison script that exercises sorted sets, hashes, and pub/sub on both engines.
Confirm the architectural gaps in the console side by side.

Create a Memcached cluster

The Memcached engine uses a completely different API path than Valkey. You will notice several options that existed for your Valkey clusters are simply absent from the Memcached creation form.

In the ElastiCache console left navigation, choose Memcached Caches.
Click Create Memcached cache.
Under Cluster info, enter saa-memcached as the Name.
For Engine version, select 1.6.22.
For Node type, choose cache.t3.micro.
Set Number of nodes to 2.
Under Subnet group settings, select the same subnet group from Project 1.
Click Create.

What is missing from this form?

Look at what is NOT on the Memcached creation screen. There is no replication option. There is no Multi-AZ option. There is no backup/restore option. There is no auto-failover setting.

These features are structurally absent from the Memcached engine. If a node dies, its data is gone permanently.

The cluster takes a few minutes to provision. While it creates, move on to setting up the comparison script on your EC2 instance.

Install pymemcache and write the Valkey demonstration

Your EC2 instance already has redis-py installed from Project 1. You need pymemcache to talk to the Memcached cluster.

SSH into your EC2 instance and install pymemcache by running:

pip install pymemcache

You should see a success message confirming the package installed.

Install command not found?

If pip is not recognized, try pip3 instead.
Confirm your EC2 instance still has the Python environment from Project 1 intact.

Help me fix my pip install issue on EC2

Create the comparison script by running:

touch engine_comparison.py

Confirm the file exists by running:

ls

You should see engine_comparison.py in the output.

Open engine_comparison.py in your editor and add the following code that demonstrates Valkey's complex data types:

import redis
from pymemcache.client.base import Client as MemcacheClient

# --- Valkey (CMD cluster) demonstration ---
print("=" * 60)
print("VALKEY - Complex Data Types & Features")
print("=" * 60)

valkey = redis.Redis(
    host="your-cmd-primary-endpoint-here",
    port=6379,
    ssl=True,
    decode_responses=True
)

# Sorted Sets (leaderboard pattern)
valkey.zadd("leaderboard", {"alice": 100, "bob": 85, "charlie": 92})
top_players = valkey.zrevrange("leaderboard", 0, 2, withscores=True)
print(f"Sorted Set (leaderboard): {top_players}")

# Hashes (object storage)
valkey.hset("user:1001", mapping={"name": "Alice", "email": "alice@example.com", "score": "100"})
user_data = valkey.hgetall("user:1001")
print(f"Hash (user object): {user_data}")

What does this code do?

Imports both redis and pymemcache so the script can talk to both engines.
Connects to your CMD cluster's primary endpoint with SSL enabled.
Demonstrates sorted sets (ZADD/ZREVRANGE) for a leaderboard pattern where you can rank entries by score.
Demonstrates hashes (HSET/HGETALL) for storing structured objects with individually addressable fields.

Replace your-cmd-primary-endpoint-here with the Primary Endpoint from your saa-cmd-cluster (without the port suffix).
Below the hashes section, add the pub/sub and persistence demonstration:

# Pub/Sub (messaging)
pubsub = valkey.pubsub()
pubsub.subscribe("notifications")
valkey.publish("notifications", "Cache invalidated for product:42")
message = pubsub.get_message(timeout=1)
message = pubsub.get_message(timeout=1)
print(f"Pub/Sub message received: {message}")
pubsub.unsubscribe()

# Persistence proof - data survives node restart
valkey.set("persistent-key", "this-survives-restart")
print(f"Persistence: key set = {valkey.get('persistent-key')}")

print("\n" + "=" * 60)
print("MEMCACHED - Simple Key-Value Only")
print("=" * 60)

memcached = MemcacheClient(
    ("your-memcached-config-endpoint-here", 11211)
)

# Simple GET/SET works
memcached.set("simple-key", "simple-value")
result = memcached.get("simple-key")
print(f"Simple GET/SET: {result}")

What does this section add?

Pub/Sub subscribes to a channel and publishes a message, proving Valkey supports real-time messaging natively.
The persistence proof sets a key that would survive a node restart because Valkey snapshots to disk.
The Memcached section connects to your Memcached cluster on port 11211 and runs a simple GET/SET to confirm basic connectivity works.

Replace your-memcached-config-endpoint-here with the Configuration Endpoint from your saa-memcached cluster (without the port suffix).
Save engine_comparison.py and run the Valkey portion to confirm connectivity by running:

python engine_comparison.py

You should see output showing the sorted set leaderboard with scores, the hash user object with fields, the pub/sub message, and the persistence key. The Memcached simple GET/SET also succeeds.

Connection refused or timeout?

Verify your security group allows inbound on port 6379 (Valkey) and port 11211 (Memcached) from your EC2 instance.
Confirm the saa-memcached cluster status is Available before running the script.
Double-check you pasted the endpoint without the :6379 or :11211 port suffix (the code adds the port separately).

Help me debug this connection error

Run the Memcached comparison and observe the designed obstacle

Valkey handled sorted sets, hashes, pub/sub, and persistence without breaking a sweat. Now the question is: can Memcached do the same?

Before you add the Memcached comparison code, predict what will happen. Do you think Memcached can store a sorted leaderboard, a hash with individually addressable fields, or publish messages to subscribers?

Below the Simple GET/SET section in engine_comparison.py, add the Memcached limitation tests:

# No sorted sets - only strings
try:
    memcached.set("leaderboard", "alice:100,bob:85")
    print(f"Memcached 'leaderboard': {memcached.get('leaderboard')}")
    print("  -> Just a string! No ZADD, no ranking, no range queries")
except Exception as e:
    print(f"Error: {e}")

# No hashes - only flat strings
try:
    memcached.set("user:1001", "name=Alice,email=alice@example.com")
    print(f"Memcached 'user': {memcached.get('user:1001')}")
    print("  -> Just a string! No HGET for individual fields")
except Exception as e:
    print(f"Error: {e}")

# No pub/sub
print("Pub/Sub: NOT AVAILABLE on Memcached")

# No persistence
print("Persistence: NONE - node restart = total data loss")

print("\n" + "=" * 60)
print("SAA-C03 DECISION FRAMEWORK")
print("=" * 60)
print("Choose Memcached ONLY when:")
print("  - Multi-threaded performance needed")
print("  - Simple key-value caching (strings only)")
print("  - No persistence required")
print("  - No replication/failover required")
print("Choose Valkey for EVERYTHING ELSE")

What does this code reveal?

Memcached can only store flat strings. When you try to store a "leaderboard" or a "user object," it is just a plain string with no structure. There is no way to rank, sort, or query individual fields.

Pub/Sub does not exist in Memcached at all. Persistence does not exist either. If a Memcached node restarts, every key it held is permanently lost.

Below the decision framework, add the cleanup section:

# Cleanup
valkey.delete("leaderboard", "user:1001", "persistent-key")
memcached.delete("simple-key")
memcached.delete("user:1001")
memcached.delete("leaderboard")

print("\nDone. All test keys cleaned up.")

Save engine_comparison.py and run the full script:

python engine_comparison.py

The output tells the whole story. Valkey returns structured data from sorted sets and hashes, delivers pub/sub messages, and proves persistence.

Memcached stores everything as flat strings with no ranking, no field access, no messaging, and no durability. This is the designed obstacle the exam tests.

Why this matters for SAA-C03

Most students memorize "Memcached is simpler" without understanding how dramatically different the capabilities are.

The SAA-C03 rule: choose Memcached ONLY when the scenario explicitly mentions multi-threaded performance for simple key-value caching with no persistence requirement. Everything else is Valkey.

🙋‍♀️ Memcached operations raising errors?

If you see a connection error for Memcached only, confirm the cluster status is Available in the console.
Ensure your security group has an inbound rule for port 11211 from your EC2 instance.
If pymemcache raises an import error, confirm pip install pymemcache completed successfully earlier.

Help me figure out if this is a connectivity issue or expected behavior

✔️ Awesome, I've got everything!

Great. Double check you have saved engine_comparison.py and the script ran to completion with the cleanup message at the end.

ⓧ I'd like to double check the full code

Your engine_comparison.py is over 30 lines, so confirm these sections are present in order:

Imports and Valkey connection (import redis through decode_responses=True).
Sorted Sets section (valkey.zadd and valkey.zrevrange).
Hashes section (valkey.hset and valkey.hgetall).
Pub/Sub section (pubsub.subscribe, valkey.publish, pubsub.get_message).
Persistence proof (valkey.set("persistent-key", ...)).
Memcached connection and simple GET/SET.
Memcached limitation tests (sorted sets as strings, hashes as strings, no pub/sub, no persistence).
SAA-C03 Decision Framework print block.
Cleanup section (valkey.delete and memcached.delete calls).

Compare cluster details in the console

The script proved the data-type gap. Now confirm the architectural gap by comparing cluster details in the console.

In the ElastiCache console, click on saa-memcached to view its details.
Note what the Memcached details page shows: only a configuration endpoint with auto-discovery, 2 nodes, no replication, no Multi-AZ, no backups.
Switch to Valkey Caches in the left navigation and click saa-cmd-cluster.
Compare: Valkey shows Multi-AZ enabled, automatic failover, backup/restore available, replication with 2 replicas.

SAA-C03 engine selection rule

Memcached is multi-threaded but has no replication, no failover, no persistence, no complex data types. Valkey is single-threaded but handles everything else.

On the exam, choose Memcached ONLY when the scenario mentions multi-threaded performance for simple key-value caching with no persistence requirement. Every other caching scenario is Valkey.

You now have concrete evidence of why Valkey dominates caching scenarios on the SAA-C03. Next up, you will push beyond single-region architecture and set up a Global Datastore for cross-region disaster recovery.

Set Up Global Datastore for Cross-Region Disaster Recovery

In Step 2, you saw automatic failover promote a replica within seconds inside a single region. That is powerful for local outages, but what happens if the entire region goes down?

The answer is: nothing automatic happens. ElastiCache does not support automatic cross-region failover. Global Datastore replicates data to a second region, but promoting the secondary requires manual action. This is the SAA-C03 trap that catches students who confuse intra-region auto-failover with cross-region recovery.

In this step, get ready to:

Create a Global Datastore using your CMD cluster as the primary.
Observe cross-region replication behavior and the read-only secondary.
Manually promote the secondary cluster to primary and confirm the role swap.

Create the Global Datastore with a secondary region

Your saa-cmd-cluster uses cache.m5.large nodes. This matters because Global Datastore requires instance families M5, M6g, M7g, R5, R6g, R6gd, R7g, or C7gn in size large and above.

In the ElastiCache console, expand the left navigation pane and choose Global Datastores.
Click Create global datastore.
In the Global Datastore info field, enter a name for your global datastore (e.g., saa-global-ds).
Under Regional cluster, select Use existing regional cluster.
Under Existing cluster, select saa-cmd-cluster.
Add a secondary cluster in a different region. Choose us-west-2 (Oregon) if your primary is in us-east-1.
Click Create.

What happens during creation?

The status moves from Creating to Modifying as ElastiCache associates the primary and secondary clusters. The secondary cluster inherits the engine version (Valkey 7.2), node type (cache.m5.large), and shard count from the primary automatically.

Once both clusters are associated, the status changes to Available. This process typically takes 5-10 minutes.

💡 Why does Global Datastore need cache.m5.large?

Global Datastore is only available for node-based clusters on supported instance families (M5, M6g, M7g, R5, R6g, R6gd, R7g, C7gn) in size large and above. Your saa-cme-cluster uses cache.t3.micro, which would be rejected.

This is why the CMD cluster was deliberately provisioned with cache.m5.large in Step 1.

Wait for the Global Datastore status to show Available in the console.

Once Available, you should see your global datastore with two clusters listed: the primary in your first region and the secondary in the second region.

Status stuck on Creating?

Global Datastore creation can take up to 10 minutes. If the status does not progress past Creating after 15 minutes, verify that saa-cmd-cluster shows Available status and is not currently being modified by another operation.

help me troubleshoot my Global Datastore creation

Observe cross-region replication behavior

Now that the Global Datastore is Available, you can see the fundamental difference between intra-region replication and cross-region replication.

Click on your global datastore name in the Global Datastores list to view its details.
Note the two clusters listed with their Global Datastore Role column: one shows Primary and the other shows Secondary.
Switch to the secondary region's ElastiCache console (open the AWS console in us-west-2 in a new browser tab).
In the secondary region, navigate to Valkey & Redis OSS caches in the left panel. You can see the secondary cluster listed there.

The primary cluster accepts both reads and writes. The secondary cluster accepts reads only and receives asynchronous updates from the primary.

Why is there no automatic cross-region failover?

ElastiCache does not support automatic failover from one AWS Region to another. When needed, you can promote a secondary cluster manually.

This is the critical SAA-C03 distinction. In Step 2, failover was automatic within a region. Across regions, it is always manual. Students who confuse these two get exam questions wrong.

Promote the secondary cluster to primary

In a real disaster scenario, the primary region becomes unreachable and you must manually promote the secondary. You will now simulate this promotion.

Before you start: what do you think will happen to the former primary cluster after promotion? Will it become a secondary, or will it be removed from the global datastore entirely?

Return to the Global Datastores page in your primary region's console.
Click the global datastore name to view its details.
Select the Secondary cluster.
Click Promote to primary.
A confirmation dialog warns that the chosen region will become read/write and the current primary will become secondary. Click Confirm.

What happens during promotion?

The global datastore enters a Modifying state while the role swap completes. The former secondary becomes the new primary (accepts writes). The former primary becomes the new secondary.

This manual step is the key SAA-C03 distinction from intra-region failover. On the exam, if a question mentions cross-region disaster recovery for ElastiCache, the answer involves manual promotion. Automatic failover only applies within a single region.

Wait for the global datastore status to return to Available.
Verify the roles have swapped: the cluster in us-west-2 now shows Primary and the cluster in us-east-1 (saa-cmd-cluster) now shows Secondary.

The promotion is confirmed. The secondary cluster in us-west-2 is now your primary and accepts writes. The original primary (saa-cmd-cluster) in us-east-1 is now secondary and read-only.

Promotion not completing?

Promotion typically takes 1-3 minutes. If the status remains at Modifying for longer than 5 minutes, check that no other modification was in progress on the global datastore (other than the promotion itself).

help me troubleshoot my Global Datastore promotion

Secret mission

Cost Optimization Deep-Dive

You have four clusters running and real CloudWatch metrics accumulating. Can you analyze them to build a right-sizing recommendation, explore reserved nodes pricing, and document Valkey's cost advantage over Redis OSS?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses multiple ElastiCache clusters across two regions, costing approximately $0.91/hr while running.

Cost warning

Your four clusters accumulate charges every hour they remain in the Available state. The CMD and Global Datastore clusters use cache.m5.large nodes, which cost significantly more than the cache.t3.micro nodes used by the CME and Memcached clusters. If you are not continuing immediately, choose Pause or Delete below to stop charges.

Resources you used:

Global Datastore (cross-region replication between us-east-1 and us-west-2).
`saa-cmd-cluster` (Valkey CMD replication group, cache.m5.large, 3 nodes in us-east-1).
`saa-cme-cluster` (Valkey CME replication group, cache.t3.micro, 3 shards with replicas).
`saa-memcached` (Memcached cluster, cache.t3.micro, 2 nodes).
`engine_comparison.py` on your EC2 instance.

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue this project in the next few hours.

All four clusters remain available and continue accumulating charges at approximately $0.91/hr total.
The Global Datastore continues replicating data between regions.
Your EC2 instance from Project 1 remains available with engine_comparison.py on it.

Pause - I'll come back to this later

ElastiCache node-based clusters cannot be stopped or paused. The only way to stop charges is to delete the clusters entirely. If you want to preserve your work, take a manual snapshot before deleting.

ElastiCache does not support pausing clusters. You must delete them to stop charges.
Before deleting, you can create a final backup of your Valkey clusters to preserve data. Memcached does not support backups.
Your EC2 instance and engine_comparison.py remain on the instance at no additional ElastiCache cost.

Delete - I don't want to use this again

Remove all project resources and stop all charges. Follow these steps in order. You cannot delete a cluster that belongs to a Global Datastore without removing it from the datastore first.

In the ElastiCache console, choose Global Datastores in the navigation pane.
Select your Global Datastore.
Choose the secondary region (us-east-1, where saa-cmd-cluster now acts as secondary) and click Remove region.
Click Confirm when prompted. Wait for the disassociation to complete.
Once the secondary is removed, return to Global Datastores, select your Global Datastore, and choose Delete. Confirm with Delete.
Navigate to the Valkey/Redis caches list. Select saa-cmd-cluster, choose Actions, then Delete. Confirm on the Delete Cluster screen.
Select saa-cme-cluster, choose Actions, then Delete. Confirm on the Delete Cluster screen.
Switch to the Memcached caches list. Select saa-memcached, choose Actions, then Delete. Confirm.
Switch to the us-west-2 region in the console and delete the cluster that was created there for the Global Datastore secondary (now a standalone cluster after promotion). Select it, choose Actions, then Delete.
Verify no clusters remain in either region. The cluster list should be empty in both us-east-1 and us-west-2.
SSH into your EC2 instance and remove the comparison script by running:

rm engine_comparison.py

What about the EC2 instance and subnet group?

The EC2 instance and VPC subnet group were created in Project 1. If you are done with the entire series, clean those up using Project 1's Before You Go instructions.

That's a Wrap!

Nice work. You just built and tested all four ElastiCache architecture patterns that appear on the SAA-C03 exam, from single-shard replication to cross-region disaster recovery.

You've learned how to:

Create a cluster mode disabled replication group with Multi-AZ failover, trigger a test failover, and observe replica promotion with the key understanding that ElastiCache uses async replication (potential data loss on failover, unlike RDS synchronous standby).
Build a cluster mode enabled cluster and dynamically scale from 2 to 3 shards via online resharding, applying the CMD vs CME decision framework: CMD for read-heavy single-dataset workloads, CME for write-heavy or large datasets needing partitioning.
Prove Memcached's limitations hands-on (no persistence, no replication, no failover, no complex data types) and set up a Global Datastore for cross-region disaster recovery, manually promoting a secondary cluster to primary to demonstrate the critical difference between intra-region auto-failover and cross-region manual promotion.
Secret Mission: Analyzed CloudWatch metrics for right-sizing, explored reserved nodes pricing, and documented Valkey's 20-33% cost advantage over Redis OSS.

Ready to quiz yourself?