AWS EC2 — Interview & Certification Prep

Amazon Elastic Compute Cloud

Resizable virtual machines (instances) with a wide choice of families, sizes and purchasing options.

When to use it: When you need full control of the OS/runtime, long-running servers, or workloads not suited to serverless/containers.

Practice EC2 in the interactive course →

What you’ll learn about EC2

8 lessons, from fundamentals to advanced architecture. Each explains the idea, then lists the points worth remembering:

Beginner

Instances, AMIs and instance families

An EC2 instance is a virtual server launched from an AMI (a machine image with the OS and pre-baked software). Instance families are optimized for different workloads — general purpose, compute-optimized, memory-optimized, storage-optimized, accelerated. You pick a family and size for the workload, attach EBS storage, place it in a subnet, and control access with security groups and an IAM role. An AMI is Region-scoped; to launch in another Region you copy the AMI there first.

  • Instances launch from AMIs into a subnet
  • Families target compute/memory/storage/accelerated workloads
  • Attach EBS + a security group + an IAM role; AMIs are Region-scoped

Exam tip: Instance store is ephemeral (lost on stop/terminate); EBS persists independently. An AMI is Region-scoped — copy it to launch elsewhere.

Source: AWS docs — EC2 User Guide

Intermediate

EBS vs instance store

EBS (Elastic Block Store) is network-attached block storage that persists independently of the instance — you can stop the instance, detach the volume, snapshot it to S3, and reattach it. Instance store is physically-attached local disk: very fast, but EPHEMERAL — its data is lost when the instance stops or terminates. Use EBS for anything that must survive (boot volumes, databases); use instance store only for scratch/cache data you can rebuild.

  • EBS = network block storage, persistent, snapshot to S3, detach/reattach
  • Instance store = fast local disk, EPHEMERAL (lost on stop/terminate)
  • EBS for durable data; instance store for scratch/cache

Exam tip: EBS persists and snapshots to S3; instance store is ephemeral. Stopping an instance keeps EBS data but loses instance-store data.

Source: AWS docs — EC2 User Guide

Security groups, key pairs, IAM role, user data & metadata

An instance is secured by a security group (its stateful firewall), an optional key pair for SSH/RDP access, and an IAM role (via the instance profile) for calling AWS APIs without stored keys. User data is a script run at first boot to configure the instance. The instance metadata service (IMDS) exposes instance details and the role's temporary credentials to code on the instance — use IMDSv2 (session-oriented) to reduce SSRF risk, and never bake long-lived keys into the AMI or user data.

  • Security group = firewall; key pair = SSH/RDP; IAM role = API access without keys
  • User data configures the instance at first boot
  • Metadata (IMDS) serves the role's temporary credentials; prefer IMDSv2

Exam tip: Code on an instance reads temporary role credentials from the metadata service — no keys needed. Use IMDSv2.

Source: AWS docs — EC2 User Guide

Purchasing options & cost

EC2 pricing models trade commitment for savings: On-Demand for flexibility, Reserved Instances / Savings Plans for steady workloads committed over 1–3 years, and Spot for fault-tolerant, interruptible workloads at large discounts. Right-sizing and Auto Scaling further cut cost by matching capacity to demand. Choosing the model to fit the workload's predictability is a classic cost-optimization decision.

  • On-Demand (flexible), Reserved/Savings Plans (committed), Spot (interruptible)
  • Match the model to workload predictability
  • Right-size + Auto Scale to avoid paying for idle capacity

Exam tip: Steady & predictable → Reserved/Savings Plans; spiky/flexible → On-Demand; fault-tolerant & interruptible → Spot.

Source: AWS docs — EC2 User Guide

Auto Scaling, load balancing & health checks

An Auto Scaling group (ASG) launches and terminates instances across multiple AZs to match demand, using a launch template. It registers instances with a load balancer's target group; the ELB health check removes unhealthy targets and the ASG replaces failed instances (self-healing). Scaling policies react to metrics — target tracking (keep CPU ~50%), step scaling, or scheduled scaling for known peaks. Together, ELB + ASG give elasticity AND availability with little operational effort.

  • ASG spans AZs, launches from a template, self-heals failed instances
  • ELB health checks route only to healthy targets; ASG replaces failures
  • Scaling policies: target tracking, step, scheduled

Exam tip: Auto Scaling provides both elasticity AND self-healing (replacing unhealthy instances); an ELB alone does neither.

Source: AWS docs — EC2 Auto Scaling

Comparison: EBS vs instance store, Spot vs On-Demand, vertical vs horizontal

EBS vs instance store: EBS persists and snapshots to S3; instance store is fast but ephemeral. Spot vs On-Demand: Spot is far cheaper but interruptible (fault-tolerant work only); On-Demand is reliable at full price. Vertical vs horizontal scaling: vertical means a bigger instance (simple, but a ceiling and a single point of failure); horizontal means more instances across AZs (scales further, survives failures, needs stateless design). The exam favors persistent storage, interruption-aware Spot use, and horizontal scaling.

  • EBS persistent vs instance store ephemeral
  • Spot cheap/interruptible vs On-Demand reliable/full-price
  • Vertical (bigger, capped, SPOF) vs horizontal (more, elastic, resilient)

Source: AWS docs — EC2 User Guide

Advanced

Spot Instances & interruption handling

Spot Instances use spare EC2 capacity at a steep discount, but AWS can reclaim them with a short interruption notice when it needs the capacity back. They suit stateless, fault-tolerant, checkpointable work: batch processing, CI, big-data, containerized workers, and flexible parts of an Auto Scaling group (mixed with On-Demand). Design for interruption — drain work, checkpoint progress, and spread across instance types/AZs so a single capacity change doesn't stop everything.

  • Deep discount for spare capacity, reclaimable with a short notice
  • Good for stateless, fault-tolerant, checkpointable work
  • Diversify instance types/AZs; mix Spot + On-Demand in one ASG

Exam tip: Spot = interruptible. If the workload cannot tolerate a sudden stop, it is not a Spot candidate.

Source: AWS docs — EC2 User Guide

Stateless design & horizontal scaling

To scale horizontally behind a load balancer, instances should be stateless — no session or user data stored on a specific instance, so any instance can serve any request and instances can be added or replaced freely. Externalize state: sessions to a shared store (ElastiCache/DynamoDB), files to S3/EFS, data to a database. Vertical scaling (a bigger instance) has a ceiling and a single point of failure; horizontal scaling (more instances across AZs) scales further and survives instance/AZ loss.

  • Stateless instances let any node serve any request and be replaced freely
  • Externalize state: sessions → ElastiCache/DynamoDB, files → S3/EFS
  • Horizontal (more instances) scales further and is more available than vertical (bigger instance)

Exam tip: Sticky sessions are a workaround; the durable answer is to externalize session state so instances stay stateless.

Source: AWS docs — EC2 User Guide

Common AWS EC2 interview questions

  1. An application on EC2 needs to read from an S3 bucket. How do you grant access securely, and how does AWS decide whether the request is allowed?

    A strong answer covers:

    • Use an IAM role via the instance profile (no stored keys)
    • Least privilege (only the needed action/resource)
    • Evaluation: explicit Deny beats Allow, default Deny

  2. Design a resilient web tier for spiky traffic that must survive an Availability Zone failure with minimal operational overhead.

    A strong answer covers:

    • Load balancer across multiple AZs
    • Auto Scaling for elasticity + self-healing
    • Stateless instances (externalize session)

  3. A workload runs a steady 24/7 fleet plus nightly fault-tolerant batch jobs, and stores rarely-read compliance data for years. How do you optimize cost across compute and storage?

    A strong answer covers:

    • Reserved/Savings Plans for the steady fleet
    • Spot for fault-tolerant batch
    • S3 lifecycle tiering to Glacier + expiry
    • Right-size + Auto Scaling to cut idle

  4. A workload runs a steady 24/7 baseline plus nightly fault-tolerant batch jobs. How would you optimize compute cost?

    A strong answer covers:

    • Savings Plans / Reserved Instances for the steady baseline
    • Spot for interruptible batch work
    • Mixed-instances ASG: On-Demand baseline + diversified Spot
    • Right-size before committing

    Common wrong turns:

    • Running the always-on database tier on Spot
    • Committing to Reserved capacity before right-sizing
    • Using a single Spot instance type (fleet-wide reclamation risk)

  5. An application behind an Application Load Balancer intermittently returns 504 responses. Walk me through your investigation.

    A strong answer covers:

    • 504 = gateway timeout: the target did not respond in time
    • Compare ALB idle timeout with backend processing time
    • Check target health, target group metrics and access logs
    • Look for saturated backends, slow queries or exhausted connections
    • Security group / NACL misconfiguration between ALB and targets

    Common wrong turns:

    • Assuming 504 always means the load balancer is broken
    • Only restarting instances without finding the saturation cause
    • Confusing 502 (bad response) with 504 (no response in time)

  6. A self-managed database on EC2 has slow disk I/O. How would you diagnose and fix it?

    A strong answer covers:

    • Measure first: CloudWatch EBS and instance metrics
    • Match volume TYPE to the access pattern (SSD vs HDD)
    • Provisioned IOPS (io2) for consistent high random IOPS
    • Instance type can cap EBS bandwidth — check the instance too

    Common wrong turns:

    • Assuming a bigger volume always means more IOPS
    • Ignoring that the instance itself can throttle EBS throughput
    • Using instance store for data that must persist

  7. A CMS runs on an Auto Scaling fleet across AZs and all instances must read and write the same uploaded media. Design the storage.

    A strong answer covers:

    • EFS: shared multi-AZ NFS mounted concurrently
    • Mount targets per AZ with scoped security groups
    • Lifecycle to EFS-IA for rarely-read files
    • Encryption at rest and in transit

    Common wrong turns:

    • Reaching for EBS and trying to share it
    • Storing uploads on instance-local disk that vanishes on scale-in

  8. When would you NOT use Lambda, and what would you use instead?

    A strong answer covers:

    • Long-running or always-busy workloads suit containers/instances
    • Steady high utilization can be cheaper on EC2/ECS
    • Cold starts and latency sensitivity matter
    • Specific runtimes, GPUs or OS control need EC2/ECS

    Common wrong turns:

    • Forcing a long batch job into Lambda
    • Assuming Lambda is always the cheapest option at scale

Answer these with follow-ups and optional AI feedback in the AWS mock interviewer.

Key EC2 comparisons

Lambda vs EC2

Lambda runs code with no servers to manage, scaling automatically and charging per request — ideal for event-driven, spiky or intermittent workloads. EC2 gives full control of a long-running instance — better for steady, stateful, or specialised workloads, and often cheaper at sustained high utilisation. Choose by workload shape and control needs.

Other AWS services to study next

EC2 rarely appears on its own in an exam question — these come up alongside it:

Related AWS topics

← All AWS servicesEBSAuto ScalingELB