Cloud computing is the on-demand delivery of computing resources (servers, storage, databases, networking, software) over the Internet, with a pay-per-use model. Instead of buying, installing, and maintaining your own hardware in a physical data center, a company rents those resources from a provider (AWS, Microsoft Azure, Google Cloud, etc.) and consumes them as a service. This matters because it radically changes the cost model (from CAPEX investment to OPEX operating expense), allows you to scale in minutes instead of months, and shifts part of the operational responsibility to the provider. Understanding the service models, the deployment models, and above all the division of responsibilities is the foundation of any architectural decision in the cloud.

1. What problem the cloud solves and its essential characteristics.
2. Service models: IaaS, PaaS, and SaaS.
3. Deployment models: public, private, hybrid, and multicloud.
4. The shared responsibility model.
5. Cloud geography: regions, availability zones, and edge.
6. Common mistakes and tips.
7. Exercises and solutions.

Before the cloud, deploying an application meant buying servers, waiting weeks for delivery, installing them in a rack, configuring networking and cooling, and maintaining them for years even when demand fluctuated. The cloud solves this with five essential characteristics (defined by NIST, the U.S. standards institute):

• On-demand self-service: users provision resources themselves, without human intervention from the provider.
• Broad network access: resources are available over the network through standard mechanisms.
• Resource pooling: the provider serves multiple customers with shared infrastructure (multi-tenant).
• Rapid elasticity: capacity scales up or down automatically according to demand.
• Measured service: consumption is measured and billed transparently (pay-per-use).

The three classic models differ by how much the provider manages and how much you manage. A useful analogy is pizza: making it at home (on-premises), buying the frozen dough (IaaS), ordering delivery (PaaS), or dining at a restaurant (SaaS).

• IaaS (Infrastructure as a Service): you rent the basic building blocks (CPU, RAM, disk, network), usually as virtual machines. You install the operating system, the runtime, and the application. Maximum flexibility, maximum responsibility.
• PaaS (Platform as a Service): you upload your code and the provider takes care of the operating system, patching, scaling, and load balancing. Ideal for accelerating development without managing servers.
• SaaS (Software as a Service): you consume a complete application by subscription. You manage none of the infrastructure; you only use and configure it.

There are more recent models such as FaaS (Functions as a Service, the basis of serverless) and CaaS (Containers as a Service), which we will cover in later lessons.

The service model answers "what level of abstraction do I consume"; the deployment model answers "where and for whom does that cloud live".

• Public cloud: shared provider resources. It is the most common model due to its elasticity and cost.
• Private cloud: dedicated infrastructure (in your own data center or hosted), common in highly regulated sectors such as banking or insurance when there are strict data sovereignty requirements.
• Hybrid cloud: combines both, for example keeping sensitive data private and overflowing load peaks to the public cloud (cloud bursting).
• Multicloud: several public providers are used at the same time, to avoid dependence on a single one or to take advantage of the best of each.

This is the most important and most misunderstood concept in cloud security. The idea: the provider is responsible for the security of the cloud (the hardware, the physical network, the virtualization) and the customer is responsible for the security in the cloud (their data, their configuration, their access). The boundary moves according to the service model.

Explanation of the diagram: as we move from IaaS to SaaS, the provider's box grows and the customer's box shrinks. But there is one constant: responsibility over data and access control is almost never fully delegated. In IaaS you patch the operating system; in PaaS the provider does; in SaaS you only manage who has access and what data you enter.

A classic mistake is to assume that "it's in the cloud, therefore it's secure." If you misconfigure a storage bucket and leave it public, the data leak is your responsibility, not the provider's. In regulated sectors (for example, insurers subject to regulations such as GDPR/LOPDGDD or DORA), understanding this boundary is critical for compliance; any specific design must be validated with the relevant compliance team.

Providers organize their physical infrastructure into a geographical hierarchy:

• Region: a broad geographical area (e.g., eu-west-1 in Ireland, eu-south-2 in Spain). You choose a region based on latency (proximity to users), data sovereignty (keeping data within the EU), and cost (prices vary by region).
• Availability Zone (AZ): within a region there are several zones, which are physically separate data centers connected by a low-latency network. They provide fault tolerance: if one AZ goes down (fire, power outage), the others keep running.
• Edge / points of presence (PoP): locations close to the end user to cache content (CDN) and reduce latency.

Explanation of the commands:

• aws ec2 describe-regions: asks the provider for the region catalog. The --query parameter filters the JSON response to show only the name, and --output table presents it in a readable table.
• aws ec2 describe-availability-zones --region eu-west-1: lists the zones within the Ireland region. You will see something like eu-west-1a, eu-west-1b, eu-west-1c. Distributing your servers across several AZs is the basic practice of high availability.

The golden rule of resilience: deploy across at least two availability zones to survive the loss of a data center, and consider multi-region only if you need disaster recovery on a geographical scale (it is more expensive and complex).

• Confusing service model with deployment model. They are orthogonal axes: you can have IaaS in a private cloud or SaaS in a public cloud. They are not the same thing.
• Believing that "the provider manages everything". The shared responsibility model always leaves data and access on your side. Configure encryption and least-privilege permissions.
• Ignoring the region out of carelessness. Deploying European customers' data in the U.S. may violate data protection regulations. Choose a region mindful of data sovereignty.
• Not using multiple availability zones. A deployment in a single AZ is not high availability: it is a single point of failure with a monthly bill.
• Underestimating lock-in. Using proprietary services accelerates things at first but ties you to a provider. Weigh the cost of migrating before committing.
• Tip: start with PaaS or managed services when you can; drop down to IaaS only when you need control the platform does not give you.

1. A startup wants to launch a web API quickly, without an operations team, and prefers not to manage servers or patches. Which service model would you recommend and why?
2. Your company stores sensitive data of European customers. Explain two design decisions related to regions and shared responsibility that you must make.
3. Classify these services as IaaS, PaaS, or SaaS: (a) an empty Linux virtual machine, (b) Gmail, (c) a platform where you upload your code and it deploys itself.

1. PaaS. Without an operations team and wanting speed, the ideal is to upload the code to a managed platform (like App Service, App Engine, or Heroku) that takes care of the operating system, patching, and scaling. IaaS would require administering servers; SaaS does not apply because they are developing their own software.
2. (a) Choose a region within the EU (e.g., Spain or Ireland) to respect sovereignty and data protection regulations, preventing the data from residing outside the permitted territory. (b) Take on responsibility for encryption and access controls, since the shared responsibility model always leaves data protection on the customer's side; the provider only guarantees the security of the infrastructure. Any specific decision must be reviewed by the compliance team.
3. (a) IaaS (you are given bare infrastructure), (b) SaaS (ready-to-use application), (c) PaaS (platform to deploy your code).

We have seen what the cloud is, its three service models (IaaS, PaaS, SaaS) and how they differ by the division of management, the deployment models (public, private, hybrid, multicloud), the critical shared responsibility model, and the geography of regions and availability zones. These fundamentals are the foundation on which everything else is built. In the next lesson we will drop one level of abstraction to package and run applications in a portable, reproducible way with containers and orchestration using Docker and Kubernetes.