Cloud Security in 2026: Securing AWS, Azure, and Google Cloud Workloads

Cloud security failures look different from traditional on-premises breaches. The compromised credential is the same; the scale of exposure is not. A misconfigured S3 bucket can expose millions of records in seconds. A cloud service account with excessive permissions can give an attacker lateral movement across an entire cloud estate. The shared responsibility model means your cloud provider secures the infrastructure; you own everything above it.

This guide covers cloud security for the three major platforms, AWS, Azure, and Google Cloud Platform (GCP), from the shared responsibility model through to container security, serverless security, and multi-cloud governance. Whether your organisation is in the early stages of cloud migration or running mature cloud-native workloads, the threat landscape and control framework here applies directly.

Table of Contents

• The Shared Responsibility Model
• Cloud Misconfigurations: The Leading Cause of Cloud Breaches
• Cloud Security Posture Management (CSPM)
• Identity and Access Management in the Cloud
• Network Security in Cloud Environments
• Container and Kubernetes Security
• Serverless Security
• Cloud Workload Protection Platforms (CWPP)
• Multi-Cloud Security Strategy
• Frequently Asked Questions

The Shared Responsibility Model

Every major cloud provider publishes a shared responsibility model defining the security boundary between what the provider secures and what the customer is responsible for. Understanding this model is not optional; misunderstanding it is the root cause of a significant percentage of cloud security incidents.

The boundary varies by service type. For Infrastructure as a Service (IaaS), the provider secures the physical infrastructure, hypervisor, and networking hardware. You are responsible for the operating system, runtime, middleware, application, and data. For Platform as a Service (PaaS), the provider additionally manages the operating system and runtime. For Software as a Service (SaaS), the provider manages nearly everything; you are responsible for access management and data.

The practical implication is that “the cloud is secure” is not a complete statement. The provider’s infrastructure may be secure while your configuration of that infrastructure is not. The largest cloud breaches are not caused by cloud provider vulnerabilities; they are caused by customer misconfigurations, excessive permissions, and unpatched workloads. The responsibility model makes this your problem, not your provider’s.

For a broader context on how the major cloud platforms compare in terms of security features and compliance certifications, the analysis of AWS vs. Azure vs. Google Cloud for AI workloads covers the architectural differences that affect security posture decisions. The guide on how hyperscalers built the AI cloud provides the infrastructure context behind the shared responsibility boundaries.

Responsibility by Platform

Cloud Misconfigurations: The Leading Cause of Cloud Breaches

Gartner has consistently forecast that through 2025, 99% of cloud security failures will be the customer’s fault. That estimate is directionally accurate even if the precise figure is debatable. The most common categories of misconfiguration causing actual breaches are publicly exposed storage buckets, over-permissive identity and access management policies, unrestricted network security group rules, and unencrypted data stores.

Publicly exposed S3 buckets, Azure Blob containers, and GCS buckets have been the single most common source of large-scale data breaches since cloud adoption accelerated. The mechanism is elementary: a developer creates a storage bucket, sets it to public access for a quick test, and never reverts the setting. Or the default configuration in a region or service tier allows public access and the developer does not know to override it. The result is that sensitive data is accessible to anyone with the URL.

Over-permissive IAM is the second major category. Developers and operations teams under delivery pressure grant broad permissions (AdministratorAccess, Owner, wildcard resource ARNs) because it resolves access issues quickly. Those permissions are rarely reduced after the immediate problem is solved. Over time, accounts and roles accumulate far more permission than they need. When those accounts are compromised, the attacker inherits the excess permissions.

For a practical introduction to cloud security controls for organisations at earlier stages of cloud adoption, the guide on cloud computing security fundamentals covers the baseline controls that prevent the most common misconfiguration categories.

Misconfiguration vs. On-Premises Vulnerability

Traditional on-premises vulnerabilities typically require an attacker to find and exploit a technical flaw. Cloud misconfigurations require no exploitation; the attacker simply accesses what has been inadvertently made accessible. Automated scanning tools continuously probe for publicly exposed cloud storage, exposed management APIs, and other common misconfigurations. The window between a misconfiguration occurring and it being discovered by an attacker is often measured in minutes.

Cloud Security Posture Management (CSPM)

Cloud Security Posture Management (CSPM) tools continuously monitor your cloud environment for misconfigurations, policy violations, and compliance gaps. They provide a real-time view of your security posture across cloud accounts and regions, alert on deviations from security baselines, and increasingly offer automated remediation for common misconfiguration categories.

The major CSPM platforms include AWS Security Hub with native AWS integration, Microsoft Defender for Cloud covering Azure and multi-cloud, Google Security Command Center for GCP, and multi-cloud CSPM platforms such as Prisma Cloud (Palo Alto Networks), Lacework, Wiz, and Orca Security. Wiz in particular has gained rapid enterprise adoption for its agentless architecture that provides complete cloud estate visibility without per-workload deployment requirements.

What Good CSPM Looks Like

Effective CSPM goes beyond generating alert lists. The most valuable capability is attack path analysis: visualising how an attacker with an initial foothold could chain misconfigurations and over-permissive access to reach sensitive data or critical systems. A publicly exposed EC2 instance that has an attached IAM role with S3 read access to a bucket containing customer data is a critical risk even if neither the exposed instance nor the IAM role would individually trigger a high-severity alert. Attack path analysis surfaces this combined risk.

Automated remediation must be applied carefully. Automatically blocking public access to a storage bucket that was intentionally public (for a CDN origin or a public website asset bucket) causes operational disruption. Start with automated detection and human-approved remediation, then selectively automate fixes for misconfiguration categories where the remediation is unambiguously safe.

Identity and Access Management in the Cloud

Cloud IAM is more complex than on-premises IAM because the entities that need access to resources include not just human users but also compute instances, Lambda functions, containers, and third-party services. Every workload has an identity, and that identity needs the minimum permissions required to perform its function.

AWS IAM

AWS IAM uses a combination of users, groups, roles, and policies. The key architectural decision for workload access is to use IAM roles rather than static access keys. An EC2 instance or Lambda function with an attached IAM role receives temporary credentials that rotate automatically. Static access keys stored in code or configuration files are a persistent vulnerability: they do not expire, they can be committed to version control, and when they are exposed, they provide access until explicitly rotated. The AWS Well-Architected Framework’s security pillar requires that no long-term access keys be used for workloads that can use roles.

Azure RBAC and Managed Identities

Azure Role-Based Access Control (RBAC) governs access to Azure resources. Managed Identities are the Azure equivalent of IAM roles: Azure services can be assigned a managed identity and granted permissions to other Azure resources without storing credentials anywhere. System-assigned managed identities are tied to a specific resource and deleted with it; user-assigned managed identities can be shared across resources. Using managed identities for all service-to-service authentication eliminates the stored credential problem at the infrastructure layer.

GCP Service Accounts and Workload Identity

GCP uses service accounts for non-human identities. Workload Identity Federation allows workloads running outside GCP (in another cloud, on-premises, or in CI/CD pipelines) to authenticate as a service account using their existing identity rather than long-lived service account keys. This eliminates the need to export and distribute service account keys for cross-environment authentication, which is the GCP equivalent of the stored credentials problem AWS and Azure face with static access keys.

Network Security in Cloud Environments

Cloud network security uses different abstractions from on-premises networking but serves the same purpose: restricting which traffic can flow between which components. The key concepts across the three major platforms are virtual private clouds (VPCs), security groups, network access control lists, and private connectivity options.

Security groups in AWS, network security groups in Azure, and firewall rules in GCP are stateful packet filters applied at the resource level. The default secure configuration is to deny all inbound traffic and allow only specifically required ports and protocols from authorised source addresses or security groups. In practice, permissive rules accumulate over time for the same reason IAM permissions do: it resolves the immediate problem quickly. Regular security group audits are the operational mechanism for keeping network access controls tight.

Private connectivity between your cloud environment and on-premises infrastructure, via AWS Direct Connect, Azure ExpressRoute, or Google Cloud Interconnect, keeps sensitive traffic off the public internet. VPC peering and Private Link services allow traffic between cloud services to stay on the provider’s private network rather than traversing the internet, which both improves security and reduces latency.

Container and Kubernetes Security

Container adoption has introduced a new set of security considerations. The container runtime is shared infrastructure; a container escape vulnerability allows a compromised container to affect the host and other containers. Container images pulled from public registries may contain vulnerabilities or malicious code. Kubernetes, the dominant container orchestration platform, has a broad attack surface that requires deliberate hardening.

Container Image Security

Every container image in production should be built from a verified base image, scanned for vulnerabilities before deployment, and rebuilt promptly when vulnerabilities are disclosed in the base image or its dependencies. Snyk Container, Trivy, Anchore, and the native scanning in Amazon ECR, Azure Container Registry, and Google Artifact Registry all provide image vulnerability scanning. Integrate scanning into your CI/CD pipeline and enforce policy gates that block deployment of images with high-severity vulnerabilities.

Minimal base images, such as Google Distroless images or Alpine Linux, reduce the attack surface by including only the libraries and binaries required for the application. An image that contains no shell, no package manager, and no debugging tools is significantly harder to exploit for post-compromise persistence than a full operating system image.

Kubernetes Security

Kubernetes has a large attack surface and a default configuration that is not hardened for production security. Critical hardening steps include: enable Role-Based Access Control (RBAC) and apply least privilege to all service accounts; use Network Policies to implement microsegmentation between pods; run workloads as non-root users and set read-only root filesystems where the application allows; enable audit logging for the Kubernetes API server; use PodSecurity Admission to enforce security standards at the namespace level; and restrict access to the Kubernetes API server to authorised networks and users.

The Kubernetes API server is a high-value target: it controls the entire cluster. Exposing the API server to the internet without strong authentication and network controls is a critical misconfiguration that automated attackers actively scan for. Use private API server endpoints where possible and restrict public access absolutely.

Serverless Security

Serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) introduce a security model that differs from both traditional VMs and containers. You do not manage the underlying infrastructure, but you remain responsible for the function code, its permissions, its dependencies, and the data it processes.

The unique security considerations for serverless include: function code is typically more exposed to untrusted input (serverless functions are often invoked via HTTP or message queues with external data); dependency chains are deep (a Lambda function may depend on dozens of npm or Python packages, each with their own vulnerability surface); IAM permissions are critical because an over-permissioned Lambda can be a significant lateral movement vector; and cold start times create pressure to keep functions warm, which can create unintended execution paths.

Apply least privilege IAM to every function: each function should have an execution role that grants only the specific AWS/Azure/GCP permissions it needs, scoped to the specific resources it needs to access. Audit function dependencies regularly for known vulnerabilities. Use environment variables for configuration values and reference secrets from a secrets manager (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) rather than hardcoding credentials in function code or environment variables in the deployment configuration.

Cloud Workload Protection Platforms (CWPP)

Cloud Workload Protection Platforms (CWPP) extend security monitoring and protection to individual workloads: VMs, containers, serverless functions, and databases. Where CSPM monitors configuration, CWPP monitors runtime behaviour. A workload that is correctly configured can still be compromised through a vulnerability or a supply chain attack; CWPP detects the malicious behaviour that follows.

CWPP capabilities typically include: vulnerability scanning for running workloads, runtime protection that detects anomalous process execution or network connections, file integrity monitoring, container behaviour monitoring, and threat detection using signatures and behavioural analytics. Leading platforms include Crowdstrike Falcon Cloud Security, Prisma Cloud, Wiz, Aqua Security, and Sysdig Secure.

The CNAPP (Cloud-Native Application Protection Platform) category has emerged to combine CSPM and CWPP capabilities in a unified platform, recognising that the split between configuration posture and runtime protection creates visibility gaps. A single platform that covers the full lifecycle from code to cloud to runtime provides a more complete picture of risk.

Multi-Cloud Security Strategy

Most organisations with significant cloud footprints operate across multiple cloud providers, either by design (using the best services from each provider) or by acquisition (inheriting another company’s cloud environment). Multi-cloud introduces security governance complexity: each platform has different native security tools, different IAM models, and different logging formats.

For a grounded analysis of when to choose different cloud platforms for different workload types, including security and compliance considerations by use case, the comparison of on-premises AI vs. cloud AI covers the decision framework that applies broadly to cloud architecture choices beyond AI specifically.

Unified Visibility

Security monitoring across multiple clouds requires either a multi-cloud CSPM/SIEM platform that ingests from all providers or a significant normalisation effort to make logs from different providers comparable. Microsoft Sentinel, Splunk, and Sumo Logic have strong multi-cloud ingestion. Native tools (AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center) have excellent depth within their own platform but limited cross-cloud correlation.

Identity Governance Across Clouds

Managing human and machine identities across multiple cloud providers requires a governance layer that sits above the native IAM systems. Enterprise identity providers such as Azure Active Directory and Okta can federate authentication across cloud platforms using standard protocols, providing a unified access review and governance process. Service identity management across clouds is harder: each provider has different role and service account abstractions, and unified lifecycle management requires tooling that understands all three.

Policy as Code

Infrastructure as Code (IaC) practices, using Terraform, Pulumi, or native tools like CloudFormation and Bicep, create consistent, version-controlled infrastructure configuration. Security policies applied to IaC templates (via tools such as Checkov, tfsec, or Conftest) catch misconfigurations at the point of definition rather than after deployment. Shifting security left into the development pipeline is the most cost-effective point to prevent misconfigurations; remediation at deploy time is significantly cheaper than remediation after an incident.

Frequently Asked Questions

Is the cloud more secure than on-premises infrastructure?

The physical and infrastructure security of major cloud providers exceeds what most organisations can achieve on-premises. The customer-controlled layers, application configuration, IAM, network access controls, and data handling, are as secure as you make them. Cloud’s broad access from the internet increases exposure if controls are misconfigured. The honest answer is: it depends on how well you implement your half of the shared responsibility model.

What are the most common cloud security failures in UK organisations?

Publicly exposed storage buckets, over-permissive IAM roles with wildcard resource access, unrestricted security group rules permitting broad inbound access, unpatched container images and EC2 instances, and credentials stored in source code or configuration files rather than secrets managers. These five categories account for the overwhelming majority of cloud security incidents across all organisation sizes and sectors.

How does CSPM differ from a traditional vulnerability scanner?

Traditional vulnerability scanners probe workloads for known software vulnerabilities. CSPM evaluates cloud configuration and IAM policies against security best practice benchmarks, such as the CIS Cloud Benchmarks and the relevant provider’s Well-Architected Framework. CSPM finds misconfigured access controls, excessive permissions, and policy violations. You need both: a vulnerability scanner for what is running on your workloads, and CSPM for how your cloud environment is configured.

Should we use native cloud security tools or third-party platforms?

Native tools (AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center) have the deepest integration and the lowest additional cost if you are already paying for the cloud service. Third-party platforms offer better multi-cloud visibility and often more sophisticated analytics. The practical answer for most organisations: use native tools as the baseline, especially for single-cloud environments, and evaluate third-party platforms when multi-cloud visibility or advanced analytics requirements emerge.

How do container security requirements differ from traditional VM security?

Containers are immutable by design, which is a security advantage: the attack surface is defined at image build time and the container should not change at runtime. This means vulnerability management focuses on the image pipeline rather than runtime patching. Runtime security monitors for deviations from expected behaviour rather than applying patches. The shared kernel model means container escape vulnerabilities in the runtime can affect the host, which has no direct equivalent in VM security.

What UK regulatory requirements apply specifically to cloud environments?

UK GDPR and the Data Protection Act 2018 apply to all processing of personal data, including processing in cloud environments. The ICO’s guidance requires understanding where data is stored, appropriate transfer mechanisms for data stored or processed outside the UK or EEA, data processor agreements with cloud providers, and technical measures appropriate to the risk. FCA-regulated organisations additionally face cloud outsourcing requirements under the FCA’s operational resilience framework, which requires understanding and managing concentration risk when relying on cloud providers.