Cloud Computing Fundamentals Intermediate

Cloud computing is the on-demand delivery of computing resources — servers, storage, databases, networking, and software — over the Internet, paid for as you use them. Instead of buying and running your own physical machines, you rent capacity from a cloud provider who operates large data centres and lets many customers share that infrastructure.

The widely cited definition comes from the U.S. NIST (National Institute of Standards and Technology). NIST describes cloud computing through five essential characteristics, three service models (IaaS, PaaS, SaaS), and four deployment models (public, private, hybrid, community). The big public providers are AWS (Amazon), Microsoft Azure and Google Cloud (GCP).

NIST lists five traits that distinguish true cloud computing from simply renting a remote server:

• On-demand self-service — you provision resources yourself, instantly, without phoning a salesperson.
• Broad network access — resources are reachable over the network from many device types.
• Resource pooling — the provider serves many tenants from a shared pool, with resources assigned and reassigned dynamically (multi-tenancy).
• Rapid elasticity — capacity can scale out and back in quickly, appearing almost unlimited to the user.
• Measured service — usage is metered, so you pay only for what you consume and can see it reported.

The three service models describe how much the provider manages versus how much you manage:

• IaaS (Infrastructure as a Service) — the provider gives you raw building blocks: virtual machines, storage and networks. You manage the operating system, runtime and your application. Examples: AWS EC2, Azure Virtual Machines, Google Compute Engine.
• PaaS (Platform as a Service) — the provider also manages the OS, runtime and scaling; you just deploy your code. Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine.
• SaaS (Software as a Service) — the provider manages everything, including the application itself; you simply use it through a browser. Examples: Gmail, Microsoft 365, Salesforce.

A common analogy is pizza: IaaS gives you the kitchen, PaaS gives you a ready oven and dough, SaaS delivers the finished pizza.

Where the cloud runs and who can use it defines the deployment model:

• Public cloud — infrastructure owned by a provider and shared by many customers over the Internet (AWS, Azure, GCP). Lowest upfront cost, huge scale.
• Private cloud — cloud infrastructure dedicated to a single organisation, run in its own data centre or by a provider. More control and isolation, often for compliance.
• Hybrid cloud — a mix that connects private and public clouds so workloads and data can move between them (for example, keep sensitive data private but burst to public cloud for peaks).
• Multi-cloud — deliberately using more than one public provider at once, to avoid lock-in, improve resilience, or pick the best service from each.

The cloud is built on virtualization: the ability to run many isolated virtual machines (VMs) on one physical server. This is what makes resource pooling and elasticity economically possible — one big machine is sliced into many independent rented ones.

The software that creates and manages VMs is the hypervisor. A Type 1 (bare-metal) hypervisor runs directly on the hardware (for example VMware ESXi, Microsoft Hyper-V, or the KVM/Xen technology behind public clouds) and is what providers use for performance and isolation. A Type 2 (hosted) hypervisor runs on top of a normal operating system (for example VirtualBox), more common on desktops. The hypervisor gives each VM its own virtual CPU, memory and devices while keeping tenants isolated from each other.

Compute is the raw processing power that runs your code. The classic unit is the cloud virtual machine — called an instance on AWS EC2, a VM on Azure, and a Compute Engine instance on GCP. You choose an instance type (CPU, memory) and an image, and it boots in seconds.

Because demand changes, you rarely run a fixed number of VMs. Autoscaling automatically adds instances when load rises and removes them when it falls, against rules you set (for example, target 60% average CPU). This is horizontal scaling (scaling out, adding more machines), distinct from vertical scaling (scaling up, giving one machine more CPU/RAM). Horizontal scaling is preferred in the cloud because it has no single-machine ceiling and pairs naturally with load balancing.

Cloud storage comes in three main shapes, each suited to different jobs:

• Object storage — stores files as objects (data plus metadata) in a flat namespace of buckets, accessed over HTTP APIs. Hugely scalable and cheap; ideal for backups, media, static websites and data lakes. Example: Amazon S3 (Azure Blob Storage, Google Cloud Storage).
• Block storage — raw volumes that attach to a single VM and behave like a hard disk; you put a filesystem on them. Ideal for databases and boot disks needing low latency. Example: AWS EBS, Azure Managed Disks, GCP Persistent Disk.
• File storage — a shared filesystem (NFS/SMB) that many machines mount at once. Ideal for shared application data. Example: Amazon EFS, Azure Files.

Your cloud resources live inside a private, logically isolated network. On AWS this is a VPC (Virtual Private Cloud); Azure calls it a Virtual Network (VNet) and GCP a VPC network. You give it a private IP range (a CIDR block) and carve it into subnets.

• Public subnets have a route to an Internet gateway, so resources there can be reached from outside.
• Private subnets have no direct inbound Internet route — ideal for databases and internal services.

Traffic is filtered by security groups — stateful virtual firewalls attached to instances that allow specific ports and sources (for example, allow TCP 443 from anywhere, allow TCP 22 only from the office). A broader, stateless layer (network ACLs) can filter at the subnet boundary.

Running a database yourself means patching the OS, configuring backups, handling failover and tuning replication — a lot of operational toil. A managed database hands those chores to the provider while you keep your data and schema.

The provider automates backups, software patching, and often high availability (a standby replica that takes over automatically) and read replicas for scaling reads. Examples include Amazon RDS and Aurora, Azure SQL Database, and Google Cloud SQL for relational engines, plus NoSQL options like DynamoDB, Cosmos DB and Firestore. Some are serverless, scaling capacity automatically with no instance to size. The trade-off is less low-level control in exchange for far less operational work.

Beyond full VMs, two lighter models dominate modern cloud apps:

• Containers package an application with its dependencies into a portable unit that shares the host OS kernel, so they start fast and pack densely. Docker builds them; Kubernetes orchestrates them at scale. Managed offerings include Amazon ECS/EKS, Azure AKS and Google GKE.
• Serverless functions (Function as a Service, FaaS) let you upload a single function that the provider runs in response to events, scaling automatically and billing only while it executes — you never manage a server. Examples: AWS Lambda, Azure Functions, Google Cloud Functions.

“Serverless” does not mean there are no servers — it means you do not provision or manage them.

To stay fast and survive failures, cloud apps spread work across many instances. A load balancer sits in front and distributes incoming requests across a pool of healthy instances, running health checks and routing around any that fail. (AWS ELB/ALB, Azure Load Balancer, Google Cloud Load Balancing.)

Providers organise data centres into Availability Zones (AZs) — isolated facilities within a Region. For high availability, you deploy instances across multiple AZs so the failure of one zone does not take your service down. For disaster recovery and global reach, you can run across multiple Regions. The principle is the same throughout the cloud: remove single points of failure by adding redundancy.

Security in the cloud is a partnership. The widely used shared-responsibility model draws a line between the two parties:

• The provider is responsible for the security of the cloud — the physical data centres, hardware, the hypervisor and the core managed services.
• The customer is responsible for security in the cloud — their data, access control and identities, OS patching (for IaaS), network rules, and how they configure services.

Where the line falls depends on the service model: with IaaS the customer manages more (including the guest OS), while with SaaS the provider handles almost everything except the customer’s data and user access. Most real-world cloud breaches stem from customer-side misconfiguration — such as a storage bucket left public — not from the provider’s infrastructure being broken.

The cloud changes how you pay for IT. Traditional infrastructure is capital expenditure (CapEx) — large upfront purchases of hardware you own and depreciate. The cloud shifts this to operational expenditure (OpEx) — ongoing usage-based charges with little upfront cost.

Common pricing options:

• Pay-as-you-go (on-demand) — pay per hour/second or per request, no commitment; most flexible, highest unit price.
• Reserved / committed use — commit to 1 or 3 years for a large discount; best for steady, predictable workloads.
• Spot / preemptible — deeply discounted spare capacity that can be reclaimed at short notice; great for fault-tolerant batch jobs.

Because you only pay for what you use, turning off idle resources and right-sizing instances directly cuts the bill.

Identity and Access Management (IAM) controls who can do what to which resources. It is the backbone of cloud security. Core concepts:

• Users and groups — identities for people.
• Roles — sets of permissions that can be assumed temporarily, including by services (for example, letting a VM read one storage bucket without embedding long-lived keys).
• Policies — documents that grant or deny specific actions on specific resources.

The guiding principle is least privilege: grant only the permissions actually needed, nothing more. Combined with multi-factor authentication (MFA) and short-lived role credentials, this limits the damage if any single credential is compromised. AWS IAM, Azure roles/Entra ID, and Google Cloud IAM all follow this pattern.

Two practices keep cloud systems observable and reproducible.

Monitoring and observability let you see what your systems are doing: metrics (numbers over time, like CPU or request rate), logs (event records), and traces (the path of a request across services). Tools such as Amazon CloudWatch, Azure Monitor and Google Cloud Monitoring collect these and can fire alerts when thresholds are crossed.

Infrastructure as Code (IaC) means defining your servers, networks and services in version-controlled text files rather than clicking in a console. Running the file creates the same environment every time — repeatable, reviewable and easy to recreate. Tools include Terraform (multi-cloud), AWS CloudFormation, Azure Resource Manager/Bicep and Google Cloud Deployment Manager. IaC is usually declarative: you describe the desired end state and the tool figures out the steps.

Moving existing systems to the cloud is rarely all-or-nothing. The common strategies (often called the “R”s) include:

• Rehost (“lift-and-shift”) — move applications to cloud VMs largely unchanged. Fast and low-risk, but you do not gain much cloud-native benefit.
• Replatform — make a few optimisations during the move, such as switching to a managed database, without rewriting the app.
• Refactor (re-architect) — redesign the application to be cloud-native (containers, serverless, autoscaling). Most effort and cost, but the biggest long-term payoff in scalability and efficiency.
• Repurchase — replace it with a SaaS product. Retire — switch off what is no longer needed. Retain — leave some systems where they are for now.

A typical approach starts with lift-and-shift to get into the cloud quickly, then refactors the highest-value workloads over time.