Cloud Security Architecture: Design for AWS, Azure, and GCP

Cybersecurity Cybersecurity 8 min read 1529 words Beginner ExcellentWiki Editorial Team

Cloud security architecture requires a fundamentally different approach than traditional on-premises security. The shared responsibility model, elastic infrastructure, and API-driven management create unique challenges and opportunities. On-premises security relied on physical perimeter controls — firewalls at the network edge, locked server rooms, air-gapped networks. In the cloud, there is no physical perimeter. Security must be embedded in every layer: identity, network, data, application, and infrastructure configuration. This guide covers the architectural principles and patterns for designing secure cloud environments.

The Shared Responsibility Model

Every cloud provider operates under a shared responsibility model. The exact division varies by service type, but the principle is consistent: the provider secures the cloud; the customer secures what they put in the cloud.

IaaS Responsibility Breakdown

In infrastructure-as-a-service (IaaS), the provider secures the physical data center, networking hardware, storage systems, and hypervisors. The customer secures everything above the hypervisor: operating systems, applications, data, network configurations, identity and access management, and client-side encryption.

AWS EC2 provides a clear example. AWS secures the physical host, the virtualization layer, and the underlying network. The customer patches the guest OS, configures security groups, manages IAM roles, encrypts data on EBS volumes, and secures the application running on the instance.

PaaS and SaaS Shifts

In platform-as-a-service (PaaS), the provider assumes responsibility for the runtime environment, middleware, and often the operating system. AWS RDS manages database patching, backups, and operating system security. The customer still controls data access policies, encryption keys, network access through security groups, and IAM permissions.

In software-as-a-service (SaaS), the provider handles most security responsibilities except user access, data classification, and data sharing policies. Salesforce, for example, secures the application infrastructure, but customers must configure multi-factor authentication, manage user roles, and control data sharing rules.

Responsibility Gaps

The most common cloud security failures occur at the boundaries of responsibility. Customers assume the provider handles something that is actually the customer’s job. The AWS IAM documentation famously states: “AWS is responsible for the security of the cloud. You are responsible for security in the cloud.” Misconfigured S3 buckets, open security groups, and unpatched EC2 instances are all customer-side failures with severe consequences.

Identity and Access Management

IAM is the cornerstone of cloud security. Every API call, every console login, every resource access requires authentication and authorization. In a perimeter-less architecture, identity is the new security boundary.

Principle of Least Privilege

Every user, service, and resource should have only the permissions necessary to perform its function. Start with no permissions and add only what is needed. Review permissions regularly and revoke unused access.

Cloud IAM systems support roles, policies, and conditions that enable fine-grained access control. AWS IAM policies can specify actions, resources, and conditions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::corporate-data/*",
      "Condition": {
        "IpAddress": {"aws:SourceIp": "10.0.0.0/16"}
      }
    }
  ]
---

Multi-Factor Authentication

MFA must be required for all human users. Cloud provider root accounts, administrative users, and developers with production access should use hardware security keys (FIDO2/WebAuthn) or time-based one-time password (TOTP) authenticator applications. SMS-based MFA is better than no MFA but is vulnerable to SIM-swapping attacks.

Roles Instead of Long-Term Credentials

In cloud environments, long-term access keys are a liability. They can be leaked, stolen, or accidentally committed. Use IAM roles instead. EC2 instances assume roles to access S3. Lambda functions assume roles to process DynamoDB streams. Human users assume roles for elevated access through single sign-on providers.

Data Protection

Encryption at Rest

All data stored in cloud services should be encrypted. Cloud providers offer key management services (KMS) for managing encryption keys. AWS KMS, Azure Key Vault, and Google Cloud KMS integrate with storage services to provide transparent encryption.

The recommended approach is envelope encryption: a master key (stored in KMS) encrypts data keys, which encrypt the actual data. This allows efficient key rotation — you rotate the master key, and the data keys are re-encrypted without re-encrypting the underlying data. Key rotation policies should enforce annual rotation at minimum.

Encryption in Transit

All network traffic should be encrypted with TLS 1.2 or higher. Load balancers terminate TLS and should use modern cipher suites. Internal traffic between services — VPC-to-VPC, service mesh traffic — should also use encryption, even within the provider’s network.

Data Classification

Not all data requires the same level of protection. Classify data by sensitivity — public, internal, confidential, restricted — and apply corresponding controls. Automated data classification tools scan cloud storage for patterns matching PII, financial data, or intellectual property and tag resources accordingly.

Network Security

Virtual Private Cloud Design

VPCs provide network isolation. Deploy resources in private subnets without direct internet access. Use NAT gateways for outbound traffic from private resources. Implement a hub-and-spoke topology with a centralized transit VPC for inspection of traffic between environments. AWS Transit Gateway or Azure Virtual WAN manage the hub-and-spoke routing.

Security Groups and Network ACLs

Security groups act as stateful firewalls at the instance level. They are the primary network security control in most cloud deployments. Network ACLs provide stateless filtering at the subnet level. The layered approach — security groups for instance-level control, NACLs for subnet-level guardrails — provides defense in depth.

Cloud WAF

Web application firewalls protect against OWASP Top 10 attacks. AWS WAF, Azure WAF, and Google Cloud Armor filter HTTP traffic for SQL injection, cross-site scripting, and common exploit patterns. Deploy WAF in front of load balancers and API gateways. Custom rules block traffic from known threat intelligence sources.

Compliance and Governance

Cloud compliance frameworks provide prescriptive controls. The CIS Benchmarks for AWS, Azure, and GCP define hundreds of configuration best practices. SOC 2, PCI DSS, HIPAA, and FedRAMP impose additional requirements.

Policy as Code

Use policy-as-code tools to enforce compliance continuously:

AWS Organizations Service Control Policies — define guardrails that prevent misconfiguration across all accounts.
Azure Policy — enforce tagging, location restrictions, and allowed resource types.
Google Cloud Organization Policies — restrict service usage and resource locations.

Security Posture Management

CSPM tools continuously assess the cloud environment against best practices. Wiz, Prisma Cloud, Check Point CloudGuard, and open-source tools like Prowler and ScoutSuite detect misconfigurations, excessive permissions, and policy violations. CSPM is essential for maintaining visibility across multi-cloud environments.

Cloud Workload Protection

Securing the workloads running in the cloud — containers, VMs, and serverless functions — requires specialized controls beyond configuration scanning.

Serverless Security

Serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) introduce unique security challenges. The attack surface shifts from infrastructure to code and dependencies. Each function has its own IAM role, environment variables, and third-party library dependencies. Security practices include:

Function permissions: scope IAM roles to the minimum resources each function needs. A function that only reads from S3 should not have DynamoDB write permissions.
Dependency scanning: use SCA tools to scan function dependencies for vulnerabilities. Lambda layers and container images used by functions should be scanned in the CI/CD pipeline.
Secrets injection: use environment variables with KMS encryption or parameter store references instead of hardcoded secrets. AWS Lambda supports encrypted environment variables that are decrypted at invocation.
Input validation: serverless functions exposed through API Gateway are internet-facing. Validate all input parameters to prevent injection attacks.

Container Security in the Cloud

Containers deployed to cloud services (Amazon EKS, Azure AKS, Google GKE) require runtime security beyond image scanning. Admission controllers (Kyverno, OPA Gatekeeper) enforce security policies at deployment time — blocking privileged containers, requiring read-only root filesystems, and enforcing resource limits. Runtime security tools (Falco, Aqua, Twistlock) monitor container behavior, detecting unexpected process execution, file system writes, or network connections that indicate compromise.

Frequently Asked Questions

What is the most common cloud security mistake?

Misconfigured access controls. Open S3 buckets, overly permissive IAM policies, and security groups allowing 0.0.0.0/0 ingress are the most frequently exploited misconfigurations. According to the Cloud Security Alliance, 90% of cloud security incidents involve customer-side misconfiguration.

How do I implement zero trust in the cloud?

Zero trust in the cloud means never trusting network location as a security control. Every request must be authenticated, authorized, and encrypted regardless of source IP. Implement with: IAM roles for all service-to-service communication, mTLS for service mesh, micro-segmentation with security groups, and continuous verification with CSPM tools.

Should I use a single cloud provider or multiple clouds?

Multi-cloud increases complexity but provides resilience against provider outages and enables best-of-breed service selection. Most organizations use a primary cloud provider with a secondary provider for disaster recovery. The security implication: multi-cloud requires consistent policy enforcement across different IAM models, logging formats, and compliance frameworks.

Conclusion

Cloud security architecture shifts from perimeter-based defense to identity-centric, data-aware protection. Strong IAM, ubiquitous encryption, automated security validation, and the shared responsibility model form the foundation. The organizations that succeed invest in automation, training, and continuous monitoring — treating cloud security as an engineering discipline rather than a compliance checkbox.

For a comprehensive overview, read our article on Cloud Security Guide.

For a comprehensive overview, read our article on Cybersecurity Beginners Guide.

Share this article

X LinkedIn Facebook Email