Cross-Account Cost Management

Once spend is spread across an organization, two things have to work: the management account must be able to see and budget for each member account, and a budget breach must reach the people who can do something about it — who are not in the management account.

What the management account can do

With consolidated billing, the management account can:

• Read cost and usage for every member account, filtered by account, service or tag. See Cost and Usage Reports.
• Create a budget per member account, per service, or per tag, and adjust each independently. See AWS cost management tools.
• Attach budget actions that apply an IAM or service control policy, or stop EC2 and RDS instances, when a threshold is crossed.

What it cannot do is show those budgets to the member account. A budget is visible only within the account that created it — a member account cannot see a management-account budget that tracks its own spend. That gap is what the pattern below closes.

Pushing alerts back to the account that caused them

graph LR B["AWS Budgets<br/>(management account)"] --> SNS["SNS topic"] SNS --> L["Lambda function"] L --> EB["EventBridge<br/>event buses in member accounts"] EB --> LA["Lambda in account A<br/>stop resources, notify owner"] EB --> LB["Lambda in account B<br/>stop resources, notify owner"]

1. Each member account has its own budget in the management account, filtered by linked account or by tag.
2. A budget alert publishes to an SNS topic. SNS fans out to as many subscribers as needed — email for the finance owner, a Lambda function for the automation.
3. The Lambda function reads the alert, works out which account it belongs to, and puts an event on that account’s EventBridge event bus. Cross-account event bus permissions are what make this leg possible.
4. A Lambda function in the member account handles the event locally: shutting down the development environment, notifying the owning team, or opening a ticket.

The value of the extra hop is that the response happens where the resources are, using local context and local permissions, rather than requiring the management account to hold rights over every workload account.

Budget alerts can also go straight to a chat application through SNS, which is often the right first step before building any of the above. Budgets refresh up to three times a day, so treat this as a control loop measured in hours, not seconds — it will not stop a runaway job in the first minute.

Making the numbers attributable

None of this is useful if spend cannot be attributed. Cost allocation depends on a tagging standard applied consistently across every account, enforced with tag policies in AWS Organizations. See tagging and resource groups.

The keys most organizations end up needing are environment, project, owner, team and cost centre. Agree them once, enforce them centrally, and audit them — a tag that is 80% applied produces cost reports nobody trusts, which is worse than none.