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

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.

• 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:

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

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.

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

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

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