What Is Cloud Infrastructure? A Security View

Most cloud incidents you will investigate do not start with an exploit. They start with a setting. An S3 bucket left readable by anyone. An IAM role with a wildcard policy that a phished access key could assume. A security group opened to 0.0.0.0/0 for a "quick test" that stayed open for a year. A snapshot shared to an account nobody owns. In each case nothing was hacked in the classic sense. The infrastructure did exactly what it was configured to do, and the configuration was wrong.

Cloud infrastructure is the pool of compute, storage, networking, and virtualization that a provider runs and rents to you on demand, plus the control plane you use to provision and govern it. NIST defines the parent concept, cloud computing, as "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 that pool actually contains, the three service models and who secures what at each, the deployment models, the components a defender has to reason about, and how teams secure and monitor an environment they do not physically own. It is written for the people who answer for it after the fact: SOC analysts triaging CloudTrail, threat hunters in a VPC, and DFIR responders who have to reconstruct what an access key touched.

What is cloud infrastructure?

Cloud infrastructure is the set of physical and virtual resources a cloud provider operates and offers as a service: servers, storage arrays, networking gear, and the virtualization layer that slices all of it into the instances, volumes, and networks you actually consume. You rent capacity instead of buying hardware, you provision it through an API or console instead of a purchase order, and you release it when you are done. The provider owns the metal and the data centers. You own the configuration of everything you spin up on top.

That word "configuration" is the whole security story. In a traditional data center, an attacker had to get through a physical perimeter and a network perimeter before reaching a host. In the cloud, every resource has an API, every API call is governed by a policy, and a single permissive policy or public setting can expose a resource directly to the internet with no perimeter in the way. The attack surface is not a building. It is the sum of your configurations and the identities allowed to change them.

Cloud infrastructure is delivered against five characteristics NIST names: on-demand self-service (you provision without a human in the loop), broad network access (it is reachable over the network), resource pooling (the provider's hardware is shared across many tenants), rapid elasticity (capacity scales up and down fast), and measured service (you pay for what you use). For a defender, two of those matter most. Self-service means anyone with credentials can create or destroy infrastructure in seconds, so identity is the perimeter. Resource pooling means you share physical hardware with strangers, so the provider's tenant isolation, and your own configuration, are what keep your data yours.

The service models: IaaS, PaaS, SaaS

The cloud is sold in three layers, and which layer you buy decides how much you have to 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. You do not manage the physical servers or the hypervisor, but 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 the one that 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. You stop managing servers and start managing your application and its data. 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, deceptively, still leaves you plenty to get wrong, because misconfigured sharing and over-broad access are the failures that bite at this layer.

The pattern across all three is the same: as you move from IaaS to SaaS, the provider takes over more of the stack, and your responsibility narrows but never disappears. The thing that is always yours, at every layer, is your data and the identities that can reach it.

Who secures what: the shared responsibility model

The single most important security concept in the cloud is that responsibility is split between provider and customer, and the line moves with the service model. AWS frames it as security "of" the cloud versus security "in" the cloud. The provider is responsible for the security of the cloud: the hardware, the data centers, the hypervisor, the managed-service software. You are responsible for security in the cloud: your data, your identity and access management, your OS patching where it applies, your network configuration, and your encryption choices.

The trap is assuming the provider covers more than it does. A managed datacenter and a patched hypervisor do nothing for an S3 bucket you set to public, an IAM policy you wrote with Action: "*", or a database you exposed to the internet with a default password. Those are all on your side of the line, at every service model. The provider secures the floor you stand on. It does not secure the door you left open. This split is exactly why cloud misconfigurations, not provider breaches, are the dominant cause of cloud data exposure: the customer-owned side of the line is where the mistakes live.

Read the table top to bottom and the rule is clear: the top two rows, data and identity, are yours at every model. They are also the two rows attackers go after first, because they do not depend on the provider doing anything wrong.

Deployment models: public, private, hybrid, multi-cloud

Where the infrastructure runs is a separate axis from how it is sold. NIST defines four deployment models, and 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. 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 IAM 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.

The components a defender has to reason about

Underneath the models, cloud infrastructure is a handful of component types. Knowing them is what lets you read an architecture diagram or an audit log and know what you are looking at.

Compute is where code runs. Virtual machines (EC2 instances, Azure VMs) are full virtualized servers you control. Containers package an application with its dependencies and run many to a host; containerization is the dominant packaging model for cloud-native workloads, usually orchestrated by Kubernetes. Serverless functions run your code on demand with no server for you to manage at all.

Storage comes in two main shapes. Object storage (S3, Azure Blob, Google Cloud 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 (EBS, managed disks) is the virtual hard drive attached to a VM, and a shared or public snapshot is a quieter but equally real leak path.

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

Identity and access management (IAM) is the policy engine that decides which identity can call which API on which resource. Users, roles, groups, and policies live here. IAM 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.

The control plane is the management layer, the APIs and console you use to create, modify, and destroy all of the above. It sits above the data plane (the running workloads and their traffic). The distinction matters for defenders: an attacker who compromises a workload is in the data plane, but an attacker who steals credentials and starts making API calls is in the control plane, where they can reshape the environment itself, change a policy, snapshot a database, or spin up mining instances. Control-plane activity is what CloudTrail and the equivalent audit logs record, and it is the first place an investigation looks.

Why cloud infrastructure 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 IAM policy, not a firewall at the building's edge. A compromised access 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, is 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.

Evidence is ephemeral. Self-service and elasticity mean infrastructure appears and disappears in seconds. An instance that ran for ten minutes and was terminated still happened, but if you were not logging the control plane, it left no trace. Evidence lives in logs, not on disks you can image later, because the disk may not exist anymore. And when a key is compromised, the blast radius is exactly what that identity was allowed to reach, which is why cloud vulnerabilities are so often permission problems rather than software bugs.

How defenders secure and monitor cloud infrastructure

Securing the cloud is mostly about getting the customer side of the shared responsibility line right, then watching it continuously. A few disciplines do most of the work.

Least-privilege IAM. Scope every policy to the specific actions and resources an identity actually needs. No wildcards on actions, no wildcards on resources, no standing admin. Use roles with short-lived credentials instead of long-lived access keys, and review what is actually used against what is granted. Most cloud incidents are a policy that was too broad.

Cloud Security Posture Management (CSPM). CSPM tools continuously scan your environment against a baseline and flag the misconfigurations that matter: public buckets, open security groups, unencrypted volumes, disabled logging, over-permissive roles. Because the dominant risk is configuration, continuous posture scanning is the single highest-leverage control, catching the open door before an attacker does.

Logging and audit trails. Turn on the control-plane audit log everywhere, AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs, and ship it somewhere it cannot be tampered with. This is the record of every API call, the accounting layer of the cloud, and without it an investigation has nothing. Capturing the inputs to each call, who, what, and from where, is what turns a compromised-key alert into a reconstructable incident.

Encryption and network controls. Encrypt data at rest and in transit, and govern key access with least-privilege IAM. Keep security groups default-deny, put anything that does not need the internet in a private subnet, and allow 0.0.0.0/0 ingress only for a genuinely public service. The VPC is still a meaningful boundary; it is just defined in policy rather than in cabling.

These map onto the broader discipline of AWS cloud security best practices, but the principle is provider-agnostic: secure the data and the identities first, watch the control plane continuously, and treat every misconfiguration as the open door it is.

The bottom line

Cloud infrastructure is compute, storage, networking, and virtualization delivered as a service, provisioned through a control plane and billed by use. It is sold in three layers, IaaS, PaaS, and SaaS, and the layer you buy decides how much of the stack you secure, but data and identity are yours at every layer. The shared responsibility model is the concept to internalize: the provider secures the cloud, you secure what you put in it, and the gap between those is where almost every cloud incident lives.

For a defender the consequences are concrete. Identity is the perimeter, so a stolen key with broad permissions beats any network exploit. The attack surface is configuration, so a public bucket or an open security group is a real exposure with no break-in. Infrastructure is ephemeral, so evidence lives in the control-plane log or nowhere. Secure the data and the identities first, scope every policy to least privilege, turn the audit log on everywhere, and scan posture continuously. The same discipline that closes the open door is the one that leaves you the record to reconstruct what happened when one is left open.