Cloud Computing Fundamentals

Cloud learning path · Step 1Available

Understand virtualization, IaaS, PaaS, SaaS, regions, availability and why cloud costs need constant attention.

Difficulty: Intermediate
Time: 85 min
Practice: Service model comparison
Assessment: Knowledge check

Before you start

Who is this for?

For teams moving workloads to the cloud or building cloud-native applications who want to understand trade-offs.

Prerequisites

Basic networking and systems concepts
No cloud experience needed

What you'll be able to do

Distinguish IaaS, PaaS and SaaS
Understand regions, availability zones and disaster recovery
Explain shared responsibility and compliance
Recognize cloud cost drivers and optimization

Practical outcome

You can evaluate which cloud service model fits your workload and architecture for cost and availability.

Cloud computing shifts infrastructure from capital expenditure (buying servers) to operational expenditure (paying for what you use). This enables flexibility but requires different thinking about architecture, security and cost.

1. From Physical to Virtual to Cloud

Physical: Buy servers, install operating systems, and operate them yourself. Capacity has upfront costs and can take time to procure and install.

Virtualization: Multiple operating systems run on shared hardware. Capacity can be allocated more flexibly, while the organisation still manages the virtual infrastructure.

Cloud: Providers expose computing, storage, and other services through consoles or APIs. You can provision on demand; automatic scaling requires service support and deliberate configuration.

2. Service Models: IaaS, PaaS, SaaS

Cloud providers offer services at different levels of abstraction. Understanding the difference tells you what you manage and what the provider manages.

Model	You Manage	Provider Manages	Example
IaaS	Application, Runtime, OS	Virtualization, Storage, Networking	AWS EC2, Azure VMs
PaaS	Application code, data, identities, and service configuration	Platform runtime, OS, middleware, and infrastructure	Heroku; a managed app platform
SaaS	Data, identities, access settings, and client devices	Application and underlying service stack	Microsoft 365, Slack, Salesforce

AWS Lambda is commonly described as serverless or function as a service (FaaS); provider labels vary, so compare the actual service boundary instead of treating every product as a textbook PaaS example. The shared responsibility model varies by service and still leaves customers responsible for data, identities, and access.

On-premises means your organisation operates its own infrastructure, though vendors and managed providers may still be involved.

3. Regions, Availability Zones and Disaster Recovery

Cloud providers spread infrastructure globally.

Region: A geographic area that contains cloud services and one or more availability zones.
Availability Zone: An isolated location within a region. In AWS, a zone consists of one or more distinct data centers with redundant power, networking, and connectivity; other providers define zones according to their own architecture.
Edge location: A provider point of presence used by services such as content delivery; its exact role varies by service.

For high availability: Design across multiple availability zones when the service supports it. You still need suitable data replication, health checks, and traffic failover; spreading resources across zones alone does not make an application fail over automatically.

For disaster recovery: A second region can help address region-wide failures. Recovery speed and data loss depend on replication, application design, and the failover plan.

RPO (Recovery Point Objective) and RTO (Recovery Time Objective) guide decisions:

RPO: How much data loss is acceptable? (5 minutes, 1 hour, 1 day)
RTO: How long can the system be down? (5 minutes, 1 hour, 24 hours)

Very tight RPO/RTO targets may require frequent or continuous replication and automated recovery, with added cost and complexity. The design should match tested recovery needs.

4. Shared Responsibility Model

Cloud providers do NOT manage everything. Responsibility is shared.

Provider commonly manages:

Physical facilities, hardware, and underlying infrastructure.
More of the operating system and application platform as you move from IaaS through PaaS to SaaS.

Customer responsibilities always include:

Data, identities, access decisions, and client devices.
Correctly configuring the cloud service and protecting credentials.

The customer may also manage the guest operating system, application code, network controls, and encryption choices depending on the selected service. Check that service’s responsibility matrix; a provider name or service-model label alone is not enough.

Confusion about responsibility is a common source of security breaches. Verify the provider’s documentation for each service.

5. Compliance and Data Governance

Cloud adoption does not exempt you from regulatory requirements. In fact, it adds complexity.

Common compliance frameworks:

GDPR: Applies to covered processing of personal data in the circumstances set out by the regulation; scope is not determined only by a person’s residence.
HIPAA: Applies to covered entities, business associates, and protected health information as defined by US law.
PCI DSS: Sets requirements for environments that store, process, or transmit payment account data.
SOC 2: An independent attestation report against Trust Services Criteria, not a law or certification. Verify the scope and period of any report.

Cloud considerations:

Data residency: Some regulations require data to stay in specific regions.
Data sovereignty: Some countries require data to be hosted locally.
Audit trails: You must prove you manage data securely.
Third-party risk: You inherit risk from the provider and their subcontractors.

Choose providers and regions that align with your compliance requirements before migrating.

6. Cloud Cost Drivers and Optimization

Cloud enables flexibility but can explode in cost without discipline.

Cost drivers:

Compute: How many instances and how long they run.
Storage: Volume, type (SSD vs HDD) and durability.
Data transfer: Charges depend on the provider, service, region, route, and pricing plan. Check actual service pricing, including inter-zone, inter-region, and outbound traffic; do not assume same-region traffic is always free.
Licenses: Bring-your-own-license or vendor licensing affects costs.

Optimization strategies:

Right-size: Use only the compute and memory you need. Monitor utilization.
Commitment discounts: Some providers offer lower rates in exchange for a time or usage commitment. Compare the current offer, flexibility, and cancellation terms; discount levels vary by service and region.
Spot instances: Use excess capacity at a discount for fault-tolerant workloads.
Auto-scaling: Scale down when demand drops.
Data transfer: Minimize egress; cache at edge locations.
Tagging: Track costs by team, project or environment.

Set up billing alerts and review costs monthly. A forgotten test environment running expensive instances is a common surprise.

7. Common Cloud Mistakes

Lifting and shifting without redesigning. Moving an on-premises architecture to cloud as-is wastes the cloud’s benefits.
Over-provisioning for peak load. Cloud auto-scaling handles peaks; constant over-provisioning is expensive.
Ignoring data transfer costs. Unplanned large data transfers can cause bill shock.
No backup or disaster recovery plan. Cloud is not a backup. You still need redundancy.
Using default security settings. Publicly accessible databases and unencrypted storage are common breaches.
Assuming the cloud provider secures your application. The provider secures the infrastructure; you secure your application.

8. Practical Cloud Checklist

What You Should Be Able to Do Now

Distinguish IaaS, PaaS and SaaS and choose appropriate service models;
Design for availability and disaster recovery across regions;
Understand shared responsibility for security and compliance;
Identify cost drivers and implement optimization strategies;