Code from github to self hosted with git tea in AWS
This commit is contained in:
ADITYANAIR01
321
PRACTICE/AUTO-SCALING-GROUP-ELB/ASG-README.md
Normal file
321
PRACTICE/AUTO-SCALING-GROUP-ELB/ASG-README.md
Normal file
@@ -0,0 +1,321 @@
|
||||
# Auto Scaling Group (ASG) with Elastic Load Balancer
|
||||
|
||||
## What is an Auto Scaling Group?
|
||||
|
||||
An **Auto Scaling Group (ASG)** is an AWS service that automatically manages a fleet of EC2 instances, maintaining the number you specify at all times. When paired with an **Elastic Load Balancer (ELB)**, the ASG registers its instances as targets in the load balancer's target group automatically — so every new instance spun up by the ASG is immediately eligible to receive traffic. The ELB continuously performs health checks on all registered instances and reports results back to the ASG; if an instance fails a health check, the ASG detects it, terminates the unhealthy instance, and launches a replacement — entirely without human intervention. This combination delivers **high availability**, **self-healing infrastructure**, and the ability to **scale in or out** based on demand.
|
||||
|
||||
> **Prerequisites:** This lab assumes an Application Load Balancer (`ALB-ASG`) and Target Group (`ALB-ASG-TG`) already exist. If you haven't created them yet, refer to the [ALB README](../APPLICATION-LOAD-BALANCER/ALB-README.md) first.
|
||||
|
||||
---
|
||||
|
||||
## Lab Overview
|
||||
|
||||
| Resource | Name / Value |
|
||||
|---|---|
|
||||
| Auto Scaling Group | `ASG` |
|
||||
| Launch Template | `ASG-launch-template` |
|
||||
| AMI | Amazon Linux 2023 (ami-0317b0f0a0144b137) |
|
||||
| Instance Type | `t3.micro` |
|
||||
| Security Group (instances) | `launch-wizard-1` |
|
||||
| Security Group (ALB) | `SG-ASG` |
|
||||
| Load Balancer | `ALB-ASG` |
|
||||
| Target Group | `ALB-ASG-TG` |
|
||||
| Desired / Min / Max capacity | `2` / `1` / `4` |
|
||||
| Availability Zones | ap-south-1a, ap-south-1b, ap-south-1c |
|
||||
| Region | `ap-south-1` (Mumbai) |
|
||||
|
||||
---
|
||||
|
||||
## Video Demo
|
||||
|
||||
[](https://youtu.be/gUS-584nZ7M)
|
||||
|
||||
---
|
||||
|
||||
## Step-by-Step Walkthrough
|
||||
|
||||
### Step 1 — Open EC2 and Navigate to Auto Scaling Groups
|
||||
|
||||
Log in to the AWS Management Console. From the **Recently visited** services on Console Home, click **EC2**.
|
||||
|
||||
|
||||
|
||||
Inside the EC2 dashboard, locate the **Resources** panel and click **Auto Scaling Groups**.
|
||||
|
||||
|
||||
|
||||
The Auto Scaling Groups landing page explains how ASG works. Click **Create Auto Scaling group** to begin.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Step 2 — Create a Launch Template
|
||||
|
||||
A **launch template** is a reusable blueprint that tells the ASG exactly how to configure every EC2 instance it launches — OS, instance type, security group, and startup script — so you never have to configure machines manually again.
|
||||
|
||||
#### 2a — Name the ASG and open the launch template wizard
|
||||
|
||||
In the **Name** field of the ASG wizard, enter `ASG`. Since no launch template exists yet, click **Create a launch template** to open the template wizard in a new tab.
|
||||
|
||||
|
||||
|
||||
#### 2b — Name and describe the template
|
||||
|
||||
Enter the following details:
|
||||
- **Launch template name:** `ASG-launch-template`
|
||||
- **Template version description:** `A launch template for Auto Scaling Group`
|
||||
- **Auto Scaling guidance:** check the box — *Provide guidance to help me set up a template that I can use with EC2 Auto Scaling*
|
||||
|
||||
Then scroll down.
|
||||
|
||||
|
||||
|
||||
#### 2c — Choose AMI and instance type
|
||||
|
||||
Under **Application and OS Images**, click **Quick Start**, select **Amazon Linux**, and choose **Amazon Linux 2023 AMI 2023.10** (Free tier eligible).
|
||||
|
||||
|
||||
|
||||
Under **Instance type**, open the dropdown and select **t3.micro** (Free tier eligible, 2 vCPU, 1 GiB Memory).
|
||||
|
||||
|
||||
|
||||
#### 2d — Select security group, add user data, and create the template
|
||||
|
||||
Under **Network settings**, choose **Select existing security group** and select **launch-wizard-1**.
|
||||
|
||||
|
||||
|
||||
Scroll down and click **Advanced details** to expand it.
|
||||
|
||||
|
||||
|
||||
Scroll to the **User data** field and paste the following script. This script runs automatically the first time each instance boots, installing and starting a web server that displays the instance's private hostname — which is how you can confirm the load balancer is routing to different instances.
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Use this for your user data (script from top to bottom)
|
||||
# install httpd (Linux 2 version)
|
||||
yum update -y
|
||||
yum install -y httpd
|
||||
systemctl start httpd
|
||||
systemctl enable httpd
|
||||
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html
|
||||
```
|
||||
|
||||
| Command | Purpose |
|
||||
|---|---|
|
||||
| `yum update -y` | Updates all installed packages |
|
||||
| `yum install -y httpd` | Installs Apache HTTP Server |
|
||||
| `systemctl start httpd` | Starts the web server immediately |
|
||||
| `systemctl enable httpd` | Ensures the web server starts on every reboot |
|
||||
| `echo ... > /var/www/html/index.html` | Creates a page showing the instance's private hostname |
|
||||
|
||||
Click **Create launch template**.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Step 3 — Select the Launch Template and Configure the Network
|
||||
|
||||
Return to the ASG wizard tab. Open the **Launch template** dropdown and select **ASG-launch-template**.
|
||||
|
||||
|
||||
|
||||
The template summary appears, confirming the AMI, instance type (`t3.micro`), and security group. Click **Next**.
|
||||
|
||||
|
||||
|
||||
On the **Choose instance launch options** step, under **Availability Zones and subnets**, select all three availability zones:
|
||||
- **aps1-az1** (ap-south-1a)
|
||||
- **aps1-az2** (ap-south-1c)
|
||||
- **aps1-az3** (ap-south-1b)
|
||||
|
||||
Leave **Availability Zone distribution** set to **Balanced best effort**. Click **Next**.
|
||||
|
||||
|
||||
|
||||
> **Why select all AZs?** Spreading instances across multiple Availability Zones means that if one AZ has an outage, your application keeps running on instances in the remaining zones.
|
||||
|
||||
---
|
||||
|
||||
### Step 4 — Attach to the Existing Load Balancer
|
||||
|
||||
On the **Integrate with other services** step, under **Load balancing**, select **Attach to an existing load balancer**.
|
||||
|
||||
Under **Select the load balancers to attach**, choose **Choose from your load balancer target groups**. Click the target group dropdown — it shows `ALB-ASG-TG | HTTP` backed by the `ALB-ASG` load balancer. Select it.
|
||||
|
||||
|
||||
|
||||
Scroll down to the **Health checks** section. Tick **Turn on Elastic Load Balancing health checks** (marked Recommended). Leave the health check grace period at **300 seconds**. Click **Next**.
|
||||
|
||||
|
||||
|
||||
> **Why enable ELB health checks?** By default the ASG only uses EC2 health checks (is the instance running?). Enabling ELB health checks adds a second layer — the ASG will also replace instances that are running but failing to serve HTTP traffic.
|
||||
|
||||
---
|
||||
|
||||
### Step 5 — Configure Group Size and Scaling
|
||||
|
||||
On the **Configure group size and scaling** step, set the capacity values:
|
||||
|
||||
| Setting | Value |
|
||||
|---|---|
|
||||
| Desired capacity | `2` |
|
||||
| Min desired capacity | `1` |
|
||||
| Max desired capacity | `4` |
|
||||
|
||||
Under **Automatic scaling**, leave **No scaling policies** selected — the group will maintain exactly the desired capacity at all times.
|
||||
|
||||
Under **Instance maintenance policy**, leave **No policy** selected.
|
||||
|
||||
|
||||
|
||||
Scroll down, review the additional settings (all defaults), and click **Next**.
|
||||
|
||||
|
||||
|
||||
On the **Add notifications** step, skip adding any SNS notifications and click **Next**.
|
||||
|
||||
|
||||
|
||||
On the **Add tags** step, skip adding tags and click **Next**.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Step 6 — Review and Create
|
||||
|
||||
The **Review** page summarises every setting. Verify:
|
||||
- **Auto Scaling group name:** `ASG`
|
||||
- **Launch template:** `ASG-launch-template` (Default version)
|
||||
- **Availability Zones:** aps1-az1, aps1-az2, aps1-az3
|
||||
|
||||
Scroll through and confirm the load balancer integration and group size settings are correct.
|
||||
|
||||
|
||||
|
||||
Scroll to the bottom and click **Create Auto Scaling group**.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Step 7 — ASG Created — EC2 Instances Auto-Provisioned
|
||||
|
||||
The ASG is created. Navigate to the **Activity** tab. The Activity history shows two **Successful** launch events — the ASG immediately provisioned the desired 2 instances using the launch template.
|
||||
|
||||
|
||||
|
||||
Navigate to **EC2 > Instances**. Two `t3.micro` instances are in **Running** state — one in `ap-south-1a`, one in `ap-south-1b`.
|
||||
|
||||
|
||||
|
||||
> **Key point:** You never clicked "Launch instance." The ASG read the launch template and provisioned both machines automatically as soon as it was created.
|
||||
|
||||
---
|
||||
|
||||
### Step 8 — Test via the Load Balancer DNS
|
||||
|
||||
Navigate to **EC2 > Load Balancers** and select **ALB-ASG**. In the details panel, locate and copy the **DNS name**:
|
||||
|
||||
```
|
||||
ALB-ASG-1425310447.ap-south-1.elb.amazonaws.com
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Paste the DNS name into your browser's address bar and press Enter. You will see a page served by one of the ASG-managed instances:
|
||||
|
||||
|
||||
|
||||
Refresh the page. The ALB routes the request to another instance, and you may see a different hostname — confirming the load balancer is distributing traffic across the ASG's instances.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Step 9 — Test Auto-Healing
|
||||
|
||||
To verify the self-healing capability, manually terminate one of the running instances. Go to **EC2 > Instances**, select one of the ASG-managed instances, click **Instance state > Terminate (delete) instance**.
|
||||
|
||||
|
||||
|
||||
Switch to **Auto Scaling groups > ASG > Instance management**. The terminated instance appears with a health status of **Unhealthy** (Lifecycle: Terminating), while the others remain **Healthy**.
|
||||
|
||||
|
||||
|
||||
Within a few minutes, check the **Activity** tab. A new entry appears:
|
||||
|
||||
> *"An instance was launched in response to an unhealthy instance needing to be replaced."*
|
||||
|
||||
The ASG detected the unhealthy instance via the ELB health check, terminated it, and launched a fresh replacement — all automatically.
|
||||
|
||||
|
||||
|
||||
> **Auto-healing in action:** No manual intervention was needed. The ASG + ELB health check loop detected the failure and self-healed the fleet within minutes.
|
||||
|
||||
---
|
||||
|
||||
### Step 10 — Cleanup
|
||||
|
||||
Delete resources in the following order to avoid dependency errors.
|
||||
|
||||
#### 10a — Delete the Auto Scaling Group
|
||||
|
||||
In **Auto Scaling groups**, select `ASG`, click **Actions > Delete**. Type `delete` in the confirmation field and click **Delete**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The ASG status changes to **Deleting** and the desired/min/max capacity drops to 0.
|
||||
|
||||
|
||||
|
||||
The Activity history shows both instances being terminated.
|
||||
|
||||
|
||||
|
||||
> **Important:** Deleting the ASG automatically terminates all EC2 instances it manages. You do not need to terminate them separately.
|
||||
|
||||
Navigate to **EC2 > Instances** to confirm all instances are terminated.
|
||||
|
||||
|
||||
|
||||
#### 10b — Delete the Load Balancer
|
||||
|
||||
In **EC2 > Load Balancers**, select `ALB-ASG`, click **Actions > Delete load balancer** and confirm. A green banner confirms: *Successfully deleted load balancer: ALB-ASG*.
|
||||
|
||||
|
||||
|
||||
#### 10c — Delete the Target Group
|
||||
|
||||
In **EC2 > Target Groups**, select `ALB-ASG-TG`, click **Actions > Delete** and confirm.
|
||||
|
||||
|
||||
|
||||
#### 10d — Delete the Security Group
|
||||
|
||||
In **EC2 > Security Groups**, select `SG-ASG`, click **Actions > Delete security groups** and confirm.
|
||||
|
||||
|
||||
|
||||
All resources from this lab have been deleted.
|
||||
|
||||
---
|
||||
|
||||
## Key Concepts Learned
|
||||
|
||||
- **Auto Scaling Group (ASG):** Automatically maintains a desired number of EC2 instances. If an instance fails or is terminated, the ASG replaces it to keep the fleet at the desired count.
|
||||
- **Launch Template:** A reusable configuration blueprint (AMI, instance type, security group, user data) used by the ASG to provision identical instances on demand — eliminating manual configuration.
|
||||
- **Desired / Min / Max Capacity:** Defines the target fleet size (Desired), the floor (Min), and the ceiling (Max) the ASG will operate between.
|
||||
- **ELB Health Checks:** When enabled, the ASG uses the load balancer's perspective of instance health (is the instance passing HTTP checks?) rather than just EC2 status (is the instance running?). This catches application-level failures.
|
||||
- **Auto-Healing:** ASG automatically replaces any instance the ELB marks as unhealthy — no manual action required.
|
||||
- **Multi-AZ Deployment:** Distributing instances across multiple Availability Zones ensures the application survives a single AZ failure.
|
||||
- **Instance Maintenance Policy:** Controls whether the ASG launches a replacement before or after terminating an unhealthy instance during rebalancing events.
|
||||
Reference in New Issue
Block a user