--- title: 'Scheduling AWS Instances Across Multiple Accounts' description: 'Running dev and staging across several AWS accounts multiplies both the waste and the work. Here is how to schedule and see savings across all of them.' date: '2026-06-13' readingTime: '6 min read' --- A single AWS account is rare once a team grows past its first year. You end up with separate accounts for production, staging, and development, often one per team, usually under AWS Organizations. It is good hygiene. It also quietly multiplies the idle-resource problem, because every account has its own dev and staging boxes running around the clock, and every account is its own place to go and fix that. ## Why Multiple Accounts Make Idle Waste Worse The waste itself is the same as in a single account: non-production EC2 and RDS running nights and weekends when nobody is working. For the maths on that, see [how much idle dev and staging environments really cost](/blog/cost-of-idle-dev-environments). Multiple accounts change two things. First, the waste is spread out, so no single bill looks alarming. Five accounts each wasting $400 a month is $24,000 a year, but nobody sees the $24,000. They see five unremarkable line items. Second, the fix has to be repeated. Whatever you do to schedule one account, you do again for the next, and the next. That repetition is where good intentions die. ## The Per-Account Tax of the Free Tools The free options work, but they were built per account, and it shows. AWS Instance Scheduler is a CloudFormation deployment. Five accounts means five stacks to deploy, five sets of schedules to keep in sync across DynamoDB tables, and five places to check when something looks wrong. When AWS updates the solution, you update it five times. Cross-region multiplies it again. (For a head-to-head, see ParkMyAWS as an [AWS Instance Scheduler alternative](https://parkmyaws.com/aws-instance-scheduler-alternative).) A DIY Lambda has the same shape with extra plumbing. To act on other accounts from one place, you set up cross-account IAM roles and assume-role logic, then maintain it as accounts come and go. The prototype that worked for one account becomes an internal tool with an org chart's worth of edge cases. In both cases the per-account tax is paid in engineering time, and it grows with the number of accounts rather than staying flat. ## What Good Multi-Account Scheduling Looks Like The bar is simple to state: - Set a schedule once and apply it wherever it is needed, without redeploying anything. - Connect each account with a least-privilege role (start, stop, describe), not shared admin credentials. - See every account's resources and schedules in one place, so an unscheduled box in account four is not invisible. - See the savings added up across all accounts, so the $24,000 is a number someone can actually look at. The first three are about effort. The last one is about whether the savings survive, which is the part teams underestimate. ## The Visibility Problem at Scale Scheduling across many accounts is only half the job. The other half is knowing it is still working, and that gets harder with each account you add. Cost Explorer can show cross-account spend if you have the management account and consolidated billing set up, but reading "did our schedules actually save money this month" out of it, per account, is a chore nobody does after the first time. So the common failure is silent: a schedule in one account stops firing, that account drifts back to 24/7, and because its bill was never large on its own, nobody notices for two quarters. The only durable defence is a single view that answers, at a glance, what is scheduled and what was saved across every account. Without it, multi-account scheduling decays one account at a time. ## How ParkMyAWS Handles Multiple Accounts This is the case [ParkMyAWS](https://parkmyaws.com) was built for. You connect each AWS account with its own cross-account IAM role, and all of them appear in one dashboard. You set schedules in a web UI rather than per-account CloudFormation or DynamoDB, and the saved amount is tracked and totalled across every connected account, so the spread-out waste becomes one visible number. Nothing runs inside your accounts except the IAM role. The scheduling itself runs from our infrastructure, so there is no per-account stack to deploy or upgrade. The honest trade-offs are the usual ones for a managed tool. It is a subscription, and you grant a role in each account. If your security policy forbids third-party roles, the per-account free tools are the route, and they work; you are choosing to spend engineering time instead of subscription money. And ParkMyAWS is AWS-only, so it does not help with Azure or GCP accounts. ## Where to Start You do not have to connect everything at once. Start with the account that has the most expensive non-production resources, schedule those for nights and weekends, and confirm the savings show up. Then add the next account. Because the schedules live in one place, the second account takes minutes rather than another deployment. To size the opportunity before you connect anything, run your instances through the [free idle-cost calculator](/aws-idle-cost-calculator). If you are also weighing how RDS behaves when stopped, read [why stopped RDS instances restart after 7 days](/blog/rds-auto-restart-7-days) first, because that catches a lot of teams out. When you want scheduling handled across all your accounts with the savings in one view, [try ParkMyAWS](https://parkmyaws.com) on the first account and add the rest from there.