AWS Cloud Operations Blog

Enforcing enterprise-wide preventive controls with AWS Organizations

When managing multiple AWS accounts in AWS Organizations organization, it’s important to implement central access controls that govern both identities and resources. These controls are essential for ensuring security, compliance, and scalability across your environment. AWS Organizations service control policies (SCPs), resource control policies (RCPs), and declarative policies enable you to centrally configure and manage preventive controls for your member accounts.

In this blog, we’ll explore the distinctions between SCPs, RCPs, and declarative policies, provide concrete use cases, and guide you through choosing the right policy type to secure your AWS Organization. Additionally, we’ll share best practices for enforcing these policies, ensuring that they are applied effectively, tested properly, and scaled across your organization. If you’re interested in a deeper dive into these concepts, we recommend reviewing the AWS Organizations policies page.

What are SCPs, RCPs, and declarative policies?

Service control policies (SCPs)

Service control policies (SCPs) are authorization policies managed in AWS Organizations that offer central control over the maximum available permissions for the IAM principals in your organization. SCPs help you to ensure your accounts stay within your organization’s access control guidelines.

  • Use case: Use SCPs to restrict your IAM principals’ access to services and resources, or the conditions under which your IAM principals can make requests (For example, from specific networks).

Resource control policies (RCPs)

Resource control policies (RCPs) are authorization policies managed in AWS Organizations that behave similarly to service control policies (SCPs). While SCPs apply to principals across your organization’s member accounts, RCPs apply to resources across your organization’s member accounts.

  • Use case: Use RCPs to restrict who can access your resources, and enforce requirements on how your resources can be accessed. (For example, only trusted external accounts can access specific Amazon S3 buckets).
  • Supported AWS services: For the list of services supported by RCPs, visit list of AWS services that support RCPs. If you need to enforce a control on resources currently not supported by RCPs, you will need to implement a service specific resource-based policy. You can use AWS Config Rules and AWS Lambda functions to monitor and automate the enforcement of specific policies on those resource types.

Declarative policies

Declarative policies are a type of management policies in AWS Organizations, that you can use to enforce your desired configuration for AWS services at scale.

  • Use case: With declarative policy, you can ensure the configuration is always maintained across member accounts, even when the service introduces new features or APIs. For example, you can enforce the block public access setting on the EC2 Amazon Machine Images (AMIs).
  • Supported AWS services and attributes: For the list of services and attributes supported by declarative policies, visit supported AWS services and attributes. For services and attributes not supported by declarative policies, you can consider using AWS Organizations SCPs or RCPs to deny configurational changes on the resources.

Choosing the right policy: when to use SCPs, RCPs, and declarative policies

The table below summarizes key differences between SCPs, RCPs, and declarative policies followed by specific examples to help clarify their applications:

Policy Type Governs Usage Considerations
Service control policy (SCP) IAM principals (within your organization) Restrict the permissions of IAM principals in member accounts of your organization. SCPs don’t affect IAM principals from accounts outside your organization. SCPs affect requests to resources that live in accounts outside of your organization.
Resource control policy (RCP) AWS resources (within your organization) Control access to resources within your organization by IAM principals external to your organization. RCPs affect IAM principals from all accounts, even those outside of your organization. RCPs don’t affect requests to resources that live in accounts outside of your organization.
Declarative policy Service configuration Ensure consistent and compliant configurations for AWS services across your organization.

When to use each policy type:

  • Enforcing configuration settings (Declarative Policy): If there’s a declarative policy available for the control you want to implement, we recommend you use the declarative policy. You can enforce configurations like ensuring that resources in a VPC or subnet cannot access the internet through Internet Gateways (IGWs), or that EC2 AMIs are not shared publicly, using declarative policies. Declarative policies automatically enforce and maintain your configuration across member accounts, regardless of future changes in AWS service APIs.
  • Restricting your IAM principal permissions (SCP): If you need to restrict your organization’s IAM principals from accessing certain resources or actions—such as preventing access to resources that don’t belong to your organization you would use an SCP. SCPs allow you to enforce organization-wide rules, ensuring that IAM principals (across all member accounts) are only able to perform allowed actions.
  • Controlling access to your resources (RCP): If you need to define who and how external IAM principals can access your resources, use RCPs. For example, you can restrict principals that don’t belong to your organization from accessing your S3 buckets, ensuring that only trusted accounts in your organization can interact with sensitive resources.

Note:

  • SCPs and RCPs are permissions guardrails and are not sufficient by themselves in granting permissions to the principals and resources in your organization. The administrator must still attach identity-based policies to IAM principals or resource-based policies to the resources in your accounts to actually grant permissions. The effective permissions are the logical intersection between the SCP/RCP and an identity policy or the SCP/RCP and a resource policy.
  • SCPs and RCPs affect only member accounts in the organization. SCPs do not affect IAM principals that live in your organization’s management account. RCPs do not affect resources that live in your organization’s management account. Thus, if you want to restrict an IAM principal in your management account, you would utilize an identity-based policy directly attached to the principal. To restrict who can access a resource and what actions are allowed on it, you would utilize a resource-based policy directly on the resource in the management account.
  • Before developing SCPs, RCPs and Declarative policies, consider reviewing AWS Control Tower built-in managed controls that help enforce governance and compliance across your organization automatically.

Best practices for enforcing SCPs, RCPs, and declarative policies

Readiness assessments

Service control policies: To understand the usage of AWS services by principals within your organization, you can review the AWS Organizations Service Last Accessed Information. Additionally, AWS CloudTrail can provide detailed logs of API calls made within your organization, offering a more granular view of actions performed by principals. This information shows which principals (e.g., root users, IAM users, or roles) in an organization or account last attempted to access a specific service and when.

Resource control policies: Before implementing RCPs, in addition to reviewing AWS CloudTrail logs, assessing IAM Access Analyzer external access findings can help understand which resources are currently public or shared externally.

Declarative policies: You can use the account status report to assess the current status of all attributes supported by declarative policies for the accounts in scope. You can choose the accounts and organizational units (OUs) to include in the report scope, or choose an entire organization by selecting the root.

Understand the quota limits

Before developing SCPs, RCPs or declarative policies, you should have a good understanding of service limits and quotas. This is important so you can start with a design that allows for future flexibility and scalability. You have the flexibility to attach multiple policies to the root of the organization, to an organization unit (OU), or to an account. For example, in an organization that has the root, one OU, and one account, attaching five SCPs to each of them would result in a total of 15 SCPs (5x SCPs at the root, 5x SCPs at the OU, and 5x SCPs on an account). Note that declarative policies support up to 10 policies at each level (root, OU, or account).

Note: For the latest information on quotas, refer to the AWS Organizations quotas documentation.

If you are running against policy size quota, we recommend you to consider strategies outlined in get more out of service control policies in a multi-account environment for guidelines on authoring compact SCPs. If you’d like to learn more about the best practices that will assist you in writing SCPs, refer to the achieving operational excellence with design considerations for AWS Organizations SCPs and best practices for AWS organizations service control policies in a multi-account environment.

Enforce data perimeters

SCPs and RCPs are independent controls that can be used separately or together. However, they are most effective when combined. For example: you can use both SCPs and RCPs to create a data perimeter around your identities and your resources. Following four data perimeter objectives out of a total of six, can be achieved by utilizing SCPs in combination with RCPs.

With SCPs, you can restrict which resources your identities can access and set conditions on how they can interact with them.

With RCPs, you can limit who can access your resources, and enforce requirements on how your resources can accessed.

For more policy examples demonstrating how to implement a data perimeter on AWS, visit data perimeter policy examples repository.

Start small and then scale

You should not attach SCPs, RCPs, and declarative policies without thoroughly testing the impact that the policy has on accounts. Once you have a policy ready that you would like to implement, we recommend testing in a separate organization or OU that can be represent your production environment. Once tested, you should deploy changes to more specific OUs and then slowly deploy the changes to broader and broader OUs over time. This staged approach can help minimizes risk, ensures proper validation, and enable teams to confidently roll out policies in production environments while avoiding unintended disruptions.

Automate policy validation and deployment

Defining and provisioning policies via Infrastructure as Code (IaC) can simplify infrastructure management, quickly add multiple policies concurrently, easily control and track changes to accounts, OUs, and policies and improve transparency and accountability for the review process. You can create SCPs, RCPs and declarative policies using AWS CloudFormation. You can choose to add a step in the deployment pipeline to validate the policies against AWS IAM access analyzer for policy grammar and best practices and remove white spaces.

For the declarative policies, you can ensure that the change you made had the intended impact on the effective policy. You can view the effective policy by using the AWS Management Console, or by using the DescribeEffectivePolicy API operation or one of its AWS CLI or AWS SDK variants.

Conclusion

In summary, SCPs enable you to set up access controls by defining the maximum available permissions for IAM principals across accounts in your organization, while RCPs enable you to setup resources centric controls by defining the maximum permissions that can be granted to resources in your organization’s member accounts. Declarative policies, on the other hand, allow you to enforce specific configurations for AWS services across your organization, ensuring compliance with organizational standards. It’s important to note that RCPs and declarative policy supports only a subset of AWS services as of writing this blog.

SCPs, RCPs, and declarative policies are essential tools for enforcing security and compliance requirements at scale. When used together, they form a comprehensive strategy for managing access, resources, and configurations across your AWS organization. You can start applying them using the AWS Organizations console, CLI, or API. AWS Organizations supports AWS CloudFormation as well, so you can manage your organization’s resources using infrastructure as code (iaC) and make changes in a central place. This can help reduce the time required to apply and update policies across multiple accounts and OUs.

Related resources:

About the Author

Swara Gandhi

Swara Gandhi is a Senior Solutions Architect on the AWS Identity Solutions team. She works on building secure and scalable end-to-end identity solutions. She is passionate about everything identity, security, and cloud.