CCSP Cloud Computing Concepts: Definitions, Roles, Characteristics and Building Blocks

Cloud computing is a model for delivering IT, not a place or a product. NIST SP 800-145 defines it as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. That last phrase is the test that separates cloud from ordinary outsourcing: if a human at the provider has to build or approve each request, the arrangement is not cloud.

The same publication organises the model as 5-3-4: five essential characteristics, three service models and four deployment models. When a policy or contract needs to cite where those come from, NIST SP 800-145 is the source. ISO/IEC 17788 is the international companion vocabulary: it lists six key characteristics (adding multi-tenancy) and defines the customer, provider and partner roles the outline uses. ISO/IEC 17789 builds the reference architecture on top of that vocabulary and names the partner sub-roles, including the broker. The regulator in the outline's role list is not an ISO/IEC 17788 or 17789 role; it comes from the outline itself.

Service models (SaaS, PaaS, IaaS) and deployment models belong to the cloud reference architecture topic. Here the point is only that they hang off this definition. Note the count: NIST SP 800-145 defines four deployment models (public, private, hybrid, community); the CCSP outline lists a fifth, multi-cloud, which is defined in ISO/IEC 22123-1 rather than in NIST's publication.

The essential characteristics are the properties a service must have to count as cloud. NIST SP 800-145 names five; ISO/IEC 17788 names six by adding multi-tenancy and phrasing elasticity as rapid elasticity and scalability. The CCSP outline uses the ISO list.

On-demand self-service

The defining feature is the absence of a provider-side human step. A data scientist who starts a GPU cluster through the provider's API for a weekend training run, and deletes it when the run finishes, never raises a ticket with the provider: that is on-demand self-service. The test is always who is involved. If the provider has to act on each request, the characteristic is missing; controls the customer places on its own staff are the customer's governance and leave the characteristic intact.

The governance consequence is that self-service removes the old change-board choke point. The general principle is about when a control acts. Policy evaluated automatically at the moment of provisioning (often written as code) keeps both safety and speed, because a non-compliant configuration never comes into existence. Controls that act afterwards leave a window in which it does exist, and controls that put a person back in front of every request trade away the characteristic the organisation adopted cloud for.

Broad network access

Broad network access means the service is reached over standard networks and protocols from many kinds of client: field engineers opening the same ticketing service from a rugged handheld, a hotel business-centre browser or a desktop client. It is about reach, not about bandwidth or about the provider's own network.

The risk that follows most directly is exposure: because the application and its admin console can be reached from any internet-connected device, stolen credentials can be used from anywhere, and unmanaged endpoints join the picture. Because wide reach is the purpose of the characteristic, identity becomes the main perimeter: who is signing in, and how strongly that is proven, matters more than which network the request comes from.

Resource pooling is how a provider serves many customers from one set of physical resources, assigning and reassigning capacity as demand changes. NIST SP 800-145 adds a sense of location independence: the customer generally has no control over, or knowledge of, the exact location of the resources, but may be able to specify location at a higher level of abstraction such as a country, state or data centre. In practice the customer picks a geography from the provider's list, never a particular machine.

Location independence has a direct compliance consequence. Data residency is therefore met at the level of abstraction the model exposes: the geographic location the provider lets the customer choose, backed by contractual commitments that cover every copy of the data, including backups and replicas. Pooling is designed so that specific hardware is not the unit of control. ISO/IEC 27018, the code of practice for protecting PII in public clouds, expects the provider to specify and document the countries where PII may be stored, which is part of how a customer confirms where its data lives.

Multi-tenancy

ISO/IEC 17788 defines multi-tenancy as the allocation of physical or virtual resources such that multiple tenants and their computations and data are isolated from and inaccessible to one another. A tenant is one or more cloud service users sharing access to a set of resources. Pooling is about sharing; multi-tenancy is about the isolation that makes sharing safe.

• Isolation can fail at the application layer. A hosted learning platform that serves many school districts from one shared application and database relies on its own code to keep each district's records apart. A bug that lets a teacher in one district open another district's student files is a multi-tenancy failure, even though the servers and network are sound.
• Tenants need not be separate companies. When a government ministry runs a private cloud for its agencies, each agency is a tenant. A single owning organisation is not a reason to relax isolation: the definition requires each tenant's computations and data to be inaccessible to the others, and that has to be enforced in the resources and data themselves.

Hypervisor and container isolation mechanisms themselves are covered under virtualization security in the security concepts topic.

Rapid elasticity is the ability to provision and release capacity quickly, in some cases automatically, so that resources track demand outward and inward. Scalability is the ability to take on more load by adding resources. The two are often paired (ISO/IEC 17788 names them together) but they are not the same: a platform that can grow to meet a surge but stays at its peak size afterwards is scalable; it becomes elastic when it also shrinks back as the surge passes. Capacity that follows demand in both directions is the elastic part.

Measured service means resource use is metered, monitored, controlled and reported, with transparency for both the provider and the consumer. It is what makes these possible:

• Chargeback and showback: a hospital's radiology and pharmacy departments each see, and pay for, what they consumed, from the same metered data the provider bills on.
• Anomaly detection: unexplained consumption, such as a burst of outbound data transfer from an account that normally sends little, is often the first visible sign of a compromise. Metered usage is a security signal, not only a billing record.
• Cost control: budgets and alerts depend on the meter.

When the two combine: economic denial of sustainability

Elasticity and measured service together change what an attack does. A flood of malicious traffic against an elastic site may never cause an outage, because the platform keeps adding capacity, but every added unit is metered and billed. The result is a financial loss rather than downtime, sometimes called economic denial of sustainability (EDoS); neither characteristic alone explains it.

The controls that matter fall into two kinds. A bound on cost is a limit on how far automatic scaling may go, usually paired with budget and usage alerts so people can act early; elasticity still works below the limit, and above it the service degrades instead of spending without end. Everything else reduces or reports cost rather than bounding it: controls that lower the volume of attack traffic leave the bill open-ended for whatever still arrives (and a genuine surge looks the same), and metered reports describe spending after it has happened, which is detection, not a limit.

Roles in cloud computing are defined by the activity a party performs in a relationship, not by what kind of organisation it is. ISO/IEC 17788 defines three main roles and one related term:

Because roles follow activity, one organisation can hold several at once. A shared-services agency that runs a private cloud for other government departments (who self-provision and are billed by usage) is a cloud service provider to those departments, and the same agency is a cloud service customer of the hosted video-conferencing service it subscribes to. The customer is the contracting organisation; the individuals who sign in are its cloud service users.

Layered providers and assurance

Holding two roles has a practical consequence for assurance. When a software company builds its SaaS product on another company's IaaS, it is the provider to its own subscribers and a customer of the infrastructure provider. Its subscribers have a contract with it, usually not with the infrastructure provider, so their due-diligence questions, including questions about layers it does not run such as physical data-centre security, are its to answer. Assurance follows the contract chain: each provider answers its own customers, drawing on its suppliers' independent attestations for the layers it does not operate and on its own evidence for the controls it does.

Partner sub-roles (ISO/IEC 17789)

• Cloud auditor: conducts an independent examination of cloud services, the provider's controls or the customer's use, and reports on it.
• Cloud service developer: designs, develops, tests and maintains the implementation of a cloud service.
• Cloud service broker: negotiates relationships between customers and providers (see the next section).

Independence limits which roles one firm can combine. The auditor's value is that the examination is independent. A firm that designed or built a control and is then engaged to assess that same control is reviewing its own work, the self-review threat that auditing standards treat as impairing independence. Both developer and auditor are partner sub-roles, and one firm can hold both, but not for the same controls: independence is judged control by control.

Most partner work is not brokering. A firm hired to penetration-test a customer's tenancy, or a software house that builds a custom integration for a provider, supports the customer or the provider and is a partner. What makes a partner a broker is managing the relationship between customers and provider services on the customer's behalf.

A note for candidates who also read NIST: NIST SP 500-292 uses a different taxonomy, with five separate actors (cloud consumer, provider, carrier, auditor and broker). There the auditor and broker are peers of the provider rather than partner sub-roles. The ideas are the same; only the classification differs.

A cloud service broker sits between customers and providers and manages the use, performance and delivery of cloud services. NIST SP 500-292 (the NIST cloud reference architecture) describes three broker services, and the near-twin pair is aggregation versus arbitrage.

Worked distinctions: a broker that wraps a customer's existing file-sharing service with data-loss prevention and usage analytics is providing intermediation, because there is still one underlying service. A broker that packages one provider's managed database with another provider's content delivery into a single, stable offering is providing aggregation. If the broker instead picks a provider afresh for each request, from a set that can change, it is providing arbitrage.

Whichever service a broker provides, it simplifies buying and operating. It does not change who owns the data or who answers to the regulator, which is the subject of the next section.

The cloud service customer, as the data owner, keeps ultimate accountability for its data. Providers, brokers and partners take on responsibilities through contracts, and they can be liable to the customer for failing them, but accountability to data subjects and regulators does not move with the work.

• When an employer's payroll processor leaks staff bank details from its hosted platform, the employer is still accountable to its employees and regulators for that data; the processor's failure is a matter for the contract and, where the law reaches the processor, for the regulator as well.
• Putting a broker or any other partner between the customer and its providers changes how services are bought and managed, not who owns the data.
• Risk transfer moves money, not accountability. An indemnity clause that makes the provider pay for breaches it causes, and cyber insurance bought by the customer, are both forms of risk transfer: they shift the financial consequences of a breach to another party. Neither moves the customer's accountability to its data subjects and regulators. The customer still has to notify, respond and answer for the data; the clause and the policy decide who ends up paying.
• An independent report such as a SOC 2 Type II is an attestation that a provider's controls operated effectively over a period. It informs the customer's due diligence; it neither transfers accountability nor binds a regulator.

The regulator

A regulator is the party that makes and enforces binding requirements on customers and providers, such as a data protection authority, a financial services supervisor or a health regulator, and it can penalise either for breaking them. That separates it from the other roles: an auditor examines and attests but cannot impose penalties, and a contract is negotiated between the parties and binds only them.

Two consequences follow:

1. Contract terms do not override the law. A contract binds only the parties who sign it; a regulation binds them whatever they have agreed. Where the two conflict, the regulation wins, and accepted terms are no defence.
2. The regulator acts against the accountable party. The law, not the contract, sets whom a regulator can pursue: typically the customer as the accountable party and, where the law extends to processors or service providers, the provider too. Likewise, attestation is not compliance: an audit report is evidence about controls, not a ruling on whether the law has been met.

How security duties split between customer and provider in each service category is covered in the secure design principles topic; contracts, SLAs and legal frameworks are developed in Domain 6.

Virtualization is the building block that makes compute poolable. A hypervisor abstracts the physical server into virtual machines, so workloads from different customers can share the same hardware and be packed onto, or rebalanced across, hosts as demand shifts. Without it there is nothing to pool, assign or release quickly.

Because a VM is decoupled from the hardware, it can move. Live migration transfers a running virtual machine to another host without stopping it, which lets a provider rebalance load or empty a host before maintenance without interrupting the workloads on it. Snapshots, templates and cloning come from the same abstraction. Hypervisor types and their security belong to the security concepts topic.

Virtual machines, containers and dedicated servers

The isolation boundary differs by how compute is packaged, and it decides what a shared pool can promise its tenants:

So when tenants must not share a kernel but the provider still wants a pooled, elastic service, the hypervisor is the building block that delivers both. (Some container runtimes wrap each container in a lightweight VM; that isolation comes from the hypervisor layer, not from the container itself.)

Networking: the software-defined network

Software-defined networking (SDN) separates the control plane, which decides where traffic should go, from the data plane, which forwards it. A central controller holds the policy and programs the forwarding devices through APIs, so tenants can create isolated virtual networks, subnets and firewall rules in seconds without an engineer touching physical switches. Ordinary traffic does not pass through the controller; the forwarding devices carry it. (In reactive designs such as some OpenFlow deployments, the first packet of an unrecognised flow can be sent up to the controller so it can install a rule.) The programmability comes from the controller's APIs and central policy, not from configuring devices one at a time.

Why traditional VLANs do not scale to cloud tenancy. An IEEE 802.1Q VLAN is identified by a 12-bit field, which allows 4,096 values of which 4,094 are usable, too few for a provider with thousands of tenants each wanting several networks. VLANs are also a property of the physical switching fabric, so every tenant network stays bound to that fabric. SDN-managed overlay networks solve both problems: each tenant's virtual network is carried encapsulated over the shared physical network (VXLAN, for example, uses a 24-bit network identifier, about 16 million networks), and each virtual network has its own address space. Two tenants can therefore both use the same private range, such as 10.0.0.0/16, without conflict.

The security payoff is microsegmentation: filtering rules defined centrally through the SDN and attached to workloads rather than to physical ports, so a rule such as "only the payment service may reach the card vault" stays attached to those workloads wherever they run. The principle: a control bound to physical topology, or maintained machine by machine, cannot follow a workload that the platform moves.

Cloud storage is a building block because it is reached over the network and decoupled from the compute that uses it. A data volume is a resource in its own right, with its own identity, and can be detached from one virtual machine and attached to another. Storage virtualization puts an abstraction between the volume a consumer sees and the disks that hold it, which is why the provider can move data underneath without the consumer noticing.

The same decoupling has a lifecycle consequence that catches teams out. Volumes, snapshots and backups are separate resources with their own lifecycles. Deleting compute does not necessarily delete the data that compute used: storage keeps its contents, and keeps accruing charges, until it is deleted itself. Data disposal plans therefore have to enumerate and remove the storage resources directly. The storage types (volume, object, file and so on) and sanitization methods are covered in their own topics.

Databases

Providers offer databases as managed services in two broad families:

Many systems use both: a ride-hailing app might keep fast-changing location pings in a key-value store that scales out across nodes, and fares and driver payouts in a relational ledger that needs transactions.

A managed database moves engine patching, backups, failover and the underlying hosts to the provider. It does not move the customer's data responsibilities: the customer still designs the schema, decides who can query what, and applies least privilege to the identities that read and change the data. The provider runs the engine; the customer governs access to the data in it.

Orchestration is the coordination of many automated tasks, across compute, storage and network, into one ordered end-to-end workflow. Automation is a script or tool doing one task without a person: resize a disk, rotate a log, apply a patch.

The difference matters because orchestration is what turns building blocks into the essential characteristics. Automation alone does not make a service self-service: if a person still has to trigger and sequence the steps, the provider is involved in every request. Orchestration removes that person by sequencing tasks, passing outputs from one to the next and handling failures, so a request runs end to end with no provider interaction. The same machinery releases capacity when demand falls, which is how elasticity is delivered.

Two consequences are easy to miss:

• The test is whether a person is in the loop. Scripting individual steps makes them faster and more consistent, but a workflow that waits for someone to start or sequence it is still automation; it becomes orchestration when the steps are chained and triggered without that person.
• Elastic capacity is only useful when it is complete. A new instance that boots but has no data volume and is not behind the load balancer serves nothing. Scaling out is one orchestrated workflow that launches compute, attaches storage, applies network rules and registers the instance to receive traffic, and scaling in reverses it.

Security orchestration, automation and response (SOAR) applies the same idea to incident handling and is covered in the AI/ML topic of this domain.