Amazon EC2: Rentable Virtual Servers on AWS

WHY IT EXISTS Before cloud computing, running a web application meant buying physical servers, provisioning them in a data center, and living with whatever capacity you bought regardless of actual demand. That was slow to set up and wasteful during quiet periods. Amazon EC2 exists to replace that physical purchase with an on demand rental: compute capacity you can acquire in minutes and give back the moment you no longer need it, without ever touching a physical machine.

THE MENTAL MODEL Think of EC2 as renting a car instead of buying one. You do not own the underlying hardware, you pick a model that fits your needs from a catalog, drive it for as long as you need it, and return it when you are done, paying only for the time you actually had it. The model you pick is an Amazon Machine Image, a template that already has an operating system and whatever software you specify baked in, so the vehicle arrives ready to drive rather than as bare parts.

HOW IT WORKS You choose an AMI and an instance type, which sets the CPU, memory, and network capacity you get, then launch it, which boots a virtual machine called an instance on AWS's physical fleet within a specific region and availability zone. AWS's hypervisor layer isolates your instance from every other customer's instance running on the same physical hardware. Once running, the instance behaves like any server: it has an IP address, you can connect to it, install software, and run workloads. You can launch more instances behind a load balancer as traffic grows, or terminate instances as it drops, and billing is metered by the second the instance is actually running.

WHEN IT MATTERS EC2 matters whenever workload demand is uneven or growing, since capacity can match actual traffic instead of a fixed upfront purchase, and when you need control over where instances physically run, for latency or for redundancy across regions. The footgun is billing: an instance you forgot to terminate keeps charging by the second indefinitely, and it is one of the most common sources of surprise AWS bills, especially for test or demo instances left running after a project ends.

ONE CONCRETE EXAMPLE A startup expecting a traffic spike from a product launch runs a handful of small EC2 instances normally, then, as sign ups surge, launches a dozen more of the same AMI behind a load balancer within minutes, and terminates them again once traffic settles back down a few days later, paying only for the extra hours those instances actually ran.