A common starting point: a Lambda function on an EventBridge cron schedule that calls ecs:UpdateService or ec2:StopInstances against a hardcoded or tag-filtered resource list. It works, and for a single account with a handful of resources it can be running in an afternoon. The cost shows up later, as the script grows.

🧑‍💻

DIY Lambda + EventBridge

• No subscription cost - only the Lambda invocations and your engineering time
• You write and own the IAM policy, retry logic, and error handling
• Manual overrides mean editing code or adding a second Lambda/parameter
• No dashboard - status lives in CloudWatch Logs unless you build one
• Multi-account or multi-team support means building tenancy yourself
• Savings reporting requires its own pricing-data pipeline

Runless

• Fixed monthly cost, no scheduling code to write or maintain
• Cross-account role with least-privilege permissions, external ID protection built in
• Manual on/off override from the dashboard, individually or in bulk
• Live status and cost-savings history per resource, no extra pipeline
• Tenant-level team management for multiple people managing the same accounts
• EventBridge scheduling and per-service grants are already handled for you

When a DIY script is the better fit

For a single account with one or two resources and an engineer who's already comfortable with EventBridge Scheduler, a small Lambda can be the pragmatic choice - there's no vendor relationship, and the surface area is small enough to reason about by hand.

When Runless is the better fit

Once you're maintaining schedules across multiple accounts or resource types, want a UI your team can use without reading Lambda code, or want manual overrides and savings tracking without building it yourself, the maintenance cost of the DIY script usually exceeds what Runless charges. Read how the cross-account role is scoped or start with Early Access.