search

Auto-Scalling group

chevron-rightNew-EC2hashtag

hashtag
Setting Up a Real-Time Auto Scaling Group for EC2 with an Example

Overview

Auto Scaling Groups (ASG) help maintain high availability and performance by dynamically adjusting the number of EC2 instances based on real-time demand.

hashtag
🛠️ Steps to Set Up an Auto Scaling Group for EC2

Step 1: Create a Launch Template

A Launch Template defines how new instances should be configured.

  1. Open AWS Console → Go to EC2.

  2. Click on Launch Templates → Create Launch Template.

  3. Enter the Launch Template Name (e.g., web-server-template).

  4. Under AMI, choose an OS (e.g., Amazon Linux 2).

  5. Select an Instance Type (e.g., t3.micro).

  6. Under Key Pair, select an existing key pair for SSH access.

  7. Configure Network Settings:

    • Select a VPC.

    • Enable Auto-assign Public IP (if needed).

  8. Add a User Data Script (optional, for boot-time setup):

    #!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "Welcome to Auto Scaling Group" > /var/www/html/index.html

  9. Click Create Launch Template.

Step 2: Create an Auto Scaling Group

  1. Open AWS Console → Go to Auto Scaling Groups.

  2. Click Create Auto Scaling Group.

  3. Enter Auto Scaling Group Name (e.g., web-server-asg).

  4. Select Launch Template created earlier.

  5. Choose a VPC and Subnets for instance placement.

  6. Configure Instance Scaling Policy:

    • Minimum Instances: 2

    • Desired Instances: 2

    • Maximum Instances: 5

  7. Configure Load Balancer (Optional):

    • Choose Application Load Balancer (ALB) if needed.

    • Create a Target Group for the ALB.

  8. Configure Scaling Policies:

    • Enable Target Tracking Scaling Policy based on CPU Utilization.

    • Set Target CPU Utilization to 50%.

  9. Click Create Auto Scaling Group.

Step 3: Test Auto Scaling in Real-Time

  1. Check if 2 instances are running initially.

  2. Simulate high CPU usage on an instance:

    stress --cpu 4 --timeout 300

  3. Verify that ASG adds more instances when CPU exceeds 50%.

  4. Stop the high CPU process and check if ASG terminates extra instances when CPU drops.

hashtag
🛠️ Terraform Code for ASG Setup

For Infrastructure as Code (IaC), use Terraform:

resource "aws_launch_template" "web_server" {
  name_prefix   = "web-server"
  image_id      = "ami-12345678"  # Change AMI ID
  instance_type = "t3.micro"

  user_data = base64encode(<<-EOF
    #!/bin/bash
    yum update -y
    yum install -y httpd
    systemctl start httpd
    systemctl enable httpd
    echo "Welcome to Auto Scaling Group" > /var/www/html/index.html
  EOF
  )

  network_interfaces {
    associate_public_ip_address = true
    security_groups             = [aws_security_group.web_server.id]
  }
}

resource "aws_autoscaling_group" "web_asg" {
  desired_capacity     = 2
  min_size            = 2
  max_size            = 5
  vpc_zone_identifier = aws_subnet.public.*.id

  launch_template {
    id      = aws_launch_template.web_server.id
    version = "$Latest"
  }

  tag {
    key                 = "Name"
    value               = "Web-ASG-Instance"
    propagate_at_launch = true
  }
}

hashtag
🎯 Key Features of this ASG Setup

✔ Real-time scaling based on CPU load. ✔ Resilience – If an instance fails, ASG replaces it. ✔ Cost Optimization – No over-provisioning of EC2 instances. ✔ Load Balancer Support – Can distribute traffic across instances.

Would you like me to add auto-healing with ALB or CloudWatch alarms for monitoring? 🚀

An Auto Scaling Group (ASG) is an AWS feature that automatically manages a fleet (group/number of) of EC2 instances by scaling in (removing instances) or scaling out (adding instances) based on demand, ensuring high availability and cost optimization.

chevron-rightExisting-EC2hashtag

To enable Auto Scaling for an existing EC2 instance, follow these steps:

hashtag
Option 1: Create an Auto Scaling Group (ASG) from an Existing Instance

If you have an existing EC2 instance and want to enable auto scaling, you need to create an Auto Scaling Group (ASG) and use the existing instance's configuration.

Step 1: Create a Launch Template from the Existing EC2 Instance

  1. Open EC2 Dashboard → Go to Instances.

  2. Select the existing instance you want to scale.

  3. Click Actions → Create Template from Instance.

  4. Provide a name for the launch template.

  5. Under Launch template content, ensure that:

    • AMI, Instance Type, and Key Pair are correctly set.

    • Security Groups match your instance.

    • User Data (startup scripts) are included if needed.

  6. Click Create Launch Template.

Step 2: Create an Auto Scaling Group (ASG)

  1. Open EC2 Dashboard → Go to Auto Scaling Groups.

  2. Click Create Auto Scaling Group.

  3. Choose Launch Template:

    • Select Use an existing launch template.

    • Pick the launch template created in Step 1.

  4. Configure ASG Settings:

    • Name: Provide a name (e.g., My-EC2-ASG).

    • Select the VPC and Subnets where instances will be launched.

    • Select Load Balancer (optional, if you want to distribute traffic).

  5. Set Scaling Policies:

    • Minimum Instances: 1 (Keeps at least 1 instance running).

    • Desired Instances: 1 or more (Depending on workload).

    • Maximum Instances: 5 (Adjust based on expected traffic).

    • Enable Target Tracking Scaling Policy (e.g., CPU utilization > 50% triggers scaling).

  6. Review & Create: Click Create Auto Scaling Group.

Step 3: Attach the Existing EC2 Instance to ASG (Optional)

If you want to attach the existing instance to the ASG instead of creating new ones:

  1. Open Auto Scaling Groups.

  2. Select the ASG you created.

  3. Click on the Instance Management tab.

  4. Click Attach Instances → Select your existing instance.

  5. Click Attach.

💡 Note: If the existing instance does not match the ASG's configuration (e.g., wrong AMI, instance type, or networking settings), the ASG may replace it when scaling happens.

hashtag
Verification

  • Go to Auto Scaling Groups → Select your ASG.

  • Under the Activity tab, check for instance launches or terminations.

  • If CPU usage increases above the threshold (e.g., 50%), new instances should be automatically launched.

  • If CPU usage drops, extra instances should be terminated.

hashtag
Alternative: Use AWS CLI to Enable Auto Scaling for an Existing EC2 Instance

aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name MyEC2AutoScalingGroup \
    --launch-template LaunchTemplateName \
    --min-size 1 \
    --max-size 5 \
    --desired-capacity 1 \
    --vpc-zone-identifier subnet-xxxxxxxxxxxx

This setup ensures your existing EC2 instance is managed by Auto Scaling and can scale dynamically based on demand. 🚀

hashtag
Scenario-Based EC2 Auto Scaling Interview Questions & Answers

1. Scenario: Your application experiences sudden traffic spikes. How would you ensure your EC2 instances scale automatically?

✅ Answer: I would configure an Auto Scaling Group (ASG) with a scaling policy based on CPU utilization or request count. If CPU usage exceeds 60% for 5 minutes, ASG should launch a new instance. I would also integrate it with an Elastic Load Balancer (ELB) to distribute traffic efficiently.

2. Scenario: Your ASG has a minimum of 2 instances, but you see that only one instance is running. What could be the issue?

✅ Answer: Possible reasons:

  1. Insufficient EC2 Capacity – AWS might not have enough instances available in that region.

  2. Failed Health Checks – One instance might be unhealthy and ASG is in the process of replacing it.

  3. Instance Launch Failures – Check IAM roles, security groups, and subnet availability.

  4. Scaling Policy Conflict – Review ASG’s scaling policies to see if an incorrect rule is limiting instance creation.

3. Scenario: Your ASG keeps launching and terminating instances rapidly. What could be the problem?

✅ Answer: This is known as Auto Scaling "flapping" and might be caused by:

  • Overly aggressive scaling policies – If the scale-in and scale-out thresholds are too close, it may cause unnecessary scaling.

  • Instance Startup Delay – If health checks run before an instance is fully initialized, ASG might assume it’s unhealthy and replace it.

  • Health Check Failures – If an ELB is marking instances unhealthy due to improper configuration.

Solution:

  • Add a cooldown period to allow time between scaling events.

  • Use a more gradual scaling threshold (e.g., scale out at 70% CPU but scale in at 30%).

  • Ensure the instance has enough time to initialize before health checks occur.

4. Scenario: You need to add an existing EC2 instance to an ASG. How would you do it?

✅ Answer:

  1. Detach the instance from the current load balancer (if any).

  2. Create an ASG with a launch template matching the instance’s configuration.

  3. Manually add the existing instance to the ASG using:

  4. Update health checks to include the new instance.

  5. Verify that ASG recognizes and manages the instance.

5. Scenario: Your ASG launched a new instance, but it’s not receiving any traffic. What could be wrong?

✅ Answer:

  • The new instance might not be registered with the Elastic Load Balancer (ELB).

  • The security group might not allow inbound traffic.

  • The instance might fail health checks, preventing it from getting traffic.

  • The instance might be in an unhealthy AZ that is not receiving traffic due to routing rules.

Solution:

  • Check if the instance is in the ELB target group:

  • Ensure health checks are correctly configured.

  • Review security groups and routing tables.

6. Scenario: Your ASG scales out but does not scale in. What could be wrong?

✅ Answer:

  • Scale-in protection might be enabled, preventing ASG from terminating instances.

  • Instance cooldown period might be too long, delaying scale-in actions.

  • Minimum instance count might be preventing scale-in.

  • Termination policies might be set incorrectly, keeping old instances running.

Solution:

  • Check ASG’s termination policies and adjust if necessary.

  • Reduce cooldown period to allow scale-in sooner.

  • Ensure minimum instance count allows termination.

7. Scenario: Your EC2 instances in an ASG need updates (e.g., OS patches). How would you update them without downtime?

✅ Answer: I would use a Rolling Update strategy:

  1. Create a new launch template/version with the updated AMI or configuration.

  2. Update the ASG to use the new launch template:

  3. Enable Rolling Update Deployment – Set a termination policy that replaces old instances gradually.

  4. Use an ELB to keep traffic running while instances update.

  5. Verify the deployment before terminating older instances.

8. Scenario: You need to ensure a minimum of 3 instances running at all times. How would you configure ASG?

✅ Answer:

  • Set desired capacity and minimum size to 3:

  • Ensure the health check mechanism is properly configured to replace failed instances.

9. Scenario: Your ASG spans multiple Availability Zones (AZs), but one AZ has no instances running. Why?

✅ Answer:

  • AZ might be at capacity – AWS might not have resources available.

  • Subnet configuration issue – Ensure subnets are correctly associated with the ASG.

  • Instance distribution policy – Check if instances are evenly spread across AZs.

  • Health checks failed in that AZ, causing ASG to terminate instances.

Solution:

  • Ensure ASG has subnets from multiple AZs.

  • Check AWS Service Quotas for EC2 instance limits in that AZ.

  • Modify the load balancing policy to evenly distribute instances.

10. Scenario: Your ASG should not terminate Spot Instances first. How do you configure this?

✅ Answer:

  • Modify the termination policy to prioritize On-Demand instances for termination before Spot:

  • Alternatively, configure Mixed Instances Policy to weight Spot vs. On-Demand instances.

These are real-world AWS Auto Scaling scenarios you might face in an interview! Let me know if you need more. 🚀

PreviousTroubleshootingNexttypes and pricing

Last updated