Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Bills Now Charge for Instance Scheduling
Transcript
- Lucas: So I was talking to a friend who runs the platform team at a mid-sized e-commerce company, and he told me something that made me do a double take. They cut their cloud bill by 18 percent last quarter, and it had nothing to do with renegotiating contracts or switching providers. It was literally just turning things off. Luna: Turning things off? Like, servers? That sounds almost too simple. Lucas: That's what I thought. But he walked me through it. They have about two hundred and forty instances running across development, staging, and production. A decent chunk of those—the non-production ones—only get used during business hours, maybe a few late nights when someone's testing a release. But they were running 24/7. Every night, every weekend, those instances sat there, idle, and the meter kept running. Luna: So they just… scheduled them to stop at 6 p.m. and start again at 8 a.m.? That's the whole trick? Lucas: Pretty much. They used AWS Instance Scheduler, which is a free tool that runs on a Lambda function and stops and starts instances according to a tag-based schedule. They tagged their dev instances with a schedule that says 'stop at 7 p.m. weekdays, start at 7 a.m.' and their staging instances with something similar. And the savings came from the fact that they were paying for compute that nobody was using for roughly sixty-five percent of the week. Luna: Let me do the math. If you're paying for 24/7 and you cut down to maybe 12 hours a day on weekdays, that's like 45 percent of the week. So you're saving over half the compute cost for those instances. Lucas: Exactly. And when you multiply that by the number of non-production instances, the number gets big fast. In their case, the 18 percent total savings was because they didn't touch production—that stays up 24/7 for obvious reasons. But dev and staging, that's where the waste lives. And it's not just compute. You're also paying for the attached storage, the networking, the licensing, sometimes the support fees. All of it scales down when the instance is off. Luna: So why don't more companies do this? Is there a catch? Lucas: There are a few catches. The first is cultural. Teams forget they have instances running, or they're worried about the startup time. If it takes five minutes to boot up a dev environment, and someone needs it at 9:15, they're going to be annoyed if it's not already running. But that's what tagging and schedules are for—you can have exceptions. You can say, 'this instance stays on because it's part of a demo environment that needs to be available always.' Luna: Right, so it's not a blanket policy. It's about understanding your usage patterns and being deliberate. Lucas: And that's the second catch: you have to actually look at your usage data. Most cloud providers give you detailed metrics on instance utilization. If you haven't looked at those, you're flying blind. My friend told me they found instances that had less than one percent CPU usage over a month. One percent. And they were paying full price for that. Luna: One percent is almost offensive. It's like paying rent on an apartment you never set foot in. Lucas: Exactly. And the thing is, the tools to do this are built into the major clouds now. AWS has Instance Scheduler, Azure has Automation accounts with start/stop runbooks, Google Cloud has its own scheduling capabilities. You don't need a third-party product. You just need to spend an afternoon tagging your resources and writing a simple schedule. Luna: But I imagine the savings are even bigger for companies that have a lot of batch jobs or CI/CD pipelines that run overnight. Those could be scheduled to run only when needed. Lucas: Absolutely. And that's where it gets interesting. You can go beyond simple on/off schedules and use things like auto-scaling or spot instances for non-critical workloads. But the low-hanging fruit, the thing that gets you the first 10 to 20 percent savings, is just turning off the stuff that's idle. And honestly, if today was worth a coffee to you, that's the link—buy me a coffee dot com slash fexingo. It's a small gesture, but it helps keep these conversations ad-free and coming to you every day. Luna: Yeah, and if you've ever saved a team from a surprise cloud bill, you know the value of a little foresight. We appreciate it. Lucas: So back to that e-commerce company. The real kicker is that they didn't even touch their production environment. That's sacrosanct, obviously. But they also didn't get any pushback from developers once they showed them the numbers. Because nobody likes wasting money, even if it's not their budget directly. Luna: So what's the actual process? Do you just flip a switch and hope nothing breaks? Lucas: No, you ease into it. You start with a few low-risk instances, you monitor them for a week, you check that the startup works, that the data is consistent, that any scheduled jobs still run. Then you expand. And you have to be careful about databases—if you have a database instance that's also scheduled off, you need to make sure it's properly shut down and that connections are drained, otherwise you'll have corruption issues. Luna: That's a good point. There's a difference between shutting down a stateless app server and a stateful database. The latter needs more caution. Lucas: Exactly. And that's why the first wave of savings usually comes from stateless compute—web servers, application servers, worker nodes. Those can be shut down and restarted with almost no risk. The stateful stuff, like databases and caches, that's where you need to be more deliberate. But even then, you can schedule a read replica to be off during off-hours if you don't need it for reporting until the morning. Luna: So the potential is huge, but the execution requires some thought. What about the people side? How do you get developers to buy in? Lucas: You show them the invoice. Once they see that a single idle instance costs, say, three hundred dollars a month, and you have forty of them, they get it. Also, you make it easy for them to override the schedule when they need to. Give them a simple way to start an instance on demand, and they won't feel like they're losing control. Luna: And the tools are getting smarter too. I've seen some new scheduling features that use machine learning to predict usage patterns and automatically adjust the on/off times. That's the next level. Lucas: Right, but you don't need the fancy stuff to get started. The basic schedule is enough to unlock real savings. And as we approach the end of Q3, a lot of teams are looking at their cloud budgets and wondering where they went. This is a quick win you can implement in a week. Luna: So what's the one thing you'd tell a listener to do tomorrow at work? Lucas: Go into your cloud console and look at your list of instances. Sort by usage. If you find any that have been idle for more than ninety percent of the last month, and they're not production-critical, tag them with a schedule that shuts them down at night. That's your first step. You'll be surprised how fast it adds up. Luna: And there's a whole ecosystem of FinOps tools that can help track all this, but honestly, a spreadsheet and a few tags can get you most of the way. Lucas: Absolutely. And the best part is, this isn't a one-time thing. Once you have the schedule in place, it keeps saving you money every month without any extra effort. It's the gift that keeps giving, as long as your teams don't start creating new instances without tagging them properly. Luna: That's a common pitfall—shadow IT spinning up resources and forgetting to tag them. So you need a governance policy around tagging, not just the schedule itself. Lucas: Right. And some cloud providers have a feature that automatically terminates instances that don't have a schedule tag after a grace period. That's a nice enforcement mechanism if you want to go that far. Luna: I've also heard that some companies are using this as a way to cut their carbon footprint, not just their costs. Turning off idle servers reduces energy consumption. Lucas: That's a nice co-benefit. And it's a good talking point if you need to convince a sustainability-minded executive to give it a green light. So to wrap it up, instance scheduling is one of the simplest, most effective ways to slash your cloud bill without touching performance or availability. It's not glamorous, but it works. Luna: And it's a perfect example of how the cloud bills now—you pay for what you use, but you also pay for what you don't use if you're not careful. So be careful. Lucas: I think that's a good note to end on. If you want to share your own cloud cost win or a horror story, we're all ears. And as always, we'll see you tomorrow.