Cloud service and deployment models

Why this matters

This is the definitional half of objective 1.3, and it is worth learning precisely because the terms get used loosely everywhere else. "The cloud" is not one thing, and the difference between IaaS and PaaS is not academic — it decides who patches the operating system when a vulnerability lands.

Exam questions here are usually scenarios: an organisation with a particular constraint, and you pick the model that fits. The constraint is the clue.

The lesson

The three service models

The clean way to hold these is to ask where the line falls between what you manage and what the provider manages. Every service model is a different place to draw that line.

IaaS — Infrastructure as a Service. The provider gives you the raw building blocks: virtual machines, storage, networking. You bring the operating system and everything above it, and you are responsible for patching it, securing it, backing it up and configuring it.

Most control, most work. Choose it when you need specific OS versions, custom kernel settings, or you are lifting an existing server estate into the cloud without redesigning it.

PaaS — Platform as a Service. The provider runs the operating system, runtime and middleware; you supply the application code and its configuration. You do not patch the OS and you do not size the servers — you deploy an application and the platform runs it.

Less control, much less operational burden. Choose it when developers should be writing software rather than maintaining servers. The trade is that you are constrained to what the platform supports, and portability between providers is worse.

SaaS — Software as a Service. The provider runs the whole thing and you consume finished software over the network. Email, CRM, collaboration suites, this store's own analytics. You manage your data, your users and your settings, and nothing else.

Least control, least work. Choose it when the software is not your differentiator.

A reliable way to remember the ordering: IaaS gives you a server, PaaS gives you a place to put code, SaaS gives you a finished application.

Note that the shared responsibility model moves with the line. In IaaS, an unpatched OS is your problem. In PaaS, it is the provider's. In every model, your data and your user accounts remain your responsibility — that never transfers, and questions about a misconfigured share or a leaked credential land on the customer regardless of model.

The three deployment models

Where the infrastructure physically lives and who else uses it.

Public cloud. Infrastructure owned and operated by a provider, shared among many customers over the internet. No capital cost, effectively unlimited capacity, pay for what you use. The concerns are that you share physical hardware with strangers, your data sits under someone else's operational control, and its location may matter legally.

Private cloud. Cloud architecture — self-service, pooled resources, automation, metering — dedicated to a single organisation. It may sit in your own data centre or be hosted for you, but the hardware is not shared.

You get control and isolation, which is why regulated industries choose it, and you pay for it: you buy capacity in advance, and you carry the operational burden. A private cloud is not simply "servers we own" — the defining feature is the cloud operating model, not the ownership.

Hybrid cloud. Both, deliberately connected so workloads and data can move between them. The common patterns are keeping regulated data private while running public-facing services in the public cloud, and cloud bursting — running normally on private capacity and spilling into public capacity at peak.

Hybrid is the most flexible and the most complex. It needs consistent identity, consistent security policy, non-overlapping address space and a reliable link between the two environments, which is where the previous lesson's Direct Connect and site-to-site VPN come in.

CompTIA also recognises community cloud — shared by several organisations with common requirements, such as a group of hospitals or government agencies. It is less commonly examined but appears as a distractor.

Scalability and elasticity

These two are constantly conflated, and N10-009 lists them separately, which means it can ask you to distinguish them.

Scalability is the ability to handle growth — to add capacity as demand increases over time. It is about the system's ceiling. It comes in two shapes:

• Vertical scaling (scaling up): make the existing machine bigger — more CPU, more memory. Simple, but bounded by the largest machine available, and it usually means a restart.
• Horizontal scaling (scaling out): add more machines and distribute the load across them. Effectively unbounded and more resilient, but the application has to be built to run in several places at once.

Elasticity is the ability to add and remove capacity automatically in response to current demand, in both directions and in minutes.

The distinction: scalability is whether you can grow; elasticity is whether it happens by itself and shrinks back again. A system can be scalable and not elastic — you can add servers, but someone has to decide to and do it.

Elasticity is where the cost argument for public cloud actually lives. A retailer sized for Black Friday runs that capacity all year on-premises; in an elastic environment it exists for four days and is paid for for four days.

Multitenancy

Multitenancy means one instance of infrastructure or software serves many independent customers — tenants — whose data and configuration are logically isolated from each other while sharing the same underlying resources.

It is what makes public cloud economically possible. Sharing hardware across thousands of customers is why capacity is cheap and available instantly.

The trade-offs are examinable:

• Isolation depends on the provider's controls, not on physical separation. A flaw in the isolation is a flaw in the boundary between customers.
• The noisy neighbour problem: another tenant's workload can consume shared resources and degrade yours, which is why providers offer dedicated instances at a premium.
• Compliance regimes may require single tenancy, which is a common driver toward private cloud.

Single tenancy is the opposite — dedicated infrastructure per customer. More isolated, more expensive, less elastic.