Understanding AWS EC2 - Instances, AMIs, and the Compute Foundation

What you will learn

• What EC2 is and why it is the foundation every other AWS service builds on
• AMI types — AWS-provided, Marketplace, and custom — and what each contains
• The EC2 instance family naming format and which family to choose for which workload
• EC2 User Data — the bootstrap script that configures servers automatically at first launch
• Security Groups — the virtual firewall, inbound/outbound rules, and chaining patterns
• Key Pairs and SSH — four methods to connect to EC2 instances
• Public IP vs Private IP vs Elastic IP and what changes on stop/start
• IAM Roles — why they are always better than access keys on EC2
• All EC2 purchasing options — On-Demand, Reserved, Spot, Savings Plans, Dedicated Hosts
• Placement Groups — Cluster, Spread, Partition and the production use case for each
• Elastic Network Interfaces — the failover pattern that keeps IP addresses stable
• EC2 Hibernate — when and why to use it over a normal stop

Why this matters

Every production workload at Swiggy, Razorpay, Zerodha, and Hotstar runs on compute. EC2 is that compute for most teams. Understanding EC2 deeply is not optional — it is the foundation. A wrong instance type means money wasted or performance problems. A poorly configured Security Group means a security incident. Not using IAM Roles and using access keys instead is one of the most common AWS security breaches. Getting EC2 right from day one is what separates infrastructure that scales safely from infrastructure that eventually becomes a liability.

What is EC2

EC2 (Elastic Compute Cloud) is AWS's service for renting virtual servers in the cloud. Instead of buying physical hardware, you rent compute capacity from AWS and pay only for what you use.

EC2 is Infrastructure as a Service (IaaS) — AWS manages the physical hardware, you manage everything above it: the OS, software, security, and applications.

Common use cases:

AMI — Amazon Machine Image

An AMI is a pre-built template containing everything needed to launch an EC2 instance — the operating system, pre-installed software, and configuration. Every EC2 instance starts from an AMI.

AMIs are built for a specific AWS region and can be copied across regions.

Three types of AMIs:

Common AMIs and default usernames:

AMI and EBS snapshots:

When you create a custom AMI from a running instance, AWS automatically snapshots every attached EBS volume.

Remember

Deleting the AMI does NOT automatically delete the underlying snapshots. Orphaned snapshots keep billing you. Always clean them up manually after deleting an AMI.

Instance Types — Choosing the Right Size

The instance type defines CPU, RAM, network speed, and storage performance. Naming format:

The number in the family name is the generation — higher is newer and better. m5 is newer than m4.

General Purpose (T, M families) — balanced CPU, memory, network:

Compute Optimized (C family) — high-performance processors:

Memory Optimized (R, X families) — large datasets in RAM:

Storage Optimized (I, D families) — high sequential read/write:

Accelerated Computing (P, G families) — GPU workloads:

Tip

Compare all instance types side by side at https://instances.vantage.sh — shows pricing, vCPU, RAM, network, and storage for every instance type in every region.

EC2 User Data — Automated Bootstrap

EC2 User Data is a script that runs automatically when an EC2 instance starts for the very first time. It automates initial server setup so you never SSH in and configure manually.

Key rules:

Remember

User Data only runs at first launch. If you need to re-run it, you must stop the instance, modify the User Data, and start again. For ongoing configuration management use AWS Systems Manager or Ansible.

Security Groups

A Security Group is a virtual firewall controlling all inbound and outbound traffic to and from your EC2 instance. Every EC2 instance must have at least one Security Group attached.

Three key characteristics:

1. Allow rules only — no explicit deny:

2. Stateful — return traffic automatically allowed:

3. Region and VPC specific:

Common ports to know:

Security Group chaining — the three-tier production pattern:

The database Security Group source is the App Server Security Group ID — not an IP address. IPs change. Security Group IDs never change.

Security

If your instance shows a connection timeout error, it is almost always a Security Group issue — a port is not open. If it shows connection refused, the Security Group is fine but the application is not running on that port. These two errors tell you exactly where the problem is.

Key Pairs and SSH Access

A Key Pair uses asymmetric cryptography instead of passwords.

Method 1 — SSH on Linux and macOS:

Method 2 — SSH on Windows (PowerShell or Git Bash):

Method 3 — EC2 Instance Connect (browser-based, no key needed):

AWS uploads a temporary one-time key automatically. Port 22 must still be open in the Security Group.

Method 4 — SSM Session Manager (no port 22, no key needed):

No inbound ports required. Instance must have the SSM Agent installed and an IAM Role with AmazonSSMManagedInstanceCore policy. The most secure option for production.

IP Addressing

Public IP:

Private IP:

Elastic IP:

A static public IPv4 address you own and assign to an EC2 instance.

Tip

Avoid Elastic IPs where possible. A better approach is using a Load Balancer with a stable DNS name so you never depend on a raw IP address. Elastic IPs reflect a design that should probably use a load balancer instead.

IAM Roles with EC2

If your EC2 instance needs to call AWS services (S3, DynamoDB, Secrets Manager), the naive approach is running aws configure on the instance and entering personal access keys.

The correct approach — IAM Roles:

Attach role to running instance:

Security

Never store AWS access keys on an EC2 instance. This is one of the most common and dangerous mistakes in cloud security. Use IAM Roles. The SDK fetches temporary credentials automatically. No keys. No risk.

EC2 Purchasing Options

On-Demand: Pay by hour or second. No commitment. Highest per-hour rate. Start/stop anytime.

Reserved Instances: Commit to specific instance type, region, OS for 1 or 3 years. Up to 72% discount. Standard RI cannot change type. Convertible RI can change type.

Savings Plans: Commit to a spend in dollars per hour. More flexible than Reserved Instances.

Spot Instances: Up to 90% off On-Demand. AWS can reclaim with 2-minute warning.

Remember

To stop a persistent Spot setup completely, cancel the Spot Request FIRST then terminate the instance. Terminating alone causes the persistent request to reopen and launch a new instance.

Dedicated Hosts: Entire physical server for your use only. Required for BYOL (Bring Your Own License) compliance. Most expensive option.

Capacity Reservations: Guarantee capacity in a specific AZ. No pricing discount. Combine with Reserved Instances or Savings Plans to get discounts.

Placement Groups

By default AWS decides where to physically place your EC2 instances. Placement Groups let you control that decision.

Cluster — all instances on same hardware in one AZ:

Spread — each instance on completely separate hardware:

Partition — instances divided into groups (partitions) on separate racks:

Elastic Network Interfaces

An ENI (Elastic Network Interface) is a virtual network card. It contains the instance's IP address, MAC address, and Security Group associations. The key insight: these belong to the ENI, not the instance.

The failover use case:

Key facts:

EC2 Hibernate

Hibernate saves the contents of RAM to the root EBS volume. When the instance starts again, that RAM state is reloaded and the instance resumes exactly where it left off.

Requirements:

Use when:

Hands-on Lab — Launch EC2 with User Data and IAM Role

Step 1 — Create a Security Group

Step 2 — Create an IAM Role for EC2

Step 3 — Launch EC2 with User Data

Step 4 — Test the web server

Step 5 — Connect and test the IAM Role

Step 6 — Test Security Group behaviour

Step 7 — Observe IP change on stop/start

Step 8 — Cleanup

Production Best Practices and Common Pitfalls

• Always use IAM Roles — never run aws configure on an EC2 instance and store access keys
• Use SSM Session Manager instead of SSH where possible — no port 22 needed, full audit trail
• Restrict SSH Security Group source to your specific IP — never 0.0.0.0/0 on port 22
• Pre-bake applications into custom AMIs — reduces boot time from minutes to seconds, critical for Auto Scaling
• Tag every EC2 instance from day one — Name, Environment, Team, Project — Cost Explorer is useless without tags
• Use Spot Instances for batch jobs, CI/CD build agents, and ML training — up to 90% savings
• Enable detailed monitoring on production instances — standard monitoring is only 5-minute intervals

Quick Reference and Troubleshooting Commands

Common problems and fixes:

Common Mistake

Opening SSH (port 22) to 0.0.0.0/0 in the Security Group. Automated scanners hit every public IP on port 22 within minutes of an instance launching. Restrict SSH to your specific office or home IP. Use SSM Session Manager in production where port 22 never needs to be open at all.

Tip

When launching EC2 instances for Auto Scaling Groups, always create a custom AMI with your application pre-installed rather than relying on User Data to install everything at boot time. User Data installation takes 5-10 minutes per instance. A pre-baked AMI starts in 60-90 seconds. For a scale-out event adding 10 instances, the difference is 50-90 minutes of delayed capacity versus 10-15 minutes.

Common Mistakes to Avoid

Common Mistake

Opening SSH (port 22) to 0.0.0.0/0 in the Security Group. Automated scanners try port 22 on every public IP in the world within minutes of launch. Restrict SSH to your specific IP only, or better, use SSM Session Manager with no port 22 at all.

Common Mistake

Storing AWS access keys on an EC2 instance by running aws configure on the server. Use IAM Roles instead. The SDK fetches temporary credentials automatically. No keys stored anywhere. No risk.

Tip

Pre-bake your application into a custom AMI instead of installing via User Data on every launch. Boot time drops from 8-10 minutes to 60-90 seconds. ASG reacts faster during scale-out events. This single change often cuts scaling overshoot by 60%.