Friday, June 12, 2026
Cohort 3 | Project CloudIgnite Topics: EC2 Auto Scaling (deep dive), Amazon Route 53, Amazon CloudFront, Lab 175 (CLI-based Auto Scaling lab) Duration: ~3 hours
Key Takeaways
- ASG anti-thrashing guards: cooldown period, warm-up period, alarm sustain period (default ~300s each)
- ASG termination policy "Terminate Newest First" — useful when a new server config fails and must be removed quickly
- To force ASG to launch new instances → increase the minimum capacity (ASG launches to meet the new floor)
- If all newly launched ASG instances are failing → the issue is in the Launch Template and/or AMI (they define instance config/behavior)
- Route 53 = AWS DNS service; can distribute traffic across regions (ALB only distributes within a region)
- Route 53 routing policies: Simple, Weighted, Latency-based, Failover, Geolocation (user's location), Geoproximity (physical distance), Multi-value, IP-based
- Geolocation vs Geoproximity vs Latency (commonly confused): Geolocation = where the user is; Geoproximity = physical distance; Latency = measured response time
- Amazon CloudFront = AWS CDN: uses global edge locations + regional edge caches to deliver static/dynamic content faster and reduce origin load
Table of Contents
- EC2 Auto Scaling — Continued Concepts
- Amazon Route 53
- Amazon CloudFront (CDN)
- Lab 175 — CLI-Based Auto Scaling Lab
- Checkpoint Questions Recap
- CLF-C02 Exam Relevance
1. EC2 Auto Scaling — Continued Concepts
Steady-State Group
- An Auto Scaling Group where Minimum = Maximum = Desired capacity.
- If an instance becomes unhealthy, Auto Scaling automatically replaces it with a new instance — core self-healing benefit of ASG.
Avoiding "Thrashing" (Repeated Scale In/Out)
| Mechanism | Description |
|---|---|
| Alarm Sustain Period | CloudWatch alarm must remain in breach for a specified duration before triggering a scaling action — avoids reacting to short spikes |
| Cooldown Period | After a scaling event completes, no new scaling action is triggered for a set time (e.g., 300 seconds) — even if scaling conditions are still met |
| Warm-Up Period | After a new instance launches, it is given time to become fully ready/configured before it's counted as "in service" (default: 300 seconds) |
Termination Policies & Scaling Behavior
- "Newest Instance First" termination policy: useful when a new server configuration fails and needs to be removed quickly from the ASG.
- To force new instances to launch: increase the minimum capacity of the ASG — ASG will automatically launch instances to meet the new minimum.
- If all newly launched instances are failing: the issue is likely in the Launch Template and/or the AMI — these define instance configuration/behavior and should be reviewed/updated.
2. Amazon Route 53
Overview
- Route 53 = AWS's DNS (Domain Name System) service.
- Functions:
- Register/purchase domain names
- Resolve domain names to IP addresses
- Connect infrastructure and distribute traffic across Regions (a key difference vs. ALB, which only distributes traffic within a single Region)
- Supports high availability and low latency
Architecture Concept
- Users request a custom domain → request goes to Route 53 → Route 53 resolves to a target DNS name (commonly an ELB DNS name, but can also be an EC2 instance DNS name or S3 bucket).
Routing Policies
| Policy | Description |
|---|---|
| Simple | Basic single-resource routing (no special logic) |
| Weighted | Distribute traffic by percentage across multiple resources (e.g., 10% to Server A, 90% to Server B) — useful when servers have different capacities |
| Latency-based | Routes traffic to the resource/region with the lowest latency for the user — not necessarily the geographically closest |
| Failover | Primary/secondary setup — if primary fails, traffic automatically routes to secondary |
| Geolocation | Routes based on the user's geographic location (e.g., users from Southeast Asia → Malaysia server) |
| Geoproximity | Routes to the physically closest resource (based on distance) |
| Multi-value answer | Returns up to 8 healthy records selected at random; includes health checking |
| IP-based | Routes based on the user's IP address to a specific endpoint |
Most emphasized for exam-style questions: Weighted, Failover, Geolocation, and Geoproximity (esp. distinguishing Geolocation vs. Geoproximity vs. Latency-based — these are commonly confused).
- Geolocation = based on where the request originates (user's location)
- Geoproximity = based on physical distance to resources
- Latency-based = based on measured response time, not physical distance
Practical Use Case: Blue-Green Deployment
- Two environments exist (e.g., "blue" = current, "green" = new).
- Route 53 (weighted routing) can gradually shift traffic from blue to green (e.g., 5% → 10% → 20% → 50% → 100%) instead of an instant cutover — reduces risk when rolling out new features.
Route 53 Targets
- Route 53 can route/connect to: Elastic Load Balancers (ALB), EC2 instances, and S3 buckets.
3. Amazon CloudFront (CDN)
Overview
- CloudFront = AWS Content Delivery Network (CDN) service that speeds up distribution of static and dynamic web content.
- Delivers content via a global network of Edge Locations (data centers around the world) plus Regional Edge Caches.
Key Features
- Security
- High availability / scalability
- Real-time metrics and logging
- Continuous deployment
- Cost-effectiveness (at scale)
Use Cases
- Fast & secure website delivery
- Accelerating dynamic content delivery / APIs
- Live and on-demand video streaming
- Distributing software patches and updates
Architecture / Flow
- Users never connect directly to the origin server.
- Request flow: User → Edge Location → Origin Server → Edge Location (cache) → User.
- For live streaming: the origin server maintains a connection only with the edge location (not with every individual viewer). The edge location then fans out the stream to all users.
- Edge locations have failover — if content isn't available at the nearest edge, the request is served from another edge location.
Cost Factors
CloudFront pricing is based on:
- Request type
- Geographic location of the edge location
- Amount of data transferred out of the AWS network
Cost-saving logic: fewer EC2 instances are needed to handle direct connections because CloudFront edge locations absorb most of the traffic.
4. Lab 175 — CLI-Based Auto Scaling Lab
Goal: Recreate a scalable web server setup using the AWS CLI, then build an Auto Scaling Group with a Launch Template and Application Load Balancer.
High-Level Steps
- Connect to the Command Host instance via EC2 Instance Connect.
- If connection fails: check that the Security Group allows SSH.
- Configure AWS CLI (
aws configure) — region was pre-set to us-west-2; access key/secret key fields could be left blank (already configured). - Launch a new EC2 instance via CLI using a prepared command including:
--image-id(AMI ID)--instance-type t3.micro--key-name--subnet-id--security-group-ids(HTTP Access security group)--region us-west-2- User data: a bash script that runs automatically on launch
- Tip: if the CLI command is on a single line, use
\(backslash) line continuations after each parameter, or write the whole command on one line.
- Save important IDs/values as shell variables (e.g.,
EC2ID=<instance-id>,AMIID=<ami-id>). - Retrieve the public DNS name of the new instance via a CLI query using the instance ID; test the web server in a browser using
http://<public-dns>(must use HTTP, not HTTPS; try Incognito mode if cached results interfere). - Create an AMI from the running "web server" instance (CLI step ~25) — save the resulting AMI ID as a variable for later use.
- Create an Application Load Balancer (ALB):
- Internet-facing, IPv4
- VPC = Lab VPC
- Subnets = Availability Zone 1 & 2 public subnets
- Security Group = HTTP Access (not default)
- Create a Target Group:
- Target type = Instance
- Protocol HTTP, Port 80
- Health check path =
/index.php
- Create a Launch Template:
- Use the custom AMI created in step 6
- Instance type = t3.micro
- Security Group = HTTP Access
- Default storage settings (gp2) are fine
- Create an Auto Scaling Group from the Launch Template:
- VPC = Lab VPC, Subnets = private subnet 1 & 2
- Attach the existing ALB and select the target group created above
- Enable ELB health checks
- Desired capacity = 2, Minimum = 2, Maximum = 4
- Scaling policy = Target Tracking, metric = CPU Utilization at 50%
- Instance warm-up = default 300 seconds
- Tag: Name =
web app
- Test Auto Scaling: use the load balancer's DNS name to access the "Start Stress / Stop Stress" test page. Generating CPU load triggers the CloudWatch alarm (CPU > 50%) → ASG launches two additional EC2 instances.
Common Troubleshooting Notes from the Lab
- "502 Bad Gateway" errors typically trace back to a problem with the original EC2 instance/AMI — since the launch template and ASG instances are duplicated from it, errors propagate downstream.
- CLI query errors are often caused by: missing backslashes for line continuation, missing spaces between parameters, or unintended line breaks.
- Scaling actions are not instantaneous — there's a delay before new instances appear after an alarm triggers.
5. Checkpoint Questions Recap
| Question | Answer / Concept |
|---|---|
| New server config might fail — which termination policy lets you quickly remove it? | Terminate newest instance first |
| How to force a new EC2 instance to launch in an ASG? | Increase the minimum capacity |
| All newly created ASG instances are failing — what should be checked? | Launch Template and AMI |
| Three ways to avoid scaling "thrashing"? | Cooldown period, Warm-up period, Alarm sustain period |
| Blue-green deployment, gradually shift traffic — which Route 53 policy? | Weighted routing policy |
| Scaling policy that reacts based on the size of a CloudWatch alarm breach? | Step scaling policy |
| Route users to the closest region — which Route 53 policy? | Geolocation |
| Users complain of slow response after geolocation routing — which policy addresses this? | Latency-based routing |
| AWS service that speeds up content delivery via edge locations (CDN)? | Amazon CloudFront |
| ELB type to distribute requests to EC2 instances in a VPC? | Application Load Balancer (ALB) — CLB is legacy/deprecated |
| ALB component that checks for incoming connection requests from clients? | Listener |
6. CLF-C02 Exam Relevance
| Topic | CLF-C02 Domain | Relevance |
|---|---|---|
| EC2 Auto Scaling (policies, cooldown/warm-up/alarm sustain, termination policies, launch templates, capacity settings) | Cloud Technology & Services | High — frequently tested for elasticity and HA |
| Amazon Route 53 (DNS, 8 routing policies) | Cloud Technology & Services | High — especially the differences between geolocation, geoproximity, and latency |
| Amazon CloudFront (CDN, edge locations, static/dynamic content, streaming) | Cloud Technology & Services | High — global infrastructure benefits |
| Elastic Load Balancing (ALB) (distinguishing from CLB, listeners, target groups, health checks) | Cloud Technology & Services | High — core exam topic |
| AWS CLI (programmatic access) | Cloud Technology & Services | Medium — deployment and management methods |
| AWS Global Infrastructure (Regions, AZs, Edge Locations) | Cloud Concepts | High — reinforced through Route 53 cross-region routing and CloudFront edge locations |
High-priority review items for CLF-C02:
- ASG cooldown vs. warm-up vs. alarm sustain period
- Route 53 routing policy differences (esp. geolocation vs. geoproximity vs. latency)
- CloudFront edge locations and why they reduce latency/improve availability
- ALB vs. Classic Load Balancer (CLB is legacy)
Notes compiled from Cohort 3 Project CloudIgnite lecture transcript — June 12, 2026.