In the world of cloud computing, most autoscaling is reactive—it waits for your CPU usage or memory to hit a threshold, then kicks in. It works, but it’s like driving with one eye on the rearview mirror… You’re constantly reacting instead of preparing. What if you could get ahead of the game and scale up before your business gets hit with traffic?
That’s where autoscaling based on business hours can really shine. If your business has predictable traffic patterns, like a team logging in at 9 AM or customers shopping online during lunch breaks, you can take control. Rather than keeping your entire infrastructure running at full speed 24/7, why not scale it down when you know traffic will be low and bring it back up when needed?
Let’s dig into how to make this magic happen with Terraform.
Why Autoscaling Based on Business Hours?
Most autoscaling solutions respond to real-time spikes in demand, but by then, your system is already working hard. Why wait for the spike when you know your business hours? Instead, you can be proactive and scale ahead of time.
For example, your dev team clocks out by 6 PM, so what’s the point of keeping all those dev servers and sandbox environments running all night? They’re just sitting there, unused, burning through your budget. With business-hours-based autoscaling, you can automatically scale down non-essential environments when they’re not in use and spin them back up the next morning, just in time for work to start.
It’s not just about cutting costs—it’s about optimizing your resources to fit your real needs.
A Real-World Example: Scaling Down Dev and Sandbox After Hours
Here’s a real-life scenario. During the day, your production environment is humming along, handling customers. Meanwhile, your dev and sandbox environments are cranking through code tests and debugging sessions. But once 6 PM rolls around? Those environments are just chilling… yet they’re still costing you, even when nobody’s using them.
Let’s take the dev environment as an example. Let’s say you’re running 50 m5.large instances, each costing around $0.096 per hour. If you leave them running 24/7, your costs stack up pretty quickly:
- 50 instances x $0.096/hour x 24 hours/day = $115.20/day
- Over a month, you’re looking at $3,456/month just for those dev instances.
Ouch, right? But if you apply autoscaling based on business hours, and only run those instances for 9 hours a day (assuming a 9 AM to 6 PM workday), the picture changes:
- 50 instances x $0.096/hour x 9 hours/day = $43.20/day
- Over a month, that’s $1,296/month.
Boom! You just saved $2,160/month by scaling down after hours. That’s serious savings for something as simple as autoscaling.
Cost Breakdown Example 2: Scaling Down Non-Essential Services
Now let’s look at your sandbox environment. Maybe you’ve got 20 c5.large instances running, each costing around $0.085 per hour. If you run them non-stop for a month:
- 20 instances x $0.085/hour x 24 hours/day = $40.80/day
- That’s $1,224/month for sandbox instances sitting around after hours.
But by applying autoscaling and scaling down outside of business hours (again, 9 hours per day), your cost drops:
- 20 instances x $0.085/hour x 9 hours/day = $15.30/day
- Over the month, that’s $459/month.
With this setup, you’re saving $765/month on your sandbox environment alone—just by being smart about when to scale up and down. Add that to your dev savings, and you’re starting to see some real impact.
How to Set It Up in Terraform
Now, let’s dive into the Terraform part. It’s easier than you think to get autoscaling based on business hours up and running.
First, define your autoscaling group. This group manages the scaling of instances based on your schedule.
resource "aws_autoscaling_group" "example_asg" {
launch_configuration = aws_launch_configuration.example_lc.id
min_size = 2
max_size = 50
desired_capacity = 10
vpc_zone_identifier = ["subnet-xxxxxxx"]
tag {
key = "Name"
value = "autoscaling-example"
propagate_at_launch = true
}
}
Next, set up the scaling schedule. In this example, we’re scaling up at 9 AM and scaling down at 6 PM.
resource "aws_autoscaling_schedule" "scale_up" {
scheduled_action_name = "scale-up-for-business"
min_size = 10
max_size = 50
desired_capacity = 10
recurrence = "0 9 * * *" # Scale up at 9 AM UTC
autoscaling_group_name = aws_autoscaling_group.example_asg.id
}
resource "aws_autoscaling_schedule" "scale_down" {
scheduled_action_name = "scale-down-after-hours"
min_size = 1
max_size = 10
desired_capacity = 1
recurrence = "0 18 * * *" # Scale down at 6 PM UTC
autoscaling_group_name = aws_autoscaling_group.example_asg.id
}
This setup handles the scaling of your instances based on your workday. You can customize this further to fit your specific business hours or extend it to other environments like production, batch jobs, or internal tools.
Why This Approach Makes Sense
Scaling based on business hours isn’t just about cutting costs (although that’s a huge win). It’s about being smart with your resources. Here’s why it’s a no-brainer:
- Cost Efficiency: You’re scaling down when resources aren’t needed, so you’re not wasting money running idle environments overnight.
- Optimized Performance: Autoscaling ensures your environments are scaled up before the rush, so you’re ready for peak traffic without scrambling.
- Proactive Approach: Instead of reacting to traffic spikes, you’re predicting and scaling based on known business patterns. It’s like setting yourself up for success.
Final Thoughts
Switching to business-hours-based autoscaling is a straightforward way to get smarter with your infrastructure. You’re no longer reacting to spikes or overpaying for resources that aren’t being used. Instead, you’re aligning your resources with your actual needs, saving money, and making sure everything is ready when your team or customers need it most.
And thanks to Terraform, it’s super easy to implement. Give it a shot, start saving those dollars, and watch as your infrastructure runs more smoothly (and affordably) than ever.