This project has a hard contract: every run is exactly one hour. That constraint is what keeps results comparable across configurations and makes exported visualisation consistent.

After I fixed shutdown reliability, the next issue wasn't infrastructure. It was methodology.

The discovery: the "happy path" trap

Reviewing telemetry from a standard run, I noticed that my default load generation (single ECS task) was not reliably pushing Redis into the state I actually care about.

Memory usage was climbing, but in many cases the run could finish without reaching maxmemory. That means the test is still useful as a smoke check, but it's not a strong performance validation: it mostly measures a cache that's not under pressure.

AWS ElastiCache Lab project has a hard rule: a test run is defined as one hour. That only stays true if the lab reliably shuts down on schedule. If it doesn't, I lose cost control and-more importantly for benchmarking-I risk starting the next run from a non-clean baseline.

I hit exactly that problem on an evening run.

What I observed

The run finished, but the environment was still up. Nothing looked "broken" in the usual sense: services were alive and responsive. In this lab, though, "still works" past the run boundary is a defect, because it means the lifecycle automation failed silently.

Imagine walking into a bank with a long queue of customers waiting to be served. To handle the influx of people, the bank opens multiple teller windows to speed up the process. Content Delivery Networks (CDNs) work in a similar manner, distributing digital content across multiple servers worldwide to ensure rapid delivery. In the finance industry, where speed, reliability, and security are paramount, CDNs are essential.