Cloud Computing Pattern

Key Control Areas

When to Use

Any organisation that consumes cloud services for production workloads, development and testing, data storage, or SaaS applications. This pattern applies whether the organisation uses a single cloud provider or multi-cloud strategy, and regardless of service model (IaaS, PaaS, SaaS). It is essential for organisations migrating workloads from on-premises to cloud, adopting cloud-native architectures (containers, serverless, microservices), or evaluating cloud providers for regulated workloads subject to compliance requirements such as PCI DSS, HIPAA, SOX, or GDPR.

When NOT to Use

Organisations that operate entirely on-premises with no cloud service consumption, including SaaS, may not need this pattern. However, this is increasingly rare -- even organisations with strict on-premises policies typically consume SaaS services (email, collaboration, HR systems) that fall under this pattern's scope. The pattern should not be applied without first completing a data classification exercise to understand what data will be stored in cloud environments and what regulatory constraints apply.

Typical Challenges

The shared responsibility model is widely misunderstood. Organisations frequently assume that 'moving to the cloud' transfers security responsibility to the provider, when in practice the customer remains responsible for data protection, access control, and application security in all service models. Cloud misconfigurations are the leading cause of cloud data breaches -- public S3 buckets, overly permissive security groups, disabled logging, and unencrypted storage are discovered by automated scanners constantly probing cloud provider IP ranges. Identity and access management complexity grows exponentially with cloud adoption: cross-account access, service account sprawl, overprivileged roles, and the challenge of implementing least privilege across thousands of fine-grained permissions. Vendor lock-in is a strategic risk -- data portability, API compatibility, and the cost of migration make provider changes expensive and disruptive. Compliance in multi-region deployments requires understanding data sovereignty laws, which vary by jurisdiction and change frequently. Shadow IT flourishes when cloud services are easy to provision with a credit card, bypassing security review processes. Cost management intersects with security when cryptomining attackers exploit compromised credentials to provision expensive compute resources.

Threat Resistance

This pattern addresses cloud-specific threats including: misconfiguration of cloud resources exposing data to public access; credential compromise enabling unauthorised access to cloud management planes; insider threats from both the customer organisation and the cloud provider; data exfiltration through overly permissive egress rules or compromised API keys; denial of service attacks targeting cloud-hosted applications; supply chain attacks through compromised container images, serverless dependencies, or infrastructure modules; cross-tenant attacks exploiting vulnerabilities in the cloud provider's isolation mechanisms; cryptojacking where attackers use compromised cloud accounts to mine cryptocurrency; data sovereignty violations from unintended data replication across jurisdictions; and loss of availability from cloud provider outages or account suspension.

Assumptions

The organisation has evaluated and selected cloud service providers based on documented security and compliance requirements. A shared responsibility model is understood and formally documented, with clear delineation of which controls are the provider's responsibility and which are the customer's. Network connectivity between on-premises and cloud environments (if applicable) uses encrypted tunnels or dedicated connections. The organisation has personnel with cloud security skills or is investing in upskilling. Data classification exists and informs decisions about which data can be stored in which cloud environments and regions.

Developing Areas

• Cloud-Native Application Protection Platforms (CNAPP) are consolidating previously separate capabilities -- CSPM, CWPP, CIEM, and cloud code security -- into unified platforms, but the market is still in flux. Vendors like Wiz, Prisma Cloud, and Orca each take different architectural approaches (agentless vs agent-based, graph-based vs policy-based), and organisations struggle to evaluate which capabilities are genuinely integrated versus bolted-on acquisitions. The risk of consolidation fatigue is real: organisations deploy a CNAPP expecting comprehensive coverage but discover gaps that require supplementary point solutions.
• Cloud-native identity federation complexity is increasing as organisations operate across multiple cloud providers, SaaS applications, and on-premises identity stores. The number of machine identities (service accounts, workload identities, API keys) now exceeds human identities by a factor of 10-45x in typical cloud environments, and tools for managing this machine identity sprawl are immature. Cross-cloud identity federation (AWS roles assuming Azure managed identities, GCP workload identity federation with external providers) introduces trust chains that are difficult to audit and easy to misconfigure.
• Sovereign cloud requirements driven by EU data sovereignty regulations, Schrems II implications, and national security concerns are fragmenting the cloud market. Hyperscale providers are responding with sovereign cloud offerings (AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, Google Distributed Cloud), but these come with reduced service availability, higher costs, and operational complexity. Organisations operating across jurisdictions must navigate an increasingly complex matrix of data residency, operational residency, and encryption key sovereignty requirements that existing cloud security frameworks do not fully address.
• Cloud Detection and Response (CDR) is emerging as a distinct discipline that applies detection engineering principles specifically to cloud control plane events. Unlike traditional EDR which monitors endpoint behaviour, CDR analyses CloudTrail, Azure Activity Log, and GCP Audit Log events to detect attacker techniques such as privilege escalation through IAM policy manipulation, persistence via backdoor role creation, and defence evasion through log disabling. The tooling is maturing rapidly (Vectra AI, Lacework, native cloud provider offerings) but detection rule libraries are still being developed, and cloud-specific threat intelligence is less mature than endpoint threat intelligence.
• The intersection of FinOps and cloud security is creating a new operational challenge. Cryptomining attacks that exploit compromised cloud credentials can generate tens of thousands of dollars in compute costs within hours, and cost anomaly detection is increasingly viewed as a security detection mechanism. Conversely, aggressive cost optimisation (shutting down logging, deleting snapshots, reducing instance sizes) can inadvertently weaken security controls. Organisations are beginning to recognise that FinOps and CloudSecOps teams need shared visibility and coordinated policies, but the tooling and processes for this integration are nascent.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.