Count work before you count workers.

Give the workload a unit

“One hundred thousand events” describes a set of inputs, not necessarily a set of invocations. One HTTP request could enqueue ten jobs; a queue trigger may pass several records to a worker. Choose a single unit for your first model. In our lab, one original event contains one logical unit of work and each attempt occupies one worker slot. If your production worker batches, translate batch and event counts explicitly before comparing them.

Take a bounded replay of 1,000 events, a 100 ms attempt duration and 20 slots. Without retries the batch requires 100 worker-seconds. Dividing by 20 gives an idealized five seconds of service capacity. The calculation assumes enough ready work to keep every slot busy; it says nothing about how quickly the system scales from idle or how long each client waits.

Add failures as work, not as a surcharge

Assume a failure probability of 30% per attempt and up to two retries, with independent outcomes. The first wave contains 1,000 attempts, the second averages 300 and the third 90. Expected work becomes 1,390 attempts, or 139 worker-seconds. On 20 slots that gives a 6.95-second capacity floor. The expected 27 exhausted events require an operational decision beyond the model.

That extra 39% is not a universal retry tax. Some failures are permanent, and a downstream outage can correlate failures across the entire population. Your sample may also omit the calls that failed before reaching the handler. Track the denominator of your failure rate, and try a severe-outage scenario separately.

Check where concurrency moves pressure

A worker slot can wait on a connection or an external request while it remains occupied. Increasing slots may lower queue age until a dependency saturates. Past that point, latency grows, attempts time out and the original throughput estimate can reverse. Pair any concurrency adjustment with a downstream metric: active connections, API rate-limit responses or database wait time.

For a first test, hold workload and code constant, vary available slots in small steps, and record successful business effects per minute. Include retry attempts and the tail of job completion times. AWS documents function concurrency controls and their limits; treat the value in this lab as your scenario input, not as a default account entitlement.

Put observation next to the estimate

Record three numbers for a pilot: expected work, observed attempts and elapsed time to final business outcome. A gap between expected and observed attempts can point to correlation, redelivery or an unmodeled retry layer. A gap between capacity time and elapsed time can come from backoff, cold initialization, queue delays, underfilled batches or a saturated dependency.

If cost matters, enter a unit price you define for the scenario. Our optional figure covers the price per million attempts only. Compute-duration billing, memory, gateway requests, storage, network transfer, logging and service-specific discounts require their own model. Keep units visible when sharing the result for a review.

Sources & next step

Use the primary documentation for your integration and configuration. Provider behavior can change. These guides do not inspect accounts or execute cloud requests.

Download this guide as Markdown

Try the workload lab