How do you implement infrastructure compliance at scale with AWS Config and SCPs?

Infrastructure compliance at scale requires a layered defense model: preventive controls stop non-compliant actions before they occur, detective controls identify drift after the fact, and corrective controls automatically remediate violations. Think of it like a highway system: SCPs are the physical guardrails that prevent cars from leaving the road, Config rules are the speed cameras that detect violations, and remediation actions are the automated toll systems that fix issues without human intervention.

Service Control Policies (SCPs) are the most powerful preventive control in AWS because they set the maximum permissions boundary for an entire account. SCPs do not grant permissions; they restrict what IAM policies can grant. This is a critical distinction: if an SCP denies ec2:RunInstances in a region, no IAM policy in that account can override it, not even the root user. SCPs apply to all principals in member accounts (except the management account itself, which is why you should never run workloads in the management account).

SCP design follows a deny-list or allow-list strategy. Deny-list is more common: start with the default FullAWSAccess SCP, then add explicit denies for non-compliant actions. For example, deny launching EC2 instances without IMDSv2 (Instance Metadata Service version 2), deny creating S3 buckets without encryption, or deny using regions outside your approved list. Allow-list is stricter: remove the default FullAWSAccess and explicitly allow only the services and actions needed. Allow-list is recommended for regulated industries (healthcare, finance) but requires significant upfront planning.

SCPs are attached to Organizational Units (OUs), not individual accounts. Structure your OUs to reflect compliance boundaries: a Production OU with the strictest SCPs (no delete operations on databases, mandatory encryption, restricted regions), a Development OU with relaxed SCPs (allow experimentation but deny production resource access), and a Sandbox OU with minimal restrictions but a spending cap via AWS Budgets actions.

AWS Config continuously records resource configurations and evaluates them against rules. Config rules come in two types: AWS-managed rules (160+ pre-built rules like s3-bucket-ssl-requests-only, encrypted-volumes, iam-root-access-key-check) and custom rules (Lambda functions that evaluate arbitrary compliance logic). For custom rules, use Config Rule Development Kit (RDK) to scaffold and test Lambda-based rules locally before deployment.

Conformance packs bundle multiple Config rules into compliance frameworks. AWS provides operational best practices packs for PCI DSS 3.2.1 (35 rules), HIPAA (55 rules), CIS AWS Foundations Benchmark (49 rules), and NIST 800-53 (100+ rules). Deploy conformance packs via AWS Organizations to roll them out across all accounts simultaneously. Each rule evaluates every relevant resource in every account, producing a compliance score per account and per rule.

Remediation actions are the corrective control layer. When a Config rule finds a non-compliant resource, it can trigger an SSM Automation document to fix the issue. For example, if s3-bucket-server-side-encryption-enabled finds an unencrypted bucket, the remediation action runs the AWS-EnableS3BucketEncryption document to apply AES-256 encryption. Use manual remediation (requires human approval via SNS) for production resources and automatic remediation for development accounts.

Config Aggregator collects compliance data from all accounts and regions into a single delegated administrator account. This gives your compliance team a centralized dashboard without granting them access to individual workload accounts. The aggregator supports both AWS Organizations-based collection (automatic for all member accounts) and individual account authorization.

Production gotchas: SCPs have a 5,120 character limit per policy, which you hit quickly with complex deny statements; use condition keys like aws:RequestedRegion with StringNotEquals instead of listing individual region denies. Config rules evaluate asynchronously, so there is a delay between resource creation and compliance evaluation (typically 1-10 minutes). Config recording charges $0.003 per configuration item recorded; in accounts with frequent Auto Scaling events, this adds up. Limit Config recording to the specific resource types you need to evaluate. SCP changes take effect immediately but can take up to 24 hours to propagate to all API endpoints globally; always test SCP changes in a sandbox OU first. Never attach a restrictive SCP to the management account OU; SCPs do not apply to the management account, creating a false sense of security.