What Is Service Control Policy? Security Definition

Imagine you are managing a large school district with many schools. Each school has its own principal and staff who can make decisions about what happens at their school. However, as the district superintendent, you want to make sure no school does something dangerous, like spending the entire budget on ice cream or allowing unauthorized people onto campus. A Service Control Policy is like a district-wide rulebook that says, no matter what the local principal allows, certain things are completely off limits. For example, you might have a rule that says no school can delete the main student database or change the security cameras. Even if the principal at a school gives permission to do those things, the district rule overrides it.

In cloud computing, an organization might have dozens or hundreds of AWS accounts for different teams or departments. Without central controls, each account administrator could give permissions that violate security policies or cause compliance issues. Service Control Policies sit at the top of the AWS Organizations hierarchy and establish boundaries. They work like a guardrail: they don't give anyone any new abilities, but they set the maximum scope of what is allowed. If an SCP says you cannot use a specific service, then even if an IAM policy grants that service permission, the action is denied.

This concept is different from an IAM policy, which grants specific permissions to users or roles. SCPs are not about granting permissions; they are about limiting them. Think of it like a castle. The king (management account) sets rules for all the knights (member accounts). The knights can decide who gets keys to which rooms (IAM policies), but if the king declares that the treasury room is off limits to everyone, no key can open that door. SCPs do not replace IAM policies; they work together. First, SCPs define the overall allowed actions, and then IAM policies determine who within that boundary can actually perform those actions.

SCPs can be used to enforce a wide variety of controls, such as preventing the deletion of critical resources, restricting access to certain regions for data sovereignty, or blocking the use of high-cost services. They are essential for organizations that need to maintain security and compliance across multiple accounts without micromanaging every policy. They are also a key tool for implementing the principle of least privilege at scale, because you can centrally block dangerous actions and then trust account administrators to grant only the permissions that remain available.

A Service Control Policy (SCP) is a policy document in JSON format that is used within AWS Organizations to centrally control the maximum available permissions for all accounts in the organization. SCPs are not identity-based policies or resource-based policies; they are a type of organization policy that sets a permission guardrail. They do not grant any permissions by themselves. Instead, they define a boundary within which IAM policies and other permission mechanisms can operate. The effective permission for any principal in a member account is the intersection of the permissions allowed by the SCP and those granted by IAM policies. If a service or action is not explicitly allowed by an SCP, it is implicitly denied, unless the SCP uses a deny effect.

SCPs operate at two main levels: the root of the organization (the top-level container) and individual organizational units (OUs) or accounts. They can be attached to the organization root, to OUs, or directly to member accounts. The policy evaluation follows the hierarchy: SCPs attached at the root affect all accounts, SCPs attached to an OU affect all accounts under that OU, and SCPs attached to an account affect only that account. When multiple SCPs apply, the effective permission is the logical intersection of all allow statements across all SCPs that apply to the account. If any SCP denies an action, that action is denied regardless of allowances. This is similar to the AWS IAM policy evaluation logic, but with an important difference: SCPs do not have an explicit deny override from IAM policies; a deny in an SCP always wins.

SCPs use a syntax similar to IAM policies, including Effect (Allow or Deny), Action (list of AWS service actions), Resource (usually '*' for SCPs), and Condition (optional context keys). However, SCPs have some limitations: they cannot grant permissions, they cannot specify a Principal element because they apply to all principals in the affected accounts, and they cannot use resource-based policies. The Resource element in an SCP is typically set to '*' because the policy applies to all resources in the account. This is because SCPs are about controlling actions, not specific resource access.

When a request is made to an AWS service, the authorization system first evaluates all applicable SCPs. If any SCP denies the action, the request is denied immediately. If no SCP denies the action, the system then evaluates IAM policies, bucket policies, and other permission mechanisms. So SCPs act as an outer filter. This architecture allows central governance teams to enforce compliance requirements without needing to modify every IAM policy in every account. For example, a healthcare organization might use an SCP to block all actions on DynamoDB tables that are not tagged with a specific compliance tag, using the Condition element. Another common use is to restrict access to AWS regions, which is done by denying actions unless the region is in an allowed list.

SCPs are defined in the management account of the organization but affect all member accounts. They can also be used in an organization that has enabled all features. The default SCP behavior is to allow all actions, meaning that if no SCP is attached, the implicit permission boundary is unlimited. Once an SCP is attached, it can restrict permissions. There is also a special type called a FullAWSAccess SCP that explicitly allows all actions. By default, when you enable SCPs, a FullAWSAccess SCP is attached to the root, OUs, and accounts to maintain existing access. If you want to implement a deny-by-default model, you can remove or modify that policy.

In practice, organizations often use a combination of allow lists and deny lists. An allow-list SCP specifies only the services or actions that are permitted, and everything else is implicitly denied. A deny-list SCP specifies actions to block, while allowing everything else. The choice depends on the security posture. Allow lists are more restrictive but harder to maintain as new services are introduced. Deny lists are more permissive but can miss new threats. Many organizations use both: a broad allow list for basic services and specific deny statements for high-risk actions.

SCPs integrate with AWS CloudTrail for logging and AWS Config for compliance monitoring. They are also a key part of the AWS Well-Architected Framework, specifically the Security Pillar, for implementing permission boundaries and centralized governance. SCPs are not available in organizations that use consolidated billing features only; they require the full set of organization features.

SCPs cannot affect the management account itself. The management account has full administrative privileges and is not subject to SCPs, by design. Similarly, service-linked roles and some AWS internal roles are also exempt from SCPs. This ensures that critical AWS services can still operate even if an SCP incorrectly blocks them. Also, SCPs do not apply to the root user of an account, although the root user is still subject to any resource-based policies or IAM boundary policies. However, root user actions can be blocked by SCPs if the SCP applies to the account.

SCPs are an essential tool for multi-account governance, especially for enterprises that must comply with regulations like HIPAA, PCI DSS, or SOC 2. They provide a scalable way to enforce security baselines across hundreds of accounts without requiring changes to each account's IAM setup. They also help prevent accidental privilege escalation by limiting the maximum possible permissions that an account administrator can delegate to users or roles. For example, if an SCP denies the ability to create IAM users, then even an account admin with full IAM permissions cannot create new IAM users. This layer of control is critical for maintaining a strong security posture in large AWS environments.

Service Control Policies matter because they provide a centralized, scalable way to enforce security and compliance across a large number of AWS accounts. Without SCPs, an organization would have to rely entirely on each account administrator to correctly configure IAM policies, which is error-prone and time-consuming. SCPs act as a safety net, ensuring that even if a local administrator makes a mistake or tries to circumvent security, the damage is limited. This is especially important in enterprises that must meet strict regulatory requirements, such as financial services or healthcare, where accidental data exposure or resource deletion can have severe consequences.

In practical IT work, SCPs are used to implement least privilege at the organizational level. For example, an SCP can block the use of root user credentials, enforce the use of multi-factor authentication, restrict access to specific AWS regions for data residency, or prevent the deletion of CloudTrail logs. These controls are vital for maintaining an audit trail and securing sensitive data. SCPs also help with cost management by blocking the launch of expensive instance types in non-production accounts.

For professionals managing multi-account environments, SCPs reduce the overhead of manually auditing each account. Instead of checking hundreds of IAM policies, you can set a few SCPs at the root level and know that certain dangerous actions are never possible. This efficiency is why SCPs are a core component of the AWS landing zone architecture. They are also essential for implementing the principle of boundary enforcement in zero-trust architectures.

From an exam perspective, understanding SCPs is critical for several AWS certifications, as well as security-focused certifications like CISSP and CompTIA Security+. Questions often test the difference between SCPs and IAM policies, how SCPs affect permissions, and what actions they can block. Knowing the hierarchy of policy evaluation and the exceptions (management account, service-linked roles) is key to answering scenario-based questions correctly.

Service Control Policy questions typically appear in one of several patterns. The first pattern is the definition question: "Which AWS service or feature allows you to centrally control permissions across multiple accounts?" The answer is AWS Organizations with SCPs. Another variation asks: "What is the purpose of a Service Control Policy?" and the correct answer is to set permission guardrails, not to grant permissions.

Scenario-based questions are common. Example: A company has multiple AWS accounts for different business units. The security team wants to ensure that no one in any account can delete the Amazon S3 buckets that contain audit logs. Which solution meets this requirement with minimal operational overhead? The answer is to create an SCP that denies the s3:DeleteBucket action for all accounts. Another scenario: A developer in a member account has full AdministratorAccess IAM policy. However, the developer is unable to launch an EC2 instance of a specific instance type. The question asks for the most likely cause. The correct answer is that an SCP attached to the account or OU denies that action.

Another pattern tests the effect of multiple SCPs. For example: An OU has an SCP that allows only EC2 and S3 services. An account in that OU also has an SCP that denies the s3:DeleteBucket action. What actions are allowed on the EC2 service? The allowed actions are those EC2 actions that are not explicitly denied by any SCP, and within the scope of the allow list. Since allow lists block everything not listed, the effective permission is the intersection: EC2 actions are allowed, but only those not denied by other SCPs. This is a more complex question that requires understanding set theory.

Troubleshooting-style questions ask: An IAM user is unable to perform an action that is explicitly allowed in their IAM policy. What could be the reason? Options include SCP deny, resource-based policy deny, or permission boundary. The correct answer is likely an SCP if the organization uses AWS Organizations.

There are also questions about exceptions: Which entities are not affected by SCPs? The management account, service-linked roles, and some AWS internal roles are exempt. Also, SCPs do not affect the root user of an account if the SCP is configured incorrectly, but generally root user is subject to SCPs, except for some account recovery actions. However, the root user can be blocked by an SCP that denies specific actions.

Finally, questions can ask about the difference between allow-list and deny-list SCPs. For example: Which SCP strategy is more restrictive and requires regular updates as new services are added? The answer is an allow-list SCP because it only permits explicitly listed services, so new services are automatically blocked until added.

Knowing these patterns helps you identify what a question is testing and recall the relevant facts quickly.

In practice, Service Control Policies are one of the most powerful tools for an AWS administrator who manages a multi-account environment. They are not something you set once and forget; they require careful planning, regular review, and monitoring. The first step is to understand your organization's security and compliance requirements. For example, if you are subject to data sovereignty laws, you must ensure that no resources are created in restricted regions. An SCP can enforce that by using a condition key like aws:RequestedRegion. The policy might look like: Deny all actions on EC2, S3, and other services unless the region is in an allowed list. This is more effective than relying on each account admin to remember the rule.

Another practical use is to protect audit trails. You can create an SCP that denies the ability to stop, delete, or modify CloudTrail trails, S3 bucket policies for log buckets, and IAM roles used by CloudTrail. This ensures that logs are tamper-proof. Similarly, you can block the ability to disable AWS Config, which is crucial for compliance monitoring.

One of the most common mistakes in practical implementation is overly restrictive policies. For instance, a deny-all SCP that mistakenly blocks required AWS support services can break the organization. Always test SCPs on a test OU first, using a set of test accounts, before applying to production accounts. AWS provides a feature to simulate SCPs using the AWS Policy Simulator, which can help you see the effects before deployment.

What can go wrong? The most common issue is that an SCP becomes too permissive or too restrictive due to misconfiguration. For example, an SCP that denies all EC2 actions except a specific list requires that list to include every EC2 API you need, including ec2:DescribeInstances, which is needed for the console to work. If you miss that, the EC2 console will be broken for all users. Another issue is the interaction with other policies: if you have a permission boundary and an SCP, the effective permission is the intersection of both, which might be more restrictive than intended.

Professionals should also know that SCPs can be used to block the root user of an account from performing certain actions. For example, you can deny the root user from deleting the account or changing support plans. However, you cannot block the root user from performing actions that are necessary for account recovery, like changing the password? Actually, you can block most root actions, but AWS recommends caution because if you lock yourself out, you might need to contact AWS support.

Another important practice is to version control your SCP documents. Since they are JSON files, you can store them in a code repository and use infrastructure-as-code tools like AWS CloudFormation or Terraform to deploy them. This makes updates auditable and reproducible.

Finally, monitor for SCP-related errors. CloudTrail events with an error code of "AccessDenied" that reference a policy type of "SCP" indicate that an SCP blocked an action. You can set up CloudWatch alarms on these events to detect potential issues or security incidents early. This is especially important when you first deploy an SCP, as it may affect legitimate workflows that you hadn't considered.

A Service Control Policy (SCP) is a policy-based access control mechanism used in AWS Organizations to centrally manage permissions across multiple accounts. SCPs are not identity-based or resource-based policies; instead, they act as a boundary or guardrail that defines the maximum permissions for all IAM users, roles, and service-linked roles in an AWS account or organizational unit (OU). When you attach an SCP to an account or OU, it restricts the actions that principals in those accounts can perform, even if an IAM policy explicitly grants those actions. This is a critical feature for security and compliance because it ensures that no entity in a child account can escalate privileges beyond the defined boundary.

SCPs are written in JSON format and follow the AWS IAM policy language. They can allow or deny specific AWS service actions, resources, and conditions. By default, AWS attaches a FullAWSAccess SCP to every root, OU, and account, which grants all permissions. When you create custom SCPs, you can either use an allow list (deny-by-default) or a deny list (allow-by-default). In a deny list, you explicitly deny specific actions while allowing everything else. In an allow list, you explicitly allow only specified actions and deny everything implicitly. The allow list is more restrictive and is often required for environments with strict compliance requirements, such as SOC 2, HIPAA, or PCI DSS.

Exam relevance: The AWS Certified Cloud Practitioner, AWS Certified Solutions Architect – Associate (SAA), and AWS SysOps Administrator – Associate exams test your understanding of SCPs as a governance tool. The CISSP, CySA+, and Security+ exams focus on the principle of least privilege and centralized policy enforcement, which SCPs directly support. The Microsoft exams (MD-102, MS-102, AZ-104, SC-900) do not cover SCPs directly, but the concept of policy-based access control in Azure (Azure Policy) is analogous, and understanding SCPs helps with cross-cloud comparisons. Key concepts include the difference between SCPs and IAM policies, the inheritance model, and the effect of SCPs on service-linked roles.

An allow list strategy in Service Control Policies (SCPs) is a restrictive approach where you explicitly permit only specific AWS service actions, while implicitly denying all others. This is implemented by creating an SCP that contains an Allow effect for a set of actions, but you must also include a Deny effect for all other actions to enforce the boundary. In practice, you create an SCP with a statement that denies all actions except those you specifically allow. For example, you might allow only Amazon EC2, Amazon S3, and AWS IAM actions for development accounts, while blocking all other services. This ensures that developers cannot accidentally or maliciously use services that are out of scope, such as creating Redshift clusters or accessing sensitive databases like Amazon RDS.

To implement an allow list, you attach the SCP to an organizational unit (OU) or individual account. The policy must include an explicit Deny for all actions, but then you use a NotAction element to exclude the allowed services. Alternatively, you can use multiple statements: one to allow the specific actions and another to deny all remaining actions. The Allow statement does not grant permissions by itself; it only marks those actions as allowed within the SCP boundary. The actual permissions still require an IAM policy or resource-based policy to be effective. The SCP simply ensures that if an IAM policy tries to grant an action not in the allow list, the SCP will block it.

Best practices include starting with a deny list for most environments because it is less likely to break existing workloads. Allow lists are best for high-security environments, such as those handling classified data or financial transactions. You should also use multiple SCPs at different levels of the organization hierarchy: a root-level SCP for global restrictions (like disabling all resources in certain regions) and OU-level SCPs for environment-specific controls (like allowing EC2 only for development OUs). This layered approach reduces complexity and improves manageability. The AWS exams often ask about the trade-offs between allow lists and deny lists, and how SCPs interact with IAM permission boundaries. For instance, an IAM permission boundary and an SCP have similar effects, but SCPs apply to all principals in the account, while permission boundaries apply only to individual roles or users.

Service Control Policies (SCPs) are a powerful tool for controlling cloud costs in AWS Organizations, but they do not directly manage billing. Instead, SCPs prevent users from creating or modifying resources that could incur unexpected costs. For example, you can create an SCP that denies the ec2:RunInstances action for specific instance types, such as expensive GPU instances like p3.16xlarge. This ensures that developers cannot accidentally provision high-cost resources, keeping the AWS bill predictable. Similarly, you can deny actions like rds:CreateDBInstance for database engines that are costly, or block the creation of resources in expensive regions like Asia Pacific (Tokyo) when you want to enforce usage only in cheaper regions like US East (N. Virginia).

To implement cost controls, you must use condition keys in SCPs. The global condition key aws:RequestedRegion allows you to restrict which regions resources can be created in. The condition key ec2:InstanceType allows you to filter specific EC2 instance types. You can also use resource-level conditions, such as rds:DatabaseEngine to restrict database engine types. For example, to block all EC2 instances of type t2.micro except in specific accounts, you would create a Deny statement with the ec2:InstanceType condition. You can use the aws:ResourceTag condition key to require that resources have cost allocation tags, such as a CostCenter tag. Without proper tags, the action is denied, helping you track costs across accounts.

Cost governance with SCPs also includes preventing the modification of billing settings. SCPs can deny actions like aws-portal:ModifyAccount or aws-portal:ModifyBilling, which prevents IAM users from changing payment methods or turning off billing alerts. This is critical for large organizations where centralized finance teams manage the master payer account. However, SCPs cannot control actions that affect the management account itself; they only apply to member accounts. Also, SCPs cannot prevent actions that have already incurred costs, such as running EC2 instances started before the policy was applied. You need to combine SCPs with AWS Budgets and AWS Cost Explorer for full visibility. The AWS exams frequently test the use of condition keys in SCPs for cost control, especially in the Solutions Architect and SysOps exams. Understanding how to write JSON with conditions is essential.

Service Control Policies (SCPs) follow a specific evaluation logic that is essential for exam success. The key rule is that SCPs are not evaluated globally across the organization; instead, they are applied at each level of the organization hierarchy (root, OU, and account). The final effective permissions for an account are the intersection of all SCPs attached to the account itself, all OUs it belongs to, and the root. In other words, the most restrictive policy wins. This is because SCPs are evaluated using a deny-by-default approach for explicit denies, but allow-by-default only if all SCPs in the hierarchy allow the action. If one SCP allows an action and another SCP denies it, the deny overrides the allow. This is different from IAM policies, where an explicit allow overrides a default deny, but an explicit deny overrides any allow. In SCPs, an explicit deny always wins.

The inheritance model is straightforward: SCPs attached to a parent OU propagate to all child OUs and accounts. However, if you attach a new SCP directly to an account, that SCP does not propagate upwards to OUs or the root. You can also create multiple SCPs at the same level, and they are evaluated together. For example, if a root-level SCP denies ec2:RunInstances, and an OU-level SCP allows ec2:RunInstances, the result is a deny because the explicit deny from the root-level SCP overrides the allow. To allow the action, you must either remove the root-level deny or attach an allow statement that does not conflict. Importantly, SCPs do not grant permissions; they only set boundaries. The actual permissions come from IAM policies. So, even if an SCP allows an action, the user must still have an appropriate IAM policy to perform that action.

The evaluation logic also includes service-linked roles. Service-linked roles (SLRs) are special roles created by AWS services that have their own trust policies. SCPs can affect SLRs only if the SCP explicitly denies the actions that the SLR performs. For most SLRs, the default FullAWSAccess SCP allows all actions, so blocking specific actions may break the service. Therefore, when creating restrictive SCPs, you must be careful not to deny actions required by AWS services like Amazon Inspector or AWS Config. The exam scenarios often present a scenario where an admin attaches a restrictive SCP and then a service fails to work properly, testing the understanding of SLR and SCP interaction. Another common exam question involves the use of the SCP effect to block root user actions (like changing account settings) by denying the action aws-portal:ModifyAccount, but note that root user itself in the master account cannot be blocked by SCPs because SCPs do not apply to the management account.