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 remove the limit with lambda:DeleteFunctionConcurrency at start. 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 removes the limit rather than restoring it
The morning call is lambda:DeleteFunctionConcurrency, which deletes the reserved concurrency
setting entirely. A function that ran with a deliberate reserved concurrency of 50 before
scheduling comes back with no reservation at all, drawing from the unreserved account pool. If
a function relies on a specific reservation for throughput isolation, re-apply it after start, because
the schedule does not know the old number.
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.