Self-Healing Auto-Scaling Web App on AWS

Deploy a fleet of EC2 instances that scale automatically based on CPU load.

Introduction

30 Second Summary

When your favorite online store crashes during a flash sale, that is a scaling failure. Production applications need to handle unpredictable traffic without anyone manually adding servers at 2 a.m.

In this project, you will deploy a self-healing, auto-scaling web application on AWS that automatically adds servers when traffic spikes and removes them when things calm down.

What You'll Build

You will create EC2 instances running Apache web servers behind an Application Load Balancer, configured with an Auto Scaling Group that scales based on CPU utilization.

By the end of this project, you'll have:

A Launch Template defining your web server configuration with a user data script that automatically installs and configures Apache.
An Application Load Balancer distributing traffic across instances in multiple Availability Zones.
An Auto Scaling Group with a target tracking scaling policy that automatically scales your fleet up and down based on CPU utilization.
Secret Mission: Add CloudWatch alarms with SNS email notifications that alert you when scaling events occur.

Are there any prerequisites?

You need an AWS account with Free Tier eligibility. If you do not have one yet, create a free account at aws.amazon.com before starting.

Set Up Your Environment

Before you can build auto-scaling infrastructure, you need a secure foundation. Every EC2 instance in your fleet needs a way for you to connect to it, and a set of firewall rules controlling what traffic can reach it.

In this step, you will sign into the AWS Management Console, create a key pair for SSH access, and configure a security group that allows web traffic. These are the building blocks every instance in your Auto Scaling Group will use.

In this step, get ready to:

Sign in to the AWS Console and set your region.
Create a key pair for SSH access to your instances.
Create a security group that controls inbound traffic to your web servers.

Sign in to the AWS Console and set your region

A Region is a geographic area containing multiple data centres. You will deploy all your resources in the same region so they can communicate with low latency.

Open https://console.aws.amazon.com/ in your browser and sign in to your AWS account.
In the top-right navigation bar, click the region dropdown.
Select Europe (London) eu-west-2.

Why eu-west-2?

The eu-west-2 region (London) has full Free Tier support and no opt-in requirement. It is geographically close to Nigeria, which means lower latency for testing.

Create a key pair

A key pair lets you SSH into your instances for troubleshooting. The private key file is like a physical key to your servers.

In the AWS Console search bar at the top, type EC2 and select EC2 from the results.
In the left sidebar, expand Network & Security and click Key Pairs.
Click Create key pair.
Enter auto-scaling-key in the Name field.
For Key pair type, select RSA.
For Private key file format, select .pem.
Click Create key pair.

The .pem file downloads automatically to your ~/Downloads folder.

Secure the key file by running this command in your terminal:

chmod 400 ~/Downloads/auto-scaling-key.pem

What does this command do?

The chmod 400 command sets the file permissions so that only you (the owner) can read it. SSH refuses to use key files that other users on the system can access.

Confirm the permissions were set correctly by running:

ls -l ~/Downloads/auto-scaling-key.pem

You should see -r-------- at the beginning of the output, confirming only the owner has read access.

File not found?

If you see a "No such file or directory" error, your browser may have saved the file with a different name or to a different location. Check your ~/Downloads folder for a file ending in .pem and adjust the path accordingly.

Help me find my downloaded key pair file.

Create a security group for the web servers

A Security Group is a virtual firewall that controls what traffic can reach your instances. You need to allow HTTP traffic so the load balancer can reach your web servers, and SSH so you can connect for the stress test later.

In the EC2 left sidebar, expand Network & Security and click Security Groups.
Click Create security group.
Enter web-server-sg in the Security group name field.
Enter Allow HTTP from ALB and SSH for management in the Description field.
For VPC, select the default VPC (it is pre-selected in most accounts).

Now add the inbound rules that define what traffic can enter your instances.

In the Inbound rules section, click Add rule.
Set Type to HTTP. This automatically sets Port to 80.
Set Source to Anywhere-IPv4 (0.0.0.0/0).
Click Add rule again to add a second rule.
Set Type to SSH. This automatically sets Port to 22.
Set Source to My IP. This restricts SSH access to your current IP address only.

Leave the Outbound rules section at its default (All traffic to 0.0.0.0/0).
Click Create security group.

You should see a success banner at the top of the page confirming that web-server-sg was created.

Why two inbound rules?

The HTTP rule (port 80) lets the load balancer send web traffic to your instances. Without it, users would never see your web page.

The SSH rule (port 22) lets you connect directly to an instance for the stress test in Step 5. Restricting SSH to "My IP" means only your computer can connect, which is a security best practice.

Don't see the default VPC?

If the VPC dropdown is empty, your account may not have a default VPC in eu-west-2. Navigate to the VPC console and click Actions then Create default VPC to restore it.

Help me restore my default VPC.

Your environment is ready. Next up, you will create a Launch Template that tells Auto Scaling exactly how to build each web server in your fleet.

Create a Launch Template

Your security group and key pair are ready. Now you need to define exactly how each web server instance will be configured when it launches.

A Launch Template is a blueprint that tells Auto Scaling how to create identical servers. Every time your fleet needs a new instance, it uses this blueprint to spin one up with the same operating system, instance size, security rules, and startup script.

In this step, get ready to:

Configure a Launch Template with your instance settings.
Add a user data script that installs and configures Apache.
Verify the template is ready for Auto Scaling.

Create the launch template

In the left sidebar of the EC2 console, click Instances, then Launch Templates.
Click Create launch template.
In the Launch template name field, enter web-server-template.
Check the box that says Provide guidance to help me set up a template that I can use with EC2 Auto Scaling.
Under Application and OS Images, click Quick Start.
Choose Amazon Linux 2023 AMI (marked Free tier eligible).
Under Instance type, select t2.micro (Free tier eligible).
Under Key pair (login), select auto-scaling-key from the dropdown.
Under Network settings > Firewall (security groups), select Select existing security group.
Choose web-server-sg from the list.

Why these settings?

Amazon Linux 2023 is AWS's own lightweight Linux distribution, optimized for cloud workloads. The t2.micro instance type gives you 1 vCPU and 1 GB of RAM, which is plenty for a simple web server and qualifies for the Free Tier.

By attaching your key pair and security group here, every instance that launches from this template will automatically have SSH access and allow HTTP traffic.

Add a user data script

User data is a startup script that runs automatically when an instance first boots. You will use it to install a web server and create a custom page without ever needing to SSH in.

Scroll down and expand Advanced details at the bottom of the page.
Scroll to the User data text box at the very bottom.
Paste the following script into the User data field:

#!/bin/bash
dnf install -y httpd
systemctl start httpd
systemctl enable httpd
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id)
echo "<h1>Hello from instance: $INSTANCE_ID</h1><p>This page is served by an Auto Scaling group behind a Load Balancer.</p>" > /var/www/html/index.html

What does this script do?

dnf install -y httpd installs Apache (the web server) using Amazon Linux 2023's package manager.
systemctl start httpd starts Apache immediately. systemctl enable httpd ensures it restarts automatically if the instance reboots.
The TOKEN and INSTANCE_ID lines use IMDSv2 (the secure metadata service) to ask "who am I?" and get the instance's unique ID.
The final echo line writes a custom HTML page to /var/www/html/index.html so you can see which instance is serving each request.

Click Create launch template.

Don't see Advanced details?

Make sure you scroll all the way to the bottom of the Create launch template page. Advanced details is a collapsible section that appears below Network settings. Click the section header to expand it.

If the page is not loading correctly, confirm you are still in the eu-west-2 region using the dropdown in the top-right corner.

Help me troubleshoot my launch template creation.

Verify your launch template

You should see a green success banner with a link to your new template web-server-template.
Click the template ID link to open it and confirm the details match what you configured.

Why does a Launch Template matter?

Without a template, you would need to manually configure every new instance. With one, Auto Scaling can launch identical servers on demand without any human intervention.

Every instance created from this template will boot up, install Apache, and start serving your custom web page automatically. This is what makes auto-scaling possible.

✔️ Awesome, I've got everything!

Great. Double check that your template shows Amazon Linux 2023, t2.micro, auto-scaling-key, and web-server-sg in the template summary.

ⓧ I'd like to double check the full code

Here is the complete user data script that should be in your launch template:

#!/bin/bash
dnf install -y httpd
systemctl start httpd
systemctl enable httpd
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id)
echo "<h1>Hello from instance: $INSTANCE_ID</h1><p>This page is served by an Auto Scaling group behind a Load Balancer.</p>" > /var/www/html/index.html

Your blueprint is locked in. Next, you will create an Application Load Balancer that distributes incoming traffic across multiple instances launched from this template.

Create an Application Load Balancer

Your Launch Template is ready to stamp out identical web servers on demand. But right now, there is no front door for users to reach those servers.

In this step, you will create an Application Load Balancer that sits between users and your fleet of servers. The ALB receives all incoming traffic and distributes it evenly across healthy instances, so no single server gets overwhelmed.

In this step, get ready to:

Create a Target Group that defines where the load balancer sends traffic.
Create an Application Load Balancer spanning two Availability Zones.
Copy the ALB DNS name so you can access your application.

Create a Target Group

Before creating the load balancer itself, you need a Target Group. This tells the ALB which instances to send traffic to and how to check if they are healthy.

In the left sidebar of the EC2 console, scroll down to Load Balancing.
Click Target Groups.
Click Create target group.
For Target type, select Instances.
Enter web-server-tg in the Target group name field.
Set Protocol to HTTP and Port to 80.
For VPC, select your default VPC.
Under Health checks, confirm Health check protocol is set to HTTP.
Set Health check path to /.
Click Next.
Do not register any targets manually. Click Create target group.

What is a Target Group?

A target group defines where the load balancer sends traffic and how it checks if instances are healthy. The / health check means the ALB will request your home page every 30 seconds to confirm each instance is alive.

You skipped registering targets because the Auto Scaling Group will handle that automatically in the next step.

You should see a success banner confirming your target group was created.

Don't see the success banner?

Make sure you selected the default VPC. If no VPC appears in the dropdown, confirm your region is still set to eu-west-2 in the top-right corner of the console.

Help me troubleshoot my target group creation.

Create the Application Load Balancer

Now you will create the ALB itself. This is the entry point that users hit when they visit your application. It distributes requests across healthy instances in multiple Availability Zones.

In the left sidebar under Load Balancing, click Load Balancers.
Click Create load balancer.
In the Application Load Balancer card, click Create.
Enter web-server-alb in the Load balancer name field.
Set Scheme to Internet-facing.
Set IP address type to IPv4.

Next, configure the network mapping so your ALB spans multiple data centres.

Under Network mapping, select your default VPC.
Check the boxes for at least two Availability Zones: eu-west-2a and eu-west-2b.

Why two Availability Zones?

Each Availability Zone is a separate data centre within the eu-west-2 region. Spreading your application across two zones means it stays online even if an entire data centre fails.

Now configure the security group and listener.

Under Security groups, remove the default security group.
Select web-server-sg from the dropdown.
Under Listeners and routing, confirm the protocol is HTTP and port is 80.
In the Default action dropdown, select web-server-tg to forward traffic to your target group.
Click Create load balancer.

You should see a success message confirming your load balancer is being provisioned.

Seeing an error about security groups?

Confirm you removed the default security group before adding web-server-sg. Also check that your region is still eu-west-2. Security groups from other regions will not appear in the dropdown.

Help me fix my load balancer security group configuration.

Note the ALB DNS name

Your load balancer has a unique DNS name that acts as the public URL for your application. You will use this to test your setup in the next step.

Click View load balancer on the success page, or navigate to EC2 > Load Balancers and select web-server-alb.
In the Description section, find the DNS name field.
Copy the full DNS name (it looks something like web-server-alb-123456789.eu-west-2.elb.amazonaws.com).
Save this somewhere you can easily find it. You will paste it into your browser in the next step.

Why does the ALB show 503 right now?

If you try visiting the DNS name now, you will see a 503 Service Unavailable error. This is expected. The ALB has no instances registered in its target group yet.

In the next step, you will create an Auto Scaling Group that automatically registers instances with this target group.

Your load balancer is provisioned and waiting for traffic. In the next step, you will create an Auto Scaling Group that launches instances and registers them with this ALB automatically.

Create an Auto Scaling Group

Your Application Load Balancer is ready and waiting for traffic. Right now it returns a 503 error because no instances are registered behind it.

In this step, you will create an Auto Scaling Group that automatically launches EC2 instances, registers them with your load balancer, and scales them up or down based on CPU usage. This is the core of cloud resilience.

In this step, get ready to:

Create an Auto Scaling Group with a target tracking scaling policy.
Watch your instances launch and pass health checks.
Test the load balancer by seeing different instance IDs on each refresh.

Create the Auto Scaling Group

An Auto Scaling Group (ASG) is the engine that manages your fleet of EC2 instances. You tell it how many instances you want running, and it maintains that count automatically. If an instance fails, the ASG replaces it.

In the left navigation pane of the EC2 console, scroll down to Auto Scaling and click Auto Scaling Groups.
Click Create Auto Scaling group.
For Auto Scaling group name, enter web-server-asg.
For Launch template, select web-server-template.
Click Next.

You are now on the instance launch options page where you configure networking.

Under Network, for VPC, select the default VPC.
For Availability Zones and subnets, select the same two AZs you chose for the ALB: eu-west-2a and eu-west-2b.
Click Next.

You are now on the Configure advanced options page where you attach your load balancer.

Under Load balancing, choose Attach to an existing load balancer.
Select Choose from your load balancer target groups.
From the dropdown, select web-server-tg.
Under Health checks, check the box for Turn on Elastic Load Balancing health checks.
Click Next.

Why turn on ELB health checks?

By default, Auto Scaling only checks whether an instance's OS is running. With ELB health checks enabled, the ASG also considers whether the load balancer can reach your web server on port 80.

If Apache crashes but the instance is still running, the ELB health check catches it and the ASG replaces the instance automatically.

You are now on the Configure group size and scaling policies page.

Under Group size, set Desired capacity to 2.
Under Scaling, set Min desired capacity to 1.
Set Max desired capacity to 4.
Under Automatic scaling, select Target tracking scaling policy.
For Scaling policy name, enter cpu-target-tracking.
For Metric type, select Average CPU utilization.
For Target value, enter 50.
Click Next through the remaining pages (notifications, tags) without making changes.
On the Review page, click Create Auto Scaling group.

What is a target tracking scaling policy?

A target tracking policy works like a thermostat. You set a target (50% average CPU), and the ASG automatically adds or removes instances to keep the metric near that value.

When CPU rises above 50%, the ASG launches new instances to share the load. When it drops below, it terminates the extras. You never have to write if/else scaling rules yourself.

Watch instances launch

The ASG immediately starts launching instances to meet the desired capacity of 2.

In the left navigation pane, click Instances under the Instances section.
Within 1-2 minutes, you should see 2 new instances appearing with their state showing Pending and then Running.
Wait until both instances show Instance state: Running and Status checks: 2/2 checks passed.

What just happened?

The Auto Scaling Group used your Launch Template to create 2 identical EC2 instances. Each one ran your user data script, which installed Apache and created the Hello page.

The ASG also automatically registered both instances with the web-server-tg target group. Once they pass health checks, the ALB starts sending traffic to them.

Instances stuck in Pending?

If your instances stay in Pending for more than 3 minutes, check that your security group web-server-sg allows outbound traffic (needed to download packages). Also confirm you selected the default VPC and not a custom VPC without internet access.

help me troubleshoot why my Auto Scaling instances are not launching

Test the load balancer

Now that your instances are running and registered, the ALB should be serving your web page.

Open a new browser tab.
Paste the ALB DNS name you copied in the previous step (it looks like web-server-alb-123456789.eu-west-2.elb.amazonaws.com).
You should see a page that says "Hello from instance: i-xxxxx" with a message about Auto Scaling.
Refresh the page several times.

The instance ID in the heading should change between your 2 instances on each refresh. This proves the load balancer is distributing traffic across your fleet.

Why does the instance ID change?

The ALB uses a round-robin algorithm to distribute requests across all healthy instances in the target group. Each time you refresh, your request may land on a different server.

This is the foundation of horizontal scaling. Instead of making one server bigger, you spread the load across many identical servers.

Still seeing 503 Service Unavailable?

If the ALB still shows a 503 error, your instances may not have passed health checks yet. Go to EC2 > Target Groups > web-server-tg and check the Targets tab. Both instances should show healthy. If they show initial, wait another minute for health checks to complete.

help me fix my ALB showing 503 when my Auto Scaling instances should be running

Your auto-scaling infrastructure is live. Next up, you will stress-test it and watch the ASG scale out in real time.

Stress Test and Watch Auto Scaling

Your load balancer is distributing traffic across two healthy instances. The infrastructure is live, but you haven't proven the most important part yet: does it actually scale?

In this step, you will spike CPU on one instance to trigger the target tracking policy. You will watch the Auto Scaling Group launch new instances automatically, then observe it scale back in when load drops. Finally, you will prove self-healing by killing an instance and watching it get replaced.

In this step, get ready to:

SSH into a running EC2 instance and install a CPU stress tool.
Trigger a scale-out event by spiking CPU above the 50% target.
Observe scale-in and self-healing behavior.

SSH into one instance and install stress

To generate CPU load, you need to connect directly to one of your running instances. The SSH protocol lets you open a terminal session on the remote server using the key pair you created earlier.

Return to the EC2 console.
In the left navigation, click Instances.
Select one of the two running instances.
In the Details tab at the bottom, find and copy the Public IPv4 address value.
Open your terminal and connect to the instance by running this command:

ssh -i ~/Downloads/auto-scaling-key.pem ec2-user@[[EC2_PUBLIC_IP="your instance's public IPv4 address"]]

What does this command do?

The -i flag points to your private key file. The ec2-user username is the default for Amazon Linux instances. Together they authenticate you with the server.

When prompted to confirm the host fingerprint, type yes and press Enter.
You should see a command prompt starting with [ec2-user@ip-...] confirming you are connected.
Install the stress utility by running:

sudo dnf install -y stress

What is the stress utility?

The stress tool generates artificial CPU load by spawning workers that continuously compute square roots. This simulates the traffic spike that would trigger auto scaling in production.

You should see output ending with Complete! confirming the package installed successfully.

Can't connect via SSH?

Make sure you are using the Public IPv4 address, not the Private IP.
Confirm your security group web-server-sg has an SSH rule with Source set to My IP. If your IP changed since you created the rule, update it.
Check that auto-scaling-key.pem has the correct permissions (chmod 400).

Why can't I SSH into my EC2 instance?

Run the stress test and observe scaling

Now you will push CPU to 100% and watch the target tracking policy respond in real time. The policy you configured targets 50% average CPU, so a sustained spike above that threshold will trigger a scale-out.

In the SSH session, start the stress test by running:

stress --cpu 4 --timeout 300

What does this command do?

This spawns 4 CPU-intensive workers that run for 300 seconds (5 minutes). On a t2.micro instance with 1 vCPU, this drives utilization to 100%.

The target tracking policy watches average CPU across all instances in the group. When the average exceeds 50%, Auto Scaling launches additional instances (up to your max of 4) to bring the average back down.

Leave the stress command running. Do not close your terminal.
Open a new browser tab and navigate to EC2 > Auto Scaling > Auto Scaling Groups.
Select web-server-asg.
Click the Activity tab.
Also click the Monitoring tab to watch the CPU utilization graph climb.
Wait 3-5 minutes. Refresh the Activity tab periodically.
You should see new entries under Activity history with a Status of Successful and a Description starting with "Launching a new EC2 instance".

What should I see?

The Activity tab shows scaling events in real time. Each entry includes the Cause (the alarm that triggered it), the Description (which instance was launched), and the Status. You should see 1-2 new instances launching, bringing your fleet from 2 up toward the maximum of 4.

On the Monitoring tab, the CPUUtilization graph will show a spike. After the new instances launch and start handling requests, the average CPU should begin dropping.

No new instances after 5 minutes?

Confirm the stress command is still running in your terminal. It outputs a message when it finishes.
Check the Monitoring tab. If CPU stays below 50% on the graph, the metric may not have been reported yet. Give it another 2-3 minutes.
Verify your scaling policy still shows Target value: 50 under Automatic scaling in the ASG details.

Why isn't my Auto Scaling Group launching new instances after the stress test?

Watch scale-in after the test and prove self-healing

The stress command runs for 5 minutes. After it finishes, CPU drops back to near zero. The target tracking policy will detect that average utilization is far below the 50% target and begin terminating excess instances.

Wait for the stress command to finish. You will see stress: info: messages in your terminal confirming completion.
Wait another 5-10 minutes after the stress finishes.
Refresh the Activity tab again.
You should see new entries with "Terminating EC2 instance" in the Description as Auto Scaling removes the extra instances.

Why does scale-in take longer than scale-out?

Auto Scaling is deliberately cautious about removing capacity. It waits to confirm that load has genuinely dropped (not just a momentary dip) before terminating instances. This prevents flapping, where instances are constantly launched and terminated in rapid succession.

Now prove self-healing. You will manually kill an instance and watch the ASG replace it to maintain desired capacity.

Navigate to EC2 > Instances.
Select one of the running instances that belongs to your ASG.
Click Instance state > Terminate instance.
Confirm the termination.
Return to Auto Scaling Groups > web-server-asg > Activity tab.
Within 1-2 minutes, you should see a new activity entry showing a replacement instance being launched.

What is self-healing?

The ASG continuously checks that the number of healthy instances matches the desired capacity (2). When you terminated an instance, the count dropped to 1. The ASG detected the shortfall and automatically launched a replacement to restore the desired count.

This is the core of cloud resilience. In production, if a server crashes, the ASG replaces it without any human intervention.

Replacement instance not appearing?

Make sure you terminated an instance that belongs to web-server-asg. Check the instance's tags for an aws:autoscaling:groupName tag matching your ASG.
Give it 2-3 minutes. The Activity tab may take a moment to update.

Why isn't my terminated instance being replaced by the Auto Scaling Group?

Secret mission

Add CloudWatch Alarms with Email Notifications

Your auto-scaling infrastructure works, but how would you know it scaled if you weren't watching the console? In production, teams need instant alerts when infrastructure changes. Add CloudWatch alarms with SNS email notifications so you get an email every time your fleet scales up or down.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Running 2 t2.micro instances 24/7 uses 1,440 hours per month, which exceeds the 750-hour monthly EC2 Free Tier allowance. The ALB also draws from a separate 750-hour monthly pool. If you are not actively experimenting, delete everything to avoid unexpected charges.

Cost warning

Your Auto Scaling Group is running 2 EC2 instances continuously. Together they consume 1,440 hours per month, nearly double the 750-hour Free Tier limit.

The Application Load Balancer has its own 750 free hours per month. If you leave both running beyond a single session, you will start accruing charges. Delete all resources as soon as you finish the project.

Resources you used:

Auto Scaling Group: web-server-asg (manages EC2 instances).
Application Load Balancer: web-server-alb.
Target Group: web-server-tg.
Launch Template: web-server-template.
Security Group: web-server-sg.
Key Pair: auto-scaling-key (AWS) and local auto-scaling-key.pem file.
CloudWatch Alarms: high-cpu-alarm and low-cpu-alarm (Secret Mission).
SNS Topic: scaling-alerts with email subscription (Secret Mission).

Keep everything running

No action needed. Choose this only if you plan to continue experimenting within the next few hours.

Be aware that your 2 running instances consume 1,440 hours per month, exceeding the 750-hour EC2 Free Tier.
The ALB is also drawing from its own 750-hour monthly pool while active.
Your CloudWatch alarms and SNS topic remain active but generate negligible cost.
The key pair, launch template, security group, and target group have no running cost on their own.

Pause - I'll come back to this later

Shut down your instances to stop hourly charges while keeping your configuration intact.

Navigate to EC2 > Auto Scaling Groups.
Select web-server-asg and click Edit.
Set Desired capacity to 0, Minimum capacity to 0, and Maximum capacity to 0.
Click Update. This terminates all instances but keeps your ASG, launch template, ALB, and all other configuration intact.
To resume later, edit the ASG and set Desired back to 2, Minimum to 1, and Maximum to 4.

What about the ALB?

The ALB continues to draw from its 750-hour monthly pool even with zero instances behind it. If you plan to pause for more than a few days, consider deleting the ALB as well and recreating it when you resume.

Delete - I don't want to use this again

Remove all project resources completely. Follow these steps in order, since some resources depend on others.

Delete the Auto Scaling Group: Navigate to EC2 > Auto Scaling Groups. Select web-server-asg and click Delete. This terminates all managed instances.
Delete the Load Balancer: Navigate to EC2 > Load Balancers. Select web-server-alb, then click Actions > Delete.
Delete the Target Group: Navigate to EC2 > Target Groups. Select web-server-tg, then click Actions > Delete.
Delete the Launch Template: Navigate to EC2 > Launch Templates. Select web-server-template, then click Actions > Delete template.
Delete the Security Group: Navigate to EC2 > Security Groups. Select web-server-sg, then click Actions > Delete security groups.
Delete the Key Pair: Navigate to EC2 > Key Pairs. Select auto-scaling-key, then click Actions > Delete.
Delete the local .pem file by running this in your terminal:

rm ~/Downloads/auto-scaling-key.pem

If you completed the Secret Mission, also delete these resources:

Delete CloudWatch Alarms: Navigate to CloudWatch > Alarms. Select both high-cpu-alarm and low-cpu-alarm, then click Actions > Delete.
Delete the SNS Topic: Navigate to SNS > Topics. Select scaling-alerts and click Delete.

Verify everything is gone

After deleting, navigate to EC2 > Instances and confirm no instances are running. Check Load Balancers and Auto Scaling Groups to confirm those pages are empty.

That's a Wrap!

Nice work! You just built a self-healing, auto-scaling web application on AWS. Your infrastructure can now handle traffic spikes automatically and recover from instance failures without any manual intervention.

You've learned how to:

Deploy a fleet of EC2 instances behind an Application Load Balancer that distributes traffic across multiple Availability Zones.
Configure an Auto Scaling Group with a target tracking scaling policy that scales your infrastructure up and down based on CPU utilization.
Prove self-healing by terminating an instance and watching the Auto Scaling Group replace it automatically.
Secret Mission: Set up CloudWatch alarms with SNS email notifications that alert you when scaling events occur.

Ready to quiz yourself?