Choosing a Cloud Provider
Welcome to the Course 🎉
This lesson introduces the major cloud providers and gives you a practical way to choose a sensible starting point.
In this lesson, you will learn to:
- Summarize the origins and typical strengths of Amazon Web Services, Microsoft Azure, and Google Cloud.
- Identify how each provider organizes resources, billing, and permissions.
- Explain why existing agreements, staff skills, and software often create a natural default provider.
This lesson starts with the question every stakeholder asks first: which provider should we use, and why?
Where the Big Three Came From and What They Are Good At 🔎
The three largest cloud providers are Amazon Web Services, Microsoft Azure, and Google Cloud. It helps to know where each one came from, because their origins still shape what they are best at today.
Amazon Web Services (AWS) launched first, in 2006, out of Amazon's own need to run a very large online retailer. Because it has been building longest, it has the widest catalogue of services, and the largest pool of engineers who already know it. If a capability exists in cloud computing at all, it almost certainly exists on Amazon Web Services.
Microsoft Azure came from a company that was already inside almost every corporate office. That is its real anchor: it aligns closely with the Microsoft software organizations already run, including Windows Server, Microsoft 365, and Active Directory, which is the directory system that holds staff usernames and permissions. If a company already pays Microsoft for licensing, Azure tends to slot into those agreements with the least friction.
Google Cloud grew out of the engineering Google built to run search, YouTube, and its own advertising systems. Its factual anchor is large-scale data and analytics work, along with containers, since Google originally created the Kubernetes project that most container platforms now use.
Notice what none of those descriptions say. They do not say one is faster, safer, or "best-in-class". Those are marketing adjectives, and stakeholders will (rightly) distrust you if you use them. Stick to the factual anchors: who launched first, who fits an existing Microsoft estate, who grew out of large-scale data engineering.
How Each Provider Organizes Your Work ⚖️
Every provider gives you containers for grouping resources, and those containers are where billing and permissions get drawn. Getting the vocabulary right matters, because it is the first thing a finance or security stakeholder will ask about.
The provider names differ, but the hierarchy is easy to compare at a glance:
| Provider | Resource Container | Billing and Organization Context |
|---|---|---|
| Amazon Web Services | Account | Organizations is the umbrella grouping multiple accounts, such as separate production and test accounts. |
| Microsoft Azure | Resource group | Resource groups sit inside a subscription, where billing is drawn; a directory tenant holds users and permissions. |
| Google Cloud | Project | Projects can be nested in folders under an organization. |
The pattern is the same everywhere even though the words differ: a small container for related resources, a bigger container that owns the bill, and a structure above that for the whole company. When someone asks "how will we stop the marketing experiment spending our production budget?", the answer is always "we put it in a separate account, subscription, or project."
What if You Go Against the Default? 🪟
Stakeholders will push on this, so be ready with a concrete answer rather than an abstract one. Suppose a company runs its applications on Windows Server and already owns those licences, but chooses Amazon Web Services anyway. What actually changes?
- It still works. Amazon Web Services runs Windows Server virtual machines, and it offers a managed Active Directory service, so nothing is technically blocked.
- The licence is usually paid twice. A standard Windows virtual machine on Amazon Web Services has the Windows licence built into the hourly rate, so the company pays for Windows again on top of the licences it already owns. Azure's Hybrid Benefit lets those existing Windows Server licences be applied to Azure virtual machines, so only the compute is charged. Reusing owned licences on Amazon Web Services is possible, but it requires dedicated hosts and licence-mobility rules, which is extra work and often extra cost.
- Identity takes more assembly. Connecting on-premises Active Directory to Azure is a well-trodden path; on Amazon Web Services it is a supported but longer integration project.
So the honest answer to "would it be more expensive?" is: for the same Windows workload, usually yes on the licensing line, and the gap grows with the number of Windows virtual machines. That is a cost difference you can quantify, not a claim that one provider is better.
Why Most Organizations Already Have a Default 💡
Here is the idea to carry out of this lesson: for most organizations, the provider choice is not really an open contest. Existing agreements, existing staff skills, and existing software already point somewhere. A firm running Microsoft 365 and Active Directory across 120 people has a natural pull toward Azure, not because Azure is superior, but because identity, licensing, and support relationships are already there. A team of three engineers who all hold Amazon Web Services certifications has a natural pull toward Amazon Web Services, because retraining costs real months.

Here, Nina, who runs a small analytics startup unrelated to our firm, asks Chris, a cloud adviser, to recommend a provider.
- Nina: Just tell me which one is best. I need a name before our board call.
- Chris: I can give you a starting point, but the reason matters more than the name. What is your team already fluent in?
- Nina: All four of our engineers hold Amazon Web Services certifications, and our product already runs there.
- Chris: Then Amazon Web Services is the sensible default, because the skills and the running system are already there. Moving would cost months of retraining for no clear gain.
- Nina: And what would change that?
- Chris: If you signed a large Microsoft licensing deal that made Azure cheaper overall, or if a client required your data to sit in a region Amazon Web Services does not serve. Those are the two things worth watching.
Observe what Chris did there. He named a front-runner rather than hiding behind "it depends," but he grounded it in the team's own facts and stated what would overturn it.
A natural default is not a rushed decision. It is a defensible starting position that saves the organization from a six-month evaluation it does not need, while leaving the door open if the facts change.
The takeaway is this: providers differ less than the marketing suggests, and the honest deciding factors are usually the contracts, skills, and software an organization already owns. Two quick pattern checks come next, one matching each provider to its factual anchor and one sorting the organizing terms into the right provider, before you take the argument into a live conversation with a director who wants a name, not a lecture.
