> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi Account Security With AWS Organizations

> Guide to designing and governing AWS multi-account IAM using Organizations, SCPs, OU patterns, centralized identity, automation, and monitoring for scalable security.

In this lesson we cover designing multi-account Identity and Access Management (IAM) at enterprise scale using AWS Organizations. You’ll learn the multi-account challenge, organizational and governance constructs, Service Control Policies (SCPs) and access patterns, and practical approaches to monitoring and automation. This article focuses on architecture- and policy-level guidance you need to prepare; the demo reinforces these concepts.

![A slide titled "Multi-Account Security – Managing IAM at Enterprise Scale" showing an AWS organization feeding into a centralized security controls layer that branches to multiple AWS accounts. An "AWS certified DevOps Engineer – Professional" badge is shown on the right.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/multi-account-iam-security-aws-org.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=ae82f1e6ab60c07b74eed5997384b813)

Why centralize IAM and governance?

Without centralized management you lose consistent enforcement, telemetry, and observability across accounts. In large environments — hundreds of accounts — inconsistent policies create gaps in security posture, auditing blind spots, and operational friction. AWS Organizations helps by providing a management account and a hierarchical OU model to apply guardrails consistently.

![A slide titled "The Multi-account Challenge" showing a before/after diagram. The left panel has separate ovals for Account 01–05, while the right panel shows a "Centralised Management" box with arrows linking down to multiple account ovals.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/multi-account-centralized-management-diagram.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=1f69cdebc2951649599213e4bae490be)

Core concepts: Accounts, OUs, and guardrails

AWS Organizations supports a management account plus Organizational Units (OUs) to group accounts. Design your OU structure driven by business drivers — for example:

* Function (prod/dev/test)
* Business unit or project
* Compliance regimes (PCI, HIPAA)
* Hybrid designs combining the above

Choose an OU design aligned with your operating model and compliance requirements, and ensure it stays within AWS Organizations limits (e.g., max OU depth). For more, see the AWS Organizations documentation: [https://docs.aws.amazon.com/organizations/latest/userguide/orgs\_introduction.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)

![A diagram titled "AWS Organizations – Multi-Account Management Framework" showing a central Management Account branching to two Organizational Units (A and B), each containing individual accounts (Account 01–04). Service Control Policies (SCPs) and Delegated Administrators are shown beneath governing the accounts.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/aws-organizations-multi-account-diagram.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=f1a0b09b5ef32d84448ba639454bff8e)

Design patterns for OUs

![A slide showing a function-based organizational unit (OU) structure: an "Organization Root" at the top branches into Production OU, Development OU, and Test OU. Each OU further branches to individual accounts (e.g., Prod Account 01/02, Dev Account 01/02, Test Account 01/02).](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/org-root-production-development-test-accounts.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=d98e3431a3561c6557e021b37702d6b3)

You can also group OUs by compliance requirements:

![A slide with a hierarchical diagram titled "Designing an Effective OU Structure" showing an Organization Root branching to four compliance-based OUs — PCI, HIPAA, Public, and Internal — each with a corresponding account beneath.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/ou-structure-pci-hipaa-public-internal.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=9b1e8512dd5f61911991fb56ce5f7875)

Table — OU design tradeoffs

| OU Design Pattern | Best for | Considerations |
| - | -: | - |
| Function-based (prod/dev/test) | Clear separation of lifecycle stages | Easier to apply environment-specific guardrails; may cross business boundaries |
| Business-unit / project | Ownership and billing alignment | More granular delegation, potential duplication of controls |
| Compliance-based (PCI/HIPAA) | Regulatory isolation and stronger controls | Requires strict enforcement and review processes |

Service Control Policies (SCPs): guardrails not grants

SCPs are JSON documents attached to roots, OUs, or accounts to set the maximum available permissions inside those accounts. Important SCP behavior:

* SCPs are evaluated before IAM identity policies. SCPs can only restrict — they do not grant permissions.
* An explicit Deny in an SCP overrides any Allow.
* SCPs affect service-linked roles and the root user.
* SCPs are inherited by child OUs and accounts in the OU hierarchy.
* Effective permissions are the intersection of SCPs, identity-based policies, resource-based policies, and permission boundaries.

Helpful reference: [https://docs.aws.amazon.com/organizations/latest/userguide/orgs\_manage\_policies\_scps.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)

Table — Quick SCP summary

| Property | Effect |
| - | - |
| Attachment points | Root, OU, Account |
| Purpose | Limit actions (guardrails) |
| Interaction with IAM | SCPs restrict what IAM policies may grant |
| Inheritance | Children inherit SCPs from parent OUs/root |
| Overrides | Explicit deny overrides allows |

SCP example

Below is an illustrative SCP implementing region restrictions, service restrictions, resource protection, privilege escalation prevention, and instance-type restrictions. Use it as a starting point and test thoroughly in non-production.

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideAllowedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    },
    {
      "Sid": "DenyUnapprovedServices",
      "Effect": "Deny",
      "Action": [
        "s3:*",
        "lambda:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ProtectSecurityResources",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigRule",
        "guardduty:DeleteDetector"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PreventPrivilegeEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:AttachUserPolicy",
        "iam:PutRolePolicy",
        "iam:PutUserPolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyUnapprovedInstanceTypes",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": [
            "t3.micro",
            "t3.small"
          ]
        }
      }
    }
  ]
}
```

Test SCPs thoroughly in a non-production environment. A misconfigured SCP can unintentionally block necessary actions and be difficult to remediate.

Common SCP patterns (visual)

![A presentation slide titled "Common SCP Patterns – Implementing Security Guardrails with SCPs" showing a "Service Restrictions" box and two example restrictions: "Prevent use of unapproved services" and "Block risky service actions."](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/common-scp-patterns-service-restrictions.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=bc589b86d07ded38c64880f635b3fffa)

![A presentation slide titled "Common SCP Patterns — Implementing Security Guardrails with SCPs" highlighting a "Resource Protection" header. Below are three boxes listing guardrails: prevent deletion of security resources; protect CloudTrail, Config, GuardDuty; and enforce encryption requirements.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/scp-guardrails-resource-protection.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=e5001a47ab426110432659b6b1328637)

Cross-account access patterns

Best practice is to avoid per-account long-lived credentials by letting identities assume roles in target accounts. Typical flow:

* Principal (user, service, CI/CD) calls sts:AssumeRole with the target role ARN (and optional ExternalId).
* Target role has a trust policy allowing the principal to assume it.
* Temporary security credentials are issued for the assumed role.

This model supports least privilege and centralized credential lifecycle management.

![A slide titled "Cross – Account Access Patterns" showing a flowchart: User/Identity → Assume Role Request (with ARN, External ID) → Target Role (Trust Policy with External ID) → Temporary Security Credentials. It illustrates how to implement secure cross-account access.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/cross-account-access-assume-role-diagram.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=28eedf7eecca7f043c8851ad6dba5345)

Example trust policy (with ExternalId)

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/TrustedRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "external-id-12345"
        }
      }
    }
  ]
}
```

Centralized identity and federation

Most organizations adopt identity federation to avoid managing IAM users in each account. Options include IAM Identity Center (AWS SSO), or third-party identity providers (Azure AD, Okta, PingFederate). Federation simplifies auditing, enforces central authentication policies, and supports SAML/OIDC access across AWS accounts.

Consider centralizing authentication with IAM Identity Center or a third-party IdP to simplify user lifecycle, centralize MFA, and improve auditability. See: [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/)

![A presentation slide titled "Centralized Identity Management" showing an IAM Centralization Models Comparison table. The table has columns for Model, Description, Pros, and Cons and lists approaches like identity account for all users, federated access (AWS SSO/IAM Identity Center), hybrid approaches, and identity federation.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/centralized-identity-iam-models-comparison.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=9691c3e0cae567aa1b4ccd0263bf5924)

AWS Control Tower: landing zone and guardrails

Control Tower provides an opinionated landing zone integrated with AWS Organizations. It offers Account Factory for provisioning, enforces preventive and detective guardrails, centralizes logging, and integrates with single sign-on. It’s a quick way to bootstrap a multi-account baseline but evaluate its scaling and customization limits against your requirements.

![A screenshot of an AWS Control Tower Multi-Account Governance "Control Tower Guardrail Compliance Dashboard" showing a table of accounts, organizational units, guardrails, compliance status (color-coded) and last-checked timestamps. The rows list example accounts like Account-Dev-001, Account-Prod-005 and their guardrail compliance (Compliant or Non-Compliant).](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/aws-control-tower-guardrail-compliance-dashboard.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=0cae43179ac8fc50ac766f5e223d67a6)

![A slide titled "AWS Control Tower – Multi-Account Governance" showing a horizontal workflow of five colored boxes. The boxes list the account provisioning steps: Request New Account via Account Factory → Validate Request and Approvals → Provision Account & Configure Landing Zone → Apply Preventive & Detective Guardrails → Monitor Compliance via Dashboard.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/aws-control-tower-multiaccount-provisioning-workflow.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=0f132d0a21a84721040b147f36ae87b6)

IAM Access Analyzer and automated governance

IAM Access Analyzer identifies cross-account and public access risks and generates findings that can be routed via EventBridge for automated triage and remediation. Integrate findings with StackSets, AWS Config, Systems Manager runbooks, and Security Hub to build an automated governance pipeline.

![A slide titled "IAM Access Analyzer for Multi-account" showing a table of access findings by account. The table lists resources, finding types, severity (High/Medium/Low), first detected dates, and statuses (Open/In Progress/Closed).](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/iam-access-analyzer-multi-account-findings.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=58e0319b342679a507eea87afa422e38)

Automation building blocks

![A diagram titled "Automated Security Governance" showing a blue "Automation Services" banner linked to four service boxes: AWS CloudFormation StackSets, AWS Config Rules and Conformance Packs, AWS Systems Manager Automation, and AWS Security Hub. The graphic illustrates these AWS automation tools working together for security governance.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/automated-security-governance-aws-automation.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=e88714929db61d3436d17449395ce53e)

Typical automation pattern

* Preventive controls: SCPs (Organizations), permission boundaries (accounts)
* Detective controls: AWS Config rules, IAM Access Analyzer, Security Hub, CloudTrail
* Remediation workflows: EventBridge → Lambda / Systems Manager → CloudFormation StackSets / Config remediation

![A presentation slide titled "Automated Security Governance" showing a flow diagram of "Common Automation Patterns" that branches into three boxes: preventive controls (SCPs and permission boundaries), detective controls (Config and Security Hub), and remediation workflows (Systems Manager). The layout visually links these automation patterns under a single governance header.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/automated-security-governance-preventive-detective-remediation.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=9abdde4e835c2e1efb2a6d64741e24ac)

EventBridge is commonly used as the central event bus to orchestrate detection and remediation across accounts. It can route findings to other EventBridge buses, SNS, Lambda, Step Functions, StackSets, etc.

![A presentation slide titled "Automating Security Controls Across Accounts" showing an "Implementation Approach" that branches to four boxes: Security as code, Event-driven security, Compliance automation, and Continuous validation.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/automating-security-controls-across-accounts.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=7ecc9ab131403e468a532e92524dce50)

![A diagram titled "Automating Security Controls Across Accounts" showing Amazon EventBridge triggering an AWS Lambda that runs checks across Account A and Account B. Results feed into a security compliance check and AWS Systems Manager for centralized automation and remediation.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/automating-security-across-accounts.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=06f2d821c939f651d464034b700fbffd)

Monitoring and auditing at scale

Centralize logs and findings to improve detection and incident response:

* CloudTrail aggregation for API activity and audit trails
* AWS Config Aggregators for cross-account configuration checks
* Security Hub for consolidated findings and security posture
* CloudWatch and EventBridge for alerting and automation

Note: ensure references to service names are correct in documentation and diagrams. For configuration auditing use AWS Config (not AppConfig).

![A slide titled "Monitoring and Auditing At Scale" showing a dashboard mockup with security score, open findings, compliance metrics and failed-checks charts on the left. On the right is an AWS Organizations diagram feeding Centralized Logging, Compliance Monitoring and Operational Monitoring with AWS service icons (CloudTrail, AppConfig, Security Hub, CloudWatch).](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/monitoring-auditing-aws-organizations-dashboard.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=f941aa13b1c2e75d27d809ce9aedbfa8)

Putting it all together: practical checklist

1. Define account and OU structure based on business and compliance drivers.
2. Choose baseline security controls: preventive (SCPs, permission boundaries) and detective (AWS Config, CloudTrail, Access Analyzer).
3. Define identity model: centralized federation (IAM Identity Center or third-party IdP) or a hybrid; enforce least privilege and centralized auditing.
4. Implement automation: use EventBridge, Security Hub, Config, StackSets, Systems Manager to validate and remediate continuously.
5. Iterate: monitor logs, tune policies, and improve automation to reduce manual processes.

Core building blocks: Organizations + SCPs + centralized logging (CloudTrail, AWS Config) + Security Hub + automation.

Common pitfalls and troubleshooting

| Problem | Likely Cause | Remediation |
| - | -: | - |
| SCP not taking effect | SCP attached to the wrong OU/account or OU inheritance misunderstanding | Verify SCP attachment point; confirm inheritance; test SCP in a staging OU |
| Cross-account access failures | Incorrect trust policy, missing ExternalId, or restrictive SCPs | Review role trust policy and permissions, check SCPs and permission boundaries |
| Inconsistent policy enforcement | OU hierarchy errors or inconsistent guardrail application | Standardize OU design, enforce templates/StackSets, run audits |
| Overly broad SCPs | Large Deny that blocks legitimate actions | Start with least-restrictive SCP, test in non-prod, iterate to tighten |

![A presentation slide titled "Common Multi-account Security Challenges" showing a three-column table of challenges, possible causes, and solutions (e.g., SCP not taking effect, cross-account access failures, governance at scale). The slide is branded © KodeKloud.](https://mintcdn.com/kodekloud-c4ac6d9a/FCC3Du5gLxWM9z2p/images/AWS-Certified-DevOps-Engineer-Professional/Domain-6-Security-and-Compliance/Multi-Account-Security-With-AWS-Organizations/common-multi-account-security-challenges-slide.jpg?fit=max\&auto=format\&n=FCC3Du5gLxWM9z2p\&q=85\&s=ded84cefdfb40377247b512cdb180920)

Further reading and links

* AWS Organizations: [https://docs.aws.amazon.com/organizations/latest/userguide/](https://docs.aws.amazon.com/organizations/latest/userguide/)
* Service Control Policies (SCPs): [https://docs.aws.amazon.com/organizations/latest/userguide/orgs\_manage\_policies\_scps.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
* IAM Identity Center (AWS SSO): [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
* AWS Control Tower: [https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
* IAM Access Analyzer: [https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer.html)
* AWS Config: [https://docs.aws.amazon.com/config/latest/developerguide/what-is-aws-config.html](https://docs.aws.amazon.com/config/latest/developerguide/what-is-aws-config.html)
* Amazon EventBridge: [https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
* AWS Security Hub: [https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)

That concludes this lesson on multi-account security with AWS Organizations. Further materials will cover the remaining domain topics and hands-on automation examples.

> **[Watch Video](https://learn.kodekloud.com/user/courses/aws-certified-devops-engineer-professional/module/d51f4260-d612-4dcb-9a91-4eeb6540c6c7/lesson/d3da63a6-ad9c-48a6-9ef1-f32b301e3170)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.