Cloud security architecture is the design of identity, network, workload, data, telemetry and governance controls that protects applications and data in public, private, hybrid and multi-cloud environments, and it defines how those controls work together from code to runtime. It sets where trust boundaries sit, who and what can reach each resource, how data is encrypted, how activity is logged and how incidents are contained. A deliberate cloud security architecture matters because cloud breaches rarely come from one missing control. They come from chains of small gaps, such as an over-permissioned role attached to an internet-facing workload that runs a reachable vulnerability. This guide, current as of October 2026, covers the components, frameworks, reference patterns and maturity-based practices that architects use to break those chains.
Key takeaways
- ✓Cloud security architecture organizes controls into planes (identity, network, workload, application, data, telemetry, policy and response) so that each attack path meets more than one barrier.
- ✓The shared responsibility model shifts by service model, but the customer always owns identities, access configuration and data in IaaS, PaaS and SaaS.
- ✓No single framework is enough: Zero Trust sets the design principle, NIST CSF and CSA CCM structure the program, and CIS Benchmarks and MITRE ATT&CK make it testable.
- ✓Runtime evidence, meaning what is actually loaded, reachable and used in production, separates real risk from theoretical findings and should drive remediation priority.
What is cloud security architecture?
Cloud security architecture is the blueprint that decides which security controls exist in a cloud environment, where they sit, who owns them and how they interact, so that protection holds even when one control fails. Dark Reading’s guide on building a comprehensive security architecture frames the work the same way. Decide what the architecture must cover, which tools deliver it and what it costs to run.
The term is often confused with adjacent concepts. The table separates them.
| Term | What it covers | What it is not |
|---|---|---|
| Cloud security | The overall practice of protecting cloud assets, including operations, tooling and people | Not a design artifact; architecture is the plan the practice executes |
| Security architecture | The design discipline for any environment, including on-premises networks and endpoints | Not cloud-specific; it predates elastic infrastructure and API-driven control planes |
| Cloud-native security | Protection for containers, Kubernetes, serverless and microservices | Only one subset of cloud security architecture |
| Cloud security architecture | Control design across IaaS, PaaS and SaaS for identity, network, workload, data, telemetry and governance | Not a product or a one-time project; it changes with every new service and account |
Goals of the architecture
- ✓Confidentiality: only authorized identities read data, enforced through IAM, encryption and key custody.
- ✓Integrity: code, images, configurations and records cannot change without detection, using signing, immutable logs and drift detection.
- ✓Availability: services survive DDoS, zone failure and ransomware through redundancy and isolated backups.
- ✓Resilience: environments can be rebuilt from known-good templates instead of repaired by hand.
- ✓Visibility: every asset, identity and action is inventoried and logged centrally.
- ✓Compliance: controls map to regulatory requirements, and evidence is collected continuously rather than once a year.
Shared responsibility by service model
Each service model moves the boundary between provider and customer. Architecture work starts by marking which side owns each layer.
| Layer | IaaS (e.g. EC2, Azure VMs) | PaaS (e.g. managed Kubernetes, Cloud Run) | SaaS (e.g. Microsoft 365, Salesforce) |
|---|---|---|---|
| Physical data center, hardware | Provider | Provider | Provider |
| Hypervisor and host OS | Provider | Provider | Provider |
| Guest OS, patching, runtime | Customer | Shared (provider patches the platform; customer patches images) | Provider |
| Network controls (security groups, firewall rules) | Customer | Shared | Provider, with customer-set access policies |
| Application code and dependencies | Customer | Customer | Provider |
| Identities, access configuration, MFA | Customer | Customer | Customer |
| Data classification and protection | Customer | Customer | Customer |
Core components of a cloud security architecture
The architecture divides into control planes, each with a clear objective, a standard set of controls and owners. The table summarizes them, and the subsections add implementation detail.
| Plane | Objective | Common controls | Example technologies |
|---|---|---|---|
| Identity | Authenticate and authorize every human and machine | SSO, MFA, RBAC/ABAC, JIT access, workload identity | Microsoft Entra ID, Okta, AWS IAM Identity Center, CIEM |
| Network | Limit reachability and blast radius | Private subnets, security groups, WAF, private endpoints, mTLS | AWS WAF, Azure Firewall, Cloud Armor, Istio |
| Compute and workload | Harden and monitor running hosts, containers and functions | Hardened images, IMDSv2, admission control, runtime detection | CWPP, Falco, eBPF sensors, Kyverno |
| Application and delivery | Keep flaws and tampering out of the pipeline | SAST/DAST, IaC and secret scanning, artifact signing | Checkov, Gitleaks, Sigstore cosign |
| Data | Protect data by sensitivity | Classification, encryption, tokenization, key management | AWS KMS, Azure Key Vault, Cloud HSM, DSPM |
| Logging and telemetry | Record and correlate all activity | Audit logs, flow logs, Kubernetes audit logs, runtime events | CloudTrail, Azure Activity Log, Google Cloud Audit Logs, SIEM |
| Policy and compliance | Enforce guardrails and prove conformance | Org policies, policy-as-code, CSPM, evidence collection | AWS SCPs, Azure Policy, Open Policy Agent |
| Incident response | Contain and recover fast | Playbooks, isolation, forensics capture, CDR | SOAR, Microsoft Sentinel, AWS Security Hub |
Identity plane
Identity is the main perimeter in the cloud because every API call is an identity decision. These patterns hold up in practice:
- ✓SSO and federation: one identity provider issues SAML or OIDC assertions to every cloud and SaaS app, so offboarding happens in one place.
- ✓RBAC plus ABAC: roles define job functions, and attribute conditions (tags such as
env=prod,team=payments) narrow them further. - ✓PAM and JIT access: admins request elevation for a fixed window, for example 60 minutes, with approval and session logging instead of standing admin rights.
- ✓Workload identity: pods and functions receive short-lived tokens through EKS Pod Identity or IRSA, GKE Workload Identity or Azure Workload Identity, so no static access keys are needed.
Network plane
Network design limits what an attacker can reach after the first foothold. Place workloads in private subnets, expose only load balancers behind a WAF, reach managed services through private endpoints (PrivateLink, Private Service Connect, Azure Private Link) and default-deny east-west traffic with Kubernetes NetworkPolicies. A service mesh adds mutual TLS between services, so identity rather than IP address governs each connection.
Compute and workload plane
Workload controls protect what actually runs. Build from minimal base images, enforce IMDSv2 to block SSRF-based credential theft, apply Pod Security Standards at the Restricted level and reject privileged containers or hostPath mounts through admission control. eBPF-based runtime sensors watch system calls, process launches and network flows at the kernel with low overhead. Some platforms hide the host, such as AWS Fargate and other serverless services, so node-level sensors cannot run there. Agentless snapshot scanning and audit-log detection cover those workloads instead.
Application and delivery plane
The delivery pipeline is both a control point and a target. A mature DevSecOps chain includes:
- ✓IaC scanning of Terraform, CloudFormation and Helm before merge.
- ✓Secret scanning in pre-commit hooks and on every push.
- ✓SAST on pull requests and DAST against staging endpoints.
- ✓SBOM generation in SPDX or CycloneDX format, plus image signing with Sigstore cosign.
- ✓Policy gates that block unsigned images or critical misconfigurations from reaching production.
Data plane
Data controls scale with sensitivity, so classification comes first. Tag stores as public, internal, confidential or regulated, then match the protection to the tier:
- ✓Encryption: AES-256 at rest by default and TLS 1.2 or higher in transit.
- ✓Key custody: provider-managed keys for low-risk data; customer-managed keys in AWS KMS, Azure Key Vault or Cloud KMS for confidential data; dedicated FIPS 140-2 Level 3 HSMs (AWS CloudHSM, Azure Managed HSM) or external key managers when regulators require single-tenant custody.
- ✓Tokenization: replace card numbers or national IDs with tokens so most systems never hold raw values.
- ✓Backup segregation: copy backups to a separate account with immutability locks (for example AWS Backup Vault Lock), so a compromised production admin cannot delete them.
Telemetry, detection and response plane
Detection depends on centralized, tamper-resistant logs. Route control-plane audit logs, VPC flow logs, Kubernetes audit logs and runtime events into a dedicated log-archive account with write-once storage, then into a SIEM. Cloud detections should cover provider-specific behaviors such as new access keys, disabled logging and unusual role assumptions. SOAR playbooks then isolate a pod, revoke a session or quarantine a node. Forensic readiness means snapshotting disks and preserving container filesystems before automation destroys the evidence.
Policy, compliance and governance plane
Governance keeps the other planes from drifting over time. Maintain a continuous cloud asset inventory, assign an owner to every control, record exceptions with an expiry date and a compensating control, and run CSPM against your chosen benchmarks so drift shows up within hours rather than at audit time.
Frameworks and reference models for cloud security architecture
Frameworks give teams a shared vocabulary for control design. Most mature programs combine several instead of picking one. The matrix compares the most widely used.
| Framework | Best for | Strengths | Limitations |
|---|---|---|---|
| Zero Trust (NIST SP 800-207) | Setting the design principle | Removes implicit network trust; verifies every request | A model, not a control catalog |
| NIST CSF 2.0 | Program structure and board reporting | Six functions (Govern, Identify, Protect, Detect, Respond, Recover) map cleanly to planes | Outcome-level; light on cloud specifics |
| NIST SP 800-53 Rev. 5 | Federal and highly regulated workloads | Exhaustive control catalog; basis of FedRAMP baselines | Heavy to implement for smaller teams |
| CIS Benchmarks | Hardening specific services | Prescriptive, testable settings for AWS, Azure, GCP and Kubernetes | Configuration-focused; no runtime or process view |
| CSA Cloud Controls Matrix v4 | Cloud-specific control mapping and vendor assessment | 17 domains mapped to ISO 27001, NIST and PCI DSS; underpins CSA STAR | Requires interpretation per service model |
| Well-Architected security pillars (AWS, Azure, Google Cloud) | Provider-specific design reviews | Concrete guidance tied to native services | Each covers one provider only |
| MITRE ATT&CK Cloud matrix | Threat modeling and detection coverage | Real adversary techniques across IaaS, SaaS and identity providers | Describes attacks, not how to architect defenses |
| Kubernetes and CNCF guidance | Container platforms | CIS Kubernetes Benchmark, NSA/CISA hardening guide, Pod Security Standards | Limited to the cluster and workload layers |
Kubernetes documentation also offers the 4Cs model for container platforms, which splits them into Cloud (account and network guardrails), Cluster (API server access, RBAC, admission control), Container (image provenance, least-privilege runtime settings) and Code (dependencies, secrets, application logic). Each layer inherits the weaknesses of the one beneath it.
Compliance mapping examples for regulated industries
Architecture controls should trace directly to requirements. For a deeper look at how standards differ, see our guide to cloud security compliance frameworks.
- ✓PCI DSS 4.0, Requirement 3 (protect stored account data): tokenization plus customer-managed KMS keys with rotation.
- ✓PCI DSS 4.0, Requirement 10 (log and monitor access): centralized, immutable audit logs with retention and daily review.
- ✓HIPAA Security Rule §164.312: audit controls, encryption of ePHI and unique user identification through SSO.
- ✓SOC 2 CC6 (logical access): RBAC, JIT elevation and quarterly access reviews based on actual usage.
How the pieces fit together: reference architecture and deployment patterns
A reference architecture shows how the planes interact on a single request as it passes through the edge, reaches the data store and feeds detection. The walkthrough below describes a typical containerized application.
- Edge: DNS and CDN front the application; a WAF and DDoS protection (AWS Shield, Azure Front Door, Cloud Armor) filter malicious traffic.
- Authentication: an API gateway validates OIDC tokens issued by the central identity provider and enforces rate limits per client.
- Ingress: traffic enters private subnets through a load balancer and Kubernetes ingress; security groups allow only the expected ports.
- Service-to-service: a service mesh enforces mTLS, and NetworkPolicies deny any flow not explicitly allowed.
- Workload identity and secrets: pods assume short-lived cloud roles and pull secrets from Vault or a provider secrets manager at runtime; no keys live in images or environment files.
- Data access: databases and object stores accept connections only through private endpoints and encrypt with customer-managed keys.
- Telemetry: audit logs, flow logs, Kubernetes audit events and runtime sensor signals stream to the log-archive account and SIEM.
- Response: correlated detections trigger SOAR playbooks that isolate the workload, revoke the session and snapshot evidence.
Single public cloud
Build a landing zone with separate accounts, subscriptions or projects for production, non-production, security tooling and log archive. Apply guardrails at the organization level through AWS Service Control Policies, Azure Management Groups with Azure Policy, or Google Cloud organization policies.
Multi-cloud
Consistency matters more than any single cloud’s tooling. In practice:
- ✓Federate identity from one IdP into every provider.
- ✓Write guardrails once as policy-as-code (for example Open Policy Agent) and apply them everywhere.
- ✓Normalize logs from all clouds into one schema, such as OCSF, before they reach the SIEM.
- ✓Use the same tagging and segmentation model so “prod-payments” means the same thing in every cloud.
Native aggregators help, but they differ in scope. AWS Security Hub centralizes GuardDuty, Inspector, Config and Macie findings within AWS, while Microsoft Defender for Cloud covers Azure, AWS and GCP and extends to on-premises servers through Azure Arc.
Hybrid cloud
Connect data centers through private links (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect), keep identity anchored in one directory and treat the on-premises network as untrusted, applying the same Zero Trust checks to traffic from it.
Sample: regulated SaaS on Kubernetes across two clouds
As an example, consider a payments SaaS running on Amazon EKS as the primary and Google GKE for disaster recovery, processing card data under PCI DSS.
| Requirement | Mapped control |
|---|---|
| Isolate cardholder data environment | Dedicated accounts/projects and namespaces, default-deny NetworkPolicies, private endpoints |
| Strong access control | Okta or Entra ID SSO, phishing-resistant MFA, JIT cluster-admin for 60 minutes |
| Protect stored card data | Tokenization service; card vault encrypted with HSM-backed keys |
| Trusted software only | Cosign-signed images verified at admission; SBOM per release |
| Detect and respond | eBPF runtime detection on nodes, CloudTrail and GCP audit logs in one SIEM, isolation playbooks |
| Recover from ransomware | Immutable backups in a separate account, quarterly restore tests to GKE |
Cloud attack paths and the controls that stop them
The attack paths that matter most in cloud environments exploit identity, exposure and automation more than perimeter gaps, and each one maps to specific architectural controls. Our overview of common cloud security risks covers the wider set of threats. The table below ties the most frequent paths to the planes that break them.
| Attack path | How it happens | Architectural controls |
|---|---|---|
| Exposed storage | Bucket or blob container made public, or shared through a broad link | Org-level public access blocks, CSPM, DSPM classification |
| IAM privilege escalation | Abuse of permissions such as iam:PassRole combined with function creation to gain an admin role |
Least privilege, permission boundaries, CIEM detection of toxic combinations |
| Metadata service abuse | SSRF reaches 169.254.169.254 and steals instance credentials | Enforce IMDSv2, egress filtering, alerts on credential use from unexpected IPs |
| CI/CD compromise | Stolen pipeline tokens or poisoned dependencies push malicious builds | OIDC federation for pipelines, signed artifacts, admission verification |
| Insecure secrets | Keys hard-coded in repos, images or environment variables | Secret scanning, secrets managers, short-lived dynamic credentials |
| API abuse | Broken object-level authorization, scraping, credential stuffing | Gateway authentication, rate limits, API discovery and runtime inspection |
| Lateral movement | Compromised pod reaches databases or the cloud control plane | Default-deny NetworkPolicies, mTLS, scoped workload identities |
| Container escape | Privileged pods, hostPath mounts or kernel exploits reach the node |
Pod Security Standards (Restricted), admission control, runtime syscall detection |
Why do layered controls matter? A single misconfiguration rarely causes a breach. An exploitable path needs exposure, a reachable vulnerability and an identity with useful permissions. Removing any one of those links breaks the path, and runtime context shows which links actually exist in production.
How Upwind adds runtime evidence to cloud security architecture
Upwind sits in a cloud security architecture as the runtime-first CNAPP layer that shows which posture, identity and vulnerability findings are actually exploitable in production. It combines agentless, read-only cloud scanning for inventory and misconfigurations with lightweight eBPF sensors on VMs, containers and Kubernetes clusters (EKS, GKE, AKS and OKE), then correlates kernel-level telemetry with cloud configuration, IAM actions and network activity. Upwind holds a 4.8/5 rating from 88 reviews on Gartner Peer Insights as of October 2026, and a few reviewers note that its GCP support could be improved.
- ✓Prioritizes CVEs by reachability, packages actually loaded, internet exposure and exploitability.
- ✓Flags over-permissioned roles, unused permissions and toxic combinations, with least-privilege policy recommendations.
- ✓Builds Threat Stories with a timeline, root cause and response steps, routable to Microsoft Sentinel playbooks for container isolation or node quarantine.
- ✓Scans Terraform and CloudFormation, plugs into CI/CD and traces runtime findings back to the line of code.
- ✓Integrates with ServiceNow, Jira, PagerDuty and AWS Security Hub.
Cloud security architecture best practices by maturity level
Sequence these practices by maturity, so teams build foundations before they invest in advanced runtime and automation controls.
Foundational
- ✓Separate accounts, subscriptions or projects per environment, with org-level guardrails that block public storage and disabled logging.
- ✓Route all human access through SSO, require phishing-resistant MFA (FIDO2) for admins and lock away root or global admin credentials.
- ✓Enable organization-wide audit logging into a separate log-archive account with write-once storage such as S3 Object Lock.
- ✓Encrypt everything at rest and in transit by default.
- ✓Keep a continuous asset inventory, apply data classification tags and run CSPM against CIS Benchmarks.
Intermediate
- ✓Adopt workload identity everywhere and retire long-lived access keys.
- ✓Right-size IAM from usage data; for example, remove permissions a role has not used in 90 days.
- ✓Replace standing admin rights with JIT elevation and session recording.
- ✓Enforce policy-as-code in CI (Checkov, Conftest) and at admission (Kyverno or OPA Gatekeeper).
- ✓Rotate secrets with dual-credential patterns or dynamic secrets that carry short TTLs.
- ✓Assign a named owner to every control and track exceptions with an expiry date and a compensating control.
Advanced
- ✓Sign images with cosign, verify signatures at admission and publish an SBOM per release.
- ✓Run eBPF runtime detection on nodes and agentless scanning where sensors cannot run.
- ✓Rank vulnerabilities by runtime reachability and exposure rather than CVSS score alone.
- ✓Automate containment through SOAR, with forensic capture before termination.
- ✓Run immutable infrastructure and isolated, immutable backups with tested restores.
- ✓Automate continuous compliance by mapping controls to frameworks and collecting evidence from live configuration.
Apply the 3 Rs. Rotate credentials frequently so stolen secrets expire quickly. Repave hosts and containers from known-good images instead of patching them in place. Repair vulnerable components by rebuilding and redeploying as soon as fixes ship. Immutable infrastructure makes all three routine rather than disruptive.
Balancing security, velocity, cost and complexity
- Velocity: prefer guardrails to gates. Warn in development, block only in production, and give developers the fix along with the finding.
- Cost: log volume, HSMs and duplicated tools add up. Tier log retention by value and consolidate overlapping scanners.
- Complexity: every additional cloud multiplies policy and telemetry work. Standardize on one identity source, one policy language and one log schema.
Selecting tools
Judge platforms by how well they fit the architecture, not by feature lists. Our comparison of the best CNAPP tools applies these criteria in detail.
| Criterion | Questions to ask |
|---|---|
| Coverage | Does it cover every cloud, Kubernetes distribution, serverless platform, API and data store you run? |
| Deployment model | Agentless, sensor-based or both? What is the sensor overhead, and where can it not run? |
| Signal quality | Does it use runtime context such as loaded packages, reachability and actual permission usage to suppress noise? |
| Remediation ability | Does it trace findings to the owning code, team and fix, and can it contain threats automatically? |
| Integration | Does it plug into CI/CD, ticketing, SIEM and SOAR without custom glue? |
Implementation blueprint
- Inventory every account, asset and identity, and classify data by sensitivity.
- Pick a framework baseline: Zero Trust principles, NIST CSF 2.0 for structure and CIS Benchmarks for settings.
- Build the landing zone, org guardrails and federated identity.
- Design network segmentation, private endpoints and the key management hierarchy.
- Add IaC scanning, secret scanning, signing and policy gates to the pipeline.
- Centralize logs, deploy runtime detection and map detections to MITRE ATT&CK.
- Write and rehearse response playbooks, including forensic capture and backup restores.
- Measure progress through mean time to remediate, share of workloads on workload identity and open exceptions past expiry, then iterate.
A cloud security architecture is never finished. New services, accounts and AI workloads change the attack surface every quarter. Teams that design in planes, build on recognized frameworks and prioritize with runtime evidence spend less time chasing alerts and more time closing the attack paths that matter.
FAQ
What is cloud security architecture?
Cloud security architecture is the blueprint for deciding which security controls exist in a cloud environment, where they sit, who owns them, and how they work together across identity, network, workload, data, telemetry, and governance.
Which frameworks are most useful for cloud security architecture?
The article recommends combining frameworks rather than relying on one. Zero Trust sets the design principle, NIST CSF 2.0 structures the program, CSA CCM maps cloud-specific controls, CIS Benchmarks provide testable hardening guidance, and MITRE ATT&CK Cloud helps validate detection coverage.
Why does runtime evidence matter in cloud security architecture?
Runtime evidence shows what is actually loaded, reachable, and used in production. That context helps teams distinguish real attack paths from theoretical findings and prioritize remediation based on exposure, exploitability, and actual permission use.
What are the first best practices to implement in a cloud security architecture?
Start with separate accounts or projects per environment, organization-level guardrails, SSO with phishing-resistant MFA for admins, centralized audit logging in a separate write-once log archive, encryption by default, continuous asset inventory, data classification, and CSPM mapped to CIS Benchmarks.