SCPs vs AWS Config
Service control policies and AWS Config are often presented as alternatives. They are not: one is preventive and one is detective, and a governance design needs both.
Service control policies
Section titled “Service control policies”- Part of AWS Organizations
- Preventive: the action fails at the API, before anything is created
- Set the maximum available permissions — a guardrail — for the accounts they apply to
- Cannot grant permissions, only restrict them
- Take precedence over IAM: an action allowed by an IAM policy but denied by an SCP is denied
- Typical uses: preventing an account from leaving the organisation, blocking Regions the organisation does not operate in, denying deletion of log archives, restricting which services may be used
Two limits matter and are frequently missed:
- SCPs do not apply to the management account. They apply only to member accounts — which means they do apply to a member account designated as a delegated administrator.
- SCPs do not apply to service-linked roles.
Since November 2024, resource control policies (RCPs) cover the other half: an SCP bounds what the principals in an account may do, an RCP bounds what may be done to the resources in an account, including by principals outside the organisation.
AWS Config
Section titled “AWS Config”- Detective: evaluates resources after they exist
- Assesses configuration against managed rules, custom rules and conformance packs
- Maintains a full history of configuration changes and the relationships between resources
- Identifies the specific non-compliant resources, not just the fact of non-compliance
- Can trigger automatic remediation through AWS Systems Manager Automation
- Typical uses: proving compliance, tracking who changed what and when, enforcing tagging, finding unencrypted volumes and public buckets
The distinctions
Section titled “The distinctions”| Service control policies | AWS Config | |
|---|---|---|
| Timing | Before the action | After the resource exists |
| Scope | Permissions, at organisation or OU level | Resource configuration, at account and Region level |
| Purpose | Access control and governance | Compliance assessment and change tracking |
| Failure mode | The API call is denied | A finding is raised |
| Flexibility | Rigid by design — a policy either denies or does not | Custom rules and remediation actions |
| Blind spots | Management account, service-linked roles | Anything that happened before Config was recording |
Using them together
Section titled “Using them together”Prevent what can be prevented and detect the rest. Some things cannot be expressed as a permission — “every EBS volume must be encrypted” is a property of the resource, not of the API call, and belongs in Config. Others should never be reachable at all — “no account may leave the organisation” — and belong in an SCP.
AWS Control Tower packages both: its preventive controls are implemented as SCPs, its detective controls as AWS Config rules, and its proactive controls as CloudFormation hooks that check a resource before it is provisioned.