Let’s start by building a clear, simple picture of what EC2 actually is before touching any technical detail.

Computing As A Utility

Before cloud computing existed, running an application meant buying a physical machine, shipping it to a data center, and hoping you guessed its size correctly. Too small, and a busy day would crash your website; too large, and you’d waste money on capacity that sat unused most of the time. Amazon EC2, launched in 2006, reframed computing power as a utility you could turn on and off like a tap, similar to how electricity or water is metered and billed by actual usage rather than a fixed monthly hardware purchase.

This shift mattered because it removed a huge barrier to starting something new. A single developer with an idea could rent a fully working server for a few cents an hour, test the idea that same afternoon, and either grow it into a real business or shut it down having risked almost nothing — a process that used to require months of planning and a meaningful upfront investment in hardware.

What You’re Actually Renting

An EC2 instance is a virtual computer — it has its own CPU, memory, storage, and network connection, and behaves just like a physical machine from the operating system’s point of view. You choose how big it should be, which operating system it boots, and how long it should exist, from a few minutes for a quick experiment to years for a stable production application.

Why This Idea Spread Far Beyond EC2

EC2 was one of the very first services to prove businesses would trust a third party with their core computing infrastructure, and that trust opened the door to hundreds of other cloud services built on the same underlying philosophy: pay for a metered utility rather than own the hardware outright. Competing products like Microsoft Azure Virtual Machines and Google Compute Engine emerged directly in response, offering the same rental model, which is why understanding EC2 deeply gives you a mental model that transfers easily to almost any modern cloud platform.

Six Building Blocks Worth Memorizing

EC2 introduces its own vocabulary. These six terms appear constantly and are worth memorizing before moving further into this tutorial.

An EC2 instance never exists in isolation — it’s placed inside a small, carefully fenced-off neighborhood of supporting services.

Your Own Private Section Of AWS

Every EC2 instance launches inside a VPC (Virtual Private Cloud) — your own isolated slice of AWS’s network. Within that VPC, instances live in subnets: a public subnet with a direct route to the internet, and a private subnet without one, typically reserved for databases and internal services that should never be reachable directly from outside.

A Security Group acts as a personal firewall wrapped around each instance, allowing only the specific traffic you define — everything else is blocked by default. Sitting one level above it, a Network ACL filters traffic at the entire subnet, acting as a second, coarser checkpoint.

Where Data Actually Lives

Most instances store their operating system and files on EBS (Elastic Block Store), a network-attached drive that exists independently of the instance itself — stop the instance, and the EBS volume’s data is untouched, just as removing a USB drive from one laptop preserves its contents when plugged into another. Some instance types also offer Instance Store, ultra-fast local disks physically bolted to the host machine that lose everything the moment the instance stops, similar to a whiteboard wiped clean at the end of a meeting.

graph LR
    Internet((Internet)) --> IGW[Internet Gateway]
    IGW --> VPC[VPC]
    VPC --> PubSub[Public Subnet]
    VPC --> PrivSub[Private Subnet]
    PubSub --> SG1[Security Group]
    SG1 --> Web[EC2 - Web Tier]
    PrivSub --> SG2[Security Group]
    SG2 --> DB[EC2 - Database Tier]
    Web --> EBS1[(EBS Volume)]
    DB --> EBS2[(EBS Volume)]
        

Signposts That Decide Where Traffic Goes

A subnet only reaches the internet if its route table explicitly points toward the Internet Gateway — think of the route table as a signpost at every intersection in the neighborhood, without which traffic has no idea how to leave. This is exactly why a private subnet, which intentionally omits that signpost, stays isolated even though it technically shares the same VPC as the public subnet next to it. When a private instance still needs outbound-only internet access, such as downloading security patches, engineers typically route it through a NAT Gateway, which allows traffic out while blocking anything unsolicited from coming back in.

What happens physically, deep inside an AWS data center, between clicking “Launch” and your instance being ready?

One Physical Machine, Several Locked Apartments

A single physical server inside an AWS data center is divided into several isolated virtual machines by a piece of software called a hypervisor. Modern EC2 instances run on AWS’s custom-built Nitro System, which shifts most virtualization work — networking, storage, and security enforcement — onto dedicated hardware chips rather than software, leaving nearly all of the physical machine’s power available to your instance.

Launching An Instance, Step By Step

When you request a new instance, an internal placement service searches AWS’s enormous fleet for a physical host with enough free capacity to fit your chosen instance type. Once a spot is found, the hypervisor allocates the requested CPU, memory, and storage, and boots the operating system from your chosen AMI, typically completing the entire process in under a minute.

sequenceDiagram
    participant User
    participant Console as AWS Console/API
    participant Fleet as Fleet Manager
    participant Hypervisor as Nitro Hypervisor
    participant Instance
    User->>Console: Request new instance
    Console->>Fleet: Find available capacity
    Fleet->>Hypervisor: Allocate CPU, memory, storage
    Hypervisor->>Instance: Boot OS from AMI
    Instance-->>User: Instance running with IP address
        

How Strangers Safely Share The Same Hardware

A natural question is: if unrelated customers share the same physical machine, how can one guarantee another never sees their memory or disk contents? The Nitro System answers this with a dedicated security chip that enforces isolation directly in hardware, rather than depending purely on software rules that could theoretically contain a bug. Even AWS staff with physical access to the data center floor cannot inspect a running customer instance’s contents, because the isolation boundary sits below anything a human operator can reach — a major reason heavily regulated industries like banking and healthcare have grown comfortable running sensitive systems on shared cloud infrastructure.

Every instance passes through the same predictable checkpoints, from the moment it’s born to the moment it’s permanently deleted.

stateDiagram-v2
    [*] --> Pending
    Pending --> Running
    Running --> Rebooting
    Rebooting --> Running
    Running --> Stopping
    Stopping --> Stopped
    Stopped --> Pending : Start
    Running --> ShuttingDown : Terminate
    Stopped --> ShuttingDown : Terminate
    ShuttingDown --> Terminated
    Terminated --> [*]
        

Hibernating Instead Of Restarting From Scratch

Some instance types support hibernation, an alternative to a plain stop that saves the entire contents of memory to the EBS volume before shutting down. When the instance starts again, applications resume exactly where they left off, instead of restarting cold — similar to closing a laptop’s lid rather than powering it fully off, preserving open windows and in-progress work for the next time it wakes up.

Choosing the right size and the right pricing plan often matters more to your monthly bill than any other single decision.

A Fleet Built For Different Jobs

Just as a delivery company uses different vehicles for different loads — a small van for parcels, a refrigerated truck for produce — AWS groups its instance types into families optimized for different kinds of work.

How You Pay Changes What You Pay

Beyond picking a size, EC2 offers several different pricing models, and choosing the wrong one for a given workload is one of the fastest ways to overspend on AWS.

Understanding Burstable Credits

The popular, low-cost T family behaves differently from most other families. Rather than offering a fixed amount of CPU power at all times, it earns “CPU credits” during quiet periods and spends them during short bursts of higher demand, similar to a mobile data plan that lets unused data roll over to cover a particularly busy month. This makes T-family instances extremely cost-effective for workloads that are mostly idle but occasionally need a short burst of power, while making them a poor fit for anything needing sustained high CPU usage around the clock, since the earned credits run out quickly under constant load.

A single instance is always a single point of failure — real production systems are designed to survive losing any one of them.

Spreading Risk Like A Relay Team

Because each Availability Zone is a physically separate data center with its own power and cooling, spreading instances across two or more zones protects an application from a single building’s outage taking everything down at once — much like a relay race team spreading runners across different legs so one runner tripping doesn’t end the whole race.

Auto Scaling And Load Balancing Working Together

An Auto Scaling Group keeps a target number of healthy instances running, automatically launching a replacement the instant one fails a health check, and adding more instances when traffic rises. A Load Balancer distributes incoming traffic evenly across every healthy instance and instantly stops sending traffic to any instance that fails its checks.

graph TD
    Users((Users)) --> R53[Route 53 DNS]
    R53 --> ALB[Application Load Balancer]
    ALB --> AZ1[Availability Zone A]
    ALB --> AZ2[Availability Zone B]
    ALB --> AZ3[Availability Zone C]
    AZ1 --> I1[EC2 Instance]
    AZ2 --> I2[EC2 Instance]
    AZ3 --> I3[EC2 Instance]
    ASG[Auto Scaling Group] -.manages.-> I1
    ASG -.manages.-> I2
    ASG -.manages.-> I3
        

How AWS Notices Something Is Wrong

An Auto Scaling Group and its Load Balancer continuously send small test requests to every instance, checking either that it’s simply running, or, more strictly, that the actual application inside responds correctly on a specific address. After several failed checks in a row, an instance is automatically marked unhealthy, pulled out of rotation, and replaced — often before any human operator would have noticed a problem, which is a major reason cloud-based systems can achieve high availability without a team watching dashboards around the clock.

EC2 security follows the shared responsibility model: AWS locks down the physical infrastructure, and you lock down everything running on top of it.

Layered Like A Bank Vault

Traffic first passes through the subnet-level Network ACL, then the instance-level Security Group, and finally, inside the operating system itself, your application’s own access controls — much like a bank vault protected by a guarded entrance, a locked inner door, and finally an individual safe-deposit box key.

Borrowed Permissions Instead Of Stored Secrets

Rather than storing long-lived passwords or access keys directly on an instance, AWS recommends attaching an IAM Role, letting the instance temporarily borrow exactly the permissions it needs to talk to other AWS services, with no credentials ever written to disk.

Protecting Data At Rest

EBS volumes can be encrypted with a single checkbox at launch, protecting stored data transparently and with essentially no performance cost, thanks to encryption being handled directly by the Nitro System’s dedicated hardware rather than the instance’s own CPU.

Keeping Software Patched At Scale

Because the operating system is the customer’s own responsibility, unpatched software remains one of the most common causes of real-world security incidents on EC2. AWS Systems Manager Patch Manager automates this process, scanning entire fleets of instances and applying security updates on a defined schedule, removing the need to log in to each instance individually and reducing the chance a forgotten server quietly becomes the weakest link in an otherwise secure system.

Running an instance blind, with no visibility into its health, is one of the fastest routes to a painful outage.

CloudWatch: Your Instance’s Cockpit Dashboard

Amazon CloudWatch automatically tracks metrics such as CPU utilization, network traffic, and disk activity, refreshed every five minutes by default or every minute with detailed monitoring enabled. Alarms can be set on these metrics to trigger a notification, or even to automatically launch a replacement instance, without any human watching a screen at that exact moment.

Status Checks And The Audit Trail

Every instance runs two continuous automatic checks: a “system status check,” verifying AWS’s underlying hardware and network are healthy, and an “instance status check,” verifying the instance’s own operating system is actually responding. Separately, CloudTrail records every API call made in your account, creating a permanent audit trail of exactly who launched, stopped, or terminated which instance and when.

Seeing Inside The Application, Not Just The Server

By default, CloudWatch only sees infrastructure-level signals like CPU and network usage — it has no visibility into your application unless told to look. Installing the CloudWatch Logs agent streams application log files, such as web server access or error logs, into a searchable, centralized location, which becomes essential once an application spans dozens or hundreds of instances where checking each one manually would simply be impossible. Teams typically combine these metrics and logs into a single CloudWatch Dashboard, giving on-call engineers one screen that summarizes the health of an entire fleet at a glance.

Getting new code onto a fleet of EC2 instances — and keeping every instance consistent — has evolved into a set of reliable, repeatable patterns.

Wiring It Into An Automated Pipeline

In mature engineering teams, a developer rarely deploys to EC2 by hand. Pushing code to a shared repository instead triggers an automated pipeline that builds the application, runs automated tests, bakes a fresh AMI, and instructs the Auto Scaling Group to begin a rolling replacement of instances. This means the same lifecycle concepts covered earlier — launching, health checking, terminating — happen automatically, potentially dozens of times a day, without anyone manually clicking “Launch Instance” in the AWS console.

A well-known way of thinking about EC2 instances is the difference between treating them as “cattle” versus treating them as “pets.”

EC2 is a genuine trade-off, not a magic bullet, and understanding both sides leads to smarter architectural decisions.

A small handful of avoidable habits are behind most EC2 cost overruns and outages.

EC2 quietly powers a surprising range of high-profile products and events.

Yes, functionally — an EC2 instance is a virtual machine running inside AWS’s data centers, but with additional AWS-specific tooling wrapped around it, such as Security Groups, IAM Roles, and CloudWatch monitoring.

Stopping preserves data on the attached EBS volume. Terminating deletes the instance and, by default, its root EBS volume as well.

Yes. Stop the instance, change its instance type, and start it again — this involves brief downtime and, for some families, different underlying hardware.

Only for parts of a system that can tolerate sudden interruption. They suit batch processing and stateless, fault-tolerant components far better than a primary production database.

You do. Under the shared responsibility model, AWS secures the physical hardware and hypervisor, while operating system updates and application security remain your responsibility.

A stopped instance still incurs charges for its attached EBS storage and any unused Elastic IP addresses, even though compute billing itself has stopped.

New AWS accounts typically receive a limited amount of free EC2 usage for a set period, which is generally more than enough to comfortably learn the basics covered in this tutorial.

Not to get started, but understanding VPCs, subnets, and Security Groups — covered in Chapter 2 of this tutorial — becomes essential as soon as you move beyond a single, simple instance.

Amazon EC2 turns computing power into something you rent by the hour rather than buy outright, giving anyone from a first-time learner to a Formula 1 broadcast team access to the same elastic, on-demand infrastructure. Mastering its core building blocks — instances, AMIs, security groups, EBS storage, and the lifecycle connecting them — provides the foundation for designing systems that scale automatically, tolerate failure gracefully, and stay secure by default.