Skip to content

Capability 04 · Governance

Policy as Code

Declarative policies, stored in Git and evaluated against your live inventory and ownership model, with findings routed to the team that owns the resource.

? Answers: Is it allowed to exist in its current state?

Free local tool
A small set of built-in policies: missing owner, untagged resources and common orphans.
Cloud Sleuth Cloud
Custom policies stored in Git, with routing to owning teams, exceptions and optional remediation.
Roadmap
Phase 1: built-in ownership policies · Phase 3: custom policy as code with Git and routing, Slack/Jira/ITSM integrations

Policy tools are good at enforcing configuration, but they are disconnected from business ownership. A finding that says “this volume is unattached” is only useful if it reaches someone who knows whether it matters and has the authority to act. Sent to a shared channel or a central backlog instead, it becomes one more alert nobody owns.

Cloud Sleuth’s policy as code evaluates declarative policies continuously against the inventory and the ownership model, so every finding already knows whose it is.

How it works

  • Simple policies in Git. Policies are written in a simple YAML or Rego-style language and stored in Git, alongside the rest of your code.
  • Ownership, hygiene and business rules. Detect missing ownership, untagged or poorly tagged resources, orphans, idle resources, non-compliant configurations, and your own custom business rules.
  • Routing to the owning team. In Cloud Sleuth Cloud, findings are routed automatically to the team that owns the resource, through Slack, Jira, email or in-product.
  • Exceptions with expiry. Exception and suppression workflows come with expiry and audit, so an intentional choice, such as a resource sized for disaster recovery, does not raise the same finding forever and does not stay suppressed forever either.
  • Optional remediation. Remediation actions are optional, and safe, reversible ones are the default.
  • Shift-left and live. Policies are evaluated against infrastructure as code where possible, plus continuously against the live estate.

Illustrative example - syntax not final. A policy that flags unattached volumes and routes each finding to the resource’s owning team:

policy: unattached-volumes
description: Unattached volumes need a decision from their owner
resource: aws.ebs.volume
when:
  attached: false
route_to: owner
exceptions:
  require_expiry: true

Why it matters

Orphaned and ambiguously owned resources accumulate because there is no reliable system of record for ownership and purpose, and nothing that checks continuously. Policy as code turns “is this allowed to exist in its current state?” into a rule that runs against the live estate, and the ownership model turns each finding into a task for a specific team.

Routing findings by ownership reduces noise and makes them actionable. That is the difference between reporting on waste and actually reducing it, and it matters most in mid-market teams, where one person or a small platform group often owns cloud cost for everyone.

Free local tool vs. Cloud Sleuth Cloud

The free local tool includes a small set of built-in policies for your AWS accounts and Azure subscriptions: missing owner, untagged resources and common orphans. It does not support custom policies, routing or integrations. Cloud Sleuth Cloud is planned to add custom policies with Git integration, routing to owning teams, exceptions and optional remediation, along with Slack, Jira and ITSM integrations.

Both are pre-launch. Get early access to hear first when they are ready.