What Is Cloud Computing? A Defender's View

A startup with no servers ships a product to a million users in a weekend. A data scientist spins up forty GPUs for an afternoon, runs a model, and tears them down before dinner. A company closes its last data center and runs entirely on infrastructure it has never seen. None of that was possible to do cheaply fifteen years ago, and all of it is routine now. That is what cloud computing changed: capacity stopped being a thing you bought and racked, and became a thing you call an API for and pay for by the hour.

Cloud computing is the on-demand delivery of computing resources, servers, storage, databases, networking, and software, over the internet, billed by use instead of owned outright. NIST puts it precisely: "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources" that can be provisioned and released with minimal management effort. This guide covers what cloud computing actually is, the characteristics that define it, the service and deployment models, why organizations moved to it, and the part that matters most to a blue team: how the move reshapes the security problem you have to defend. It is written for the people who answer for it after the fact, SOC analysts triaging cloud logs, threat hunters in someone else's data center, and DFIR responders reconstructing what a stolen key touched.

What is cloud computing?

Cloud computing means renting computing capacity from a provider instead of owning it. You do not buy a server, rack it, and depreciate it over five years. You request a virtual machine, a database, or a storage bucket through an API or a web console, the provider gives it to you in seconds, and you pay for exactly the time and capacity you use. When you are done, you release it and the bill stops.

The provider, AWS, Microsoft Azure, Google Cloud, and others, owns the physical data centers, the hardware, and the software that turns one giant pool of machines into millions of separate, isolated tenants. You consume slices of that pool. The economic shift is from capital expense to operating expense: no upfront hardware, no over-provisioning for a peak you hit twice a year, no idle servers between projects.

For a defender, the consequence of that model is the whole story. In a traditional data center you defended a perimeter: a building, a network edge, a firewall between inside and outside. In the cloud there is no building you control and no single edge. Every resource is reachable through an authenticated API call, and what gates that call is an access policy, not a wall. The thing you defend is no longer a network boundary. It is a set of configurations and the identities allowed to change them.

The five characteristics that define it

NIST SP 800-145 names five essential characteristics. A service is cloud computing only if it has all five, and each one carries a security implication a defender should read directly.

On-demand self-service. You provision capacity yourself, through an API or console, without a human in the loop on the provider's side. The security read: anyone with valid credentials can create or destroy infrastructure in seconds. Identity, not a change-control ticket, is what stands between an attacker and a new admin role.

Broad network access. Resources are available over the network through standard mechanisms. The security read: everything is reachable from somewhere, so a misconfigured access policy exposes a resource to whoever can reach the endpoint.

Resource pooling. The provider's hardware is shared across many tenants, with physical resources assigned and reassigned dynamically. The security read: you share physical machines with strangers, so the provider's tenant isolation and your own configuration are what keep your data yours.

Rapid elasticity. Capacity scales up and down quickly, sometimes automatically, to match demand. The security read: infrastructure is ephemeral. An instance that ran for ten minutes and was terminated still happened, but if you were not logging it, it left no trace to investigate.

Measured service. Usage is metered, controlled, and reported, which is how billing works. The security read: the metering and audit layer is also your evidence. Where there is a bill, there is a log of who did what, if you turned it on.

The service models: IaaS, PaaS, SaaS

Cloud computing is sold in three layers, and which layer you buy decides how much of the stack you operate and secure. NIST SP 800-145 defines all three.

Infrastructure as a Service (IaaS) gives you the raw building blocks: virtual machines, block and object storage, and networking, with you in control of the operating system and everything above it. The provider runs the hardware and the virtualization layer; you patch the guest OS, configure the firewall rules, install the software, and own the data. AWS EC2, Azure Virtual Machines, and Google Compute Engine are IaaS. It is the most flexible model and leaves the most for you to secure.

Platform as a Service (PaaS) hands you a managed runtime: you deploy code or a database, and the provider runs the OS, the patching, and the scaling underneath. Managed databases, app-hosting platforms, and serverless functions live here. PaaS shrinks your operational surface, but it does not shrink your responsibility for the code you ship or the access policies you set on the service.

Software as a Service (SaaS) is a finished application delivered over the network: email, a CRM, a collaboration suite. The provider runs everything down to the application. Your job is the data you put in it, who you grant access to, and how you configure the tenant. SaaS leaves you the least to operate, and still leaves you plenty to get wrong, because misconfigured sharing and over-broad access are the failures that bite at this layer.

The pattern is the same across all three: as you move from IaaS to SaaS, the provider takes over more of the stack and your responsibility narrows, but it never disappears. The thing that is always yours, at every layer, is your data and the identities that can reach it. That split is the shared responsibility model, and getting it wrong is the most common way cloud security fails: organizations assume the provider covers more than it does, and leave the customer side, data, identity, and configuration, unguarded.

The deployment models: public, private, hybrid, multi-cloud

Where the cloud runs is a separate axis from how it is sold. NIST defines four deployment models; a fifth term, multi-cloud, has become standard practice on top of them.

Public cloud is the shared model: the provider owns the infrastructure and many tenants run on it. AWS, Azure, and Google Cloud are public clouds. You get elasticity and no hardware to manage, at the cost of sharing physical resources and trusting the provider's tenant isolation.

Private cloud is provisioned for a single organization, self-hosted or run by a third party on dedicated hardware. It trades the public cloud's scale for tighter control, common where regulation or sensitivity demands that data never sit on shared hardware.

Hybrid cloud connects a private environment or on-premises data center to a public cloud so workloads can move between them. It is the reality for most large organizations and a defender's headache, because identity, logging, and network controls have to stay consistent across two environments with different tooling.

Multi-cloud means using more than one public cloud provider at once. It avoids lock-in, but it multiplies the attack surface: every provider has its own identity model, its own logging format, and its own set of default settings to get wrong. A hunter covering multi-cloud has to be fluent in each provider's audit log, not just one.

Why organizations moved to the cloud

The shift was not fashion. The cloud changed the economics and the speed of running software, and four pressures did most of the moving.

Cost model. Capital expense became operating expense. Instead of buying servers for the peak load and letting them sit idle, you rent what you use and scale it down when demand drops. For a workload that spikes and quiets, that is dramatically cheaper.

Speed and elasticity. Provisioning that used to take weeks of procurement takes seconds of an API call. Capacity scales with demand automatically, so a service that gets a traffic spike absorbs it instead of falling over, and releases the capacity afterward.

Reach and managed services. Providers run data centers in regions worldwide, so an application can sit close to its users. And the provider operates higher-level services, managed databases, queues, machine-learning platforms, containerization and orchestration, so a small team can run infrastructure that once needed a department.

Focus. Offloading hardware, data center operations, and base-layer patching to the provider lets an organization spend its people on its product instead of its plumbing. That is the real draw, and it is also the trap, because "the provider handles it" quietly stops being true above the hardware line.

What the cloud is built from

Under the models, cloud computing assembles a handful of resource types. The pool the provider rents you, the cloud infrastructure, is mostly these components, and knowing them is what lets you read an architecture diagram or an audit log and understand what you are looking at.

Compute is where code runs: virtual machines you control, containers that package an application with its dependencies and run many to a host, and serverless functions that run on demand with no server for you to manage.

Storage comes in two main shapes. Object storage holds files as objects in buckets and is the single most common source of public-data exposure, because a bucket policy is easy to get wrong and the data sits one setting away from the open internet. Block storage is the virtual disk attached to a machine, and a shared snapshot is a quieter but equally real leak path.

Networking is the virtual private network and everything in it: subnets, route tables, security groups that act as virtual firewalls, gateways, and load balancers. A security group rule open to 0.0.0.0/0 is the cloud equivalent of unplugging the firewall.

Identity and access management is the policy engine that decides which identity can call which API on which resource. It is the real perimeter of a cloud environment: every action is an authenticated, authorized API call, and a stolen key or an over-permissive role is the most direct path to everything that identity can reach.

How the cloud changes the security problem

Moving to the cloud does not make the security problem smaller. It changes its shape, in three ways that matter to a defender.

Identity is the perimeter. There is no network edge to defend in the old sense. Every resource is an API call away, and what gates that call is an access policy, not a firewall at a building's edge. A compromised key with broad permissions is a more direct path to data than any network exploit, which is why identity telemetry, who assumed which role and which key called which API from where, sits at the center of cloud detection.

The attack surface is configuration. Because every resource is provisioned and governed through APIs and policy, the surface is the sum of your settings. A public bucket, an open security group, an over-broad role, a disabled log: each is a one-line mistake that exposes real data, and none of them trip a traditional intrusion alarm because nothing was broken into. Misconfiguration is the dominant cloud risk, and it is self-inflicted by definition. The 2019 Capital One breach, which exposed data on more than 100 million people, followed exactly this logic: a misconfigured web application firewall let an attacker reach the credentials of an over-privileged role, which then read storage buckets. The provider was not compromised. The configuration was.

Evidence is ephemeral. Self-service and elasticity mean infrastructure appears and disappears in seconds, so the disk you would have imaged may no longer exist. Evidence lives in logs, not on hardware. The control-plane audit log, AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs, is the record of every API call and the first place an investigation looks. If it was off, the incident is invisible.

The defensive program follows from those three facts. Scope every identity to least privilege so a stolen key reaches as little as possible. Scan configuration continuously, because the dominant risk is a setting, not an exploit. Turn the control-plane audit log on everywhere and ship it somewhere it cannot be tampered with, because it is the evidence and the detection source at once. Secure the data and the identities first; the rest is detail.

Frequently Asked Questions

What is cloud computing in simple terms?

Cloud computing is renting computing resources, servers, storage, databases, and software, from a provider over the internet, instead of owning the hardware. You provision what you need through an API or console, pay for the time and capacity you use, and release it when you are done. The provider owns and operates the physical data centers; you control and secure what you run on top.

What are the three service models of cloud computing?

The three models are IaaS, PaaS, and SaaS. IaaS gives you raw compute, storage, and networking, with you managing the operating system and everything above it. PaaS gives you a managed runtime where the provider handles the OS and patching and you manage your application and data. SaaS is a finished application where you manage only your data, access, and tenant settings.

What are the deployment models of cloud computing?

The main deployment models are public cloud (shared infrastructure run by a provider for many tenants), private cloud (dedicated to one organization), and hybrid cloud (a private environment connected to a public cloud). Multi-cloud, using more than one public provider at once, is a common practice layered on top. NIST also defines community cloud, shared by organizations with common concerns.

What is the difference between cloud computing and cloud infrastructure?

Cloud computing is the overall model of delivering computing resources on demand over the internet, including the service models, the economics, and the way you consume capacity. Cloud infrastructure is the pool of physical and virtual resources, compute, storage, networking, and virtualization, that the provider operates to make that model work. Cloud computing is the what and why; cloud infrastructure is the what-it-is-built-from.

Why did organizations move to the cloud?

Organizations moved for cost, speed, reach, and focus. The cloud turns large upfront hardware spending into pay-as-you-go operating cost, replaces weeks of procurement with seconds of provisioning, scales capacity automatically with demand, and lets a small team use managed services that once required a dedicated department. Offloading hardware and base-layer operations to the provider frees people to work on the product.

Is cloud computing secure?

The provider's side of the cloud, the hardware, data centers, and virtualization layer, is typically more rigorously secured than most organizations could manage themselves. The risk lives on the customer side: data, identity, and configuration. Most cloud incidents come from misconfiguration and stolen credentials, not from the provider being breached. The cloud can be secure, but only if the customer gets the part they own right.

What changes for defenders in the cloud?

Three things. Identity becomes the perimeter, because every resource is reached through an authenticated API call governed by policy rather than a network wall. The attack surface becomes configuration, because a single wrong setting can expose data with no exploit. And evidence becomes ephemeral, living in control-plane audit logs rather than on disks, because the infrastructure itself appears and disappears on demand.

The bottom line

Cloud computing is the on-demand delivery of computing resources over the internet, metered by use, defined by NIST through five characteristics: self-service, broad network access, resource pooling, elasticity, and measured service. It is sold in three service models, IaaS, PaaS, and SaaS, and run in four deployment models, public, private, hybrid, and multi-cloud. Organizations adopted it for cost, speed, reach, and focus, and the adoption is now the default rather than the exception.

For a defender, the move rewrites the problem. There is no perimeter to patrol, so identity becomes the boundary. There is no break-in to most incidents, so configuration becomes the attack surface. There is no disk to image after the fact, so the control-plane log becomes the case file. Secure the data and the identities first, scope every policy to least privilege, scan configuration continuously, and turn the audit log on everywhere. The provider secures the cloud. You secure what you put in it, and the gap between those two is where almost every cloud incident lives.