Service Control Policies for Networking: A Comprehensive Guide

Introduction: Why Governance Matters in Cloud Networking

In the early days of cloud computing, the primary focus for engineers was connectivity—getting systems to talk to one another, establishing VPNs, and ensuring that packets reached their destination. However, as cloud environments have scaled into massive, multi-account architectures, the challenge has shifted from simple connectivity to control. When you have hundreds of developers, automated scripts, and various departments deploying infrastructure, the risk of misconfiguration—such as an accidentally public database or an unauthorized internet gateway—becomes a significant operational and security concern.

This is where Service Control Policies (SCPs) enter the picture. SCPs are a fundamental governance mechanism used in cloud environments to define the maximum permissions that any user, group, or service role can have within an account or an entire organizational unit. Unlike standard identity-based policies that grant permissions, SCPs act as a guardrail, explicitly denying actions even if a user has full administrative rights. In the context of networking, SCPs ensure that no matter how much freedom a developer has, they cannot bypass the security standards established by the central networking or security team.

Understanding SCPs is critical because they provide a "deny-by-default" layer of security that exists outside the standard IAM workflow. By mastering these policies, you can prevent the creation of unauthorized network components, enforce the use of specific virtual private clouds (VPCs), and mandate that all traffic flows through approved inspection points. This lesson will guide you through the theory, implementation, and best practices of using SCPs to govern your network architecture.

The Role of SCPs in Network Governance

Governance is the practice of ensuring that IT resources are used in alignment with business requirements and regulatory standards. In a cloud networking context, governance often involves enforcing a "hub-and-spoke" topology, ensuring that all traffic is logged, and preventing the creation of shadow IT infrastructure. Without SCPs, governance relies entirely on reactive monitoring—waiting for an alert that someone has created an unapproved resource and then manually deleting it.

SCPs shift this paradigm to proactive prevention. Because SCPs are applied at the organizational root or organizational unit (OU) level, they are inherited by every child account. If you implement an SCP that prevents the creation of internet gateways in production accounts, it is physically impossible for even a root user in those accounts to bypass that restriction. This creates a predictable environment where the central networking team can guarantee the integrity of the network perimeter.

How SCPs Interact with IAM Policies

It is important to clarify that SCPs do not grant permissions; they only filter them. Think of it as a two-key system. To perform an action, the user must have permission granted by an IAM policy, and that action must not be explicitly denied by an SCP. If an IAM policy grants "Full Access" but an SCP contains a "Deny" rule for a specific networking action, the action will fail. This hierarchy is essential for security teams who need to maintain control over sensitive infrastructure while allowing developers to manage their own application-level resources.

Callout: The "Deny" Logic Unlike traditional IAM policies where you can mix Allow and Deny statements, SCPs are primarily used to define boundaries. If you create an SCP, it essentially acts as a logical "AND" operator with the user's IAM permissions. If an SCP says "Deny all CreateVPC actions," it does not matter if the user has a policy that says "Allow all actions." The request will be rejected. This is the cornerstone of cloud security, as it provides a hard stop against accidental or malicious configuration changes.

Designing Network Guardrails: Common Use Cases

When planning your networking SCPs, you should focus on the most common areas of risk. These typically involve resource creation, modification, and deletion. Below are the primary areas where governance is most needed.

1. Preventing Unauthorized Internet Access

One of the most dangerous misconfigurations is an engineer accidentally attaching an Internet Gateway (IGW) to a VPC that is meant to be private. An SCP can be written to prevent the creation of IGWs or the modification of route tables to point to an IGW in specific accounts.

2. Standardizing Network Connectivity

Many organizations require all VPCs to connect to a central hub, such as a Transit Gateway or a peering connection. By using an SCP, you can prevent users from creating unauthorized peering connections or VPNs, forcing them to use the approved connectivity methods provided by the central network team.

3. Restricting VPC Creation

In highly regulated industries, allowing developers to create their own VPCs can lead to address space collisions and unmanaged IP ranges. An SCP can be used to restrict the ability to create VPCs to only the core infrastructure team, or to require that all new VPCs are created using a specific automated provisioning tool that tags resources correctly.

4. Protecting Network Infrastructure

Once a network component is deployed, it often needs to remain untouched. You can use SCPs to prevent the deletion or modification of critical network resources like NAT Gateways, Direct Connect connections, or firewall rules. This prevents a rogue or compromised account from taking down an entire segment of the network.

Implementing SCPs: Practical Examples and Code

To implement an SCP, you must have an organization set up with "All Features" enabled. SCPs are written in JSON format, using the same syntax as IAM policies. Let's look at a concrete example.

Example 1: Preventing the Creation of Internet Gateways

This policy prevents any user, including administrators, from creating an Internet Gateway in any account where the policy is applied.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInternetGatewayCreation",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateInternetGateway",
        "ec2:AttachInternetGateway"
      ],
      "Resource": "*"
    }
  ]
}

Explanation:

• Version: Defines the policy language version.
• Sid: A descriptive identifier for the policy statement.
• Effect: Set to "Deny" to explicitly forbid the actions.
• Action: Lists the specific API calls to block (CreateInternetGateway and AttachInternetGateway).
• Resource: The asterisk indicates this applies to any resource within the scope of the account.

Example 2: Restricting Route Table Modifications

Often, you want to allow developers to manage their own subnets but prevent them from changing route tables that direct traffic to the internet.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictRouteTableEdits",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateRoute",
        "ec2:ReplaceRoute",
        "ec2:DeleteRoute"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "ec2:RouteTableId": "rtb-0123456789abcdef0"
        }
      }
    }
  ]
}

Explanation: This policy uses a Condition block to target a specific route table. This is a powerful way to protect central infrastructure (like a core transit VPC) while still allowing flexibility elsewhere in the account.

Step-by-Step Implementation Process

Implementing governance at scale requires a methodical approach to avoid breaking existing workflows. Follow these steps to deploy SCPs safely.

Step 1: Audit Existing Infrastructure

Before you apply a "Deny" policy, you must ensure that it will not break production traffic. Use logs (such as CloudTrail) to identify who is currently creating or modifying network resources. If you find that developers are frequently creating IGWs for testing, you must provide an alternative—such as a NAT Gateway or a pre-provisioned testing VPC—before you restrict the original action.

Step 2: Create a Test OU

Never apply an SCP directly to your production root. Create a "Sandbox" or "Test" Organizational Unit in your account hierarchy. Move a non-production account into this OU and apply the SCP there first. This allows you to observe the impact of the policy in a safe environment.

Step 3: Use Dry-Run or Monitoring

If your cloud provider supports it, use "dry-run" modes or audit-only policies. An audit-only policy is a simple IAM policy that logs when someone tries to perform an action, without actually denying it. This helps you verify that your policy logic is correct before you flip the switch to "Deny."

Step 4: Deploy to Production

Once you have validated the policy, attach the SCP to the relevant production OUs. Remember that SCPs are inherited. If you apply a policy to the Root, it applies to every account. It is usually best to apply policies to specific OUs (e.g., "Production", "Development", "Security") rather than the root itself.

Warning: The "Locked Out" Scenario Be extremely careful when writing SCPs. Because SCPs affect everyone, including the account root user, you could accidentally lock yourself out of critical network administration tasks. Always ensure that you have at least one "break-glass" account or a specific OU that is exempt from these policies to maintain administrative control.

Industry Standards and Best Practices

Governance is not a one-time project; it is an ongoing process. To maintain a secure network, adopt the following industry-standard practices.

1. Principle of Least Privilege

Apply the most restrictive SCP possible. If your organization only uses a specific region, create an SCP that denies all network actions in every other region. This reduces your attack surface significantly.

2. Consistent Tagging

Use SCPs to enforce tagging. You can write a policy that denies the creation of any network resource (like a VPC or subnet) if it does not contain a specific set of tags, such as ProjectID or Environment. This ensures that every piece of network infrastructure is accounted for in your billing and monitoring tools.

3. Maintain Documentation

Governance policies can become complex. Maintain a registry of all active SCPs, their purpose, and the accounts they affect. When a developer reports a "Permission Denied" error, your support team should be able to quickly check the registry to see if an SCP is the cause.

4. Automated Testing

Treat your SCPs like code. Store them in a version control system (like Git), and run automated tests against them to ensure they do not conflict with each other. As your organization grows, the number of SCPs will increase; automated testing is the only way to ensure they remain functional.

Comparison Table: IAM vs. SCP

Understanding the distinction between IAM policies and SCPs is the most common hurdle for new cloud administrators.

Callout: The "Maximum Boundary" Concept Think of SCPs as the "ceiling" of a room. An IAM policy is the person inside the room. No matter how high the person jumps (their IAM permissions), they can never go through the ceiling (the SCP). If the ceiling is set too low, they hit their head. This is why you must set your SCPs high enough to allow necessary work, but low enough to maintain security.

Common Mistakes and How to Avoid Them

Mistake 1: Overly Broad "Deny" Statements

A common mistake is creating a policy that is too broad, such as "Deny all EC2 actions." This will break not only networking but also the ability to launch instances, manage security groups, and view logs.

• The Fix: Always be as specific as possible. If you want to restrict networking, target the specific API calls like ec2:CreateVpc or ec2:AuthorizeSecurityGroupIngress.

Mistake 2: Ignoring Global Resources

Some resources are global, meaning they exist outside of a specific region. If you write an SCP that restricts actions in "us-east-1," it might not affect global network services like Route 53 or CloudFront.

• The Fix: Review your resource types and ensure your SCPs cover the global footprint of your cloud environment.

Mistake 3: Failing to Test in a Sandbox

Applying an SCP to a production account without testing is the fastest way to cause a self-inflicted outage.

• The Fix: Always test in a dedicated Sandbox account. Even better, use a staging environment that mimics your production network topology.

Mistake 4: Not Communicating with Developers

If developers suddenly lose the ability to create VPCs without prior warning, productivity will grind to a halt.

• The Fix: Governance is a team effort. Communicate the upcoming SCP changes to the development teams, explain why the changes are necessary, and provide them with the approved path forward (e.g., "Use the automated provisioning portal instead of manual VPC creation").

Advanced Governance: Using Conditions in SCPs

To make your SCPs more intelligent, use Condition keys. For example, you can allow network creation only if the request comes from a specific IP address (like your corporate office) or if the request is made by a specific service role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowNetworkingOnlyFromCorporateVPN",
      "Effect": "Allow",
      "Action": "ec2:CreateVpc",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.0.2.0/24"
        }
      }
    }
  ]
}

This approach allows you to enforce "location-based" security. Even if a user has the right credentials, they cannot modify the network unless they are connected to the trusted corporate network. This is an excellent way to prevent unauthorized changes from public Wi-Fi or compromised remote machines.

FAQ: Common Questions about SCPs

Q: Can I use SCPs to restrict traffic between VPCs? A: No, SCPs control the ability to make API calls (like creating a peering connection), not the actual traffic flow between resources. To control traffic flow, you should use Network Access Control Lists (NACLs) or Security Groups.

Q: What happens if I have multiple SCPs attached to the same OU? A: SCPs are additive. If one policy denies an action and another allows it, the "Deny" wins. The final effective permission is the intersection of all policies.

Q: Do SCPs apply to the root user of a member account? A: Yes. This is one of the most powerful features of SCPs. Even the root user of a member account is subject to the guardrails defined by the organization's root account.

Q: Is there a limit to how many SCPs I can have? A: Yes, there are service quotas on the number of SCPs and the size of each policy. Keep your policies concise and well-structured to avoid hitting these limits.

Conclusion: Key Takeaways for Network Governance

Implementing Service Control Policies is a vital step in maturing your cloud networking strategy. By shifting from manual oversight to automated, policy-driven guardrails, you ensure that your network remains secure, compliant, and predictable.

Here are the key takeaways from this lesson:

1. SCPs are Guardrails, Not Permissions: They act as a "deny-by-default" filter that sits above IAM, ensuring that no user, including administrators, can perform actions that violate organizational policy.
2. Proactive over Reactive: Use SCPs to prevent unauthorized network configurations (like public internet gateways) before they are created, rather than cleaning up after they are deployed.
3. Hierarchy Matters: Understand that SCPs are inherited from the organizational root down to child accounts. Design your OU structure carefully to apply policies at the appropriate level.
4. Test Before Deploy: Always test policies in a sandbox environment. A poorly written SCP can easily cause a self-inflicted outage across your entire organization.
5. Use Conditions for Granularity: Leverage Condition blocks to create sophisticated rules that allow actions only under specific circumstances, such as from trusted IP ranges or with specific tags.
6. Collaborate with Developers: Governance should not be a secret. Communicate your policies clearly so that developers understand the approved ways to provision infrastructure.
7. Treat Infrastructure as Code: Store your SCPs in version control, document their purpose, and implement automated testing to ensure they continue to function as intended as your environment scales.

By following these principles, you will build a robust networking foundation that allows your organization to innovate safely and at speed. Governance is not about blocking progress; it is about providing a safe environment where developers can work without the constant fear of triggering a security breach.