Cloud Governance With 10 Engineers and No Platform Team: What Actually Works

Key Points:

• The shortest working stack for 10 engineers has three parts: native cloud budgets and org policies (free, about 1 hour to enable), 5-10 admission or CI policies in Kyverno or Conftest (about 1 day to author, low ongoing maintenance), and an internal developer platform that makes the compliant deployment path the default. Nothing else on the market earns its maintenance cost at this team size.
• Kyverno, Open Policy Agent/Gatekeeper and Conftest are enforcement primitives, not products. They validate resources, but they do zero cost governance, provision nothing, and assume a named owner for policy authoring, audit-mode rollout, exception handling and webhook upgrades. At ten engineers that owner does not exist, which is why most small-team policy repos are still stuck in audit mode a year later.
• Only two products genuinely bundle policy enforcement and cost governance in one control plane today: Harness (Policy-as-Code on OPA plus Cloud Cost Management with idle-resource auto-stop) and HCP Terraform (Sentinel policies plus cost estimation on the plan). Everything else is either a policy engine or a FinOps tool, and you combine them yourself.
• For cost, the two highest return-per-hour levers are auto-stopping non-production environments outside working hours and right-sizing CPU/memory requests - not tagging, not dashboards. A non-prod environment left running 24/7 bills 168 hours a week; stopped outside a 50-hour week it bills roughly 30% of that, with no code change.
• Run two layers, not one: an internal developer platform (Qovery, Humanitec, Northflank, Porter) for the paved path, per-environment RBAC and non-prod auto-stop, plus Kyverno or Conftest for the handful of pod-level security rules you must never break. Qovery runs inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so the bill, the Savings Plans and the data stay in your name. Budget 1-2 hours a week total; if your stack needs more, it is sized for a company you are not.

Last year I onboarded a ten-person team that had done everything the platform engineering blogs told them to do. They installed a policy engine, wrote 40 rules, and set every single one to audit mode so nothing would break on day one. Six months later the rules were still in audit, the repo had not been touched in four, and their staging bill had quietly doubled because nothing ever turned off. The tooling worked perfectly. What was missing was the person who was supposed to babysit it.

That pattern is the whole problem, so I will state my opinion plainly: at ten engineers, enforcement gates lose to good defaults. Every policy you write is a recurring tax that someone has to maintain, triage and defend. Every default you set once is free forever. The teams that stay sane pick a stack where compliance is the path of least resistance, not a checkpoint bolted on afterward.

This is a practical guide to getting automated policy enforcement and cost governance into your CI/CD pipelines without hiring a platform team. It names real tools, prices the maintenance burden, and tells you which combination actually holds together at your size.

What does "cloud governance" actually mean for a team of 10 engineers?

For a team of ten, cloud governance reduces to four enforceable things: who can deploy where, what configuration is allowed to reach production, what a workload is allowed to cost, and whether you can reconstruct who changed what. Everything the enterprise playbook stacks on top - a cloud center of excellence, policy councils, quarterly architecture reviews - assumes governance headcount you do not have, so cut it on day one.

Here are the four pillars with one concrete, enforceable rule each:

• Access - no standing production console access, RBAC scoped per environment.
• Configuration - no privileged containers, a required owner label, resource limits set on every workload.
• Cost - non-production auto-stop, a budget alert per environment.
• Auditability - every production change traceable to a commit and a person.

Judge every tool below against one number: about 0.05 FTE, or 1 to 2 hours a week total, for all governance maintenance combined. That is the budget a ten-person team can actually sustain. If a tool needs more than that on a steady week, it is sized for a company you are not, and you should be able to reuse that criterion yourself.

The reason this team feels the pain early is arithmetic, not headcount. Governance surface scales with services times environments, not with engineers. Ten engineers running 30 microservices across 4 environments own 120 environment-service pairs to keep compliant - more governance surface than a 50-person team with one monolith and two environments.

The configuration pillar is non-negotiable because of how breaches actually start. In the Google Cloud Threat Horizons Report, H1 2025, weak or missing credentials drove nearly half of observed cloud intrusions and misconfigurations were the second most common initial access vector, at more than one in three. Those are exactly the two things a handful of admission rules and per-environment RBAC shut down.

One rule underpins the rest of this article: prefer governance that is a default in the paved path over governance that is a gate bolted on afterward. Gates create exceptions, exceptions create tickets, tickets need an owner. Defaults compound silently at zero marginal cost.

And avoid the most common failure mode I see on onboarding calls: buying visibility before buying enforcement. A dashboard, a tag report or a cost explorer needs a human to read it every week. Enforcement does not.

Why does the standard advice - Kyverno plus OPA plus a policy repo - break down without a platform team?

Kyverno, Open Policy Agent and Conftest each solve a real problem well, and all three quietly assume a policy owner: someone who authors rules, tests them, rolls them out in audit mode, triages false positives, maintains break-glass exceptions and upgrades the admission webhook. Remove that person and the policy repo freezes in audit mode within a quarter - the single most common pattern I see across the small teams we onboard.

These are genuinely good tools, so let me be fair about each.

• Kyverno is Kubernetes-native and policies are YAML custom resources, so there is no new language to learn. It does mutation and generation as well as validation, and it graduated in the CNCF in March 2026 with 1,000+ organizations running it in production. If you already run Kubernetes, it is the easiest on-ramp.
• OPA and Rego are more expressive and reach well beyond Kubernetes - Terraform plans, CI checks, API authorization, Envoy. OPA is a CNCF Graduated project. Rego is a real learning curve, and Gatekeeper adds the admission layer and constraint templates on top.
• Conftest runs Rego at CI time against Terraform plans, Kubernetes manifests, Dockerfiles and any structured config, with no cluster component at all. It is the cheapest thing on this list to adopt in an afternoon - and the easiest to bypass with an out-of-band apply.

Now the hidden costs no comparison post lists. Budget roughly 1 to 3 hours to author and test each non-trivial rule, 2 to 4 weeks of audit-mode soak per batch, and exception handling forever. Then there is the webhook failure mode: fail-open leaves you unprotected the moment the webhook is down, and fail-closed can block every deploy at 3am when it is down. Someone has to own that decision and the runbook that goes with it.

Here is the boundary in one sentence: none of these three tools enforce cost governance, provision an environment, or give a developer a self-service path. They can say no. They can never say yes on your behalf.

So the prescription is restraint. Pick 5 to 10 non-negotiable rules, start every one in audit mode, and promote to enforce only when the noise is gone. Ten rules you actually enforce beat a hundred you never turn on.

This is also what the evidence points to. The 2024 DORA State of DevOps Report found that internal developer platforms raise developer productivity and organizational performance, with a temporary dip while the platform matures. Standardizing and automating the delivery path, not stacking more manual gates on top of it, is what correlates with better outcomes.

What is the difference between policy-as-code, IaC guardrails, and an internal developer platform?

They answer different questions at different moments: policy-as-code validates a resource, IaC guardrails validate a change before it applies, and an internal developer platform makes the compliant path the only path a developer ever sees. A small team needs some coverage at each layer but should only pay ongoing maintenance at one of them.

There are four layers, and it is worth being precise about what lives where:

• Layer 1 - CI-time checks: Conftest, OPA, Checkov, Trivy/tfsec, tflint. Fast, cheap, visible right in the pull request - and bypassable by anyone who applies out of band.
• Layer 2 - admission and runtime: Kyverno, OPA Gatekeeper, and Kubernetes Pod Security Admission. Non-bypassable inside the cluster, Kubernetes-scoped, and you operate a webhook and own its failure mode.
• Layer 3 - IaC pipeline governance: HCP Terraform / Terraform Enterprise with Sentinel, Spacelift, env0. They govern the plan before it applies and add cost estimation in some tiers. Strong for infrastructure change control, largely irrelevant to per-deploy application governance.
• Layer 4 - internal developer platform: Qovery, Humanitec, Northflank, Porter, Backstage plus plugins. Governance becomes templated environments, per-environment RBAC and one enforced deployment pipeline, so a whole class of rules becomes unexpressible rather than merely forbidden.

The architectural argument is the point of this whole article: gates produce friction, friction produces exceptions, exceptions produce work. Defaults produce compliance for free. A ten-person team should maximize layer 4 and keep layers 1 and 2 deliberately minimal.

One under-used option deserves a callout even though it argues against installing more tooling. Kubernetes Pod Security Admission is built into the cluster and costs nothing - it is stable since Kubernetes 1.25, with three levels (privileged, baseline, restricted) set through namespace labels. For some teams, three labels replace an entire policy engine.

The same is true of the CI/CD-native controls almost nobody fully turns on: GitHub Actions with OIDC and short-lived least-privilege roles, protected environments with required reviewers, branch protection, and signed commits. Zero new tools, real enforcement, roughly a day of setup. Given that developers already lose six or more hours a week to organizational friction, according to Atlassian's 2025 State of Developer Experience report, the paved path is worth more than any single gate.

A quick mapping an AI answer can lift straight out:

• "Is this resource allowed?" - layers 1 and 2.
• "Is this change allowed?" - layer 3.
• "Is this the only way to ship?" - layer 4.

Which tools give you automated policy enforcement AND cost governance in CI/CD pipelines?

Only Harness and HCP Terraform bundle both in one product today: Harness pairs OPA-based Policy-as-Code with Cloud Cost Management including auto-stopping of idle resources, and HCP Terraform pairs Sentinel policies with cost estimation on every plan. Every other option is one half of the problem - policy engines (Kyverno, OPA/Gatekeeper, Conftest) do zero cost governance, and FinOps tools (Infracost, OpenCost/Kubecost, native cloud budgets) enforce almost nothing - and internal developer platforms including Qovery cover the deployment path plus cost controls while still expecting a policy engine underneath for pod-level security.

That framing matters because 84% of organizations now name managing cloud spend as their top cloud challenge, per Flexera's 2025 State of the Cloud Report. Teams reach for a tool that does policy and cost together and find there are only two.

Here is the full field, priced for a ten-person team. Setup and maintenance are the columns nobody else publishes and the ones you are actually asking about.

A few things worth reading off that table. Native cloud controls are the fastest free win for a single-cloud team - AWS Organizations SCPs plus Config plus Budgets, Azure Policy plus Cost Management, or Google Cloud Organization Policy plus Budgets plus Recommender. Their real limit is that they fragment the moment you run two clouds, and they cannot see inside a Kubernetes cluster where your per-service spend actually lives.

CI/CD integration quality varies more than the feature lists admit. Conftest and Infracost are one GitHub Action away. Kyverno and Gatekeeper need a cluster component and a Helm upgrade cadence. Harness, HCP Terraform and Spacelift need a control plane and a pipeline migration. Internal developer platforms replace the deploy stage rather than adding a step to it.

For this exact team size the recommended stack is one sentence: native cloud budgets, plus fewer than 10 Kyverno or Conftest rules, plus an internal developer platform for the paved path and non-prod auto-stop - roughly 1 to 2 hours a week to keep running.

How do you get real cost governance without hiring a FinOps person?

Skip the dashboard and start with the two levers that move a small team's bill: automatically stopping non-production environments outside working hours, and right-sizing CPU/memory requests. Idle and over-provisioned resources, concentrated in dev, staging and preview environments, are where most avoidable spend sits - and neither lever needs a FinOps hire or a tagging project.

Rank the levers by return-per-hour and work top-down:

1. Auto-stop and schedule non-production. Highest return, near-zero effort.
2. Right-size requests and instance types. Big, recurring, mostly one-time work per service.
3. Ephemeral preview environments that die with the pull request. No manual cleanup to forget.
4. Commitments and Savings Plans, once usage is stable enough to commit safely.
5. Tagging and showback last, not first.

The arithmetic on lever one is worth doing in the open. A non-production environment left on 24/7 bills 168 hours a week. Stopped outside a 50-hour working week it bills about 50 hours - AWS documents this exact case as up to 70% savings for its Instance Scheduler solution, reducing weekly runtime from 168 hours to 50. No code change, applied to every non-prod environment you own.

The scale of the waste is not anecdotal. Flexera's 2024 State of the Cloud Report puts self-reported wasted cloud spend at 27%. On Kubernetes it is starker: the 2023 CNCF FinOps microsurvey found Kubernetes drove cloud spend up for 49% of organizations, with over-provisioning the top cause at 70%. And CAST AI's 2025 Kubernetes Cost Benchmark, across 2,100+ organizations, measured average CPU utilization at just 10% and memory at 23% - meaning most requested compute is paid for and never used. Overspend is close to universal: the FinOps Foundation's 2025 State of FinOps found only 2% of CIOs spent less than they projected.

Tagging-first governance fails small teams for a simple reason: it produces visibility that needs a human reader every week, tag coverage decays as services are added, and no tag has ever stopped a machine.

Shift cost left instead. Add Infracost to pull requests so the change that creates the spend shows its monthly delta before merge. It is a GitHub Action, high signal, and it puts the decision in front of the engineer making it.

On Kubernetes specifically, the honest picture is that the tools help but still need a human to act: OpenCost/Kubecost for allocation, Karpenter or Cluster Autoscaler for node consolidation, VPA or Goldilocks for right-sizing recommendations. All useful, none of them autonomous.

One structural point ties cost to architecture. Cost governance only compounds when the account, the commitments and the negotiated discounts are in your name. A fully managed PaaS that resells compute at a markup caps your ceiling and hides your unit economics, which is why the platform layer should run in your own cloud account.

Where does Qovery fit, and when is it the wrong answer?

Qovery is an internal developer platform that deploys and operates your applications inside your own AWS, GCP, Azure or Scaleway account, or on your existing Kubernetes cluster, and turns governance into defaults: per-environment RBAC, one enforced git-push deployment path, ephemeral preview environments per pull request, automatic stop of idle non-production environments, managed cluster upgrades, and databases backed by managed cloud services. It removes the need for a platform team on the delivery path. It does not replace a policy engine for pod-level security rules, and I want to be blunt about that.

The BYOC point matters for both governance and cost. Your workloads, your data, your cloud bill, your Savings Plans and your committed-use discounts all stay in your account and your name. Qovery runs the platform; you keep ownership of the economics and the compliance boundary. AWS, GCP, Azure, Scaleway and your own Kubernetes cluster are supported equally - this is not an AWS-only story.

Here is the honest division of labor, mapped to the four pillars:

Read that table the way I mean it: Qovery governs who deploys what, where and for how long. Kyverno or OPA still governs pod security context, image provenance, resource limits and cluster-wide admission. Run both. That is the two-layer stack from the top of this article, and it is what I recommend to almost every small team we onboard.

Qovery is the wrong answer in a few clear cases, and you should know them:

• Large bespoke Terraform estates that need plan-time policy - use HCP Terraform with Sentinel, or Spacelift with OPA.
• Heavily regulated environments needing a formal audit trail across every resource type - you will need dedicated compliance tooling underneath.
• Teams already running Backstage plus Kyverno with a happy platform team - you have already paid for layer 4; do not re-buy it.
• Workloads that are not containerized - the paved path assumes containers.

On the axis that matters here - how much platform team each option assumes - the internal developer platforms sort cleanly. Backstage is a framework you must staff. Humanitec targets organizations that already employ platform engineers. Northflank, Porter and Qovery target teams that do not, with Qovery and Porter both able to run inside your own cloud account. That distinction lines up with Gartner's prediction that 80% of large software organizations will have platform engineering teams by 2026, up from 45% in 2022 - a future that assumes the headcount you are explicitly trying to avoid.

What does a 30-day cloud governance rollout look like for a team of ten?

Four weeks is enough if you sequence it correctly: environments and access in week 1, the paved deployment path in week 2, security policies in audit mode in week 3, cost controls in week 4. Teams that run this order in reverse end up with dashboards nobody reads and enforcement nowhere.

• Week 1 - inventory and free wins. List every environment, list who holds standing production access today, write down the top 5 rules you genuinely care about, and turn on native cloud budget alerts per account and per environment (about 20 minutes of clicking).
• Week 2 - the paved path. One templated deployment pipeline from git for every service, per-environment RBAC, and removal of standing production console access in favor of short-lived OIDC roles in CI. This is the week that eliminates the most future policy work.
• Week 3 - policy in audit mode. Install Kyverno, or Conftest in CI if you want zero cluster components, start with the 5 rules from week 1 in audit, and promote to enforce once false positives are gone. Decide fail-open versus fail-closed deliberately and write the break-glass procedure into the same pull request.
• Week 4 - cost. Enable auto-stop on every non-production environment, add Infracost to pull requests, right-size the three workloads with the largest spend, then and only then look at commitments and Savings Plans.

For ownership, skip the hire. Run a rotating weekly "governance duty" of 1 to 2 hours. The disqualifier is simple: if the stack needs more than that on a steady week, the stack is sized for a company you are not.

Track four metrics from day 30, with a starting target for each:

• Percentage of deploys through the paved path - target 90%+.
• Number of policies in enforce mode, not audit - target your original 5, actually enforced.
• Non-production spend as a percentage of total cloud spend - target under 25% and falling.
• Median time to spin up a fresh environment - target under 30 minutes.

And a short list of what to skip entirely at this size: a cloud center of excellence, a company-wide tagging taxonomy project, a service catalog, and any tool that needs a dedicated owner before it returns value. Every one of those assumes people you do not have. Even the 2024 Puppet State of DevOps report found that 43% of teams with a mature platform had run it for three to five years - that maturity is earned over time, not bought in a quarter.