Purpose of This Lesson

AWS Auto Scaling is a family of capabilities that automatically adjusts AWS resources to match demand, replace failed resources, or follow a planned schedule. This lesson focuses primarily on Amazon EC2 Auto Scaling, while also identifying how scaling applies to Spot Fleets, Amazon ECS, DynamoDB, and Amazon Aurora.

For the AWS Certified CloudOps Engineer Associate assessment, the key skill is recognizing which Auto Scaling feature or policy fits a scenario and understanding the operational consequences of each choice.

Key Concepts

AWS Auto Scaling Across Services

AWS Auto Scaling can adjust different types of resources:

• EC2 Auto Scaling: Launches or terminates EC2 instances automatically.
• EC2 Spot Fleet: Adjusts Spot capacity when using the Spot pricing model.
• Amazon ECS: Adjusts the desired count of tasks in an ECS service.
• Amazon DynamoDB: Automatically changes provisioned read capacity units and write capacity units.
• Amazon Aurora: Automatically launches or terminates read replicas to handle read traffic.

The scaling mechanism depends on the service. EC2 Auto Scaling changes the number of instances, ECS changes the desired task count, DynamoDB changes capacity units, and Aurora changes the number of read replicas.

EC2 Auto Scaling Groups

An Auto Scaling group (ASG) is a managed collection of EC2 instances that are scaled together. An ASG defines:

• Minimum, desired, and maximum group size
• The configuration used to launch instances
• VPC and subnet placement
• Optional load balancer integration
• EC2 and Elastic Load Balancing health checks
• Scaling policies
• Purchase options such as On-Demand or Spot instances

The desired capacity represents how many instances the group should normally maintain. The ASG can launch or terminate instances to move the group toward the desired capacity or to respond to scaling policies.

CloudWatch and Auto Scaling

CloudWatch provides the monitoring information that Auto Scaling uses. Metrics can indicate resource utilization, such as aggregate CPU usage, while EC2 status checks and Elastic Load Balancing health checks can indicate that an instance is unhealthy.

For example:

1. An instance fails EC2 status checks.
2. The failure is reported to CloudWatch and Auto Scaling.
3. The ASG terminates or replaces the unhealthy instance.
4. A replacement instance is launched to maintain capacity.

For demand-based scaling, a CloudWatch alarm can detect a threshold breach, such as average CPU utilization exceeding a configured target. Auto Scaling then launches additional instances. When demand decreases, the group can scale in by terminating instances, reducing cost.

This is horizontal scaling: capacity is increased or decreased by adding or removing instances rather than by changing the size of an existing instance.

EC2 Auto Scaling Configuration and Behavior

Launch Templates and Launch Configurations

A launch template defines the configuration for new EC2 instances launched by an ASG. Relevant settings include:

• Amazon Machine Image (AMI)
• Instance type
• EBS volumes
• Security groups
• Key pair
• Network configuration
• Other instance launch settings

A launch configuration is an older construct with fewer options. Launch templates are generally preferred, although both constructs are available in the context covered by this lesson. When analyzing a configuration scenario, identify the launch template as the more capable and current choice.

Health Checks

An ASG can use two main health-check sources:

EC2 Health Checks

These use EC2 status checks. If an instance fails its status checks, Auto Scaling can identify it as unhealthy and replace it.

Elastic Load Balancing Health Checks

When ELB health checks are enabled for the ASG, Auto Scaling also uses the health status reported by the load balancer. If a target is unhealthy, the load balancer removes it from service and Auto Scaling can terminate and replace the corresponding instance.

ELB health checks are in addition to, not a replacement for, EC2 status checks.

Health Check Grace Period

The health check grace period is the time Auto Scaling waits after launching an instance before acting on health-check results. It should reflect the time required for the application to initialize and become ready.

A grace period prevents Auto Scaling from replacing a newly launched instance merely because its application port is not available during startup. A period that is too short can cause premature replacement and unstable scaling behavior.

Scaling Modes

• Dynamic scaling: Adjusts capacity in response to current demand or metrics.
• Predictive scaling: Uses machine learning to anticipate future demand.
• Scheduled scaling: Changes capacity at times defined by a schedule.

Scheduled scaling is useful when demand follows a known timetable. Dynamic scaling reacts to observed conditions, while predictive scaling attempts to anticipate future conditions.

Scaling Policies

Target Tracking Scaling

Target tracking maintains a CloudWatch metric near a target value. For example, a policy may attempt to keep aggregate CPU utilization around 70%.

• If utilization rises above the target, the ASG launches instances.
• If utilization falls below the target, the ASG can terminate instances.

Choose target tracking when the operational goal is to maintain a metric near a known target rather than manually define different adjustments for different alarm levels.

Step Scaling

Step scaling uses multiple step adjustments. The number of instances added or removed depends on how far the CloudWatch alarm metric breaches its threshold.

A small breach can produce a smaller capacity adjustment, while a large breach can produce a larger adjustment. This is useful when the response should be proportional to the severity of the metric breach.

Simple Scaling

Simple scaling changes capacity using a single scaling adjustment. It is less flexible than step scaling and target tracking.

Simple scaling uses a cooldown period to prevent another launch or termination from occurring before the effects of the previous activity are visible. The lecture identifies five minutes as the default cooldown value. The purpose is to reduce erratic behavior caused by making decisions before the group has stabilized.

Operational Controls

Termination Policies

A termination policy controls which instances are selected first during a scale-in event. The policy matters when multiple instances could be terminated and the selection order affects application behavior or instance age.

Termination Protection

Termination protection prevents the ASG from terminating a protected instance. It can be used when a particular instance must not be selected during normal ASG scale-in activity.

Protection does not mean the instance is exempt from every possible operational action; it specifically controls termination by the Auto Scaling group.

Standby State

An in-service instance can be moved to Standby to support troubleshooting or maintenance. While in Standby, the instance is not treated as actively serving in the normal way, and the ASG does not trigger normal actions against it while the troubleshooting activity is performed.

Use Standby when an engineer needs to investigate an instance without immediately terminating it or allowing normal ASG behavior to interfere with the investigation.

Lifecycle Hooks

Lifecycle hooks pause an instance during an Auto Scaling launch or termination transition so that custom actions can be performed.

Examples include:

• Running a script to install software during instance launch
• Performing initialization or configuration work before the instance becomes active
• Processing or preserving data before an instance is terminated

During a scale-out event, an instance can enter a pending wait state while custom code runs. A termination lifecycle hook can similarly pause the termination process while cleanup or data processing occurs.

Monitoring Granularity and Cost

The lesson distinguishes the following monitoring options:

Monitoring type	Granularity	Charge	Enablement
Auto Scaling group metrics	One minute	No charge	Must be enabled manually
EC2 basic monitoring	Five minutes	No charge	Instance monitoring option
EC2 detailed monitoring	One minute	Charges apply	Instance monitoring option

The important assessment distinction is that one-minute group metrics must be enabled manually, while detailed EC2 monitoring provides one-minute granularity with charges applying.

Exam- or Assessment-Relevant Takeaways

• Use an Auto Scaling group to manage and scale a collection of EC2 instances together.
• Use a launch template for the instance configuration used by new ASG instances; it is the more capable, preferred construct compared with a launch configuration.
• An ASG can replace an instance that fails EC2 status checks.
• ELB health checks provide an additional health signal and can cause unhealthy targets to be removed from service and replaced by the ASG.
• Set the health check grace period long enough for the application to initialize.
• Choose target tracking to maintain a metric near a target value.
• Choose step scaling when the scaling adjustment should vary according to the size of the alarm breach.
• Choose simple scaling for a single adjustment, while remembering its cooldown behavior.
• Use scheduled scaling for known time-based demand and dynamic scaling for observed demand.
• Use termination protection to prevent the ASG from terminating a protected instance.
• Use Standby for troubleshooting an in-service instance without immediately removing it from the environment.
• Use lifecycle hooks when custom launch or termination work must occur before the transition completes.
• Remember that group metrics have one-minute granularity, are not charged, and must be enabled manually.

Tool / Feature Decision Guide

Requirement	Appropriate feature	Decisive reason
Maintain average CPU near a defined value	Target tracking	Adjusts capacity to keep a metric near a target
React differently to small and large alarm breaches	Step scaling	Uses multiple step adjustments
Apply one fixed capacity adjustment	Simple scaling	Uses a single scaling adjustment
Increase capacity at a predictable time	Scheduled scaling	Follows a defined schedule
Anticipate future demand	Predictive scaling	Uses machine learning to predict likely demand
Replace an instance that fails infrastructure health checks	EC2 health checks with the ASG	The ASG can replace failed instances
Also detect application or target health behind a load balancer	ELB health checks	Adds load-balancer-reported health information
Avoid replacement during application startup	Health check grace period	Delays health-based action after launch
Run custom setup during launch	Launch lifecycle hook	Pauses the transition for custom actions
Investigate an instance without normal ASG interference	Standby state	Temporarily moves the instance out of normal service behavior
Prevent ASG scale-in termination of a specific instance	Termination protection	Protects the instance from ASG termination

Common Traps / Misconceptions

• Confusing horizontal and vertical scaling: EC2 Auto Scaling adds or removes instances; it does not resize an existing instance as the scaling action described here.
• Treating desired capacity as a permanent fixed count: Desired capacity is the group’s target count, but scaling policies can cause the group to launch or terminate instances.
• Assuming ELB health checks replace EC2 checks: ELB checks are additional health information used alongside EC2 status checks.
• Setting the grace period too short: A new instance may be healthy at the infrastructure level but not yet ready to serve application traffic.
• Using target tracking when discrete breach responses are required: Step scaling is more appropriate when large and small alarm breaches need different adjustments.
• Forgetting simple-scaling cooldown behavior: A cooldown gives previous scaling activity time to become visible before another change is made.
• Assuming termination protection makes an instance impossible to terminate: It prevents termination by the ASG, not every form of termination or administrative action.
• Using lifecycle hooks as a general monitoring feature: Lifecycle hooks pause launch or termination transitions for custom actions; they are not a replacement for CloudWatch monitoring.
• Assuming Standby permanently removes an instance: Standby is a temporary operational state used for activities such as troubleshooting.
• Overlooking monitoring configuration and cost: Group metrics must be enabled manually, and detailed EC2 monitoring incurs charges.

Real-World Engineer / Analyst Notes

• Choose the health-check grace period based on observed application startup time, not merely the time required for an EC2 instance to pass infrastructure checks.
• When using ELB health checks, investigate both the instance and the application path. An instance can pass EC2 checks while still failing the application health check.
• Scaling out only helps if the application can distribute work across the new instances. Load balancer integration is therefore an important part of a useful ASG design.
• Use lifecycle hooks carefully: pausing an instance transition creates an operational dependency on the custom action completing successfully.
• Standby is valuable for preserving an instance’s state during investigation, whereas termination and replacement are more appropriate when the instance is known to be unhealthy.
• Scaling in improves cost efficiency, but termination policies and protection settings should be reviewed when instances have different operational importance.
• Monitoring granularity affects how quickly scaling signals become available. Balance responsiveness against monitoring cost and the risk of reacting to transient conditions.

Quick Reference Summary

• AWS Auto Scaling adjusts service capacity automatically.
• EC2 Auto Scaling uses Auto Scaling groups to manage instance collections.
• CloudWatch metrics and health signals drive scaling and replacement decisions.
• Launch templates define how replacement and newly scaled instances are configured.
• EC2 health checks detect instance-level failures; ELB health checks add target or application health information.
• The health check grace period protects newly launched instances while they initialize.
• Dynamic scaling responds to demand, predictive scaling anticipates demand, and scheduled scaling follows a timetable.
• Target tracking maintains a metric near a target; step scaling varies adjustments by breach size; simple scaling uses one adjustment and cooldown behavior.
• Termination policies control scale-in selection, termination protection prevents ASG termination of protected instances, and Standby supports troubleshooting.
• Lifecycle hooks pause launch or termination transitions for custom scripts, initialization, cleanup, or data processing.

Flashcards

Q: An EC2 Auto Scaling group must keep average CPU utilization near 70%. Which scaling policy best matches this requirement?

A: Target tracking scaling. It adjusts group capacity to keep a CloudWatch metric near a configured target.

Q: A team wants small CPU breaches to add one instance but severe breaches to add several. Which policy should it choose?

A: Step scaling, because it supports multiple step adjustments based on the size of the alarm breach.

Q: When would simple scaling be selected instead of step scaling?

A: When one fixed scaling adjustment is sufficient. Simple scaling is less flexible and uses cooldown behavior after scaling activity.

Q: What happens when an EC2 instance in an ASG fails its EC2 status checks?

A: Auto Scaling can identify it as unhealthy, terminate or remove it, and launch a replacement to maintain group capacity.

Q: Why enable ELB health checks for an Auto Scaling group?

A: They add load-balancer-reported target health to the EC2 status checks, allowing unhealthy application targets to be removed and replaced.

Q: What is the purpose of an Auto Scaling health check grace period?

A: It delays health-based action after launch so the application has time to initialize before Auto Scaling evaluates its health.

Q: A new instance passes EC2 checks but its application endpoint is not ready immediately. What configuration helps prevent premature replacement?

A: A suitable health check grace period. It should be long enough for the application to become ready.

Q: Why is a launch template generally preferred over a launch configuration?

A: Launch templates provide more configuration options for instances, while launch configurations are older and more limited.

Q: Which scaling mode fits demand that reliably increases every weekday at 9:00 a.m.?

A: Scheduled scaling, because capacity changes can be defined for a known timetable.

Q: What is the operational purpose of a simple-scaling cooldown?

A: It prevents another launch or termination from occurring before the effects of the previous activity are visible, reducing erratic decisions.

Q: An engineer needs to troubleshoot an instance without immediately allowing normal ASG behavior to affect it. Which state is appropriate?

A: Standby. It moves an in-service instance into a state suitable for troubleshooting without normal ASG actions interfering.

Q: How does termination protection differ from a termination policy?

A: Termination protection prevents the ASG from terminating a protected instance. A termination policy determines which eligible instance is selected first during scale-in.

Q: When should a lifecycle hook be used during an instance launch?

A: Use it when custom actions, such as installing software or running initialization code, must occur before the launch transition completes.

Q: What is the monitoring difference between Auto Scaling group metrics and EC2 detailed monitoring in this lesson?

A: Both provide one-minute granularity, but group metrics are free and must be enabled manually, while EC2 detailed monitoring incurs charges.

Practice Questions

Question 1

An application runs in an EC2 Auto Scaling group behind an Elastic Load Balancer. Instances pass EC2 status checks, but the application health endpoint fails and the load balancer marks targets unhealthy. What should be configured so Auto Scaling can replace these instances?

A. Only EC2 basic monitoring
B. ELB health checks for the Auto Scaling group
C. Termination protection
D. A lifecycle hook only

Correct answer: B. ELB health checks for the Auto Scaling group.

Explanation: ELB health checks add target or application health information to the EC2 status checks. An unhealthy ELB target can be removed from service and replaced by Auto Scaling.

Question 2

A service has predictable traffic spikes at a specific time each day. The operations team wants additional EC2 capacity before the spike begins, without waiting for CPU utilization to rise. Which approach is most appropriate?

A. Scheduled scaling
B. Simple scaling with no cooldown
C. Standby state
D. Termination protection

Correct answer: A. Scheduled scaling.

Explanation: Scheduled scaling changes capacity according to a defined timetable, making it suitable for known recurring demand.

Question 3

An ASG should keep aggregate CPU utilization around 70%, scaling out when CPU rises and scaling in when it falls. Which policy directly expresses this goal?

A. Target tracking
B. Step scaling with one step
C. A termination policy
D. A lifecycle hook

Correct answer: A. Target tracking.

Explanation: Target tracking is designed to maintain a CloudWatch metric near a configured target value.

Question 4

An application requires six minutes to initialize after an EC2 instance launches. The ASG currently evaluates health almost immediately and replaces instances whose application port is not yet available. What is the most relevant change?

A. Enable termination protection
B. Use a longer health check grace period
C. Change to Standby state permanently
D. Enable a termination policy

Correct answer: B. Use a longer health check grace period.

Explanation: The grace period delays health-based action after launch, allowing the application time to initialize and become ready.

WordPress Metadata

Suggested Slug:
aws-auto-scaling-ec2-scaling-groups-policies-health-checks

Meta Description:
Study AWS Auto Scaling across EC2 and other services, including scaling policies, health checks, launch templates, lifecycle controls, and assessment-focused tradeoffs.

Tags:
AWS Auto Scaling, Amazon EC2, Auto Scaling groups, CloudWatch, scaling policies, launch templates, Elastic Load Balancing, health checks, lifecycle hooks, high availability, AWS CloudOps, SOA-C03