AWS Services
Service Control Policies
Understand service control policies as AWS Organizations permission guardrails, including effective permissions, OU inheritance, deny strategies, testing, and exam traps.
After this, you will understand
SCPs explain one of the most common AWS governance confusions: the difference between granting access and limiting what access can ever be granted.
A service control policy sets the maximum available permissions for IAM users and roles in AWS Organizations member accounts.
Learners expect SCPs to grant permissions or forget that a blocked action stays blocked even for an account administrator.
Use SCPs as organization-level guardrails for member accounts, then use IAM policies inside accounts to grant least-privilege access.
Think before readingIf an SCP allows S3 but an IAM user has no S3 permissions, can the user access S3?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Service control policies
- Permission guardrails
- Effective permissions
- Explicit deny
- Allow-list and deny-list strategies
- FullAWSAccess
- OU inheritance
- Management account exception
- Service-linked role exception
- SCP testing and rollout
- SAA-C03 traps
1. Plain-English Mental Model
A service control policy is a permission ceiling for AWS Organizations member accounts.
The simple model is:
effective permission = allowed by IAM and allowed by SCPs
An SCP does not hand anyone access. It says what access is allowed to be possible inside member accounts. IAM policies, resource policies, permission boundaries, and session policies still participate in the final permission decision.
This is the heart of SCPs:
IAM grants access only inside the box that SCPs permit.
If an SCP denies an action, an account administrator cannot bypass it by attaching AdministratorAccess inside the member account.
2. Why This Service Exists
In a multi-account environment, local administrators can become too powerful.
Imagine every workload account has an admin role. Those admins may need broad authority to operate their workloads, but the organization may still want non-negotiable rules: do not disable CloudTrail, do not use unapproved Regions, do not leave the organization, do not create certain network paths, do not delete required security tooling.
SCPs exist to express organization-wide guardrails above the account.
They are especially useful because IAM policies are account-local. A production account admin can attach powerful permissions inside the account, but an SCP attached to the account or its OU can still limit what those permissions can do.
For SAA-C03, SCPs appear in questions about preventing member accounts from using services, enforcing allowed Regions, protecting audit services, limiting even administrators, and applying controls to groups of accounts.
3. The Naive Approach And Where It Breaks
The naive governance pattern is "trust each account admin":
member account admin -> AdministratorAccess -> local decisions
This breaks when local convenience conflicts with organization policy. A team may disable logs to debug, launch resources in an unapproved Region, or create a service the company does not allow.
Another naive pattern is to put every restriction in IAM roles inside each account. That is fragile because every account must be kept consistent. A missed role, copied policy, or emergency admin exception can create drift.
Another mistake is writing SCPs too aggressively and attaching them at the organization root without testing. A bad SCP can block deployments, break automation, or remove access to services that accounts depend on.
SCPs are powerful because they are broad. That is also why they require rollout discipline.
4. Core Primitives
An SCP is an AWS Organizations policy type.
SCPs can be attached to the organization root, OUs, or accounts.
Member accounts inherit applicable SCPs from every parent above them.
FullAWSAccess is the default AWS managed SCP that allows all actions. If it is removed without replacement, member account actions can fail because there is no remaining allow path.
Explicit deny in an SCP overrides allows.
An allow-list strategy permits only listed services or actions. It is stricter but harder to maintain.
A deny-list strategy denies specific risky services, actions, or Regions while allowing everything else not denied.
SCPs do not affect users or roles in the management account.
SCPs do not restrict service-linked roles.
5. Architecture Use Cases
Use SCPs to restrict member accounts to approved AWS Regions:
deny requested Region not in approved list
Use them to prevent disabling CloudTrail, AWS Config, GuardDuty, or other baseline security services.
Use them to deny account leaving the organization or changing organization-critical settings.
Use them to create stricter controls for production OUs than for development or sandbox OUs.
Use them with IAM Identity Center permission sets. IAM Identity Center grants workforce access, while SCPs define what cannot be done even when a permission set is broad.
Use CloudTrail and IAM service-last-accessed data to understand what services accounts actually use before tightening SCPs.
7. Security Model
SCPs are a central security guardrail, not a complete security model.
They define maximum available permissions for IAM users and roles in member accounts. They do not directly edit resource policies, and they do not grant access.
Effective permissions depend on the intersection of SCPs, IAM policies, resource policies, permission boundaries, and session policies.
Because SCPs can affect many accounts, access to create, attach, detach, or edit them should be tightly controlled.
The management account exception matters. SCPs do not protect you from mistakes or compromise in the management account. Keep that account hardened.
Service-linked roles are also not restricted by SCPs. AWS services use them for integrations, so do not assume SCPs intercept every service action.
8. Reliability And Resilience
SCPs improve reliability by preventing dangerous actions consistently.
For example, denying deletion of logging infrastructure can preserve incident evidence. Denying unsupported Regions can reduce data residency and operational surprises. Denying removal of security integrations can preserve baseline monitoring.
But SCPs can also cause outages if applied carelessly.
An automation role may need an action that the SCP blocks. A deployment pipeline may rely on a service you forgot to allow. A Region deny policy may accidentally block a global service because of how the API request is evaluated.
Roll out SCPs gradually. Test in a dedicated OU. Move accounts in small groups. Watch CloudTrail and service-last-accessed data.
9. Performance And Scaling
SCPs do not affect application runtime performance directly.
Their scaling concern is policy manageability. Large organizations need clear guardrail patterns, naming, testing, and documentation.
Avoid one-off SCPs for every team if they all express similar controls. Prefer reusable OU-level policy sets.
Keep policies understandable. An SCP that no one can reason about becomes risky.
Use OUs as control boundaries. A clean OU structure makes SCPs easier to apply and debug.
10. Cost Model
SCPs do not have a separate usage charge.
They can reduce cost by preventing unapproved expensive services, limiting Regions, or blocking resource types that create spend risk.
They can also increase work if they block legitimate automation and create support tickets.
The cost model is operational: strong guardrails reduce risk, but poorly tested guardrails slow teams down.
In exam questions, "least operational overhead" often favors central SCPs over manually updating IAM policies in every account.
12. SAA-C03 Exam Signals
"Prevent member accounts from using a service" points to SCPs.
"Restrict all accounts in an OU" points to SCPs attached to that OU.
"Even administrators in member accounts must be blocked" points to SCPs.
"Centrally enforce allowed Regions" often points to SCPs.
"Grant access to a user" points to IAM or IAM Identity Center, not SCPs.
"Management account must be restricted by SCP" is a trap because SCPs do not affect the management account.
"Service-linked role is blocked by SCP" is usually a trap.
13. Common Exam Traps
Do not say SCPs grant permissions.
Do not forget IAM permissions are still required.
Do not forget the management account exception.
Do not forget service-linked roles are not restricted by SCPs.
Do not remove FullAWSAccess without understanding the replacement allow path.
Do not attach broad restrictive SCPs to the root without testing.
15. Related Topics
Review AWS Organizations, IAM Foundations, Identity Policies vs Resource Policies, AWS CloudTrail, and AWS Config.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.