EC2 basics: instances, AMIs, and instance types

EC2 (Elastic Compute Cloud) rents virtual machines called instances — you choose an operating system image, a hardware profile (CPU/memory/network), a network location, and AWS provisions a running VM within seconds to minutes, billed for however long it runs.

Each of those flags corresponds to one of the core concepts this lesson covers: --image-id (an AMI), --instance-type (a hardware profile), --subnet-id/--security-group-ids (networking, covered in depth in this domain's VPC lesson).

An AMI (Amazon Machine Image) is a template containing an operating system and, optionally, pre-installed software — the actual disk image an instance boots from. Three common sources:

Building a custom AMI from a fully-configured instance is a common pattern for auto-scaling groups (covered in the Cloud Computing domain) — every new instance the scaling group launches boots already-configured, with no first-boot setup delay.

Instance type names encode their hardware profile in a compact format, e.g. t3.micro, m5.large, c6g.xlarge:

The size suffix (.micro, .small, .large, .xlarge, .2xlarge...) scales CPU/memory roughly geometrically within the same family. A common, avoidable mistake: picking an oversized instance "to be safe" without ever checking actual CPU/memory utilization — right-sizing (the same principle covered in the Cloud Computing domain's cost-optimization lesson) applies directly to instance type choice.

The distinction that trips people up: stopping an instance keeps it (and, by default, its attached EBS root volume) around — you stop paying for compute but still pay for the attached storage, and can start it again later with the same disk contents. Terminating an instance destroys it permanently — the instance ID is gone, and unless DeleteOnTermination was explicitly set to false, its root volume is deleted too. "I terminated it instead of stopping it" is a common, sometimes-costly mix-up for anyone new to EC2.

User data is a script (commonly bash, or cloud-init YAML) passed at launch time that runs automatically the first time an instance boots — the standard way to install software, pull application code, or run setup steps without needing to bake every possible variation into a custom AMI:

This combines well with custom AMIs: bake the slow, rarely-changing setup (runtime, dependencies) into the AMI, and use user data for the fast, frequently-changing part (pulling the latest application code, environment-specific configuration).

The Cloud Computing domain's compute-options-overview lesson covers the general VM-vs-container-vs-serverless trade-off; EC2 is AWS's specific VM offering, and it's what container orchestration (ECS/EKS, covered in the Docker & Containers domain) and even some serverless internals ultimately run on top of, one layer down. Understanding EC2 directly — instances, AMIs, instance types, the stop/terminate distinction — makes every one of those higher-level, more-managed services easier to reason about, since they're all, in some form, managing EC2 (or something architecturally similar) on your behalf.