Multi-Account Waste Estimator

AWS Organizations allows teams to manage multiple AWS accounts under a single billing umbrella. It's a recommended architecture for separating environments, controlling blast radius, and managing permissions — but it also means cost optimisation becomes a cross-account exercise. The estimator above helps you map your accounts by type and calculate the aggregate savings opportunity from scheduling non-production compute.

Cost Challenges in Multi-Account AWS

The cost management challenges in multi-account AWS environments are fundamentally the same as in single-account setups — idle instances, overprovisioned resources, unattached storage — but they're harder to see and harder to act on at scale. Each account has its own Cost Explorer view, its own set of instances, and its own billing history. Without a consolidated view, it's difficult to understand where the biggest opportunities lie across the organisation.

The Consolidated Billing feature in AWS Organizations helps by aggregating spend into a single invoice and enabling organisation-level Savings Plans and Reserved Instances that apply across accounts. But it doesn't give you visibility into which accounts have idle resources or which are good candidates for scheduling. That requires either manual auditing of each account or a tool that can connect to multiple accounts simultaneously.

Mapping Accounts by Environment

The first step in multi-account cost optimisation is mapping each account to an environment type. The standard taxonomy for AWS Organizations separates accounts into production, non-production (dev, staging, QA), shared services (networking, security tooling, logging), and sandbox. Each type has a different cost profile and a different approach to optimisation.

Production accounts are candidates for Savings Plans, right-sizing, and Reserved Instances. Non-production accounts are candidates for scheduling — the economics are compelling and the risk is low. Shared services accounts often have predictable, stable workloads that respond well to commitment-based discounts. Sandbox accounts are candidates for both scheduling and periodic termination of long-running idle instances.

Cross-Account Scheduling Strategy

Implementing scheduling across multiple AWS accounts requires connecting each account to your scheduling tool. In ServerScheduler, this means creating an IAM role in each account using a provided template and adding the account connection in the dashboard. Once connected, accounts appear in a unified view and schedules can be defined at the organisation level — apply the same schedule to all dev accounts simultaneously rather than configuring each one individually.

For teams using AWS Organizations service control policies (SCPs), it's worth defining a policy that enforces tagging requirements on new instances — requiring an Environment tag and an Owner tag. This makes it straightforward to apply schedules by environment tag across all accounts and ensures new instances are automatically included in the appropriate schedule. The multi-account management guide covers the governance layer in detail.

Governance and Cost Visibility at Scale

At organisation scale, cost governance becomes a cross-team coordination problem as much as a technical one. Different teams own different accounts, and cost optimisation decisions in one account affect another team's workflow. A clear policy framework — defining who can approve schedule changes, how exceptions are requested, and what the review cadence is — prevents friction and ensures the optimisation programme sustains itself beyond the initial implementation.

AWS Cost Explorer at the organisation level provides consolidated reporting, but the granularity of reporting depends on your tagging discipline. Accounts with consistent Environment, Team, and Project tags can produce team-level cost reports that make accountability clear. Accounts without tagging can only be attributed at the account level. Implementing a tagging standard before running the estimator gives you more actionable output from the tool. The broader infrastructure governance approach is covered in the infrastructure governance guide.

Implementing Cost Optimisation at Scale

A phased approach works best for multi-account optimisation. Start by connecting all accounts to your management tool and generating a baseline picture of spend by account and environment type. Then prioritise the highest-spend non-production accounts for scheduling — these deliver the largest absolute savings with the lowest risk. Roll out scheduling progressively, communicating with account owners before making changes.

Once scheduling is in place across non-production accounts, move to right-sizing. Use the data from your connected accounts to identify the most overprovisioned instances across the organisation — the EC2 right-sizing recommendations surface these automatically. Finally, use your stabilised production baseline spend to right-size your Savings Plans commitments. The Cost Savings Calculator helps you model each phase before implementation.