3.2.2. AWS Organizations for Network Governance (SCPs)

AWS Organizations and Service Control Policies (SCPs) centralize network governance, enforcing consistent network policies and preventing unauthorized network operations across multiple AWS accounts at scale.

Scenario: You need to ensure that no developer can accidentally create public S3 buckets or launch EC2 instances in unauthorized AWS Regions across all development accounts in your organization.

For network specialists managing complex enterprise AWS environments, defining and enforcing network policies across many accounts is a significant challenge. AWS Organizations provides the framework for this.

AWS Organizations is a service that helps you centrally manage and govern your AWS environment as you grow and scale your AWS resources. It allows you to group accounts into Organizational Units (OUs).

Service Control Policies (SCPs) are a powerful type of policy within AWS Organizations.

Key Features of AWS Organizations & SCPs for Network Governance:

• Centralized Control: Manage network-related permissions and policies from a single master account.
• Multi-Account Management: Organize and manage multiple AWS accounts within a hierarchical structure (OUs).
• Preventative Guardrails (SCPs):
  • Concept: SCPs set the maximum available permissions for all IAM users and roles in member accounts (including the root user).
  • Network Use Cases: Prevent users from creating public S3 buckets or EC2 instances in specific Regions. Restrict changes to critical network resources (e.g., Transit Gateways).
  • Enforcement: An explicit Deny in an SCP overrides any Allow in an IAM policy.
• S3 Block Public Access: Account-level Block Public Access blocks public ACLs and public bucket policies for every current and future bucket in the account — a preventive control, unlike detective Config rules or Macie. Enable it in every account and use an SCP to deny s3:PutAccountPublicAccessBlock so member accounts cannot turn it off.

Practical Implementation: Example SCP to Deny Public S3 Buckets

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPublicS3Buckets",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketAcl",
        "s3:PutBucketPolicy",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ],
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": [
            "public-read",
            "public-read-write",
            "authenticated-read"
          ]
        },
        "Bool": {
          "s3:x-amz-grant-read-acp": "true",
          "s3:x-amz-grant-write-acp": "true",
          "s3:x-amz-grant-read": "true",
          "s3:x-amz-grant-write": "true",
          "s3:x-amz-grant-full-control": "true"
        }
      }
    }
  ]
}

⚠️ Common Pitfall: Applying SCPs too broadly without testing. SCPs are powerful and can inadvertently block legitimate actions across an entire organization if not carefully designed and tested in a sandbox OU first.

Key Trade-Offs:

• Centralized Control vs. Decentralized Autonomy: SCPs provide strong centralized control but can limit the autonomy of individual accounts. Finding the right balance is key for enterprise governance.

Reflection Question: How do AWS Organizations (for centralized management) and Service Control Policies (SCPs) (for preventative guardrails) fundamentally enable network governance, enforcing consistent network policies and preventing unauthorized network operations across multiple AWS accounts at scale?