Global Enterprise Multi-Account Scenario

Goal

Bring the chapter together in one realistic recommendation for a large organization with both central control needs and independent delivery teams.

The earlier sections explained the mental model, the hierarchy, the landing zone, and platform boundaries. This section shows how those ideas combine in a conversation-ready enterprise design.

The Short Version

A practical enterprise AWS environment uses accounts as ownership boundaries, OUs as control groupings, a landing zone as the prepared operating model, and central accounts for security, logging, and platform capabilities that should not be reinvented per team.

The durable idea is:

Multi-account AWS design succeeds when governance follows clear boundaries and teams inherit a prepared operating environment.

The Scenario

A global enterprise has:

• Twenty business units.

• Several regulated workloads.

• Shared platform services used across many teams.

• Central security and finance functions that need visibility.

• Application teams that still need to deploy independently.

The wrong response is to choose either total centralization or total freedom.

The better response is to design an estate where each boundary has a reason.

A Practical Organization Shape

One sensible model could look like this:

Organization root
  -> Security OU
      -> Log archive account
      -> Security operations account
      -> Audit account
  -> Platform OU
      -> Shared networking or DNS account
      -> Identity or access support account
      -> Shared tooling account
  -> Production workload OUs
      -> Business-unit production accounts
  -> Non-production workload OUs
      -> Business-unit development and test accounts
  -> Sandbox OU
      -> Temporary experiment accounts

The exact naming is less important than the control story behind it.

Why This Shape Works

This layout gives the enterprise several useful properties:

• Clear isolation. Production workloads are separated from development and experimentation.

• Central evidence. Logging and security views can converge in dedicated accounts.

• Delegated autonomy. Business units operate their own workload accounts without sharing one oversized administrative surface.

• Repeatable onboarding. New accounts can be provisioned into the correct OU with the correct baseline through the landing-zone workflow.

• Cost clarity. Spending can be mapped more directly to business units, environments, and platforms.

This is especially important for global enterprises because scale amplifies ambiguity. Weak boundaries do not stay weak in one corner of the estate. They multiply.

How Teams Would Work Day To Day

In this model:

• Central platform teams maintain the landing zone, shared tooling, and common cross-account services.

• Security teams own organization-wide visibility, investigation support, and selected guardrails.

• Finance teams review consolidated cost data and account-level ownership patterns.

• Workload teams deploy and operate their applications inside their own accounts and environments.

Notice that no group needs to own everything. The model works because responsibilities are separated intentionally.

Trade-Offs The Architect Should Explain

An enterprise recommendation should not pretend there is no cost.

The architect should say these trade-offs out loud. Enterprises trust governance models more when the costs are explicit rather than hidden.

Recommendation Narrative

If asked for a recommendation, a strong answer could sound like this:

1. Use AWS Organizations as the governing structure for the estate.

2. Group accounts into OUs based on control and lifecycle patterns, not only org-chart labels.

3. Maintain dedicated central accounts for logging, security visibility, and shared platform capabilities.

4. Provision new accounts through the landing-zone workflow so they inherit baseline controls and access patterns.

5. Keep workload ownership in the workload accounts, even when shared services and central evidence exist.

That recommendation is practical because it balances control and autonomy instead of choosing one side rhetorically.

Common Mistakes

• Copying a small-company layout into a large enterprise. Enterprise scale usually needs clearer separation of control patterns, central evidence, and onboarding automation.

• Using OUs with no operating meaning. A label such as "Business Unit A" is not enough unless it also helps explain governance behavior.

• Forgetting cost and evidence. Multi-account design is not complete if nobody can explain where the logs go or who owns the bill.

• Letting central teams become the deployment path. The point of the model is safe team independence, not ticket-driven cloud usage.

If Someone Asks You

If someone asks, "What does a practical enterprise multi-account AWS design look like?" a clear answer is:

It uses AWS Organizations to group accounts by control pattern, keeps dedicated security, logging, and platform accounts centrally, provisions workload accounts through a landing-zone workflow, and lets business units operate independently inside those inherited guardrails.

What You Should Remember

Multi-account design works when every boundary has a reason: control, ownership, evidence, cost, or team independence.

The most important idea is this:

An enterprise AWS structure is successful when teams inherit safety and still keep room to move.

Questions to Check Your Understanding

1. Which accounts usually need to exist centrally in a large AWS estate?

2. Why should OU design reflect control patterns rather than just reporting lines?

3. What trade-offs should an architect make explicit when recommending a multi-account model?

Further Study

• Organizing Your AWS Environment Using Multiple Accounts - Official AWS guidance on enterprise-scale multi-account strategy and isolation boundaries.

• What Is AWS Control Tower? - Official AWS overview of landing-zone governance and multi-account orchestration.