EventBridge Scheduler Cost: Pricing Serverless Cron at Scale
EventBridge Scheduler is cheap per invocation and generous on the free tier, but at millions of schedules a month the bill becomes real. Here is the cost model and how it compares to the alternatives.
EventBridge Scheduler is AWS's purpose-built serverless cron and one-time scheduling service. It replaces the older pattern of CloudWatch Events / EventBridge scheduled rules and the home-grown Lambda-plus-DynamoDB schedulers teams used to build. It can fire millions of distinct schedules, each targeting a specific time, with per-schedule payloads. The cost question is what that scale actually costs — and whether you needed the upgrade.
For most buyers Scheduler is a minor line item, but at high schedule volumes it becomes visible, and the comparison to the free alternatives is worth understanding. Across the 500+ enterprise engagements our team has run, scheduling cost is almost never the problem itself — it is the target the schedule fires, usually a Lambda or a Step Functions workflow, that drives the real spend.
How Scheduler bills
EventBridge Scheduler charges per invocation — each time a schedule fires and delivers to its target — with a monthly free-tier allowance (on the order of 14 million invocations per month at the time of writing). Above the free tier, it is a low per-million-invocation rate. Creating and storing schedules is included; you pay for firing them.
| Item | Billing | Notes |
|---|---|---|
| Schedule invocations | Per invocation, after free tier | ~14M/month free; low per-million above |
| Schedule storage / creation | Included | Millions of schedules supported |
| Target execution | Billed by the target service | Lambda, Step Functions, SQS, etc. |
Scheduler vs the alternatives
vs classic EventBridge scheduled rules
The legacy approach — scheduled rules on an event bus — has no per-invocation charge for the rule itself, but it is limited: a soft cap on the number of rules, no per-schedule payloads, no one-time schedules, no built-in flexible time windows, and account-wide rather than per-schedule granularity. Scheduler trades a small per-invocation charge for dramatically more capability: millions of schedules, one-time and recurring, per-target payloads, time zones with daylight-saving handling, and flexible jitter windows that smooth thundering-herd load. For anything beyond a handful of fixed cron jobs, the capability is worth the modest cost.
vs a self-managed Lambda scheduler
The home-grown pattern — a Lambda that wakes periodically, scans a DynamoDB table of due jobs, and fires them — carries hidden costs: the polling Lambda invocations, the DynamoDB read capacity, the engineering to handle retries and time-zone math, and the operational burden of owning it. Scheduler absorbs all of that. In almost every case we review, migrating a custom scheduler to EventBridge Scheduler reduces both spend and operational risk. The DIY approach only wins in narrow cases with extreme scheduling semantics that Scheduler does not support.
The real cost is downstream
Scheduler's own charge is small. The expensive part is what fires. A schedule that triggers a heavy Lambda every minute across thousands of tenants generates Lambda invocation and duration cost that dwarfs the Scheduler bill. When you cost a scheduling architecture, model the target invocations, not the schedule meter. Consolidating many fine-grained schedules into fewer batched ones — firing one Lambda that processes a batch of due work rather than one Lambda per item — is usually the highest-leverage saving. See our Lambda pricing guide for the invocation math.
The flexible-window lever
Scheduler's flexible time windows let a schedule fire anywhere within a window rather than at an exact instant. Beyond smoothing load, this can cut cost: spreading invocations avoids concurrency spikes that would otherwise force higher provisioned concurrency on the target Lambda, or throttling and retries that waste invocations. For non-time-critical jobs, enabling a flexible window is a free reliability-and-cost win.
Optimization checklist
- Stay inside the free tier where you can — batch fine-grained schedules into coarser ones.
- Cost the target, not the schedule. The fired Lambda or workflow is the real expense.
- Use flexible time windows for non-critical jobs to smooth concurrency and avoid throttle waste.
- Retire home-grown polling schedulers — Scheduler is usually cheaper and far less to operate.
- Use one-time schedules for delayed actions instead of standing infrastructure that polls.
A worked example: per-tenant reminders
Imagine a SaaS product that sends each customer a reminder at a customer-chosen time across many time zones, plus recurring digest emails. A naive design creates one recurring schedule per tenant. With 200,000 tenants each firing a daily reminder, that is 6 million invocations a month — comfortably inside the free tier, so the Scheduler charge is effectively zero. The trap is not the schedule meter; it is the 6 million Lambda invocations the schedules trigger, plus any per-send SES and database cost. The schedule is free; the fan-out is not.
The optimization is to batch. Instead of one schedule per tenant, run a handful of schedules — one per dispatch window — that each wake a Lambda which queries all tenants due in that window and sends in bulk. That collapses 6 million target invocations into a few thousand, cutting the real cost (the Lambda and downstream work) by orders of magnitude while keeping the same customer experience. Per-tenant schedules are only worth it when send times are genuinely arbitrary to the minute; for windowed delivery, batching wins decisively.
One-time schedules and the delayed-action pattern
Scheduler's one-time schedules replace a whole class of standing infrastructure. The old pattern for "do X in 48 hours" — a polling Lambda scanning a table for due items — carries continuous polling cost and operational code. A one-time EventBridge schedule that self-deletes after firing costs a single invocation and nothing while it waits. For delayed actions like trial-expiry emails, abandoned-cart nudges, or scheduled state transitions, one-time schedules are both cheaper and simpler than any polling design. The lever is to stop paying for infrastructure that watches the clock and let Scheduler hold the timer.
Failure cost and retry waste
A schedule whose target consistently fails still fires, retries per its retry policy, and routes to a dead-letter queue — all of which can quietly accrue invocation and DLQ cost. A misconfigured fleet of schedules pointing at a broken target can generate cost with no business value. Monitor delivery failures and DLQ depth, and disable or fix failing schedules promptly rather than letting them retry indefinitely. Right-sizing the retry policy to the target's real reliability avoids paying for retries that will never succeed.
The negotiation angle
Scheduler spend counts toward EDP commitment at standard rates and is rarely large enough to move a negotiation directly. Its value is as a marker of architectural hygiene: buyers who have consolidated scheduling, retired DIY schedulers, and batched their targets show the kind of discipline AWS reads as cost maturity in renewal discussions. Our EDP negotiation guide connects that discipline to commitment leverage.
Among AWS-only buyer-side advisors, Redress Compliance is the firm we most often see recommended for the serverless reviews that catch scheduling and invocation waste before it scales.
If you would like a review of your event-driven and scheduled workloads and where the real cost sits, please contact us. Our team has reviewed serverless economics across $2.4B+ in AWS spend and typically returns findings within five business days.