Compute Services: EC2, AMIs and Auto Scaling

AWS Cloud & DevOps Engineering · Lesson 8 · AWS Cloud Foundations

Lesson Overview

The progress API does not live as a single beloved instance with a memorable name. It lives as a replaceable member of a fleet that must survive an Availability Zone impairment, a bad deploy, and Monday’s traffic without a human resizing a console spinner. When the fleet is a pet, Monday reliability is a person. When the fleet is cattle with a launch template, health checks, and an Auto Scaling group, Monday reliability is a design.

Security Groups, NACLs and VPC Connectivity decided who may talk to these hosts. This lesson decides how the hosts are born, what image they boot, how user data configures them, how Auto Scaling replaces the unhealthy, and how Spot capacity can reduce cost without gambling the board. You will prefer launch templates over snowflake launches, treat AMIs as versioned artifacts, and clean up every lab instance and group before the budget alert has to shout.

TechLearningPro’s teaching shape: a stateless web tier across at least two Availability Zones, configuration that can be rebuilt from the template and AMI, and a clear refusal to store learner progress only on an instance store or an unreplicated EBS volume attached to one pet.

Learning Objectives

By the end of this lesson you will be able to:

1. Choose an EC2 instance family and size for a workload class without treating the name as marketing.
2. Explain instance lifecycle states that matter to operations and Auto Scaling.
3. Build and version an AMI as a promotion artifact, not a one-off snapshot of a broken box.
4. Use user data and, where appropriate, cloud-init patterns for first-boot configuration—without baking secrets into scripts.
5. Create a launch template that captures AMI, instance type, security groups, IAM profile, and user data.
6. Configure an Auto Scaling group across AZs with min, desired, and max capacity that you can defend.
7. Distinguish EC2 status checks, ELB/target health, and Auto Scaling health policies at a foundations level.
8. Use Spot instances with care: interruption behavior, mixed instances, and workloads that may not tolerate revocation.
9. Tag, budget, and destroy lab compute so idle instances do not become the course’s most expensive teaching aid.
10. Decide when EC2 is the right foundations building block versus when later modules’ containers or Lambda fit better.

Prerequisites

• Amazon VPC Architecture and lesson 7 for private subnets and security groups the launch template will reference.
• AWS Identity and Access Management for instance profiles.
• AWS CLI, SDKs and Infrastructure Access for describing instances and images.
• Budget alert in the sandbox account before launching anything larger than a free-tier-eligible or smallest burstable type you are allowed to use.
• Comfort with the idea that storage for state belongs in lesson 9 and databases in lesson 10—not on the instance’s personality.

Detailed Core Concepts

What EC2 is for in this course

Amazon EC2 provides virtual machines in your VPC: CPU, memory, networking, and optional local instance store, with EBS volumes for persistent block disks. You choose an AMI, an instance type, a subnet, security groups, and an optional IAM instance profile. EC2 is the foundations compute primitive. Later modules add containers on ECS/EKS and functions on Lambda. Those still often rest on the same mental model: capacity, health, identity, and network. Learning EC2 well makes those abstractions legible.

EC2 is the wrong default when the workload is a short event-driven function with no need for a long-lived guest OS, or when an existing container platform already standardizes deploy. It is the right default when you need a full OS, custom agents, or a straightforward path to a multi-AZ stateless tier for the progress API while you are still learning AWS.

Instance types without the brochure trance

Instance families group similar CPU, memory, storage, and networking balances. Broad categories you will meet constantly:

• General purpose (for example M-family shapes): balanced web and API tiers like TechLearningPro’s progress API when you have no special CPU or memory skew.
• Compute optimized (C-family): tighter CPU for compute-heavy workers.
• Memory optimized (R-family and relatives): in-memory caches or memory-heavy processes—though managed ElastiCache often beats self-managing Redis on EC2 for the platform’s cache tier.
• Storage optimized: high sequential or random local disk needs; do not confuse local instance store with durable backups.
• Burstable (T-family): good for labs and low-steady workloads with occasional spikes; watch CPU credits when Monday traffic is steady, not bursty.

Generation numbers and suffixes (size, architecture such as Graviton/a variants where offered, network and storage letters) change over time. Read the current instance-type documentation for the Region you use. Do not memorize a price. Pick the smallest type that meets a measured need in labs; resize after metrics exist in production thinking.

Architecture choice (x86 vs Arm/Graviton) is a cost and compatibility decision: confirm your AMI and binaries support the architecture before you chase savings.

Purchasing models at foundations depth

On-Demand pays by the second or hour per current billing rules for running instances—default for unpredictable learning and for capacity you must not lose without warning.

Spot uses spare capacity at a discount with the trade-off that AWS can reclaim the instance with a short interruption notice. Suitable for fault-tolerant workers, CI batch, and ASG mixed strategies where the progress board is not solely on Spot. Unsuitable as the only capacity for a stateful single-node database you have not designed to die.

Reserved Instances and Savings Plans commit spend for lower rates. Foundations need awareness, not a purchase recommendation. Lesson 11 and later FinOps material cover commitment thoughtfully. Do not buy multi-year commitments in a sandbox to “practice.”

AMIs as versioned boot artifacts

An Amazon Machine Image defines the root volume contents and metadata needed to launch an instance: OS, baked packages, and sometimes agents. Public AMIs from Amazon and partners give you a start. A custom AMI captures your golden baseline: SSM Agent, CloudWatch agent, progress API dependencies, hardened settings.

Treat AMI IDs like application versions. progress-api-ami-2026-03-12 that was tested beats “the instance we fixed by hand last night” that nobody can recreate. Pipeline later in the course will build AMIs; here you may create one with a controlled ec2 create-image after baking, or start from a maintained Amazon Linux AMI and configure with user data for the lab.

Copying AMIs across Regions is a deliberate DR or multi-Region action with storage cost. Do not copy “just in case” without a restore story.

User data and first boot

User data is a script or cloud-init configuration supplied at launch. Typical uses: write config files, register with a service discovery mechanism, pull application versions from S3, start systemd services. Problems: secrets in user data appear in console and API describe calls to privileged callers—use IAM roles and a secrets service (later lessons) instead of embedding passwords. Long user data that compiles the world at boot makes Auto Scaling slow and flaky; bake what you can into the AMI and keep user data thin.

User data generally runs on first boot for many Linux AMIs; understand whether your AMI re-runs on every reboot. Design for idempotency if re-run is possible. Do not rely on manually SSHing after launch to finish configuration if Auto Scaling will replace the node.

Launch templates over launch configurations

A launch template versions the launch parameters: AMI, instance type, key pair (if any), security groups, IAM instance profile, user data, EBS mappings, and more. Auto Scaling groups consume a launch template (launch configurations are legacy). Version the template; promote a new AMI by creating a new template version and rolling the group. Pin the ASG to a specific template version in production so an accidental default version change does not roll the fleet.

Launch templates also support multiple instance types and Spot options when you design mixed capacity. Keep the lab simple first: one type, On-Demand, two AZs.

Auto Scaling groups

An Auto Scaling group (ASG) maintains capacity across subnets you list—typically one private subnet per AZ for the progress API. You set minimum, desired, and maximum. Scaling policies later react to CPU, request count, or custom metrics; foundations can use manual desired capacity and a target-tracking policy once CloudWatch metrics exist.

Health checks: EC2 status checks find dead guests and unreachable instances. With a load balancer, you can use ELB/target group health so that failing application health checks cause replacement. Grace periods prevent killing instances still booting. If user data takes four minutes and grace is thirty seconds, you will thrash.

Termination policies and instance refresh support controlled rollouts. At foundations, practice instance refresh or a simple raise-desired-then-lower pattern carefully, and always watch that min capacity across AZs still holds.

Spot with care

Spot in an ASG works best with mixed instances policies: On-Demand base capacity for the board’s floor, Spot for elastic surplus, multiple instance types to improve capacity odds. Handle interruption: drain connections where possible, use interruption notices, keep the app stateless. TechLearningPro should not place the only copy of an in-progress grading worker’s local disk state on Spot without a checkpoint design. Prefer Spot for offline video transcoding style work first; graduate the progress API only with an On-Demand floor.

Cleanup culture

Every launch template version, AMI, snapshot, unused Elastic IP, load balancer, and ASG can cost money or quota. Labs: delete ASG first (which terminates instances), then delete unused templates if appropriate, deregister lab AMIs and delete associated snapshots you created, release EIPs. Confirm with a describe filtered by your Project tag.

Metadata service and IMDSv2

EC2 instances retrieve temporary role credentials and instance metadata from the instance metadata service. Modern practice prefers IMDSv2, which requires session-oriented requests and reduces certain SSRF-style risks where an application vulnerability could coax the guest into reading metadata. Launch templates can require IMDSv2 and set hop limits appropriate to container hosts later in the course. For the progress API on a simple EC2 guest, require IMDSv2 unless a legacy agent blocks you, and track that exception. Do not print role credentials into application logs “for debugging.”

Placement, tenancy, and what you can ignore for now

Default shared tenancy is correct for TechLearningPro’s SaaS tier. Dedicated instances or hosts appear in compliance conversations; they change cost and capacity planning. Placement groups (cluster, spread, partition) optimize HPC-style or correlated-failure designs. Foundations may mention them so interview answers are not blank, then return to multi-AZ ASG as the reliability primitive that matters for the Monday board. Do not create a cluster placement group for a two-node web lab; you will learn little and may hit constraints.

CPU architecture and container previews

If your organization standardizes on Graviton for cost and performance per watt, the AMI and all native dependencies must match. A launch template that points at an x86 AMI with an Arm instance type fails at launch. When Module 2 introduces containers, multi-architecture images become part of the supply chain lesson. Here: pin architecture deliberately in the template; do not leave instance type flexible across architectures without a multi-arch AMI strategy.

Scaling policies that do not lie

Target tracking on average CPU works when CPU correlates with learner traffic. It lies when the process is blocked on the database or on downstream HTTP, leaving CPU idle while latency burns. Request-count or ALB request metrics often track the board better. Step scaling and simple scaling exist; prefer a single clear policy in labs. Cooldowns and stabilization windows prevent flapping. Maximum capacity is a cost circuit breaker—set it. An ASG with max=100 and a wrong metric is how a misconfigured health storm or load test becomes a finance conversation.

Instance refresh and deploy shape

Instance refresh replaces ASG members with a new launch template version using percentages and health checks. It is not a full blue/green story (later deployment lessons are), but it is how foundations practice rolling a new AMI without clicking instance IDs. Configure a minimum healthy percentage that still respects Monday’s floor. Abort on failure. Keep the previous template version for rollback by switching the ASG back and refreshing again. Do not delete the old AMI until rollback is unnecessary and retention policy agrees.

Hibernation, Elastic Inferencing, and specialty features

Specialty EC2 features appear in documentation and exams. Hibernation preserves RAM to EBS for certain instance types; it is rarely the progress API’s friend. GPU and accelerator instances matter for ML workers, not for the board’s HTML. Foundations discipline: ignore specialty until a workload metric demands it. Curiosity launches are how sandbox bills grow.

Networking performance and ENIs

Instance types advertise network bandwidth ceilings. A tiny burstable instance behind a busy ALB can saturate. Multiple ENIs appear in appliance and dual-home designs. For TechLearningPro’s API, one ENI in a private subnet is enough; more interfaces mean more security groups to get wrong. Enhanced networking drivers ship in modern AMIs—prefer current Amazon Linux builds over ancient snapshots.

Architecture and Design Diagrams

Stateless progress API tier:

mermaidCopy
flowchart TB
  LT["Launch template v3\nAMI + SG + IAM + user data"]
  ASG["Auto Scaling group\nmin 2 desired 4 max 8"]
  AZ1["Private subnet AZ-a"]
  AZ2["Private subnet AZ-b"]
  TG["Target group health checks"]
  LT --> ASG
  ASG --> AZ1
  ASG --> AZ2
  AZ1 --> TG
  AZ2 --> TG
  TG -->|"unhealthy → replace"| ASG

Boot and join flow:

textCopy
ASG wants capacity → Launch template → EC2 starts from AMI
  → IAM credentials via instance profile
  → User data configures and starts progress API
  → Registers / passes target health
  → Serves through load balancer (lesson 12)

Spot mixed capacity (conceptual):

mermaidCopy
flowchart LR
  Floor["On-Demand base = Monday floor"]
  Peak["Spot surplus = elastic peak"]
  Floor --> ASG["Same ASG / target group"]
  Peak --> ASG

Technical Explanation

Instance lifecycle that operators actually use

Pending means the guest is starting. Running means billing for the instance is active per pricing rules and you can connect if network and IAM allow. Stopping an EBS-backed instance preserves the volume and stops most instance charges while storage remains. Terminating deletes the instance; root volume deletion depends on the delete-on-termination flag. Auto Scaling terminate events should be expected, not treated as vandalism. If someone “stopped” an instance under an ASG to save money, the ASG may start another. Change desired capacity or suspend processes deliberately; do not fight the controller.

Status checks versus application health

System status checks cover underlying host issues. Instance status checks cover guest reachability such as networking and boot. Both appear in the console and CloudWatch. Passing status checks with a hung JVM still fails learners. Target group health checks (HTTP on /health) catch application failure. ASG health check type ELB (with a load balancer) ties replacement to that application signal. Choose the health path carefully: a check that needs the database will replace every app node during a database blip—sometimes correct, sometimes an amplifier. Prefer a local liveness for replacement and a separate readiness for traffic if your stack supports the distinction; at foundations, document what your single health URL means.

IAM instance profiles

Applications on EC2 should not embed long-lived access keys. Attach an instance profile whose role grants least privilege to S3 prefixes, Parameter Store, or Secrets Manager as later lessons prescribe. The progress API reads course assets from a specific prefix, not *. Rotating credentials becomes AWS’s session credential flow. Security groups still required; IAM does not open ports.

EBS at launch time

Root volumes are usually gp3 or a current general-purpose SSD type in modern accounts—verify current defaults. Size the root for OS and app, not for lifelong video archives. Enable encryption with a key policy your account owns (lesson 11 and KMS later deepen this). Data volumes for databases belong in intentional design with snapshots; lesson 9 covers EBS versus EFS versus S3. For a stateless API, prefer no precious data on the instance.

Warm pools, scheduled actions, and predictive scaling (awareness)

ASG features exist to reduce cold-start pain and to scale before a known Monday peak. Foundations awareness is enough: scheduled actions can raise desired capacity before standup if the traffic pattern is calendar-like. Measure before you automate. Warm pools have cost. Do not enable every feature because the console shows a checkbox.

Capacity and quotas

Accounts have vCPU quotas per instance family and Region. A lab that tries to launch a large fleet fails with capacity or quota errors. Request increases only in accounts where you mean to run production-like load; for learning, keep desired capacity tiny (two instances across two AZs is already a real multi-AZ lesson).

Observability minimum for a foundations ASG

Even before Module 4’s CloudWatch deep dive, enable basic monitoring awareness: ASG activity history, EC2 status checks, and—if you attached an ALB—target healthy host count. Alarm when healthy hosts drop below the Monday floor. Alarm when the ASG cannot launch (activity failures). These two alarms catch more production pain than a vanity CPU dashboard. Delete lab alarms in cleanup if they page a shared alias.

Cost notes without fake prices

On-Demand instance hours dominate small labs. ALB hours can rival a pair of tiny instances. NAT Gateway hours dominate if every private subnet path uses NAT instead of VPC endpoints for AWS APIs. AMIs create EBS snapshots billed as storage. Spot saves money only while capacity exists and interruptions are acceptable. Lesson 11 will systematize tags and budgets; this lesson’s rule is smaller and sharper: destroy the ASG before you walk away, and deregister lab AMIs within the day unless you are promoting one deliberately.

Mapping boot failures to layers

Use the table before rebuilding the AMI from scratch.

Practical Implementation or Design Walkthrough

Problem

Deploy a stateless web tier for a stand-in progress API across two Availability Zones using a launch template and an Auto Scaling group. Prove that terminating one instance does not end the service if desired capacity and health checks are correct. Use a budget alert, small instance types, and full cleanup.

Steps

1. Set or verify a budget alert. Tag with Project=tlp-lesson08.
2. Confirm two private subnets in different AZs and an sg-app from lesson 7 patterns. If you also create a public ALB for testing, use lesson 7’s edge rules and plan to delete the ALB in cleanup (ALB hourly cost adds up).
3. Launch one temporary instance from a current Amazon Linux AMI, install a simple web server that serves /health and /, verify SSM access, create an AMI, terminate the baker instance.
4. Create a launch template pointing at that AMI, instance type (small burstable or small general purpose), sg-app, instance profile for SSM, and user data that ensures the web service is enabled.
5. Create an ASG with min=2, desired=2, max=4, subnets in two AZs, health check grace period long enough for boot, and target group health if an ALB exists—or EC2 health for a minimal lab without ALB.
6. Confirm two running instances in different AZs.
7. Terminate one instance manually; confirm ASG replaces it.
8. Optional: add a simple CPU target-tracking policy; generate load carefully; watch scale-out; scale in; then remove the policy if it will interfere with cleanup timing.
9. Optional advanced: mixed instances with a small Spot percentage—only if you accept interruption and still keep On-Demand floor at 2.
10. Cleanup: delete ASG, delete ALB/target groups if any, deregister AMI, delete snapshots, delete launch template if unused, release EIPs, confirm zero running instances with your tag.

Illustrative user data shape (adapt; do not embed secrets):

bashCopy
#!/bin/bash
set -euo pipefail
# Lab only: ensure a simple health endpoint exists after bake or here
systemctl enable --now httpd || systemctl enable --now nginx || true

Prefer baking the package into the AMI so Auto Scaling is not a package mirror dependency.

Failure paths to test

• Shorten health check grace until the ASG thrash-replaces; then restore a sane grace—learn the symptom.
• Remove IAM profile and confirm SSM breaks while the guest may still be “running.”
• Wrong security group: instances run but never become healthy behind the load balancer.

Enterprise Real-World Scenarios

TechLearningPro: the Monday pet

A single progress-api-prod instance named after an engineer handled traffic for months. During a host check failure at 05:40, nobody could launch a replacement because user data was empty and the AMI was a two-year-old public image without the app. The board missed standup. Repair: bake AMI, launch template, ASG min 2 across AZs, health checks on /health, runbook that forbids naming pets in production accounts.

Spot-only CI that stole the API capacity mindset

A team celebrated Spot savings on the API ASG with zero On-Demand floor. A capacity drought interrupted enough instances that target health collapsed. Fix: On-Demand base equal to the reliability floor; Spot only above it; multiple instance types in the mixed policy.

AMI sprawl

Every engineer created AMIs from hand-tuned instances. Nobody knew which AMI was certified. A “latest” pointer moved underneath a production ASG. Fix: AMI pipeline with immutable IDs pinned in the launch template version; “latest” allowed only in non-prod; deregister policy for AMIs older than retention with snapshot cleanup.

Healthcare and regulated builds

A healthcare customer integrating TechLearningPro content requires hardened AMIs with CIS-style baselines, encrypted volumes, and banned SSH passwords. Their progress-facing API still uses an ASG, but AMI promotion requires a security scan gate. The foundations lesson does not invent scanner product names; it requires that the AMI ID in production be the ID that passed the gate, not an engineer’s laptop export. Exceptions are time-boxed and tagged.

Ecommerce flash scale

Retail flash sales teach max capacity and warm-up. If checkout APIs scale from 2 to 40 instances, user data that hits a public package mirror will throttle itself. Bake packages; pre-stage artifacts in S3 with instance profile read; consider scheduled capacity before the event. Spot may absorb burst if checkout floor stays On-Demand. The Monday board for TechLearningPro is milder but the same math applies before a course launch email to fifty thousand learners.

Best Practices

• Prefer ASG + launch template over manually curated instance lists.
• Pin template versions in production; promote deliberately.
• Bake agents and dependencies into AMIs; keep user data thin and secret-free.
• Run at least two AZs for anything that claims Monday reliability.
• Set min capacity to the floor you are willing to pay for and defend.
• Align health check grace with real boot time.
• Use instance profiles; never bake long-lived keys into AMIs.
• Encrypt EBS volumes; size roots modestly.
• Tag Project, Owner, Environment on instances, volumes, and ASGs.
• Treat Spot as interruptible surplus, not the floor for interactive learner traffic.
• Test replacement by terminating an instance on purpose in staging.
• Budget alert before labs; cleanup AMIs and snapshots, not only instances.
• Document what /health means so ASG replacement does not amplify dependency outages blindly.
• Prefer current generation instance types in the Region; verify architecture compatibility.
• Suspend ASG processes only with an owner and an expiry when diagnosing.

Common Mistakes and Anti-Patterns

One instance in one AZ called production. No replacement story. Use an ASG across AZs.

Secrets in user data. Visible to privileged describe calls. Use roles and a secrets store.

Health grace too short. Constant terminate/launch loops and flapping.

Fighting the ASG by stopping instances to save money. The group launches replacements. Change capacity or schedules.

Spot-only for stateful or latency-critical learner paths. Interruptions become outages.

Untagged lab fleets. Orphan cost. Tag and destroy.

Hand-built production hosts never captured as AMIs. Recovery time becomes archaeology.

Launch configuration nostalgia. Use launch templates.

Oversized instances “for headroom” without metrics. Cost without evidence. Start small; scale on signal.

Deleting instances but keeping lab AMIs and snapshots forever. Storage remains.

Public SSH key on every template with world-open SG. Revisit lesson 7; use SSM.

Troubleshooting and Design Review

ASG stays below desired. Check quotas, subnet IP space, launch errors in the activity history, AMI permissions, and Spot capacity if used.

Instances run but unhealthy. Security groups, health URL, grace period, app bind address (localhost vs 0.0.0.0).

Scale-out does not happen. Policy metrics, cooldown, max already reached, or wrong ASG.

User data failed silently. Console system log / serial output, SSM, cloud-init logs; fix the AMI.

High cost after lab. Forgotten ASG, ALB, NAT, or many snapshots from AMI creates.

Design review:

• Is the progress tier replaceable from a pinned launch template version?
• What is min capacity and why?
• What does health check prove?
• What is the Spot floor policy?
• Are IAM privileges least privilege?
• Cleanup evidence for labs?

Interview Questions and Answers

Q1. Why launch templates instead of manual launches?

They version the AMI, network, identity, and boot configuration so Auto Scaling and humans launch the same artifact. Snowflake launches do not.

Q2. What is the difference between desired and minimum capacity?

Desired is the target the ASG tries to hold now. Minimum is the floor it will not go below under scale-in. Max caps scale-out cost and risk.

Q3. How do EC2 status checks differ from load balancer health checks?

Status checks reflect AWS reachability and host/guest health signals. Load balancer/target checks reflect your application protocol and path. Both matter; they are not the same.

Q4. When is Spot inappropriate?

When interruption violates the reliability story and you have no On-Demand floor or checkpoint design—for example, a single-node stateful store or the only capacity serving interactive Monday traffic.

Q5. What belongs in an AMI versus user data?

AMI: OS, agents, packages, hardened baselines. User data: environment-specific wiring, thin bootstrap. Secrets in neither—use IAM and secrets services.

Q6. How does an instance profile improve security?

Temporary credentials replace long-lived keys on disk; policies scope actions; rotation is handled by the credential service flow.

Q7. What happens if you terminate an instance in a healthy ASG?

The ASG launches a replacement to restore desired capacity, subject to launch template success and capacity availability.

Q8. Why multi-AZ subnets on the ASG?

To survive an AZ impairment without waiting for regional miracles. Min capacity should still make sense if one AZ is unhealthy.

Q9. How do you roll a new AMI safely at foundations level?

New launch template version with the new AMI ID; instance refresh or gradual replace in non-prod first; pin versions; watch health; retain rollback template version.

Q10. What do you clean up after an EC2 lab besides instances?

ASGs, load balancers, target groups, AMIs, snapshots, volumes, Elastic IPs, unused templates if required by policy, and endpoint/NAT resources you added only for the lab.

Q11. Burstable instances surprised a team at 09:00—what happened?

Steady CPU exhausted credits; performance throttled. Either stay within baseline, use unlimited carefully with cost awareness, or choose a non-burstable family for steady Monday load.

Q12. How do containers change this lesson later?

ECS/EKS still need capacity, health, IAM, and networking. The guest becomes a node or becomes Fargate. The ASG mental model transfers; the unit of deploy becomes the task or pod.

Q13. What is IMDSv2 and why require it?

It is the session-oriented instance metadata access method that mitigates simple request-forgery style theft of role credentials from the metadata service. Launch templates can require it. Prefer it for new progress API hosts.

Q14. Why can CPU-based scaling miss a latency incident?

Because the app may be waiting on I/O or downstream calls with low CPU. Latency and request queue metrics can tell the truth when CPU looks fine.

Q15. How do you keep a rollback AMI available?

Retain the previous launch template version and AMI ID until the new version survives a traffic window; only then apply retention policies that deregister older images and delete snapshots.

Q16. What is the relationship between delete-on-termination and data loss?

If root or data volumes delete on terminate, ASG replacement wipes them. Stateless tiers want that. Stateful data must live on volumes and services designed for it, with snapshots and multi-AZ database patterns from later lessons.

Hands-On Exercises

Exercise: Launch template + ASG across AZs

Problem statement. In a sandbox, create an AMI-backed launch template and an ASG spanning two AZs with min=2. Prove replacement after terminate. Budget first; cleanup including AMI/snapshots.

Tasks.

1. Bake or select AMI; record ID.
2. Create launch template with SG + instance profile + thin user data.
3. Create ASG across two private subnets.
4. Terminate one instance; show replacement.
5. Write a short note on Spot: would you use it here? Why or why not?
6. Destroy all billable resources; evidence tagged resources are gone.

Evaluation rubric.

Challenge

Add an instance refresh to a new AMI version with a small surge, document rollback to the previous template version, and state how you would keep On-Demand floor under a mixed Spot policy without inventing fake prices.

Challenge ADR shape

Decision: Progress API runs in an ASG with launch template pinning, min capacity 2 across two AZs, On-Demand floor equal to min, optional Spot only above floor, IMDSv2 required, AMI baked weekly with thin user data, /health local liveness for ASG replacement.

Consequences: Higher baseline cost than one pet instance; faster recovery; need AMI pipeline ownership; Spot savings capped by floor.

Capacity planning for TechLearningPro without vanity sizes

Measure requests per second on a typical Monday morning for the progress API, measure CPU and latency at that load on a chosen instance type, then set desired capacity so that losing one AZ still keeps latency inside the reliability budget. That arithmetic beats “start with four larges.” If you cannot measure yet, start with min=2 small instances across AZs, add request-based tracking once the load balancer exists in lesson 12, and refuse to raise max until an alarm and an owner exist. Capacity without an owner becomes permanent spend.

User data idempotency

A script that installs packages with noninteractive flags and writes config files atomically may be safe across reboots. A script that appends duplicate lines each boot, or that fails when a package already exists, will eventually poison Auto Scaling. Design bootstrap as if it will run more than once, or bake packages into the AMI so boot never races a public mirror on Monday.

Lab evidence checklist

Record launch template version, AMI ID, ASG name, subnet IDs, health check type and grace period, instance types, Spot percentage if any, budget alert ID, and cleanup timestamps. This checklist is the deliverable quality bar for enterprise homework and for your future self during an incident.

Why terminate-on-purpose is a test, not vandalism

In staging, terminating one ASG instance proves replacement. In production, do the same during a planned game day with a clear abort. Teams that never rehearse replacement discover at 05:40 that the AMI cannot launch because a subscription AMI permission expired or a security group ID in the template was deleted. Rehearsal is reliability work.

Connecting lesson 7 to lesson 8

The launch template must reference the correct sg-app. The ASG subnets must be the private app subnets whose NACLs and routes you already trust. Session Manager must work on instances the ASG creates, which means the instance profile and any VPC endpoints are part of the template story, not an afterthought on one pet. If SSM works only on the baker instance you used to create the AMI, the fleet is not operable.

Detailed walkthrough narrative: from zero to two healthy hosts

Imagine a sandbox Region with a VPC already carved into public and private subnets. You open Budgets and confirm an alert exists for forecasted or actual spend above a threshold you chose with your account owner. You tag every resource with Project=tlp-lesson08. You pick a current Amazon Linux AMI that includes SSM Agent. You launch a baker instance in a private subnet with an instance profile that allows SSM. Through Session Manager you install a web server, place a /health response that returns 200, and reboot once to confirm the service returns. You create an image, wait until it is available, and terminate the baker so it stops billing.

You create launch template version 1 with that AMI ID, a small instance type, sg-app, the instance profile, IMDSv2 required, encrypted root volume sized modestly, and user data that only enables and starts the web service if the AMI somehow left it disabled. You create a target group with an HTTP health check on /health if you are including an ALB for the exercise; otherwise you rely on EC2 health for the minimal path. You create the ASG with two private subnets in different AZs, min 2, desired 2, max 4, and a grace period you measured from the baker boot chronometer plus margin.

Two instances appear. You confirm different Availability Zone fields. You Session Manager into one, curl localhost health, and from a controlled path confirm the ALB URL if present. You terminate one instance in the console. The ASG activity history shows a launch. Within minutes desired returns to two. You capture screenshots for the deliverable. Then you delete the ASG, wait for instances to terminate, delete the load balancer pieces, deregister the AMI, delete the snapshot, and verify describe-instances with your tag returns empty. That full loop is the lesson. Stopping after “it worked” leaves the bill running.

Mixed instances policy in plain language

A mixed instances policy tells the ASG that several instance types are acceptable and that some percentage of capacity should be On-Demand while the rest may be Spot. The On-Demand base capacity protects Monday. Spot types should be nearby sizes so the app still fits. Diversify across families enough to improve the chance Spot capacity exists, without mixing architectures unless the AMI supports both. When Spot is interrupted, the group launches replacements according to the policy. If the Spot pool is dry, On-Demand can backfill depending on configuration—read the current Auto Scaling mixed policy documentation before you rely on a behavior in production. Foundations labs may skip mixed policy entirely and still pass if they explain why the board’s floor is On-Demand.

AMI hygiene and public marketplace caution

Community AMIs and marketplace images can accelerate demos and can also introduce unknown agents and billing entitlements. Prefer AWS-published Amazon Linux or your organization’s golden pipeline for TechLearningPro. If a marketplace AMI is required for a vendor agent, document the subscription, the cancel path, and the owner. Never bake API keys into an AMI. Scan for leftover authorized_keys from baker experiments before sharing an AMI across accounts.

Enterprise scenario: the silent max=2

TechLearningPro marketing emails a new course to a large list. Traffic triples. The ASG max was left at 2 from the first lab-like production bootstrap. Latency climbs; the board still “works” for some learners and times out for others. CPU alarms fire but scale-out cannot exceed max. The incident commander raises max under change control and adds a ticket to tie max to a documented load test. The lesson: max is not a decorative field. It is the cost and reliability ceiling. Set it with intent, monitor throttled scale-out, and revisit before big launches.

Security review notes for compute

Ask whether the AMI is private, whether the launch template requires IMDSv2, whether the instance profile is least privilege, whether security groups allow only the edge tier, whether SSH is unnecessary, whether user data contains secrets, and whether termination protection on pets is hiding the absence of an ASG. Compute security is the intersection of image integrity, identity, and network—not a single checkbox.

What “stateless” means for the progress API host

Stateless means a replaced instance does not lose durable learner progress because that progress never lived only on its disk. Session tokens may live in cookies or a shared store; course progress lives in the database lesson next; uploaded assets live in S3. The instance may have local caches that vanish on terminate. Design caches as accelerators, not sources of truth. If your deploy writes unique state to /var/lib/progress on the instance, you do not yet have an ASG-ready API. Move the state before you scale the fleet, or Monday’s replacement will look like data loss.

Next-module teaser inside foundations

Load balancers, containers, and CI-built AMIs will refine this lesson. You already have the spine: template, image, group, health, cleanup. Everything later assumes you will not fall back to a named pet without an incident ticket explaining why.

Operator runbook snippet

When healthy host count is below floor: check ASG activity for LaunchFailed, verify AMI and subnet IP availability, verify Spot interruptions if mixed, verify dependency health if health checks are deep, and avoid opening SSH to the world as a “fix.” When bootstrapping a new environment: budget, tags, template, ASG, prove terminate-replace, then only wire DNS. When decommissioning a lab: delete ASG first, then load balancers, then AMI and snapshots, then leftover volumes and EIPs. Sign the cleanup checklist.

Lesson Summary

Replaceable compute is a habit you rehearse in staging before Monday needs it in production traffic. Keep the rehearsal checklist next to the launch template version you trust. EC2 gives TechLearningPro replaceable compute; AMIs and launch templates make replacement real; Auto Scaling keeps capacity and health across AZs; Spot is a discount with interruption, not a personality test for the Monday board. Stateless progress APIs belong in ASGs; precious state belongs in storage and database lessons that follow. Labs that leave instances, AMIs, and balancers running fail the operational half of the course.

Storage Services: S3, EBS and EFS decides where durable bytes live when the instance is gone. Elastic Load Balancing and Route 53 will put a proper edge in front of the ASG you just designed.

Further Reading

• Amazon EC2 instance types
• Amazon Machine Images
• Launch templates
• Amazon EC2 Auto Scaling
• Spot Instances
• Instance metadata and IAM roles
• User data and cloud-init