Amazon EC2 provides virtual servers in the cloud. It allows you to run applications without owning physical hardware.

EC2 instances are virtual machines running on AWS-managed physical hosts. You choose the operating system, install software, configure networking — just like a physical server, but provisioned in seconds and billed by the second.

EC2 sits in the compute layer of AWS:

• Cloud → Compute → Virtual Machines

It is the foundation for:

Think of EC2 like renting a machine:

Every modern EC2 instance runs on the AWS Nitro System — AWS's purpose-built hypervisor platform that replaced the older Xen hypervisor.

A virtual machine running in AWS.

• Runs an OS (Linux or Windows)
• Executes your applications
• Scales based on instance type selection
• Can be started, stopped, and terminated on demand

An EC2 instance moves through specific states during its lifecycle. Understanding what happens at each state is critical for managing data, billing, and recovery.

State	Billing?	EBS Data?	Instance Store?	Notes
pending	No	—	—	Instance launching — allocating resources
running	Yes	✅ Persists	✅ Available	Active — accepting connections, executing code
stopping	No	✅ Persists	❌ Lost	Transitioning to stopped — instance store data lost here
stopped	No (compute) Yes (EBS)	✅ Persists	❌ Gone	No compute charges — EBS volume charges continue
shutting-down	No	Depends*	❌ Gone	*EBS deleted if DeleteOnTermination=true (default for root)
terminated	No	❌ Deleted*	❌ Gone	Instance gone forever — cannot recover

A template used to launch instances. Think of it as a "snapshot" of a configured machine.

Defines the hardware characteristics of your virtual machine:

Family	Optimized For	Example Use Case
General purpose (t3, m5)	Balanced CPU/memory	Web servers, small databases
Compute optimized (c5, c6g)	High CPU	Batch processing, gaming servers
Memory optimized (r5, x1)	High RAM	In-memory databases, caching
Storage optimized (i3, d2)	High disk I/O	Data warehousing, HDFS
Accelerated (p4, g5)	GPU / FPGA	ML training, video encoding

Used for secure access to your instance:

User Data is a script that runs automatically when an EC2 instance starts for the first time. It enables fully automated instance setup without manual SSH access.

Instance Metadata Service (IMDS) provides information about the running instance — its IP address, instance type, IAM role credentials, and more. Accessible from within the instance at http://169.254.169.254/latest/meta-data/.

Feature	IMDSv1 (Legacy)	IMDSv2 (Recommended)
Request method	Simple GET request	Session-based: PUT to get token, then GET with token header
Security	Vulnerable to SSRF attacks (attacker can access metadata via app)	Token-based — prevents SSRF exploitation
Hop limit	Unlimited (containers/proxies can reach it)	Default hop=1 — only the instance itself can reach it
AWS recommendation	Disable in new launches	Enforce as required (block IMDSv1)

• Controls inbound traffic (who can reach the instance)
• Controls outbound traffic (what the instance can reach)
• Rules are stateful — if you allow inbound, return traffic is automatically allowed

Example rules:

Type	Port	Source	Purpose
SSH	22	Your IP	Remote access
HTTP	80	0.0.0.0/0	Web traffic
HTTPS	443	0.0.0.0/0	Secure web traffic

A Virtual Private Cloud is your isolated network in AWS.

• You define IP address ranges (CIDR blocks)
• Control traffic flow between resources
• Isolate environments (dev, staging, prod)

Divide your VPC into smaller networks:

To access an EC2 instance from the internet:

• Public IP — temporary, changes on stop/start
• Elastic IP — static, persists across stop/start
• Internet Gateway — must be attached to VPC

IAM Roles allow EC2 instances to securely access other AWS services without storing credentials on the instance. AWS automatically rotates temporary credentials via the Instance Metadata Service (IMDS).

Common IAM role use cases for EC2:

• Read objects from an S3 bucket
• Write logs to CloudWatch Logs
• Read secrets from Secrets Manager or SSM Parameter Store
• Publish messages to SQS or SNS

Feature	Security Group	Network ACL
Level	Instance	Subnet
Type	Stateful	Stateless
Rules	Allow only	Allow and Deny
Evaluation	All rules evaluated	Rules evaluated in order
Default	Deny all inbound	Allow all

When a user connects to an EC2 instance, traffic passes through multiple checkpoints:

Feature	Auto-assigned Public IP	Elastic IP (EIP)
Assigned when	Launch in subnet with auto-assign enabled	You allocate and associate manually
Persists on stop?	❌ Released on stop — new IP on start	✅ Stays until you release it
Cost when attached	Free (while running)	Free (while attached to running instance)
Cost when NOT attached	N/A	$0.005/hour — AWS charges for wasted IPs
Quota	Unlimited	5 per region (default, can request increase)
Best for	Ephemeral instances, auto-scaling	Static endpoints: NAT, bastion, failover

Persistent block storage attached to EC2 instances.

• Acts like a hard disk attached to your instance
• Survives instance stop and restart
• Can be detached and reattached to another instance
• Supports snapshots for backup

EBS offers multiple volume types optimized for different performance and cost requirements. Choosing the wrong type is a common source of both performance problems and unnecessary cost.

Type	Category	Max IOPS	Best For
gp3	General Purpose SSD	16,000	Default for most workloads — web servers, dev environments
gp2	General Purpose SSD (older)	16,000	Legacy — prefer gp3 (cheaper + better baseline IOPS)
io1 / io2	Provisioned IOPS SSD	64,000+	High-performance databases (MySQL, Oracle, SQL Server)
st1	Throughput Optimized HDD	500	Big data, log processing, data warehouses (sequential access)
sc1	Cold HDD	250	Infrequently accessed data — lowest cost option

Multi-Attach allows a single EBS volume to be attached to up to 16 EC2 instances simultaneously — but only within the same AZ and only for io1/io2 Provisioned IOPS volumes.

Feature	Details
Supported types	io1, io2 only (NOT gp2, gp3, st1, sc1)
Max instances	16 simultaneous attachments
AZ constraint	Same Availability Zone only
Filesystem requirement	Must use cluster-aware filesystem (GFS2, OCFS2) — NOT ext4/xfs
Use cases	Clustered databases, shared storage for HA applications

Temporary, high-performance storage physically attached to the host:

• Extremely high I/O performance
• Data is lost when instance stops or terminates
• Ideal for temporary data: caches, buffers, scratch files

Point-in-time backup of EBS volumes:

• Stored in S3 (managed by AWS — you don't see the bucket)
• Incremental — only changed blocks are saved after first snapshot
• Used to restore volumes or create new volumes in different AZs
• Enable cross-region disaster recovery

Feature	EBS	Instance Store
Persistence	Yes — survives stop	No — lost on stop
Performance	Medium to High	Very High (local NVMe)
Detachable	Yes	No
Snapshot support	Yes	No
Use case	Databases, boot volumes	Caches, temporary data

A single EC2 instance is a single point of failure.

A Launch Template defines exactly how EC2 instances should be created — capturing all the configuration in one reusable, versioned document. Auto Scaling Groups require a Launch Template (or the older Launch Configuration) to know what to launch.

Feature	Launch Template ✅	Launch Configuration (Legacy) ❌
Versioning	Yes — multiple versions, default version	No — immutable, create new for any change
Mixed instance types	Yes — combine On-Demand + Spot in one ASG	No — single instance type only
T2/T3 Unlimited	Yes	No
Spot options	Full control (max price, allocation strategy)	Limited
Network interfaces	Multiple ENIs supported	Limited
Placement groups	Yes	Yes (limited)
AWS recommendation	Use this always	Deprecated — do not use for new setups

Placement Groups control how EC2 instances are physically placed on underlying hardware. Choose based on whether you need low latency, fault isolation, or large-scale distribution.

Placement Group	Use Case	Max Per AZ	Risk
Cluster	Low latency, high throughput between instances	Unlimited (same rack)	Single rack failure = all fail
Spread	Critical instances that must be isolated	7 instances max	Low — separate hardware per instance
Partition	Large distributed workloads (Kafka, HDFS)	7 partitions, many instances	Partition failure = subset fails

Auto Scaling Groups manage a fleet of EC2 instances automatically:

• Maintain desired capacity — always keep N instances running
• Replace unhealthy instances — detect failures and launch replacements
• Scale based on demand — add/remove instances as load changes

Policy Type	How It Works	Best For
Dynamic Scaling	React to metrics (CPU > 70%, request count)	Variable traffic patterns
Scheduled Scaling	Scale at fixed times (e.g., 9am M–F)	Predictable daily/weekly patterns
Predictive Scaling	ML-based forecasting from historical data	Recurring spikes with lead time

Load balancers distribute incoming traffic across EC2 instances:

• Prevent any single instance from being overloaded
• Improve fault tolerance — unhealthy instances are removed
• Enable horizontal scaling transparently to users

Deploy instances across multiple Availability Zones:

• Protects against AZ failure (data center-level outage)
• Ensures system uptime even if one AZ goes down
• ALB automatically routes to healthy AZs

• ELB health checks — ping instances on a configured path
• EC2 status checks — monitor hardware and software health
• ASG integration — automatically terminates and replaces failed instances

EC2 offers multiple pricing options to match different workload patterns:

Savings Plans are a flexible pricing model that offers similar discounts to Reserved Instances but with greater flexibility across services and regions.

Feature	Reserved Instances	Savings Plans
Commitment	Specific instance type + region	Hourly spend commitment (e.g., $10/hr)
Flexibility	Low — locked to instance family	High — applies across EC2, Lambda, Fargate
Discount	Up to 72%	Up to 66%
Best for	Stable, known instance types	Mixed or evolving workloads

• Use Spot for batch processing, CI/CD, dev environments
• Use Reserved for steady-state production workloads
• Stop unused instances — don't pay for idle compute
• Right-size instances — monitor and downsize over-provisioned ones
• Use Savings Plans — flexible alternative to Reserved Instances

• Choose the correct instance family for your workload
• Use SSD-backed EBS (gp3) for latency-sensitive workloads
• Use enhanced networking for high-throughput applications
• Place instances in the same AZ as their data when possible

Capacity Reservations guarantee that EC2 capacity will be available when you need it — without the pricing discount of Reserved Instances. Use them when you need assured capacity during peak events or compliance requirements.

Feature	On-Demand Capacity Reservation	Reserved Instances
Pricing discount?	No — pay On-Demand rate	Yes — up to 72% off
Capacity guaranteed?	Yes — capacity reserved in specific AZ	Optional (zonal RI only)
Commitment	None — cancel anytime	1 or 3 years
Best for	DR readiness, launch events, compliance	Steady-state production workloads
Can combine with Savings Plans?	Yes — get discount + guaranteed capacity	—

Track key metrics to optimize both cost and performance:

Metric	What It Tells You	Action
CPU Utilization	Is the instance over/under-provisioned?	Right-size or scale
Network In/Out	Traffic patterns and throughput needs	Upgrade instance or add ELB
Disk I/O	Storage bottlenecks	Switch EBS type or add IOPS
Status Checks	Hardware/software failures	Auto-replace via ASG

Feature	Basic Monitoring (Default)	Detailed Monitoring
Interval	5 minutes	1 minute
Cost	Free	$2.10/instance/month (7 metrics × $0.30)
Use case	General monitoring	ASG rapid scaling, alerting on fast changes

CloudWatch Agent collects metrics that AWS cannot see from outside the instance:

• Memory utilization — not available in default CloudWatch metrics
• Disk space — filesystem-level usage
• Process counts — running/zombie processes
• Custom application metrics — anything you emit

A complete production architecture includes:

• Frontend tier: ALB + Auto Scaling Group across 2+ AZs
• Application tier: Private subnet EC2 instances with internal ALB
• Database tier: RDS Multi-AZ or Aurora in private subnet
• Monitoring: CloudWatch alarms + SNS notifications
• Security: NACLs + Security Groups + IAM roles

• Avoid single points of failure — always multi-AZ
• Scale horizontally (add instances) not vertically (bigger instance)
• Use automation — ASG, Launch Templates, IaC (CloudFormation/Terraform)
• Monitor system health — CloudWatch metrics + alarms
• Decouple components — use SQS, SNS between tiers

Mistake	Why It's Bad	Fix
Single instance in production	One failure = total downtime	Use ASG + Multi-AZ
Not using Auto Scaling	Over-pay or under-serve	Define scaling policies
Ignoring cost optimization	10x overspend vs. right-sized	Monitor + right-size + RI/Spot
Poor security config	Open ports = attack surface	Least-privilege SGs + private subnets
No monitoring	Blind to failures and waste	CloudWatch + alarms + dashboards