EC2 — Compute Fundamentals

What we're doing: See a user-data script that runs once at first boot, and where it gets its instructions from.

#!/bin/bash
# runs once, as root, on first boot only
yum install -y nginx
systemctl enable --now nginx

1

The shebang tells EC2 how to execute this user-data payload — bash here, but it could equally be cloud-init YAML.

3

This install only happens on first boot — restarting the instance later does not re-run this script.

Why this works: User data is the mechanism that turns a generic AMI into a specifically configured instance at launch time, without needing a custom AMI baked for every possible configuration.

What we're doing: See how the same workload might mix purchasing options rather than using one exclusively.

Baseline (always-on, predictable): Savings Plan-covered instances
Burst capacity (traffic spikes):    On-Demand instances
Batch processing (can be retried):  Spot Instances

1

Steady, predictable load is exactly what a 1- or 3-year commitment is priced to reward.

2

Unpredictable spikes are covered without any commitment, at the cost of the higher per-hour rate.

3

A batch job that can tolerate being interrupted and retried gets the steepest discount available.

Why this works: A single fleet rarely fits one purchasing option cleanly — mixing them so each workload characteristic (steady vs bursty vs interruptible) is matched to the option that rewards it is how the discount is actually captured without giving up flexibility where it is needed.

What we're doing: Compare what actually happens to availability when scaling vertically versus horizontally, given the same load increase.

# Vertical scaling
1x m6g.large → stop → resize to m6g.2xlarge → start
# during the resize, that single instance is fully unavailable

# Horizontal scaling
1x m6g.large → add 3 more m6g.large behind the load balancer
# each addition happens without taking any existing instance offline

2

Vertical scaling of an EC2 instance requires stopping it first — there is a real, if brief, availability gap.

6

New instances join the target group as they become healthy — no existing capacity is ever taken offline to add more.

Why this works: The tradeoff is not just "which scales further" — vertical scaling has an unavoidable availability gap during the resize itself, which horizontal scaling does not need at all.

What we're doing: See the actual tradeoff cluster placement makes explicit: speed against blast radius.

# Cluster placement group
Instances packed close together on the same underlying hardware/network
→ lowest possible inter-instance latency

# But:
A single hardware failure can simultaneously affect many instances
in the same cluster placement group

2

Physical proximity is exactly what buys the latency improvement.

5

That same physical proximity is what makes a hardware failure's blast radius larger than instances spread across distinct hardware.

Why this works: Cluster placement is a deliberate tradeoff, not a strictly-better option — the same physical closeness that minimizes latency is what increases the number of instances a single hardware failure could affect at once.

What we're doing: See why "the instance seems fine in CloudWatch" can still mean it is out of memory.

CPUUtilization: 12%        # looks healthy
NetworkIn/Out: normal       # looks healthy

# but without the CloudWatch agent installed:
mem_used_percent: not reported at all — no data, not "0%"

2

Every default metric can look completely normal even while the instance is struggling.

5

Missing memory data is not the same as healthy memory — it means nothing was ever configured to report it.

Why this works: A gap in CloudWatch's dashboard is easy to misread as "nothing wrong here" instead of "this was never being measured" — an out-of-memory condition can be invisible to CloudWatch entirely without the agent, even while CPU and network both look completely fine.