TCP #130: Multi-Account AWS Environments Fail When Nobody Owns the Boundaries
Why account sprawl, tenant separation, and shared services break down without explicit control-plane ownership.
Most engineering organizations adopted multi-account AWS for the right reasons.
The single-account deployment was sprawling. The blast radius was unacceptable. Compliance was difficult to scope.
The team split workloads across accounts: production, staging, and dev. Then a separate account for the data team. Then accounts for individual customer tenants. Then a logging account. Then a security tooling account.
By year three, the organization has 40 accounts. AWS Organizations holds the top of the tree. Control Tower, if the team adopts it, holds the bottom. The middle is unclear.
The accounts work. Workloads run in them. Bills are paid. But the boundaries between accounts, the rules about what crosses what and who decides, are owned by nobody.
When something goes wrong, the cost is visible. The data engineer cannot get cross-account access to the bucket they need. The compliance team cannot find the audit log for an action in the production account. The platform team discovers that three accounts have public S3 buckets nobody owns. The security team flags an IAM role assumption pattern that has been running for 14 months without review.
The accounts are not the problem. The boundaries between them are. And boundaries without owners produce the same outcomes as no boundaries at all.
Why Account Sprawl Happens
Multi-account architectures rarely start sprawling. They become sprawling because account creation is rewarded and account boundaries are not.
The team that needs isolation creates an account. Provisioning is fast; the security team approves it, and the workload comes in. The team is unblocked. Nobody asks who owns the account in 18 months, when the workload changes shape, who decides which other accounts can call into it, who reviews the IAM policies written into it, or who confirms that logging is exported to the central account.
The account becomes orphaned at the moment it is provisioned. The team that owns the workload owns the workload. The platform team owns the foundation. Nobody owns the account.
Multiply this by 18 months of provisioning decisions. The org chart shifts twice. The platform team turns over a third of its engineers. The compliance scope expands to a new framework. The original team that requested the account no longer remembers why they needed it.
The boundary that was clear at creation time is now ambiguous. The account is still running. The workload inside it is operationally healthy. The boundary between this account and the others is undefined, and the security team has no record of who would answer questions about it.
What Boundary Ownership Actually Means
Boundary ownership is not the same as account ownership.
The team that operates a workload owns the workload. They are responsible for the application, deployment, on-call rotation, and cost. This is straightforward, and most organizations get it right.
Boundary ownership is the layer above. It governs the rules about what crosses the account, in either direction. Specifically:
Identity boundary. Who can assume IAM roles in this account from outside, and what those roles can do? Who can assume IAM roles into other accounts from this one, and what those roles can do. Trust relationships, condition keys, session policies.
Network boundary. What VPC peering, Transit Gateway attachments, or PrivateLink endpoints exist into and out of this account? What CIDR ranges are routable? What ports are open at the security group level for cross-account traffic?
Data boundary. What S3 buckets, KMS keys, or other resources in this account can be accessed from other accounts? What buckets, keys, or resources in other accounts can this account access? Resource policies, bucket policies, KMS key policies.
Audit boundary. What CloudTrail, Config, GuardDuty, and Security Hub data flows out of this account into the central audit account? Whether the flow is enforced, whether it is verified, and who reviews it.
Cost boundary. Which cost center is the spend in this account allocated to? Whether the allocation is automatic via tagging policy or manual via accounting reconciliation. Who reviews variance?
Each of these boundaries has a different ownership profile. The team that runs the workload does not own the identity boundary. The platform team does. The compliance team does not own the network boundary. The networking team does. When ownership is explicitly named for each boundary, the team has a forwarding address for boundary-related questions. When ownership is implicit, the questions sit in nobody’s queue.
The Three Failure Patterns of Boundary Drift
Boundary ownership ambiguity produces three predictable failure patterns.
The shadow trust relationship. A workload in account A needs to read a bucket in account B. The team writes a bucket policy. The team writes a role with the right permissions. The role works. Nobody flags that the bucket policy now grants cross-account access. Six months later, a security review discovers the policy and cannot trace why it was written or whether it is still needed. Removing it might break the workload. Leaving it leaves an undocumented trust path. The team chooses to leave it. The trust path stays.
The audit gap. A new account is provisioned. The team configures the workload. The team forgets to enable CloudTrail forwarding to the central audit account. Eleven months later, the audit team is collecting evidence for SOC 2 Type II and discovers that the account's CloudTrail data has been missing for 11 months. The audit finding is significant. The remediation is a one-line configuration change that should have been made on day zero. Nobody owned the audit boundary, so nobody verified it.
The networking debt. Each new account is given a Transit Gateway attachment. The attachments accumulate. The CIDR ranges overlap or nearly overlap. The platform team does not realize this until a new account cannot peer because the CIDR space is exhausted. The fix is a re-IP project that takes a quarter. The cause was a boundary nobody was reviewing as accounts were created.
These patterns are not specific to one organization. They are predictable outcomes of the same root cause: boundaries without explicit owners drift, and drift compounds.
Four Questions That Surface Whether Your Boundaries Have Owners
Before the next account is provisioned, the platform team should be able to answer four questions in writing. If they cannot, boundary ownership is the work that needs to come before more accounts.
For each existing account, who owns the identity boundary? The named individual or team that approves cross-account role assumptions, reviews trust policies, and decides when a role can be assumed from a new principal. If the answer is “the platform team” without a specific person and a documented review cadence, the answer is no.
For each existing account, who owns the network boundary? The named individual or team that approves VPC peering, Transit Gateway attachments, and PrivateLink endpoints. The team that maintains the CIDR allocation registry. If the team cannot produce the registry, the boundary is unowned.
For each existing account, who verifies that audit data is flowing to the central account? Not configured. Verified. The difference is monthly: configuration drifts, forwarding breaks, and retention policies change. The team that owns audit boundary verification runs a monthly check. If no team runs the check, the audit boundary is unowned.
When a new account is provisioned, what is the first action that establishes ownership of each boundary? A defined process that names the identity boundary owner, the network boundary owner, the audit boundary verification owner, and the cost boundary owner before the account is handed to the workload team. If account provisioning does not include this step, every new account starts unowned.
These four questions are diagnostic. The honest answer reveals which boundaries are owned, which are partially owned, and which are not owned at all. Most organizations discover that one or two of the four are well known, while the others are not.
What Changes When Boundaries Have Owners
When boundary ownership is explicitly named, the failure patterns above stop occurring.
The shadow trust relationship is caught at creation. The identity boundary owner reviews the trust policy as part of the workload onboarding. Cross-account access has a documented justification, a documented review cadence, and a removal trigger if the workload changes.
The audit gap is caught within 30 days. The audit boundary owner runs a monthly verification. Configuration drift is detected before it becomes an audit finding. The CloudTrail forwarding question is answered before the auditor asks.
The networking debt is caught at the design phase. The network boundary owner maintains the CIDR registry and reviews each new attachment against the existing topology. Re-IP projects do not become quarter-long initiatives because the topology was managed instead of accumulated.
The platform team’s relationship to multi-account architecture changes. The team is no longer reactive to drift. The team is proactive about the boundary that prevents drift. The accounts continue to multiply as the workload portfolio grows. The boundaries stay coherent because they are owned.
Why This Is the Right Conversation Now
The teams most exposed to boundary drift are SaaS organizations expanding into regulated customer segments.
A SOC 2 Type II audit produces findings on boundary drift. A FedRAMP authorization fails on it. A HIPAA business associate agreement requires the organization to demonstrate control over the boundary, not just over the workload. A customer requesting tenant isolation in a separate account requires the organization to have a defensible model for what crosses the account boundary and what does not.
The cost of unowned boundaries is invisible until one of these events. By that point, the cost is high.
Teams that name boundary ownership before the next account is provisioned do not incur these costs in the same way. The boundary is owned. The boundary is reviewed. The boundary survives org-chart changes because it is documented. The audit, the customer, and the framework all encounter a defended boundary, not a boundary that has been drifting for two years.
On Wednesday, paid subscribers get the AWS Multi-Account Design Checklist for regulated SaaS platforms. The checklist covers account strategy, logging, identity, networking, tenant isolation, shared services, and audit evidence. Each section names the explicit owner, the verification cadence, and the artifact that confirms the boundary is intact. Use it to baseline your existing accounts before the next audit, or as the design document before the next account is provisioned.
Upgrade If You Need Implementation, Not Just Ideas
If you’re using these emails to guide real decisions on your platform, you’ll get more leverage from the paid version of The Cloud Playbook.
The free newsletter gives you patterns and language.
The paid newsletter turns those patterns into implementation kits you can ship inside a quarter:
Concrete rollout plans (90‑day roadmaps for each pattern)
Templates and checklists (policies, runbooks, tagging schemes, review checklists)
Real examples from high‑stakes AWS environments (what we actually shipped and why)
If the paid side doesn’t save you more than the subscription cost in a single incident, audit cycle, or bad migration you avoid, you should cancel and keep the playbooks.
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.