Explore cloud infrastructure

Use caseIntermediate13 min

Most infrastructure questions sound simple: what do we run, who owns it, is it in Terraform, what breaks if it goes away. Answering them properly means reading several accounts and providers, joining relationships, and knowing which parts of the estate were actually scanned. This page covers each of those operations with Vörr from Claude or ChatGPT and CodeZero in VS Code, and what a credentialed coding agent can already do without them.

When you'd do this

You have joined a platform team, or inherited an account, and need to know what runs where before you change anything.
A maintenance window is coming up for a database, cache or queue and you need the real list of what depends on it, not the one in the wiki.
Someone asks how much of production is managed by Terraform, and which resources were created by hand.
A cleanup or ownership drive needs a list of resources with no workspace, environment or owner.
A Kubernetes cluster is running hot and you want the top CPU and memory consumers and the pods that keep restarting.
A data engineer needs to know which buckets, databases and streams a pipeline touches, and which repository builds the job that reads them.

Before you start

Vörr: your organisation is set up and at least one AWS, Google Cloud or Azure account is connected with read-only credentials, and a scan has completed. Add every account you want answers about; Vörr only knows what it has scanned.
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 cloud connections and the service map. ChatGPT needs a paid plan with Developer mode turned on.
Vörr, for Kubernetes and live health: an observability source that reports cluster metrics (Prometheus, Grafana or SigNoz) is connected.
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.
Vörr, for linking to code: your repositories are connected, with branches mapped to environments where you have them.
CodeZero: the extension is installed in VS Code and the organisation's repositories, including infrastructure-as-code and deployment-config repositories, are indexed.
Nothing here needs write access to your cloud. 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:

Operations

The operations below cover the whole activity, from finding a resource to planning a change to it. Each one names which product does each step. Most start in the assistant with Vörr and end, when something has to change, in VS Code with CodeZero.

Search the inventory

Vörr: ask for resources by type (for example EC2 instance or RDS instance), by category, region, account, tag or mapping status. Results span every connected AWS, Google Cloud and Azure account you can see.
Vörr: narrow the search with a second filter rather than asking for everything; a large account is easier to read by type and environment.
Agent: group or summarise the list, for example per account or per region, and ask for the next filter.

By category and regionUsing Vörr, list every database in eu-west-1 across all connected AWS accounts, with type, account and environment.

By tagUsing Vörr, find every resource tagged team=payments in any provider, grouped by account and resource type.

Cross-provider

Using Vörr, show me all object storage across AWS, Google Cloud and Azure, with region and whether each one is mapped to a workspace.

A good result names the account, region and type of each resource and says which accounts were searched. Check that the account you expected is in that list before treating a short result as complete.

Read one resource in detail

Vörr: open the resource and read its scanned configuration and tags, including fg: tags and your own.
Vörr: check its workspace and environment mapping, and any mapping gaps called out for it.
Vörr: list its one-hop neighbours. Each relationship carries a confidence, so you can tell a relationship read directly from configuration from one that was inferred.
Vörr: check whether it is managed by Terraform and, if so, from which module and state.

Using Vörr, describe the orders-db RDS instance: configuration, tags, workspace and environment, whether Terraform manages it, and its immediate neighbours with confidence.

Using Vörr, what is directly connected to the ingest-events Pub/Sub topic, and which of those relationships are inferred rather than read from configuration?

Low-confidence neighbours are leads, not facts. Before you act on one, check the configuration it came from in Vörr's Cloud Mapping or in the provider console.

Get an account or organisation summary

Vörr: ask for the account summary to see resource counts by category, mapping status and exposure, and the organisation summary when you run several accounts or projects. Per-type counts come with scan coverage.
Vörr: ask for the latest scan time alongside it, so you know how current the counts are.

Using Vörr, summarise the prod AWS account: resource counts by category, mapping status and exposure, the last completed scan, and how many resources still need mapping.

Using Vörr, give me an organisation-wide summary across every connected cloud account and project.

Check scan coverage before trusting a result

This is the operation that keeps every other answer honest. An empty list from a cloud API can mean nothing exists, or it can mean the scanner was denied access, was throttled, failed, or never looked at that resource type. If you cannot tell those apart, "no public buckets" or "no unmanaged databases" is a guess.

Vörr: ask for scan coverage per service for the account and region in question. Each service is reported as completed, scanned and empty, access denied, partial permission, skipped, failed or throttled.
Vörr: ask what it scans and which types it could not read, so you know what a search cannot see.
Agent: restate the original answer with its coverage, for example "zero in the services that completed; not known for the two that were denied".

Completed with results: The service was scanned and the resources listed are what exists.
Scanned, empty: The service was scanned successfully and nothing was found. This is a real zero.
Access denied: The read-only role is missing a permission for this service. The answer is unknown, not zero.
Partial permission or skipped: Some of the service was read, or it was not scanned this time. Treat the answer as partial.
Failed or throttled: The scan did not finish for this service. Re-run the scan or treat the answer as partial.
Not scanned: The resource type is outside what Vörr scans, so it will never appear in a search.

Using Vörr, before you answer: which services in the prod account completed, came back empty, were denied, had partial permission, were skipped, failed or were throttled in the last scan? Which types could you not read?

You said there are no Lambda functions in us-east-2. Is that a verified zero, or was Lambda not scanned there?

Never report a zero, in a review, a ticket or a postmortem, without the coverage behind it. An unconnected account or a denied service looks exactly like an empty one if you only read the result.

Find mapping gaps and unmapped resources

Vörr: search by mapping status to list resources with no workspace or environment, or with gaps on their mapping.
Vörr: read their tags and neighbours; a resource that sits next to the payments service and carries a payments tag usually belongs to that team.
CodeZero or Vörr: check repository owners by commit history for the code that uses the resource, to find a person to ask.
You: assign the workspace and environment in Vörr's Cloud Mapping. The assistant cannot write mappings or tags; it can only prepare the list.

Using Vörr, list resources in the prod account that need mapping, grouped by type, with their tags and their closest mapped neighbour.

For each unmapped resource you found, suggest a likely owning workspace from its tags and neighbours, and say how confident you are and why.

Treat suggested owners as a draft for a human. The useful output is a short table: resource, suggested workspace, the evidence, and who to confirm with.

Check Terraform coverage

Vörr: ask for Terraform coverage for the account: the connected state buckets, and unmanaged counts by type.
Vörr: for a single resource, read whether it is Terraform-managed and from which module and state.
CodeZero: search the indexed infrastructure repositories for the module named in the state, to find the files that define it.
Agent: for each type with unmanaged resources, look up the individual resources and separate ones that look deliberate (provider defaults, resources created by managed services) from ones that look hand-made.

Using Vörr, how much of the prod AWS account is managed by Terraform? List the connected state buckets and the unmanaged counts for databases, queues and load balancers.

Using Vörr, is the checkout-cache ElastiCache cluster Terraform-managed? If so, which module and state; if not, what else in its neighbourhood is managed?

In VS Code

Find the Terraform module that defines the orders-db RDS instance across our indexed repositories, and show the file and its last commit.

Terraform coverage is only as good as the state you have connected. Vörr reports a coverage status for each account; quote an unmanaged count only where that status is complete, and check the list of connected state buckets first.

Look at Kubernetes resource usage

Many teams run Kubernetes on a managed service such as Amazon EKS, Google GKE or Azure AKS. The steps are the same for each, because cluster usage comes from the connected metrics source rather than from the cloud provider.

Vörr: ask for top CPU and memory consumers by pod, namespace, deployment or node, from the connected metrics source.
Vörr: ask for service health on the worst offenders: pods ready, restarts, CPU and memory.
Vörr: if a restart pattern lines up with a change, ask for recent deploys of that workload.
CodeZero: open the deployment config (Helm values, manifests) that sets the requests and limits.

Using Vörr, show the top ten memory consumers by deployment in the prod EKS cluster over the last 24 hours, with pods ready and restart counts for each.

Using Vörr, which nodes in the staging GKE cluster are using the most CPU, and which namespaces are on them?

Each figure should name the source it came from. If two sources report the cluster, Vörr reports them separately instead of averaging them; a disagreement is worth reading before you resize anything.

Monitor service health

Map dependencies and blast radius before maintenance

"What depends on this database?" is a transitive question. A service reads the database; a worker reads from a queue that service writes to; a scheduled job reads a replica. Checking one hop finds the first of these and misses the rest, and a count built by hand covers only what was walked, which gets expensive on a large graph.

Vörr: ask for the upstream and downstream blast radius of the resource. It is precomputed from the scanned graph and reports true totals, and the list behind them, which may be truncated.
Vörr: read the one-hop neighbours with confidence to see how each path starts.
CodeZero: check the code side, i.e. which repositories read or write the tables in that database, and which services name it in deployment config.
Agent: merge the two into one list, marking which items came from the cloud scan and which from code.

Using Vörr, what is the full downstream blast radius of the orders-db RDS instance in prod? Give me the true totals, then list the services.

Using Vörr, if the shared-redis cluster is down for 30 minutes, what is affected upstream and downstream, and how complete was the scan for those services?

In VS Code

Which repositories read or write the orders and order_items tables, and which services reference ORDERS_DB_URL in env vars or Helm values?

A good answer gives counts, the list behind them, the confidence of each relationship, and the scan coverage that bounds the result. Anything in an account that is not connected is outside the radius by definition, so say so in the maintenance notice.

Link resources back to code

Vörr: list repositories and their branch-to-environment mapping, so a production resource can be tied to the branch that deploys it.
Vörr: read built-from relationships where the scan found them, for example a container workload or image linked to the registry or build source it came from.
CodeZero: find where the code uses the resource, i.e. connection strings and the deployment config that points to it, across indexed repositories, including ones not checked out.
CodeZero: open Graph to see which services reference it through Kubernetes, Helm or Compose config, with file:line evidence.

Using Vörr, which repository and branch deploy to the prod payments ECS service, and what image is it built from?

In VS Code

Where is the S3 bucket name for invoice exports configured? Show every Helm value and Terraform output that sets it, across all repositories.

Plan an IaC or config change in CodeZero

Vörr, in the assistant: collect the facts, i.e. the resource, its module, its dependents and the coverage, and paste the summary into CodeZero.
CodeZero: start in Planned mode. The plan names the repositories (for example the Terraform repository and the Helm charts), the phases and the verification commands, such as terraform fmt, terraform validate and terraform plan.
You: approve the plan. The agent cannot approve its own plan, it asks before editing outside the plan's repositories, and only the declared verification commands run without asking.
You: review terraform plan output and apply through your normal pipeline. Neither product applies infrastructure changes.

In VS Code

/plan Bring the hand-made checkout-cache ElastiCache cluster under Terraform in the infra repo: write the resource and an import block, match the scanned configuration below, and verify with terraform validate and terraform plan. Facts from Vörr: ...

In VS Code

/plan Raise the memory limit of the reports-worker deployment in the helm-charts repo from 512Mi to 1Gi in prod only, and list every other environment file that sets it.

Without CodeZero or Vörr

Claude Code with the aws, gcloud, az, kubectl and terraform CLIs installed and credentialed is genuinely good at this work for one account at a time. It can list and describe resources, read tags, run terraform state list in a checked-out repository, run kubectl top and describe pods, and reason well over the output. ChatGPT or Claude chat can do the same reasoning over output you paste in.

The cost is in the setup and the joins. Every provider needs its own credentials on the developer's machine, usually with more than read access. The agent queries one account or project at a time, builds relationships by matching IDs across describe calls itself, and has no record of what it did not look at.

Operation	Claude Code / ChatGPT on their own	With CodeZero and Vörr
Inventory search	Good per account with CLI calls; multi-account and multi-provider means switching profiles and merging results	Vörr searches every connected account and provider by category, type, region, tag and mapping status
Resource detail	describe calls give configuration and tags; neighbours must be joined by hand	Vörr returns configuration, tags, mapping gaps, Terraform management and one-hop neighbours with confidence
Scan coverage	An AccessDenied may surface, but an empty list or an unqueried service looks like zero	Vörr reports completed, empty, denied, partial, skipped, failed and throttled per service, and the types it could not read
Terraform coverage	terraform state list for each state it can reach; comparing against live resources is manual	Vörr lists connected state buckets and unmanaged counts by type per account; CodeZero finds the module in indexed repositories
Mapping gaps	Only if your tagging convention is consistent and the agent greps for it	Vörr searches by mapping status and shows workspace and environment gaps
Kubernetes usage	kubectl top and describe per cluster, if the context is configured	Vörr gives top consumers by pod, namespace, deployment or node and pod health from connected sources
Blast radius	Built hop by hop, which is expensive on large graphs and can stop early; counts are only what was walked	Vörr gives precomputed upstream and downstream blast radius with true counts; CodeZero adds code-side readers and writers
Link to code	Grep in cloned repositories only	CodeZero searches all indexed repositories for config and deploy settings; Vörr maps repositories to environments
Plan a change	Edits freely; no plan or approval guard	CodeZero plan with named repositories, approval and declared verification

Credentials that let an agent run describe calls often let it run delete calls too. If you use cloud CLIs from a coding agent, give it a read-only role and keep production profiles out of its environment.

With CodeZero and Vörr

One inventory across providers (Vörr): AWS, Google Cloud and Azure, scanned read-only, searchable from the assistant without credentials on your machine.
Coverage on every answer (Vörr): Per-service scan status and unindexed types, so a zero is either verified or explicitly unknown.
Relationships already joined (Vörr): One-hop neighbours with confidence and a precomputed transitive blast radius with true counts.
Ownership and IaC state (Vörr): Workspace and environment mapping with gaps, fg: and customer tags, and Terraform management per resource and per account.
Cluster usage (Vörr): Top CPU and memory consumers and pod health from connected observability sources, each figure with its source.
The code that uses it (CodeZero): Config, deployment settings, tables read and written, and Terraform modules across every indexed repository, including ones not cloned.
A safe path to change (CodeZero): A reviewed plan that names the repositories and verification commands, with no code changes until you approve it.

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

Illustrative example

Worked example: maintenance on a shared database

A platform engineer needs to take the prod orders-db RDS instance through a major-version upgrade, and wants the real dependents, the Terraform position and any coverage caveats before writing the change notice. Resource names, counts and findings below are illustrative.

Using Vörr, for orders-db in the prod AWS account: is it Terraform-managed, what is its full upstream and downstream blast radius with true counts, and how complete was the last scan for every service involved?

Illustrative example

What Vörr returned

Resource: orders-db (RDS, PostgreSQL 13) - account prod-core, eu-west-1
Workspace: commerce   Environment: production   Mapping: complete
Tags: team=orders, fg:workspace=commerce
Terraform: managed - module rds_orders, state s3://tf-state-prod/core.tfstate

Blast radius (downstream, true counts)
  ECS services       4   orders-api, checkout-api, refunds-worker, reports-worker
  Lambda functions   2   nightly-export, order-reconcile
  RDS read replicas  1   orders-db-replica-1
  Total             7

One-hop neighbours
  orders-api          high    (security group + config)
  checkout-api        high
  orders-db-replica-1 high
  reports-worker      medium  (security group only)

Scan coverage (prod-core, eu-west-1)
  ECS, RDS, Lambda   completed
  Glue               access denied
  EventBridge        throttled

Illustrative example

Checking the code side in CodeZero

The engineer asks CodeZero which repositories read or write the orders tables and which services reference the database URL. CodeZero finds the four services Vörr listed, plus a Glue job defined in the analytics repository whose Python script reads the orders tables. Glue was access denied in the scan, so Vörr could not have seen it.

ORDERS_DB_URL referenced in:
  orders-api       helm/values-prod.yaml:41
  checkout-api     deploy/prod.env:12
  refunds-worker   helm/values-prod.yaml:27
  reports-worker   helm/values-prod.yaml:19
  analytics-jobs   glue/orders_daily.py:8   (reads orders, order_items)

Illustrative example

Conclusion and follow-ups

Dependents: seven from the cloud scan plus one Glue job found in code. The notice lists eight, and states that Glue and EventBridge coverage were incomplete.
reports-worker is a medium-confidence neighbour, but its Helm values confirm it uses the database, so it stays on the list.
The upgrade is a Terraform change in module rds_orders. A CodeZero plan names the infra repository, changes the engine version and parameter group, and declares terraform validate and terraform plan as verification.
Follow-up for the account owner: grant the read-only role Glue permissions and re-run the scan, so the next blast radius includes it.

Verify and follow up

Coverage first: for any count or zero, read the per-service scan status for the accounts and regions involved, and the scan time.
Accounts: confirm every account and project that could hold a dependent is connected. Anything outside them is not in the answer.
Confidence: check medium and low-confidence relationships against configuration in Vörr's Cloud Mapping, or against the call site in CodeZero with Verify on the inferred edge.
Terraform: confirm the state bucket list matches what your team expects before quoting a managed percentage.
Kubernetes: check which source each usage figure came from, and the time window.
Changes: let the CodeZero plan's verification commands run, then read the terraform plan output yourself before anything is applied.
Next: run an exposure review on anything public, look at cost on anything idle, and assign owners to what is still unmapped.

Limits

Vörr is read-only towards your systems from the assistant. It cannot change resources, mappings or tags from chat. Opt-in fg: tag writes and consented EC2 deep inspection exist in the product but are not available to the assistant.
Answers are bounded by the connected accounts and the latest scan. Resources created since the last scan, and resource types Vörr does not scan, do not appear.
Confidence on relationships is a judgement from scanned configuration, and inferred edges can be wrong. Blast radius follows the scanned graph and does not include dependencies that exist only in code or in systems that are not connected.
Terraform coverage covers the state buckets connected through the Terraform connector. Quote unmanaged counts only for accounts whose coverage is complete.
Kubernetes usage and pod health come from connected observability sources. Without one, the assistant has no cluster metrics.
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.
Cost and security exposure have their own pages; this page does not cover savings or network exposure paths.

When you'd do this

Before you start

Operations

Search the inventory

Read one resource in detail

Get an account or organisation summary

Check scan coverage before trusting a result

Find mapping gaps and unmapped resources

Check Terraform coverage

Look at Kubernetes resource usage

Map dependencies and blast radius before maintenance

Link resources back to code

Plan an IaC or config change in CodeZero

Without CodeZero or Vörr

With CodeZero and Vörr

Worked example: maintenance on a shared database

What Vörr returned

Checking the code side in CodeZero

Conclusion and follow-ups

Verify and follow up

Limits

Related