The Hidden Cost of Zombie Infrastructure: How Federal Agencies Find and Remove Idle Cloud Resources
Idle and orphaned cloud resources rarely show up on a dashboard. They show up in the billing data. Here is how a read-only forensic audit finds them across AWS, Azure, and Google Cloud, proves each one with evidence, and keeps them from coming back.

Zombie infrastructure is cloud capacity that keeps billing after its purpose is gone: a volume detached from an instance terminated last year, a snapshot chain nobody restores from, a test environment that outlived its project. It rarely trips an alert because nothing is broken. It shows up only in the billing data, one small line at a time.
Finding it reliably is a data problem before it is an engineering problem. The approach below is how a read-only forensic audit works through 12 to 24 months of billing and inventory data, turns suspicion into evidence, and hands the agency a list it can act on without risking a mission system.
Start From the Bill, Not the Console
Consoles show what exists now. Billing data shows what has been paid for, by resource, by hour, over time, which is what a waste finding has to rest on. The audit ingests each provider's native detail:
| Platform | Source | What it contains |
|---|---|---|
| AWS | Cost and Usage Report (CUR 2.0) | Line items by resource ID, usage type, pricing model, and tags |
| Azure | Cost Management exports | Actual and amortized cost by resource, meter, and tag |
| Google Cloud | Cloud Billing export to BigQuery | Cost and usage by SKU, project, and label |
Each source is normalized to FOCUS, the FinOps Foundation's open cost and usage specification (opens in a new tab). The payoff is practical: one query library can run across all three providers, and a finding means the same thing on each. The normalized data is then reconciled against reseller or vehicle invoices, because the bill the agency pays is not always the bill the provider generated.
Access is read-only. On AWS that means billing and read-only roles; on Azure, Cost Management Reader plus Reader; on Google Cloud, Billing Account Viewer plus viewer roles on the projects. No write permission is requested, and nothing changes in the environment during the audit.
The Waste Categories, and How Each Is Found
Orphaned storage. Block volumes with no attachment, and snapshots whose source volume no longer exists. The query joins volume inventory to attachment state and creation date, then prices each item from the billing line. Age matters. A volume detached last week may be mid-migration, while one detached for 11 months is almost always forgotten.
Unassociated addresses and idle load balancers. Public IP addresses billed while unattached, and load balancers with no healthy targets or negligible request counts over the review period. These are small individually and numerous in aggregate.
Oversized compute. Instances whose CPU and memory never approach their provisioned size across the whole period, not a single quiet week. The finding includes the proposed size and the monthly difference. Memory metrics often require an agent that is not installed. When the data is missing, the finding says so rather than guessing.
Always-on non-production. Development and test environments that run 168 hours a week when their teams work about 50. The evidence is the hourly usage pattern plus the owner's confirmation that nights and weekends are not needed.
Rate gaps. Workloads that have run steadily for months on on-demand pricing, and Reserved Instances or Savings Plans with low utilization or near expiry. This category costs nothing to fix technically; it is a purchasing decision, sized to appropriated funding. Commitments that run past the current appropriation or into unexercised option years need the contracting officer and budget office in the decision, not just the cloud team.
Storage placement. Objects untouched for a year sitting in the highest-cost tier. Access logs or last-access metadata support the finding, and lifecycle rules fix it.
Billing errors. Reseller markup above contract terms, missing credits, duplicate charges, and applicable GSA OneGov pricing the agency has not opted into. This workstream needs the contract documents, not just the data.
Separating Waste From Headroom
Not every underused resource is waste. Federal systems carry capacity for reasons a utilization chart cannot see: surge periods such as open enrollment or tax season, disaster recovery targets, and failover capacity held for a mission system that must not go down. An audit that treats all of it as waste produces findings the agency will reject, and loses credibility for the ones that are real.
Three checks keep the analysis honest:
- Look at the whole period. Twelve to 24 months of data catches seasonal peaks that a 30-day view misses.
- Read the architecture. Standby and recovery resources are identified from how the system is built, not from their load.
- Ask before classifying. Anything that looks deliberate goes to the owner as a question, not a finding.
The result is a shorter list than a tool would generate, and a far higher share of it gets acted on.
Evidence Before Recommendations
Every finding lands in an Evidence Workbook with the same fields:
- The resource ID and account or subscription
- The monthly cost from the billing data
- The evidence behind the classification (attachment state, utilization series, access history)
- The proposed action and the expected monthly reduction
- The owner
Then the audit does something a tool report cannot. It walks each terminate or rightsize recommendation through with the engineers who own the resource. Some findings are withdrawn at this step: a "zombie" volume turns out to be a quarterly restore target, or an idle instance is a warm standby for a mission system. That is the point. A finding that survives the owner's review is one the agency can act on without a second investigation, and one a budget office can defend.
Security Findings Come Along for Free
Read-only inventory access sees more than cost. Along the way, the audit notes what it cannot help seeing:
- Wildcard IAM permissions on roles nobody has reviewed
- Storage buckets with public access enabled
- Unencrypted EBS volumes and managed disks
- Security groups open to 0.0.0.0/0 on SSH or RDP
These go into a separate appendix. They are not remediated in the audit, and they are not framed as compliance findings. They are handed to the security team, because an account nobody owns for cost purposes usually has nobody watching it for security either. The same pattern drives unreviewed cloud infrastructure findings in CMMC assessments (opens in a new tab) on the contractor side.
Allocation Is the Upstream Fix
Most zombie infrastructure exists because nobody owned it. The allocation workstream measures how much of today's spend can be attributed to a program or system. Many environments start well under half.
It then defines the standard that closes the gap:
- A small, required tag set: program, system, environment, owner, and funding line
- An account or subscription structure that makes ownership obvious
- A target of 95% or more of spend attributable
Standards fail without enforcement, so the ongoing program writes them as code:
- AWS: service control policies and tag policies that reject untagged resource creation in governed accounts
- Azure: Azure Policy with deny or modify effects on missing tags
- Detection: Cloud Custodian rules that report resources out of policy, stop idle non-production instances on a schedule, and flag detached volumes past an age threshold for review
Scheduled shutdown is where policy-as-code pays for itself fastest. Stopping non-production compute outside working hours removes about two-thirds of its runtime without touching an application.
What the Agency Receives
The audit delivers four artifacts:
| Deliverable | Contents |
|---|---|
| Findings Report | Recoverable savings ranked by dollar value, effort, and mission risk |
| Evidence Workbook | Resource-level detail behind every finding |
| Remediation Roadmap | A 30, 60, and 90-day sequence with owners and expected realization dates |
| Executive Briefing | Baseline, recoverable total, top ten actions, and decisions needed |
Remediation itself is outside the audit. Terminating resources, resizing instances, and changing commitments are the agency's decisions and the agency's changes, made through its own change control. The roadmap is written so a cloud operations team can execute it item by item. Each action carries a realization date, so the savings can be tracked monthly against a locked baseline.
How Long It Takes
A single platform with annual spend under about $10M typically takes six to eight weeks. Each additional platform adds about two weeks, and so does a reseller or enterprise agreement that needs deep contract review. The schedule runs from the day read-only access is granted, not from contract award. Federal account provisioning and security approval routinely take two to six weeks on their own.
The scale driver is the number of payer accounts and subscriptions, not the size of the agency. One consolidated AWS payer is a faster audit than 40 unlinked Azure subscriptions. The same method runs at contractor scale too, where idle cloud infrastructure eats directly into contract margin (opens in a new tab).
Avalon's FinOps engagement delivers this as a fixed-fee Forensic Cloud Audit using native billing data, FOCUS normalization, and read-only access. Its first technical deliverable is the Evidence Workbook: every idle, orphaned, and oversized resource in your environment, priced, sourced, and validated with the engineers who own it.