Create an Amazon EC2 Auto Scaling Group Across Availability Zones – SAP-C02 Study Guide

Purpose of This Lesson

This hands-on exercise demonstrates how to create an Amazon EC2 Auto Scaling group (ASG) that maintains two web server instances across two Availability Zones. It also shows how the ASG detects a terminated instance and launches a replacement to restore the desired capacity.

The exercise uses an EC2 launch template containing the AMI, instance type, security group, and user data required to configure each web server.

Key Concepts

Launch templates define instance configuration

An Auto Scaling group uses a launch template or launch configuration to determine how new EC2 instances are created. The launch template in this exercise includes:

• AMI: Amazon Linux 2023
• Instance type: t2.micro
• Security group: A group permitting HTTP access on TCP port 80
• Key pair: Not configured for this lab
• User data: A shell script that installs Apache and creates a custom web page

Every instance launched by the ASG receives the same baseline configuration. User data runs during instance initialization, making it useful for installing packages and applying initial configuration.

User data can provide instance-specific validation

The web server script creates a page that displays the instance’s Availability Zone. This is useful for validating that instances are distributed as expected and for identifying which instance handled a request during testing.

In production, user data should be designed to complete reliably and idempotently. If initialization fails, the instance may still be considered running unless additional health checks or lifecycle controls are used.

Auto Scaling group capacity settings

An ASG uses three primary capacity values:

• Desired capacity: The number of instances the group attempts to maintain.
• Minimum capacity: The lowest number of instances the group should run.
• Maximum capacity: The highest number of instances the group can launch.

For the initial static configuration:

• Desired: 2
• Minimum: 2
• Maximum: 2

This configuration maintains two instances but leaves no capacity for scale-out. A dynamic scaling policy would require the maximum capacity to be increased above two.

Multi-AZ placement

The ASG is configured to use two Availability Zones in the same Region. When launching two instances, the group distributes them across the enabled Availability Zones, typically placing one instance in each zone.

Multi-AZ deployment improves resilience against an Availability Zone failure. It does not, by itself, provide application-level traffic distribution; an Application Load Balancer would normally be placed in front of the instances.

Health-based replacement

The ASG monitors instance health and maintains the configured capacity. If an instance is terminated or fails the applicable EC2 health check, the ASG can mark it out of service and launch a replacement.

This is one of the core distinctions between manually managed EC2 instances and an Auto Scaling architecture: instances are treated as replaceable compute capacity rather than permanent servers.

Security groups and web access

The instance security group must allow inbound TCP port 80 from the intended client source. In a production architecture, the preferred pattern is usually:

• The load balancer security group permits client traffic.
• The instance security group permits port 80 only from the load balancer security group.

Allowing port 80 from 0.0.0.0/0 is suitable for a simple public-web demonstration but is broader than necessary when a load balancer is used.

Exam-Relevant Takeaways

• An ASG does not contain the complete instance definition by itself; it references a launch template.
• A launch template can define the AMI, instance type, security groups, key pair, storage, networking options, and user data.
• The ASG determines where instances are launched by selecting subnets or Availability Zones during configuration.
• Desired capacity is the target number of instances, while minimum and maximum values constrain scaling.
• Setting desired, minimum, and maximum to the same value creates fixed capacity rather than useful dynamic scaling headroom.
• An ASG can replace terminated or unhealthy EC2 instances automatically.
• Distributing instances across multiple Availability Zones improves resilience, but a load balancer is still needed to route client traffic.
• Auto Scaling group activity history is the primary place to inspect launches, terminations, failed actions, and health-based replacements.
• EC2 status checks are not the same as application health checks. For application-aware replacement, configure an appropriate load balancer health check and use the ASG’s health-check settings accordingly.

Architecture Decision Guide

Requirement	Relevant configuration	Design implication
Maintain a fixed number of web servers	Desired, minimum, and maximum set to the same value	The ASG replaces lost instances but does not scale out
Allow demand-based scale-out	Set maximum above desired and add a dynamic scaling policy	The ASG can increase capacity when policy conditions are met
Improve Availability Zone resilience	Select subnets in multiple Availability Zones	Instances can be distributed across independent failure domains
Standardize new instances	Use a launch template	Every replacement follows the same AMI and initialization settings
Route traffic to healthy instances	Attach an Elastic Load Balancing target group	The load balancer distributes requests and performs health checks
Restrict direct instance access	Allow the instance security group to reference the load balancer security group	Clients access the load balancer rather than the instances directly
Verify instance placement	Display the Availability Zone in the web page or instance metadata	Useful for lab validation and troubleshooting

Common Exam Traps

• Confusing desired capacity with maximum capacity: Desired capacity is the current target, not the upper scaling limit.
• Setting maximum equal to desired when scale-out is required: The ASG cannot launch more instances than its maximum.
• Assuming an ASG distributes traffic: The ASG launches and manages instances; an Elastic Load Balancing service handles request distribution.
• Assuming multi-AZ placement is automatic across every zone: The ASG can launch only into the subnets or Availability Zones configured for it.
• Treating user data as continuous configuration management: User data normally runs during initial boot. It does not continuously enforce configuration.
• Assuming EC2 health checks validate the application: Basic EC2 status checks identify infrastructure-level problems. A load balancer health check is better suited to testing application availability.
• Using an unrestricted instance security group behind a load balancer: Public access to instances may bypass the load balancer and weaken the intended security boundary.
• Expecting immediate replacement: ASG activities such as detecting termination, launching an instance, and completing initialization take time. The activity history shows the progression.

Real-World Engineer Notes

• Use subnets in multiple Availability Zones and ensure the selected subnets have appropriate routing. Public web instances require a public IPv4 address and Internet Gateway path, while private instances typically use a load balancer and NAT Gateway or VPC endpoints as appropriate.
• For production workloads, prefer current-generation instance types and use a launch template rather than relying on older launch configurations.
• A static desired capacity is useful for a basic high-availability baseline, but production systems commonly add target tracking, step scaling, scheduled scaling, or predictive scaling based on workload behavior.
• Attach the ASG to an Elastic Load Balancing target group so that traffic is sent only to instances passing application health checks.
• Consider instance refresh when updating the AMI or launch template. Replacing instances gradually reduces deployment risk compared with changing every server at once.
• Use CloudWatch metrics and ASG activity history to investigate scaling decisions and launch failures.
• For more reliable initialization, use immutable images created with tools such as EC2 Image Builder rather than installing substantial software during every boot.
• Enable scale-in protection only for instances that require temporary protection from termination; it can prevent the ASG from reaching the desired capacity during scale-in.

Quick Reference Summary

• Launch template: Defines how an EC2 instance is launched.
• Auto Scaling group: Maintains and replaces a fleet of EC2 instances.
• Desired capacity: Current target number of instances.
• Minimum capacity: Lowest permitted ASG size.
• Maximum capacity: Highest permitted ASG size.
• Multi-AZ configuration: Places capacity across selected Availability Zones.
• User data: Boot-time script used for initial setup.
• Health replacement: The ASG launches a replacement when an instance is terminated or considered unhealthy.
• Load balancer: Distributes client requests and provides application-level health checks.
• Activity history: Shows ASG launch, termination, and replacement operations.

Flashcards

1. Q: What does a launch template provide to an Auto Scaling group?

A: The EC2 launch configuration, including the AMI, instance type, security groups, storage, key pair, and user data.

1. Q: What does desired capacity mean in an ASG?

A: The number of instances the ASG currently attempts to keep running.

1. Q: What happens if desired, minimum, and maximum capacity are all set to two?

A: The ASG maintains two instances but cannot scale out beyond two.

1. Q: Why configure an ASG across multiple Availability Zones?

A: To distribute capacity across independent failure domains and improve availability.

1. Q: What does user data typically do in this type of exercise?

A: It runs during instance initialization to install and configure the web server.

1. Q: How does an ASG respond when a managed instance is terminated?

A: It detects that capacity is below the desired level and launches a replacement, subject to its settings and health checks.

1. Q: Which AWS component distributes HTTP requests to ASG instances?

A: An Elastic Load Balancing service, commonly an Application Load Balancer for HTTP/HTTPS workloads.

1. Q: Where can you review ASG launches and terminations?

A: The Auto Scaling group activity history.

1. Q: Why should instance security groups usually not allow unrestricted public access when an ALB is used?

A: Clients should reach the instances through the ALB, allowing the instance security group to restrict inbound traffic to the load balancer.

1. Q: What is the limitation of relying only on EC2 status checks?

A: They may not detect an application that is running at the instance level but is unable to serve valid requests.

Practice Questions

Question 1

A solutions architect configures an Auto Scaling group with a desired capacity of 4, a minimum capacity of 4, and a maximum capacity of 4. A scaling policy is attached, but CPU utilization remains high and the ASG does not launch additional instances. What is the most likely cause?

• A. The launch template does not include a key pair
• B. The ASG maximum capacity prevents scale-out
• C. The instances are deployed across multiple Availability Zones
• D. User data runs only during the first boot

Correct answer: B

The maximum capacity is the upper limit on the number of instances in the ASG. With maximum capacity set to 4, the group cannot scale out beyond its current desired capacity.

Question 2

An application runs on EC2 instances managed by an Auto Scaling group. The architect wants the application to remain available if one Availability Zone becomes unavailable. Which configuration best addresses this requirement?

• A. Launch all instances in one public subnet with a larger instance type
• B. Configure the ASG to use subnets in multiple Availability Zones
• C. Increase the ASG maximum capacity without changing its subnets
• D. Add an SSH key pair to the launch template

Correct answer: B

Selecting subnets in multiple Availability Zones distributes instances across failure domains. A load balancer should typically be added to route traffic to the remaining healthy instances.

Question 3

An ASG maintains two instances. An administrator terminates one instance manually. What should the architect expect?

• A. The ASG permanently operates with one instance
• B. The ASG launches a replacement to restore desired capacity
• C. The ASG increases maximum capacity by one
• D. The launch template is deleted

Correct answer: B

The ASG monitors its managed capacity. When an instance is terminated and the group falls below desired capacity, it normally launches a replacement using the configured launch template.

Question 4

A web application uses an Application Load Balancer in front of an ASG. Which security group configuration follows least-privilege principles?

• A. Allow port 80 from the entire internet to both the ALB and instances
• B. Allow port 80 from the ALB security group to the instances and client traffic to the ALB
• C. Allow SSH from the entire internet to the instances and deny HTTP
• D. Allow all inbound traffic to the instances because the ASG performs health checks

Correct answer: B

The ALB security group should accept the required client traffic, while the instance security group should permit application traffic from the ALB security group rather than from arbitrary internet clients.