Phase 4: Security & Compliance

AWS Organizations, SCPs & multi-account governance

Advanced ~2 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you have a HUGE collection of Lego. Like, hundreds of sets, thousands of bricks! If it all just sat in one giant pile, it would be super messy. It would be hard to find pieces, easy to break someone else's project, and really difficult to keep track of everything. In the world of cloud computing, big companies have lots of digital "Lego projects" happening at once, and they need a clever way to keep everything tidy, safe, and organized.

That's where something called AWS Organizations comes in. Think of AWS Organizations as your super-organized Lego storage system. Instead of one giant pile, you get lots of separate, smaller Lego boxes. Each box is like an "account" in the cloud – maybe one box is for building spaceships, another for castles, and another for race cars. You can even group these boxes together into bigger categories, like putting all your "fantasy" Lego sets into one big cupboard, and all your "science fiction" sets into another. These bigger categories are called "Organizational Units." This helps everyone know exactly where everything is and keeps different projects from getting mixed up. It also means you get one simple bill for all the digital Lego you use across all your projects.

Now, let's say you have some special, super-rare Lego bricks, like glow-in-the-dark pieces, or maybe some delicate parts that break easily. You definitely don't want someone accidentally using them in a project where they're not supposed to be, or worse, breaking them! That's where "Service Control Policies" (SCPs) come in. Think of SCPs as special rules you put on your Lego boxes or even entire cupboards. These rules might say, "No glow-in-the-dark bricks allowed in the race car box!" or "You can't use these super-delicate castle windows in the rough-and-tumble spaceship battles."

The important thing about these rules is they never give you new Lego pieces; they only stop you from using certain pieces where they shouldn't be. They're like fences or warning signs for your Lego. So, if your spaceship builders accidentally try to grab a delicate castle window, the SCP rule will stop them. This means you can keep your awesome digital Lego collection safe and organized, making sure everyone builds what they're supposed to, where they're supposed to, without breaking important rules or messing up someone else's creation. When you start building your own cloud projects, this helps you keep your digital constructions secure and well-managed, just like a master Lego builder!

As a Cloud Architect, mastering AWS Organizations is foundational for effective multi-account strategies and centralized governance. AWS Organizations enables you to consolidate multiple AWS accounts into a single, centrally managed structure. This provides key benefits like consolidated billing, central identity management (via AWS SSO), and most critically, the ability to apply guardrails across your entire cloud estate. A well-designed multi-account strategy is paramount for security (reducing blast radius, strong isolation), operational efficiency (environment separation), cost allocation, and regulatory compliance. Organizations allow you to group accounts into Organizational Units (OUs), mirroring your company's structure or compliance zones, such as Security, Networking, Production, Development, or Sandbox OUs.

Service Control Policies (SCPs) are the powerhouse of multi-account governance within AWS Organizations. SCPs are a type of organization policy that specifies the maximum permissions that all IAM principals (users, roles, groups) can have within any account associated with the SCP. Crucially, SCPs are guardrails – they never grant permissions, they only restrict them. Even if an IAM policy within an account explicitly grants a permission, an SCP denying that same permission at an OU or Organization root level will always take precedence. This allows you to enforce baseline security and compliance requirements across your entire organization, such as preventing root user sign-ins, blocking access to specific AWS regions, or disallowing the deletion of critical logging resources (e.g., CloudTrail S3 buckets).

Effective multi-account governance hinges on strategically designing your OU structure and applying granular SCPs. For instance, you might place stricter SCPs on your Production OUs to limit actions and approved regions, while applying more permissive policies to Sandbox OUs. SCPs operate on an explicit deny takes precedence principle, meaning any explicit deny in an SCP will override any allow. This allows architects to implement robust security postures at scale, ensuring consistent adherence to policies irrespective of individual account configurations. Understanding the hierarchical inheritance and evaluation logic of SCPs is critical for architects to prevent unintended restrictions while ensuring a strong security posture across dozens, or even hundreds, of accounts.

Key Takeaways

  • AWS Organizations centralizes management and billing for multiple AWS accounts.
  • SCPs are organizational-level guardrails that restrict the maximum permissions for all IAM principals.
  • SCPs cannot grant permissions; they only deny them, overriding any IAM policy allow.
  • A well-designed OU structure combined with granular SCPs is fundamental for multi-account governance.
  • Use SCPs to enforce baseline security, compliance, and prevent common misconfigurations across your AWS estate.

Code Example

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:root"
          ]
        }
      }
    }
  ]
}

How this code works

This Service Control Policy (SCP) serves a critical security function: it prevents the AWS account root user from performing any actions within any account where this SCP is applied. This enforces the best practice of never using the root user for day-to-day operations, ensuring all administrative tasks are performed by IAM users or roles with specific, least-privilege permissions. By effectively disabling the root user, it significantly reduces the attack surface and helps maintain a robust security posture across an AWS Organization.

The policy achieves this with an Effect of Deny, which is crucial because an explicit Deny always overrides any Allow statements from other policies. It applies this Deny to Action: "*" and Resource: "*", ensuring absolutely no operations can be performed. The key targeting mechanism is the Condition block, which checks the aws:PrincipalArn (the identity making the request). Using StringLike, the policy specifically matches any ARN that ends with :root (e.g., arn:aws:iam::123456789012:root), identifying the root user in any account. This ensures that only the highly privileged root user is restricted, leaving IAM users and roles unaffected.

Related Articles

Hand-picked reads to go deeper on iam deep dive.

Back to Cloud Architect Roadmap