FinOps: Automating Cloud Cost Optimization

Cloud bills do not spike because engineers are careless — they spike because cost is an emergent property of thousands of autonomous decisions made every hour by people, pipelines, and autoscalers with no visibility into the invoice they are generating. Closing that loop with the same rigor SREs apply to reliability — telemetry, automation, and closed-loop remediation — is what separates FinOps programs that produce quarterly PowerPoint decks from ones that actually bend the cost curve.

The FinOps Problem at Scale

Every large cloud estate eventually arrives at the same uncomfortable fact: nobody actually knows why the bill is what it is. A typical enterprise account structure spans dozens of AWS accounts or Azure subscriptions, hundreds of Kubernetes namespaces, thousands of IAM principals, and millions of resource-hours per month. Cost is the sum of independent decisions — a developer forgot to delete a load balancer, an autoscaler over-provisioned during a traffic spike three weeks ago and never scaled back down, a data engineer left a 96-vCPU Redshift cluster running over a holiday weekend, a machine learning team spun up eight A100 GPU instances for an experiment that finished on Tuesday. None of these are malicious. Each one is individually defensible. Collectively they are why the finance team is asking hard questions in the Monday leadership sync.

The traditional response — a monthly cost review meeting, a spreadsheet exported from the billing console, a Slack message asking "can someone look at this" — does not scale past a handful of accounts. By the time a human notices an anomaly in a monthly report, the waste has already accrued for four to six weeks. FinOps as a discipline exists precisely to close that latency gap, and the only way to close it at cloud scale is automation: continuous telemetry, continuous analysis, and increasingly, continuous remediation without waiting for a ticket to route through three approval layers.

This is fundamentally the same problem SREs and SOC analysts already solve for reliability and security — high cardinality signal, noisy baselines, and the need to act before a human can triage every event individually. That structural similarity is why the most mature organizations are converging their FinOps, SRE, and security operations tooling onto a shared observability and automation substrate rather than running three disconnected toolchains that each reinvent alerting, correlation, and workflow orchestration.

Why Traditional Cost Management Fails at Cloud Scale

Native cloud cost tools — AWS Cost Explorer, Azure Cost Management, GCP Billing reports — are excellent at answering "what did we spend" and mediocre at answering "why" and nearly useless at answering "what should we do about it, automatically, right now." They are retrospective by design: cost and usage reports (CUR) typically land with an eight to twenty-four hour delay, and the dashboards built on top of them are optimized for finance personas doing monthly reconciliation, not engineers who need real-time feedback loops on the infrastructure decisions they make in a pull request.

Three structural gaps explain why spreadsheet-and-dashboard FinOps consistently underperforms its promise:

• Attribution gap. Shared resources — NAT gateways, load balancers, managed Kubernetes control planes, shared RDS instances, data transfer across availability zones — do not map cleanly to a single team or product. Without consistent tagging enforcement and a cost allocation model that can split shared costs proportionally, 20–40% of spend in most estates lands in an "unallocated" bucket that nobody owns and nobody is incentivized to optimize.
• Latency gap. Monthly or even weekly review cadences mean waste compounds for weeks before it is caught. A forgotten dev environment running at production scale for six weeks is not a rounding error — at $40/hour for a GPU-backed instance, that is over $16,000 gone before anyone looks at a report.
• Action gap. Even when a dashboard correctly flags an idle resource or an oversized instance, someone still has to file a ticket, get an approval, schedule a maintenance window, and execute the change. In organizations without automated remediation, the median time from "identified" to "fixed" for a rightsizing recommendation is measured in weeks, and a meaningful fraction of identified savings opportunities are simply never actioned because the manual effort outweighs the perceived benefit.

The fix is not a better dashboard. It is treating cost the way reliability engineering treats error budgets: instrument continuously, alert on deviation from expected baselines, and wire remediation actions directly into the operational loop — ideally with policy guardrails that allow safe actions to execute autonomously while routing ambiguous or high-blast-radius decisions to a human for approval.

The FinOps Operating Model: Inform, Optimize, Operate

The FinOps Foundation's operating model — Inform, Optimize, Operate, run as an iterative loop rather than a linear project — remains the right mental model, but each phase has to be re-architected for automation rather than manual quarterly cycles if it is going to keep pace with elastic infrastructure.

Inform: Real-Time Visibility and Allocation

The Inform phase establishes shared visibility into cost, usage, and unit economics, broken down by team, product, and environment. At scale this requires a normalized data model across multiple cloud providers and billing formats — AWS CUR, Azure Cost Management exports, GCP BigQuery billing export — unified into a common schema (the FinOps Foundation's FOCUS specification is increasingly the target normalization layer) so that engineers see one consistent view regardless of which cloud a workload runs on.

Optimize: Turning Insight into Recommendations

Optimize is where rightsizing, commitment purchasing, storage tiering, and architecture recommendations get generated. This phase increasingly relies on machine learning over historical utilization data rather than static rules ("if CPU < 20% for 14 days, flag as oversized"), because static thresholds produce both false positives (bursty batch workloads that are legitimately idle most of the time) and false negatives (workloads with a misleading average that mask a painful p99 spike).

Operate: Closing the Loop with Automation

Operate is the phase most organizations under-invest in, and it is where the actual dollar savings materialize. This is where recommendations become executed changes — either through automated workflows with policy guardrails or through well-instrumented human-in-the-loop approval chains that are fast enough to matter. A recommendation that sits in a backlog for six weeks captured zero value; the same recommendation executed within an hour of detection, gated by a lightweight policy check, captures the full opportunity.

Building the Cost Telemetry Pipeline

A production-grade cost automation pipeline has four architectural layers, and skipping any one of them is why so many FinOps tooling initiatives stall at "we have a dashboard" and never reach "we have automation."

Ingestion. Pull cost and usage data from every provider's native billing export — AWS CUR 2.0 delivered to S3, Azure Cost Management scheduled exports, GCP BigQuery billing export — on the tightest interval the provider supports (AWS CUR now supports near-daily granularity; several providers still lag on true real-time metering). Supplement billing exports with resource inventory APIs (EC2 DescribeInstances, Azure Resource Graph, GCP Asset Inventory) polled hourly, because billing data alone tells you what something cost, not what it currently is, and remediation actions need current state.

Normalization. Map every provider's proprietary line-item format into a common schema. The FinOps Foundation's FOCUS (FinOps Open Cost and Usage Specification) has become the de facto standard for this layer, defining consistent columns for billed cost, effective cost, list cost, service category, and resource identifiers across providers. Without this normalization step, every downstream report, alert rule, and automation policy has to be duplicated three or four times — once per cloud — which is exactly the kind of maintenance burden that causes FinOps tooling to rot within a year.

Allocation. Split shared and untagged costs using a defensible methodology. Common approaches include proportional allocation by consuming resource's tagged share, fixed splits negotiated between teams for genuinely shared infrastructure (a shared EKS control plane, a shared Direct Connect circuit), and untagged-cost chargeback to a platform team that owns closing the tagging gap. The allocation engine needs to run continuously, not as a monthly finance close exercise, because engineers only change behavior in response to feedback that arrives while they still remember the decision that caused the cost.

Enrichment. Join cost data against operational context — deployment metadata, on-call ownership, service catalogs, Kubernetes labels, business unit hierarchies — so that a cost anomaly alert can be routed to the team that owns the resource rather than landing in a shared inbox nobody monitors. This is the layer that determines whether automation feels like a helpful colleague or an annoying alert-spam generator; get enrichment wrong and teams will build filters to ignore the alerts within a month.

Organizations running an AI-native operations stack generally consolidate this pipeline with the same event bus and correlation engine already ingesting infrastructure telemetry and security signals, because cost anomalies, reliability incidents, and security events frequently share a root cause — a misconfigured autoscaling policy, an exposed API that is being hit by a scraper, a runaway batch job — and correlating across all three domains catches issues that a cost-only tool would miss entirely.

Anomaly Detection and Forecasting with AI

Static threshold alerting ("notify if daily spend exceeds $X") is the FinOps equivalent of a fixed CPU threshold alert in infrastructure monitoring — it is trivial to implement and reliably wrong. Cloud spend has strong seasonality (weekday versus weekend, end-of-month batch processing, retail traffic patterns around promotions), and a fixed threshold either fires constantly during expected peaks or misses genuine anomalies during quiet periods.

Effective anomaly detection models expected spend per service, per account, and per cost category using time-series forecasting techniques — seasonal decomposition, gradient-boosted regression trees over calendar and usage features, or more recently transformer-based forecasting models trained on the organization's own historical billing data. The model produces a confidence band, and anomalies are flagged when actual spend deviates outside that band by a statistically meaningful margin, adjusted for the natural volatility of that specific cost category. A 15% swing in a highly variable spot-instance-heavy batch processing account is normal noise; the same 15% swing in a steady-state production database bill is a five-alarm signal.

Forecasting serves a second, equally important purpose beyond anomaly detection: budget planning. A well-tuned forecast model projects month-end spend by day three or four of the billing cycle with enough accuracy that finance teams can flag budget risk while there is still time to act, rather than discovering an overage after the invoice closes. The best implementations decompose the forecast by driver — committed spend (reservations, savings plans, already-provisioned capacity) versus variable spend (on-demand compute, data transfer, API calls) — because the two categories require entirely different intervention levers.

Root-cause analysis is where AI adds the most differentiated value over rules-based systems. When an anomaly fires, the useful question is not "spend went up" but "which specific resource, deployment, or configuration change caused it." Correlating the cost anomaly timestamp against deployment events, autoscaling group activity, IAM API call logs (CloudTrail, Azure Activity Log, GCP Audit Logs), and Kubernetes admission events narrows the search from "somewhere in a 400-account estate" to "this specific commit merged at 14:32 changed the autoscaling max from 20 to 200 nodes." This is precisely the correlation pattern that AIOps platforms already apply to reliability incidents, and applying the same causal-inference engine to cost telemetry is a natural extension rather than a separate discipline requiring separate tooling.

Automated Remediation: From Alert to Action

Detection without action is a report, not FinOps. The Operate phase is where organizations either capture the savings a recommendation identified or watch it evaporate as the backlog item nobody has time for. Automated remediation needs to be designed with the same rigor as any production change-management system: tiered by risk, gated by policy, and fully auditable.

Remediation Tiers

Not every action carries the same blast radius, and treating them uniformly is how automation programs either move too slowly to matter or move fast enough to cause an outage. A workable tiering model:

• Tier 1 — fully autonomous. Zero production risk actions: deleting unattached EBS volumes older than a grace period, releasing unassociated Elastic IPs, cleaning up orphaned snapshots past retention policy, terminating instances tagged as ephemeral that have exceeded their declared TTL. These execute without human approval, logged for audit.
• Tier 2 — autonomous with rollback. Actions with production impact but a fast, safe rollback path: rightsizing a non-production instance, scaling down a dev/test Kubernetes node pool outside business hours, applying a scheduled stop/start policy to a QA environment. These execute automatically but are wrapped in a monitoring window and auto-rollback trigger if error rates or latency degrade.
• Tier 3 — approval-gated. Actions on production-critical resources: rightsizing a production database instance, modifying autoscaling policies on customer-facing services, purchasing or modifying multi-year reserved capacity commitments. These generate a remediation plan and route to the resource owner or a designated approver via chat-ops (Slack, Teams) with one-click approve/reject, and execute immediately on approval rather than waiting for a change-advisory-board cycle.
• Tier 4 — advisory only. Architectural recommendations that require engineering judgment: migrating a workload to a different instance family, re-architecting a monolithic service into components with independent scaling, moving cold data to a cheaper storage tier with different access-latency trade-offs. These generate a ticket with supporting cost and utilization evidence but do not execute automatically.

The Guardrail Layer

Every automated action — regardless of tier — passes through a policy engine before execution. Practical guardrails include maintenance-window restrictions (no production changes during declared peak traffic windows or change freezes), dependency checks (do not terminate an instance that is currently serving active connections, verified via load balancer target health rather than just a CPU metric), blast-radius caps (no single automated action may affect more than N% of a service's capacity or more than $X of monthly run-rate in one execution), and a global kill switch that can pause all autonomous remediation instantly if something looks wrong. This policy layer is exactly the kind of guardrail-plus-autonomy pattern used in agentic security operations, where autonomous response actions on security alerts are similarly tiered by confidence and blast radius rather than treated as all-or-nothing automation.

Worked Example: Idle Non-Production Rightsizing

Consider a concrete workflow for the highest-volume, lowest-risk automation most organizations should implement first: non-production rightsizing and scheduling.

1. Telemetry pipeline ingests fourteen days of CPU, memory, and network utilization for every instance tagged environment=dev or environment=staging.
2. Analysis engine computes p50, p95, and p99 utilization per resource and compares against the provisioned instance class's capacity curve.
3. Any instance with p95 CPU utilization below 15% and no memory pressure for the full window is flagged as a rightsizing candidate; the engine recommends the smallest instance class that would keep p99 utilization under 70%.
4. A scheduling analysis runs in parallel: instances with near-zero activity outside 08:00–20:00 local business hours on weekdays are flagged for an automated stop/start schedule.
5. Both recommendations pass the Tier 2 policy gate — non-production, rollback available via re-launch from the same AMI/image, no active user sessions detected — and execute automatically, with the change logged and a summary posted to the owning team's channel.
6. A 72-hour monitoring window tracks whether the resized instance shows any performance degradation signal (elevated error rate, CPU throttling, OOM kills); if so, the change auto-reverts and the resource is excluded from future automated rightsizing for a cooldown period.

This single workflow, applied consistently across a mid-size estate, typically recovers 20–35% of non-production compute spend within the first quarter of operation, because non-production environments are provisioned once by a developer optimizing for "definitely enough capacity" and then never revisited.

Rightsizing, Reservations, and Commitment Management

Compute rightsizing and commitment-based discounting (reserved instances, savings plans, committed use discounts) are the two largest optimization levers in most cloud bills, and they interact in ways that make sequencing important: rightsize first, then commit, not the other way around. Purchasing a three-year reserved instance for an oversized instance class locks in the waste for three years.

Commitment portfolio management is itself a continuous optimization problem, not a one-time purchase decision. Coverage (the percentage of eligible usage covered by a commitment) and utilization (the percentage of purchased commitment actually consumed) need to be tracked separately, because they fail in opposite directions — low coverage means you are paying on-demand rates for workloads that are steady-state and commitment-eligible, while low utilization means you bought more commitment than your actual usage justifies and are burning money on unused reserved capacity. The target zone for a mature program is coverage above 70–80% for genuinely steady-state workloads combined with utilization above 95%, achieved through laddered commitment terms (mixing one-year and three-year terms, and mixing standard/convertible reservation types) that leave room to adjust as usage patterns shift.

Spot and preemptible capacity deserves separate treatment from the standard rightsizing conversation because the savings profile is different — 60–90% discounts versus on-demand, in exchange for the possibility of reclamation with a short notice window (two minutes on AWS, thirty seconds on GCP). Spot is appropriate for fault-tolerant, stateless, or checkpoint-able workloads: batch processing, CI/CD runners, stateless web tier capacity behind an autoscaling group with diversified instance types, and increasingly a meaningful fraction of Kubernetes worker node pools for non-critical workloads. Automated spot management requires diversification across multiple instance types and availability zones to reduce simultaneous reclamation risk, combined with graceful drain handling so that reclamation notices trigger workload migration rather than abrupt termination.

Kubernetes and Container Cost Allocation

Kubernetes breaks the traditional cost allocation model because the billing unit (the underlying node) and the consumption unit (the pod, namespace, or workload) are decoupled by design — a single node hosts workloads from multiple teams, and the cloud provider's invoice has no visibility below the node level. Solving this requires a metering layer that reads Kubernetes resource requests, limits, and actual usage (via the metrics-server or a Prometheus-based collector) and allocates each node's cost proportionally across the pods scheduled on it, accounting separately for requested-but-unused capacity, which is itself a major and frequently invisible source of waste.

Two allocation philosophies compete here, and most mature programs end up running both simultaneously for different purposes. Request-based allocation charges teams for what they asked Kubernetes to reserve (their declared CPU/memory requests), which correctly incentivizes accurate resource requests but can overstate cost for teams running conservative headroom. Usage-based allocation charges teams for what they actually consumed, which is fairer in the moment but removes the incentive to right-size requests, since a team requesting 4 vCPUs and using 0.5 pays the same as a team correctly requesting 0.5. The practical answer is to allocate cost on requests for chargeback purposes (so the incentive to request accurately stays intact) while separately surfacing a request-versus-usage efficiency score per namespace that becomes its own optimization target, distinct from the chargeback number.

Cluster-level waste compounds the pod-level allocation problem: over-provisioned node pools, unused persistent volumes left behind after a workload is deleted, and cluster autoscaler configurations that scale up aggressively but scale down conservatively (a common default tuning choice made to avoid disruption, which quietly inflates baseline spend). Automated remediation here includes bin-packing optimization (consolidating workloads onto fewer, better-utilized nodes and cordoning/draining the freed capacity), vertical pod autoscaler recommendations fed back into deployment manifests via a GitOps pull request rather than a runtime mutation (so the change is reviewable and versioned), and orphaned-volume cleanup jobs running on the same cadence as the broader idle-resource sweep described earlier.

Governance, Guardrails, and Policy-as-Code

Automated remediation only works if the underlying environment is governed consistently enough for automation to trust its own inputs, which means policy-as-code is a prerequisite for FinOps automation, not an optional add-on. Tag governance, in particular, has to be enforced at admission time — via cloud provider service control policies, Kubernetes admission webhooks (OPA/Gatekeeper or Kyverno), or CI/CD pipeline checks on infrastructure-as-code templates — rather than corrected after the fact, because retroactive tagging campaigns have a well-documented failure rate: they achieve a burst of compliance right after the campaign and decay steadily afterward as new resources get created without enforcement.

A minimum viable tagging schema for automation to function includes: cost center or business unit owner, environment (production/staging/dev/sandbox), service or application name, and a data classification or criticality tier that the policy engine can use to determine which remediation tier applies. Anything beyond these four is a nice-to-have; anything less and the allocation and automation layers cannot reliably distinguish a production database from a forgotten sandbox experiment.

Budget guardrails deserve their own governance layer, separate from tagging. Hard budget caps (hard-stopping resource creation once a threshold is breached) are appropriate for sandbox and experimentation accounts where the risk of over-restriction is low; soft budget alerts with escalating notification severity are more appropriate for production accounts, where a hard stop could itself cause an outage. Provisioning guardrails — blocking the creation of instance types above a certain size, or GPU instances, or cross-region data transfer configurations without an explicit approval — catch the most expensive mistakes (an accidentally-provisioned 96-vCPU instance in the wrong region) before they ever reach the billing pipeline, which is strictly better than detecting and remediating them after the fact.

This governance layer is also where FinOps automation intersects most directly with security posture. An unrestricted ability to provision arbitrary compute is both a cost risk and an attack surface — compromised credentials used for cryptomining are a cost anomaly and a security incident simultaneously, and organizations that run continuous exposure management alongside their cost governance catch this dual-nature class of incident far faster than teams treating cost and security as separate concerns with separate tooling and separate on-call rotations.

FinOps Meets SecOps and Reliability

Treating FinOps, reliability engineering, and security operations as three separate disciplines with three separate toolchains is an organizational artifact, not a technical necessity, and it is increasingly a competitive disadvantage. All three disciplines are, at their core, the same operational pattern applied to different signal types: continuously ingest telemetry, detect deviation from an expected baseline, correlate against recent changes to find root cause, and execute a remediation with appropriate guardrails for the blast radius involved.

The overlap is not just architectural convenience — it catches real incidents that siloed tooling misses. A sudden spike in outbound data transfer cost is, simultaneously, a FinOps anomaly and a potential data exfiltration indicator. A misconfigured autoscaling policy that drives cost up is often the same misconfiguration causing a reliability incident downstream (thundering-herd scaling delays, or over-aggressive scale-down causing capacity shortfalls during traffic spikes). Idle, forgotten resources are both cost waste and unpatched attack surface — an abandoned staging environment nobody is monitoring is exactly the kind of asset that shows up in an exposure management scan with known CVEs and no owner to remediate them.

Organizations that unify observability, correlation, and automated response across cost, reliability, and security — the model behind agentic AI-native operations — get a compounding benefit: a single event bus, a single correlation engine, and a single policy-and-approval framework serve all three domains instead of maintaining three separate alerting systems, three separate on-call rotations, and three separate audit trails that have to be manually reconciled during a postmortem. For teams running an integrated NOC/SOC model, extending that same operational floor to cost telemetry is a natural next step rather than a new program, and it means the analysts and SREs who already know how to triage an anomaly and evaluate a remediation's blast radius can apply exactly the same judgment to a cost spike as they do to a latency spike or a suspicious authentication pattern.

This convergence also changes the skill profile FinOps teams need. Rather than a dedicated cost-analyst function reading dashboards, the durable model is embedding cost awareness into the same platform engineering and SRE teams already responsible for reliability and security posture, supported by agentic automation that handles the repetitive detection-and-remediation work so human attention concentrates on the Tier 3 and Tier 4 decisions that genuinely need engineering judgment.

Metrics That Matter: KPIs and Dashboards

A FinOps program that tracks only total spend is measuring the wrong thing — total spend should go up as the business grows, and a program that only reports "we saved $X this month" without unit-economic context cannot distinguish genuine efficiency gains from a slowdown in business growth. The metrics that actually drive better engineering and purchasing decisions fall into four categories.

Unit economics connect cost to business output: cost per transaction, cost per active user, cost per API call, cost per gigabyte processed. These are the numbers that let a FinOps program say "we grew revenue 40% and infrastructure cost only 22%," which is a fundamentally different and more credible story than "we spent less than last month."

Coverage and utilization for commitment-based discounting, tracked separately as discussed earlier, tell you whether the commitment portfolio is well-tuned or leaking money in either direction.

Waste ratio — the percentage of total spend attributable to identified, actionable waste (idle resources, oversized instances, orphaned storage, untagged/unallocated cost) — is the single best leading indicator of program health, because it is the pool of spend automation can actually act on. A mature program drives this below 10–15% of total compute and storage spend; an unmanaged estate frequently runs 30–40% or higher.

Automation coverage and time-to-remediation measure the Operate phase directly: what percentage of identified recommendations were executed automatically without human intervention, and what is the median time from detection to remediation for each tier. A program can have excellent detection and terrible outcomes if remediation execution lags — tracking time-to-remediation as a first-class metric, the same way SREs track mean-time-to-resolution for incidents, keeps the Operate phase honest.

Implementation Roadmap: A 90-Day Plan

Organizations starting from a dashboard-only or spreadsheet-based FinOps practice can reach meaningful automation maturity in roughly a quarter if the rollout is sequenced correctly — and sequencing matters more than tooling choice, because deploying automation onto ungoverned, untagged infrastructure produces unreliable recommendations and erodes trust in the program before it has a chance to prove value.

1. Weeks 1–2: Foundation. Stand up the normalized billing ingestion pipeline (FOCUS-schema normalization across every cloud in use) and establish the minimum viable tagging schema with admission-time enforcement on all newly created resources. Do not attempt to retroactively fix historical tagging yet — stop the bleeding first.
2. Weeks 3–4: Allocation and visibility. Build the allocation engine covering shared-cost splitting, and ship team-level and product-level dashboards with unit-economic metrics, not just raw spend. Get every engineering team looking at their own numbers before introducing any automation, so the baseline behavioral shift (accurate tagging, awareness of cost impact) starts before automated action does.
3. Weeks 5–8: Tier 1 and Tier 2 automation. Deploy the zero-risk automated cleanup sweep (orphaned volumes, unattached IPs, expired snapshots) and the non-production rightsizing/scheduling workflow described earlier. These two workflows alone typically deliver the largest single tranche of savings in the entire program and build organizational trust in automation before higher-stakes tiers are introduced.
4. Weeks 9–11: Anomaly detection and forecasting. Train and validate the baseline forecasting model against at least 60–90 days of historical data, tune anomaly sensitivity against known past incidents to calibrate false-positive rates, and wire alerts into the same chat-ops and on-call routing already used for reliability and security alerts.
5. Week 12: Tier 3 workflows and commitment optimization. Launch approval-gated remediation for production resources with chat-ops one-click approval, and run the first commitment portfolio review using the now-clean, now-rightsized usage data as the basis for reservation and savings-plan purchasing decisions — not before, since committing against unoptimized usage locks in avoidable waste for the length of the term.

Beyond the 90-day mark, the roadmap shifts from building the pipeline to tuning it: expanding Kubernetes-level allocation and bin-packing automation, integrating cost signals into the same correlation engine used for reliability and security incident response, and steadily migrating well-proven Tier 3 workflows down to Tier 2 as confidence in the automation's judgment builds through a track record of clean executions. Programs that reach this steady state typically settle into a rhythm where the platform team spends the bulk of its time tuning policy thresholds and reviewing the small number of Tier 4 architectural recommendations, while the high-volume detection-and-remediation work runs autonomously in the background — which is the entire point: cost optimization should be a property of the platform, not a recurring manual chore competing for engineering time against feature work.

Frequently asked questions