Cloud Computing Fundamentals

Cloud computing gives you computing resources as network-accessible services. You request capacity when you need it, release it when you do not, and measure what you use.

That changes the delivery model for IT. A team can provision compute, storage, networking, platforms, or complete applications without buying and installing every underlying system first. The provider operates some layers. You still own the outcomes and the responsibilities assigned to you.

Cloud is not a synonym for someone else's server. The useful distinction is the operating model. NIST defines five essential characteristics that separate cloud services from ordinary hosted infrastructure.

The five characteristics

Use these characteristics as a test for a cloud service:

On-demand self-service: You provision capabilities without waiting for manual action from the provider.
Broad network access: You reach capabilities over a network through standard mechanisms.
Resource pooling: The provider pools resources for multiple consumers and assigns them according to demand.
Rapid elasticity: Capacity can expand or contract quickly. To the consumer, available capacity can appear effectively unlimited.
Measured service: The system meters usage so the provider and consumer can monitor and control it.

Virtualization can help a provider pool resources, but virtualization alone is not cloud computing. A fixed virtual machine that requires a ticket and has no usage measurement may be hosted infrastructure without the full cloud operating model.

Choose the service boundary

A service model describes the capability you receive and the portion of the technology stack you control.

Infrastructure as a service

Infrastructure as a service, or IaaS, supplies fundamental compute, storage, and networking. You can deploy operating systems and applications. The provider controls the underlying cloud infrastructure.

Choose IaaS when you need control over the operating system or software stack. That control brings work. You usually configure the guest operating system, application, data, access, and parts of the network.

Platform as a service

Platform as a service, or PaaS, supplies a managed platform for deploying your applications. You control the applications and their configuration. The provider operates more of the runtime, operating system, and infrastructure.

Choose PaaS when the platform fits your application and you want less infrastructure work. Check service limits, supported runtimes, scaling behavior, and portability before you commit.

Software as a service

Software as a service, or SaaS, supplies a provider-run application. You use and configure the application instead of deploying its underlying platform.

Choose SaaS when an existing application meets the business need. You still manage users, access, data handling, integration, and configuration within the service.

These models form responsibility boundaries, not quality grades. PaaS is not automatically better than IaaS. SaaS is not automatically safer than PaaS. The best boundary matches your required control and your ability to operate what remains.

Choose the deployment model

A deployment model describes who can use the cloud infrastructure and how environments connect.

Public cloud: The infrastructure is provisioned for open use by the general public and exists on the provider's premises.
Private cloud: The infrastructure is provisioned for exclusive use by one organization. It can exist on or off the organization's premises.
Community cloud: The infrastructure is provisioned for a community of organizations with shared concerns.
Hybrid cloud: Two or more distinct cloud infrastructures remain separate but connect through technology that enables data or application portability.

Hybrid does not mean that every organization with both cloud and on-premises systems has an integrated hybrid cloud. The environments need a deliberate connection and operating design.

See the cloud as a relationship

NIST's reference architecture names five actors:

The cloud consumer uses cloud services.
The cloud provider makes cloud services available.
The cloud carrier supplies connectivity and transport.
The cloud broker manages service use, delivery, or relationships.
The cloud auditor performs an independent assessment.

You may interact with only a provider in a small deployment. The wider model matters when procurement, connectivity, assurance, or service integration crosses organizational boundaries.

Build from resources and services

Cloud providers expose compute, storage, networking, databases, identity systems, analytics, and other capabilities as services. You combine services into a workload, which is a set of resources that delivers a business outcome.

Providers commonly organize resources by geographic regions and smaller zones. A region gives a geographic placement. A zone provides a separate location within a region. Exact meanings and failure boundaries differ by provider and service.

Placement affects latency, service availability, legal requirements, cost, and failure exposure. Creating resources in one zone does not make a workload resilient to that zone's failure. Using more locations also does not create resilience by itself. Your workload must route traffic, replicate state, and recover correctly.

Understand elasticity and scaling

Scalability is a system's ability to meet a change in demand by changing capacity. Elasticity is the ability to add or remove capacity as demand changes.

You can scale vertically by changing the capacity of one resource. You can scale horizontally by changing the number of resources. The service must support the change, and the workload must be designed to use it.

Elastic capacity can reduce long provisioning delays. It does not guarantee performance. Quotas, service limits, architecture, data access, and downstream dependencies can still constrain a workload.

Treat cost as a system behavior

Measured service supports consumption-based pricing. You often replace some large advance purchases with charges tied to allocated resources, requests, storage, data transfer, or other usage dimensions.

Pay as you go does not mean pay only for useful work. An idle resource can still incur charges. Data retained without purpose can still incur charges. A design that moves data across billable boundaries can create recurring cost.

Estimate cost before deployment. Then assign ownership, apply budgets, inspect actual usage, and remove waste. Cost becomes an operational signal that changes with architecture and behavior.

Keep shared responsibility visible

The provider secures and operates parts of the cloud. You secure and operate the parts assigned to the consumer. This is the shared responsibility model.

The boundary moves with the service model. With IaaS, you manage more of the stack. With PaaS, the provider manages more platform layers. With SaaS, the provider manages the application stack. Across these models, you retain duties for your data, identities, access, and configuration.

Never infer your exact duties from the label alone. Read the service's responsibility documentation. A managed service removes specific tasks, not accountability for your use of the service.

Know what cloud does not solve

Cloud services do not automatically provide:

Secure identities and least-privilege access
Correct application behavior
Backup and tested recovery
Availability across the failure scope you care about
Regulatory compliance
Predictable cost
Easy portability between providers
Skilled operations

Public cloud also moves data, applications, or infrastructure outside your direct environment. NIST advises organizations to assess governance, compliance, trust, architecture, identity, data protection, availability, and incident response before outsourcing these systems.

Some workloads do not fit a public cloud service well. Hardware dependencies, disconnected operation, strict location rules, latency constraints, migration risk, or a stable existing platform may favor private, hybrid, edge, or on-premises placement.

A practical selection sequence

Start with the workload, not the product catalog.

Define the business outcome and users.
Classify the data and applicable constraints.
Set security, reliability, performance, and recovery requirements.
Choose a deployment model.
Choose the service model that gives you enough control.
Compare provider services, locations, limits, responsibility boundaries, and pricing dimensions.
Design identity, networking, data protection, observability, and recovery.
Estimate cost and define ownership.
Test the workload and its failure behavior.
Review usage, security, reliability, and cost after deployment.

Cloud competence starts when you can explain the tradeoff behind each choice. A service name will change. The questions about control, responsibility, location, failure, and cost remain useful.