Cloud Parts

Amazon EC2

AWS’s virtual machines: pick an instance type, boot an image, and you have a server in minutes.

Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026

What it is

An EC2 instance is a virtual machine running on an AWS server. You choose an instance type, which fixes its vCPUs, memory, network bandwidth and sometimes a GPU or local SSD, and an Amazon Machine Image (AMI) to boot from. AWS offers more than 1,000 instance types across Intel, AMD and its own Arm-based Graviton chips. The instance’s disks are usually EBS volumes attached over the network, and it sits in a subnet of your VPC.

EC2 runs on the AWS Nitro System, which moves networking, storage and hypervisor work onto dedicated cards so nearly all of the host’s CPU goes to your instances. What sets EC2 apart is the purchasing model as much as the machine: On-Demand is billed per second (60-second minimum) on Linux and Windows, Savings Plans cut the price by up to 72% for a one- or three-year spend commitment, and Spot Instances sell spare capacity at up to 90% off, but AWS can take them back with a two-minute warning.

Why teams pick it

  • Full control: any OS, kernel settings, drivers or long-running daemon you like
  • Huge range of shapes, from burstable t instances to multi-GPU and terabyte-memory machines
  • Spot and Savings Plans make steady or interruptible work much cheaper than On-Demand list prices
  • The base layer most other AWS compute (ECS, EKS nodes, EMR) runs on

Watch out for

  • You patch, secure and monitor the operating system yourself
  • Capacity is per instance, so you pay for idle CPU unless you add autoscaling
  • Booting a new instance takes tens of seconds to minutes, too slow for sudden spikes
  • Spot Instances can be reclaimed at any time, so the work on them must tolerate interruption

Alternatives

What all virtual machines have in common →

How it fits with other technologies

Launch a Graviton Spot instance with the AWS CLI · bash

aws ec2 run-instances \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64 \
  --instance-type m7g.large \
  --subnet-id subnet-0a1b2c3d4e5f67890 \
  --security-group-ids sg-0123456789abcdef0 \
  --iam-instance-profile Name=api-server \
  --instance-market-options MarketType=spot \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=api-1}]'

aws ec2 describe-instances --filters Name=tag:Name,Values=api-1 \
  --query 'Reservations[].Instances[].[InstanceId,State.Name,PrivateIpAddress]'

See it in a real stack

No architecture uses Amazon EC2 yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2003–2026

In 2003, Benjamin Black, a network engineering manager at Amazon, and his boss Chris Pinkham wrote a short paper describing infrastructure that was “completely standardized, completely automated, and relied extensively on web services”. Near the end they floated selling virtual servers as a service. In early 2004 Jeff Bezos asked for a detailed write-up of that idea, and the team turned it into a press release and FAQ for what became EC2.

Pinkham returned to South Africa, taking a lead developer with him, and built the EC2 team there. On August 25, 2006, Amazon opened a limited public beta. There was one kind of machine, later called the m1.small: the equivalent of a 1.7 GHz Xeon, 1.75 GB of RAM, 160 GB of local disk and 250 Mb/s of network, for 10 cents an hour, carved out of a physical server by the Xen hypervisor. EC2 dropped its beta label on October 23, 2008.

EC2 made a server something you rent by the hour from an API call rather than buy, rack and depreciate. Much of its later history is about wringing more out of the same hardware: auctioning spare capacity, replacing Xen with AWS’s own Nitro cards, and designing its own Arm chips.

Why it’s built this way

Servers started and stopped by a web service call
The original vision was infrastructure run entirely through automated web services. Exposing that to customers meant a machine could exist for an hour and be thrown away, billed only for the time it ran.
Local disks that disappear with the instance
The first instances only had disk on the host itself, which is lost when the instance ends. Persistent storage was missing until EBS added network-attached volumes in 2008, which is why EBS is the default disk today.
Selling spare capacity at a discount
A cloud has to keep idle machines ready for peaks. Spot Instances (2009) let customers bid on that unused capacity, on the understanding that AWS can take it back.
Moving the hypervisor’s work onto dedicated hardware
Under Xen, emulating network and storage devices ate whole CPU cores, and the cost grew as networks and disks got faster. The Nitro System (2017) moved that work onto separate cards so customers get nearly all of the host’s CPU.

Timeline

  1. 2003

    Black and Pinkham’s paper on standardized, automated, web-service infrastructure

  2. 2006

    Limited public beta opens on August 25 with a single instance type

  3. 2008

    EBS adds persistent volumes in August; beta label dropped in October

  4. 2009

    Spot Instances let customers bid on unused capacity

  5. 2017

    Per-second billing for Linux; Nitro debuts with the C5 instances

  6. 2018

    A1 instances bring AWS’s own Arm-based Graviton processor

  7. 2026

    Graviton5-based M9g instances become generally available in June

Sources9 · facts checked 5 October 2026

Improve this page on GitHub