Instance families and how to choose between them, AMIs, security groups as stateful firewalls, spot vs on-demand pricing, and where EC2 fits against ECS and EKS.
Published September 23, 2026
General purpose (m-series): balanced CPU/memory — the default starting point
Compute-optimized (c-series): high CPU relative to memory — CPU-bound workloads
(video transcoding, from Video Streaming Platform)
Memory-optimized (r-series): high memory relative to CPU — large in-memory
caches, in-memory databases
EC2 offers dozens of instance types grouped into families optimized for different resource ratios — the interview/practical-relevant skill isn't memorizing every type, it's mapping a workload's actual resource profile (from Back-of-Envelope Estimation's capacity numbers) to the right family: a CPU-bound batch job wants compute-optimized; a Redis cache holding a large working set wants memory-optimized; most typical web application servers are perfectly served by general-purpose.
An AMI (Amazon Machine Image) is a template containing the OS, any pre-installed software, and configuration — every EC2 instance launches FROM an AMI, conceptually identical to how a Docker container launches from an image (Docker Fundamentals' images-vs-containers distinction applies directly here, one layer up the stack). Custom AMIs (baking your own application and dependencies into the image ahead of time) let new instances boot already-configured and ready, rather than running a slow provisioning script on every launch.
Security group inbound rule: allow TCP 443 from 0.0.0.0/0
— an OUTBOUND response to an ALLOWED inbound connection is automatically permitted back out,
WITHOUT needing a matching outbound rule (this is what "stateful" means)
A security group acts as a virtual firewall attached to an instance, with two properties worth being precise about: it's stateful (a connection allowed in one direction automatically permits the return traffic, unlike a stateless firewall requiring explicit rules for both directions), and it only supports ALLOW rules (there's no explicit "deny" rule type — everything not explicitly allowed is implicitly denied). This contrasts directly with Network ACLs (VPC Basics), which ARE stateless and DO support explicit deny rules — the two mechanisms are complementary, not redundant.
EC2 gives full control over the underlying instance (OS-level access, custom software, precise resource tuning) at the cost of operational burden (patching, scaling, monitoring, all your own responsibility) — a managed service (RDS instead of self-hosted Postgres on EC2, for instance) trades away some of that control for AWS handling the operational burden. The general heuristic: reach for a managed service by default, and justify EC2 specifically when you need control a managed service doesn't offer (a highly customized runtime, software not available as a managed offering, or genuine cost optimization at very large predictable scale).
On-demand: pay full price, guaranteed availability, no interruption risk
Spot: pay UP TO ~70-90% less, but AWS can reclaim the instance with only
a short (typically 2-minute) warning, whenever it needs the capacity back
Spot instances use AWS's spare capacity at a steep discount, in exchange for accepting that the instance can be reclaimed ("interrupted") with minimal notice — appropriate for workloads that are genuinely fault-tolerant and interruptible (batch processing, the transcoding workers from Video Streaming Platform, CI build runners) where losing an individual instance mid-job just means retrying, not a real problem. Using spot instances for anything stateful or latency-critical (a database, a request-serving web server with no redundancy) risks real, unplanned outages — the fault-tolerance requirement isn't optional, it's the entire basis for spot pricing being viable at all.
EC2: raw virtual machines — you manage the OS, scaling, orchestration, everything
ECS: AWS's own container orchestration service — simpler setup than Kubernetes,
tightly integrated with other AWS services, but AWS-proprietary
EKS: managed Kubernetes on AWS — the full Kubernetes API/ecosystem (Core Objects,
Services & Ingress, everything from the Kubernetes Essentials chapter),
portable to any other Kubernetes-compatible cloud, more operational complexity
This is a real, consequential architecture decision, not just a feature comparison: EC2 alone means building your own orchestration (or running Kubernetes manually on top of it); ECS is AWS's simpler, tightly-integrated but proprietary alternative to Kubernetes; EKS gives you genuine Kubernetes (everything covered in the Kubernetes Essentials chapter applies directly) at the cost of more operational surface area than ECS. Teams already committed to Kubernetes (for portability, or because they already run it elsewhere) pick EKS; teams wanting the simplest AWS-native container experience often pick ECS instead.
Q: Can a workload mix spot and on-demand instances? A: Yes, and this is common practice — a baseline of on-demand (or reserved) instances guarantees minimum stable capacity, with spot instances added on top to absorb burst demand cheaply; if spot capacity is reclaimed, the on-demand baseline ensures the service doesn't drop below a functional minimum.
Q: Why would security groups being stateful matter in practice, beyond convenience? A: It significantly simplifies rule management — without statefulness, every allowed inbound connection would also need an explicit matching outbound rule for the response, doubling the rule surface and the chance of a misconfiguration accidentally blocking legitimate return traffic.
Q: Is there a cost reason to prefer EC2 over a managed service beyond raw compute pricing? A: At very large, predictable, steady-state scale, self-managing on EC2 can sometimes undercut a managed service's markup — but this needs to be weighed honestly against the added operational engineering cost (the team's own time spent patching, scaling, and handling failures) which is real, ongoing cost even if it doesn't appear on the AWS bill directly.
Q: How does choosing ECS vs EKS affect a team's ability to move workloads to a different cloud provider later? A: EKS (genuine Kubernetes) is meaningfully more portable — the same Kubernetes manifests largely work against GKE or any other Kubernetes-compatible cluster with minimal changes; ECS's task definitions and service model are AWS-specific, making a later migration to a different cloud a more substantial rewrite, a real, sometimes underweighted factor in the initial choice.