Multi-Account AWS Governance

Most estates reach twenty-plus AWS accounts without anyone having designed the shape. They accumulate — one per team, one per environment, a few nobody can identify. The result is predictable: nobody can say with confidence who can reach production, and cost attribution is guesswork.

What we look at

• Account and organizational unit structure against how the business is actually organised
• Service control policies, permission boundaries and role assumption paths
• Cross-account networking — transit gateways, peering, endpoint routing and what it costs
• Whether new accounts are provisioned from a baseline or hand-built each time
• Tagging and cost allocation, which is normally the gap blocking everything else

What you get

A documented account structure with the reasoning written down, guardrails enforced through service control policies rather than convention, a repeatable path for provisioning new accounts, and network boundaries that match your actual security model. Delivered as infrastructure as code so your team can extend it.

On scope

If the honest answer is that you have too many accounts and should consolidate, that is what you will hear. Multi-account done badly is worse than a single account done carefully.