Cloud-Native Guardrails

Cloud-Native Guardrails

Policy as Code at the Kubernetes layer (OPA, Kyverno) handles workload-level decisions. But the guardrails that govern your entire cloud account — what regions are allowed, which services can be provisioned, what encryption must be applied — live one layer higher, inside the cloud control plane itself. In AWS, three overlapping mechanisms enforce this layer: Service Control Policies (SCPs), AWS Config rules, and Conformance Packs. Understanding when to use each, and how they fail, is the difference between a compliance posture that holds under pressure and one that breaks the first time an engineer works around it.

Service Control Policies: the Outer Fence

SCPs are IAM policy documents attached to AWS Organizations accounts or Organizational Units (OUs). Unlike IAM policies — which grant permissions — SCPs define the maximum permission boundary. Even an account's root user cannot do what an SCP denies. This is the property that makes SCPs uniquely powerful: they apply to every principal in the account without exception.

Key design principles for SCPs at production scale:

• Deny-by-default is the correct mental model. AWS Organizations ships with a built-in FullAWSAccess policy that allows everything. Your SCPs layer additional explicit denies on top of it. SCPs act as an allow-filter on what IAM can grant, not as grants themselves.
• SCPs do not grant permissions. A principal still needs an IAM policy that allows the action. SCP + IAM allow = effective permission. SCP deny (or no SCP allow within a FullAWSAccess + deny model) = blocked, regardless of IAM.
• Exemptions require a condition, not a separate policy. Rather than creating two SCPs — one that denies for most and one that allows for an exception — use ArnNotLike or StringNotEquals conditions to exempt specific roles inline. This keeps the policy surface minimal and auditable.
• Test in a sandbox OU first. A broken SCP that denies sts:AssumeRole in a production account will lock out all cross-account automation. You cannot fix it from inside the account — only an Organizations administrator can remove the SCP.

A second common SCP enforces that all S3 buckets must have encryption and block public access. This is not redundant with AWS Config — Config detects after the fact, whereas an SCP prevents provisioning in the first place:

AWS Config Rules: Detective Controls at Scale

Where SCPs are preventive — they block before anything happens — AWS Config rules are detective. Config records the configuration state of every supported AWS resource and evaluates it against rules you define. When a resource drifts out of compliance, Config marks it NON_COMPLIANT and can trigger automated remediation via an SSM Automation document or a Lambda function.

Config rules come in two forms:

• AWS-managed rules: pre-built rules for the most common compliance checks. encrypted-volumes, rds-storage-encrypted, s3-bucket-ssl-requests-only, iam-password-policy, mfa-enabled-for-iam-console-access — over 200 rules available. Use these before writing custom rules; they are maintained by AWS and updated when services change.
• Custom rules: Lambda functions you write and deploy that receive a configuration snapshot and return a compliance verdict. Use these when a control is specific to your architecture — e.g., enforcing that every RDS cluster must have a specific tag set for cost allocation, or that ECS task definitions must not run as root.

Deploying a Config rule via Terraform — the correct way to manage Config at scale:

Conformance Packs: Mapping Rules to Frameworks

A Conformance Pack is a YAML template that bundles a set of Config rules — and optionally their remediation actions — into a single deployable unit mapped to a compliance framework. AWS ships pre-built packs for CIS AWS Foundations Benchmark, PCI DSS, HIPAA, NIST 800-53, and SOC 2. You deploy them to individual accounts or across an entire Organization via the AWS Config console, CLI, or Terraform.

The primary value of conformance packs is audit evidence. Instead of manually running Config rule queries and assembling a spreadsheet, you can point an auditor at the Conformance Pack dashboard: a single page showing per-rule compliance percentage, the list of non-compliant resources, and the timestamps of all evaluations. This turns a week of audit prep into a URL.

For custom packs — when you need to map your specific internal policies to a named framework — author the YAML template directly:

Layering the Three Mechanisms

At a well-run organization, these three tools are not alternatives — they form a layered defense where each handles the cases the others cannot:

• SCPs enforce the absolute boundaries of what the account can do. Region restrictions, root account lockdown, disabling services that have no legitimate use in your workloads (e.g., deny lightsail:* in an account that only runs ECS). SCPs cannot evaluate resource attributes — they act on the API call, not on the resulting resource state.
• Config rules evaluate resource configuration continuously. They catch drift that SCPs cannot — for example, a bucket that existed before the encryption SCP was applied, or a tag that was removed after provisioning. Config rules are the primary mechanism for ongoing drift detection.
• Conformance Packs aggregate Config rule results into framework-mapped reports. They do not add new enforcement; they add audit-ready visibility and a governance layer that names the framework each rule satisfies.