Policy as code works best before cloud changes ship

AWS argues for policy as code before cloud changes ship#

AWS Security Blog has published a practical model for governing infrastructure as code with pattern-based policy as code. The core point is simple: many cloud control failures are visible before deployment, but only if teams check proposed infrastructure changes consistently inside the delivery workflow.

The examples are familiar. A workload lands in an AWS Region that was not approved for that class of data. A security group allows broader access than intended. Required tags are missing. Encryption is assumed but not actually configured. None of these are exotic failure modes. They are routine governance gaps that grow when many teams can provision infrastructure directly.

Manual review can catch some of this. It does not scale well across many repositories, environments, and delivery teams. AWS’s post argues for a preventive layer: convert control expectations into automated checks that run before infrastructure is deployed.

The article focuses on Open Policy Agent, or OPA, evaluating Terraform plan JSON in a CI/CD workflow. It does not present OPA as a full replacement for AWS governance services. That distinction matters. The model is layered: OPA checks proposed changes before deployment, while AWS Organizations, Control Tower, AWS Config, Security Hub, and service-level protections continue to matter after resources exist.

The useful shift: organize by control pattern, not by service#

The strongest part of the AWS guidance is the policy organization model. Teams often build policy as code one AWS service at a time. That can work at first. It becomes harder to review as the library grows.

The problem is not only file count. Similar control requirements start appearing in different forms across teams and repositories. One team expresses a tagging rule one way. Another handles a related requirement somewhere else. Over time, the policy library stops matching how governance, risk, compliance, security, and engineering teams talk about controls.

AWS recommends organizing checks around recurring control intent. The post gives several practical patterns:

• required metadata, such as ownership, support, cost allocation, or automation tags
• allowed configuration, such as approved AWS Regions or deployment boundaries
• exposure restriction, such as preventing public ingress or internet-facing resources in the wrong environment
• protection enforcement, such as encryption, logging, or deletion protection
• privilege constraint, especially for IAM definitions and access patterns that need tighter validation

This is a cleaner abstraction. It lets a team ask, “Do we enforce required metadata?” instead of hunting through dozens of service-specific rules. It also makes the policy library easier to explain during audit review.

The tradeoff is that patterns still need precise implementation. A category name like “baseline” or “networking” does not enforce anything by itself. The value comes from mapping specific infrastructure properties to specific policy decisions, then keeping those checks versioned and reviewable.

Where OPA fits in the delivery workflow#

AWS places OPA in the automated quality gate layer of CI/CD. A typical flow looks like this:

1. A developer submits a pull request or merge request.
2. The pipeline runs early checks, such as formatting, syntax validation, and dependency checks.
3. Terraform generates a plan.
4. The plan is converted to JSON.
5. OPA evaluates the plan JSON against a shared policy library.
6. The pipeline publishes a validation report as an artifact.
7. Additional automated checks run as needed.
8. Approvers use the validation artifact for higher-risk environments.
9. Runtime monitoring continues after deployment through AWS-native governance services.

The separation between quality gates and approval gates is important. A manual approver should not be the first person to discover that a required tag is missing, a disallowed Region is selected, or an internet-facing path exists in the wrong environment.

Automated gates are better suited for deterministic checks. Approval gates are better suited for risk acceptance, context, and release decisions. OPA’s output can inform an approval, but it should not be treated as a decorative report that someone reads only after the real decision has already been made.

Validation artifacts are part of the control story#

One practical detail in the AWS post deserves attention: retain validation artifacts.

In many organizations, policy as code is framed only as a deployment blocker. That is useful, but incomplete. If the pipeline produces a clear report showing what was checked, what passed, what failed, and which policy version was used, that report can support both release decisions and later audit review.

This reduces the gap between engineering workflow and compliance evidence. Instead of reconstructing intent after the fact, teams can show that controls were evaluated during the normal delivery process.

That does not make audits automatic. It does make the evidence trail more concrete. It also helps teams debug policy changes. If a deployment was blocked, the artifact should explain why in terms that both engineering and governance teams can understand.

What this model does not solve#

AWS is careful to scope the post to the pre-deployment layer. That limit should be preserved.

Policy checks against Terraform plan JSON can catch many proposed misconfigurations before they ship. They do not prove that runtime state will remain compliant forever. They also do not replace organizational guardrails, detective controls, drift detection, remediation workflows, or service-level enforcement.

There are several reasons for this.

First, infrastructure can drift after deployment. A resource might be changed manually, by another automation path, or by an exception process. Pre-deployment validation will not see those changes unless they return through the same workflow.

Second, not every effective control is visible in the same way in a plan file. Some controls depend on organization-level settings, runtime behavior, or relationships outside the submitted change.

Third, policy logic can be wrong. A policy library is code. It needs review, tests, ownership, and change control. Pattern-based organization helps manage that work, but it does not remove it.

The right conclusion is not “OPA solves cloud governance.” The better conclusion is that OPA can provide an early, repeatable control checkpoint when infrastructure changes are still cheap to fix.

Practical takeaways for cloud teams#

For teams already using infrastructure as code, the AWS model suggests a few useful checks.

Start by looking at repeated review comments. If reviewers keep flagging missing tags, broad security group rules, unapproved Regions, disabled logging, or weak IAM patterns, those are candidates for policy as code.

Then group rules by control intent. A policy library organized only by AWS service may be harder to govern over time. A pattern-based layout can make coverage easier to reason about across teams.

Keep the pipeline role clear. OPA should run before deployment as an automated gate. Its result should be available to approvers, but human review should not be the first line of detection for routine control failures.

Retain the report. A validation artifact has operational value during release and evidence value later. That only works if the report is understandable and tied to the policy version that produced it.

Finally, keep runtime governance in place. Pre-deployment checks are strongest when they are part of a layered model: organizational guardrails, continuous monitoring, drift detection, and resource-level protections still matter.

AWS’s post is not a new vulnerability story. It is more useful than that for many teams. It describes a way to make cloud governance less dependent on memory, manual review, and inconsistent local habits. The main lesson is narrow but important: check the infrastructure change while it is still a proposal, and organize those checks around the controls the organization actually needs to enforce.