Lambda Provisioned Concurrency for Weekday Attendance Peaks

The bottleneck is compute initialization, not table capacity. The recurring weekday pattern and the statement that gradual growth is tolerable point to Lambda cold starts: when many concurrent invocations arrive at once, Lambda must create new execution environments, and those requests pay initialization latency. Provisioned concurrency keeps a pool of initialized environments ready, and scheduled auto scaling raises that pool before the known attendance peak. That is exactly option A.

Why DynamoDB is the wrong focus. The table is in on-demand capacity mode, which is designed for spiky, unpredictable traffic and does not require capacity planning. A competing comment argues that on-demand can only instantly absorb up to twice the previous peak and proposes option D, fixed provisioned capacity at peak. That argument would matter only if the scenario showed DynamoDB throttling or a spike beyond the documented allowance; here the symptom is slow performance during a predictable daily surge, and switching to provisioned capacity does not warm Lambda execution environments. Option C adds DynamoDB auto scaling, but reactive scaling is not pre-warming and can still lag a sudden burst.

Eliminate the concurrency trap. Option B sounds similar because reserved concurrency also concerns Lambda concurrency, but reserved concurrency sets a maximum or guaranteed concurrency limit; it does not pre-initialize environments and does not reduce cold-start latency. Option A is the only choice that combines pre-initialized execution capacity with a schedule aligned to the weekday peak.

Decision. Choose A: configure provisioned concurrency with scheduled auto scaling for the Lambda functions. The scheduled action should increase provisioned concurrency shortly before the weekday spike and reduce it afterward.