Scheduled Scaling: Predictable Autoscaling on Schedule

Scheduled Scaling: Predictable Autoscaling on Schedule

Your application's load spikes every Monday at 9 AM sharp. Reactive autoscaling takes 5–10 minutes to respond, causing degraded performance during those critical minutes. We solve this with Scheduled Scaling: capacity is provisioned 10–15 minutes before the expected event, not after. This is standard for workloads with predictable patterns—business SaaS, marketing campaigns, nightly ETL jobs. We implement turnkey Scheduled Scaling with Terraform code, monitoring, and documentation. According to AWS, properly configured schedules can reduce instance costs by up to 40%.

Why Reactive Scaling Fails for Predictable Peaks

Reactive scaling—responding to metric growth—has inherent latency. The metric rises, an alarm triggers, the new instance launches and passes health checks: 5–10 minutes in total. For a spike that occurs every Monday at 9:00, this delay is unacceptable. When you know load will triple at a specific time, it's far better to increase capacity in advance—at 8:45. We guarantee that Scheduled Scaling eliminates this problem: instances are ready for the peak, not chasing it.

How We Configure Scheduled Scaling: A Real Case Study

Our best practice is to define all scheduled actions as code using Terraform. Here's a real example for an e-commerce platform facing predictable daily traffic:

# Morning scale-out: prepare for office hours
resource "aws_autoscaling_schedule" "scale_out_morning" {
  scheduled_action_name = "scale-out-morning"
  autoscaling_group_name = aws_autoscaling_group.app.name
  recurrence = "45 6 * * MON-FRI" # 8:45 MSK (UTC+3) = 06:45 UTC
  min_size = 4
  max_size = 20
  desired_capacity = 6
}

# Evening scale-in: reduce after work hours
resource "aws_autoscaling_schedule" "scale_in_evening" {
  scheduled_action_name = "scale-in-evening"
  autoscaling_group_name = aws_autoscaling_group.app.name
  recurrence = "0 18 * * MON-FRI" # 20:00 MSK
  min_size = 1
  max_size = 20
  desired_capacity = 2
}

# Night batch: extra workers for ETL
resource "aws_autoscaling_schedule" "batch_start" {
  scheduled_action_name = "batch-workers-start"
  autoscaling_group_name = aws_autoscaling_group.workers.name
  recurrence = "55 1 * * *" # 01:55 UTC
  desired_capacity = 10
}

resource "aws_autoscaling_schedule" "batch_end" {
  scheduled_action_name = "batch-workers-end"
  autoscaling_group_name = aws_autoscaling_group.workers.name
  recurrence = "0 5 * * *" # 05:00 UTC
  desired_capacity = 0
  min_size = 0
}

A common pitfall: AWS cron uses UTC. We carefully convert time zones and add comments with local time. For Belarus/Russia (UTC+3): work start at 9:00 MSK = 6:00 UTC.

On one project—a SaaS platform serving 500+ businesses—we reduced instance costs by 35% while eliminating morning latency. By scheduling capacity 15 minutes early, the application handled the 9:00 spike seamlessly.

What's Included: Deliverables

As part of this service, we provide:

• Infrastructure code (Terraform/CloudFormation) in your repository
• CI/CD integration (GitLab CI / GitHub Actions) for deploying changes
• Monitoring of scheduled actions via CloudWatch with dashboards and alerts
• Runbook with instructions for modifying schedules
• Team training: 2–4 hour workshop session
• 30-day support warranty after deployment

Scheduled Scaling vs Reactive Scaling

Scheduled Scaling is about 5 times more effective for recurring patterns when considering the trade-off between idle capacity (underutilization) and overpaying for extra instances.

What About One-Time Events?

For marketing campaigns, sales events, or feature launches, we use scheduled actions with a specific date (not recurrence). Example for Black Friday:

resource "aws_autoscaling_schedule" "black_friday" {
  scheduled_action_name = "black-friday-scale-out"
  autoscaling_group_name = aws_autoscaling_group.app.name
  start_time = "2024-11-29T08:00:00Z"
  end_time = "2024-11-29T22:00:00Z"
  min_size = 10
  desired_capacity = 20
}

After end_time, the ASG reverts to previous settings—convenient, no manual rollback needed.

How Scheduled Scaling Works for ECS and DynamoDB

Application Auto Scaling covers ECS Services, DynamoDB tables, Aurora replicas, and Lambda provisioned concurrency. For ECS:

resource "aws_appautoscaling_scheduled_action" "ecs_scale_out" {
  name               = "scale-out-morning"
  service_namespace  = "ecs"
  resource_id        = "service/my-cluster/my-service"
  scalable_dimension = "ecs:service:DesiredCount"
  schedule           = "cron(45 6 ? * MON-FRI *)"

  scalable_target_action {
    min_capacity = 4
    max_capacity = 20
  }
}

With DynamoDB, this is critical: if a planned batch starts writing to a table with normal read/write capacity, you'll get ProvisionedThroughputExceededException. Scheduled actions raise capacity in advance, ensuring smooth batch processing.

Comparison of Cloud Provider Capabilities

All three support cron-based schedules, but AWS offers the richest API via Application Auto Scaling.

Monitoring and Adjustments

After initial setup, we verify in CloudWatch that instances appear 10–15 minutes before the predicted peak. We monitor GroupDesiredCapacity and GroupInServiceInstances over time. If the application has a warm-up period (JVM, cache), we shift the scheduled action earlier.

Quarterly, we audit the schedule: load patterns change, new markets appear with different time zones, batch times shift. We update Scheduled Scaling along with business realities.

Timeline

Basic setup for one ASG or ECS service takes 1 day. Comprehensive setup for multiple services with different schedules, one-time events, and monitoring—1–2 days. Pricing is tailored after evaluating your project.

Get expert advice: contact us—we'll help find the optimal solution for your infrastructure. Request Scheduled Scaling setup and reduce instance costs by up to 40%. With over 8 years in DevOps and 50+ cloud automation projects, we deliver reliable results.