Skip to content

EC2 (Elastic Compute Cloud)

1. Why This Service Exists (The Real Problem)

The Problem: Before EC2 (pre-2006), if you wanted to host an application, you had to buy physical servers. - Procurement Time: It took 3–6 months to order, ship, and rack servers. - Wasted Money (CapEx): You had to guess your traffic peaks. If you guessed high, you paid for idle metal. If you guessed low, your site crashed. - Inflexibility: Once purchased, you were stuck with that hardware specs for 3-5 years.

The Solution: AWS virtualized the hardware and put an API in front of it. EC2 turns "hardware procurement" into a software API call.

2. Mental Model (Antigravity View)

The Analogy: Hotel Rooms for Software. - You don't buy the hotel (Data Center). - You check in (Start Instance), sleep there (Run App), and check out (Terminate). - You pay exactly for the hours you occupy the room. - If you need a bigger suite (more RAM/CPU), you move rooms (Change Instance Type).

One-Sentence Definition: EC2 is a programmable API that gives you a raw Linux or Windows virtual machine with root access.

3. Core Components (No Marketing)

Ignore the 500+ flashy features. This is what actually matters: 1. AMI (Amazon Machine Image): The "Save State" of a hard drive. It's the template (OS + Pre-installed software) used to boot the server. 2. Instance Type: The hardware specs (e.g., t3.micro = 2 vCPU, 1GB RAM). Defined by CPU, Memory, Network, and Storage capacity. 3. EBS (Elastic Block Store): The virtual hard drive (SSD/HDD) attached to the instance. It persists even if the instance stops (usually). 4. VPC & Subnet: The network environment where the computer lives. 5. Security Group: The instance-level Firewall. It denies all traffic by default and only allows what you whitelist (e.g., Allow port 80). 6. Key Pair: The cryptographic key (PEM file) required to SSH into the box. AWS keeps the public key; you keep the private key.

4. How It Works Internally (Simplified)

  1. Request: You call RunInstances API.
  2. Control Plane: AWS checks your quotas, finds a physical host with available capacity in the requested Availability Zone (AZ), and allocates the slot.
  3. Data Plane:
    • The Hypervisor (Nitro System) partitions a slice of the CPU/RAM from the physical host.
    • It copies the AMI bits onto a fresh EBS volume.
    • It attaches a virtual network interface (ENI).
  4. Boot: The VM boots up.
  5. User Data: Cloud-init scripts inside the VM run once at startup (used for bootstrapping/installing app).

5. Common Production Use Cases

  • Legacy/Monolithic Apps: Applications that haven't been containerized yet.
  • Scalable Web Servers: Running stateless web apps behind a Load Balancer.
  • Databases: Hosting Postgres/MySQL/Redis yourself (if you don't use RDS/ElastiCache) for full control.
  • Worker Nodes: Background processing (video transcoding, data crunching).
  • Bastion Hosts: A "jump box" to securely access private databases.

6. Architecture Patterns

The "Golden Standard" (Stateless Scaling)

Don't perform "pet" management (giving servers names and nursing them). Do "Cattle" management (automated replacement).

Architecture: 1. Auto Scaling Group (ASG): Monitors health. If an EC2 dies, ASG kills it and spawns a clone immediately. 2. Application Load Balancer (ALB): Distributes traffic to all healthy instances in the ASG. 3. Multi-AZ: Instances are spread across at least 2 Availability Zones for disaster recovery.

The "Stateful" Pattern

For simple apps or databases (not recommended for beginners): - One EC2 instance with an Elastic IP (Static IP). - EBS Snapshots scheduled daily for backups.

7. IAM & Security Model

Crucial Concept: IAM Roles (Instance Profiles). NEVER put your AWS Access Keys (AWS_ACCESS_KEY_ID) inside the code or on the disk of the EC2 instance.

The Right Way: 1. Create an IAM Role (e.g., EC2S3AccessRole). 2. Attach policies (e.g., S3ReadOnly). 3. Assign this Role to the EC2 Instance. 4. The AWS SDK on the server automatically fetches temporary credentials from the Instance Metadata Service.

Security Groups: - Inbound: Allow Port 443 (HTTPS) from 0.0.0.0/0 (Internet). - Inbound: Allow Port 22 (SSH) ONLY from your specific IP or VPN.

8. Cost Model (Very Important)

You are billed for: 1. Compute Time: Per second the instance is "Running". (Stopping stops the billing, Terminating stops it forever). 2. Storage (EBS): You pay for the GBs provisioned, even if the instance is stopped! 3. Data Transfer OUT: Traffic leaving AWS (downloading files from your server) is expensive. Inbound is free. 4. Elastic IP: Free if attached to a running instance. Charged if the instance is stopped (hoarding penalty).

Optimization: - On-Demand: Pay full price. Good for spikes/unknowns. - Reserved Instances (RI) / Savings Plans: Commit to 1 or 3 years for ~40–70% discount. - Spot Instances: Bid on spare AWS capacity for ~90% discount. (Warning: AWS can reclaim these with 2 minutes notice). Use for stateless workers only.

9. Common Mistakes & Anti-Patterns

  • "It worked on my machine": Storing data on the Root Volume or Instance Store (ephemeral) and losing it when the instance terminates. Fix: Use S3 or EFS for shared/persistent data.
  • Manual Configuration: SSH-ing in to sudo apt-get install everything. Fix: Use "User Data" scripts or create a custom Golden AMI.
  • Open SSH: Leaving Port 22 open to 0.0.0.0/0. You will get brute-forced in minutes.
  • Zombie Volumes: Terminating an instance but forgetting to delete the attached EBS volumes. You keep paying for the disk.
  • Vertical Scaling: Upgrading t3.micro -> t3.large when traffic hits. Fix: Horizontal scaling (add more micros).

10. When NOT to Use This Service

  • Static Websites: Use S3 + CloudFront (Cheaper, faster, zero maintenance).
  • Simple Microservices: Use Lambda (No server management, pay per request).
  • Containers: Use ECS Fargate (Run containers without managing the underlying EC2s).
  • Databases: Use RDS (Unless you have a DBA team and specific kernel-level tuning needs).

11. Interview-Level Summary

  • Bootstrap: How do you run scripts on startup? User Data.
  • Security: How do you grant an EC2 permission to S3? IAM Instance Profile, not hardcoded keys.
  • Storage: What is the difference between Instance Store and EBS? Instance Store is ephemeral (physically attached, fast, data dies on stop). EBS is persistent network storage.
  • Scaling: Vertical (Instance Type upgrade) vs Horizontal (ASG). AWS prefers Horizontal.
  • Networking: What blocks traffic to an instance? Security Groups (Stateful) or NACLs (Stateless, Subnet level).