Wednesday, June 10, 2026

Cohort 3 | Project CloudIgnite Topics: EC2 Instance Lifecycle & Management, AMI Deprecation, AWS Elastic Beanstalk, EC2 Launch via Console & CLI, VPC/Security Group Troubleshooting, Intro to Elastic Load Balancing & Auto Scaling Duration: ~3 hours

---

Key Takeaways

• EC2 lifecycle states: pending → running → stopping → stopped → terminated; terminated is permanent and unrecoverable
• Billing in stopped state: no compute charge, but EBS storage still billed; also billed during the brief "stopping" transition
• Instance Store vs EBS: Instance Store is ephemeral (data lost on stop/restart); EBS is persistent (preserved across stop/start)
• IP behavior: Public IP changes on every stop/start; Elastic IP is a static, reassignable public IP
• AMI deprecation: custom AMIs deprecated ~2 years after creation; existing instances keep running, but new launches are blocked (critical to refresh AMI in time for ASGs)
• Elastic Beanstalk = PaaS: AWS manages OS, runtime, scaling; you upload code; no additional charge — pay only for underlying EC2/EBS/RDS
• Modifying instance type: must stop the instance first; new type's architecture must be compatible
• Security Group = instance-level stateful firewall (default deny inbound); NACL = subnet-level stateless

---

Table of Contents

1. EC2 Instance Lifecycle & States
2. Billing Implications of Instance States
3. Data Persistence: Instance Store vs EBS
4. Public IP Behavior & Elastic IP
5. Modifying an EC2 Instance
6. AMI Deprecation
7. AWS Elastic Beanstalk
8. Lab: Launching EC2 via Console & Troubleshooting LAMP
9. Launching EC2 via AWS CLI
10. Challenge Lab: New VPC + EC2 + Security Group Troubleshooting
11. Intro: ELB, Auto Scaling, Route 53
12. CLF-C02 Exam Relevance

---

1. EC2 Instance Lifecycle & States

• Pending → instance is launching; takes time before it becomes available.
• Running → instance is active and usable.
• From running, you can: reboot, stop, or terminate.
• Reboot → goes through a temporary "rebooting" state before returning to "running".
• Stop → goes through a temporary "stopping" state before reaching "stopped".
• Terminate → instance enters "terminated" state — this is permanent and unrecoverable.
• From a stopped state, you can either start the instance again or terminate it.

Instance Hibernation

• Hibernation = instance consumes very little power (not fully running), but RAM state is preserved.
• On resume, the instance starts faster and resumes exactly where it left off.
• Not available for all instance types — requires an EBS root volume.

---

2. Billing Implications of Instance States

Key takeaway: Even a stopped instance generates EBS storage cost.

---

3. Data Persistence: Instance Store vs EBS

Termination & EBS

• By default, the root EBS volume is deleted on termination.
• Controlled by the "Delete on Termination" setting:
  • Yes → EBS volume deleted when instance terminates.
  • No → EBS volume is retained after termination.

---

4. Public IP Behavior & Elastic IP

• A normal public IP address changes every time you stop and start an instance.
• If you need a static IP that persists across stop/start and can be reassigned to different instances, use an Elastic IP.

Checkpoint Q&A: An engineer rebooted an instance and it worked fine. After stopping and restarting it the next day, users can't access the app. Answer: The public IP address changed after stop/start — users were likely still using the old IP/DNS.

---

5. Modifying an EC2 Instance

Why design for quick start/stop?

• Supports horizontal scalability (Auto Scaling Groups need to launch/terminate instances quickly).
• Faster OS upgrades, faster repair, cost savings.

Steps to change instance type

1. Stop the instance first (cannot resize while running).
2. Modify via AWS Management Console (Actions → Instance Settings → Change Instance Type), or via AWS CLI.

Conditions to modify instance type

1. Instance must be stopped.
2. New instance type's architecture must be compatible (e.g., both must support 64-bit).
3. (For hibernation) Instance must have an EBS root volume — otherwise RAM state can't be preserved.

OS/Software Updates

• You are responsible for periodically updating OS, security patches, and tools.
• Can use AWS Systems Manager and OpsWorks to manage/automate updates.

---

6. AMI Deprecation

• AMI (Amazon Machine Image) = a template used to quickly launch EC2 instances (includes OS, configuration, etc.).
• AMI sources: provided by AWS, shared by other users, or created by you.
• Custom AMIs are deprecated ~2 years after creation date.
• Effect of deprecation:
  • Existing instances launched from that AMI continue to run fine — no issue.
  • You cannot launch new instances using a deprecated AMI.
  • You must update/refresh your AMI before it deprecates, especially important for Auto Scaling Groups that rely on AMIs.

---

7. AWS Elastic Beanstalk

Conceptual Comparison

What Elastic Beanstalk Does

• You choose the OS/language stack (e.g., Red Hat Linux, Node.js, Java) — AWS installs, patches, and maintains it.
• AWS handles: OS upgrades, security patches, language runtime/interpreter, application server, load balancing, auto scaling, and health monitoring.
• You retain control over key configuration: EC2 instance type, database choice, auto-scaling settings, load balancer options.

Supported Languages/Platforms

Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker (containers).

Benefits

• Increased developer productivity (focus only on code).
• Built-in scalability.
• Reduced management complexity (no manual patching/upgrades).

Cost Model

• No charge for Elastic Beanstalk itself — you only pay for the underlying AWS resources (EC2, EBS, RDS, etc.).

---

8. Lab: Launching EC2 via Console & Troubleshooting LAMP

Scenario: A bakery (Sophia/Frank/Martha's business) previously had a static website (for displaying info only). They now want an online ordering system, which requires a dynamic backend → decided to use a LAMP stack (Linux, Apache, MariaDB, PHP).

Sophia attempted deployment via a user data script but something went wrong — this lab is the troubleshooting exercise.

Steps to Launch EC2 (Console)

1. Launch Instance → name/tag it (e.g., "bastion host").
2. Choose AMI: Amazon Linux.
3. Choose instance type: T3.micro.
4. Key pair: "Proceed without a key pair" (lab purposes only).
5. Network settings:
   • Select the correct VPC (e.g., "Lab VPC", not default).
   • Use public subnet.
   • Enable auto-assign public IP.
   • Create a new security group — keep the SSH (port 22) rule.
6. Storage: Default EBS GP3 volume, 8 GB.
7. Advanced Details: Set the Instance Profile — critical step, easy to skip, hard to fix later if missed.
8. Launch instance → wait for status checks to turn green.

Connecting to the Instance

• Use EC2 Instance Connect (not SSM Session Manager) — this works over SSH (port 22) under the hood.
• Requires port 22 open in the security group's inbound rules.

Troubleshooting Misconfigured Instance

Problem 1: Couldn't connect via Instance Connect.

• Cause: Security group only had port 80 open, no port 22.
• Fix: Add inbound rule for SSH (port 22).

Problem 2: Public DNS didn't load a web page.

• Cause: Web server (Apache) wasn't actually running — user data script hadn't executed.
• Fix:
  1. Rename userdata.txt → install.sh (text files can't be executed directly).
  2. Give execute permission: chmod +x install.sh
  3. Run with elevated privileges: sudo ./install.sh
• Result: Apache installs and dashboard becomes accessible.

Key concept: User data = a bash script that runs on first boot. Must have execute permission and proper file extension/handling to run.

---

9. Launching EC2 via AWS CLI

Workflow

1. Retrieve AMI ID dynamically (newer metadata retrieval requires a token — may need to set values manually if the automated script fails):

   export AZ=us-west-2a
   export region=us-west-2
   

2. Retrieve subnet ID and security group ID — store in environment variables ($SUBNET, $SG, $AMI).

3. Download the user data script — this script downloads a .zip/.gz file and extracts it to /var/www/html to deploy a basic website.

4. Launch the instance:

   aws ec2 run-instances \
     --image-id $AMI \
     --subnet-id $SUBNET \
     --security-group-ids $SG \
     --user-data file://userdata.txt \
     --instance-type t3.micro \
     --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server}]' \
     --query 'Instances[0].InstanceId'
   

   • Running this command multiple times launches multiple separate instances (does not overwrite existing ones).

5. Describe instances:

   aws ec2 describe-instances
   aws ec2 describe-instances --instance-ids <instance-id>
   aws ec2 describe-instances --instance-ids <instance-id> \
     --query 'Reservations[0].Instances[0].PublicDnsName' --output text
   

Practical Takeaways

• CLI launches are faster and repeatable compared to clicking through the console — can be saved as a bash script for future use.
• Use --query with JSONPath-like syntax to extract specific fields from CLI JSON output.
• Watch out for unexpected newlines when copying multi-line commands.

---

10. Challenge Lab: New VPC + EC2 + Security Group Troubleshooting

Task: Use the Management Console to:

1. Create a new VPC (with new subnets).
2. Launch a T3.micro EC2 instance in the new VPC's public subnet with auto-assigned public IP.
3. Use user data to install/start HTTP service (Apache) and set correct permissions on the web root.
4. Use GP2 storage (not GP3, per challenge requirements).
5. Configure security so you can connect via SSH.
6. Create projects.html, move it to /var/www/html/, and verify via browser.

VPC Creation Notes

• Used "VPC and more" option — automatically creates:
  • Internet Gateway
  • Route tables (public/private)
  • Subnets (2 public, 2 private)
• CIDR block: Must be between /16 and /28.
  • A /22 CIDR → ~1,000 available IP addresses (smaller number = larger range).
• NAT Gateway: set to None for this lab (not required).
• S3 Gateway Endpoint: not needed for this lab — used only when you want private connectivity between EC2 and S3 without going over the public internet.

Security Group Setup

• Create a new security group explicitly associated with the new ("Challenge") VPC — NOT the default VPC's security group.
• Add inbound rules:
  • SSH (port 22) — Anywhere (IPv4)
  • HTTP (port 80) — Anywhere (IPv4)
• Outbound rule: Leave as default — Allow all traffic. Do not restrict/remove the default outbound rule.

Common Troubleshooting Issues

---

11. Intro: ELB, Auto Scaling, Route 53

Elastic Load Balancing (ELB)

• Sits between end users and backend servers.
• Distributes incoming traffic across multiple EC2 instances.
• Types to be covered later: Application Load Balancer, Network Load Balancer, etc.

EC2 Auto Scaling Group

• Automatically adds or removes EC2 instances based on demand (traffic spikes/drops).
• Scaling can be triggered by:
  • Traffic/load (e.g., CPU usage, network bandwidth)
  • Time (scheduled scaling — e.g., higher traffic during business hours)
  • Events (e.g., queue depth)
• Benefits: fault tolerance, high availability, better performance, and cost optimization.
• Important distinction: Auto Scaling adds more instances (horizontal scaling) — it does not increase RAM/CPU of an existing instance.

Route 53 (brief mention)

• AWS's DNS service.
• Will cover failover routing — automatically redirects traffic to a secondary/backup server if the primary server fails.

---

12. CLF-C02 Exam Relevance

Practical/Lab content (AWS CLI commands, security group troubleshooting) is less likely to appear directly on CLF-C02 (which is conceptual) but reinforces the underlying concepts that are tested.

---

Notes generated from lecture transcript dated June 10, 2026 (Cohort 3: Project CloudIgnite).