Twenty years ago today, Jeff Barr published a blog post announcing the Amazon EC2 Beta. One instance type. One Region. A 1.7 GHz Xeon slice with 1.75 GB of RAM, 160 GB of local disk, and 250 Mbps of network bandwidth — yours for $0.10 per hour. No persistent storage. No VPC. No load balancer. You launched an m1.small into a flat, shared /8 network, crossed your fingers, and hoped your app stayed up.
Today, EC2 spans over 1,200 instance types across 39 Regions, powered by five generations of custom silicon. The distance between that 2006 launch and what architects build on today is the story of how cloud infrastructure matured from a clever hack into the foundation of modern computing.
I’ve been using EC2 since 2009 — before VPCs existed, before IAM roles for instances were a thing, before you could even attach a persistent disk without downtime. I remember SSH’ing into instances that lived in a flat, shared network with every other AWS customer, praying that my Elastic IP reassignment would propagate before traffic started dropping. The platform has come an extraordinary distance since then, and this anniversary feels personal. Let me walk you through the arc.
The Original Architecture: 2006–2009
If you launched an instance in August 2006, your architecture looked something like this:
Internet → Public IP (assigned at boot) → m1.small → Local ephemeral disk
That was it. There was no Elastic IP, no persistent block storage, no way to define network topology. Every customer’s instances lived in a single giant 10.0.0.0/8 network — what we now call EC2 Classic. Security groups existed but operated at the instance level in a shared flat space.
The foundational primitives arrived in rapid succession:
- 2008 — Elastic Block Store (EBS) gave instances persistent storage that survived termination
- 2009 — Elastic Load Balancing, Auto Scaling, and CloudWatch made apps scalable and observable
- 2009 — Virtual Private Cloud (VPC) introduced logically isolated networks with subnets, route tables, and gateways
VPC was the architectural inflection point. For the first time, you could design network topology — public subnets, private subnets, NAT gateways, peering connections. The multi tier web application pattern that defined a generation of cloud architecture became possible only after VPC existed.
The Nitro Revolution: 2017
For the first decade, EC2 ran on the Xen hypervisor. Networking, storage, and management functions all competed for CPU cycles on the host. Every packet your application sent had to traverse the same general purpose processor running your workload.
AWS began offloading these functions to dedicated hardware as early as 2013 with the C3 instance family, but the full Nitro System arrived in November 2017. The architecture changed fundamentally:
┌─────────────────────────────────────┐
│ Customer Instance │
│ (nearly bare metal performance) │
├─────────────────────────────────────┤
│ Nitro Hypervisor │
│ (lightweight, minimal attack │
│ surface) │
├───────────┬───────────┬─────────────┤
│ Nitro Card│ Nitro Card│ Nitro Card │
│ (Network) │ (Storage) │ (Mgmt/Sec) │
└───────────┴───────────┴─────────────┘
By moving networking, storage I/O, and instance management onto purpose built Nitro Cards, AWS freed the host CPU entirely for customer workloads. The result: near bare metal performance with the security boundary of a hypervisor. Every EC2 instance launched since early 2018 runs on the Nitro System.
In 2026, AWS pushed isolation even further with the Nitro Isolation Engine — a component inside the Nitro Hypervisor that uses formal verification to provide mathematical proof that customer workloads are isolated from each other and from AWS operators. Not just “trust us” — cryptographic, formally verified assurance.
Custom Silicon: Graviton and the AI Accelerators
The Nitro System made a second revolution possible. Once the hypervisor was thin and the I/O offloaded, AWS could drop in any processor architecture without re-engineering the platform.
Graviton timeline:
| Generation | Year | Key Advancement |
|---|---|---|
| Graviton (A1) | 2018 | First Arm based instances, up to 45% cost reduction for scale out workloads |
| Graviton2 | 2020 | 40% price performance over x86, broad adoption |
| Graviton3 | 2022 | 25% better compute over Graviton2, DDR5 memory |
| Graviton4 | 2024 | 30% better performance, 75% more memory bandwidth |
| Graviton5 | 2025 | 192 cores, 5x larger cache, optimized for agentic AI workloads |
Today’s M9g instances (Graviton5, sixth generation Nitro) are so architecturally distant from the original m1.small that they share little beyond the “general purpose” label. And they’re running workloads — real time reasoning, multi step orchestration, code generation — that did not exist as categories in 2006.
AI accelerators followed a similar trajectory. Inferentia (2019) brought purpose built inference silicon. Trainium (2021) tackled training. By late 2025, Trn3 UltraServers interconnect up to 144 Trainium3 chips to train and serve frontier models. The progression from “rent a virtual CPU” to “reserve a 144 chip training cluster” happened in under 20 years.
What This Means for Architects Today
The architectural decisions you face in 2026 are qualitatively different from 2006, but the meta pattern is the same: match the workload to the right primitive.
Here’s what a modern EC2 launch looks like compared to 2006:
# 2006: Launch an m1.small. That's all there was.
ec2-run-instances ami-xxxxxxxx -t m1.small
# 2026: Launch a Graviton5 instance in an isolated VPC with IMDSv2 enforcement
aws ec2 run-instances \
--image-id ami-0abc123def456 \
--instance-type m9g.2xlarge \
--subnet-id subnet-0a1b2c3d4e \
--security-group-ids sg-0f1e2d3c4b \
--metadata-options "HttpTokens=required,HttpEndpoint=enabled" \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Environment,Value=prod}]'
The CLI call got longer because the platform got richer. Every additional flag represents a decade of lessons learned about security, cost, and operational maturity.
Practical Takeaways
-
Default to Graviton. Unless your workload has a hard x86 dependency (specific licensed software, architecture specific binaries you cannot recompile), start with Graviton instances. The price performance advantage is real and compounding with each generation.
-
Understand the Nitro System boundary. The security model of modern EC2 is fundamentally different from pre-2017 instances. Network and storage I/O never touch your host CPU. The Nitro Isolation Engine provides formally verified separation. Design your threat models accordingly — the Nitro System security whitepaper is essential reading.
-
Use purpose built instances for AI workloads. Running inference on general purpose instances is like using a sedan to haul freight. Inf2 for inference, Trn2/Trn3 for training, and EC2 Capacity Blocks for reserving GPU/accelerator time exist specifically to avoid overpaying for the wrong compute shape.
-
Treat instance selection as an architectural decision, not a default. With 1,200+ instance types, the “just pick an m5.large” reflex leaves performance and money on the table. Profile your workload, right size with AWS Compute Optimizer, and revisit quarterly as new generations launch.
-
Remember that EC2 is still the foundation. Lambda, Fargate, EKS, SageMaker, Bedrock — they all run on EC2 underneath. Understanding the compute layer makes you a better architect regardless of the abstraction you choose to expose to your application.
Looking Forward
EC2’s first 20 years traced an arc from a single shared network with one instance type to a global, multi architecture platform with mathematically proven isolation and purpose built silicon for every workload class. The next 20 will likely be defined by AI native compute patterns, disaggregated architectures, and deployment models we have not yet named.
But the core principle that made EC2 transformative in 2006 has not changed: give builders the primitives, make them minimal yet useful, and iterate relentlessly based on what they actually build. Twenty years in, that flywheel is still spinning.
Happy birthday, EC2. Here’s to the next twenty.
