Twenty thousand requests, three different bills

Lab Overview

A courier charges by the parcel. You send a hundred parcels, you pay for a hundred. Then you discover the invoice is by weight, and the hundred envelopes you sent last month cost rather less than the hundred boxes you sent this month.

Nothing about the count changed. The count was never the thing being charged for.

The problem. Capacity conversations about a cache start with requests per second, because that is the number on every dashboard. ElastiCache Serverless bills in ECPUs, and an ECPU is charged per kilobyte moved. The request rate and the bill are related only through a quantity nobody is looking at.

The objective. Issue the same number of requests three times, against values of 1 KB, 10 KB and 100 KB, and read the billed ECPUs for each from CloudWatch.

The outcome. 20,000 requests billed 20,803, 200,830 and 2,000,960 ECPUs — a 96× spread with the request count held constant. The byte model predicts all three to within 4%, which is the point: the model is sound and the request count is the useless number.

Cloud Services and Concepts

An ECPU is the higher of two numbers

AWS defines it in two parts. A simple read or write "requires 1 ECPU for each kilobyte (KB) of data transferred". A command that needs more processing consumes proportionally more. And when both apply, "ElastiCache calculates the ECPUs required based on the higher of the two dimensions" — not the sum.

For a plain GET the byte dimension wins, which makes the arithmetic simple and the budgeting counter-intuitive: a 100 KB value costs a hundred times a 1 KB value to read, and the request counter shows the same number either way.

Valkey's floor is 100 MB, not 1 GB

Storage is billed per GB-hour with a minimum, and the minimum differs by engine: 100 MB for Valkey against 1 GB for Redis OSS and Memcached. At $0.084/GB-hour that is about $6.13 a month for a cache that holds almost nothing, which is the figure behind AWS's "starts at $6/month". The same page says there is "no minimum fee". Both statements are true: there is no fee floor, but there is a storage floor.

Architecture and Workflow

1. 20,000 reads of 1 KB values. The byte dimension implies 20,000 ECPUs.
2. 20,000 reads of 10 KB values. Same request count, ten times the bytes.
3. 20,000 reads of 100 KB values. Same request count again, a hundred times the bytes.

Each run writes its value once, then reads it back 20,000 times sequentially. A cache hit is the cheapest thing the service does, so this is the best case for a request-based estimate — and it still misses by two orders of magnitude.

Prerequisites

Implementation

What was deployed

Ten resources, applied in about seven minutes.

The one thing that is not obvious in the Terraform

Encryption in transit is not a choice. AWS: "If you are using ElastiCache Serverless, encryption in transit is always enabled", and it cannot be turned off. The client therefore has to speak TLS or it will not connect at all:

_client = valkey.Valkey(host=HOST, port=PORT, ssl=True,
                        ssl_cert_reqs=None, socket_timeout=10)

Port 6379 is the primary endpoint. 6380 is a read-optimised reader endpoint, left closed here so the measurement has one path.

Validation and Evidence

Three runs, 20,000 reads each, separated by five idle minutes so no measurement window overlaps another. Billed ECPUs are read from CloudWatch's ElastiCacheProcessingUnits after every run has finished and published.

Security and Cost

What this means for a platform team

Size a cache from payload, not from request rate. The request-per-second figure on the dashboard is the number everyone quotes in a capacity review, and on ElastiCache Serverless it carries almost no information about cost. Two services with identical traffic profiles can differ by two orders of magnitude on the invoice because one of them caches rendered HTML and the other caches integers.

The practical control is the value itself. Caching a 100 KB serialised object where a 1 KB identifier would do is not a style preference at this price; it is the dominant term.

On security, two things are worth copying regardless of engine: the cache has no public endpoint and cannot be given one, and encryption in transit is mandatory and cannot be disabled. Neither needed configuring — which is the right default for a datastore.

Cost

Measured: $0.078 from Cost Explorer, for a cache that existed about thirteen hours. Cost Explorer splits it in a way worth reading closely:

Storage was 83% of the bill, and almost all of that was the 100 MB floor on a cache holding a few hundred kilobytes.

The ECPU figure is larger than this experiment: the three measured runs account for 2.2 million of those 5.6 million, with the rest from earlier attempts that were discarded. Following this lab once costs about half a cent in ECPUs, plus the storage floor for as long as the cache exists.

That ratio is the lesson in miniature. The workload everyone would have budgeted for cost a fifth of the idle floor nobody would have thought to budget for.

Troubleshooting and Lessons

Problem. The first run died with ReadTimeoutError: Read timeout on endpoint URL while invoking the Lambda.
Root cause. Two layers. boto3 stops waiting for a response after 60 seconds by default, well short of the function's 300-second timeout; and 200,000 sequential round-trips genuinely exceeded that 300 seconds. CloudWatch recorded Duration: 300,000 ms and one error.
Resolution. An explicit read_timeout on the boto3 client, and 20,000 requests rather than 200,000.
Lesson. A serverless cache answers in about a millisecond and a loop of 200,000 of them does not finish in five minutes. Per-operation latency and total runtime are different questions.

Problem. The first measurement reported 10 KB values billing fewer ECPUs than 1 KB values.
Root cause. The CloudWatch windows were five minutes wide and overlapped each other, so each figure included a neighbouring run. A second attempt fixed the overlap but still queried too early and caught only the first of the two minutes each run spans.
Resolution. Idle gaps between runs, and the measurement taken after all three have finished publishing.
Lesson. Bytes moved set a floor on ECPUs, so a billed figure below that floor is impossible rather than surprising. The runner now refuses to print any result below it, which is what caught both attempts.

Problem. The remote apply failed with No valid credential sources found.
Root cause. The workspace is created on first terraform init and starts with no variables, so an HCP run has no way to reach AWS.
Resolution. Set TFC_AWS_PROVIDER_AUTH and TFC_AWS_RUN_ROLE_ARN on the workspace, which is how every other week in this series authenticates.
Lesson. A new workspace is not a configured workspace, and the error names the symptom rather than the cause.

Cleanup and Key Takeaways

Teardown is verified against the API rather than the destroy output — a destroy reports what Terraform removed, not what is left in the account. The cache and the function are both checked by name.

Key takeaways

References

• The full lab guide
• Amazon ElastiCache pricing — ECPUs, and the minimum billed storage per engine
• Metrics for Valkey and Redis OSS serverless caches — ElastiCacheProcessingUnits
• Getting started with ElastiCache Serverless — TLS is always on
• Terraform — aws_elasticache_serverless_cache
• valkey-py — the client, not present in the Lambda runtime