Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Penalize Idle Compute with Zombie Fees
Transcript
- Lucas: So there's a new term showing up in cloud contracts that I think catches a lot of teams off guard: zombie fees. Luna: Zombie fees. That sounds like something from a horror movie, not an AWS invoice. Lucas: Right, but it's very real. Starting April of this year, AWS introduced a charge for idle resources that aren't properly deprovisioned. They call it the Idle Resource Charge, but everyone in FinOps circles just calls it the zombie fee. Luna: What counts as idle? An EC2 instance that's stopped? An unattached EBS volume? Lucas: Exactly. The policy targets resources that have been sitting untouched for more than 30 days. So a stopped instance still incurs storage cost for the root volume, plus the elastic IP if you're holding it. And an unattached gp3 volume that you forgot to delete? That's the classic zombie. Luna: I've seen those. I bet a lot of teams have a graveyard of old volumes from decommissioned projects. Lucas: Absolutely. And the fee is calculated based on a daily snapshot of your resource state. So if you have a stopped instance for 31 days, on day 31 you get charged an extra 10 percent on top of the base storage cost. It's not huge per unit, but it scales fast. Luna: What's the justification from AWS's side? They're already charging for the storage. Lucas: Their argument is operational overhead. Every unused resource still takes up capacity in their control plane, they have to run monitoring on it, and it fragments the inventory. They want to discourage hoarding. And honestly, it aligns with sustainability goals — idle compute is wasted energy. Luna: But from a customer perspective, it feels like nickel and diming. You're already paying for storage, now you get fined for not cleaning up fast enough. Lucas: I get that. But I talked to a FinOps lead at a mid-size SaaS company — they had $47,000 in zombie fees over three months because a developer left a test cluster running in a stopped state. The fee actually got their attention. Before that, nobody was auditing idle resources. Luna: Forty-seven thousand dollars. That's real money. Lucas: Yeah. And what's interesting is that Azure and Google Cloud are watching this closely. Azure already has a similar policy for unattached managed disks — they call it 'idle disk surcharge' — but it's not as aggressive. GCP hasn't announced anything formal, but they're running beta tests on lifecycle warnings. Luna: So this is becoming an industry norm. What can teams do to avoid the fees? Lucas: First, automated lifecycle policies. Use tools like AWS Instance Scheduler or custom Lambda functions to automatically stop or delete resources after a set period. Second, tagging audits. Tag every resource with an owner and an expiration date. If a resource has no tag, flag it for review. Luna: And monitoring. You need to be able to see which resources have been idle for 25 days before you hit the 30 day threshold. Lucas: Exactly. CloudWatch can alert on stopped instance age. Or there are third-party FinOps platforms like CloudHealth or Vantage that track idle resources in a dashboard. The key is to have a process before the fee kicks in. Luna: I think this is part of a broader shift. Providers are getting more aggressive about cost accountability as cloud spend matures. Lucas: Absolutely. The era of 'just spin up resources and forget about them' is ending. Zombie fees are one mechanism. We've also seen data egress penalties, carbon inefficiency fines, and now idle resource charges. Luna: It seems like the contract language is getting more prescriptive. Which forces better practices, but also adds complexity to the negotiation. Lucas: Right. And if you're negotiating a new enterprise agreement, you should ask about any pending idle resource policies. Ask for a grace period or a waiver for certain development environments. Some providers will give you an exception if you have a documented lifecycle policy. Luna: That's a good tip. So the zombie fee isn't inevitable — you can manage around it. Lucas: Exactly. But you need to be intentional. And I think that's actually the hidden value: it forces teams to clean up their cloud estate. That $47,000 company ended up saving more than that in avoided storage costs once they implemented automated cleanup. Luna: So the fee becomes a catalyst for better hygiene. But it stings when you first get the bill. Lucas: No question. If today's breakdown of zombie fees was useful for what you're running — whether you're a cloud architect or a finance lead trying to understand your next invoice — this kind of practical content is why we keep the show ad-free. Listener support is what makes that possible. If it's helped you, you can buy me a coffee at buy me a coffee dot com slash fexingo. Totally optional, but it keeps the conversation going without ads. Luna: Yeah, I think that's a fair ask. We dig into the details so you don't have to dig through contract fine print yourself. So if that's valuable, great. Lucas: Alright, back to the mechanics. One thing I want to highlight is how the fee is actually calculated. AWS takes a daily snapshot of your stopped instances and unattached volumes. They compute the age of each resource, and if any resource is older than 30 days, they apply a surcharge of 10 percent on the underlying storage cost per day, starting from day 31. Luna: So it's retroactive in a sense. If you clean up on day 35, you still pay the surcharge for days 31 through 35. Lucas: Correct. And there's no retroactive refund if you delete it. So the incentive is to catch it before day 30. That's why monitoring is crucial. Luna: What about resources that are intentionally idle for long periods? Like a development environment that's only used every other month? Lucas: Great question. You can use an instance schedule to start and stop it on specific days. But if it stays stopped for 30 contiguous days, the fee kicks in. So you might need to start it briefly to reset the clock. Or better, use a 'scheduled start-stop' solution that ensures it's never stopped for 30 consecutive days. Luna: That feels like gaming the system, but it's within the rules. Lucas: It's edge-case management. The policy is designed to catch genuinely abandoned resources. If you have a good reason for keeping something idle, you can design around it. Luna: I also wonder about the impact on smaller teams. A startup might not have a dedicated FinOps person. Lucas: That's a real concern. For small teams, the zombie fee can be a nasty surprise. But the good news is that most providers offer free tools. AWS Trusted Advisor has a 'idle instances' check, and there's a cost optimization dashboard in the console. You don't need a dedicated person — you just need to set up a weekly alert. Luna: Alright, so the takeaway: know your idle resources, automate cleanup, and check your contracts for zombie fee language. Anything else? Lucas: One more thing: if you're a large enterprise, you can negotiate the threshold. Instead of 30 days, ask for 45 or 60. Some providers are flexible if you commit to certain volumes. But for most teams, the standard 30-day window is manageable with basic hygiene. Luna: Good to know. So the zombie fee is here to stay, but it's not the end of the world — it's just a nudge to be more disciplined. Lucas: Exactly. And that discipline pays off in more ways than avoiding the fee. You'll save on base storage costs, reduce security risk from forgotten resources, and lower your carbon footprint. The zombie fee is just the tip of the iceberg.