Amazon Auto Scaling: Architecting Elastic Infrastructure on AWS

Modern production workloads rarely sustain a uniform traffic profile. Demand fluctuates throughout the day, surges unpredictably during promotional events, and contracts to near-zero during off-peak hours. Amazon Auto Scaling addresses this fundamental operational challenge by dynamically adjusting compute capacity — the number of running EC2 instances — in direct response to real-time demand signals. Rather than provisioning for peak capacity and absorbing waste, or under-provisioning and risking degraded user experience, Auto Scaling maintains the precise level of infrastructure your application requires at any given moment.

When to deploy Auto Scaling: Applications exhibiting variable traffic patterns, systems requiring high availability guarantees, and architectures demanding automatic horizontal scaling all benefit from this service.

Alternatives worth evaluating: Manual vertical scaling via instance type changes, container-based auto-scaling through ECS or EKS, and serverless compute via AWS Lambda each address overlapping but distinct use cases.

Key Concepts

Essential AWS CLI Commands

aws ec2 create-image \
    --instance-id i-1234567890abcdef0 \
    --name "myapp-v1.0.0" \
    --description "Production app with dependencies" \
    --no-reboot

aws ec2 create-launch-template \
    --launch-template-name myapp-template \
    --version-description "Initial version" \
    --launch-template-data '{
        "ImageId": "ami-0abc123",
        "InstanceType": "t3.micro",
        "SecurityGroupIds": ["sg-12345"],
        "UserData": "IyEvYmluL2Jhc2g...",
        "IamInstanceProfile": {"Name": "ec2-role"},
        "KeyName": "my-keypair"
    }'

aws ec2 create-launch-template-version \
    --launch-template-id lt-0abc123 \
    --version-description "Updated to t3.small" \
    --launch-template-data '{"InstanceType": "t3.small"}'

aws elbv2 create-target-group \
    --name myapp-targets \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-12345 \
    --health-check-path /health \
    --health-check-interval-seconds 30 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 3

aws elbv2 create-load-balancer \
    --name myapp-lb \
    --subnets subnet-abc123 subnet-def456 \
    --security-groups sg-12345 \
    --scheme internet-facing \
    --type application

aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:... \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:...

aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name myapp-asg \
    --launch-template LaunchTemplateId=lt-0abc123,Version='$Latest' \
    --min-size 2 \
    --max-size 10 \
    --desired-capacity 2 \
    --target-group-arns arn:aws:elasticloadbalancing:... \
    --vpc-zone-identifier "subnet-abc,subnet-def" \
    --health-check-type ELB \
    --health-check-grace-period 300

aws autoscaling put-scaling-policy \
    --auto-scaling-group-name myapp-asg \
    --policy-name target-tracking-cpu \
    --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "ASGAverageCPUUtilization"
        },
        "TargetValue": 70.0
    }'

aws ec2 describe-images --owners self

aws ec2 describe-launch-templates

aws ec2 describe-launch-template-versions --launch-template-id lt-0abc123

aws autoscaling describe-auto-scaling-groups \
    --auto-scaling-group-names myapp-asg

aws autoscaling describe-auto-scaling-groups \
    --auto-scaling-group-names myapp-asg \
    --query 'AutoScalingGroups[0].Instances[*].[InstanceId,LifecycleState,HealthStatus,AvailabilityZone]' \
    --output table

aws autoscaling describe-scaling-activities \
    --auto-scaling-group-name myapp-asg \
    --max-records 10

aws elbv2 describe-target-health \
    --target-group-arn arn:aws:elasticloadbalancing:...

aws elbv2 describe-load-balancers

aws autoscaling update-auto-scaling-group \
    --auto-scaling-group-name myapp-asg \
    --min-size 3 \
    --max-size 15 \
    --desired-capacity 5

aws autoscaling update-auto-scaling-group \
    --auto-scaling-group-name myapp-asg \
    --launch-template LaunchTemplateId=lt-0abc123,Version='$Latest'

aws autoscaling set-desired-capacity \
    --auto-scaling-group-name myapp-asg \
    --desired-capacity 8

aws autoscaling delete-auto-scaling-group \
    --auto-scaling-group-name myapp-asg \
    --force-delete

aws elbv2 delete-load-balancer \
    --load-balancer-arn arn:aws:elasticloadbalancing:...

aws elbv2 delete-target-group \
    --target-group-arn arn:aws:elasticloadbalancing:...

aws ec2 delete-launch-template \
    --launch-template-id lt-0abc123

aws ec2 deregister-image --image-id ami-0abc123

Architecture

Complete Infrastructure Overview

Automatic Scaling Lifecycle

Health Check Verification Flow

Best Practices

Security

• Instances behind the Load Balancer: Configure security groups so instances only accept traffic from the Load Balancer, never directly from the internet
• IAM Instance Profiles: Assign IAM roles to instances rather than hardcoding credentials under any circumstance
• Secrets Management: Leverage AWS Secrets Manager or Parameter Store for sensitive variables — never embed them in user data
• Layered Security Groups: Maintain separate security groups for the Load Balancer, which accepts internet traffic, and for instances, which accept only Load Balancer traffic
• Secure Key Pairs: Rotate key pairs on a regular cadence and prefer AWS Systems Manager Session Manager over direct SSH access

Cost Optimization

• Target Tracking over Step Scaling: Target Tracking policies scale more efficiently, provisioning only what is genuinely required
• Appropriate minimum size: Avoid setting min-size higher than operational necessity demands
• Scheduled Scaling: For workloads with predictable traffic patterns, define schedules to scale capacity up and down at known intervals
• Appropriate instance types: Select free-tier-eligible instance types when applicable — t3.micro in sa-east-1, for example
• Spot Instances: Consider blending On-Demand with Spot Instances for workloads tolerant of interruption

Performance

• Multi-AZ deployment: Distribute instances across a minimum of two Availability Zones to ensure resilience
• Health check interval: A 30-second interval strikes an effective balance between responsiveness and resource consumption
• Sufficient grace period: Allow at least 5 minutes for applications with non-trivial startup sequences
• Connection draining: Ensure in-progress requests complete gracefully before the ASG terminates an instance
• Optimized AMIs: Pre-install all dependencies and application code in the AMI to minimize instance startup duration

Reliability

• Desired capacity above one: Always maintain at least two instances to guarantee fault tolerance
• ELB health check type: ELB-based health checks are substantially more reliable than EC2 health checks for web-facing applications
• Unhealthy threshold: Configure a threshold of at least three consecutive failures to tolerate transient issues without premature instance termination
• Metrics monitoring: Establish CloudWatch alarms for anomalous scaling activity and unhealthy instance counts

Operational Excellence

• Versioned Launch Templates: Create new versions rather than modifying existing templates, preserving a complete audit trail
• Consistent tagging: Apply tags to identify ASG instances by environment, project, and ownership
• Centralized logging: Route application logs to CloudWatch Logs for streamlined troubleshooting across the fleet
• Documented user data: Comment user data scripts thoroughly to support future maintenance
• AMI validation: Test AMIs in isolation before deploying them to production Auto Scaling Groups

Common Mistakes

Cost Considerations

Resource Pricing Overview

Cost Optimization Strategies

Scale with precision using Target Tracking:

--target-tracking-configuration TargetValue=70.0

Implement Scheduled Scaling for predictable workloads:

aws autoscaling put-scheduled-update-group-action \
    --auto-scaling-group-name myapp-asg \
    --scheduled-action-name scale-down-night \
    --recurrence "0 22 * * *" \
    --min-size 1 --desired-capacity 1

Eliminate unused resources aggressively: Deregister old AMIs and delete their associated snapshots. Tear down Load Balancers created for testing. Terminate development ASGs that are no longer actively used.

Leverage Reserved Instances or Savings Plans: If you maintain a predictable base load — for instance, a minimum of two instances running continuously — Reserved Instances can yield savings of up to 72%.

Free Tier Limits

Integration with Other Services

Additional Resources

Official Documentation

• Auto Scaling Groups
• Elastic Load Balancing
• Launch Templates
• AMI Management

Relevant Whitepapers

• AWS Well-Architected Framework - Reliability Pillar
• Overview of Amazon Web Services - Auto Scaling
• Best Practices for Amazon EC2

Recommended Tutorials

• AWS Tutorial: Create Auto Scaling Group
• Workshop: Building Resilient Applications
• Scaling your application on AWS