Global Datastore Operations

Creating a Global Datastore

Step 1: Create the Global Datastore from an Existing Primary

The primary replication group must already exist and be in available status.

This registers the existing primary replication group as the primary member of the Global Datastore.

Wait for the Global Datastore status to become available:

Note: The full Global Datastore ID is prefixed with a short string derived from the primary region (e.g., ldgnf- for us-east-1). Use describe-global-replication-groups without the ID filter to discover the prefix if needed.

Step 2: Add a Secondary Region

Create a replication group in the secondary region that joins the Global Datastore:

Many parameters are inherited from the Global Datastore and must not be specified when creating a secondary, including: PrimaryClusterId, AutomaticFailoverEnabled, NumNodeGroups, CacheParameterGroupName, CacheNodeType, Engine, EngineVersion, CacheSecurityGroupNames, EnableTransitEncryption, AtRestEncryptionEnabled, SnapshotArns, and SnapshotName.

Monitor until the secondary reaches available and replication lag is minimal:

Removing a Secondary Region

Removing a secondary region is a two-step process: disassociate, then delete.

Step 1: Disassociate the Secondary

Wait for the disassociation to complete. The secondary becomes a standalone replication group in its region.

Step 2: Delete or Retain the Secondary

After disassociation, the secondary is independent. Delete it if no longer needed:

Or retain it as a standalone cluster in that region.

Deleting the Global Datastore

To delete the Global Datastore itself, all secondaries must be disassociated first:

Use --retain-primary-replication-group to keep the primary as a standalone cluster after disassociation. Use --no-retain-primary-replication-group to delete the primary replication group as part of the Global Datastore deletion. If you want to keep the primary, you must specify --retain-primary-replication-group explicitly.

Upgrading Engine Version on Global Datastore

Engine upgrades must be performed on the Global Datastore object, not on individual members. See upgrade-patching.md for the version compatibility matrix and general upgrade procedures.

The key difference from standalone upgrades: you cannot upgrade individual member replication groups independently. The upgrade applies to secondary regions first, then to the primary region.

Failover Between Regions

Use regional failover to promote a secondary to primary. This is used for disaster recovery or planned region migration.

Important: ElastiCache does not support automatic cross-region failover. When needed, you must promote a secondary cluster manually.

After failover:

• The former secondary becomes the new primary (read-write).
• The former primary becomes the new secondary (read-only).
• Application writes must target the new primary region’s endpoint.
• Update application connection strings or DNS to point to the new primary region.

Monitor failover progress:

Planned Failover vs Unplanned Scenarios

The failover-global-replication-group command performs a planned failover (both regions must be healthy). For unplanned scenarios where the primary region is unavailable:

1. Disassociate the secondary from the Global Datastore (this promotes it to a standalone primary).
2. Point applications to the promoted cluster.
3. When the original primary region recovers, assess data divergence before re-establishing replication.

Node Type Changes on Global Datastore

Same principle as engine upgrades: modify the Global Datastore object, not individual members. See upgrade-patching.md for general node type change procedures.