Building an Amazon MemoryDB Test Lab
I have started a separate Amazon MemoryDB test project to make its behavior under load observable and repeatable. The repository is public, but it is still being adapted from my ElastiCache lab. This page introduces the project before the first MemoryDB result.
MemoryDB's acknowledged writes pass through a distributed Multi-AZ transaction log. That durability contract shapes the test setup, the metrics worth keeping, and the way read and write latency should be reported.
MemoryDB project
The starting point is my ElastiCache test lab: a way to run controlled workloads and keep the telemetry needed to explain what happened. Its lifecycle and export work established another requirement: a run is only useful when its artifacts survive and the test resources are confirmed gone.
The MemoryDB repository takes those principles into a service with its own topology and durability model. Its current code is a scaffold copied from the earlier project. The implementation plan identifies the MemoryDB-specific work still to be completed. The presence of Terraform and reporter files in the repository is not evidence of a completed MemoryDB run.
The project
The intended workflow is one controlled run from provisioning through the report:
- Provision a MemoryDB cluster and ECS load generators with a recorded engine version, node type, shard and replica count, and client configuration.
- Run a time-bounded memtier workload with a cluster-aware client and the connection settings required by the cluster.
- Stop the load generators, delete the cluster, and verify that both parts of the test environment are gone.
- Export the workload logs and CloudWatch measurements to S3, then generate the HTML report with separate read and write latency views.
These are project requirements, not a claim that this sequence has already run successfully on MemoryDB. The repository's README and plan are the current place to inspect the implementation as it develops.
AWS's MemoryDB engine list documents Valkey 7.2.6 and a MemoryDB 7.3 release for Multi-Region. The test project must verify the version available for the chosen cluster and region, then record the effective version with each run. A version label in a plan cannot substitute for that observation.