# Scheduling 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.

Source: https://zop.dev/integrations/aws/lambda/schedule
Updated: 2026-08-19

---

## 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.