AWS EC2 — Everything You Need to Know

Understand pricing models, instance types, scaling strategies, load balancing, and deployment options — everything you need to make confident EC2 decisions.

In this guide

1. What is EC2?
2. EC2 Pricing Models
3. Billing states explained
4. Instance types & families
5. Scalability & Elasticity
6. Elastic Load Balancer
7. ElasticBeanStalk & LightSail
8. Burstable Performance

EC2 is the backbone of AWS cloud computing. Whether you’re hosting a web app, running a database, or building a microservices architecture - understanding EC2 deeply will make you a more effective cloud engineer. This guide covers everything from the fundamentals to advanced pricing strategies, with diagrams throughout.

SECTION 01

What Is EC2?

EC2 (Elastic Compute Cloud) is AWS’s web service that provides resizable virtual machines — called instances — in the cloud. Instead of buying and maintaining physical servers, you rent compute capacity from AWS and pay only for what you use.

Fig 1. — Traffic flows from users → ELB → Auto Scaling Group of EC2 instances spread across Availability Zones.

1. EC2 is a Regional Service

AWS services are either Regional (available in specific regions) or Global (available everywhere). EC2 is Regional — when you launch an instance, you choose which AWS region it runs in, and it stays there.

ℹ️ Resizable means you can Scale Up (more power), Scale Down (less power), Scale Out (more instances), or Scale In (fewer instances) at any time. This is what makes EC2 “elastic.”

2. Servers = EC2 Instances (Virtual Machines)

When AWS says “instances,” they mean virtual machines running on AWS hardware. Each instance has a defined amount of CPU, RAM, and storage. You choose the size — AWS handles the physical infrastructure underneath.

✓ Free tier: AWS gives you 750 hours per month of a t2.micro instance free for 12 months — enough to run one instance continuously all month.

3. On-Premises vs Cloud — Why EC2 Wins

Traditional on-premises setups require you to buy, maintain, and manage physical servers. There’s no built-in high availability, auto-scaling, or elasticity. EC2 removes all that burden — AWS manages the hardware and you focus on your application.

On-Premises VS EC2

SECTION 02

EC2 Pricing Models — Choose the Right One

AWS offers six different ways to pay for EC2 instances. Your choice dramatically affects your bill. The right model depends on how long you’ll need the instance, how predictable your usage is, and how much flexibility you need.

On-Demand

Pay per hour

Fixed hourly price. No commitment, no upfront payment. Start and stop anytime. Best for unpredictable workloads or testing.

Reserved Instances

1 or 3 year commit

Up to 72% discount vs On-Demand. Pay full or partial upfront. Best for steady-state, predictable workloads.

SPOT Instances

Bidding/Auction

Up to 90% discount. AWS can reclaim the instance with 2-min notice. Best for fault-tolerant batch jobs.

Dedicated Hosts

Physical server for you

Book an entire physical machine. Full control over instance placement. For compliance or licensing needs.

Dedicated Instances

Isolated hardware

No other customer shares your hardware. You don’t control placement. More expensive than shared tenancy.

Capacity Reservation

Reserve in specific AZ

Guarantees capacity in a specific AZ for any duration. No time commitment needed. Pay even if not used.

Reserved Instances — deeper look

Standard vs Convertible Reserved Instances

Both offer significant discounts for committing to 1 or 3 years, but they differ in how much flexibility you get during that term.

You can buy and sell unused Reserved Instances on the AWS RI Marketplace — so if your needs change, you’re not completely locked in.

Savings Plans — a flexible RI alternative

Savings Plans — commit to spend, not to instances

Similar to Reserved Instances, but instead of committing to a specific instance, you commit to a certain amount of usage (measured in $/hour). This gives more flexibility.

📌 Savings Plans commit you to a 1 or 3 year term based on the amount of usage — not a specific instance. They are locked to an instance family and Region but flexible across instance size, OS, and tenancy.

SPOT Instances — most cost-effective, with a catch

SPOT Instances can save up to 90% — but AWS can reclaim them

SPOT uses AWS’s spare capacity. The price fluctuates based on demand (like an auction). When AWS needs the capacity back, they give you a 2-minute warning and then terminate the instance.

⚠️ Never use SPOT for databases, stateful apps, or anything that cannot tolerate unexpected interruptions. Use SPOT for batch processing, data analysis, rendering jobs, or CI/CD pipelines that can checkpoint and resume.

Shared vs Dedicated Tenancy

Fig 2. — Shared tenancy: multiple customers share hardware (isolated by hypervisor). Dedicated: only your workloads on the physical machine.

SECTION 03

EC2 Billing States — When You Pay and When You Don’t

Understanding billing states is crucial to controlling your AWS costs. The state of your EC2 instance determines whether you’re being charged or not.

⚠️ Stop vs Terminate: Stopping is temporary — your data and configuration are preserved. Terminating is permanent — the instance is destroyed. If you’re on free tier, remember: 5 minutes running + 5 minutes running adds up. Two separate sessions = 2 hours billed total.

SECTION 04

Instance Types & Families

Every EC2 instance has a type that defines its CPU and memory configuration. Instance types are grouped into families based on their optimisation — choose the family that matches your workload’s primary bottleneck.

Instance families

1. General Purpose — balanced CPU and memory

The default choice for most workloads. Balanced CPU and RAM. Examples: web servers, small databases, dev environments. The t2 and t3 families are general purpose.

2. Specialised instance families

Beyond general purpose, AWS offers families optimised for specific workloads. Match the family to your bottleneck — don’t pay for CPU you don’t need.

SECTION 05

Scalability & Elasticity — Growing and Shrinking on Demand

Two of EC2’s most powerful properties are Scalability (changing a single instance’s size) and Elasticity (changing the number of instances). Understanding the difference helps you design cost-efficient, resilient architectures.

Fig 3. — Scalability changes one instance’s size (requires downtime). Elasticity changes the number of instances (no downtime).

Scalability — Scale Up or Down (requires a brief stop)

To change instance type (e.g. t2.micro → t2.small), you must stop the instance, change the type, then start it again. This causes downtime. However, your data is completely safe — it’s stored in EBS volumes, not in the instance itself.

✓ Data is never lost when scaling up or down — because data lives in attached EBS (Elastic Block Storage) volumes, not in the instance’s compute layer. The instance is just CPU + RAM; your files and database are on the volume.

Elasticity — Scale Out or In (no downtime)

Elasticity means adding more instances under a load balancer when traffic spikes (Scale Out), and removing them when traffic drops (Scale In). This is handled automatically by Auto Scaling Groups and has zero downtime — requests simply route to other instances.

ℹ️ The Load Balancer + Auto Scaling Group combination is the standard pattern for production applications. The ELB distributes traffic; the ASG ensures the right number of instances are always running.

SECTION 06

Elastic Load Balancer (ELB)

An Elastic Load Balancer (ELB) distributes incoming traffic across multiple EC2 instances, ensuring no single server is overwhelmed. It’s a service, not a server — you don’t manage it, AWS does.

Key things to know about ELB

ELB is one of the most important services for building production-grade applications on AWS. Understanding its characteristics prevents architectural mistakes.

ℹ️ When a user hits your application’s URL, the request goes to the ELB first. The ELB then forwards it to one of your EC2 instances in the Auto Scaling Group. If one instance fails, the ELB stops sending it traffic automatically.

SECTION 07

ElasticBeanStalk & LightSail — Managed Deployment Options

ElasticBeanStalk — deploy without managing infrastructure

Upload your code — BeanStalk handles everything else

ElasticBeanStalk is AWS’s Platform-as-a-Service (PaaS) offering. You upload your application code, select your platform (Java, Python, .NET, Node.js, Docker, etc.), and BeanStalk automatically provisions EC2 instances, ELBs, Auto Scaling — everything.

✓ Key difference from regular PaaS: In BeanStalk, you retain full access to the underlying EC2 instances. You can SSH in, adjust configuration, and modify anything. This gives you PaaS convenience with IaaS control. The backbone of BeanStalk is EC2.

LightSail — pre-built application servers

LightSail — pre-configured instances with software already installed

LightSail lets you launch instances with popular applications already installed — WordPress, GitLab, Node.js, Joomla, Drupal, Redmine, cPanel, Nginx and more. It’s designed for simple use cases where you want everything ready to go immediately.

⚠️ LightSail limitations: It does not support Auto Scaling, and has no built-in High Availability or automatic elasticity. It’s great for small websites and dev environments — not for production applications expecting variable traffic.

SECTION 08

Burstable Performance Instances

Instances like t2 and t3 are Burstable Performance Instances. Instead of always running at full CPU, they earn CPU credits during low-utilisation periods and spend those credits to burst to higher performance when demand spikes.

Fig 4. — Burstable instances earn credits at low CPU, spend credits during traffic spikes. Burst mode is billable when enabled.

How burstable instances work

A t2.small runs on 2 vCPUs by default. During quiet periods, it accumulates CPU credits. When your app suddenly spikes — a traffic surge, a scheduled job — the instance "bursts" using those credits to deliver higher CPU performance temporarily.

⚠️ Credit Specification (Unlimited mode) is billable. If an instance runs out of CPU credits and Unlimited mode is on, AWS charges you for the extra CPU used above the baseline. For always-on workloads, consider a compute-optimised instance instead.

✓ The number of credits earned per hour depends on the instance type. Larger instances in the t family earn more credits. Check the AWS documentation for the specific credit earning rates per instance type.

QUICK REFERENCE

Key Concepts at a Glance

What you learned

• EC2 is a Regional service — instances run in the region you choose. Free tier gives you 750 hours/month on t2.micro.
• Running = billed.
• Stopped = no compute bill (but EBS storage still billed).
• Terminated = no bill, but data is gone.
• Choose On-Demand for flexibility,
• Reserved for predictable long-running workloads (up to 72% off),
• SPOT for fault-tolerant batch jobs (up to 90% off).
• Scalability = change instance size (requires stop).
• Elasticity = change number of instances (no downtime, handled by Auto Scaling Groups).
• The ELB is a managed service (not a server). Access it via DNS Name. It distributes traffic across EC2 instances across Availability Zones.
• ElasticBeanStalk = upload code, select platform, AWS handles provisioning. You still have full EC2 access. Backbone is EC2.
• LightSail = pre-configured instances with software installed. No Auto Scaling, no HA — good for simple, predictable workloads only.
• Burstable instances(t2, t3) earn CPU credits at low utilisation and spend them during traffic spikes. Burst mode with Unlimited is billable