A service that lets you centrally manage and govern multiple AWS accounts with features such as consolidated billing, organizational units (OUs), and Service Control Policies (SCPs).

The top-level account that creates and manages an AWS Organization. It can create or invite member accounts and attach SCPs but should not host regular workloads due to its power.

Organizational Unit (OU)

A logical container in AWS Organizations used to group accounts, often by environment, business unit, or function, so that policies like SCPs can be applied consistently.

IAM identity-based policy

A policy attached to an IAM user, group, or role that grants specific permissions within a single account, subject to any applicable SCPs or permission boundaries.

The original identity associated with an AWS account email address. It has full access and bypasses many IAM restrictions and should be protected and rarely used.

A service that records configuration changes of supported AWS resources and evaluates them against rules to detect non-compliant configurations.

What is AWS CloudTrail?

A service that records API calls and management events in AWS accounts, providing audit logs that can be stored in S3 and integrated with CloudWatch Logs and other tools.

Securing AWS Accounts and Governance: Organizations, Guardrails, and Access Boundaries — AWS Solutions Architect Associate (SAA‑C03): Complete Exam-Ready Masterclass

From Single Account to Multi-Account Governance

Why Multi-Account Matters

Many teams start with one AWS account. As workloads and compliance needs grow, that single account becomes hard to secure and govern. Multi-account strategy and AWS Organizations solve this.

Separation and Guardrails

Multiple accounts let you separate prod vs. dev, isolate risk, and apply different guardrails per business unit. You manage fewer complex IAM policies inside any single account.

Shared Responsibility Context

The AWS shared responsibility model describes how AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including configuration.

Exam Pattern

SAA-C03 loves scenarios where you choose between tags, SCPs, and permission boundaries; isolate workloads into separate accounts; and centralize logging and root user protections.

What You Will Learn

You will design AWS Organizations structures, use SCPs, compare them to IAM and permission boundaries, protect root users, set baselines, and add CloudTrail and Config for visibility.

AWS Organizations: Structure, Terminology, and Use Cases

What Is AWS Organizations?

AWS Organizations lets you centrally manage and govern multiple AWS accounts. As of 2026, it is the standard tool for multi-account environments.

Key Components

The management account creates the organization and manages policies. Member accounts are governed accounts. Organizational Units (OUs) group accounts by environment or business.

Consolidated Billing

All accounts roll up charges to the management account, enabling volume discounts and centralized cost visibility. Billing is a core benefit in real deployments.

Common OU Design

Expect a Security OU (tooling, log archive), a Sandbox/Dev OU, and a Production OU with accounts per product or domain. This pattern appears often in exam scenarios.

When to Think Organizations

If a scenario mentions many teams, strict isolation, or different compliance scopes, the best answer is usually multi-account design using AWS Organizations and OUs.

Designing a Multi-Account Structure (Step-by-Step)

Step 1: Environments & Risk

Start by separating environments: Prod (highest security), Non-prod (Dev/Test), and Sandbox (experiments). Each has different risk and control needs.

Step 2: Shared & Security Accounts

Create dedicated Security Tooling, Log Archive, and Shared Services accounts so security and core services are isolated from app workloads.

Step 3: OU Layout

Under the org root, use a Security OU, Sandbox OU, NonProd OU, and Prod OU. Place accounts like Prod-App1 or Dev-App1 into the matching OU.

Step 4: Policy Attachment

Attach broad guardrails at the org root, stricter controls to the Prod OU, and cost/risk limits to Sandbox OU. SCPs flow down the tree.

Exam Pattern Recognition

If a question mentions centralized logging or a separate security account, think of this design: Security OU with Log Archive and Security Tooling governed by SCPs.

Service Control Policies (SCPs): Organization-Wide Guardrails

What SCPs Do

Service Control Policies define the maximum permissions accounts can have. They do not grant access; they filter what IAM policies can ever allow.

Scope and Attachment

SCPs attach to the org root, OUs, or individual accounts and affect all principals in those accounts, including the root user.

Default Behavior

New organizations use the FullAWSAccess SCP, which allows all services and actions, leaving IAM to control actual permissions.

Deny Wins

An action must be allowed by IAM and not denied by SCP. Any explicit Deny in an SCP overrides any Allow in IAM policies.

Exam Clue

If you need org-wide restrictions that even root cannot bypass, choose SCPs. If it is about one role in one account, SCPs are probably not the right tool.

Example: SCPs vs IAM Policies vs Permission Boundaries

Three Layers of Control

You must distinguish SCPs, IAM identity-based policies, and permission boundaries. Each operates at a different scope and solves different problems.

SCPs: Org Guardrails

SCPs limit what any principal in an account can ever do. They attach to org root, OUs, or accounts and are ideal for cross-account restrictions.

IAM Policies: Grant Access

IAM identity-based policies attach to users, groups, or roles and grant permissions within a single account, subject to SCP limits.

Permission Boundaries

Permission boundaries attach to a user or role and define the maximum permissions that identity can receive from any policy.

Scenario Mapping

Org-wide restriction → SCP. One role’s permissions → IAM policy. Limiting what a role can ever get, even if others attach policies → permission boundary.

Sample SCP and Permission Boundary Policies

Inspect these JSON policies to see how SCPs and permission boundaries look in practice.

Root User Protection and Account Security Baselines

Root User Risk

The account root user bypasses many IAM restrictions and should be used rarely. In multi-account setups, protecting every root user is critical.

Protecting the Root User

Enable MFA, use a strong unique password, avoid root access keys, and reserve the root user only for tasks that explicitly require it.

Security Baselines

Per-account baselines include CloudTrail, AWS Config, GuardDuty, Security Hub, IAM Access Analyzer, and policies preventing public S3 or unencrypted data.

Centralization

Send logs to a central Log Archive account and aggregate security findings in a Security Tooling account for unified monitoring.

Exam Angle

When new accounts must automatically meet security standards, think AWS Organizations with SCPs plus automation to enable CloudTrail, Config, and security tools.

Audit and Monitoring: CloudTrail and AWS Config Across Accounts

CloudTrail Role

AWS CloudTrail records API calls and management events. In multi-account setups, organization trails log across all accounts to a central S3 bucket.

Organization Trail Pattern

Create an org trail in a security or management account, log all regions, and send logs to an S3 bucket in a dedicated Log Archive account.

AWS Config Role

AWS Config records resource configurations and can evaluate them with rules to flag non-compliant resources across accounts.

Central Aggregation

Use Config aggregators and CloudTrail central buckets so security teams can see changes and compliance across all member accounts.

Exam Mapping

Org-wide logging → CloudTrail org trail. Compliance checks → AWS Config rules. Tamper-resistant logs → separate Log Archive account plus SCPs.

Design Exercise: Choosing the Right Guardrail

Work through these thought scenarios. For each, decide which control you would use: SCP, IAM policy, or permission boundary. Then compare your reasoning to the guidance.

Scenario A: Your company wants to ensure that no account in the organization can launch resources outside `us-east-1` and `eu-central-1`. Even the root user must be blocked.

Think: Is this org-wide, account-wide, or per-role?
Recommended: SCP attached at the organization root or to all relevant OUs with a `Deny` on `aws:RequestedRegion` not in the allowed list.

Scenario B: In a single dev account, you want to prevent junior developers from creating or modifying IAM roles, but senior admins in the same account should still be able to.

Think: This is about specific identities inside one account.
Recommended: IAM policies and/or permission boundaries. Use IAM policies to deny `iam:*` to junior roles, or use permission boundaries to ensure roles they create cannot gain IAM privileges.

Scenario C: A CI/CD pipeline role in one account must manage EC2 instances but must never be able to delete RDS databases, even if someone later attaches a broader policy.

Think: This is about one role’s maximum power.
Recommended: Permission boundary on the CI/CD role that omits `rds:DeleteDBInstance` and denies sensitive actions.

Scenario D: Compliance requires that CloudTrail cannot be disabled in any production account.

Think: Cross-account, production scope.
Recommended: SCP attached to the Prod OU that denies `cloudtrail:StopLogging`, `DeleteTrail`, and `UpdateTrail`.

Quiz: Organizations and SCP Fundamentals

Check your understanding of AWS Organizations and SCPs.

You manage 50 AWS accounts and must ensure that no one, including root users, can disable CloudTrail in any account. Which solution best meets this requirement with the least operational overhead?

Create an IAM policy in each account that denies CloudTrail actions and attach it to all users and roles.
Create a Service Control Policy at the organization root that explicitly denies CloudTrail stop and delete actions.
Enable AWS Config in each account and create a rule that marks CloudTrail as non-compliant when disabled.
Use a bucket policy on the central S3 log bucket to deny deletion of CloudTrail logs.

Show Answer

Answer: B) Create a Service Control Policy at the organization root that explicitly denies CloudTrail stop and delete actions.

A Service Control Policy (SCP) at the organization root can deny CloudTrail stop and delete actions across all accounts, including root users, with a single configuration. IAM policies in each account are harder to manage and do not cover root by default. AWS Config can detect issues but not prevent actions. A bucket policy protects stored logs but does not stop CloudTrail from being disabled.

Quiz: IAM Policies vs Permission Boundaries

Test your understanding of permission boundaries and IAM policies.

A platform team lets application teams create their own IAM roles for workloads. The platform team wants to ensure that no application role can ever obtain permissions to manage IAM users or roles, even if app teams attach overly permissive policies. What is the BEST solution?

Attach an SCP to the account that denies all IAM actions.
Use a permission boundary on application roles that allows only non-IAM actions.
Rely on tagging and resource-based policies to restrict IAM usage.
Create a CloudTrail trail and alert when IAM actions are used.