Smarter Scaling: Automating EC2 with CloudWatch

1. Automated Instance Launch (Bootstrapping)

While beginners manually install software via RDP, advanced DevOps engineers use User Data to "bootstrap" instances. This allows the server to configure itself immediately upon launch, reducing manual toil and human error.

Step-by-Step Configuration:

1. Navigate to the EC2 Dashboard and select Launch Instance.
2. AMI & OS: Select Windows Server 2022 Base. We choose "Base" to retain the GUI for this tutorial, though "Core" is preferred for production to reduce attack surface.
3. Instance Type: Select t2.micro (or t3.medium for faster processing).
4. Network Strategy:

   Ensure you select a VPC and a specific Public Subnet (e.g., us-east-1a). Enable Auto-assign Public IP.

<powershell>
# Install IIS Role including Management Tools
Install-WindowsFeature -name Web-Server -IncludeManagementTools

# Create the specific HTML file for the Load Balancer to check
$Content = "<h1>Server A - US-East-1A</h1><p>Bootstrapped via PowerShell</p>"
Set-Content -Path "C:\inetpub\wwwroot\index.html" -Value $Content
</powershell>

2. Verify IIS and Security Groups

Security in AWS is handled via Security Groups, which act as a virtual stateful firewall. Unlike Network ACLs (NACLs), you only need to allow inbound traffic; outbound is allowed by default.

• Create Security Group: Name it production-web-sg.
• Inbound Rule 1 (Traffic): Allow HTTP (Port 80) from 0.0.0.0/0 (Anywhere).
• Inbound Rule 2 (Management): Allow RDP (Port 3389) only from your IP.

Once the instance state is Running, paste the Public IP into your browser. If the PowerShell script worked, you will see "Server A - US-East-1A" immediately, without ever logging in.

3. Creating a "Golden Image" (AMI)

To scale horizontally, we cannot manually configure every new server. We capture the current state of our server into an AMI (Amazon Machine Image). This allows us to spawn identical clones in seconds.

1. Select your running instance.
2. Go to Actions > Image and templates > Create image.
3. Name it v1-iis-golden-image.
4. AWS will reboot the instance to ensure data integrity during the snapshot process.

4. Launching into a Second Availability Zone

High Availability requires physical separation. We will launch a second server into a different Availability Zone (AZ) to protect against data center failures.

The Strategy:

1. Go to the AMIs section in the left sidebar.
2. Right-click your new v1-iis-golden-image and select Launch Instance from AMI.
3. Critical Step: Select a different subnet (e.g., us-east-1b).
4. User Data Modification: In the User Data for this second instance, change the HTML content to say Server B - US-East-1B. This will help us visually verify that the Load Balancer is doing its job later.

5. Configuring the Application Load Balancer (ALB)

The Application Load Balancer operates at Layer 7 of the OSI model. It inspects incoming HTTP traffic and routes it to healthy targets (our EC2 instances).

A. Configure Target Group

The ALB doesn't point to servers directly; it points to a Target Group.

1. Navigate to Target Groups > Create Target Group.
2. Select Instances.
3. Health Check Protocol: This is critical. The ALB will ping /index.html on Port 80. If it doesn't get a "200 OK" response, it stops sending traffic to that server.
4. Register both Instance A and Instance B.

B. Configure Load Balancer

1. Create an Application Load Balancer (Internet-facing).
2. Network Mapping: Select your VPC and check both subnets used (us-east-1a and us-east-1b).
3. Security Group: Create a new SG for the ALB that allows HTTP 80 from Anywhere.
4. Listener: Set Port 80 to forward to your new Target Group.