The Public Cloud Deployment Model: Multitenancy, Pay-as-You-Go, and Noisy Neighbors

A public cloud is infrastructure owned and operated by a third-party provider and made available to the general public over the internet, with many unrelated customers — tenants — sharing the same pools of physical hardware. Its defining characteristic is multitenancy, and its defining cost model is pay-as-you-go: you rent capacity by the hour, second, or request instead of buying hardware up front. Those two traits explain almost everything else about the model, including its biggest operational quirk, the noisy-neighbor effect.

What makes a cloud “public”

Deployment models describe who owns the infrastructure and who is allowed to use it — not where it physically sits or which technology runs it. In the public model, the provider owns the data centers, the servers, the storage arrays, and the network gear. Any paying customer can provision resources from that shared pool through a self-service portal or an API (application programming interface), usually within minutes and with no human approval step.

Contrast that with a private cloud, where the infrastructure is dedicated to a single organization, and a community cloud, where a handful of organizations with shared requirements (a group of hospitals, for example) jointly consume dedicated infrastructure. A hybrid cloud connects two or more of these models so workloads and data can move between them.

Model	Who owns it	Who uses it	Typical cost profile
Public	Third-party provider	Anyone who signs up	Pay-as-you-go OpEx
Private	One organization (or hosted for it)	That organization only	Heavy upfront CapEx
Community	Shared by a consortium	Member organizations	Shared CapEx/OpEx
Hybrid	Mixed	One organization across both	Blend of the above

Multitenancy: how the sharing actually works

Multitenancy means multiple customers run workloads on the same physical hosts, separated by virtualization rather than by walls. The hypervisor slices a physical server into virtual machines (VMs) that belong to different tenants; software-defined networking keeps their traffic logically isolated; storage systems present each tenant a private slice of a shared array. You never know — and are not supposed to care — which other companies’ VMs are executing on the CPU next to yours.

This is the trait the exam most closely associates with the public model, because it drives both the economics and the risks. Sharing hardware across thousands of customers is what lets providers achieve enormous economies of scale and sell capacity cheaply. It is also why regulated industries scrutinize the model: your data sits on equipment you do not control, in facilities you will never enter, alongside strangers’ workloads. (Isolation failures are rare, but the perception of shared hardware is itself a compliance conversation — see data sovereignty and compliance in the cloud.)

The pay-as-you-go cost model

Building your own infrastructure is a capital expenditure (CapEx): a large upfront purchase of servers, storage, and networking that you then depreciate over several years, whether you use it fully or not. Consuming public cloud converts that into an operating expenditure (OpEx): a metered, recurring bill based on what you actually consumed — compute-hours, gigabytes stored, requests served.

The OpEx model has three practical consequences worth understanding rather than memorizing:

• No capacity gamble. On-premises, you must forecast peak demand years ahead and buy for it. In public cloud, you scale up for a traffic spike and scale back down, paying only for the spike’s duration.
• Costs track usage, not ownership. An idle VM still bills by the hour, which is why rightsizing and shutting down unused resources are core cloud-operations tasks.
• Low barrier to entry, unbounded ceiling. There is no purchase order for a rack of servers — but there is also no natural cap, so runaway workloads produce runaway bills. Budget alerts and quotas replace the discipline that a fixed hardware pool used to impose.

When an exam question asks which cost model characterizes adopting public cloud instead of building on-premises, the answer is this consumption-based, pay-as-you-go OpEx pattern.

Noisy neighbors: the price of sharing

The noisy-neighbor effect is performance degradation that occurs when one tenant’s workload consumes a disproportionate share of a shared physical resource — CPU cycles, memory bandwidth, disk I/O (input/output), or network throughput — leaving less for other tenants on the same host. Your VM did nothing wrong; the tenant sharing your hypervisor launched a batch job, and suddenly your storage latency doubled.

Providers mitigate this with resource throttling, quality-of-service limits, and scheduler placement logic, but they cannot eliminate it, because overcommitting hardware is fundamental to the economics. What you can do as a cloud operator:

• Buy guaranteed performance tiers — provisioned IOPS storage, instances with dedicated bandwidth — instead of burstable/shared tiers for latency-sensitive workloads.
• Use dedicated hosts or dedicated instances, which pin your VMs to hardware no other tenant shares. This trades away some of the cost advantage to buy single-tenant isolation inside a public cloud.
• Monitor for it: intermittent latency with no corresponding change in your own workload’s metrics is the classic noisy-neighbor signature.

How the CV0-004 exam tests this

• Trait identification: a question names several characteristics (dedicated hardware, multitenancy, single-organization ownership) and asks which one belongs to the public model. Multitenancy and on-demand self-service over the internet are the public-cloud fingerprints.
• Cost-model matching: a scenario contrasts building on-premises infrastructure with adopting a provider’s service and asks which cost model applies to the cloud side — expect pay-as-you-go/OpEx as the discriminator, with CapEx anchoring the on-premises side.
• Symptom naming: a scenario describes one tenant’s workload degrading performance for others on shared hardware and asks for the term. That is the noisy-neighbor effect, and wrong answers usually include resource contention terms from other contexts (oversubscription, throttling) that don’t specifically name the cross-tenant phenomenon.
• Mitigation selection: given a noisy-neighbor symptom, pick the fix — dedicated hosts or provisioned-performance tiers, not “restart the VM” or “add more of the same shared tier.”

Deployment models are one of the first objectives in the Cloud Architecture domain of the full CV0-004 study guide, and among the first things a CV0-004 practice exam will test you on.

Quick reference

• Public cloud = provider-owned infrastructure, open to any customer, consumed over the internet on demand.
• Its most closely associated characteristic is multitenancy — many customers sharing the same physical hardware behind virtualization-based isolation.
• Its cost model is pay-as-you-go OpEx: metered billing for actual consumption, versus the upfront CapEx of building your own.
• Elasticity works both directions: scale up for spikes, scale down after — you stop paying when you release resources.
• Noisy neighbor = performance degradation caused by another tenant monopolizing shared host resources.
• Mitigate noisy neighbors with dedicated hosts/instances or provisioned-performance storage and network tiers.
• Deployment models are defined by ownership and audience — public, private, community, hybrid — not by technology.