Enforcing AWS Guardrails with Service Control Policies (SCPs) 

By Igunma Ighile, Technical Architect 

The Problem 

Growing your AWS environment is exciting until it isn’t. Accounts multiply, developers need access, and before you know it, someone has spun up resources in the wrong region or ended up with more permissions than they should have. This usually happens as environments scale faster than governance controls can keep up. And the bigger your environment gets, the harder it is to keep track of. 

Chasing down issues after the fact only gets you so far. At some point, you need guardrails that are always on, no matter what’s happening inside any given account. That’s where Service Control Policies come in. 

What Are SCPs? 

SCPs are a feature of AWS Organizations that let you define the maximum permissions available to accounts in your organization. The key word here is maximum. An SCP doesn’t grant access to anything. It just sets the outer limit of what’s possible, and whatever IAM policies exist inside an account, an SCP can still prevent those actions from executing. 

A few things worth knowing upfront: 

  • SCPs are not grants. An SCP that allows “s3:*” doesn’t mean every principal can access S3. IAM still has to explicitly grant the permission. 
  • SCPs do not apply to the management account. The root account of your organization sits completely outside SCP enforcement. 
  • SCPs apply to every principal in a member account, including that account’s root user. IAM can’t touch the root user, but SCPs can restrict what it’s allowed to do. 
  • SCPs do not directly modify resource-based policies, but they still affect whether principals in member accounts can perform actions, even when a resource policy allows access.  

What SCPs Protect Against 

When configured well, SCPs are one of the most effective preventive controls in AWS. Some of the most common use cases include blocking privilege escalation by preventing principals from modifying IAM policies beyond a defined scope, restricting API calls to approved regions only, limiting what the root user in a member account can do, and preventing accounts from leaving the organization entirely. You can also use them to make audit controls like CloudTrail and GuardDuty non-negotiable by blocking any attempt to disable them. 

What No One Tells You About SCPs 

This is where most teams run into trouble. 

1. The Management Account Is Fully Exempt 

It bears repeating because it surprises people every time: SCPs do not apply to the management account. Any IAM principal operating from that account can take any action regardless of what SCPs exist in the org. This is by design, and it’s part of why the management account should be treated as a break-glass environment with minimal access and no active workloads. 

2. Deny List and Allow List Behave Very Differently 

AWS gives every org a default FullAWSAccess SCP. Most teams operate on a deny list model, keeping that default and layering on targeted denies. The alternative is removing FullAWSAccess and defining only what’s allowed. Teams that make this switch mid-deployment without a thorough audit often find things breaking in ways that are genuinely hard to trace. 

3. Service-Linked Roles Can Get Blocked 

If your SCP broadly restricts role creation, you may accidentally prevent AWS from creating service-linked roles required by services like EKS, RDS, or Security Hub. Be intentional about excluding required service-linked role creation from broad deny conditions.  

 

4. Cross-Account Access Can Fail in Unexpected Ways 

If a principal in Account B is subject to an SCP denying s3:GetObject, the request fails even if Account A’s bucket policy explicitly allows access. The bucket policy may permit the request, but the SCP still blocks the principal from performing the action. This often catches teams off guard in managed service provider (MSP) environments where cross-account data pipelines and shared access patterns are common. 

5. AWS Landing Zone Accelerator’s Default SCPs Can Conflict with Custom Ones 

If you’re running AWS Landing Zone Accelerator (LZA), it ships with its own SCPs at the Organizational Unit (OU) level. Custom SCPs added through the console can get overwritten on the next pipeline run, and policies defined outside of LZA’s configuration files can drift out of sync quickly. If LZA manages your org, it needs to be your single source of truth for SCP changes. 

Best Practices 

Start with the deny list approach and build from there. Design your OU structure to reflect your actual policy boundaries since SCPs inherit down the tree. Document every SCP with clear intent so whoever inherits your environment isn’t left guessing. Test changes in a sandbox OU before rolling them out broadly. And when something breaks, CloudTrail is your best friend. Filter for serviceControlPolicy in your AccessDenied events and you’ll find the culprit much faster than manually tracing policy evaluation logic. 

Pulling It All Together 

SCPs are one of the most effective preventive governance controls available in AWS. The earlier they are designed thoughtfully, the easier it becomes to scale securely without constantly reacting to avoidable misconfigurations and permission drift. 

Ready to strengthen governance across your AWS environment? TekStream helps organizations implement scalable AWS security controls, governance frameworks, and cloud architectures that enable innovation without sacrificing control. Contact our team to learn how we can help secure your AWS environment.

About the Author

Igunma Ighile is a Technical Architect with strong background in cloud infrastructure, security architecture, and DevSecOps across the AWS platform. His cloud journey has consisted of designing cloud migration strategies and optimizing infrastructure performance for enterprise clients. Over the years, he has led critical security and network modernization initiatives for Fortune 500 organizations, driving secure, scalable, and highly available architectures. 

Igunma has designed and automated infrastructure using Terraform and PowerShell, implemented security solutions leveraging AWS native services like WAF, GuardDuty, and Security Hub, and developed event-driven architectures with Lambda and API Gateway. He has also worked across cross-functional teams to enhance visibility into remote access environments, optimize VPN and Zscaler configurations, and bridge cloud/on-prem gaps. 

Prior to joining TekStream, Igunma held architect and engineering roles supporting cloud transformations, security enforcement, and infrastructure automation. He holds certifications as an AWS Certified Solutions Architect Associate and Salesforce Platform App Builder and Administrator. Osayawe graduated with a B.S. in Civil Engineering from the University of Missouri – Kansas City and currently resides in Atlanta, GA with his wife and son.