Cloud Computing Fundamentals
The 5 Characteristics of Cloud Computing
A deep dive into the 5 NIST essential characteristics, on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service, and how to use them as a test for whether a service is truly cloud computing.
- Define each of the 5 NIST essential characteristics of cloud computing
- Give a concrete example of each characteristic in action
- Apply the 5 characteristics as a test to determine whether a service is truly cloud computing
- Explain how virtualization enables resource pooling and rapid elasticity specifically
The 5-question test
Two lessons ago, you learned the formal NIST definition of cloud computing. That definition names 5 essential characteristics, but only listed them by name. This lesson is where they earn their keep: each one is a specific, testable trait, and a service has to show all 5 before it genuinely counts as cloud computing rather than just "a server somewhere else."
Treat this lesson as a checklist. When someone calls a service "cloud," you can now ask, one by one, whether it actually has each trait.
1. On-demand self-service
You can provision computing resources, spinning up a server, requesting more storage, the moment you need them, without calling anyone or waiting for a person at the provider to act. You open a console, an API, or a command line, make the request, and it happens.
Contrast this with the hosting example from 2 lessons ago: emailing support and waiting a day for more RAM fails this test immediately. A real cloud service never puts a human approval step between your request and the resource showing up.
2. Broad network access
The service is reachable over standard networks, in practice the internet, from a mix of ordinary devices, laptops, phones, tablets, using standard tools like a web browser or a documented API, rather than requiring specialized hardware or a private connection only you have access to.
This is why you can manage a cloud account from your phone on a train and from a laptop at your desk with the same login, the same interface, and the same result. The service does not care what device asked.
3. Resource pooling
The provider serves many customers from the same underlying hardware using a multi-tenant model, and dynamically assigns resources to customers based on demand. Crucially, you usually do not know, and do not need to know, exactly which physical machine or which data center rack your workload is running on at any given moment.
This is the characteristic virtualization makes possible, covered in the previous lesson. A hypervisor slicing one physical server into many isolated virtual machines is exactly how a provider pools hardware across thousands of customers while keeping each customer's data and workload separated from the others.
4. Rapid elasticity
Capacity can scale outward, adding more resources, or inward, releasing resources, quickly, often automatically, to match real demand, and from the customer's perspective the pool of available resources looks close to unlimited.
Picture a retailer's website during a flash sale: traffic jumps 20 times its normal level for 3 hours, then falls back. A cloud setup can add servers to absorb that spike as it happens and remove them once the sale ends, so the retailer pays for that extra capacity only for the hours it actually ran. On-premises infrastructure, remember from the first lesson in this topic, cannot do this: it is stuck at whatever capacity you already bought.
5. Measured service
Cloud systems automatically meter resource usage, whether that is compute hours, gigabytes stored, or data transferred, and both the provider and the customer can see that usage transparently. This metering is what makes pay-as-you-go pricing possible: you are billed for what the system actually measured, not for a fixed allocation you may or may not have used.
You will cover the pricing models built on top of this metering, on-demand, reserved, and others, later in this domain's Cloud Economics topic.
Running the checklist
Put the 5 together and you get a fast test for any service someone calls "cloud":
| Characteristic | The question to ask |
|---|---|
| On-demand self-service | Can you get it yourself, right now, with no human approval? |
| Broad network access | Can you reach it from any ordinary device over the internet? |
| Resource pooling | Are you sharing underlying hardware with other customers, safely and invisibly? |
| Rapid elasticity | Can capacity scale up and back down quickly to match real demand? |
| Measured service | Are you billed based on metered, actual usage? |
A service that is missing even one of these is not fully cloud computing under the NIST definition, no matter how it is marketed. The hosting example from earlier in this topic fails characteristic 1. A privately virtualized data center with a slow ticketing process for new VMs fails characteristics 1 and often 4. A service that only shows 3 of the 5 might still be useful, but calling it "cloud" is a marketing choice, not a technical one.
Carrying this forward
You can now recognize real cloud computing by testing a service against these 5 traits instead of trusting a label. The next topic in this domain moves from what the cloud is to how it is deployed: public, private, community, and hybrid, the 4 models that describe who shares the pool with you.