# AWS Auto Scaling > "Configures automatic scaling of compute resources (EC2, RDS, DynamoDB" Lambda) based on demand metrics with scaling policies and lifecycle hooks. - Skill: `paulpas/aws-auto-scaling` (Agent Skill) - Install (CLI): `npx skillmds@latest add paulpas/aws-auto-scaling` - Raw SKILL.md: https://api.skillmd.com/api/skills/paulpas/aws-auto-scaling/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: MIT - Author: paulpas (https://skillmd.com/u/paulpas) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/paulpas/aws-auto-scaling --- # Auto Scaling Configure automatic resource scaling based on demand metrics with target tracking policies, scheduled scaling, and lifecycle hooks. ## TL;DR Checklist - [ ] Use target tracking policies (CPU, ALB request count) - [ ] Set appropriate min/max capacity bounds - [ ] Implement cooldown periods to prevent thrashing - [ ] Configure lifecycle hooks for graceful shutdown - [ ] Monitor scaling activity with CloudWatch - [ ] Test scaling policies under realistic load - [ ] Use predictive scaling for recurring patterns - [ ] Implement step scaling for gradual increases - [ ] Regular capacity planning and review - [ ] Set up alarms for scaling failures --- ## When to Use Use Auto Scaling when: - Capacity needs fluctuate with demand - Building cost-optimized infrastructure - Requiring high availability with failover - Running variable workloads --- ## Purpose and Use Cases **Primary Purpose:** Automatically adjust compute capacity based on demand metrics, optimizing cost and ensuring availability. **Common Use Cases:** 1. **Web Applications** — Scale EC2 with traffic 2. **Batch Processing** — Scale on job backlog 3. **Database Replicas** — Scale read capacity 4. **API Services** — Scale on request rate --- ## Architecture Design Patterns ### Pattern 1: EC2 Auto Scaling with Target Tracking ```yaml AWSTemplateFormatVersion: '2010-09-09' Resources: # Auto Scaling Group ApplicationASG: Type: AWS::AutoScaling::AutoScalingGroup Properties: AutoScalingGroupName: app-asg LaunchTemplate: LaunchTemplateId: lt-0123456789abcdef0 Version: !GetAtt LaunchTemplate.LatestVersionNumber MinSize: 2 MaxSize: 10 DesiredCapacity: 3 VPCZoneIdentifier: - subnet-0123456789abcdef0 - subnet-0123456789abcdef1 - subnet-0123456789abcdef2 HealthCheckType: ELB HealthCheckGracePeriod: 300 TargetGroupARNs: - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/app/0123456789abcdef0 Tags: - Key: Name Value: app-instance PropagateAtLaunch: true # Target Tracking Scaling Policy CPUScalingPolicy: Type: AWS::AutoScaling::ScalingPolicy Properties: AutoScalingGroupName: !Ref ApplicationASG PolicyType: TargetTrackingScaling TargetTrackingConfiguration: PredefinedMetricSpecification: PredefinedMetricType: ASGAverageCPUUtilization TargetValue: 70 ScaleOutCooldown: 60 ScaleInCooldown: 300 # ALB Request Count Policy RequestCountPolicy: Type: AWS::AutoScaling::ScalingPolicy Properties: AutoScalingGroupName: !Ref ApplicationASG PolicyType: TargetTrackingScaling TargetTrackingConfiguration: PredefinedMetricSpecification: PredefinedMetricType: ALBRequestCountPerTarget ResourceLabel: !Sub 'app/my-load-balancer/0123456789abcdef0' TargetValue: 1000 ScaleOutCooldown: 60 ScaleInCooldown: 300 # Lifecycle Hook for Graceful Shutdown TerminationHook: Type: AWS::AutoScaling::LifecycleHook Properties: AutoScalingGroupName: !Ref ApplicationASG LifecycleTransition: autoscaling:EC2_INSTANCE_TERMINATING DefaultResult: CONTINUE HeartbeatTimeout: 300 NotificationTargetARN: !GetAtt TerminationQueue.Arn RoleARN: !GetAtt ASGRole.Arn TerminationQueue: Type: AWS::SQS::Queue Properties: VisibilityTimeout: 300 ASGRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: autoscaling.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: PublishToSNS PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - sqs:SendMessage Resource: !GetAtt TerminationQueue.Arn # CloudWatch Alarms ScalingActivityAlarm: Type: AWS::CloudWatch::Alarm Properties: AlarmName: asg-scaling-failure MetricName: GroupTerminatingInstances Namespace: AWS/AutoScaling Statistic: Sum Period: 300 EvaluationPeriods: 1 Threshold: 5 ComparisonOperator: GreaterThanThreshold Dimensions: - Name: AutoScalingGroupName Value: !Ref ApplicationASG ``` **Key Elements:** - Auto Scaling Group with min/max bounds - Target tracking for CPU utilization - Request count scaling for ALB - Lifecycle hooks for graceful shutdown - CloudWatch alarms for failures --- ## Best Practices Summary | Category | Best Practice | |---|---| | **Policies** | Target tracking (simpler than step scaling) | | **Cooldown** | Prevent thrashing with appropriate delays | | **Lifecycle** | Hooks for graceful instance termination | | **Monitoring** | CloudWatch metrics and alarms | | **Testing** | Load test scaling policies | --- ## Related Skills | Skill | Purpose | |---|---| | `cncf-aws-ec2` | Instances in Auto Scaling Group | | `cncf-aws-cloudwatch` | Scaling metrics and alarms | | `cncf-aws-elb` | Health checks and target groups | --- ## Core Workflow 1. **Assess Requirements** — Understand the use case, scale, integration needs, and existing infrastructure. **Checkpoint:** Document requirements, constraints, and success criteria. 2. **Design Architecture** — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. **Checkpoint:** Verify the architecture addresses all requirements and follows CNCF conventions. 3. **Implement & Configure** — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. **Checkpoint:** Validate all YAML against schema and test in a staging environment. 4. **Deploy & Monitor** — Apply manifests to the cluster, verify component health, and confirm observability is working. **Checkpoint:** Confirm all pods/services are running, probes passing, and metrics/alerts configured. --- ## Constraints ### MUST DO - Include at least one complete working YAML manifest example - Note when content is auto-generated vs. manually verified - Reference relevant CNCF project documentation ### MUST NOT DO - Deploy manifests without testing in a staging environment first - Use deprecated API versions (e.g., apps/v1beta1) - Omit resource limits and requests in Kubernetes manifests --- ## Live References > Authoritative documentation links for this skill's domain. The model follows markdown links at load time to resolve external references and inline content. - [Primary Documentation](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-concepts.html) - [API Reference or Getting Started](https://docs.aws.amazon.com/autoscaling/ec2/userguide/scaling-policy.html) - [Configuration Guide](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scheduled-requests.html) - [Best Practices](https://docs.aws.amazon.com/autoscaling/ec2/userguide/health-checks-asg.html) - [Common Patterns or Tutorials](https://docs.aws.amazon.com/autoscaling/ec2/userguide/plans.html)