AWS Lambda Function
Does ZopNight manage AWS Lambda Function?
AWS Lambda bills per request plus GB-seconds, meaning memory allocation multiplied by execution time, so an oversized memory setting inflates every single invocation. ZopNight tracks 90 days of invocation, duration, and concurrency metrics, recommends memory rightsizing and arm64, and can block non-production functions on schedule by setting reserved concurrency to 0.
Rules that fire on AWS Lambda Function
At a glance
| Field | Value |
|---|---|
| Stop verb | lambda:PutFunctionConcurrency |
| Scheduling notes | reserved concurrency set to zero via lambda:PutFunctionConcurrency on stop, blocking invocations; the limit is removed via lambda:DeleteFunctionConcurrency on start. |
AWS Lambda runs code on demand, billed per request and per GB-second of execution. While Lambda is pay-per-use, functions with provisioned concurrency, oversized memory settings, or runaway invocation loops can still generate significant cost.
The GB-second is the unit to understand
Every invocation bills a flat per-request fee plus duration: memory allocation multiplied by execution time, metered in GB-seconds at millisecond granularity. Memory is the price lever. A function allocated 3,008 MB bills roughly 6 times the per-millisecond rate of the same code at 512 MB, whether or not it touches the memory. Provisioned concurrency is the exception to pay-per-use: it bills per GB-hour for capacity kept warm, invoked or not.
Where serverless bills grow
Memory set high to be safe and never revisited, taxing every invocation. Provisioned concurrency configured for a launch event and left running. Runaway loops, where a function retriggers itself through S3 events or SQS retries, turning per-invocation fractions of a cent into real money. And generous timeouts that let a hung function bill for minutes instead of milliseconds.
Scheduling without a stop button
A Lambda function has no off switch, so ZopNight blocks it instead: at the scheduled stop it sets reserved concurrency to 0 via lambda:PutFunctionConcurrency, which throttles every invocation attempt, and at start it removes the limit via lambda:DeleteFunctionConcurrency. This fits non-production functions driven by schedules and queues that should stay silent overnight. Callers see throttles during the blocked window, so it is deliberately not applied to anything user-facing.
Discovery and metrics
Functions are found every 6 hours via Resource Explorer 2. Hourly CloudWatch metrics (invocations, duration, errors, concurrency) run with a 90-day lookback, and per-function cost comes from Cost Explorer or CUR 2.0. Recommendations cover memory rightsizing and migration to arm64 Graviton, which bills a lower per-GB-second rate for the same work.
The three numbers in the console
Lambda console, then Functions. A function’s Configuration tab holds memory, timeout, and concurrency: the three numbers behind most Lambda cost surprises.