AWS EC2 (Elastic Compute Cloud) is Amazon's web service that lets you rent virtual computers on-demand. Instead of buying physical servers, you spin up instances in minutes, pay only for what you use, and scale up or down instantly. It's the foundational compute service that powers millions of applications worldwide.
EC2 stands for Elastic Compute Cloud, and it's Amazon's answer to the question: "What if you could rent a computer in the cloud instead of buying one?" Think of it as a vending machine for servers. You select the specs you need—CPU, memory, storage—and within seconds, you've got a running virtual machine.
The word "elastic" is key. Your infrastructure stretches and shrinks automatically. Running a web app that gets 10x traffic during Black Friday? Spin up 100 instances. Traffic dies down Monday? Shut them down. You only pay for those hours of compute time.
Before EC2, companies had three awful options: buy servers upfront (expensive and risky), lease dedicated hardware (inflexible contracts), or cobble together a hybrid nightmare. EC2 changed everything by offering on-demand, disposable compute resources priced by the second.
EC2 runs on top of Amazon's massive global infrastructure. AWS owns and operates data centers across the globe. Within each region, they've carved out isolated chunks called Availability Zones. Inside those zones, they run hypervisors—software that divides physical servers into multiple virtual machines.
When you launch an EC2 instance, you're essentially:
The instance gets a public IP address (if you want it), a hostname, and direct network access. You connect via SSH (Linux/Mac) or RDP (Windows) and interact with it like it's a physical machine sitting in front of you. It's not. It's running on a shared physical server in an AWS data center, virtualized alongside dozens of other customers' instances.
EC2 offers dozens of instance types, and choosing wrong wastes money. Here's the practical breakdown:
Jack-of-all-trades instances. Good for web servers, small databases, and development. They balance CPU, memory, and network. Start here unless you have a specific reason not to.
High CPU performance. Use these for batch processing, machine learning, video transcoding, and anything CPU-bound. You pay more, but you get serious compute power.
Tons of RAM. Perfect for in-memory databases (Redis, Memcached), data warehousing (Redshift), and real-time analytics. If your bottleneck is RAM, go here.
Fast local NVMe storage. For databases with heavy read/write patterns, NoSQL datastores, and Elasticsearch clusters. Less common than the others.
Within each family, sizes range from nano (tiny, cheap) to xlarge and larger. A t3.micro might cost $0.01/hour while a c5.4xlarge runs $0.68/hour. Pick based on your actual needs, not hopes.
AWS offers three ways to pay for EC2:
Pay per second, no commitment. Most flexible, least cost-effective. Great for testing, development, and unpredictable workloads. Standard choice for beginners.
Commit to 1 or 3 years, get 30-70% discount. Ideal for stable workloads running 24/7. You're locked in, but savings are massive for production databases or always-on web servers.
Bid on spare capacity, save up to 90%. AWS can terminate anytime with 2-minute notice. Perfect for fault-tolerant batch jobs, testing, and non-critical workloads. Risky for production.
Real-world strategy: Use Reserved Instances for your baseline (web servers, databases), On-Demand for variable load (autoscaling groups), and Spot for batch jobs and CI/CD.
The AWS Management Console makes this straightforward. Here's the basic flow:
Within 30 seconds, your instance boots. You'll see it in the console with a public IP. Connect via:
ssh -i your-key.pem ec2-user@your-instance-public-ipFor Windows, use Remote Desktop with the decrypted password (AWS provides this). You're now logged into a computer running somewhere in the cloud, and you can install anything—databases, web servers, custom apps.
By default, EC2 instances use EBS (Elastic Block Storage)—network-attached drives that persist even after you stop the instance. Stop and start your instance? Your data's still there. Delete the instance? You can keep the volume or delete it (your choice).
Some instance types also offer instance store—fast local NVMe storage physically attached to the host server. It's blazingly fast but ephemeral. Reboot? Data survives. Terminate the instance? Gone forever. Use it for caches and temporary data, never for anything you care about.
For most beginners, EBS is the safe choice. Volumes are affordable ($0.10/GB-month), reliable, and you can snapshot them for backups.
Security Groups control inbound and outbound traffic to your instance. They're stateful firewalls—if you allow inbound HTTP traffic, responses automatically flow back out.
Common rules:
SSH (Port 22): 0.0.0.0/0 — allow your IP only in production
HTTP (Port 80): 0.0.0.0/0 — allow the world
HTTPS (Port 443): 0.0.0.0/0 — allow the world
Custom TCP (Port 3306): Security Group ID — allow from app servers onlyDefaults are restrictive (good). No inbound traffic is allowed until you explicitly permit it. Many security breaches happen because someone opens port 3306 (MySQL) to 0.0.0.0/0 "temporarily." Don't be that person.
When you stop and restart an EC2 instance, its public IP changes. For servers that need a fixed address (web servers, email, DNS), that's a disaster. Enter Elastic IPs—static public IPs you can allocate and associate with instances.
Allocate one, associate it with your instance, and you've got a permanent address. Stop and start? The IP sticks with your instance. Switch it to another instance? Done in seconds. They're free while associated with an instance, charged if allocated but unused.
EC2 doesn't exist in isolation. Common integrations include:
A typical architecture might be: Users hit an Application Load Balancer, which routes traffic to 3-10 EC2 instances in an Auto Scaling Group, which read/write to an RDS database and store assets in S3. CloudWatch watches metrics and adds instances when CPU hits 70%.
Forgetting to stop instances. They're not running up charges if they're stopped, but they drain money if left running. Set alarms or use AWS Cost Explorer.
Choosing the wrong instance type. A t3.nano is cheap ($0.0035/hour) but painfully slow. A c5.4xlarge is powerful ($0.68/hour) but overkill for a blog. Right-size based on benchmarks, not guesses.
Storing secrets in code. Never hardcode passwords or API keys in code that runs on EC2. Use IAM roles, AWS Secrets Manager, or environment variables (stored securely).
Ignoring security groups. Default to deny everything, allow only what's needed. Regularly audit your rules—old rules accumulate and widen your attack surface.
No backups. EBS volumes can fail. Create snapshots regularly (AWS can automate this) or use RDS, which handles backups for you.
EC2 is powerful but part of a larger ecosystem. Once comfortable with instances, explore:
The free tier includes 750 hours/month of t2.micro instances for 12 months, plus data transfer and storage. That's enough to run a small website or test application at zero cost. Sign up, launch an instance, and get hands-on. That's how you learn.
Yes, but with limitations. You can change instance type only if both the current and target types are compatible (EBS-backed). Stop the instance, change the type via the console, and restart. Changing between instance families or from instance store to EBS requires launching a new instance. Downtime is minimal (minutes) for most workloads.
Stopping pauses the instance—it's not running, not incurring compute charges, but the EBS volume is retained and charged. Restarting brings it back with the same IP and data. Terminating deletes the instance permanently. By default, the EBS root volume is deleted too (unless you change termination protection). Use stop for temporary pauses, terminate when you're done.