Thursday, June 11, 2026

Cohort 3 | Project CloudIgnite Topics: Elastic Load Balancing (deep dive), Auto Scaling Groups, Lab 173 (EC2 LAMP deployment troubleshooting script), Lab 174 (ALB + Auto Scaling Group build with load testing) Duration: ~3 hours

Key Takeaways

• ELB types: ALB (L7, HTTP/HTTPS, path-based routing), NLB (L4, TCP/UDP, extreme performance/low latency), GWLB (L3/4, third-party security appliances), CLB (legacy — avoid)
• Auto Scaling Group (ASG) maintains desired instance count and scales in/out based on demand; pairs with ELB for high availability
• ASG capacity: Minimum (floor), Desired (target), Maximum (ceiling)
• Shared database (RDS) is critical — ASG instances are ephemeral, so data must live in centralized storage to survive scale-in
• Decoupled architecture: ALB in public subnets, application servers in private subnets (not directly reachable)
• AMI → Launch Template → ASG: the custom AMI in the launch template makes new instances identical
• CloudWatch alarms (e.g., CPU > 50%) trigger ASG scaling actions
• Service-linked IAM role for Auto Scaling may be required for ASG + CloudWatch integration to work

Table of Contents

1. Elastic Load Balancing (ELB) — Deep Dive
2. Auto Scaling Groups (ASG)
3. Decoupled / Scalable Architecture Concepts
4. Lab 173 — Troubleshooting the LAMP EC2 Deployment Script
5. Annotated Walkthrough of create-ec2.txt
6. Lab 174 — Building an Auto Scaling Group Behind an ALB
7. Useful Vim/Nano & CLI Commands
8. CLF-C02 Exam Relevance

1. Elastic Load Balancing (ELB) — Deep Dive

ELB distributes incoming application traffic across multiple targets (EC2 instances, containers, IP addresses) in one or more Availability Zones, increasing fault tolerance and availability.

Types of Load Balancers

Key ALB Features

• Path-based routing (e.g., /auth → instance group 1, /posts → instance group 2)
• Health checks: continuously monitors whether EC2 instances are healthy
• TLS termination: ALB decrypts incoming traffic so backend servers don't need to handle SSL/TLS overhead
• Active-active design across multiple EC2 instances/AZs

Scenario-Based Selection Rule of Thumb

• Normal website → ALB
• Massive sudden traffic bursts / gaming / extreme low-latency → NLB
• Need to route traffic through a security appliance for packet inspection → GWLB
• Legacy systems only → CLB (avoid for new designs)

2. Auto Scaling Groups (ASG)

Why ASGs Are Needed

ELB alone only distributes traffic across existing instances — it does not add or remove instances. Auto Scaling Groups maintain the desired number of EC2 instances and automatically scale in/out based on demand.

Typical Architecture Flow

Route 53 (DNS) → Elastic Load Balancer → EC2 Instances (in an Auto Scaling Group) → RDS (shared database)

Why a Shared Database (RDS) Matters

• If application data is stored locally on an individual EC2 instance, and the ASG terminates that instance during scale-in, the data is lost.
• Best practice: use a centralized RDS database so all EC2 instances share consistent data.

Scaling Policy Types

• Target tracking scaling policy – e.g., maintain CPU utilization at 50%; if CPU > 50%, ASG launches more instances
• Based on number of requests
• Based on a CloudWatch alarm
• Scheduled scaling – e.g., scale down overnight in regions with predictably low traffic

Capacity Settings

• Minimum capacity – the floor; ASG will never go below this number of instances
• Desired capacity – the target number of instances under normal conditions
• Maximum capacity – the ceiling; ASG will never exceed this number

Lab 174 example values: Minimum = 2, Desired = 2, Maximum = 4, Target Tracking on CPU Utilization = 50%

3. Decoupled / Scalable Architecture Concepts

• Decoupling: Client requests go to the Load Balancer first, not directly to application servers. Application servers can live in private subnets (not publicly reachable).
• Stateless application design: Because ASG can terminate instances at any time during scale-in, instances should not store unique/critical data locally — use a shared database (RDS) or external storage.
• Microservices: Different EC2 instances/target groups can handle different responsibilities, with the ALB routing based on URL path.
• Static/media content (video, images, audio) is generally better served via Amazon S3 + CDN rather than from application servers.

4. Lab 173 — Troubleshooting the LAMP EC2 Deployment Script

Lab Setup Steps

1. Connect to a CLI host EC2 instance using EC2 Instance Connect.
2. Configure AWS CLI with aws configure:
   • Access Key ID
   • Secret Access Key
   • Default region
   • Output format (JSON)
3. Locate the provided script create-lamp-instance...sh and create a backup copy before editing.
4. Use vim (with :set number to show line numbers) to review the script.

Issue 1: Hardcoded/Incorrect Region

• The script contained a hardcoded region (us-east-1) that did not match the actual working region (us-west-2).
• Fix: Edit the script in vim and replace the hardcoded region string with the $region variable that the script already derives dynamically, so the script becomes region-agnostic.

Issue 2: Wrong Port in Security Group (8080 vs 80)

• After running the script successfully, the resulting website was unreachable.
• Used nmap to scan open ports on the public IP:
  • sudo yum install -y nmap
  • nmap -Pn <public-ip> → scans all ports, showing port 22 and 8080 open, but port 80 closed
• Root cause: The script opened port 8080 instead of port 80 in the security group ingress rule.
• Two ways to fix:
  1. Edit the security group inbound rule directly in the AWS console — change the rule type from "Custom TCP / 8080" to HTTP (port 80).
  2. Edit the script itself (change 8080 → 80) so the security group is created correctly the next time the script runs.
• Once port 80 is open, the LAMP "Cafe" web app becomes accessible at: http://<public-ip>/cafe

Additional Notes from the Lab

• HTTPS will not work simply by opening port 443 in the security group — an SSL/TLS certificate must also be installed/configured on the server.
• The outbound rule should remain "All traffic" (default) — no change needed.
• If an EC2 instance is terminated, it cannot be recovered (unlike "stopped," which can be restarted).

5. Annotated Walkthrough of create-ec2.txt

Key takeaways for understanding automation scripts:

• Most of the script's logic is dedicated to discovering required resource IDs dynamically via CLI queries rather than hardcoding them.
• Only the final aws ec2 run-instances command actually creates the resource — everything before it gathers the inputs needed.
• Scripts like this are idempotent-aware: they check for and optionally clean up pre-existing resources before re-running.

6. Lab 174 — Building an Auto Scaling Group Behind an ALB

High-Level Steps

1. Create an AMI from the existing configured EC2 instance (Actions → Image and templates → Create image). This "Web Server AMI" is later used to launch identical new instances.
2. Create a service-linked IAM role for Auto Scaling (IAM → Roles → Create role → AWS service → use case = EC2 Auto Scaling). May be required for the ASG to function correctly with CloudWatch alarms.
3. Create an Application Load Balancer:
   • Choose Application Load Balancer (not Network or Gateway)
   • Name it (e.g., Lab ELB)
   • Network mapping: select the lab VPC (not default VPC), both Availability Zones, and public subnets
   • Security group: use the existing web security group (not default)
   • Create a new target group (target type = instances, protocol HTTP, port 80)
   • Note/copy the ALB's DNS name — this is the URL used to test the app
4. Create a Launch Template:
   • Provide name/description
   • Instance type: t3.micro
   • Do not include a key pair in the launch template
   • Select the web security group
   • Select the custom AMI created in step 1 (critical — easy to miss this step)
5. Create the Auto Scaling Group from the launch template:
   • Network: lab VPC, private subnets (1 and 2) — application instances run in private subnets behind the ALB
   • Attach to the existing load balancer → select the target group created above
   • Enable Elastic Load Balancing health checks
   • Set capacity: Minimum = 2, Desired = 2, Maximum = 4
   • Scaling policy: target tracking, metric = CPU Utilization, target = 50%
   • Add a tag: Key = Name, Value = e.g. lab instance
6. Verify:
   • After creation, check EC2 console — instance count should increase to match the ASG's desired capacity
   • Open the ALB's DNS name in a browser to confirm the app is reachable
7. Load Testing:
   • The lab's web app includes a "load test" button that artificially raises CPU utilization (observed reaching ~70%+)
   • In CloudWatch → Alarms, an alarm should trigger once CPU exceeds the 50% target, causing the ASG to launch additional instances (scale-out)
   • May take a few minutes for the alarm state to update — refresh periodically

Troubleshooting Notes from the Lab

• If no CloudWatch alarm appears after load testing, it may be related to the service role for Auto Scaling not being created correctly — recreating the ASG (delete and re-create) sometimes resolves it.

7. Useful Vim/Nano & CLI Commands

8. CLF-C02 Exam Relevance

Bottom line: Today's lecture ties together several CLF-C02 "Cloud Architecture" pillars into one coherent picture — ELB + ASG + RDS + VPC subnetting — a very common pattern in exam scenario questions (e.g., "A company needs a fault-tolerant, scalable web application...").

Notes compiled from Cohort 3 Project CloudIgnite lecture transcript — June 11, 2026.