The Complete AWS Organizations Guide (2025): Multi-Account Management, SCPs, Best Practices & Real-World DevOps Scenarios

By Srikanth Ch, Senior DevOps Engineer | Last Updated: November 2025

Imagine managing ten AWS accounts manually—billing scattered across invoices, access policies configured individually, security settings inconsistent across environments. That’s chaos waiting to happen. That’s exactly why AWS Organizations exists.

I’ve seen teams struggle with multi-account management firsthand. One startup I worked with had seven AWS accounts—one for each microservice team—and nobody could figure out why their monthly bill kept climbing. No consolidated view, no shared policies, and certainly no governance. Sound familiar?

AWS Organizations transforms this mess into a well-orchestrated system. Think of it as your cloud command center, where you manage multiple AWS accounts from a single pane of glass, enforce security policies across your entire infrastructure, and finally get a consolidated bill that makes sense.

In this comprehensive guide, you’ll learn everything from basic setup to advanced Service Control Policies (SCPs), real-world DevOps scenarios, and battle-tested best practices. Whether you’re preparing for the AWS Solutions Architect Associate (SAA-C03) or Professional (SAP-C02) exams, or simply building a scalable multi-account architecture, this guide has you covered.

What is AWS Organizations and Why Should DevOps Engineers Care?

AWS Organizations is a free account management service that lets you consolidate multiple AWS accounts into an organization that you create and centrally manage. But it’s so much more than just account grouping. Official AWS Organizations documentation provides comprehensive technical details.

Think of it like managing a large software company with multiple development teams. Without structure, each team operates in isolation—different coding standards, different deployment processes, different security measures. Now imagine having a central governance framework where company-wide policies apply automatically, but teams still have autonomy within safe boundaries. That’s AWS Organizations for your cloud infrastructure. For more on IAM best practices that complement Organizations, see our IAM tutorial.

Here’s what AWS Organizations brings to your DevOps practice:

Centralized Management: Control all your AWS accounts from one place. No more logging in and out of different accounts to make configuration changes.

Security Guardrails: Define organization-wide policies that prevent dangerous operations—like disabling CloudTrail or allowing public S3 buckets—even if someone has admin access in a member account.

Simplified Billing: Get one consolidated bill for all accounts. Plus, benefit from volume discounts across your entire organization instead of per-account limits.

Resource Sharing: Share resources like AWS Transit Gateway, License Manager licenses, or even Route 53 Resolver rules across accounts without complex cross-account configurations.

The real power shows up when you’re managing environments at scale. Production, staging, development, shared services, security tooling, data analytics—each gets its own account with appropriate isolation, yet all under unified governance.

How AWS Organizations Works: Understanding the Hierarchy

AWS Organizations uses a tree-like hierarchy that’s both simple and powerful. Let me walk you through it the way I explain it to new team members.

The Root: At the very top sits your root account—the AWS account you used to create the organization. This is your master control panel. It’s the only account that can manage organization-wide settings, create new organizational units, and apply policies at any level.

Important distinction here: the organization root (the top level of your AWS Organizations hierarchy) is completely different from the AWS account root user (the all-powerful user credentials created when you first open any AWS account). We’re talking about the organizational root—the structural top of your account tree—not the dangerous root user credentials you should lock away and rarely touch. The organization root is a logical concept, while the root user is a set of credentials. Keep these concepts separate in your mind to avoid confusion.

Organizational Units (OUs): Think of OUs as folders in your file system, but for AWS accounts. You might create OUs like “Production,” “Development,” “Sandbox,” or “Security.” You can nest OUs up to five levels deep, though I rarely see need for more than three in practice.

Here’s a real-world example from a project I architected: We had a parent OU called “Workloads” with three child OUs underneath—”Production,” “Non-Production,” and “Sandbox.” Under “Production,” we further divided into “Frontend-Prod” and “Backend-Prod.” This structure let us apply progressively stricter policies as we moved toward production environments.

Member Accounts: These are your individual AWS accounts living within OUs. Each account operates independently for day-to-day work but inherits policies from the organization structure above it.

Service Control Policies (SCPs): These are the enforcement mechanism—JSON-based policies that define what actions are allowed or denied across your organization. They act as maximum permission boundaries. Even if an IAM policy in a member account allows an action, an SCP can override and deny it. AWS SCP documentation provides detailed syntax and examples (add link when publishing).

Consolidated Billing: The root account becomes the paying account, receiving one bill for all member accounts. This isn’t just convenience—it unlocks volume pricing tiers and reserved instance sharing across your organization.

🎯 Pro Tip: Visualize your organization structure on paper before building it. I use a simple tree diagram showing Root → OUs → Accounts. This planning saves hours of reorganization later when you realize your structure doesn’t match your actual workflows.

Setting Up AWS Organizations: From Zero to Structured

Let’s get hands-on. Setting up AWS Organizations is straightforward, but there are decisions to make that impact your future flexibility.

Step 1: Create Your Organization

You’ll do this from your root account—the account that will manage everything. Head to the AWS Organizations console and click “Create organization.” AWS asks whether you want to enable “All features” or just “Consolidated billing.”

Always choose “All features”. Yes, always. The consolidated billing-only option is a legacy holdover, and you lose the ability to use SCPs, which is half the power of Organizations. Trust me, you’ll want SCPs even if you don’t think so right now.

From the AWS CLI, here’s how you’d create an organization programmatically:

aws organizations create-organization --feature-set ALL

Note: All AWS Organizations CLI commands must be executed with credentials from the root account or an IAM user/role with organization management permissions. If you’re using named profiles, specify them with --profile your-profile-name. For production environments, I recommend using IAM roles with temporary credentials via AWS STS rather than long-lived access keys.

The ALL feature set enables both consolidated billing and advanced features like SCPs and tag policies.

Step 2: Invite Existing Accounts or Create New Ones

Now you face a choice: invite existing AWS accounts to join your organization, or create fresh accounts from within Organizations.

Creating new accounts is cleaner. The organization owns them, and you avoid potential conflicts from existing resources. Here’s the CLI command to create a new account:

aws organizations create-account \
  --email devops-prod@yourcompany.com \
  --account-name "Production-Account" \
  --role-name OrganizationAccountAccessRole

That OrganizationAccountAccessRole is crucial—it’s automatically created with full admin permissions, allowing your root account to manage the new account without needing separate credentials.

Inviting existing accounts works too, but requires the account owner to accept the invitation. Use this when you’re consolidating pre-existing infrastructure:

aws organizations invite-account-to-organization \
  --target '{"Type":"EMAIL","Id":"existing-account@company.com"}'

💭 Reflection Prompt: Would you invite existing AWS accounts or create fresh ones for a new enterprise setup? Consider this: existing accounts come with history—resources, IAM users, potentially messy configurations. Fresh accounts are clean slates but require migration. What factors would influence your decision?

Step 3: Create Your OU Structure

With accounts ready, build your organizational units. Start simple—you can always refine later. From the console, navigate to “Organize accounts” and create OUs that match your actual team structure and environment separation needs.

Via CLI:

aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name Production

The parent-id is either the root ID (starts with “r-“) or another OU ID (starts with “ou-“).

Step 4: Move Accounts into OUs

Finally, organize your accounts by moving them into the appropriate OUs:

aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id r-xxxx \
  --destination-parent-id ou-xxxx-xxxxxxxx

Your organization structure is now live. But without policies attached, it’s just organizational bookkeeping. The real power comes next.

Service Control Policies (SCPs): The Guardrails You Didn’t Know You Needed

Here’s where AWS Organizations goes from “nice to have” to “absolutely essential” for security-conscious DevOps teams. Service Control Policies are the enforcement layer that prevents even the most powerful admin from doing dangerous things.

Let me share a story. A junior developer at a company I consulted for had admin access to a development account. One Friday afternoon, experimenting with S3, they accidentally ran a script that made several buckets publicly accessible. The buckets contained test data—thankfully not production—but it could have been catastrophic.

SCPs prevent exactly this scenario. Even with admin permissions, if an SCP denies an action, it can’t be performed. Period.

SCPs vs. IAM Policies: Understanding the Difference

This trips people up constantly, so let’s clarify: IAM policies grant permissions. SCPs define permission boundaries. Think of SCPs as the fence around your property—IAM policies determine what you can do within that fence, but the fence limits how far you can go.

An SCP doesn’t grant permissions; it filters them. If an IAM policy allows s3:* (all S3 actions) but an SCP denies s3:DeleteBucket, that user cannot delete buckets, regardless of their IAM permissions.

Allow Lists vs. Deny Lists

SCPs support two strategies. The default is an implicit allow—meaning everything is permitted unless explicitly denied. This is called a deny list approach, where you block specific dangerous actions.

Alternatively, you can use an allow list strategy where you explicitly specify what’s allowed and deny everything else. This is more secure but requires careful maintenance.

Most organizations use deny lists for practical reasons. Let me show you a real-world example—preventing anyone in your organization from disabling CloudTrail logging:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

Attach this SCP to your root or to specific OUs, and nobody—not even account admins—can disable CloudTrail. For security and compliance, this is non-negotiable.

Here’s another practical SCP that prevents public S3 access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3PublicAccess",
      "Effect": "Deny",
      "Action": [
        "s3:PutAccountPublicAccessBlock",
        "s3:PutBucketPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:PublicAccessBlockConfiguration": "BlockPublicAcls"
        }
      }
    }
  ]
}

This SCP prevents disabling S3 Block Public Access settings—a common security misconfiguration.

🧠 Mini Quiz: If an SCP at the OU level denies ec2:TerminateInstances, but an IAM policy attached to a user in that OU explicitly allows ec2:*, can the user terminate EC2 instances?

Answer: No. SCPs always win. The deny in the SCP creates a permission boundary that cannot be overridden by IAM policies. The user might have IAM permissions, but the SCP blocks the action at the organizational level.

SCP Inheritance

SCPs inherit down the tree. If you attach an SCP to an OU, all accounts within that OU—and any child OUs—inherit those restrictions. This is powerful: apply broad security policies at the root, then add more specific restrictions as needed at lower levels.

A practical pattern I use: apply a baseline security SCP at the root (prevents disabling CloudTrail, GuardDuty, etc.), then apply environment-specific SCPs at the OU level (Production OU gets stricter cost and region controls than Development OU).

SCP Propagation Note: When you attach, detach, or modify SCPs, or when you move accounts between OUs, changes can take anywhere from a few seconds to several minutes to propagate across all regions and services. If you apply an SCP and immediately test its effect, you might see inconsistent behavior during the propagation window. In production scenarios, wait at least 2-3 minutes after SCP changes before verifying enforcement. This propagation delay is worth remembering when troubleshooting permission issues—that “broken” SCP might just need a minute to fully apply.

Organization Units (OUs) Explained: Logical Grouping That Makes Sense

Organizational Units are how you bring order to what could otherwise become account sprawl. But they’re not just folders—they’re policy enforcement points and logical boundaries for your infrastructure.

I’ve architected OU structures for companies with three accounts and companies with over a hundred. The principles remain the same: group accounts by function, environment, or team in ways that match how your organization actually works.

Common OU Patterns

The simplest pattern is environment-based: separate OUs for Production, Staging, and Development. This lets you apply progressively stricter policies as environments get more critical.

For example, your Production OU might have SCPs that:

• Deny deletion of certain resources without MFA
• Restrict deployments to specific AWS regions (for compliance)
• Prevent changes to encryption settings
• Require all EC2 instances to use approved AMIs

Your Development OU, meanwhile, might have more permissive policies allowing experimentation, but still block truly dangerous actions like disabling security services.

Another pattern is team-based: “Team-Frontend,” “Team-Backend,” “Team-DataScience,” “Team-Security.” This works well when teams have different technology stacks and operational requirements. The Data Science team might need access to expensive GPU instances and SageMaker, while the Frontend team needs broader CloudFront and S3 permissions.

You can also combine both: create a parent OU called “Engineering” with child OUs for each team, and under each team OU, have environment-specific accounts. It might look like:

Root
├── Engineering
│   ├── Frontend
│   │   ├── Frontend-Prod
│   │   └── Frontend-Dev
│   └── Backend
│       ├── Backend-Prod
│       └── Backend-Dev
├── Shared-Services
└── Security

Policy Inheritance in Action

Here’s where OUs really shine. Policies attached to parent OUs automatically flow down to child OUs and accounts. This cascading means you can set baseline security at high levels and add specific controls at lower levels.

In the structure above, you might attach a “Baseline Security SCP” to the root that applies everywhere. Then attach a “Production Hardening SCP” to all -Prod accounts. The production accounts get both sets of restrictions, while development accounts only get the baseline.

💭 Reflection Prompt: If you were architecting AWS Organizations for a company with separate mobile app, web platform, and ML teams—each running their own production and dev environments—how would you structure your OUs? Would you organize by team first, then environment? Or by environment first, then team? Consider how policies, billing, and access control would differ between these structures.

Consolidated Billing: More Than Just One Invoice

On the surface, Consolidated Billing seems simple: instead of ten separate AWS bills, you get one. But the benefits run deeper than administrative convenience.

Volume Pricing Across Accounts

AWS pricing often includes volume tiers—the more you use, the less you pay per unit. Without consolidated billing, each account hits these tiers independently. With consolidated billing, usage aggregates across all member accounts.

Let’s say your S3 pricing is $0.023 per GB for the first 50TB, then $0.022 per GB after. If you have three accounts each using 20TB, without consolidated billing, none reaches the discount tier. With consolidated billing, your organization uses 60TB total, and the last 10TB gets the lower rate.

This applies to most AWS services: S3, data transfer, EC2 reserved instances, even AWS Support costs. For companies with significant AWS spend, consolidated billing can save thousands monthly just through volume efficiencies.

Cost Allocation and Visibility

You still get per-account cost breakdowns. The consolidated bill shows total costs, but you can drill down to see exactly what each account spent. Combined with AWS Cost Explorer at the organization level, you get visibility into cost patterns across your entire infrastructure.

Even better, enable cost allocation tags at the organization level. Tag resources with “team,” “project,” or “environment,” and you can slice cost reports however you need—even across account boundaries.

Reserved Instance and Savings Plan Sharing

Here’s a huge benefit: Reserved Instances and Savings Plans purchased in one account automatically apply to eligible usage in other accounts (within the same organization). No complex sharing configuration needed.

Imagine your Production account runs consistent EC2 workloads—perfect for Reserved Instances. Your Development account has unpredictable, bursty usage—terrible for RIs. Without Organizations, the Dev account pays full on-demand prices.

With consolidated billing, you buy RIs in the Production account for your baseline load. When Production’s usage is covered, unused RI capacity automatically applies to the Development account. You maximize RI utilization across your entire organization.

Free Data Transfer Between Accounts

Data transfer within AWS can get expensive, especially cross-region or to the internet. But data transfer between accounts in the same organization and region? Completely free. This makes architectural patterns like centralized logging or shared data lakes much more cost-effective.

Security and Governance Best Practices: Lessons from the Trenches

I’ve seen AWS Organizations implementations range from brilliantly secure to frighteningly exposed. Here are the practices that separate robust architectures from security incidents waiting to happen.

Principle 1: Lock Down Your Root Account

The root account is your organization’s master key. Compromise it, and an attacker controls everything. Here’s what you must do:

Enable MFA on the root account user—not just any MFA, but hardware MFA if possible. Hardware tokens from providers like YubiKey or Gemalto provide stronger protection than app-based authenticators.

Delete access keys for the root user. Seriously, delete them. Navigate to the AWS Console, click your account name in the top-right, select “Security Credentials,” and under “Access keys” you’ll see any existing keys. Delete them immediately. The root user should never need programmatic access—all automation should use IAM roles or dedicated service accounts. If you absolutely must perform a task that requires root credentials programmatically (extremely rare), create temporary keys, use them immediately, then delete them the same day.

Store root credentials in a physical safe with multiple-person access control. Yes, actually physical. I’m not kidding. The password should be written down (not stored digitally where it might be compromised), placed in a sealed envelope, and kept in a safe that requires at least two people to open. Document the access procedure and make it clear this is emergency-only access.

Configure alerts for any root account login. In CloudWatch, create an alarm that notifies your security team immediately if the root user logs in. This should be rare enough that every login warrants investigation.

Principle 2: SCPs Are Security Guardrails, Not Permissions

Don’t try to grant access via SCPs—they’re for preventing dangerous actions. Grant actual permissions through IAM roles and policies in member accounts. Use SCPs to deny actions you never want anyone to take: disabling CloudTrail, deleting KMS keys, leaving security groups fully open, launching expensive instance types.

Here’s an SCP I deploy for almost every organization—preventing operations in unapproved AWS regions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessToUnauthorizedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "budgets:*",
        "cloudfront:*",
        "globalaccelerator:*",
        "support:*",
        "sts:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-central-1"
          ]
        }
      }
    }
  ]
}

This SCP denies all actions in regions outside your approved list. The NotAction clause excludes global services that don’t operate in regions. Adjust the region list to match your compliance and latency requirements.

⚠️ Important Note on NotAction: The NotAction element can be powerful but dangerous. It can accidentally allow broad actions if not scoped carefully. When excluding global services in region deny SCPs like the example above, you must explicitly test in a development account to ensure you don’t inadvertently block required API calls. I’ve seen teams accidentally lock themselves out by overly-broad NotAction statements that blocked critical IAM or STS operations. Always start with permissive NotAction lists (including all global services that might be needed), then narrow down only after thorough testing across your actual workflows.

Principle 3: Enable Organization-Wide Security Services

AWS Organizations integrates with security services to enable them across all accounts automatically. Don’t enable security services account-by-account manually—that’s error-prone and doesn’t scale.

AWS CloudTrail: Create an organization trail in your root account. This logs all API calls across every account to a central S3 bucket. Invaluable for security investigations and compliance auditing. Make sure the bucket is in a separate security account with restricted access. Learn more about CloudTrail in AWS documentation .

AWS Config: Enable Config organization-wide to continuously monitor resource configurations. Set up Config rules for compliance checking—flag unencrypted S3 buckets, security groups with unrestricted ingress, RDS instances without backups. AWS Config documentation.

Amazon GuardDuty: Turn on GuardDuty at the organization level for intelligent threat detection across all accounts. The root account becomes the GuardDuty administrator, giving you centralized visibility into threats. GuardDuty organization setup guide.

AWS Security Hub: Aggregate security findings from GuardDuty, Config, and other services into one dashboard across your organization. Security Hub documentation.

From the console, you can enable these services organization-wide with just a few clicks. Via CLI for CloudTrail:

aws cloudtrail create-trail \
  --name OrganizationTrail \
  --s3-bucket-name my-org-cloudtrail-logs \
  --is-organization-trail

IAM Access Analyzer (Organization-Wide): Use IAM Access Analyzer to proactively identify resources in your organization that allow access from external principals—including cross-account access you didn’t intend. Enable Access Analyzer for each account or use centralized findings aggregation (via CloudWatch and EventBridge) to send findings to your security account. I recommend running Access Analyzer after major policy changes (SCPs, IAM updates) to catch unintended access paths early. This service essentially acts as your continuous auditor, scanning resource-based policies on S3 buckets, IAM roles, KMS keys, Lambda functions, and SQS queues to ensure you’re only granting access to principals you trust. When Access Analyzer flags external access, you can quickly determine whether it’s intentional (like sharing data with a partner organization) or accidental (a misconfigured policy that opened your resources wider than intended).

Principle 4: Implement Least Privilege at Every Level

Even with SCPs preventing dangerous actions, practice least privilege within member accounts. Create specific IAM roles for specific tasks, not broad “admin” roles unless absolutely necessary. Use IAM policies to grant exactly the permissions needed, no more.

For cross-account access, use IAM roles with trust policies rather than sharing credentials. If your CI/CD pipeline in Account A needs to deploy to Account B, create an IAM role in Account B that Account A can assume, with permissions scoped to deployment actions only.

🚀 Security Tip: Use SCPs to enforce protective controls globally. For example, create an SCP that requires all S3 buckets to have encryption enabled. Even if someone forgets to check the encryption box when creating a bucket, the SCP prevents creation of unencrypted buckets. Prevention beats detection every time.

AWS Organizations + IAM + SSO Integration: Scaling Access Management

Managing access across multiple AWS accounts manually is a nightmare. You end up with duplicated IAM users, inconsistent permissions, and password management chaos. AWS Identity Center (formerly AWS SSO) changes everything.

AWS Identity Center: Single Sign-On Done Right

AWS Identity Center integrates natively with AWS Organizations. Instead of creating separate IAM users in each account, you create identities once in Identity Center, then assign them permissions across multiple accounts.

Here’s how it works: Enable AWS Identity Center in your root account. Connect it to your identity provider—whether that’s the built-in Identity Center directory, Active Directory, or an external provider like Okta or Azure AD.

Create permission sets—collections of policies that define what users can do. You might have permission sets like “PowerUserAccess,” “ReadOnlyAccess,” or “BillingAdmin.” These are similar to IAM managed policies but work across accounts.

Then assign users and groups to accounts with specific permission sets. “DevOps team gets PowerUser access to all Production accounts.” “Developers get PowerUser access to Dev accounts but ReadOnly to Production.” One place, all accounts configured.

When users sign in, they see a portal listing all accounts they have access to. Click an account, choose a role, and they’re in—no more juggling credentials or bookmarked console URLs.

Cross-Account IAM Roles

For programmatic access—like CI/CD pipelines or automated scripts—IAM roles with cross-account trust policies are the answer. This works even without AWS Identity Center.

In the target account (where resources live), create an IAM role with a trust policy that allows another account to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id"
        }
      }
    }
  ]
}

Then in the source account, grant IAM principals permission to assume that role. When your pipeline runs, it assumes the cross-account role, gets temporary credentials for the target account, and performs its work.

The ExternalId in the condition is crucial for security—it prevents the “confused deputy” problem where a third party might trick you into assuming a role you shouldn’t.

AWS Control Tower: Organizations on Autopilot

AWS Control Tower builds on Organizations to automate multi-account setup. It creates a “landing zone”—a pre-configured multi-account environment following AWS best practices. AWS Control Tower documentation.

Control Tower automatically creates core accounts (log archive, security audit), sets up Organization Units, applies guardrails (pre-packaged SCPs), and configures baseline security services. It’s like having an AWS architect set up your organization structure for you.

Use Control Tower when starting from scratch or when you need AWS’s opinionated structure. It’s particularly valuable for regulated industries where compliance frameworks are critical.

However, if you already have a complex existing organization, Control Tower’s opinionated approach might conflict with your structure. In that case, manually configure Organizations with your own OU design.

💭 Scaling Reflection: When scaling to 10+ accounts, which would you choose—manually creating and managing IAM roles for cross-account access, or implementing AWS Identity Center for centralized user management? Consider the trade-offs: Identity Center requires more initial setup but dramatically reduces ongoing management. Cross-account roles work great for service-to-service access but create user management complexity. What’s your threshold for choosing one over the other?

Real-World DevOps Use Cases: Where AWS Organizations Shines

Theory is useful, but let me show you how AWS Organizations solves actual DevOps challenges I’ve encountered.

Use Case 1: Multi-Account CI/CD Pipeline

Your CI/CD pipeline runs in a dedicated Tooling account, but it needs to deploy to multiple environment accounts—Dev, Staging, Production. Without Organizations, you’d need to manage credentials for each target account in your pipeline.

With Organizations and cross-account roles, the solution is elegant:

Create a “DeploymentRole” in each environment account with trust policies allowing the Tooling account to assume it. Configure your CodePipeline or Jenkins jobs to assume the appropriate role for each deployment stage. The pipeline never needs long-term credentials—just assumes roles on-demand.

Add SCPs to ensure only the Tooling account can assume these deployment roles, preventing manual deployments that bypass your pipeline.

Use Case 2: Centralized Logging Architecture

Every account should send logs to a central location for security analysis and compliance. Create a dedicated Security or Logging account. Configure CloudTrail, VPC Flow Logs, and application logs from all member accounts to ship to S3 buckets in the Logging account.

Use an SCP to prevent anyone (even in the Logging account) from deleting these logs. Set up S3 lifecycle policies to transition older logs to Glacier for cost-efficient long-term retention.

With consolidated logging, your security team has one place to investigate incidents, run queries, and build detection rules that span your entire infrastructure.

Use Case 3: Shared Services Account for Networking

Large organizations often need shared networking resources—transit gateways, direct connect connections, centralized DNS. Create a Shared Services or Networking account that owns these resources.

Use AWS Resource Access Manager (RAM) to share the transit gateway with other accounts in your organization. Workload accounts attach their VPCs to the shared transit gateway without duplicating expensive networking infrastructure.

This pattern enables hub-and-spoke network topologies where the Shared Services account is the hub, and workload accounts are spokes—all managed within your organization’s structure.

Use Case 4: Sandbox Accounts for Experimentation

Developers need space to experiment without fear of breaking production or incurring massive costs. Create a Sandbox OU with accounts that have:

• Permissive SCPs allowing most services (except dangerous security operations)
• AWS Budgets with alerts when spending exceeds thresholds
• Automated account wiping on a schedule (weekly or monthly) to control costs
• Clear isolation from production networks

Developers get freedom to try new services, prototype architectures, and learn AWS hands-on. The organization maintains cost control and security boundaries through SCPs and budgets.

💭 Reflection Prompt: How would you balance developer agility with security if developers need occasional elevated privileges? Would you use temporary role elevation, an approval workflow, or ephemeral sandbox accounts? Consider scenarios like: a developer needs one-time access to production logs for debugging, or a team wants to test a new AWS service that’s currently blocked by SCPs. What governance model maintains both velocity and control?

🧠 Mini Quiz: You attach an SCP to the root that explicitly allows only s3:GetObject and s3:ListBucket for everyone in the organization. A developer in a member account has an IAM policy that grants s3:* on a specific bucket. Will they be able to put (upload) objects to that bucket?

Answer: No. If the SCP restricts allowed actions using an explicit allow list, IAM policies cannot grant permissions beyond that boundary. The SCP acts as the maximum permission ceiling—even though the IAM policy says s3:*, the SCP’s allow list only includes GetObject and ListBucket, so PutObject is blocked at the organizational level. This is why most organizations use deny lists (blocking specific dangerous actions) rather than allow lists, as allow lists require maintaining comprehensive lists of every action users might legitimately need.

Common Mistakes to Avoid: Learn from Others’ Pain

I’ve made or witnessed every mistake on this list. Learn from our collective experience:

Mistake 1: Using the Root Account for Daily Operations

The root account should be locked away and rarely accessed. Some organizations continue using the root account for management tasks “because it’s easier.” This is asking for trouble. One compromised password and your entire organization is exposed. Always use IAM users or Identity Center for administrative work, even in the root account.

Mistake 2: Not Enforcing SCPs at the OU Level

Some teams create beautiful OU structures but never attach SCPs to them, treating them as purely organizational. This wastes Organizations’ primary security benefit. Even basic SCPs—preventing CloudTrail disabling, blocking public S3 buckets, restricting regions—dramatically reduce your attack surface.

Mistake 3: Mixing Billing and Production Resources

Never run production workloads in your root account. The root account should be for organization management only—creating accounts, configuring organization-wide settings, viewing consolidated billing. Keep it clean. Production belongs in dedicated member accounts within your Production OU.

Mistake 4: Forgetting to Remove Old Invited Accounts

When you invite existing accounts into your organization, they keep running whatever was already there. Teams sometimes invite accounts, realize they’re not needed, but forget to remove them. Months later, you’re paying for forgotten resources in accounts you don’t even use. Audit your member accounts quarterly and remove any that aren’t actively managed.

Mistake 5: Ignoring Cross-Account Trust Policies

Setting up cross-account IAM roles requires trust policies in both accounts—the account owning the role, and the account allowed to assume it. Missing either side, and the role assumption fails with cryptic permission errors. Document your cross-account access patterns and regularly audit trust relationships.

Mistake 6: Not Testing SCPs Before Production

SCPs can break things spectacularly if misconfigured. Always test new SCPs on a development account first. Attach the SCP, verify critical workflows still function, then roll it to production OUs. I’ve seen overly broad deny statements lock teams out of accounts entirely—requiring root account intervention to fix.

Cost and Pricing: What You Need to Know

AWS Organizations is completely free. You don’t pay anything to create an organization, add accounts, structure OUs, or apply SCPs. Zero cost for the service itself.

However, mismanagement within Organizations can definitely increase costs. Here’s what to watch:

Leaving Unused Accounts Active

Every AWS account has some baseline costs even with zero usage—S3 storage, EBS volumes that weren’t deleted, NAT Gateways still running. Multiply this across ten unused accounts, and you’re bleeding money. When you create an account, use it purposefully, or shut it down properly.

Not Leveraging Consolidated Billing Benefits

You’re already paying for AWS resources. Not taking advantage of volume pricing through consolidated billing means you’re overpaying unnecessarily. Review your Cost Explorer at the organization level to understand where volume tiers could save money.

Over-Provisioning Across Accounts

With separate accounts comes the temptation to duplicate infrastructure “just in case.” Each account gets its own VPN connection, its own NAT Gateways, its own load balancers—even when sharing would work fine. Architect for appropriate isolation, but avoid needless duplication of expensive resources.

Cost Control Strategies

Enable AWS Budgets at the organization level to set spending alerts across all accounts or per-account. When your Development OU exceeds its monthly budget, you get notified before the bill becomes painful.

Use Cost Allocation Tags consistently across accounts. Tag everything with “Environment,” “Team,” “Project,” and “Owner.” Then generate cost reports that slice by these dimensions organization-wide.

Create SCPs that prevent launching expensive instance types in non-production environments. If developers don’t need 96-vCPU instances in Dev, deny them at the SCP level. Cost control through policy enforcement.

Implement automated account cleanup. Lambda functions that scan for unused resources—unattached EBS volumes, old snapshots, stopped instances—and either delete them or alert owners. Run these across all organization accounts from a central automation account.

Frequently Asked Questions

Wrapping Up: Your Cloud Command Center Awaits

Think of AWS Organizations as your cloud command center. Once set up properly, it gives you control, clarity, and confidence. You’re no longer drowning in account sprawl or wondering if someone just disabled CloudTrail in a production account.

The initial setup takes thought—designing your OU structure, crafting your first SCPs, deciding whether to use Identity Center. But that investment pays dividends immediately in simplified management, enhanced security, and reduced costs.

Remember the key principles: structure your organization to match how your teams actually work, use SCPs to prevent dangerous actions organization-wide, leverage consolidated billing for cost optimization, and integrate security services across all accounts from day one.

Whether you’re managing three accounts for a small startup or three hundred for an enterprise, AWS Organizations provides the governance framework to do it right. Start with a simple structure—you can always expand and refine as you grow.

The DevOps engineers who master AWS Organizations become force multipliers for their organizations. They architect multi-account environments that are secure by default, cost-efficient by design, and scalable as the business grows.

👉 Ready to Build Your Multi-Account Architecture?

Take the free AWS Organizations hands-on lab at TheDevOpsTooling and learn to build secure multi-account environments like a pro. Follow along with real-world scenarios, practice creating OUs and SCPs, and get your AWS infrastructure under control. Access hands-on labs.