What does a provider-native cloud control cost you compared with the same rule in your own policy engine?

## The trade, stated plainly A provider-native control buys **coverage and unbypassability**: it is evaluated inside the cloud's own control-plane API, so every caller hits it and there is nothing of yours to remove. Everything below is what you hand over for that. ### 1. No verdict on a change before the change exists An engine of yours can read a *proposed* change — a rendered plan, a diff in review — and answer "this would be denied" before any API call is made. A native control decides on the **actual request**. Some provider APIs offer a dry-run flag, but that still needs real credentials and a fully resolved request, which is not the same as judging a design in review. The consequence is a feedback loop that ends at apply time, in a pipeline, in front of whoever happened to press deploy. ### 2. The denial message is not yours to write This is the most-underrated cost. When your engine denies, you control the string: *"instances may not have a public IP; private connectivity is via the shared egress path; the exception process is here."* When the provider denies, the developer sees a generic authorization failure. It typically does not say which guardrail fired, who owns it, why the rule exists, or how to ask for an exception. That gap is where support tickets, cargo-culted workarounds and "security is why we cannot ship" come from. ### 3. The policy language belongs to the provider You write in whatever expression form the provider exposes, with its own condition keys, operators and evaluation semantics. If the rule you need sits above that ceiling — *deny a public IP unless the resource carries an ownership tag that matches an entry in our service registry* — you cannot extend the language, add a data source, or implement a helper. You either simplify the rule to fit or move it back into your own engine. You also inherit the provider's semantics for absence: an attribute that is simply not present in a request often does not match a condition at all, which is not the same as matching false, and rules written without thinking about that quietly fail to fire. ### 4. Nothing ports A rule in your engine is one artifact you can point at more than one kind of input. A native control is provider-specific by construction. A second provider means a second implementation, in a second language, with different attribute names and different semantics — and now two rules that are supposed to say the same thing, maintained by people who must be fluent in both. ### 5. You cannot test it the way you test code A rule in your engine is a unit under test: fixtures in, verdicts out, run in CI on every change, with regression cases for every past incident. Native controls rarely come with a local evaluator you can run over sample inputs. "Testing" tends to mean attaching the control to a sandbox scope and making real calls, which is slow, needs real credentials, and is hard to run on every pull request. The practical result is that native controls get changed less often and reviewed more nervously. ### 6. And two smaller ones - **Rollout modes are whatever the provider gives you.** If you want to run a rule in a record-only mode first to see what it would have blocked, you get that only if the provider offers it. You cannot build the staged rollout you would have designed. - **The control's lifecycle may sit outside your repository.** Unless you deliberately manage it as code, the current state of the guardrail lives in a provider console rather than in a reviewed, versioned change. ## The counter-column, so the answer is honest Say the other side too, or the answer sounds like an argument against native controls rather than an analysis. The native control evaluates the **fully resolved request** — after defaults, after whatever the module or the console filled in — which is often more accurate than reading a plan where values may still be undecided. It covers callers your engine will never see. It cannot be skipped under deadline pressure. And it requires no availability engineering from you: there is no endpoint whose downtime becomes either an outage or an open door. ## How this gets asked Usually as "we already have a native control for this — why would you also build it in the engine?" or "we have engine rules — why bother with native at all?". Both want the same list. Lead with the two properties native buys, then walk the five costs, then say which cost bites hardest in the environment being described: in a fast-moving product team it is the message and the late feedback; in a company about to acquire something running on another provider it is portability.