MemoryDB borrows Redis’s vocabulary almost entirely, but layers a durability guarantee underneath it that changes what several of these familiar terms actually mean in practice.

Redis API Compatibility as a Deliberate, Bounded Promise

MemoryDB implements the Redis API surface for data structures, commands, and client protocol compatibility, meaning existing Redis client libraries and much application code can run against it largely unchanged. However, this compatibility is deliberately bounded — MemoryDB does not support arbitrary Redis modules, and certain administrative or persistence-related commands specific to self-managed Redis’s own AOF/RDB persistence model are not applicable, since MemoryDB’s durability model replaces that mechanism entirely with its own transaction log.

Node Types and the Memory-to-vCPU Trade-off

Each node type available for MemoryDB carries a fixed ratio of available memory to vCPU capacity, and because the engine’s command processing for a given shard is fundamentally single-threaded per shard (mirroring Redis’s own execution model), advanced node-type selection weighs whether a workload is genuinely memory-bound (favoring node types with a higher memory-to-vCPU ratio) or command-throughput-bound (favoring more, smaller shards over fewer, larger ones, since additional vCPU on an oversized node type does not help a single-threaded command path handle more concurrent commands per shard).

Cluster Configuration Endpoint vs Per-Shard Endpoints

A MemoryDB cluster exposes both a single cluster configuration endpoint, used by cluster-aware clients to discover current topology and hash slot ownership, and individual per-shard endpoints for direct connections once topology is known. Advanced client configuration always initializes against the cluster configuration endpoint rather than hardcoding a specific shard’s endpoint, since the configuration endpoint transparently reflects topology changes from resharding or failover, while a hardcoded per-shard endpoint reference can become stale the moment that shard’s primary role changes.

Parameter Groups and Engine-Level Tuning Boundaries

MemoryDB exposes a subset of Redis’s configurable engine parameters through parameter groups, letting administrators tune behaviors like maximum memory policy and certain timeout thresholds without modifying the underlying managed infrastructure directly. Advanced operators recognize this as a deliberately bounded surface compared to a fully self-managed Redis deployment — parameters affecting the service’s own durability and failover mechanics are intentionally not exposed for modification, since altering them could undermine the very guarantees the managed service exists to provide.

Understanding exactly what happens between “client sends a write” and “client receives an acknowledgment” is the single most important internal detail for reasoning about MemoryDB’s durability and latency characteristics.

flowchart TD
    A[Client Sends Write Command] --> B[Primary Node Receives Command]
    B --> C[Command Applied to In-Memory Data Structure]
    C --> D[Write Also Sent to Multi-AZ Transaction Log]
    D --> E{Log Persisted Across Multiple AZs?}
    E -- No, still propagating --> D
    E -- Yes, quorum confirmed --> F[Acknowledgment Returned to Client]
    C --> G[Async Replication Stream to Replica Nodes]
    G --> H[Replica In-Memory State Updated]
        

Why the Transaction Log Is Separate From In-Memory Replication

A crucial internal distinction advanced operators must hold clearly in mind: the Multi-AZ transaction log and the asynchronous replica replication stream are two entirely separate mechanisms serving two different purposes. The transaction log exists purely for durability — surviving node failure without data loss — while replica replication exists purely for read scaling and failover readiness. A write is only acknowledged to the client once the transaction log confirms durable persistence, but replicas may lag slightly behind that same write, which is precisely why reads from replicas are eventually consistent even though the underlying write was already fully durable the moment it was acknowledged.

The Cost of Durability: Write Latency Composition

Because every write must round-trip to the Multi-AZ transaction log before acknowledgment, MemoryDB’s write latency is composed of the in-memory operation cost plus the network round-trip cost to achieve durable log persistence across Availability Zones — a fundamentally different latency profile than a pure in-memory cache like ElastiCache, where a write is acknowledged the instant it lands in local memory, with no cross-AZ durability round-trip at all. Advanced capacity and latency planning treats this as an explicit, unavoidable cost of the durability guarantee, not a performance defect to be tuned away.

Single-Threaded Command Processing and Its Consequences

Consistent with its Redis lineage, each shard’s primary node processes commands for its portion of the keyspace on a single execution thread, meaning any individual command’s execution time directly blocks every other command queued behind it on that same shard. This is precisely why advanced application design avoids issuing genuinely expensive operations — an unbounded SORT on a massive list, a large Lua script performing significant computation — against a shard also serving latency-sensitive production traffic, since such an operation does not merely run slowly itself, it delays every other concurrent operation on that shard for its entire duration.

How the Engine Log Differs From the Transaction Log

Advanced operators should not confuse the durability-focused Multi-AZ transaction log with the separate engine log, which records operational events — connection errors, memory warnings, replication state changes — for diagnostic and monitoring purposes rather than for data durability. The engine log is a troubleshooting tool an operator reads after the fact; the transaction log is an active, continuously-consulted durability mechanism the write path depends on for every single acknowledged write, and conflating the two during an incident investigation leads to looking in the wrong place for the wrong kind of information.

A read or write against a healthy cluster is simple. What actually happens during a primary node failure is where MemoryDB’s architectural investment pays off — or reveals a gap in how a client application was built to handle it.

Hash Slot Routing and Client-Side Cluster Awareness

Like Redis Cluster, MemoryDB partitions its keyspace into a fixed number of hash slots distributed across shards, and a client must be cluster-aware — capable of computing which shard owns a given key’s slot and routing the command directly to that shard’s current primary. A client library that is not cluster-aware, or that caches a stale slot-to-shard mapping across a resharding or failover event, will receive redirection errors or route to the wrong node entirely, which is why advanced application design always uses a maintained, cluster-aware Redis client library rather than a naive single-endpoint connection.

sequenceDiagram
    participant Client
    participant Primary as Shard Primary
    participant Log as Multi-AZ Transaction Log
    participant Replica as Shard Replica

    Note over Primary: Primary node fails unexpectedly
    Log->>Replica: Replica promoted using durable log state
    Replica->>Replica: Becomes new Primary
    Client->>Client: Detects connection failure, refreshes cluster topology
    Client->>Replica: Redirects subsequent writes to new Primary
    Note over Log,Replica: No data loss - promoted primary state matches durably logged writes
        

Automatic Failover and the Role of the Transaction Log in Promotion

When a primary node fails, MemoryDB automatically promotes a replica to primary — but critically, because every acknowledged write was already durably persisted in the Multi-AZ transaction log independent of any single node’s in-memory state, the promoted replica can be brought fully up to date against that log before serving new writes, guaranteeing zero data loss for any write that was ever acknowledged to a client. This is the single most important reliability property distinguishing MemoryDB from a plain in-memory Redis replication setup, where a primary failure before replication catches up can silently lose recently acknowledged writes.

Snapshot Lifecycle for Point-in-Time Recovery

Beyond the continuously durable transaction log, MemoryDB also supports scheduled and on-demand snapshots, stored independently in S3, which serve a different purpose than the transaction log’s continuous durability — snapshots enable restoring an entirely new cluster to a specific historical point in time, useful for recovering from a logical error (an accidental FLUSHALL, a bad application deployment that corrupted data) rather than a node or AZ failure, which the transaction log already protects against automatically.

Distinguishing Node Failure Recovery From Logical Error Recovery

Advanced disaster recovery planning explicitly separates these two distinct failure classes, since they require entirely different recovery mechanisms and carry entirely different recovery point characteristics. A node or Availability Zone failure is handled automatically and near-instantly by the transaction log and failover mechanism, with genuinely zero data loss for any acknowledged write. A logical error, however — bad data written by a buggy deployment — is durably persisted by the very same mechanism that protects against node failure, meaning the transaction log will happily and correctly preserve the bad data forever unless a snapshot-based restore to a point before the error occurred is deliberately initiated; durability and correctness are not the same guarantee, and MemoryDB’s architecture only automatically provides the former.

Application-Level Safeguards Against Logical Errors

Because the transaction log durably preserves logical errors just as faithfully as legitimate writes, advanced application design layers its own safeguards in front of genuinely destructive operations — requiring explicit confirmation flags before a bulk-delete code path executes, or restricting FLUSHALL and similar cluster-wide commands to a narrowly-scoped administrative ACL user entirely separate from any application-facing credential. These safeguards exist precisely because MemoryDB’s durability guarantee, by design, has no concept of “this specific write was a mistake” — it durably persists whatever the application instructs it to, correct or not.

Read Consistency Options and When to Use Them

Applications can explicitly choose whether a given read targets the primary (for strict read-your-writes consistency) or a replica (for read scaling, accepting eventual consistency), and advanced application design makes this choice deliberately per access pattern rather than defaulting uniformly to one or the other. A user checking their own just-submitted order status needs primary-consistency reads; a public leaderboard display refreshed every few seconds tolerates replica read staleness perfectly well, and routing that traffic to replicas frees primary capacity for the writes and consistency-sensitive reads that genuinely need it.

MemoryDB vs. ElastiCache for Redis vs. DynamoDB

ElastiCache for Redis remains the right choice when data is genuinely disposable or reconstructible from a system of record — a cache in the traditional sense, where losing it on failure means, at worst, a slower cache-miss path to the real source of truth, not permanent data loss. DynamoDB offers durable, disk-backed storage with effectively unlimited scale and strong consistency options, but with materially higher latency per operation than an in-memory engine and a different, more constrained data model for certain access patterns Redis handles natively (sorted sets, native list operations, pub/sub). MemoryDB occupies the specific niche where an application genuinely needs Redis’s data structures and speed, but the data itself is primary, not disposable — session stores, leaderboards, real-time feature stores for machine learning, and message brokering backends where losing data is unacceptable.

The Storage Cost Multiplier: In-Memory Durability Is Not Cheap

Durable in-memory storage carries a meaningfully higher per-GB cost than disk-backed storage of any kind, a direct consequence of DRAM’s fundamental cost structure relative to SSD or magnetic storage. Advanced cost modeling explicitly quantifies this multiplier against the latency and durability benefit gained, since a dataset that could tolerate DynamoDB’s single-digit-millisecond latency just as well as MemoryDB’s microsecond latency for its actual business requirement is paying a real, ongoing cost premium for a performance characteristic it does not functionally need.

When Neither Cache Nor Durable Store Is the Right Framing

Some workloads are best served by using both MemoryDB and a separate system of record together deliberately, rather than treating the choice as strictly either-or. A pattern that stores the authoritative, rarely-changing core record in a relational database while using MemoryDB purely for the specific, latency-critical derived state (a computed leaderboard rank, a real-time inventory counter) captures durability for the source of truth and speed for the derived view, without forcing every single piece of data in the system into one architecture’s trade-off profile uniformly.

Horizontal Scaling Through Sharding

MemoryDB scales write and overall throughput horizontally by adding shards, each responsible for a distinct portion of the hash slot space — a workload’s total achievable throughput and dataset size both grow roughly linearly with shard count, provided the key access pattern distributes reasonably evenly across hash slots. A workload dominated by a small number of extremely hot keys does not benefit proportionally from additional shards, since those hot keys remain pinned to whichever single shard currently owns their slot, regardless of how many other shards exist.

Online Resharding Without Downtime

MemoryDB supports online resharding — adding or removing shards, or rebalancing hash slot ownership across existing shards — without taking the cluster offline, migrating hash slots and their associated data gradually in the background while the cluster continues serving live traffic. Advanced capacity planning schedules resharding operations during lower-traffic windows regardless of this online capability, since the migration process itself consumes additional CPU and network resources on the shards involved, and a resharding operation initiated during genuine peak load competes for the same resources the live workload needs.

Read Replica Scaling and Read/Write Splitting

Adding replica nodes to a shard scales read throughput for that shard’s keyspace without adding write capacity, since all writes for a given shard must still funnel through that shard’s single primary. Advanced applications explicitly split their client connections — directing reads that can tolerate eventual consistency to replica endpoints while ensuring writes and any read requiring strict read-your-writes consistency go to the primary — rather than relying on a single connection type for both, which either under-utilizes available replica read capacity or risks staleness on consistency-sensitive reads.

Connection Pooling and Client-Side Resource Management

Because each shard’s primary processes commands on a single thread, a large number of concurrent client connections issuing commands simultaneously does not increase a single shard’s actual command throughput ceiling — it can, in fact, degrade latency through increased connection-handling and context-switching overhead if pool sizes are set far beyond what the workload’s actual concurrency profile requires. Advanced client configuration sizes connection pools based on measured, realistic concurrent command volume per shard, rather than defaulting to an arbitrarily large pool under the mistaken assumption that more open connections inherently means more throughput.

Pipelining as a Latency Amortization Technique

For workloads issuing many independent commands in quick succession, command pipelining — batching multiple commands into a single network round trip rather than waiting for each command’s individual response before sending the next — amortizes network round-trip latency across many operations, delivering substantially higher effective throughput for bulk operations than issuing the same commands one at a time. Advanced application design uses pipelining deliberately for genuinely batchable workloads (bulk cache warming, batch feature retrieval) while recognizing it does not reduce the latency of any single individual command, only the aggregate cost of many.

Multi-AZ by Default, Not by Configuration Choice

Unlike many AWS services where Multi-AZ is an optional, explicitly enabled configuration, MemoryDB’s durability model is inherently Multi-AZ — the transaction log itself is architected to span Availability Zones as a fundamental property of the service, not a toggle a customer can disable to save cost. This is a deliberate design decision reflecting that MemoryDB’s entire value proposition rests on durability; a hypothetical single-AZ mode would undermine the guarantee the service exists to provide.

Multi-Region Resilience via Global Datastore-Style Replication

For disaster recovery needs beyond a single region’s Multi-AZ protection, MemoryDB supports cross-region replication, propagating writes from a primary region’s cluster to one or more secondary region clusters with typical propagation latency in the low seconds. Advanced disaster recovery architecture treats this cross-region replication as providing regional-outage protection with an inherent, small window of potential data loss for the very latest writes not yet propagated at the moment of a regional failure — a materially different guarantee than the zero-loss promise the Multi-AZ transaction log provides within a single region.

Planned Maintenance and Its Relationship to Automatic Failover

Routine operational events — a security patch applied to underlying infrastructure, a minor version upgrade — trigger the same primary-to-replica failover mechanism used for unplanned failures, meaning a well-designed client application experiences planned maintenance identically to an unplanned node failure: a brief connection interruption, a topology refresh, and resumed operation with zero data loss. Advanced operations teams treat this as validation that maintenance windows do not require special-cased application behavior, provided the application’s failover handling was already built and tested correctly for the unplanned case.

Backup Retention and Cross-Region Snapshot Copy

Scheduled snapshots can be configured with an explicit retention period and, for organizations requiring protection against a full regional disaster beyond what cross-region replication’s asynchronous propagation provides, copied into a separate region entirely independent of the live replication stream. Advanced disaster recovery design treats these as complementary rather than redundant — cross-region replication provides near-real-time failover with a small loss window, while cross-region snapshot copies provide a point-in-time recovery option that survives even a scenario where replication itself was compromised or misconfigured at the time of a disaster.

Access Control Lists as Redis-Native Fine-Grained Permissions

MemoryDB implements Redis-compatible Access Control Lists, allowing administrators to define users with permissions scoped to specific commands and specific key name patterns — a materially finer-grained control than a single shared authentication token, letting a reporting service be granted read-only access to a specific key namespace while an application write path retains full read-write access to its own namespace, all enforced natively by the engine rather than through an external proxy layer.

Encryption in Transit and at Rest

MemoryDB encrypts data at rest by default, including both the in-memory engine’s persisted state and the transaction log itself, using a customer-managed or AWS-managed KMS key. In-transit encryption via TLS is similarly available and, for genuinely sensitive workloads, should be enforced as mandatory rather than optional, since Redis’s own protocol has no inherent transport encryption without TLS explicitly layered on top by the service.

VPC Isolation and Network-Level Access Control

A MemoryDB cluster is deployed within a customer VPC with no public endpoint option at all, meaning network access is governed entirely by VPC security groups and subnet placement — advanced architectures place clusters in private subnets with security group rules scoped precisely to the specific application security groups that legitimately need connectivity, rather than broad CIDR-range-based rules that inadvertently permit access from unrelated resources sharing the same VPC.

Command Restriction as a Blast-Radius Control

Beyond key-pattern restrictions, ACL rules can also deny entire categories of commands per user — preventing a read-only reporting service from ever issuing FLUSHALL, CONFIG, or other administrative commands even if a bug or compromise in that service attempted to. Advanced security design treats destructive and administrative commands as requiring their own explicit, narrowly-scoped ACL user, entirely separate from any application-facing credential, ensuring that no application-tier compromise can ever reach commands capable of wiping or reconfiguring the cluster.

Auditing ACL Configuration Drift Over Time

As an organization’s number of services connecting to a shared MemoryDB cluster grows, ACL configuration can drift from its originally intended least-privilege design through incremental, individually reasonable-seeming permission grants made under time pressure. Advanced governance practice periodically reviews the full set of ACL users and their granted permissions against what each connecting service actually uses in practice — observable through command-level audit logging — rather than assuming a permission grant made months or years ago is still appropriately scoped today.

Because MemoryDB serves latency-critical workloads by design, advanced observability focuses less on aggregate uptime and more on the specific latency and memory-pressure signals that predict degradation before it becomes visible to end users.

Slow Log Analysis for Command-Level Optimization

The slow log records the exact command, its arguments, and execution duration for any operation exceeding a configured threshold, giving advanced operators direct visibility into which specific commands — an unbounded KEYS scan, an oversized Lua script, a poorly designed sorted-set range query — are responsible for latency outliers, rather than only seeing an aggregate latency percentile with no attribution to a specific root cause.

Memory Fragmentation and Eviction Policy Monitoring

Because MemoryDB is fundamentally memory-bound, advanced monitoring tracks not just raw memory usage percentage but also memory fragmentation ratio and eviction event counts, since a cluster approaching its memory ceiling under a restrictive eviction policy will begin actively discarding data — a behavior that, for a durable primary data store rather than a disposable cache, represents genuine, unacceptable data loss if triggered unexpectedly in production.

Correlating Latency Percentiles With Shard-Level Hot Spots

An aggregate p99 latency metric across an entire cluster can mask a severe problem confined to a single shard — if nine of ten shards serve requests in well under a millisecond while one overloaded shard serves requests in tens of milliseconds, the cluster-wide p99 may still look acceptable purely because the healthy shards dominate the sample volume. Advanced observability computes and alerts on per-shard latency percentiles specifically to catch this masking effect, since the business impact of a hot shard falls entirely on whichever subset of end users happens to be routed to that shard’s specific keys, regardless of how healthy the aggregate metric appears.

Alerting Thresholds Tuned to Durability-Critical Workloads

Because MemoryDB workloads are frequently chosen specifically for their durability guarantee, advanced alerting configures noticeably more conservative memory-pressure thresholds than a team might use for a disposable ElastiCache deployment — triggering a capacity-planning alert well before a cluster approaches actual eviction risk, since the cost of proactively resharding ahead of need is far lower than the cost of unexpected data loss on a system explicitly chosen for its durability promise.

Infrastructure as Code for Cluster Topology

Because shard count, node type, and ACL configuration are all security- and performance-critical decisions, advanced teams manage MemoryDB clusters entirely through Infrastructure as Code, treating any resharding or node-type change as a reviewed, versioned change rather than a manual console action — particularly important given that certain topology changes trigger data migration processes with real performance impact during the transition window.

Feature Store Pattern for Machine Learning Inference

A widely adopted advanced pattern uses MemoryDB as a low-latency online feature store for real-time machine learning inference — precomputed features are written durably to MemoryDB by an offline batch pipeline, then read with microsecond latency at inference time by a production serving path that cannot tolerate the latency of a disk-backed database lookup on every prediction request.

Zero-Downtime Migration From Self-Managed Redis

Teams migrating from self-managed Redis typically use online migration tooling that establishes MemoryDB as a replica of the existing Redis deployment, allowing data to synchronize continuously while the cutover is planned, then promoting MemoryDB and repointing application connection strings during a brief, controlled cutover window rather than requiring a full offline export-and-import process with an extended downtime window.

Event-Driven Cache Warming and Cold-Start Mitigation

Because a resharding or restore operation can create shards with no data yet resident in memory locally beyond what has replicated so far, advanced deployment pipelines deliberately warm newly provisioned shards with the most frequently accessed keys before directing production traffic to them, rather than allowing cold-start latency spikes to be discovered by real user traffic hitting an under-warmed shard for the first time.

Multi-Tenant Namespace Isolation on a Shared Cluster

Organizations running multiple applications or business units against a single MemoryDB cluster to reduce operational overhead typically enforce logical isolation through a combination of key-name prefixing conventions and ACL user restrictions scoped to each tenant’s prefix, rather than provisioning fully separate clusters per tenant. This pattern trades some blast-radius isolation — a severely overloaded tenant’s hot keys can still affect shard-level performance for co-located tenants — for meaningfully lower total infrastructure cost and operational overhead, a trade-off advanced platform teams document explicitly rather than leaving implicit.

Load Testing Failover, Not Just Steady-State Throughput

Advanced production readiness testing deliberately triggers a controlled failover during a load test, measuring the client application’s actual behavior — connection recovery time, error rate during the transition, and whether in-flight requests are retried correctly — rather than only validating steady-state throughput and latency under normal conditions. A cluster’s underlying failover mechanism working correctly is only half the story; the client application’s resilience to that failover event is the other half, and it is frequently the half left untested until a real incident exposes the gap.

Version Upgrade Planning and Compatibility Testing

Engine version upgrades, like node type changes, trigger a rolling primary replacement process across shards, and while MemoryDB maintains backward compatibility for the vast majority of Redis commands across versions, advanced teams still validate application behavior against a new engine version in a non-production environment before scheduling a production upgrade, specifically to catch any subtle behavioral difference in edge-case command semantics that a version bump could introduce before it affects live traffic.

Right-Sizing Node Type Against Working Set, Not Total Dataset

Because MemoryDB is fully in-memory, node type selection must account for the entire dataset residing in memory at all times, not merely a “hot” working subset the way a disk-backed database with a memory cache layer might. Advanced capacity planning explicitly models total dataset size growth over the cluster’s expected lifetime, since under-provisioning memory capacity on a durable primary data store risks the specific failure mode of unwanted eviction discussed above, a materially more severe consequence than the same under-provisioning would cause on a disposable cache.

Documenting Which Guarantee Each Workload Actually Needs

Advanced platform teams maintain explicit documentation, per workload, of exactly which MemoryDB guarantees that workload’s design depends on — zero-loss durability, read-your-writes consistency, a specific hash-tag co-location assumption — rather than leaving these as implicit assumptions embedded only in application code. This documentation becomes essential the moment a workload’s requirements are re-evaluated during a later architecture review, since a reviewer without this context has no way to know whether a proposed change (switching some reads to replicas, for instance) would silently violate a consistency assumption the original application design quietly depended on.

Avoiding Over-Engineering for Guarantees the Workload Doesn’t Need

Just as under-provisioning durability guarantees is a mistake, so is reflexively routing every workload through MemoryDB’s full durability and consistency machinery when a plain ElastiCache cache would serve the actual requirement just as well at lower cost. Advanced architectural judgment distinguishes genuinely durability-dependent state from data that is, on reflection, perfectly reconstructible from an existing system of record — and reserves MemoryDB’s premium cost specifically for the former.

The Common Thread Across These Industries

Every one of these real-world patterns shares a common structural feature worth naming explicitly: each involves state that is both accessed with extreme latency sensitivity and genuinely irreplaceable if lost — not a cache of something else, but the primary and only record of that specific piece of state at that moment. This is the precise intersection MemoryDB was purpose-built to occupy, and its adoption across such structurally different industries reflects how frequently that specific combination of requirements — sub-millisecond access plus zero tolerance for silent data loss — actually arises once an organization looks for it deliberately, rather than defaulting to whichever database happened to be already in use for everything else.

No — MemoryDB always operates in cluster mode, even with a single shard, meaning clients must always be cluster-aware regardless of how small the deployment currently is.

No — reads are served directly from in-memory state on the primary or a replica and do not require a round-trip to the transaction log at all; only writes incur the durability round-trip cost, since only writes need to be durably persisted.

Only writes that were fully persisted to the transaction log and acknowledged to the client are guaranteed to survive; a write in flight at the exact moment of failure, before acknowledgment, may need to be retried by the client, which is standard practice for any distributed system’s failure handling.

Yes — node type scaling is performed by provisioning new nodes of the target type and migrating each shard’s role over in sequence, with the cluster remaining available throughout, though individual shards briefly experience the same failover-like transition as during any primary replacement.

Cross-region replication is asynchronous, meaning writes are acknowledged based on the primary region’s Multi-AZ transaction log alone, with propagation to secondary regions happening afterward — a regional failure can therefore lose the small window of writes not yet propagated at that moment.

Yes — ACL rules can restrict a user to specific key name patterns using glob-style matching, enabling namespace-level isolation between different applications or services sharing the same cluster.

Yes — restoring from a snapshot into a new cluster allows specifying a different shard count than the original cluster had, which is a common technique for both disaster recovery testing and deliberate cluster topology redesign.

It does not support this directly — Redis Cluster’s architecture, which MemoryDB follows, requires all keys referenced within a single Lua script or transaction to reside on the same hash slot, which is precisely why deliberate hash-tag design for related keys matters for any workload needing multi-key atomic logic.

Yes — online resharding is designed to keep the cluster fully available for both reads and writes throughout the migration, though shards actively involved in the migration may experience some additional latency due to the background data-movement work competing for resources.

No — hash slot assignment is a deliberate configuration decision, and while MemoryDB will evenly distribute slots by count across shards, it has no awareness of which specific keys or slots are actually hot in practice; correcting genuine hot-key skew requires an application-level key design change, not an automatic rebalancing feature.

Not directly — since MemoryDB has no public endpoint option, external access requires an intermediary such as a VPN, VPC peering, Transit Gateway, or a bastion host within the VPC, all of which must be deliberately provisioned as part of the network architecture rather than being available by default.

AWS MemoryDB’s core achievement is resolving a trade-off that Redis users have lived with for years — the choice between an in-memory engine’s extraordinary speed and a disk-backed engine’s durability — by architecting a distributed transaction log that gives every acknowledged write the same zero-loss guarantee a traditional durable database offers, without sacrificing Redis’s native data structures or its microsecond-class read latency. Advanced practitioners who understand precisely where that durability cost is paid — on the write path, through Multi-AZ log persistence, never on reads — can reason clearly about exactly which workloads benefit from this trade and which are better served by a plain cache or a disk-backed alternative instead.

The patterns running through every chapter of this tutorial converge on a single operating principle: MemoryDB rewards treating it as a genuine primary data store deserving the same rigor around key design, capacity planning, failover testing, and access control that any durable database demands — not as “just Redis with a durability flag flipped on.” Teams that internalize this distinction design hash-tag strategies deliberately, provision memory capacity for full dataset growth rather than a working-set assumption, and test client-side failover behavior explicitly, arriving at a system that delivers on both halves of its core promise: Redis-class speed and database-class durability, together, rather than being forced to choose one or the other.

It is worth closing on the distinction that separates every advanced capability discussed in this tutorial from a superficial deployment: MemoryDB does the hard architectural work of making durability and speed coexist, but it cannot compensate for a client application that was never built to expect a failover, a key-space design that concentrates load onto a single shard, or a capacity plan sized for today’s dataset with no allowance for tomorrow’s growth. The service delivers exactly the guarantee it promises — nothing more, nothing less — and the advanced practitioner’s job is building the surrounding application and operational discipline that actually lets that guarantee translate into a genuinely resilient production system.