beginnerintermediateadvanced

AWS · EC2 Compute Fundamentals

EC2 — Compute Fundamentals

From an AMI and instance type at launch to knowing what CloudWatch actually sees once it is running

AMI + instance type + user datauser data runs once, at first boot only
Match the purchasing option to the shapesteady → commit, bursty → On-Demand, interruptible → Spot
Vertical has a ceilinghorizontal needs statelessness but scales further
Memory/disk need the CloudWatch agentmissing data is not the same as healthy

1.EC2 vocabulary: instances, AMIs, and instance types

An instance is a running virtual server, launched from an AMI (a template of a disk image) at a chosen instance type (a fixed bundle of CPU/memory/network). User data runs once at first boot; the instance metadata service answers questions the instance asks about itself.

Key features

AMI: a template containing the OS, and optionally pre-installed software
Instance type (e.g. m6g.large): a fixed bundle of vCPU, memory, and network performance
User data: a script that runs once, at first boot, unless explicitly re-triggered
Instance metadata (IMDS, 169.254.169.254): lets the instance query its own instance ID, role credentials, and more
Lifecycle states: pending → running → stopping/stopped → (terminated), each with distinct implications

Instance lifecycle states and what changes in each

Instance lifecycle states and what changes in each
State	What still exists	Billed?
pending	Instance being launched	Not yet
running	Fully active	Yes
stopping / stopped	EBS root volume persists; instance store does not	No compute charge, EBS still billed
terminated	Instance and (by default) its root EBS volume are gone	No

The three pieces that define an instance

AMI

the template — OS + software

Instance type

fixed vCPU/memory/network bundle

User data

runs once, at first boot only

Command

bash

aws ec2 run-instances --image-id ami-0abc123 --instance-type m6g.large \
  --user-data file://init.sh --security-group-ids sg-0def456

An AMI is the template, an instance type is the fixed CPU/memory/network bundle, user data runs once at first boot only — and it stays retrievable for the instance's whole life, so it is not a safe place for secrets.

2.EC2 purchasing options and their tradeoffs

On-Demand costs the most per hour but requires no commitment. Savings Plans and Reserved Instances trade a 1- or 3-year commitment for a lower rate. Spot Instances are unused capacity at a steep discount, but AWS can reclaim them with short notice.

Key features

On-Demand: pay by the second, no commitment, highest per-hour rate
Savings Plans: commit to a $/hour spend for 1 or 3 years, flexible across instance families
Reserved Instances: commit to a specific instance configuration for 1 or 3 years
Spot Instances: unused capacity at a discount, can be reclaimed by AWS with short notice
Dedicated Hosts/Instances: single-tenant hardware, often for licensing compliance

Purchasing options and what each trades for a lower rate

Purchasing options and what each trades for a lower rate
Option	Commitment	Best for
On-Demand	None	Unpredictable or short-lived workloads
Savings Plans	1 or 3 years, $/hour	Steady baseline usage, flexible instance family
Reserved Instances	1 or 3 years, specific config	Steady usage with a known, fixed configuration
Spot Instances	None, but interruptible	Fault-tolerant, flexible-timing workloads

What each option trades for a lower rate

tolerates interruptionmust never be interrupted

no commitmentmulti-year commitment

On-Demand: highest rate, zero commitment
Reserved Instances: fixed config, 1-3yr
Savings Plans: flexible family, 1-3yr
Spot Instances: steepest discount, reclaimable

Command

text

Predictable, steady load     → Savings Plan / Reserved Instance
Unpredictable / short-lived  → On-Demand
Flexible timing, fault-tolerant → Spot

Match the option to the workload's shape: steady and predictable earns a Savings Plan or Reserved Instance discount, unpredictable stays On-Demand, and only genuinely interruptible workloads belong on Spot.

3.Vertical vs horizontal scaling

Vertical scaling means making one instance bigger (more vCPU/memory) — simple, but capped by the largest instance type and requires a stop/start. Horizontal scaling means adding more instances — takes more design (statelessness, load balancing) but scales further and survives one instance failing.

Key features

Vertical: change instance type to a larger size — requires a stop/start, has a ceiling
Horizontal: add more instances of the same (or similar) size — needs load balancing and statelessness
Vertical scaling has a single point of failure — one bigger instance is still one instance
Horizontal scaling composes naturally with Auto Scaling and load balancers
A stateful application resists horizontal scaling until its state is externalized

Command

text

Vertical:   m6g.large → m6g.2xlarge      (bigger, same instance, ceiling exists)
Horizontal: 1x m6g.large → 4x m6g.large  (more instances, load-balanced)

Vertical scaling is simpler but has a ceiling and a resize-time availability gap; horizontal scaling needs statelessness and a load balancer but scales further and survives single-instance failure.

4.Placement groups and tenancy

A placement group controls how EC2 physically places your instances relative to each other — clustered for low latency, spread for maximum fault isolation, or partitioned for large distributed systems. Tenancy controls whether your instance shares physical hardware with other AWS customers at all.

Key features

Cluster placement: packs instances close together for the lowest network latency
Spread placement: each instance on distinct hardware, max 7 per AZ, for maximum fault isolation
Partition placement: groups of instances on distinct partitions, for large distributed systems (Hadoop, Cassandra)
Default tenancy: shared hardware, standard pricing
Dedicated tenancy/hosts: single-tenant hardware, often for compliance or license requirements

Placement group strategies

Placement group strategies
Strategy	Optimizes for	Constraint
Cluster	Lowest network latency, highest throughput	Single AZ; a hardware failure can affect many at once
Spread	Maximum fault isolation	Max 7 running instances per AZ per group
Partition	Large-scale distributed systems needing rack-level isolation	Partitions map to distinct racks, tracked by the app

Command

text

Need lowest latency between instances → cluster
Need max fault isolation, few instances → spread
Large distributed system, rack-aware     → partition

Cluster placement trades fault isolation for the lowest latency; spread placement trades some latency for maximum fault isolation — choose based on whether the workload is latency-sensitive or fault-sensitive.

5.Diagnosing instance resource problems

CloudWatch's default EC2 metrics cover CPU, network, and disk I/O — but not memory or disk space, which require the CloudWatch agent installed on the instance. Diagnosing "the instance is slow" starts with knowing which of these five resources CloudWatch already sees, and which it does not.

Key features

Default CloudWatch metrics: CPUUtilization, NetworkIn/Out, disk I/O — no agent needed
Memory and disk space usage: require the CloudWatch agent installed and configured
StatusCheckFailed distinguishes a system-level problem from an instance-level one
EC2 Serial Console gives direct access when SSH itself is unreachable
A process-level problem (a specific process pegging CPU) needs tools run on the instance itself, not CloudWatch alone

What is visible by default vs what needs the CloudWatch agent

What is visible by default vs what needs the CloudWatch agent
Resource	Visible by default?
CPU utilization	Yes — CPUUtilization metric
Network in/out	Yes — NetworkIn / NetworkOut
Disk I/O	Yes — read/write ops and bytes
Memory usage	No — requires the CloudWatch agent
Disk space usage	No — requires the CloudWatch agent

What CloudWatch already sees, before reaching for the agent

CPUUtilization

visible by default, no agent needed

NetworkIn / NetworkOut

visible by default, no agent needed

Disk I/O

visible by default, no agent needed

mem_used_percent / disk_used_percent

no data at all without the CloudWatch agent installed

Command

text

StatusCheckFailed_System → AWS infrastructure issue, often self-resolves or needs a stop/start
StatusCheckFailed_Instance → OS-level issue, often needs investigation on the instance

CloudWatch's default metrics cover CPU, network, and disk I/O — memory and disk space need the CloudWatch agent explicitly installed, and a metric with no data is not the same as a healthy metric.

Spotted a mistake on this page? Tell us.

Read Sheet