AWS EC2

---

Cloud Concepts: Scalability, Elasticity & Agility

• Scalability ≠ Elasticity: Scalability is the capacity, elasticity is automatic, dynamic adjustment
• Vertical scaling (scale up/down) = bigger instance; has limits (max instance size)
• Horizontal scaling (scale out/in) = more instances; no real upper limit, fault-tolerant

---

What is EC2?

• Elastic Compute Cloud — virtual servers (instances) in the cloud
• Infrastructure as a Service (IaaS) — you manage the OS and above, AWS manages hardware
• Fully configurable: OS, CPU, RAM, storage, networking, firewall
• Elastic — scale up/down on demand; only pay for what you use

What you can configure:

• OS: Linux, Windows, macOS
• CPU + RAM: instance type
• Storage: EBS (network), Instance Store (physical), EFS (shared)
• Network: VPC, subnet, IP, security groups
• Bootstrap script: EC2 User Data (runs once on first launch)

---

EC2 User Data

• Bootstrap script that runs once on first launch (as root)
• Used to: install packages, start services, pull config from S3
• Runs as the root user — no sudo needed inside the script

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from EC2</h1>" > /var/www/html/index.html

Exam tip: User Data only runs on the first boot by default. To re-run, you must stop the instance, modify User Data, and enable "run on every restart" (not default).

---

Instance Types

Instance type format: [family][generation][attributes].[size] Example: m5.xlarge → General Purpose, 5th gen, extra large

graph TD
    Types[EC2 Instance Types] --> GP[General Purpose<br/>T, M series]
    Types --> CO[Compute Optimized<br/>C series]
    Types --> MO[Memory Optimized<br/>R, X, z series]
    Types --> SO[Storage Optimized<br/>I, D, H series]
    Types --> AC[Accelerated Computing<br/>P, G, Inf series]

    style Types fill:#dbeafe,stroke:#3b82f6
    style GP fill:#dcfce7,stroke:#16a34a
    style CO fill:#fef9c3,stroke:#ca8a04
    style MO fill:#fed7aa,stroke:#ea580c
    style SO fill:#f3e8ff,stroke:#9333ea
    style AC fill:#fce7f3,stroke:#db2777

T Series — Burstable Performance

• Earns CPU credits when CPU usage is below baseline
• Spends credits when CPU bursts above baseline
• t2.micro / t3.micro — Free Tier eligible
• T3 Unlimited mode — can sustain high CPU beyond credits, billed for extra usage
• When credits run out in standard mode → CPU throttled back to baseline

Graviton (ARM-based)

• AWS-designed ARM processors — up to 40% better price/performance than x86
• Series: m6g, c6g, r6g (g = Graviton)
• Requires software compiled for ARM — check compatibility before migrating

Bare Metal Instances

• Direct access to physical hardware — no hypervisor
• Use for: licensing requirements, performance-sensitive workloads, running your own hypervisor
• Examples: m5.metal, i3.metal

---

Pricing Models

graph LR
    Pay[Pricing Models] --> OD[On-Demand<br/>Pay per hour/sec<br/>No commitment]
    Pay --> RI[Reserved<br/>1 or 3 year<br/>Up to 72% off]
    Pay --> SP[Savings Plans<br/>Flexible commitment<br/>Up to 72% off]
    Pay --> Spot[Spot<br/>Spare capacity<br/>Up to 90% off]
    Pay --> DH[Dedicated Host<br/>Physical server<br/>Compliance / BYOL]
    Pay --> CR[Capacity Reservation<br/>Reserve capacity<br/>No discount]

    style Pay fill:#dbeafe,stroke:#3b82f6
    style OD fill:#fef9c3,stroke:#ca8a04
    style RI fill:#dcfce7,stroke:#16a34a
    style SP fill:#dcfce7,stroke:#16a34a
    style Spot fill:#fed7aa,stroke:#ea580c
    style DH fill:#f3e8ff,stroke:#9333ea
    style CR fill:#fce7f3,stroke:#db2777

Reserved Instances — Types

Can be bought/sold on the Reserved Instance Marketplace if you no longer need them.

Spot Instances — Deep Dive

• AWS reclaims with 2-minute warning (Spot interruption notice via metadata)
• Spot Block (deprecated) — used to reserve 1–6 hours without interruption
• Spot Fleet — mix of Spot + On-Demand, targets a capacity and price
• EC2 Fleet — mix instance types across On-Demand, Spot, Reserved
• Never use Spot for: databases, stateful critical workloads, anything that can't be interrupted

Dedicated Host vs Dedicated Instance

---

Security Groups

• Virtual firewall for EC2 instances — controls inbound and outbound traffic
• Operate at the instance level (NACLs operate at subnet level)
• Stateful — allow inbound → response traffic is automatically allowed outbound
• A group can be attached to multiple instances.
• It's locked down to the region or VPC combination.

Rules:

• Only Allow rules — no explicit deny (use NACL for denying)
• Rules define: protocol, port range, source/destination (CIDR or another SG)
• Multiple SGs can be attached to one instance (up to 5 by default)
• Default: all inbound denied, all outbound allowed
• Changes apply immediately

Common ports:
  22   — SSH (Linux)
  21   - FTP (File Transfer Protocol) - upload file into a file share
  22   - SFTP (Secure File Transfer Prootocol) - upload file using SSH
  3389 — RDP (Windows)
  80   — HTTP
  443  — HTTPS
  3306 — MySQL / Aurora
  5432 — PostgreSQL
  27017 — MongoDB
  6379 — Redis
  8080 — HTTP alternate

SG referencing: A security group can reference another SG as the source — all instances in SG-A can reach SG-B without managing IPs. Standard pattern for multi-tier apps (web tier → app tier → DB tier).

Security Groups vs NACLs

Exam trap: NACLs are stateless — return traffic must be explicitly allowed. Security Groups are stateful — return traffic is always allowed.

---

EC2 Instance Connect & Access

Key Pairs

• Public key stored on EC2 (in ~/.ssh/authorized_keys), private key stored by you
• Linux: SSH with .pem file (chmod 400)
• Windows: decrypt Administrator password using private key
• Lost private key → cannot recover. Must: create AMI → launch new instance with new key pair

EC2 Instance Connect

• Browser-based SSH via AWS Console — no key pair needed
• Works only on Amazon Linux 2 and Ubuntu 20.04+
• Requires security group to allow port 22 from AWS IP ranges (not 0.0.0.0/0)
• Pushes a temporary one-time-use key, connects, key expires

SSM Session Manager

• Access instances without SSH, no port 22, no key pair, no bastion host
• Works even in private subnets (agent calls out to SSM endpoint)
• Requires: SSM Agent installed (pre-installed on Amazon Linux 2) + IAM role with AmazonSSMManagedInstanceCore policy
• Audit trail: all sessions logged to S3 or CloudWatch
• Best practice for production — no inbound ports needed

---

IAM Roles for EC2

• EC2 instances need IAM Roles (not access keys!) to call AWS services
• Role is attached as an instance profile — only one role per instance
• Credentials are automatically rotated by AWS
• Application code uses the Instance Metadata Service (IMDS) to get temporary credentials

Never hardcode AWS access keys in EC2 instances or user data. Always use IAM Roles.

---

AMI (Amazon Machine Image)

• A template for launching EC2 instances — includes OS, pre-installed software, configuration
• Region-specific — can be copied across regions
• Types:
  • AWS-provided — Amazon Linux 2, Ubuntu, Windows Server
  • AWS Marketplace — third-party pre-configured AMIs (NGINX, databases, etc.)
  • Custom AMI — snapshot of your configured instance (bake your own stack)
  • Community AMIs — public AMIs from other AWS users

Why use a custom AMI?

• Faster launch — no install/configure on boot
• Consistent environments across all instances
• Golden image pattern — snapshot a known-good state

Launch EC2 → Configure + install → Stop instance → Create AMI → Launch new instances from AMI

Exam tip: Always stop the instance before creating an AMI to ensure data consistency. You can create from a running instance but there may be data integrity issues.

AMI Lifecycle

graph LR
    L[Launch EC2] --> C[Configure]
    C --> S[Stop Instance]
    S --> A[Create AMI]
    A --> CP[Copy to other regions]
    A --> SH[Share with other accounts]
    A --> MK[Make Public]
    A --> D[Deregister when done]

AMI Sharing & Encryption

• Can share AMI with specific AWS accounts or make public
• Encrypted AMI → can share the underlying snapshot KMS key with another account
• Cannot copy an encrypted AMI without access to the KMS key

EC2 Image Builder

• Automates creation, maintenance, validation, and distribution of AMIs
• Define a pipeline: base image → build steps → test → distribute to regions
• Runs on a temporary EC2 instance, creates AMI, terminates instance
• Free to use (pay only for EC2 instances + storage during build)

---

EC2 Instance Lifecycle

graph LR
    Pending --> Running
    Running --> Stopping
    Stopping --> Stopped
    Stopped --> Pending
    Running --> ShuttingDown[Shutting-down]
    ShuttingDown --> Terminated
    Stopped --> Terminated
    Running --> Rebooting[Rebooting]
    Rebooting --> Running

Exam trap: Stopping and starting an instance may change the Public IP unless you use an Elastic IP. Private IP stays the same.

EC2 Hibernate

• Saves in-memory (RAM) state to the EBS root volume — instance resumes where it left off
• Faster startup than a cold start (RAM doesn't need to reload)
• Requirements: EBS root volume must be encrypted, RAM must be < 150 GB, not bare metal
• Max hibernate duration: 60 days
• Use for: long-running processes, pre-warming services that take time to load

---

Storage Options

graph TD
    Storage[EC2 Storage] --> EBS[EBS<br/>Network block storage<br/>Persistent, AZ-bound]
    Storage --> IS[Instance Store<br/>Local physical disk<br/>Ephemeral, very fast]
    Storage --> EFS[EFS<br/>Network file system<br/>Multi-instance, shared]
    Storage --> FSx[FSx<br/>Managed file systems<br/>Windows, Lustre, ONTAP]
    Storage --> S3[S3<br/>Object storage<br/>Not mounted, API-based]

    style Storage fill:#dbeafe,stroke:#3b82f6
    style EBS fill:#dcfce7,stroke:#16a34a
    style IS fill:#fef9c3,stroke:#ca8a04
    style EFS fill:#fed7aa,stroke:#ea580c
    style FSx fill:#e0e7ff,stroke:#4f46e5
    style S3 fill:#f3e8ff,stroke:#9333ea

---

EBS (Elastic Block Store)

• Network-attached block storage — like plugging a USB drive into an instance
• Persists independently of the instance (survives stop/terminate if not set to delete)
• Bound to a single AZ — to move across AZs, take a snapshot → restore in target AZ
• One EBS → one instance (by default). Exception: io1/io2 Multi-Attach

Volume Types

gp3 vs gp2: gp3 is always preferred — IOPS and throughput are configurable independently of volume size. gp2 IOPS are tied to size (3 IOPS/GB). Cannot use HDD (st1/sc1) as boot volume — only SSD types.

EBS Multi-Attach (io1/io2 only)

• Attach one EBS volume to multiple EC2 instances in the same AZ
• Up to 16 instances simultaneously
• Each instance has full read/write permissions
• Must use a cluster-aware file system (not standard ext4/xfs)
• Use for: high-availability applications that manage concurrent writes

EBS Encryption

• Encrypts data at rest, in transit between instance and volume, and in snapshots
• Uses KMS keys (aws/ebs default key or customer-managed)
• Encryption is transparent — no application changes needed
• Encrypt an unencrypted volume: snapshot → copy snapshot with encryption → create volume from encrypted snapshot
• Snapshots of encrypted volumes are automatically encrypted
• Volumes created from encrypted snapshots are automatically encrypted

EBS Snapshots

• Point-in-time backup stored in S3 (managed by AWS, not in your S3 bucket)
• Incremental — only changed blocks after first full snapshot
• Can copy across regions → use for Disaster Recovery or data migration
• EBS Snapshot Archive — move to archive tier (75% cheaper), restore takes 24–72 hrs
• Recycle Bin — protect snapshots from accidental deletion, retention 1 day–1 year
• Fast Snapshot Restore (FSR) — eliminates latency on first restore (extra cost)

Instance Store

• Physically attached local disk — much faster than EBS (millions of IOPS)
• Ephemeral — data lost when instance stops, terminates, or hardware fails
• Persists through reboots only
• Cannot be detached and re-attached
• Use for: temp files, caches, buffers, scratch space where loss is acceptable

EFS (Elastic File System)

• Managed NFS — can be mounted on multiple EC2 instances simultaneously, even across AZs
• Linux only (NFSv4 protocol)
• Scales automatically (no capacity planning needed)
• 3× more expensive than EBS but shared access
• Storage classes: Standard (frequent access) and Infrequent Access (IA) — lifecycle policies auto-move files
• EFS vs EBS: EFS = shared file system across instances; EBS = dedicated block storage per instance

FSx (Amazon FSx)

• Managed third-party file systems — high-performance file storage for specialized workloads
• Unlike EFS (NFS/Linux-only), FSx supports Windows-native and high-performance compute file systems

FSx for Lustre — Key Details:

• Designed for fast, distributed high performance compute — scratch (ephemeral) or persistent storage
• Can be backed by S3 — lazy-loads data from S3 on first access, writes back to S3 on completion
• Scratch: temporary, no replication, maximum throughput (e.g. short batch jobs)
• Persistent: replicated within AZ, survives failures (e.g. long-running HPC)

FSx for Windows — Key Details:

• Integrated with Microsoft Active Directory — supports user auth, ACLs
• Supports DFS (Distributed File System) namespaces for spanning multiple file systems
• Supports SMB protocol and Window NTFS
• Multi-AZ deployment option for HA

Exam tip: Use EFS for Linux shared storage; use FSx for Windows for SMB/AD workloads; use FSx for Lustre for HPC/ML with S3 integration.

---

Networking

Elastic IP (EIP)

• Static public IPv4 address — yours until you release it
• Remaps to another instance in seconds during failure (failover)
• Billed when not associated with a running instance (waste = cost)
• Max 5 Elastic IPs per account (can request increase)
• Best practice: Use DNS (Route 53) or Load Balancers instead of Elastic IPs

ENI (Elastic Network Interface)

• Virtual network card — can have: primary private IP, secondary private IPs, Elastic IP, public IP, MAC address, security groups
• Can be detached and re-attached to another instance in the same AZ
• Use for: failover (move ENI to standby instance), dual-homed instances (two subnets), network appliances
• Each instance has a primary ENI (eth0) that cannot be detached

Placement Groups

Control how instances are placed across underlying hardware:

graph LR
    PG[Placement Groups] --> C[Cluster<br/>Same rack, same AZ<br/>Low latency, 10Gbps]
    PG --> S[Spread<br/>Different racks<br/>Max 7 per AZ]
    PG --> P[Partition<br/>Different racks per partition<br/>Hadoop, Kafka, Cassandra]

    style PG fill:#dbeafe,stroke:#3b82f6
    style C fill:#fce7f3,stroke:#db2777
    style S fill:#dcfce7,stroke:#16a34a
    style P fill:#fef9c3,stroke:#ca8a04

Cluster PG exam trap: All instances in same AZ → if you start more instances later, may get "insufficient capacity" error. Launch all instances at once to maximize success.

---

EC2 Instance Metadata Service (IMDS)

• Internal endpoint: http://169.254.169.254/latest/meta-data/
• Only accessible from within the instance
• Provides: instance ID, AMI ID, IAM credentials, public IP, hostname, etc.

# Get instance ID
curl http://169.254.169.254/latest/meta-data/instance-id

# Get IAM role credentials (temporary)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole

# Get user data
curl http://169.254.169.254/latest/user-data

IMDSv1 vs IMDSv2

Exam tip: AWS recommends requiring IMDSv2. Can enforce via instance settings or SCP.

---

Auto Scaling Groups (ASG)

• Automatically add or remove instances based on load or schedule
• Maintains min / max / desired instance count
• Replaces unhealthy instances automatically using health checks
• Configured via a Launch Template (defines: AMI, instance type, SG, user data, key pair)

graph LR
    LB[Load Balancer] --> ASG

    subgraph ASG[Auto Scaling Group]
        I1[Instance 1]
        I2[Instance 2]
        I3[Instance 3]
    end

    CW[CloudWatch Alarm<br/>CPU > 70%] -->|Scale Out| ASG
    CW2[CloudWatch Alarm<br/>CPU < 30%] -->|Scale In| ASG

    style ASG fill:#dcfce7,stroke:#16a34a,stroke-width:1.5px
    style LB fill:#dbeafe,stroke:#3b82f6
    style CW fill:#fef9c3,stroke:#ca8a04
    style CW2 fill:#fef9c3,stroke:#ca8a04

Scaling Policies

• Cooldown period — after a scaling event, ASG waits before triggering another (default 300s). Prevents rapid thrashing.
• Scale-in protection — protect specific instances from being terminated during scale-in

ASG Lifecycle Hooks

Pause instance at specific states to run custom actions:

Launch: Pending → Pending:Wait → [your action] → Pending:Proceed → InService
Terminate: Terminating → Terminating:Wait → [your action] → Terminating:Proceed → Terminated

• Use for: install software before instance goes live, drain connections before termination, send logs before termination
• Default timeout: 1 hour

ASG Termination Policy (Scale-In)

Default termination order:

1. AZ with most instances
2. Oldest launch template/config
3. Instance closest to next billing hour

ASG Warm Pools

• Pre-initialized instances waiting in Stopped or Running state
• Dramatically reduces launch latency (already initialized)
• Useful when app has long startup/initialization time

Health Checks

• EC2 health check (default) — checks instance state (running vs stopped/terminated)
• ELB health check — checks if app is responding (HTTP 200)
• Always enable ELB health checks when ASG is behind a load balancer — EC2 check alone won't catch app failures

Launch Template vs Launch Configuration

---

Load Balancers (ELB)

Distribute incoming traffic across multiple targets (EC2, Lambda, containers).

graph TD
    Internet([Internet]) --> LB[Load Balancer]
    LB --> I1[Instance 1]
    LB --> I2[Instance 2]
    LB --> I3[Instance 3]

    style Internet fill:#dbeafe,stroke:#3b82f6
    style LB fill:#d0bfff,stroke:#7c3aed
    style I1 fill:#dcfce7,stroke:#16a34a
    style I2 fill:#dcfce7,stroke:#16a34a
    style I3 fill:#dcfce7,stroke:#16a34a

ALB (Most Common in Exams)

• Routes by URL path: /api/* → Target Group A, /web/* → Target Group B
• Routes by hostname: api.example.com vs app.example.com
• Routes by HTTP headers, query strings, source IP
• Targets: EC2, Lambda, IPs, ECS containers
• Sticky sessions — same client always routes to same instance (app-based or duration-based cookie)
• X-Forwarded-For header — contains original client IP (LB IP reaches EC2, not client IP)
• Can return fixed response (200/404/503) directly without forwarding to target
• Can redirect (e.g. HTTP → HTTPS) at the LB level
• Static DNS

NLB

• Handles millions of requests per second with microsecond latency
• Static IP per AZ — can assign Elastic IPs
• No security group on the NLB itself — configure on targets
• Preserves client IP address (no need for X-Forwarded-For)
• Supports: TCP, UDP, TLS termination

GLB

• GENEVE Protocol on IP Packets (L3)
• Route Traffic to Firewalls that you manage on Ec2 Instances
• Intrusion detection

Target Groups

• ALB/NLB route to Target Groups, not directly to instances
• Target types: EC2 instances, IP addresses, Lambda functions, ALB (ALB → NLB → ALB chaining)
• Health checks configured at target group level

Cross-Zone Load Balancing

• Enabled: traffic distributed evenly across all instances in all AZs
• Disabled: traffic distributed evenly across AZs only (AZ with fewer instances gets less per-instance traffic)

Connection Draining (Deregistration Delay)

• Time to complete in-flight requests before instance is deregistered or unhealthy
• Default: 300 seconds (range: 1–3600s, 0 = disabled)
• Set low for short-lived requests, higher for long-running (file uploads, etc.)

SSL/TLS Termination

• LB decrypts HTTPS, forwards HTTP to backend (or re-encrypts with HTTPS)
• Uses ACM (Certificate Manager) to manage SSL certs
• SNI (Server Name Indication) — ALB/NLB can serve multiple SSL certs for multiple domains on the same listener

---

EC2 Exam Cheat Sheet — Common Scenario Questions

---

Summary