The cloud era, AWS, S3, and the death of the server room

Field note. Why your server isn't on AWS, why some hosts are, why the price difference is what it is.

In 2005, if you wanted to run a website at any scale, you needed servers. Physical machines, in a room you rented or owned, that you bought, configured, maintained, replaced. Setting up a startup's infrastructure took months and tens of thousands of dollars.

By 2015, you could spin up servers in seconds with a credit card. By 2020, "the cloud" was the default deployment model for almost all new software.

This is the story of how that happened.

Before the cloud

The pre-cloud world (1995-2005) had several patterns:

Owned servers in a closet. A small company bought a few servers, kept them in an office closet, hoped the AC worked. Survived as long as the company stayed small.

Colocation. Rent rack space in a data center. Bring your own servers. Pay for power, cooling, bandwidth. Common for growing companies.

Managed hosting. Pay a provider for servers in their data center. They handle the hardware. You handle the software. Pricier than colo, less work.

Dedicated servers from companies like Rackspace, ServerBeach, The Planet. Mid-range option. Decent.

Shared hosting (Dreamhost, GoDaddy, etc.) for small sites. Many sites on one server.

Each had its costs in money, time, and operational complexity. To scale a service, you ordered new servers, waited for them to arrive (days to weeks), racked them, configured them, deployed software, hoped everything worked.

This was the norm. Nobody thought it was weird.

Amazon's needs

Amazon (the bookstore turned everything-store) had built large internal infrastructure for its retail business. They had data centers, custom server designs, monitoring systems, automated deployment, all the operational infrastructure of a large internet company circa 2003-2005.

A pattern emerged: when an internal team wanted to launch a new service, they had to provision servers and infrastructure themselves. This took weeks. Most projects spent more time on infrastructure than on the actual feature.

Amazon engineers built internal services to abstract away the infrastructure work. The retail team could request "a database" or "storage" and get it as a service, without thinking about hardware.

In 2003-2004, Amazon recognized this was a product. Other companies had the same need. They could sell the internal services externally.

S3 (March 2006)

The first major Amazon Web Services product: Simple Storage Service (S3), launched March 14, 2006.

What it offered:

• Unlimited file storage.
• Accessed via simple HTTP API.
• Pay per gigabyte per month plus per request.
• 99.999999999% (eleven nines) annual durability promise.

Before S3, storing arbitrary files at scale meant managing your own disks, your own RAID arrays, your own backups, your own data center. S3 collapsed all of that into "PUT this file; GET it later."

The price was attractive. Storage at $0.15/GB-month. Compared to buying and operating storage, S3 was cheaper by a wide margin for many workloads.

Adoption was fast. Startups built on S3 from day one. Established companies migrated piece by piece. By 2010, S3 was holding trillions of objects.

EC2 (August 2006)

Five months after S3, Amazon launched Elastic Compute Cloud (EC2): virtual servers on demand, paid by the hour.

What it offered:

• Launch a virtual server in seconds.
• Pay only while it runs ($0.10/hour for small instances initially).
• Spin up and down to match traffic.
• No data center, no contracts, no minimums.

This was revolutionary. A startup could deploy without buying any hardware. Want to A/B test something? Launch new EC2 instances. Need to scale for a traffic spike? Launch more. Cleanup later.

Pricing was per-hour. You could pay-as-you-go without commitments. For small companies, this eliminated huge upfront costs.

Adoption took off. By 2008, EC2 was processing millions of API calls daily. New companies were building from the start on AWS rather than on their own hardware.

The cloud ecosystem expands

AWS rapidly added more services:

• RDS (Relational Database Service, 2009). Managed databases.
• CloudFront (2008). CDN.
• DynamoDB (2012). NoSQL database service.
• Lambda (2014). Serverless compute.
• S3 Glacier (2012). Cheap archival storage.
• ... and 200+ others over time.

Each new service let customers do something they previously had to build themselves. Each became a billion-dollar-plus product line.

Microsoft launched Azure in 2010. Google launched Google Cloud Platform in 2011 (with Google App Engine being earlier, 2008). The Big Three cloud providers emerged.

Other providers (DigitalOcean, Linode, OVH, Hetzner, etc.) found niches: cheaper, simpler, specific markets.

What the cloud changed

Several large shifts:

Time to deploy collapsed. From "weeks" to "minutes." Startups could launch products in days.

Capex to opex. Servers were no longer capital expenditures; they were operating expenses. Easier accounting for many businesses.

Geographic distribution became easy. Launch instances in 30 regions worldwide. Previously this would require building data centers worldwide.

Failure tolerance became standard. Cloud services were designed to be deployed redundantly. "Treat servers as cattle, not pets" became the operational maxim.

The Linux/open-source world dominated. Most cloud workloads run on Linux. Windows Server lost relevance for new deployments.

DevOps emerged. Combining development with operations. Infrastructure as code (Terraform, Ansible, CloudFormation). Continuous deployment.

Microservices became practical. When provisioning a new service is free, why not have many of them? Architectures fragmented.

The startup playbook changed. Build on the cloud, scale as you grow, don't think about hardware until you have to.

What it didn't change

Some things stayed:

Real hardware still exists. Cloud providers operate massive physical data centers. The "cloud" runs on physical machines.

Networking matters. Cloud networking has its own complexity (VPCs, peering, transit gateways).

Costs add up. "Pay per use" sounds cheap. At scale, cloud bills can exceed equivalent on-prem costs. Many companies repatriate workloads back to physical infrastructure.

Lock-in is real. Building deeply on AWS-specific services makes migration to GCP or Azure expensive. Vendor lock-in is the cloud era's version of vendor lock-in.

Pricing evolution

Cloud pricing has changed over time:

• Initial prices were high (in retrospect). Margins were significant.
• Competition (especially between AWS and GCP) drove prices down through 2014-2016.
• Pricing has stabilized. New prices are often increases, not decreases, in the late 2020s.
• "Cloud is cheap" assumption breaking. Many large customers find that running their own infrastructure at scale is cheaper.

For small workloads, cloud is undoubtedly easier. For very large workloads, it's a real question.

The repatriation trend

Starting around 2020, a counter-trend emerged: large customers moving workloads out of cloud back to dedicated infrastructure.

Examples:

• Dropbox. Moved storage from S3 to its own data centers in 2015-2017, saving significant money.
• 37signals (Basecamp). Loudly repatriated in 2022-2023, citing better economics.
• Various financial and gaming companies. Workloads that need predictable latency or cost.

The pattern: companies that started small on cloud, scaled, and reached the point where the cloud's flexibility was less valuable than the lower costs of dedicated infrastructure.

This isn't an anti-cloud movement. It's a maturity. The right answer for each workload is "what works." Cloud for startups and dynamic workloads; dedicated for predictable large workloads.

The hyperscalers' grip

In 2026, the cloud market is dominated by three providers (AWS, Azure, GCP) with Oracle, Alibaba, and others as smaller players. The Big Three combined have roughly two-thirds of the cloud market.

This concentration matters:

• Most internet services depend on one of the Big Three.
• A major cloud outage affects huge swaths of the internet.
• Pricing competition is limited.
• Regulatory concerns are real.

The 2021 Akamai outage, the 2017 S3 outage, the 2025 Microsoft Azure issues, all demonstrated how much of the internet is hosted on shared cloud infrastructure.

Whether this concentration will be reduced by regulation, competition, or repatriation is one of the open questions of the next decade.

Cloud and gaming

For game hosting, the cloud has mixed implications:

Web-style backends (login, matchmaking, leaderboards, social) live in the cloud. Standard.

Game servers themselves have a more complicated story. Cloud-hosted game servers are common, especially for indie / small studios who don't want their own infrastructure. But large game services (large MMOs, AAA online games) often run on dedicated infrastructure for cost and latency reasons.

Specialized "game cloud" services exist: services like AWS GameLift, dedicated to game-server orchestration. Useful for some workloads.

For small hosting companies, the question is "use cloud or own metal." Each has tradeoffs. Many serious hosting companies invest in their own data center infrastructure rather than reselling cloud.

Conclusion

The cloud era transformed how software gets built. Server provisioning went from a weeks-long project to a few clicks. Startups could deploy without capital. Established companies got operational flexibility.

The cloud is the dominant infrastructure model for new applications in 2026. It's not the only model. For some workloads, dedicated infrastructure is better. The right answer depends on scale, predictability, regulatory needs, and cost sensitivity.

AWS's 2006 launch was the inflection point. Within 20 years, "the cloud" became default. The pendulum has slightly swung back for some workloads, but the basic shift (most services hosted on virtualized infrastructure) is here to stay.

Coming up

Next: IPv4 runs out, the slow-motion address-shortage crisis that's been unfolding since the 1980s.