If your team is already deploying with CDK, a natural next step past a bare Lambda is a purpose-built construct - an npm package that wraps EventBridge Scheduler, IAM, and the start/stop calls behind a typed new ScheduledResource(...) API you drop into your own stacks. It fits your existing deploy pipeline and stays entirely in your account. Runless takes the opposite approach: nothing to add to your CDK app, a cross-account role instead.

🧱

CDK scheduler construct

• Runs inside your own CDK app and AWS account - no external service
• Usually free/open-source, cost is your own EventBridge and Lambda usage
• Schedules are defined in code and deployed like any other infrastructure change
• Changing a schedule means a code change, review, and deploy
• No dashboard, no manual override UI - the construct's job ends at deploy time
• Multi-account rollout means including the construct in every account's CDK app

Runless

• Nothing to add to your CDK app - one Quick Start stack per AWS account
• Schedule changes happen in the dashboard, no deploy required
• One control plane manages every connected account and tenant
• Manual override, live status, and per-resource savings tracking included
• Non-engineers on the team can adjust schedules without touching code
• Fixed monthly cost instead of construct-maintenance time

When a CDK construct is the better fit

If your schedules genuinely belong in version control - they change rarely, alongside other infrastructure changes, and are reviewed the same way - keeping scheduling as code in your own CDK app avoids adding an external dependency at all.

When Runless is the better fit

If schedules change often, need a manual override that doesn't wait for a deploy, or need to cover multiple AWS accounts and give non-engineers a way to adjust them, Runless removes the code-review-and-deploy step from what should be a quick operational change. See how account linking works or start with Early Access.