AWS CloudFormation Guard: Policy Evaluation for Structured Infrastructure Data

Guard's Policy Boundary for Cloud Configuration

AWS CloudFormation Guard addresses a specific form of validation: deciding whether structured JSON or YAML satisfies declarative policy rules. It is intended for developers, infrastructure teams, governance engineers, and organizations that want policy checks to become machine-enforceable inputs to development and delivery workflows.

The documented use cases extend beyond CloudFormation templates. Guard can evaluate CloudFormation ChangeSets, Terraform JSON configuration files and plans, Terraform state files, Kubernetes configurations, AWS Config configuration items, and data associated with AWS Security Hub. This breadth comes from applying one DSL to common structured data rather than by providing a separate policy model for every domain.

Guard is useful when a rule expresses an organizational requirement, such as requiring versioning for Amazon S3 buckets or preventing unsafe replacement operations in a CloudFormation ChangeSet. It is also used to inspect deployed resources represented as configuration data, which places it on the detective side of governance rather than limiting it to source templates.

The important boundary is explicit in the project documentation: Guard is not a general-purpose programming language. Its loops, conditional execution, variable assignments, filters, and joins support policy evaluation, but the tool should not be treated as a replacement for an application language or a full infrastructure provisioning engine.

Clause Evaluation Inside Guard's Rust Workspace

Guard policies are built around clauses, which are assertions that evaluate to `true` or `false`. A clause can compare values with binary operators such as `==`, `>`, and `in`, or inspect one value with unary operators including `exists`, `empty`, and `is_list`. This makes a policy readable as a condition rather than requiring it to be represented as procedural control flow.

The following rule checks the `Type` value against the CloudFormation resource type for an S3 bucket:

Type == /AWS::S3::Bucket/

The language supports primitive values including strings, 64-bit integers, 64-bit floats, booleans, characters, and regular expressions. It also represents maps and arrays. A range expression such as `r(10, 200)` expresses a bounded value, while nested maps and arrays allow policies to address structured configuration rather than only top-level fields.

For policies that need more than a single assertion, the documented DSL includes loops, filtered queries, cross-query joins, single-shot variable assignments, conditional execution, and composable rules. Built-in functions add stateful rule capabilities. Version 3.0 also added shell command completion, advanced regular expressions, improved intrinsic-function handling for the `test` command, and a `--structured` option for the `validate` command that can emit JSON or YAML parseable output.

Repository layout shows a Cargo workspace containing the main `guard` crate, `guard-lambda`, `guard-ffi`, and a library example. The Lambda and FFI packages indicate deployment integrations beyond the basic CLI, while the Dockerfile builds a native binary for the `x86_64-unknown-linux-musl` target and places it in an Alpine execution image. This is a compiled Rust tool with packaging around the CLI, not a shell-only policy script.

Getting cfn-guard and Authoring the First Policy

The README points users to the GitHub releases page for Guard 2.x migration artifacts, but its installation section does not show a complete platform-specific installation command or confirm the command name and options needed for a fresh 3.x setup. The repository does contain `install-guard.sh` and `install-guard.ps1`, but no invocation instructions for those scripts appear in the README, so an exact installation command cannot be stated reliably here.

The repository also provides a Dockerfile. Its build stage installs `musl-tools` and `musl-dev`, adds the Rust target, and builds the release binary. The execution image then contains the resulting `cfn-guard` executable:

FROM rust:latest AS builder
RUN apt update && apt install -y musl-tools musl-dev
RUN rustup target add x86_64-unknown-linux-musl
RUN cargo build --target x86_64-unknown-linux-musl --release

After obtaining a documented release or building the repository, a first policy can begin with the clause shown below. Save it as a Guard rule file and combine it with a JSON or YAML input through the CLI's validation workflow. The README confirms `validate` and `test` as Guard commands, but it does not provide their complete syntax.

Type == /AWS::S3::Bucket/

The repository's container entry point exposes the help command as the default smoke check:

CMD [ "./cfn-guard", "--help" ]

That check confirms that the executable starts and can display its command help. It does not verify a policy against a real document. A first operational check should therefore include one controlled input and one expected failing input after selecting the exact command form documented by the installed release.

Choosing JSON or YAML Inputs for Guard Evaluation

Guard's common value model allows a policy to be reused across domains, but the input format still matters. CloudFormation templates are commonly YAML or JSON, Kubernetes configurations are structured YAML or JSON, and Terraform support is explicitly limited in the documentation to JSON configuration files, plans, and state files. A Terraform plan in another format is outside the supported examples given here.

The `--structured` flag added for the `validate` command is relevant when another system needs to consume results rather than only display them. JSON or YAML output can be parsed by CI reporting tools or policy pipelines, whereas ordinary command output may be intended for a person reading a terminal. The README does not specify the complete output schema, so consumers should inspect the release-specific examples before depending on field names.

Guard 3.0 corrected intrinsic-function handling for the `test` command. The README warns that previously written tests may need review because behavior changed. This is a concrete upgrade concern for teams whose rules or test fixtures depend on CloudFormation expressions. A version upgrade should therefore be treated as a policy review, not only as a binary replacement.

The tool evaluates documents, not deployment intent in full. It can identify that a ChangeSet contains a replacement operation, or that a template violates a rule, but the README does not claim that Guard performs the deployment or resolves every deployment-time behavior.

Compatibility Limits Between Guard 1.0 and Guard 3.x

The largest documented compatibility boundary is between Guard 1.0 and Guard 2.0 or later. The README states that Guard 2.0 was a complete rewrite and is backward incompatible with Guard 1.0 rules. Existing policies may therefore require migration before they can be loaded or interpreted by a current release.

The documented migration path starts by obtaining release artifacts from the GitHub releases page, running the `migrate` command, and then reviewing new Guard features before modifying rules further. That path is specific to the old grammar. It does not mean that a policy can be moved between every future release without review. The intrinsic-function warning in Guard 3.0 gives a second reason to compare old test cases against the behavior of the target release.

Guard's intended user is not limited to Rust developers. The DSL is described as human-readable and usable by non-technical people as well as developers. Adoption still requires agreement about document structure, rule ownership, failure handling, and version compatibility. Those are governance concerns outside the parser itself, and the repository does not document a compatibility matrix beyond the stated 1.0 boundary and 3.0 behavior warning.

The tool is also not a general solution for every kind of compliance control. It can evaluate rules against data that a caller supplies, but the documentation does not describe automatic collection of every cloud resource, a hosted policy service, or a complete remediation engine. The organization remains responsible for producing suitable input and acting on failed evaluations.

Guard 3.2.1 Packaging and Maintenance Boundaries

The repository is not archived, and its last push was on 2026-09-14. Recent releases listed for the project include `v3.2.1` on 2026-08-25, `v3.2.0` on 2026-03-02, and `v3.1.2` on 2024-11-25. This supports treating the repository as receiving project changes, while release-specific compatibility still needs verification before an upgrade.

The project is licensed under Apache-2.0. That is the repository's stated license, and organizations should review the license text and their own compliance obligations when distributing binaries, containers, or derived integrations. This article does not provide legal advice.

Packaging creates a separate operational surface. The main Dockerfile uses `rust:latest` for the build stage and `alpine` for execution. It builds `cfn-guard` for `x86_64-unknown-linux-musl`, so the resulting image is tied to that target unless it is changed. The workspace also includes `guard-lambda`, `guard-ffi`, and a Makefile target for building a Lambda bootstrap artifact. The Makefile comments explicitly note that installing Rust during every build is not ideal, but the shown target still installs it through `rustup` when invoked.

A team adopting Guard must therefore account for binary distribution, container base-image changes, policy migration, and CI integration. The project provides pieces for those tasks, but the README does not provide a complete upgrade procedure for Lambda artifacts, FFI consumers, or Docker image publishing.

Editorial conclusion

Guard is appropriate for teams that already control the structure of JSON or YAML inputs and can commit to maintaining a dedicated policy DSL. It is a poor fit for arbitrary application logic or existing Guard 1.0 rules that have not been migrated. Before adoption, verify that the documented `validate`, `test`, and `migrate` commands in the selected release can read your actual documents, including CloudFormation intrinsic functions, and review the expected failure output in your CI pipeline.

Frequently asked questions

Official sources

1. aws-cloudformation/cloudformation-guard on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases