Cloud consulting, without the multi-cloud tax.

Account structure is a security decision and a cost decision at the same time. AWS’s own multi-account guidance says dedicated accounts establish “clear security, access, and billing boundaries” that keep a problem in one part of the estate from spreading to the rest, and because an account is the default unit AWS allocates costs to, separate accounts per business unit and workload make spend easier to report, forecast and budget. All three clouds give you the same building blocks under different names:

The providers’ own guidance on arranging those blocks converges on a few rules:

• Keep workloads out of the top of the hierarchy. AWS recommends keeping all resources out of the management account, not least because service control policies do not apply to it. On Azure, a default management group for new subscriptions keeps them from landing directly under the root.
• Separate the platform from the products. AWS’s recommended OU structure puts security and shared infrastructure accounts in their own Security and Infrastructure OUs, apart from the Workloads OU. Azure’s equivalent is a platform management group under the root; on GCP, Google recommends separate folders for bootstrap resources and common services.
• Split production from non-production at the account boundary. Separate accounts for production and non-production keep each environment’s resources and data apart by default, so each can carry its own security and operational controls. Azure’s guidance is to do this with separate subscriptions, not separate management groups per environment.
• Give experiments a sandbox. AWS’s Sandbox OU groups the accounts used for experimentation, typically with limited access to production resources; Azure’s sandbox management group isolates experiments from development, test and production environments.
• Set guardrails high, and keep them few at the root. On AWS, a deny attached at the root or an OU applies to every account beneath it; on GCP, every descendant inherits an organization policy by default. Azure’s guidance is to limit policy assignments at the root management group, which keeps inherited policies easier to debug further down.
• Provision new accounts from code. Each new account should arrive with the landing zone’s identity, networking, security, logging and billing structure already in place, which is the Terraform side of a landing zone.

In engagement terms this is the landing-zones line in the deliverables above: AWS Organizations and SCP design, Azure management groups and Policy, GCP folder structure and Org Policy, and the network topology (Transit Gateway, hub-and-spoke) that connects the accounts.