Airframe

Why Airframe

FinOps built in

A product's monthly budget is written once, in its catalog entry, and every other budget follows it: the check that holds a merge, the cost dashboard's thresholds and the Google Cloud budgets on the product's billed projects. A scheduled plan reports drift, so a change made outside a merge request to anything a Terraform root manages shows up as an issue.

One budget, used everywhere

  1. One number in the catalog

    The catalog entry carries monthly_budget, in US dollars, production and non-production together. The cost rules read it from the entry, the Grafana root sets the cost dashboard's thresholds from it, and the project factory splits it 70 to 30 into a Google Cloud budget on each billed project, alerting at 80 and 100 percent.

  2. The merge request knows the cost

    At each approval the executor plans every root of the product, prices each plan with Infracost and posts one note per root, with that root's monthly cost against the budget and what is left out. The gate adds the roots' monthly costs and sets the merge request's Airframe cost check: it fails when the total or any one root is above the budget, or when a root could not be priced, and GitLab keeps the merge closed. The check's reason, which the executor prints in its job log, gives the total and each root's share. The refusal says to raise the budget in the catalog.

  3. The cost dashboard shows it

    A daily job reads the billing export and pushes each product's cost as metrics. Each product's Grafana folder has a cost dashboard: month to date and the forecast against the budget, orange at 80 percent and red at 100. The Grafana root creates it, with its thresholds from monthly_budget, when the product's catalog entry is merged.

  4. Drift is reported, not hidden

    On a repository's daily schedule, the drift job plans every root without applying it. When a plan is not empty, the platform opens an issue for that root listing the resources and their actions, never their values, rewrites it while the drift lasts, and closes it when the root converges again.

Try it

Set a product's budget and a planned change. The verdict and the message are the policy pack's cost check, with its thresholds at the platform release this site describes.

Denied
  • Denied cost.budget

    the product's projected monthly cost, USD 45, is above its budget of USD 40 in the catalog: raise the budget by a catalog merge request approved by the domain's leads before this change can merge

    A change that takes the product's projected monthly cost above the budget in its catalog entry is refused: the budget is raised by a catalog merge request that a domain lead approves, or the change gets smaller.

  • Warning cost.delta

    the change adds USD 25 a month (USD 20 to USD 45), above USD 10: platform approval

  • Warning cost.delta

    the change adds 125 percent a month (USD 20 to USD 45), above 25 percent: platform approval

    A change that adds more than USD 10 or 25 percent a month is designed to need the platform's approval; today the policy pack warns in the merge request and holds nothing back. From a cost of nothing there is no percentage, so only the amount is judged.

Merge: blocked until a catalog merge request raises the budget

What makes it true

A change over the budget cannot merge.
The gate sets each product merge request's Airframe cost status check from the executor's priced plans of every root at its head: failed when the roots' total or any root is above the entry's monthly_budget, or when a root has no price. The domain's render job sets the product project's rule that status checks must succeed. A plan on main stops on a recorded refusal too, so nothing refused is applied. Previews and usage-based resources are outside the figure.
Raising a budget takes a domain lead.
The gate's ownership rule requires a domain lead's approval of a catalog change that raises monthly_budget; where the domain's leads have no GitLab account, as in the demo, the platform team stands in.
Every product has a cost dashboard against its budget.
operations' Grafana root, which runs when the catalog changes, creates a cost dashboard in each catalog product's folder: month to date and the forecast against the entry's monthly_budget, orange at 80 percent and red at 100. The cost figures come from the billing export through the daily cost:report job.
Drift is reported.
The tf-apply component's drift job plans each root on the repository's daily schedule, and the drift-report component, as the audit identity, keeps one issue labeled audit::drift per drifting root, rewrites it and closes it when the plan is empty again.
The Google Cloud budgets follow the same number.
The domain's project factory creates a budget on each billed product project from monthly_budget, 70 percent for production and 30 for non-production, with alerts at 80 and 100 percent; the demo organization's folder and the billing account have budgets of their own. No demo product is billed today, so none has its project budgets yet.