Auto Scaling Groups — How They Work
Fast recall
Quick revision
Core answer
Understanding of horizontal scaling, health checks, and capacity management
Scaling too aggressively on CPU without considering JVM warm-up time — new instances may show high CPU briefly during JIT compilation
Explain scale-in protection to prevent terminating instances that are mid-request, and target tracking vs step scaling policies
Interview-ready guide
Interview answer
Auto Scaling Groups maintain a fleet of EC2 instances or ECS tasks between a minimum and maximum count, replacing unhealthy instances and adjusting capacity in response to load — which means the fleet self-heals and grows or shrinks automatically.
How scaling works
- An ASG scales out (adds instances) when a CloudWatch metric crosses a threshold — CPU > 70%, request count per instance above a target — and scales in (removes instances) when load drops
- Target tracking scaling is the simplest policy: set a target metric value like
CPUUtilization = 50%and the ASG adjusts the instance count to keep the metric near the target — you don't write scale-in/scale-out rules separately - Scheduled scaling pre-warms capacity for known traffic patterns — add 20 instances at 8am on weekdays, remove them at 8pm — which is more reliable than reactive scaling for predictable load
Health checks and self-healing
- ASG performs EC2 health checks (is the instance running?) and optionally ELB health checks (is the application responding to HTTP health checks?)
- An instance that fails the health check is terminated and replaced automatically — which means a JVM crash or OOM that kills the process results in a new instance starting with no manual intervention
- Configure the ELB health check to call
/actuator/healthwith a timeout that gives Spring Boot enough time to initialize before failing
Warm-up period — the Spring Boot cold start problem
- New EC2 instances need time to bootstrap the OS, start the JVM, and initialize Spring's ApplicationContext before serving traffic — configure the instance warm-up period to match your application's startup time
- Without a warm-up period, the ASG counts the new instance's metrics immediately, causing premature scale-in or misleading averages during startup
ECS Auto Scaling — ECS services have their own Application Auto Scaling separate from ASGs; the pattern is the same (target tracking on CPU or a custom metric) but operates at the task level, not the instance level.
Auto Scaling Groups — How They Work
Direct Answer
An Auto Scaling Group (ASG) maintains a fleet of EC2 instances or ECS tasks between a minimum and maximum count. It replaces unhealthy instances automatically and scales in/out based on CloudWatch metrics or scheduled actions. For Spring Boot on ECS, ECS Service Auto Scaling provides the same capability at the task level without managing EC2 directly.
Common Mistakes & Pitfalls
Scaling too aggressively on CPU without considering JVM warm-up time — new instances may show high CPU briefly during JIT compilation
Check your understanding
Answer these without looking back at the article.
- How do you prevent Auto Scaling from terminating an instance that is processing a long-running job?
- What is scheduled scaling and when would you use it for a Spring Boot application?
- How does ALB request routing interact with ECS service auto scaling during a scale-out event?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.