No history yet

Centralised Multi-Account Governance

Beyond a Single Account

As an organisation grows, managing everything within a single AWS account becomes risky and inefficient. A mistake in one project could impact another, billing becomes a tangled mess, and security permissions get complicated. The solution isn't to be more careful; it's to adopt a better structure.

This is where a multi-account strategy comes in. By using separate AWS accounts for different teams, environments (like development and production), or projects, you create clear boundaries. This limits the 'blast radius' of any potential incident, simplifies cost tracking, and streamlines security. Managing all these accounts, however, requires a central hub.

Using multiple AWS accounts to help isolate and manage your business applications and data can help you optimize across most of the AWS Well-Architected Framework pillars, including operational excellence, security, reliability, and cost optimization.

That hub is AWS Organizations It’s a service that lets you centrally govern and manage your environment as you scale your AWS resources. You can group accounts, automate account creation, and apply policies across your entire fleet of accounts from one place.

Designing Your Organisational Structure

At the heart of AWS Organizations is a hierarchical structure. It all starts with the 'management account'. This is the parent account that creates the organisation. All other accounts, called 'member accounts', are nested underneath it. This structure gives you a powerful tool for control and visibility.

To keep things tidy, you can group related accounts into (OUs). Think of OUs like folders on a computer. You wouldn't store all your files on the desktop; you'd create folders for 'Work', 'Photos', and 'Projects'. Similarly, you can create OUs for 'Security', 'Infrastructure', and 'Workloads'. The 'Workloads' OU might even have nested OUs for 'Production' and 'Development'. This hierarchy allows you to apply policies and controls to entire groups of accounts at once.

One of the most immediate benefits is consolidated billing. All costs from member accounts roll up to the management account. This gives you a single bill and a holistic view of your organisation's spending. You can also centrally manage tax information and take advantage of volume-based discounts, as AWS combines the usage from all accounts.

Setting Up Inescapable Guardrails

While OUs provide structure, (SCPs) provide enforcement. SCPs are a type of policy that you can attach to the organisation root, an OU, or an individual account. They act as 'guardrails', defining the maximum permissions available to any user or role in the accounts they affect.

It's important to understand that SCPs do not grant permissions. Instead, they act as a filter. An IAM user can only perform an action if it is allowed by both their IAM policy and the relevant SCPs. If the SCP denies the action, it's blocked, no matter how permissive the user's IAM policy is. This makes them perfect for setting broad, preventative controls across your organisation.

Here are some common security measures you can enforce with SCPs:

Restrict AWS Regions: To reduce your attack surface and comply with data residency requirements, you can create an SCP that denies access to all AWS Regions except the ones your company actively uses.

Deny Root User Access: The root user has unrestricted access, so its use should be avoided for everyday tasks. An SCP can block all actions for the root user in member accounts, forcing the use of IAM roles with more limited permissions.

Prevent Disapproved Services: If your organisation has standardised on certain services, you can use an SCP to block access to unapproved ones, preventing shadow IT and ensuring architectural consistency.

Below is an example of an SCP that prevents member accounts from leaving the organisation. This is a critical control to ensure that accounts remain under central governance.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

By attaching this SCP to the root of your organisation, you ensure no member account can detach itself, accidentally or maliciously.

Building a Secure Foundation

Combining these elements—a well-designed OU structure, consolidated billing, and powerful SCPs—allows you to build a 'landing zone'. A landing zone is a pre-configured, secure, and scalable multi-account environment that serves as a starting point for all your organisation's workloads. It establishes a baseline for security and compliance that all new projects automatically inherit.

For example, a typical landing zone includes a dedicated 'Log Archive' account that collects and stores logs from all other accounts. It also has a 'Security Tooling' account where services like AWS Security Hub or Amazon GuardDuty are managed centrally. This approach ensures that security isn't an afterthought but a foundational part of your cloud infrastructure.

Finally, AWS Organizations facilitates secure cross-account resource sharing. Using services like AWS Resource Access Manager (RAM), you can share resources like VPC subnets or Transit Gateways from a central networking account with your workload accounts. This avoids duplicating resources, reduces operational overhead, and ensures consistent network configuration.

Quiz Questions 1/5

What is the primary purpose of AWS Organizations?

Quiz Questions 2/5

In the context of AWS Organizations, what is the function of a Service Control Policy (SCP)?

Centralised governance transforms AWS from a collection of isolated accounts into a cohesive, secure, and cost-efficient enterprise platform. It's a foundational step for scaling your cloud operations responsibly.