Reduce cloud cost

When you'd do this

• The AWS bill stepped up last month and finance wants to know which service, which usage type and which team caused it.
• A FinOps or platform lead is preparing a quarterly cost review and needs a ranked list of savings, separated into what is safe to act on now and what needs checking.
• An account has years of history: detached volumes, unused Elastic IPs, old manual snapshots and load balancers nobody remembers creating.
• Compute is steady and growing, and someone asks whether a Savings Plan, Graviton instances or spot capacity would pay off.
• An engineering lead wants to resize an oversized instance or remove an idle resource without breaking a service nobody listed.
• A cost-saving change has shipped and you need to show that spend actually came down.

Before you start

• Vörr: your organisation is set up and the AWS accounts you care about are connected with read-only credentials, and a scan has completed. Waste and configuration-based savings come from the scan, so they are available as soon as it finishes.
• Vörr, for actual spend: Cost Explorer is enabled on the account. It takes about a day to populate, and spend is read from a daily pull, so figures can be up to a day old. Organisation-wide numbers need the payer (management) account connected; a member account shows only its own spend.
• Vörr, for utilisation-based rightsizing: AWS Compute Optimizer (or Cost Explorer's rightsizing recommendations) is enabled and has enough history to make recommendations: for EC2 instances, at least 30 hours of CloudWatch metrics in the past 14 days.
• Vörr, for owners and estimates per team: resources are mapped to workspaces and environments in Cloud Mapping. Per-workspace spend is estimated from that mapping.
• Vörr, for utilisation: CloudWatch comes through the AWS connection; for Kubernetes, an observability source that reports cluster metrics (Prometheus, Grafana or SigNoz) is connected.
• Vörr: the connector is added to Claude, ChatGPT or another MCP assistant and you have consented to connect it. Answers draw on the organisation's connected sources, and workspaces label what comes back; admins manage connections. ChatGPT needs a paid plan with Developer mode turned on.
• Vörr, for Terraform coverage: your Terraform state buckets are connected through the Terraform connector. Without it, Vörr cannot say whether a resource is managed as code.
• CodeZero: the extension is installed in VS Code and the organisation's repositories, including Terraform and deployment-config repositories, are indexed.
• Nobody needs billing permissions on their laptop. Vörr's credentials stay in Vörr and are never shown to the assistant.

If any of this isn't set up yet, start here:

• Connect a cloud account
• Connect observability
• Add Vörr to Claude or ChatGPT
• Install and connect CodeZero
• AWS: Enabling Cost Explorer
• AWS: Compute Optimizer resource requirements

Operations

A cost review has two halves. The first finds and ranks the money: spend, waste, savings and rightsizing. The second makes each item safe to act on: utilisation, owner, dependents, the code that creates it, and a reviewed change. Vörr carries most of the first half and the cloud side of the second; CodeZero carries the code side and the change. Neither product changes your infrastructure.

Read the spend breakdown and trend

1. Vörr: ask for actual spend for the trailing month, broken down by service, highest first, with the 30-day forecast. Spend is amortised, so Savings Plans and reserved instances are spread across their term instead of landing as one large charge.
2. Vörr: ask about the trend. If spend stepped up during the period, Vörr names the day it jumped and by how much, and compares the forecast with the trailing month to show whether the run rate is rising.
3. Vörr: break opaque lines such as EC2-Other or S3 down by usage type, so NAT gateway data processing, inter-AZ transfer or EBS storage show up as their own drivers.
4. Vörr: ask for the per-workspace estimate to see roughly how spend divides between teams or applications. It is an estimate built from workspace mapping, not a per-resource bill.
5. Agent: summarise the shape in two or three lines: the dominant service, the driver behind it and any step-up date.

A good result separates actual figures from Cost Explorer from estimates, names the account and whether it is the payer or a member account, and states the data's age. If the answer looks organisation-wide but came from a member account, it is partial.

Find waste

Waste is spend on resources that are doing nothing. Vörr finds it from the scanned configuration, without calling a cost API, and groups it by pattern with a rough monthly estimate for each.

1. Vörr: ask for likely waste in the account. The patterns it reports are unattached EBS volumes, unassociated Elastic IPs, orphaned snapshots, stopped EC2 instances still holding volumes, idle load balancers with no target group or no registered targets, and manual RDS snapshots, which never expire and bill until someone deletes them.
2. Vörr: read the coverage for each pattern. An empty pattern is only a real zero if that part of the scan completed.
3. Vörr: open the larger items to read tags, workspace mapping and age before deciding anything.
4. Agent: rank the list by estimated monthly cost and mark which items have an obvious owner.

Some estimates are deliberately rough: stopped instances with volumes are flagged without a figure, and load balancer estimates cover only the base hourly charge. Load balancers whose targets are all unhealthy are not detected as idle, so look for those separately.

Find savings opportunities

1. Vörr: ask for configuration-based savings. These need no utilisation data and work before Compute Optimizer is enabled: EC2 instances on non-Graviton families that could move to Graviton, priced as the difference; RDS instances on non-Graviton classes, flagged without a figure; gp2 EBS volumes that could move to gp3, attached or not; the on-demand versus spot split; and EKS, Karpenter or Auto Scaling node pools that fell back to on-demand.
2. Vörr: ask for the commitment position: a Savings Plan purchase recommendation with hourly commitment, estimated savings and return, and existing Savings Plan and reserved-instance coverage, utilisation, uncovered on-demand spend, unused commitment and the next expiry date.
3. Agent: rank by estimated monthly saving and attach one verification step to each line, for example ARM compatibility for Graviton.

Treat every configuration-based figure as a range, not a quote. Spot savings for node pools are an upper bound. Graviton is a price-performance swap, not a utilisation call: check that the AMI, the container images and any native dependencies build for ARM before you plan it. A Savings Plan is a financial commitment; buying one is a decision for whoever owns the budget, not something to take from a chat answer.

Review rightsizing candidates with a safe-to-act hint

1. Vörr: ask for EC2 rightsizing recommendations. Each one gives the current and recommended instance type and the estimated monthly saving, sorted by saving.
2. Vörr: each recommendation is joined to the dependency graph from the scan. It carries a safe-to-act hint that is true when nothing in the scan depends on the instance.
3. Agent: lead with the safe-to-act candidates, and list the others as needing a dependency and utilisation check first.

Safe to act means no known dependents in the scan, not zero traffic. Something outside the connected accounts, or a caller that exists only in code, will not be in the graph. Always check utilisation, the next operation, before resizing anything.

Cross-check against utilisation

1. Vörr: for each instance, database or service you plan to resize, ask for CloudWatch CPU and memory metrics against the 14-day baseline (EC2 memory needs the CloudWatch agent installed). Each reading is classed as normal, elevated or unprecedented, or unknown where there is no baseline yet.
2. Vörr: for Kubernetes, ask for the top CPU and memory consumers by pod, namespace, deployment or node from the connected metrics source, and for pod health (pods ready, restarts) on the workloads you plan to touch.
3. Vörr: compare a quiet week with a busy one using a comparison window, for example the last seven days against the same period a week earlier. Where two sources disagree, Vörr reports both instead of averaging them.
4. Agent: drop or downgrade any candidate whose peak, not average, would not fit the recommended size.

• Monitor service health

Find the owner and environment of each costly resource

1. Vörr: read each resource's workspace and environment mapping, its fg: and customer tags, and any mapping gaps.
2. Vörr: search for resources that need mapping, to see which part of the spend has no owner at all.
3. CodeZero or Vörr: check repository owners by commit history for the code that creates or uses the resource, to find a person to ask.
4. You: assign missing workspaces and environments in Vörr's Cloud Mapping; see Explore cloud infrastructure for how mapping works.

Unmapped resources also weaken the per-workspace estimate. A large unattributed share is a mapping job before it is a cost job.

Check dependencies before removing or resizing

1. Vörr: ask for the upstream and downstream blast radius of the resource, with true counts, and its one-hop neighbours with confidence.
2. Vörr: for a snapshot or volume, check what it was taken from or attached to; for a load balancer, what sits behind and in front of it.
3. CodeZero: check the code side, i.e. which services name the resource in connection strings or Kubernetes, Helm or Compose config, and which repositories read or write the tables in a database.
4. Agent: merge both lists and mark where each item came from.

A good answer gives counts, the list behind them, the confidence of each relationship and the scan coverage that bounds the result. If the resource is low-confidence or the coverage is incomplete, it belongs in the verify-first group, whatever the hint said.

Tie cost to code

1. Vörr: check whether the resource is Terraform-managed and from which module and state. Anything unmanaged has to be changed by hand or imported first.
2. Vörr: read the repositories and their branch-to-environment mapping, to tie a production resource to the branch that deploys it.
3. CodeZero: find the Terraform module, the instance type or volume type it sets, and every environment file that overrides it, across indexed repositories, including ones not cloned.
4. CodeZero: read the deployment config that sets each service's requests, limits and replica counts.
5. CodeZero: check recent commits on the path to see when the size or count last changed and who changed it.

• Graph (CodeZero)

Plan the change in CodeZero

1. Vörr, in the assistant: collect the facts for each item, i.e. resource, estimated saving, utilisation, dependents, owner, Terraform module and coverage, and paste the summary into CodeZero.
2. CodeZero: plan, approve and apply the change as described on Explore cloud infrastructure. Deleting unmanaged waste such as old snapshots is done by a person with the right access, not by either product.

Batch safe-to-act items into one plan and keep verify-first items in their own plans, each with its owner named. That keeps a rollback small when one assumption turns out to be wrong.

• Execution modes
• Delegate approved work

Verify after the change

1. Vörr: after the change has run for a few days, ask for the spend trend again. Spend data arrives through a daily pull, so a change made today will not show for a day or more, and commitments and monthly charges can take longer to settle.
2. Vörr: compare utilisation and service health before and after with a comparison window, for example error rate, p95 latency, CPU, memory and restarts against the week before the change.
3. Vörr: re-run waste and savings after the next scan to confirm the items are gone, and check the coverage is the same as before, so a disappearance is not just a scan that failed.
4. Agent: write a short before-and-after note with actual spend figures, estimates labelled as estimates, and any regressions.

Read coverage before you quote a number

Every cost answer from Vörr carries a coverage status, and it is the part most worth reading. An empty waste pattern can mean nothing exists, or that the scan was denied permission for that service, failed or only partly ran. A spend figure can be missing because Cost Explorer is not enabled or the role cannot read it. Rightsizing can be empty because Compute Optimizer has no data yet.

Completed or no resources found

The pattern was fully checked. An empty result is a real zero.

Access denied, failed or partial permission

Not fully scanned. The absence of waste or savings is unknown, not zero.

Cost Explorer unavailable

No actual spend for this account. Waste and configuration-based savings still stand; spend figures and the Savings Plan recommendation do not appear.

No rightsizing data

Compute Optimizer is not enabled or lacks history. No recommendations does not mean nothing is oversized.

Without CodeZero or Vörr

Claude Code with the AWS CLI installed and credentials that can read Cost Explorer is genuinely useful here. It can run ce get-cost-and-usage grouped by service or usage type, pull rightsizing and Savings Plan recommendations, list unattached volumes and unassociated Elastic IPs with describe calls, read CloudWatch metrics, run kubectl top, grep a checked-out Terraform repository for an instance type, and reason well over all of it. ChatGPT or Claude chat can reason over a Cost Explorer CSV or a billing export you paste in.

The cost is in the credentials and the joins. Billing and Cost Explorer permissions end up on developers' laptops, often in roles that can also change resources. Each waste pattern is a separate set of queries per account and region. Joining a cost line to its owner, its dependents and the code that creates it is manual, and an empty result from a query the agent never ran, or one that was denied, looks the same as no waste.

With CodeZero and Vörr

Spend without billing keys on laptops (Vörr)

Amortised AWS spend, trend, usage types, forecast, commitments and a per-workspace estimate from the assistant.

Waste and savings from the scan (Vörr)

Idle and orphaned resources, Graviton, gp3, spot and node-pool candidates, available as soon as a scan completes.

Rightsizing with dependents (Vörr)

Each recommendation joined to the dependency graph, so safe-to-act items are separated from ones that need checking.

Utilisation in the same conversation (Vörr)

CloudWatch against a 14-day baseline and Kubernetes top consumers from connected sources, each figure with its source.

Owner, environment and IaC state (Vörr)

Workspace and environment mapping with gaps, tags, Terraform management and blast radius for each costly resource.

The code behind the cost (CodeZero)

Terraform modules, overrides and deployment config across every indexed repository, with recent commits and owners.

A reviewed change (CodeZero)

A plan that names repositories and verification commands, with no code changes until a person approves it.

Coverage on every answer (Vörr)

Each cost answer says what it could not see.

The two products do not call each other. The combination is you, or the agent, carrying Vörr's ranked and checked findings into a CodeZero plan: Vörr says where the money goes and what depends on it; CodeZero changes the definition under a plan you approve.

Worked example: a step-up in EC2 spend

A platform lead sees the prod AWS bill rise and wants a ranked, checked list of what to do about it before the monthly cost review. All resource names, figures and findings below are illustrative.

What Vörr returned

Spend (actual, amortised) - prod-core, last 30 days: $48,200   Forecast next 30 days: $52,900
Step-up: +$310/day from 9 October
  EC2-Instances   $19,400   (+18%)
  EC2-Other        $7,100   usage types: NatGateway-Bytes $3,900, EBS:VolumeUsage.gp2 $2,100
  RDS              $8,300
Commitments: Compute Savings Plan coverage 41%, next expiry 14 November
Workspace estimate: commerce ~ $17k, data ~ $11k, unattributed ~ $6k

Tier 1 - safe to act (nothing in the scan depends on it)
  ~$420-480/mo   38 unattached EBS volumes (staging and prod)
  ~$260-300/mo   27 manual RDS snapshots older than 12 months
  ~$140-170/mo   rightsize i-0a12 (reports-batch) m5.4xlarge -> m5.2xlarge

Tier 2 - verify first
  ~$900-1,100/mo  Graviton: 14 instances in reports-worker ASG   (verify ARM compatibility)
  ~$350-400/mo    gp2 -> gp3: 61 attached volumes
  up to ~$1,800/mo  eks prod-general node pool 92% on-demand   (upper bound)
  ~$95/mo         rightsize i-0b34 (search-indexer)   3 dependents

Coverage
  EC2, EBS, RDS, ELB   completed
  Cost Explorer        ok (data to 28 October)
  Compute Optimizer    ok
  Lambda               access denied

Checking utilisation, owners and code

The CloudWatch check shows reports-batch peaking at 31% CPU over 14 days, well within the smaller size, so it stays in Tier 1. search-indexer has an unprecedented memory peak on 22 October and three dependents, so it moves out of this round. The new reports-worker instances launched on 9 October match the step-up date. CodeZero finds the instance type in the infra repository, in a Terraform module with a prod override that a commit changed on 8 October.

reports-worker instance type set in:
  infra   modules/reports_worker/main.tf:22        default = "m5.xlarge"
  infra   envs/prod/reports_worker.tfvars:4        instance_type = "m5.2xlarge"   (commit 8 Oct, desired_capacity 8 -> 14)
  infra   envs/staging/reports_worker.tfvars:4     instance_type = "m5.large"
reports-worker image built in:
  reports-service   Dockerfile:1   FROM python:3.12-slim   (multi-arch base image)

Conclusion and follow-ups

• The step-up is the reports-worker scale-out on 9 October, plus NAT data processing that rose alongside it. Both are explained, not waste.
• Tier 1, roughly $820-950 a month: the volumes and snapshots go to their owners in commerce and data for deletion, and the reports-batch resize goes into a CodeZero plan in the infra repository with terraform validate and terraform plan as verification.
• Tier 2: a separate plan moves reports-worker to Graviton in staging first, after the team confirms the image and its native dependencies build for ARM.
• The Savings Plan expiring on 14 November goes to the budget owner as a decision, with coverage and the purchase recommendation attached.
• The $6k unattributed spend becomes a mapping task in Cloud Mapping, and Lambda access for the read-only role goes to the account owner so the next scan covers it.
• Verification: a week after each change, re-read the trailing-30-day spend breakdown and step-up trend, and compare the reports-worker CPU, memory, error rate and p95 against the week before.

Verify and follow up

• Coverage first: for every total, read the coverage for each pattern, whether Cost Explorer and Compute Optimizer were available, and which accounts were included.
• Actuals and estimates: keep Cost Explorer figures and configuration-based estimates apart in anything you send on. Quote estimates as ranges.
• Payer or member: confirm whether spend came from the payer account before calling it organisation-wide.
• Safe to act: re-check utilisation and code-side references for every Tier 1 item; the hint covers only known dependents in the scan.
• Confidence: check medium and low-confidence relationships against configuration in Cloud Mapping, or against the call site in CodeZero with Verify on the inferred edge.
• Changes: let the CodeZero plan's verification commands run, then read the terraform plan output yourself before anything is applied.
• After: once the change has been in place for at least a few days, re-read the trailing-30-day spend breakdown and step-up trend, compare service metrics over matching windows, and re-run waste after the next scan.
• Next: assign owners to unattributed spend, and review exposure on anything public you found along the way.

Limits

• Cost is AWS only. Google Cloud and Azure spend, waste, savings and rightsizing are not supported, although their resources still appear in Vörr's inventory.
• Actual spend needs Cost Explorer enabled and readable, comes from a daily pull and can be up to a day old. Organisation-wide totals need the payer account connected.
• Per-workspace spend is an estimate from workspace mapping, not a billed per-resource figure. Unmapped resources reduce its accuracy.
• Waste and savings are computed from the latest scan with rough estimates. Some items are flagged without a figure, load balancer estimates cover only the base charge, load balancers whose targets are all unhealthy are not detected, and spot savings are an upper bound.
• Rightsizing covers EC2 recommendations from Compute Optimizer or Cost Explorer and needs them enabled with enough history. The safe-to-act hint means no known dependents in the scan, not zero traffic.
• Graviton candidates do not check whether your software runs on ARM. That check is yours.
• Vörr is read-only towards your systems from the assistant. It cannot delete, resize, tag or map resources, or buy commitments. CodeZero edits files under an approved plan; neither product applies infrastructure changes.
• CodeZero indexes committed code on the default branch; local working trees add your current branch. Its relationships are name- and pattern-based, not compiler-accurate.

Related

• Explore cloud infrastructure
• Review security and exposure
• Monitor service health
• Refactor or upgrade safely
• Delegate approved work
• Make engineering decisions
• Where AI engineering gets stuck
• Connect a cloud account (Vörr)
• Explore your cloud architecture (Vörr)
• Ask Vörr
• Roles and permissions (Vörr)
• Code Graph (CodeZero)
• Execution modes (CodeZero)