Scheduling AWS Lambda Function
lambda:PutFunctionConcurrencyCan ZopNight schedule AWS Lambda Function?
Lambda schedules set reserved concurrency to 0 via lambda:PutFunctionConcurrency, which throttles every invocation during the window, then restore the reservation saved at stop, or remove the limit with lambda:DeleteFunctionConcurrency if there was none. An idle function already costs $0, so the schedule buys a hard activity freeze, not a compute saving. Blocked async events retry, then divert.
How the stop works
| Field | Value |
|---|---|
| Behaviour | reserved concurrency set to zero via lambda:PutFunctionConcurrency on stop, blocking invocations; the limit is removed via lambda:DeleteFunctionConcurrency on start. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
A hard block, not a pause
Reserved concurrency of zero means no execution environment may ever run. Synchronous callers get throttling errors immediately. Nothing queues inside Lambda itself and nothing is billed, because nothing runs. The morning start does not “resume” anything. It simply lifts the limit so new invocations succeed.
Why schedule something that costs nothing when idle
Lambda bills per invocation, so a function nobody calls at night is already free. The schedule earns its keep differently: it freezes activity. A function that hammers a scheduled-off RDS instance, calls a rate-limited third-party API, or must not run during a change window can be made provably inert from 7pm to 7am. The saving, when there is one, lives downstream of the function.
Where the blocked events end up
Each event source reacts in its own way. Async invocations are retried twice over a few hours, then land in the failure destination or dead-letter queue if one is configured, and vanish if not. SQS-sourced messages stay safely in the queue and process at start, provided retention outlasts the window; the default 4 days is ample for any overnight schedule. Event source mappings for streams pause and resume with position kept. Know which of these applies before the first night, because the no-DLQ async case genuinely loses events.
Start restores the saved reservation
At stop, ZopNight reads the function’s reserved concurrency and saves it in the
zopnight:saved-concurrency tag before setting it to 0. The morning call restores that value with
lambda:PutFunctionConcurrency, so a function that ran with a deliberate reserved concurrency of 50
comes back at 50. Only a function that had no reservation before scheduling gets
lambda:DeleteFunctionConcurrency, returning it to the unreserved account pool. Removing or
editing the tag during the window changes what start restores.
Provisioned concurrency is a separate meter
Provisioned concurrency bills by the hour regardless of this schedule. Zeroing reserved concurrency on a function that also has provisioned concurrency blocks invocations while the warm environments keep billing. Schedule or remove the provisioned config itself for that saving.