# Multi-Account Strategies and AWS Organizations

> Chapter 2 of the Courseiva AWS-SAP-C02 curriculum — https://courseiva.com/learn/aws-sap-c02/multi-account-strategies-and-aws-organizations

**Official objective:** 1.2 — Design a multi-account AWS environment using AWS Organizations

## Introduction

How do you stop a single mistake in one part of your cloud from bringing down the entire company? That is the exact problem solved by a multi-account strategy using AWS Organizations. It is crucial for the SAP-C02 exam because the Real-World of large companies uses dozens or hundreds of accounts, and you must be able to design a secure, cost-effective structure.

## The Apartment Building with Separate Unit Number Analogy

Ever lived in a big apartment building where the landlord gave every tenant their own key, but the building only had one front door? What happens when a family moves out and forgets to return their key? Now every new tenant needs a new lock, and you worry the old key will let strangers into your flat. 

That is exactly the problem 'Multi-Account Strategies' solves in the cloud. Think of a company as an apartment building: each department (like Engineering, Marketing, and Finance) is a separate flat. AWS Organizations is like the building management office — it issues unique key cards for each flat. Instead of everyone sharing one risky front door (a single AWS account), each department gets its own account, like a private flat with its own key. The building management can set rules: 'No flat can have a door that opens directly onto the street (no public S3 buckets allowed)' and 'Each flat’s alarm system must be a specific brand (only approved EC2 instance types)'. 

This way, if Marketing accidentally leaves their door open, only their data is at risk — not Engineering’s or Finance’s. And the building manager can see who enters which flat, which helps with audits. The whole system is called a 'multi-account strategy', and AWS Organizations is the tool that lets you design and control it without chaos.

## Core explanation

Let’s start with the most basic idea: an AWS account is a container. Inside a single AWS account, you can create all sorts of resources — virtual servers (EC2 instances), databases (RDS), storage buckets (S3), and so on. The problem is that if you put everything your company owns into one account, a single mistake (like accidentally making a storage bucket publicly readable) could expose *all* your data. Also, if one team uses a lot of expensive resources, you cannot easily see which department is burning money. 

A multi-account strategy fixes this by splitting your company’s cloud footprint across many separate AWS accounts. You might have one account for development, another for testing, and another for production. Or you might have an account per business unit: one for the sales team, one for the engineering team, one for the finance team. Each account is completely isolated by default — meaning if the development account gets hacked, the production account is safe. 

But managing hundreds of accounts manually is a nightmare. That is where AWS Organizations comes in. AWS Organizations is a free service that lets you create new AWS accounts, group them into logical units called Organisational Units (OUs), and apply policies across all of them at once. Think of an OU as a folder for accounts — for example, all accounts belonging to the 'Security' team can be placed inside a 'Security OU'. 

There are two main types of policies you can apply with AWS Organizations: Service Control Policies (SCPs) and Tag Policies. 

- **Service Control Policies (SCPs)** are like a guardrail. They define the maximum permissions for every user and role in an account. For example, you can write an SCP that says 'no one in any account in this OU can launch an EC2 instance larger than a certain size' or 'no one can delete S3 buckets'. SCPs do not grant permission; they only restrict what the account’s own IAM policies can allow. Think of them as a 'parental control' on the account. 

- **Tag Policies** help you enforce consistent tagging across all accounts. Tags are labels you attach to resources (like 'Environment: Production' or 'CostCentre: Marketing'). Tag Policies make sure everyone uses the same tag keys and allowed values, which makes billing reports much easier to read. 

- **AI services opt-out policies** allow you to control whether your organisation’s data can be used to improve AWS AI services. This is important for companies that handle sensitive customer data. 

- **Backup policies** let you deploy backup plans across all accounts, ensuring that critical data is always protected. 

- **Resource Control Policies (RCPs)** are similar to SCPs but apply to resources (like storage buckets) instead of users. They are newer and less common in exam scenarios. 

To use AWS Organizations, you start by designating one account as the 'management account' (formerly called the master account). This management account has full administrative control over everything. All other accounts become 'member accounts'. The management account can invite existing accounts to join the organisation, or you can create new accounts directly. 

Once accounts are in the organisation, you organise them into OUs. A common structure is: a root OU (the top-level container), then an OU called 'Security' for security-related accounts, an OU called 'Workloads' for application accounts, and an OU called 'Sandbox' for experimentation. Within 'Workloads', you might have sub-OUs like 'Dev', 'Test', and 'Prod'. 

Why bother with all this structure? Because you can attach different SCPs to different OUs. For example, your 'Sandbox' OU can have a very restrictive SCP that prevents users from launching expensive resources, while your 'Prod' OU can have a looser SCP. This allows you to give teams freedom while still maintaining central control over security and costs. 

AWS Organizations also enables consolidated billing. Instead of each account paying its own AWS bill separately, all charges are rolled into the management account’s bill. This gives you a single, unified invoice and lets you take advantage of volume discounts. You can also set up a 'Cost Explorer' or use 'Budgets' across all accounts. 

In short, AWS Organizations gives you a way to manage growth, enforce security boundaries, and simplify billing — all key requirements for any large cloud deployment. For the SAP-C02 exam, you must understand not just what it does, but when to use it for designing a well-governed multi-account environment.

## Real-world context

Let’s walk through a real scenario. Imagine you work for a mid-size company called 'GlobalRetail Inc.' that sells clothes online. The company has three main teams: the Web Shop team (which runs the public website), the Inventory team (which manages stock data), and the Data Analytics team (which analyses customer behaviour). Currently, all teams share a single AWS account. One afternoon, a junior developer on the Web Shop team accidentally deletes a production database. The entire website goes offline for four hours. The CEO is furious. 

You are hired to fix this. You decide to implement a multi-account strategy with AWS Organizations. Here is the step-by-step process: 

1. **Set up AWS Organizations.** You create a new AWS account to be the management account (call it 'globalretail-org-admin@company.com'). This account will never run any applications — it is purely for administration and billing. 

2. **Design the OU structure.** You create three top-level Organisational Units: 'Security', 'Infrastructure', and 'Sandbox'. Under 'Infrastructure', you create three sub-OUs: 'WebShop-Prod', 'WebShop-Dev', and 'Inventory'. Under 'Security', you create 'LogArchive' and 'Audit'. 

3. **Create accounts.** You use the AWS Organizations 'Create Account' feature to create one account for each sub-OU. For example: 'webshop-prod@globalretail.com', 'webshop-dev@globalretail.com', 'inventory@globalretail.com'. Each team gets its own isolated environment. 

4. **Apply Service Control Policies (SCPs).** You write an SCP that blocks any account from deleting CloudTrail logs (so audit data is always preserved). You attach this SCP to the root of the organisation. Then you write another SCP that blocks launching EC2 instances larger than 't3.medium' in the 'Sandbox' OU, so developers experimenting there cannot accidentally run up huge bills. 

5. **Set up consolidated billing.** All charges from the new accounts are now visible in a single bill under the management account. The finance team can use Cost Explorer to see exactly which account (and therefore which department) is spending the most. 

6. **Enable AWS CloudTrail for all accounts.** You configure a 'trail' in the management account that sends logs from every member account into a central S3 bucket in the 'LogArchive' account. This gives you a single pane of glass for security auditing. 

Now, when a junior developer in the 'webshop-dev' account accidentally deletes a database, it only affects the development environment, not production. The company can restore the dev database from backup without any customer impact. The CEO is happy. 

In this world, you also use Role-based access control (IAM Roles) so that users from the corporate identity provider (like Microsoft Entra ID) can assume roles into specific accounts. This means an engineer can switch between accounts without needing separate usernames and passwords for each one. 

The real-world value of AWS Organizations is that it allows you to scale from one account to hundreds while maintaining security, visibility, and cost control. For the SAP-C02 exam, scenarios like this — where you must design the OU structure, write SCPs, and centralise logging — are extremely common.

## Exam focus

The SAP-C02 exam loves to test your understanding of AWS Organizations and multi-account strategies in several specific ways. Here is what you must be ready for: 

- **OU design and policy attachment order.** The exam often describes a complex company structure and asks which OU to place an account in, or which SCP will be in effect. A common trap is forgetting that SCPs are evaluated in order from the root down to the target account. If the root SCP denies something, it cannot be overridden by a child OU’s SCP. You must memorise that SCPs are 'deny-by-default' at the root level. 

- **SCPs vs IAM Policies.** The exam frequently asks what happens when an IAM policy grants a permission that an SCP denies. The answer is always: the SCP wins — it acts as a boundary. You cannot give a user an IAM role that allows something an SCP blocks. This is a classic exam trap. 

- **Management account vs member accounts.** The management account has full, unfettered access to everything — it is *not* bound by SCPs. The exam might try to trick you by suggesting that the management account is also subject to SCPs. It is not, but member accounts are. 

- **Consolidated billing vs AWS Budgets.** The exam sometimes presents a scenario where a company wants to control costs. Consolidated billing is for aggregating invoices, not for setting spending limits. For that, you use AWS Budgets and Cost Anomaly Detection. Do not confuse them. 

- **AWS CloudTrail in a multi-account setup.** A frequent question is: how do you ensure all accounts send logs to a central S3 bucket? The answer: configure an 'organisation trail' in the management account. That single trail automatically covers all member accounts. Creating separate trails in each account is a common wrong answer. 

- **Tag Policies vs Resource Groups.** Tag Policies enforce consistency; Resource Groups let you search and manage resources by tags. The exam may ask which tool to use to ensure all resources have a 'CostCentre' tag. The answer is Tag Policies, not Resource Groups. 

- **AI services opt-out policies.** The exam occasionally includes a question about data protection and AWS AI services. If a company wants to stop its data from being used to train AWS AI models, you apply an AI services opt-out policy at the organisational level or OU level. 

- **Backup policies.** A newer topic: you can deploy backup plans across all accounts using a backup policy. The exam may ask what policy type ensures all RDS databases in the 'Prod' OU are automatically backed up daily. The answer is a backup policy. 

- **Resource Control Policies (RCPs).** These are newer and less frequent, but know they apply to resources (like S3 bucket policies) rather than principals (users/roles). They are the 'resource-level' equivalent of SCPs. 

- **Organisations features that require all features mode.** The exam notes that if you want to use SCPs, you must have 'All features' enabled in your organisation (not just consolidated billing mode). This is a common trap: they describe a company that wants SCPs but has only enabled 'Consolidated billing features'. 

- **Move accounts between OUs.** A question may ask: can you move an account from one OU to another? Yes, you can, and you do it from the AWS Organizations console or API. It does not affect running resources — only the policies that apply to the account. 

- **The 'root' container.** The root is the top-level container in your organisation. All accounts live inside it. You attach SCPs to the root to apply them to every account. A common wrong answer is to think you must attach SCPs to each OU individually — you can, but attaching to the root is more efficient for global rules. 

- **Graduated permissions.** The exam often tests 'allow lists' vs 'deny lists' for SCPs. An 'allow list' SCP uses a default deny and then explicitly allows only certain services. A 'deny list' SCP explicitly denies certain services and allows everything else by default. The exam expects you to know which is more secure: allow lists are more restrictive and therefore more secure, but harder to manage. 

- **Service-linked roles.** When you enable AWS Organizations, certain AWS services create a special IAM role called a 'service-linked role' to interact with the organisation on your behalf. The exam might ask which role allows AWS Config or AWS CloudTrail to manage resources across accounts. The correct answer is the service-linked role created by the organisation. 

To pass this section, you need to have a mental map: management account, root, OUs, member accounts, SCPs (allow vs deny lists), tag policies, backup policies, and AI opt-out policies. Practise drawing the hierarchy. Know the order of evaluation. And remember: the management account is all-powerful.

## Step by step

1. **Create the Management Account** — Designate a new AWS account that will act as the 'management account' for AWS Organizations. This account must never host applications — it is only for administration, billing, and logging. You will use it to invite or create all other accounts.
2. **Enable AWS Organizations** — From the management account, enable AWS Organizations. Choose 'All features' mode (not just consolidated billing) so you can use SCPs, tag policies, and other advanced features. This step cannot be undone later, so it is critical for exam questions.
3. **Design the Organisational Unit (OU) Structure** — Plan a hierarchy of OUs that reflects your company's security, compliance, and isolation needs. For example, create a 'Security' OU for logging and audit accounts, a 'Workloads' OU for application accounts (with sub-OUs for Dev, Test, Prod), and a 'Sandbox' OU for experimentation.
4. **Create or Invite Member Accounts** — Use the 'Create Account' feature in AWS Organizations to generate new accounts directly, or use 'Invite Account' to bring existing AWS accounts into the organisation. Place each account into the appropriate OU based on its purpose.
5. **Attach Service Control Policies (SCPs)** — Write SCPs that define guardrails — for example, denying the deletion of CloudTrail logs, restricting EC2 instance types, or blocking regions. Attach these SCPs to the root OU for global rules, or to specific OUs for departmental rules. The order of evaluation starts from the root down to the target OU.
6. **Configure Centralised Logging and Monitoring** — Set up an organisation-wide AWS CloudTrail trail in the management account to send logs from all member accounts to a central S3 bucket in the 'Security' OU. Optionally, enable AWS Config rules for compliance checks across accounts.

## Comparisons

### Service Control Policy (SCP) vs IAM Policy

**Service Control Policy (SCP):**
- Defines a permission boundary across all users/roles in an entire account or OU.
- Cannot grant permissions — only restricts what IAM can allow.
- Applies to the entire account or OU, not to individual users.

**IAM Policy:**
- Defines permissions for a specific user, group, or role within a single account.
- Can grant or deny permissions.
- Applies to individual principals (users/roles).

### Management Account vs Member Account

**Management Account:**
- Controls the organisation, creates accounts, and manages policies.
- Is not subject to SCPs — can override any guardrail.
- Should not run production workloads for security reasons.

**Member Account:**
- Is a regular AWS account belonging to the organisation.
- Is fully subject to SCPs and other organisation policies.
- Can run workloads but only within the boundaries set by the management account.

### Allow List SCP vs Deny List SCP

**Allow List SCP:**
- Explicitly specifies a set of allowed services; all else is denied by default.
- More secure but harder to maintain as new services must be added.
- Uses a default 'deny' statement and then 'allow' statements for specific services.

**Deny List SCP:**
- Explicitly specifies a set of denied services; all else is allowed by default.
- Less secure but easier to manage because you only block what you know is bad.
- Uses a default 'allow' and then 'deny' statements for specific services.

### Organisational Unit (OU) vs AWS Account

**Organisational Unit (OU):**
- A container for grouping accounts within an organisation.
- Policies (SCPs, tag policies) can be attached to an OU.
- Cannot run resources or incur charges on its own.

**AWS Account:**
- An independent AWS resource container with its own billing and limits.
- Holds actual cloud resources like EC2, S3, and RDS.
- Incurs charges based on resources used.

## Diagram

_A typical AWS Organizations hierarchy showing the management account controlling the root OU, which contains three OUs (Security, Workloads, Sandbox) with member accounts inside them._

```mermaid
flowchart TD
    R[Root OU] --> S[Security OU]
    R --> W[Workloads OU]
    R --> X[Sandbox OU]
    S --> SA[LogArchive Account]
    W --> DEV[Dev Account]
    W --> TST[Test Account]
    W --> PR[Prod Account]
    R--> MGMT[Management Account]
    MGMT -.->|Controls Policies| R
    style R fill:#e6f7ff
    style MGMT fill:#b3d9ff
```

## Common misconceptions

- **Misconception:** A Service Control Policy (SCP) grants permissions to users and roles in an account. **Reality:** SCPs never grant permissions. They only set a maximum boundary on what IAM policies can allow. Think of them as a ceiling; the actual permissions still come from IAM. (The word 'policy' makes beginners think it 'grants' access like an IAM policy. The exam specifically tests the difference between granting and restricting.)
- **Misconception:** You can attach two SCPs that conflict, and the most permissive one wins. **Reality:** SCPs are evaluated using an 'effect' logic: if any effective SCP denies an action, it is denied, regardless of other SCPs that allow it. Deny always overrides allow. (This mirrors the way IAM policies work (where an explicit deny overrides an allow), but beginners often assume 'less restrictive wins'.)
- **Misconception:** AWS Organizations can be used to create AWS accounts that are completely free and have no charges. **Reality:** AWS Organizations is free, but each member account you create is a real AWS account that can incur charges for the resources you launch in it. (The word 'free' causes people to think there is no cost risk. The exam expects you to understand that accounts can still accrue spending.)
- **Misconception:** You can only have one 'management account' and it can also run production workloads. **Reality:** The management account is not recommended for running workloads because it has complete, unbound administrative access. Best practice is to keep it empty and use it only for organisation management and billing. (Beginners think 'one account to rule them all' means it should do everything, but the exam tests the principle of least privilege — even at the account level.)
- **Misconception:** Moving an account from one OU to another will cause downtime for applications running in that account. **Reality:** Moving an account between OUs changes which SCPs apply to it, but it does not affect running resources or require a reboot. Only future API calls are affected by new SCPs. (The concept of 'moving' sounds disruptive, but it is purely a metadata operation.)

## Key takeaways

- AWS Organizations is a free service that lets you centrally manage multiple AWS accounts by grouping them into Organisational Units and applying policies.
- Service Control Policies (SCPs) set permission boundaries and never grant access — they only restrict what IAM policies can allow.
- Deny in an SCP is always authoritative; if any effective SCP denies an action, it is blocked, even if another SCP allows it.
- The management account is immune to SCPs and should never be used for running workloads to avoid security risks.
- Consolidated billing aggregates all member account charges into a single invoice but does not control spending — use AWS Budgets for that.
- An organisation-wide CloudTrail trail set up in the management account automatically covers all member accounts without manual configuration per account.
- Tag Policies enforce consistent tagging across all accounts, which simplifies cost allocation and resource management.
- AI services opt-out policies allow you to prevent your organisation's data from being used to train AWS AI models.
- Backup policies let you deploy backup plans automatically to all accounts in an OU, ensuring critical data is protected.
- Allow list SCPs (default deny, then allow specific services) are more secure but harder to maintain than deny list SCPs.

## FAQ

**Can I have two management accounts in one AWS Organizations?**

No, each organisation has exactly one management account. You can create multiple organisations, but they cannot be merged.

**Can I use SCPs to block specific API calls for the management account?**

No, SCPs do not apply to the management account. The management account is exempt from all SCPs.

**If I create an SCP that denies access to S3, can I still use IAM to grant S3 access to a user in a member account?**

No. The SCP blocks all S3 access regardless of what IAM policies say. SCPs act as a maximum boundary.

**Is there a limit to how many accounts I can have in AWS Organizations?**

Yes, by default you can have up to 10,000 member accounts per organisation. You can request an increase from AWS support.

**What happens if I move an account from a 'Sandbox' OU to a 'Prod' OU?**

The SCPs and other policies attached to the 'Prod' OU will now apply to that account. There is no downtime — only future API calls are affected.

**Do I need to set up separate billing for each member account?**

No, consolidated billing is automatic once accounts join the organisation. All charges appear on the management account's invoice.

## Check your understanding

1. **What is the primary purpose of a Service Control Policy (SCP) in AWS Organizations?**

   Answer: To set a maximum permission boundary for all users and roles in a member account or OU — it never grants permissions.

2. **True or False: The management account in AWS Organizations is subject to the same SCPs as member accounts?**

   Answer: False. The management account is exempt from all SCPs.

3. **Which feature of AWS Organizations allows you to enforce consistent resource tagging across all accounts?**

   Answer: Tag Policies.

4. **If you apply two SCPs to an account — one that allows EC2 and one that denies EC2 — what happens when a user tries to launch an EC2 instance?**

   Answer: The request is denied because a deny in any effective SCP overrides any allow.

5. **A company wants to centralise all AWS CloudTrail logs from 50 member accounts into one S3 bucket. What is the simplest way to achieve this?**

   Answer: Create a single organisation-trail in the management account, which automatically logs all member accounts.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-sap-c02/multi-account-strategies-and-aws-organizations