What "The Cloud" Actually Is

Cloud Platform Fundamentals

Chapter 1 · What "The Cloud" Actually Is

This course is deliberately cross-provider rather than picking one vendor to specialize in — every concept chapter maps AWS, Azure, and GCP terminology side by side, because in real support work you rarely get to choose which cloud the customer or company happens to be running on. Course 2 goes further, into the specifically operational and troubleshooting skills a support engineer actually needs day to day. This chapter starts with the foundation everything else builds on: what "the cloud" actually means underneath the marketing term.

From On-Premises to "The Cloud"

Running software "on-premises" (on-prem) means an organization owns and operates its own physical servers, in its own building or a rented data center rack, handling everything from buying the hardware to replacing failed disks. "The cloud" replaces that with renting compute, storage, and networking from a provider's own massive data centers — Amazon (AWS), Microsoft (Azure), and Google (GCP) being the three dominant providers today.

Modern cloud computing is generally dated to AWS's 2006 launch of S3 (storage) and EC2 (virtual servers) — the first time renting raw infrastructure by the hour, at scale, became a practical, self-service option rather than something requiring a lengthy contract with a hosting provider.

The Service Models — IaaS, PaaS, SaaS

Cloud services are usually described by how much of the stack you manage yourself versus how much the provider manages for you:

Model	You manage	Provider manages	Examples
IaaS	OS, runtime, app, data, config	Physical hardware, virtualization, network	EC2, Azure VMs, Compute Engine
PaaS	App code, data	OS, runtime, scaling, patching	Elastic Beanstalk, Azure App Service, App Engine
SaaS	Your own data and user access	Everything else, end to end	Gmail, Microsoft 365, Salesforce

Moving down this table (IaaS → PaaS → SaaS), you give up more control in exchange for less operational burden. Chapter 3 (Compute) goes deep specifically on the IaaS layer, since that's where most of the hands-on troubleshooting work in this course actually happens.

The Shared Responsibility Model

Every major provider frames security using the same underlying idea, usually summarized as security "of" the cloud versus security "in" the cloud:

The provider's responsibility ("of" the cloud) — physical data center security, the underlying hardware, the virtualization/hypervisor layer, and the global network infrastructure.
The customer's responsibility ("in" the cloud) — your own data, your IAM configuration (Chapter 6), your network configuration (security groups, firewall rules), and — depending on the service model above — your OS patching and application code.

Exactly where that line sits shifts depending on the service model: with IaaS, you're responsible for almost everything above the hypervisor; with SaaS, you're mainly responsible for your own data and who has access to it.

Arguably the single most useful concept in this chapter for support work

A large share of "the cloud is down" tickets turn out, on investigation, to be a misconfiguration sitting entirely on the customer's own side of the responsibility line — an overly permissive security group, a misconfigured IAM policy, an application bug — not an actual provider outage. Knowing where that line sits, and checking it first, is one of the fastest ways to correctly triage an incident before escalating it. Chapter 5's troubleshooting flowchart in Course 2 builds directly on this distinction.

"Managed service" doesn't mean "zero responsibility"

Even at the SaaS end of the spectrum, where the provider manages essentially everything technical, you're still fully responsible for your own data and access management. An employee's leaked SaaS login, or a document shared with the wrong permissions, is still your organization's problem to handle — the provider secured the platform, not your usage of it.

Why Organizations Migrate to the Cloud

Elasticity — scaling capacity up or down on demand, rather than provisioning for peak load year-round.
CapEx to OpEx — converting large upfront hardware purchases into an ongoing operating expense, paid as you use it.
Global reach — running infrastructure close to customers worldwide without building physical data centers in every region.
Speed of provisioning — a new server ready in minutes, rather than the weeks or months on-prem hardware procurement often takes.
Managed services — offloading operational burden (patching, backups, scaling) onto the provider.

Honestly, though: cloud isn't automatically cheaper, and unmanaged usage can grow costs unpredictably — Chapter 9 covers cost management as its own dedicated topic, not an afterthought. Vendor lock-in (services and APIs specific to one provider, making a future migration harder) is also a genuine, real trade-off worth weighing rather than ignoring.

Public, Private & Hybrid Cloud

Public cloud — shared infrastructure operated by AWS/Azure/GCP, used by many different customers (this course's main focus).
Private cloud — dedicated infrastructure for a single organization, whether on-prem or hosted by a third party.
Hybrid cloud — a deliberate mix of both, often for compliance requirements, latency-sensitive workloads, or legacy systems that aren't practical to migrate.

Hybrid and multi-cloud environments come with their own real support challenges — connectivity between environments, consistent monitoring across both — covered properly in Course 2's cloud2-9.

What This Course Covers

Chapter	Topic
2	The Big Three, Compared
3	Compute Fundamentals
4	Storage Fundamentals
5	Networking Fundamentals
6	Identity & Access Management
7	Databases in the Cloud
8	Monitoring & Logging
9	Cost Management & Billing
10	Security & Compliance Basics
11	Infrastructure as Code — A First Look
12	Choosing & Comparing Providers, and Where to Go Next

Hands-On Exercises

Exercise 1

Classify each scenario as IaaS, PaaS, or SaaS: (a) "we rent virtual machines and manage our own OS patching and web server config," (b) "we just push our application code and the platform handles scaling and runtime patching automatically," (c) "we use a web-based CRM tool and never think about servers at all."

📄 View solution

Exercise 2

A customer's cloud storage bucket was left publicly readable by mistake, and data was accessed by an unauthorized party. Using the shared responsibility model, whose side of the line does this fall on — the provider's or the customer's — and why?

📄 View solution

Exercise 3

Give at least two legitimate reasons an organization might deliberately choose a hybrid cloud setup rather than moving everything to the public cloud.

📄 View solution

Chapter 1 Quick Reference

On-prem = you own the hardware; cloud = you rent it, at scale, self-service, by the hour
IaaS/PaaS/SaaS — how much of the stack you manage vs. the provider does; moving down the list trades control for less operational burden
Shared responsibility model — provider secures "of" the cloud (hardware, hypervisor, network); customer secures "in" the cloud (data, IAM, config); the line shifts by service model
A huge share of "outage" tickets are actually customer-side misconfigurations — check the responsibility line first
Migration drivers: elasticity, CapEx→OpEx, global reach, provisioning speed, managed services — with real trade-offs (cost unpredictability, vendor lock-in)
Public/private/hybrid cloud — hybrid exists for real reasons (compliance, latency, legacy systems), not indecision
Next chapter: The Big Three, Compared — AWS/Azure/GCP terminology mapping, the habit this whole course relies on