Public cloud hyperscalers: AWS, GCP and Azure

Picture two data centers in 2006. The first is a medium-sized facility with about 1,000 servers. The second is a very large one with about 50,000. The first pays about $95 per Mbit/s of network bandwidth per month. The second pays about $13. Storage costs the first $2.20 per GB per month and the second $0.40. One administrator in the first looks after about 140 servers, while in the second one person runs more than 1,000. These are James Hamilton's estimates, reported in the Berkeley “Above the Clouds” report, the same table part 01 used to explain why the cloud stays centralized. Here it explains who can afford to be the cloud.

That gap is the whole story of the Hyperscaler. The slides note that there are a great many public cloud service providers, yet they focus on three. The reason is economic. A provider that buys bandwidth, disks, power and staff at one fifth to one seventh of a medium firm's price can rent capacity by the hour below what that firm pays to own it, and still make a profit. This is Utility computing sold at a wholesale cost base. It is also why the Public cloud model rewards size so strongly: every new customer spreads the fixed cost of software and operations over more machines.

Who could become a provider, and why

Big data centers are necessary but not sufficient. Armbrust and colleagues argue that a provider also needs large-scale software infrastructure (MapReduce, the Google File System, Bigtable, Dynamo) and the operational expertise to run and defend it. In the early 2000s only a handful of internet companies had both. Given those assets, the report lists six motives; the four that matter for the hyperscalers are:

1. Make a lot of money from economies of scale, turning a cost advantage into margin.
2. Leverage existing investment, adding a revenue stream on top of data centers already built for internal use.
3. Defend a franchise, giving existing enterprise customers a cloud path before a rival does.
4. Attack an incumbent, establishing a beachhead before a single “800 pound gorilla” emerges (the report's example is Google App Engine).

The other two are leveraging customer relationships (as with IBM) and becoming a platform (as with Facebook). Keep the four above in mind. The next concepts show that each hyperscaler's origin story fits one of them especially well. The market today reflects the same concentration: in the second quarter of 2026 the three largest providers took almost two thirds of a fast-growing market.

By the early 2000s, Amazon's engineering leaders noticed something expensive. Teams building shopping features were spending about 70% of their time on the same basic plumbing: storage, compute, databases. Amazon later called this undifferentiated heavy lifting: work every team must do that does not set the product apart. Leaders began to think about building “a shared layer of infrastructure services that all these teams can rely on”. They soon saw that outside developers had exactly the same problem, and at a 2003 offsite at Jeff Bezos's house the top managers decided to sell those services to everyone else.

This is the Berkeley motive “leverage existing investment” in its purest form. Werner Vogels, Amazon's CTO, said that many AWS technologies were first developed for Amazon's internal operations. The slide adds the design pressures behind that platform: absorbing huge traffic spikes such as the holiday season, supporting a global store, and moving services onto commodity Linux hardware and open-source software. Building for those pressures forced Amazon to make infrastructure into reusable services with clean interfaces, which is exactly what a customer of a Cloud service provider (CSP) needs.

The public launches came in quick succession. A message queue, SQS, appeared in beta in November 2004. In March 2006 Amazon announced object storage as “storage for the Internet”. In August 2006 EC2 opened in limited beta, renting a Virtual machine (VM) at 10 cents per virtual CPU hour. EC2 made the Infrastructure as a Service (IaaS) model concrete: start a server with an API call in minutes, add more when load rises (Rapid elasticity), and pay only for the hours used (Measured service).

A portfolio slide with twenty product icons looks like a list to memorise. It is easier to read it as a floor plan. Take a small web shop and place each piece of it on the AWS portfolio from slide 51.

The general rule is that every hyperscaler portfolio fits the same six blocks. The slides draw Google Cloud and Azure with exactly the same layout. Learn the categories once and the vendor names become vocabulary: what changes between providers is the name on the box, not the job it does. That is the point of slide 52, which skips a detailed tour of every CSP because the big ones offer similar or comparable services. Building on Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) on any of the three means picking a box in each block.

Comparable is not identical, though. Microsoft's own guide for AWS professionals says the two clouds offer similar products built independently, and warns that “not every matched service has exact feature-for-feature parity”. Even the containers that hold resources differ: AWS organises them under accounts, Azure under subscriptions. These differences in APIs, limits and behaviour are exactly where Vendor lock-in comes from.

In April 2008 a developer could upload a Python web application to Google App Engine and never see a server. Google ran it on its own infrastructure, scaled it as traffic grew, balanced the load and stored the data in Bigtable and the Google File System. The free preview gave each application 500 MB of storage, 200 million megacycles of CPU per day and 10 GB of bandwidth per day, enough for about 5 million page views a month. Raw virtual machines came much later: Compute Engine (often abbreviated GCE) was announced at Google I/O on 28 June 2012 and became generally available on 2 December 2013.

So Google entered the cloud from the opposite end to Amazon. AWS started with hardware-like building blocks and later added managed services. Google started with a fully managed Platform as a Service (PaaS) and only later offered Infrastructure as a Service (IaaS). The Berkeley report turns this into a general way to tell providers apart: by the level of abstraction they present to the programmer, the spectrum part 07 used to place IaaS and PaaS. EC2 sits at the low end, where an instance looks like physical hardware and you control nearly the whole software stack from the kernel up. App Engine sits at the high end, where Google enforced a clean split between a stateless request-reply compute tier and a stateful storage tier, and in return gave you automatic scaling and high availability. Azure, as launched, sat in between.

In Berkeley terms, App Engine is the report's example of “attack an incumbent”: its appeal lay in automating the scalability and load balancing features that developers would otherwise build themselves.

Azure automated some scaling and failover only after you declared your application's properties, so the figure leaves scaling with you.

The constraint is the price of the convenience. App Engine could scale your application automatically precisely because it knew its shape. A general-purpose program that keeps state in memory or needs long computations did not fit. EC2 would run anything, but scaling and failover were left to you because the provider cannot know how your application replicates state. Neither end is better; the right point depends on the task, which is why every hyperscaler now offers the whole range.

Google's portfolio on slide 54 shows that convergence. App Engine is still there in Deployment and Management, now beside Compute Engine for raw VMs, a managed Kubernetes service for each Container, Cloud Storage, Persistent Disk, Bigtable and Cloud SQL. The Application Services block also lists Pub/Sub for messaging and Dataflow and Dataproc for data processing, a reminder of Google's strength in large-scale data. The six blocks are the same as Amazon's; only the names differ.

Picture a company that runs Windows Server in its own data center, signs its staff in through Active Directory, and works in Office every day. Its developers write .NET. For this company, Azure is the shortest road to the cloud: the identities, licences and skills it already has carry straight over. That is the Berkeley motive “defend a franchise”, and the report names Azure as its example: it “provides an immediate path for migrating existing customers of Microsoft enterprise applications”.

Ray Ozzie unveiled Windows Azure at the Professional Developers Conference on 27 October 2008. It became generally available on 1 February 2010 in 21 countries, with full service level agreements. On 25 March 2014 Microsoft announced it would rename the platform Microsoft Azure, and the new name took effect on 3 April 2014. The rename signalled that Azure was no longer only about Windows: by then it ran Linux virtual machines and open-source stacks too. The enterprise focus on slide 55 remains its strongest card, with deep integration across Windows, Active Directory and Microsoft 365.

One map for all three providers

Slide 56 completes the set, and the portfolio once again falls into the same six blocks. Putting the three slides side by side gives the single most useful table in this part. Read each row as one need, then look up the local name on each provider. Where the slide's label is outdated or misplaced, the table gives the current service and notes the slide's version.

The equivalences are close enough to plan a design and to answer exam questions, but each row hides differences. Azure's Cosmos DB, for example, is a fully managed NoSQL and vector database that offers document, key-value, graph and table models, and a 99.999% Availability SLA for multi-region setups. That is broader than DynamoDB or Bigtable, so a migration between them is a redesign, not a copy. This is the practical face of Vendor lock-in on any Hyperscaler. Slide 56 also shows Communication Services, Azure's APIs for chat, SMS, voice and video, which has no box on the other two slides.