Amazon EC2
Elastic Compute Cloud — virtual servers in the cloud covering instance types, AMIs, placement groups, Nitro, tenancy, and pricing models.
Overview
Amazon Elastic Compute Cloud (EC2) is AWS's core compute service — resizable virtual servers (instances) in the cloud that provide on-demand capacity for virtually any workload.
EC2 underpins the majority of AWS architectures. An instance is a virtual machine running on a physical host in an Availability Zone (AZ). Each instance is launched from an Amazon Machine Image (AMI), attached to a Virtual Private Cloud (VPC) subnet, and assigned an instance type that determines its compute, memory, storage, and networking resources.
Core Concepts
| Concept | Description |
|---|---|
| Instance | A virtual server running on AWS infrastructure; defined by an instance type and launched from an AMI |
| AMI | Amazon Machine Image — a template containing the OS, application server, and applications |
| Instance Type | Determines the hardware profile: vCPUs, memory, storage, and network bandwidth |
| Security Group | Stateful virtual firewall controlling inbound and outbound traffic at the instance level |
| Key Pair | RSA or ED25519 key pair used for SSH (Linux) or RDP password decryption (Windows) |
| Elastic IP | Static public IPv4 address that can be remapped between instances |
| User Data | Bootstrap script (bash/PowerShell) executed on first launch — runs as root/Administrator |
| Instance Metadata | Instance-accessible endpoint (169.254.169.254) exposing identity, network, and IAM role info |
| Nitro System | AWS's custom hypervisor and hardware platform — enables bare metal, enhanced networking, and EBS optimisation |
Instance Families
Instance type naming follows the pattern: <family><generation>.<size> (e.g., m7i.xlarge).
| Family | Category | Optimised For | Example Types |
|---|---|---|---|
| M | General Purpose | Balanced compute, memory, networking | m7i, m7g, m6a |
| C | Compute Optimised | CPU-intensive: batch processing, ML inference, gaming | c7i, c7g, c6a |
| R | Memory Optimised | In-memory databases, real-time analytics | r7i, r7g, r6a |
| X | Memory Optimised | Very large in-memory workloads (SAP HANA, etc.) | x2idn, x2iedn |
| I | Storage Optimised | High sequential I/O, data warehousing, Hadoop | i4i, i3, i3en |
| D | Storage Optimised | Dense HDD storage, distributed file systems | d3, d3en |
| P | Accelerated (GPU) | ML training, HPC, computational fluid dynamics | p5, p4d |
| G | Accelerated (GPU) | Graphics rendering, video encoding, ML inference | g6, g5 |
| Inf | Accelerated (Inferentia) | ML inference at low cost | inf2 |
| T | Burstable | Baseline + burst CPU credits; dev/test, small apps | t3, t3a, t4g |
| Hpc | HPC Optimised | Tightly-coupled HPC, weather modelling | hpc7g, hpc7a |
Suffix modifiers: g = Graviton (ARM), a = AMD, n = enhanced networking, d = local NVMe SSD, e = extra memory or storage.
SAA/SAP Tip: Graviton instances (suffix g) deliver up to 40% better
price-performance than x86 equivalents for most workloads. Prefer them unless
the application requires x86 binaries.
Amazon Machine Images (AMIs)
An AMI packages everything needed to launch an instance: root volume snapshot, launch permissions, and block device mapping.
| AMI Source | Description |
|---|---|
| AWS-provided | Amazon Linux, Ubuntu, Windows Server — maintained by AWS |
| Marketplace | Third-party vendor AMIs (some with license fees baked in) |
| Community | Shared publicly by other AWS users — use with caution |
| Custom | Created from an existing instance or imported from on-premises |
Key behaviours:
- AMIs are region-scoped — copy an AMI to target region before launching there
- AMIs can be shared cross-account or made public
- Golden AMI pattern: pre-bake software + config into an AMI to reduce bootstrap time
Placement Groups
Placement groups control how instances are physically positioned on underlying hardware.
| Strategy | Behaviour | Use Case | Limitation |
|---|---|---|---|
| Cluster | All instances in a single AZ, close together on same rack | Low-latency, high-throughput HPC / tightly coupled | No multi-AZ; higher blast radius |
| Spread | Each instance on distinct hardware (max 7 per AZ per group) | Individual critical instances needing HA | Max 7 instances per AZ |
| Partition | Instances spread across logical partitions on separate racks | Large distributed workloads (HDFS, Cassandra, Kafka) | Max 7 partitions per AZ |
Exam Trap: Spread placement groups support a maximum of 7 running instances per AZ. For large-scale distributed workloads, use Partition placement groups instead.
Tenancy
| Tenancy Model | Description | Cost Impact |
|---|---|---|
| Shared (default) | Instance runs on shared hardware alongside other AWS customers | Lowest |
| Dedicated Instance | Instance runs on hardware dedicated to one AWS account; other instances from the same account may share it | Higher |
| Dedicated Host | An entire physical server allocated to one account — visibility into sockets, cores, and host affinity | Highest |
SAA/SAP Tip: Dedicated Hosts are required for Bring Your Own License (BYOL) models that bind to physical hardware (e.g., Windows Server, SQL Server per-socket licensing). Dedicated Instances do not provide host-level visibility.
Networking
| Feature | Description |
|---|---|
| Elastic Network Interface (ENI) | Virtual network card; an instance can have multiple ENIs in different subnets |
| Enhanced Networking (ENA) | Up to 200 Gbps using SR-IOV; enabled by default on Nitro instances |
| Elastic Fabric Adapter (EFA) | OS-bypass networking for HPC and ML training — lower latency than ENA |
| Elastic IP (EIP) | Static public IPv4; charged when not associated with a running instance |
| Public IP | Auto-assigned from AWS pool; released on stop; cannot be remapped |
Storage Options
| Storage Type | Persistence | Use Case |
|---|---|---|
| EBS volumes | Persist beyond stop | Boot volume, databases, general-purpose block storage |
| Instance Store | Ephemeral (lost on stop/terminate) | Temp data, caches, scratch space, buffers |
| EFS / FSx | Network-attached | Shared file storage across multiple instances |
Exam Trap: Instance store volumes are ephemeral — all data is lost when the instance stops, terminates, or the underlying hardware fails. Never store critical data on instance store alone.
Purchasing Options
| Model | Commitment | Discount vs On-Demand | Best For |
|---|---|---|---|
| On-Demand | None | 0% | Short-term, unpredictable workloads |
| Reserved Instances | 1 or 3 yr | Up to 72% | Steady-state workloads with predictable usage |
| Savings Plans | 1 or 3 yr | Up to 72% | Flexible commitment across instance families |
| Spot Instances | None | Up to 90% | Fault-tolerant, flexible-start workloads |
| Dedicated Hosts | None or 1/3 yr | Varies | BYOL, compliance requiring host-level control |
| Capacity Reservations | None | 0% (On-Demand price) | Guaranteed capacity in a specific AZ |
Spot Instances
Spot Instances use spare EC2 capacity at steep discounts (up to 90% off On-Demand). AWS can reclaim them with a 2-minute warning.
- Spot Fleet — request a mix of instance types and AZs to meet target capacity
- Spot Block (deprecated for new launches) — reserved Spot for 1–6 hours
- Best for: batch jobs, CI/CD builds, data analysis, containerised workloads
SAA/SAP Tip: Combine Spot with On-Demand in an Auto Scaling group using a mixed instances policy to balance cost and availability. Set the On-Demand base to handle minimum steady-state load.
Reserved Instances vs Savings Plans
| Aspect | Reserved Instances (RI) | Compute Savings Plans |
|---|---|---|
| Scope | Specific instance type + region (or AZ) | Any instance type, region, OS, or tenancy |
| Flexibility | Convertible RIs allow family changes | Automatically applies to cheapest usage |
| Payment options | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront |
| Applies to | EC2 only | EC2, Fargate, Lambda |
Instance Lifecycle
pending → running ↔ stopping → stopped → terminated
↘ shutting-down → terminated- Stop: EBS root volume persists; instance store data is lost. No compute charges while stopped (EBS charges continue).
- Hibernate: RAM contents are saved to EBS root volume. On start, RAM is restored — faster than a cold boot. Root volume must be encrypted and large enough.
- Terminate: Instance is deleted. EBS root volume is deleted by default (configurable via
DeleteOnTermination).
SAA/SAP Tip: EC2 Hibernate is useful for long-initialisation applications (large in-memory caches, JVM warm-up). The instance must use an encrypted EBS root volume and belongs to specific instance families with RAM ≤ 150 GB.
Common Use Cases
- Web application hosting — Run HTTP servers (Apache, Nginx, Node.js) behind an Application Load Balancer with Auto Scaling.
- Batch processing — Process large datasets using Spot Instances for cost efficiency with fault-tolerant job queues.
- Development and testing — Spin up and tear down environments on demand; T-family burstable instances keep costs low.
- High-Performance Computing — Cluster placement groups + EFA + P/Hpc instances for tightly-coupled parallel workloads.
- Database hosting — Run self-managed databases (when RDS lacks the required engine) on memory-optimised instances with EBS io2.
- Machine learning training — GPU instances (P5, G6) with large datasets on S3 or FSx for Lustre.
SAA/SAP Exam Tips
SAA/SAP Tip: When a question mentions "per-socket" or "per-core" licensing, the answer is Dedicated Hosts — not Dedicated Instances. Only Dedicated Hosts provide visibility into physical hardware.
Exam Trap: Stopping and starting an EC2 instance may move it to different underlying hardware — the public IP changes (unless using an Elastic IP) and instance store data is lost.
SAA/SAP Tip: For "lowest cost" questions with fault-tolerant workloads, Spot Instances are almost always the answer. For steady-state, choose Reserved Instances or Savings Plans.
Exam Trap: EC2 User Data runs only on the first boot by default. To run scripts on every start, configure cloud-init accordingly or use a systemd service.
Cross-Cloud Equivalents
| Provider | Service / Solution | Notes |
|---|---|---|
| AWS | Amazon EC2 | Baseline |
| Azure | Azure Virtual Machines | Similar instance families; different naming |
| GCP | Google Compute Engine | Predefined + custom machine types |
| On-Premises | VMware vSphere, KVM, Hyper-V | Traditional hypervisor-based virtualisation |
Pricing Model
| Dimension | Unit | Notes |
|---|---|---|
| Compute | Per-second | Minimum 60 seconds; Linux and Windows per-second billing |
| EBS storage | GB-month | Separate from EC2; varies by volume type |
| Data transfer out | GB | First 100 GB/month free; intra-AZ traffic is free for same account |
| Elastic IP | Per-hour idle | Charged when not associated with a running instance |
| AMI storage | GB-month (S3) | EBS snapshots backing the AMI incur standard snapshot costs |
Related Services / See Also
- Amazon EBS — block storage volumes for EC2 instances
- Amazon S3 — object storage for application assets and backups
- AWS Auto Scaling — automatically adjust EC2 fleet capacity
- AWS Lambda — serverless compute (no instance management)
- Elastic Load Balancing — distribute traffic across EC2 instances
AWS Auto Scaling
Automatic capacity management — target tracking, step, scheduled, and predictive scaling policies for EC2, ECS, DynamoDB, and more.
Amazon ECS and EKS
Container orchestration services — ECS with Fargate/EC2 launch types and EKS for managed Kubernetes, covering task definitions, services, and decision criteria.