backend / cloud aws / management and governance / README.md

AWS Auto Scaling

6 min read index source

AWS Auto Scaling

Overview

AWS Auto Scaling helps you maintain application availability and allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define.

Key Features

  • Automatic Scaling: Scale resources up or down based on demand
  • Health Checks: Automatically replace unhealthy instances
  • Multiple Scaling Policies: Target tracking, step scaling, and simple scaling
  • Integration: Works with EC2, ECS, DynamoDB, Aurora, and more
  • Cost Optimization: Scale down during low usage periods

Interview Topics

1. Auto Scaling Groups (ASG)

  • Definition: A collection of EC2 instances managed as a group
  • Components: Launch template, scaling policies, health checks
  • Lifecycle: Instance launch, health check, scaling events

2. Scaling Policies

  • Target Tracking: Scale based on target metric (CPU, memory, custom)
  • Step Scaling: Scale based on CloudWatch alarms with multiple steps
  • Simple Scaling: Scale based on single CloudWatch alarm
  • Scheduled Scaling: Scale at specific times

3. Launch Templates vs Launch Configurations

  • Launch Templates: Newer, more flexible, support multiple versions
  • Launch Configurations: Legacy, immutable, single version

4. Health Checks

  • EC2 Health Checks: Basic instance health
  • ELB Health Checks: Application-level health
  • Custom Health Checks: Application-specific health criteria

5. Scaling Triggers

  • CloudWatch Metrics: CPU, memory, network, custom metrics
  • Scheduled Actions: Time-based scaling
  • Manual Scaling: Manual adjustment of desired capacity

Common Interview Questions

Basic Questions

  1. What is AWS Auto Scaling and when would you use it?

    • Automatically adjusts capacity to maintain steady performance
    • Use for applications with variable traffic patterns
    • Ensures high availability and cost optimization

  2. What are the different types of scaling policies?

    • Target tracking: Maintain target metric value
    • Step scaling: Scale based on alarm breaches
    • Simple scaling: Scale based on single alarm
    • Scheduled scaling: Scale at predetermined times

  3. How do you create an Auto Scaling group?

    aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --launch-template LaunchTemplateId=lt-1234567890abcdef0 \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 2 \
  --vpc-zone-identifier subnet-12345678,subnet-87654321

Advanced Questions

  1. How does Auto Scaling handle instance termination?

    • Uses termination policies (OldestInstance, NewestInstance, etc.)
    • Respects AZ balance
    • Considers instance health and lifecycle hooks

  2. What are lifecycle hooks and when would you use them?

    • Pause scaling operations for custom actions
    • Use for graceful shutdown, data backup, or cleanup
    • Can be added to launch or terminate events

  3. How do you implement blue-green deployment with Auto Scaling?

    • Create new ASG with updated launch template
    • Gradually shift traffic using ALB
    • Terminate old ASG after validation

Troubleshooting Questions

  1. What if Auto Scaling isn’t scaling as expected?

    • Check CloudWatch metrics and alarms
    • Verify scaling policies and cooldown periods
    • Review instance health and termination policies
    • Check for conflicting manual scaling actions

  2. How do you handle scaling during maintenance windows?

    • Use scheduled scaling to prevent scaling during maintenance
    • Implement lifecycle hooks for graceful handling
    • Consider using instance refresh for controlled updates

Best Practices

1. Capacity Planning

  • Set appropriate min/max/desired capacity
  • Use target tracking for most scenarios
  • Monitor and adjust based on actual usage patterns

2. Health Checks

  • Use ELB health checks for application-level monitoring
  • Set appropriate health check grace period
  • Implement custom health checks for complex applications

3. Scaling Policies

  • Start with target tracking policies
  • Use step scaling for predictable traffic patterns
  • Implement proper cooldown periods

4. Cost Optimization

  • Scale down during off-peak hours
  • Use spot instances where appropriate
  • Monitor and optimize instance types

5. Monitoring and Alerting

  • Set up CloudWatch alarms for scaling events
  • Monitor scaling history and trends
  • Alert on failed scaling operations

Use Cases

1. Web Applications

  • Handle variable traffic loads
  • Ensure high availability
  • Optimize costs during low usage

2. Batch Processing

  • Scale up for large batch jobs
  • Scale down during idle periods
  • Use spot instances for cost savings

3. Microservices

  • Independent scaling per service
  • Handle service-specific load patterns
  • Maintain service isolation

Integration Patterns

1. Load Balancer Integration

  • Distribute traffic across instances
  • Health check integration
  • Session affinity configuration

2. CloudWatch Integration

  • Metric-based scaling
  • Custom metrics support
  • Comprehensive monitoring

3. Application Load Balancer (ALB)

  • Target group integration
  • Health check coordination
  • Traffic distribution

Security Considerations

1. IAM Roles

  • Use instance profiles for EC2 permissions
  • Follow principle of least privilege
  • Regularly rotate access keys

2. Network Security

  • Use security groups appropriately
  • Implement VPC best practices
  • Consider private subnets for internal services

3. Compliance

  • Ensure scaling doesn’t violate compliance requirements
  • Maintain audit trails
  • Implement proper logging

Cost Optimization

1. Instance Selection

  • Choose appropriate instance types
  • Use spot instances where possible
  • Consider reserved instances for baseline capacity

2. Scaling Optimization

  • Set appropriate scaling thresholds
  • Use predictive scaling for known patterns
  • Implement proper cooldown periods

3. Monitoring Costs

  • Track scaling costs
  • Monitor instance utilization
  • Optimize based on actual usage

Performance Optimization

1. Scaling Speed

  • Optimize launch template for fast instance startup
  • Use pre-warmed AMIs
  • Implement proper health check timeouts

2. Application Optimization

  • Optimize application startup time
  • Implement proper health check endpoints
  • Use connection pooling and caching

3. Network Optimization

  • Use placement groups for low latency
  • Optimize security group rules
  • Consider enhanced networking

Disaster Recovery

1. Multi-AZ Deployment

  • Distribute instances across AZs
  • Implement proper health checks
  • Test failover scenarios

2. Backup Strategies

  • Use lifecycle hooks for data backup
  • Implement proper data replication
  • Test recovery procedures

3. Monitoring and Alerting

  • Set up comprehensive monitoring
  • Implement proper alerting
  • Test disaster recovery procedures

Migration Strategies

1. From Manual Scaling

  • Start with conservative scaling policies
  • Gradually adjust based on monitoring
  • Maintain manual override capabilities

2. From Other Cloud Providers

  • Map existing scaling policies
  • Adapt to AWS-specific features
  • Test thoroughly before migration

3. Application Modernization

  • Implement proper health checks
  • Optimize for cloud-native patterns
  • Use modern AWS features

Common Pitfalls

1. Scaling Too Aggressively

  • Can lead to unnecessary costs
  • May cause application instability
  • Set appropriate cooldown periods

2. Ignoring Health Checks

  • Can lead to unhealthy instances
  • May cause service degradation
  • Implement proper health check endpoints

3. Not Monitoring Scaling

  • Can miss scaling issues
  • May not optimize costs
  • Set up comprehensive monitoring

Resources

Interview angle

  • “What metric do you scale on?” - the one that reflects user-visible pressure. For a web tier, request count per target or p99 latency; for a worker fleet, queue depth or age of the oldest message. CPU is a proxy that misleads for I/O-bound Python services, which sit at low CPU while fully saturated on connections.
  • “Target tracking or step scaling?” - target tracking for almost everything: you name a target value and AWS manages the rest. Step scaling when you need different responses at different breach magnitudes.
  • “Why does scaling out not help immediately?” - instance launch plus application warm-up plus health-check passes is minutes, and traffic spikes in seconds. That gap is why you keep headroom, use warm pools, or scale predictively rather than purely reactively.
  • “What is flapping and how do you stop it?” - scaling out and in repeatedly around a threshold. Cooldown periods and an asymmetric policy - scale out fast, scale in slowly - are the fix.