Cloud Security Best Practices 2025: AWS vs. Azure vs. GCP – Zero Trust, IAM, CSPM and the Shared Responsibility Model

Securing Cloud Infrastructure: Best Practices for AWS, Azure and GCP

Now that critical workloads are moving to the public cloud, security built around a fixed network perimeter (the "castle and moat" model) no longer works. This guide looks at how the responsibility models have changed and at the main security controls in Amazon Web Services, Microsoft Azure and Google Cloud Platform.

1. The Evolution: From Shared Responsibility to "Shared Fate"

Cloud security starts with knowing where the provider's (CSP's) responsibility ends and the customer's begins. Each platform draws that line differently:

AWS (Binary Model): AWS draws a strict line between "security of the cloud" (physical infrastructure, virtualization) and "security in the cloud" (operating system, data, firewalls). Customers get granular control but carry a heavy operational burden.
Azure (Layered Model): Responsibility shifts depending on the service model (IaaS, PaaS, SaaS). Identity and data always stay with the customer.
GCP (Shared Fate): Google takes an active role in its customers' security. It offers "opinionated architectures" and secure-by-default configurations, which takes some of the operational load off the customer.

Zero Trust Architecture

Whichever provider you use, a modern strategy calls for a Zero Trust model (NIST 800-207): verify continuously and never trust any component by default.

2. Identity (IAM): The New Security Perimeter

Identity is now the only perimeter that really works, and IAM misconfigurations are the leading cause of cloud incidents.

IAM Models Compared

Key Protection Strategies

Conditional Access: Check the context of each sign-in, such as the device and location. In Azure, for example, you can require phishing-resistant MFA for sign-ins from outside a trusted network. In AWS, you use Condition Keys in policies and the Verified Access service.
Eliminate long-lived keys: Use temporary credentials (STS in AWS, Managed Identities in Azure, Workload Identity Federation in GCP) instead of static key files.
CIEM (Cloud Infrastructure Entitlement Management): Use tools that find excess permissions and cut them back (rightsizing), so you avoid the "toxic combinations" that allow privilege escalation.

3. Network Security Engineering

Zero Trust doesn't make the network layer irrelevant. It is still a key part of a defense-in-depth strategy, protecting against lateral movement and data exfiltration.

Firewalls

AWS Security Groups: Security Groups are stateful, so they are easier to manage: return traffic for allowed connections gets through automatically. Network ACLs are stateless, so treat them only as a fallback.
Azure NSG & ASG: Application Security Groups (ASGs) let you write logical rules (for example, "AppServer to DBServer") without dealing with IP addresses.
GCP Firewall Rules: GCP can tie firewall rules to a machine's identity (its Service Account). Of the three, this comes closest to Zero Trust.

Preventing Data Exfiltration

One of the most effective controls in the cloud is GCP's VPC Service Controls. It draws a logical perimeter around API services such as BigQuery and Storage. Even with stolen credentials, an attacker cannot pull data from outside the trusted network. In AWS and Azure, use Private Link so that traffic to PaaS services stays inside the provider's private network.

4. Cryptography and Key Management (KMS)

How you manage encryption keys determines how much control you have over your data.

Platform Managed Keys: The provider manages the keys. They are convenient and free, but you have no control over rotation or access. They are a good fit for non-critical data.
Customer Managed Keys (CMK): You create the key in KMS and manage its policy. This makes "crypto-shredding" possible: delete the key and the data is effectively erased.
HYOK / EKM: The key is kept outside the cloud (for example, on-premises) for data sovereignty. Google EKM leads in this area.

Important: In Azure, always enable Soft Delete and Purge Protection on Key Vault to stop ransomware attacks from deleting your keys.

5. Automating Security Posture (CSPM)

Cloud environments are too large to check by hand, so you need guardrails.

Organizational Policies:
- AWS SCP: Blocks dangerous actions (such as disabling CloudTrail) across the whole organization, even for account administrators.
- Azure Policy: Can deny the creation of resources in regions that don't comply with GDPR.
- GCP Constraints: Predefined restrictions, such as blocking access to a VM's serial console.
CSPM Tools: AWS Security Hub, Microsoft Defender for Cloud and GCP Security Command Center, along with third-party tools such as Wiz and Orca, continuously check configurations against standards such as CIS and NIST and flag misconfigurations.

6. DevSecOps and Infrastructure as Code (IaC)

Security has to be built into the CI/CD pipeline (Shift-Left).

IaC Scanning: Tools such as Checkov, Prowler and Trivy analyze code (Terraform, K8s manifests) before deployment and block misconfigurations such as unencrypted disks.
Supply Chain Protection: Use hardened images (CIS Hardened Images) and scan container images in your registries for known CVEs.

Summary and Strategic Recommendations

A secure multi-cloud environment requires:

Treating identity as the foundation: strong authentication (FIDO2) and the principle of least privilege.
Automating CSPM: managing security by hand at cloud scale is not possible.
Adopting the Shared Fate model: use the patterns and architectures your platform provides rather than building your own from scratch.

Need Help with a Secure Cloud Migration?

If you are planning a move to AWS, Azure or GCP, need a security audit of your current cloud infrastructure, or want to implement a Zero Trust Architecture, get in touch. We'll help you design a secure multi-cloud architecture that meets NIS2, GDPR and ISO 27001 requirements.

What We Offer

Cloud Security Assessment - an audit of IAM configuration, network segmentation and encryption in AWS/Azure/GCP
Zero Trust Architecture Implementation - putting the NIST 800-207 model into practice in cloud environments
CSPM and Compliance Automation - setting up AWS Security Hub, Microsoft Defender for Cloud and GCP Security Command Center
Secure Cloud Migration - planning and running your migration while keeping the business running and staying compliant
Multi-Cloud Security Strategy - optimizing cost and security in mixed environments (AWS+Azure+GCP)
DevSecOps and IaC Scanning - building security into CI/CD (Terraform, Checkov, Prowler)

📧 Talk to a Cloud Security expert →

FAQ

What is the Shared Responsibility Model, and how does it differ between AWS, Azure and GCP?

The Shared Responsibility Model sets out which security tasks belong to the cloud service provider (CSP) and which belong to the customer. AWS (Binary Model): A clear split between "Security OF the Cloud" (AWS handles the physical infrastructure, the hypervisor and the network layer) and "Security IN the Cloud" (the customer handles the OS, applications, data, firewall and encryption). AWS gives you the most control but demands the most expertise. Azure (Layered Model): Responsibility shifts with the service model: in IaaS the customer manages the OS, in PaaS Azure manages the OS, and in SaaS Azure manages everything except data and users. Identity and data always remain the customer's responsibility. GCP (Shared Fate): Google promotes a "shared fate" model in which the provider takes an active part in the customer's security through "opinionated architectures" (secure-by-default configurations), lifting some of the operational burden. Key takeaway: Whatever the model, the customer is ALWAYS responsible for IAM, data and application configuration, and these are the most common sources of incidents.

What are the most common IAM misconfigurations in the cloud?

The most common IAM mistakes behind incidents: 1. Overprivileged identities: Granting AdministratorAccess/Owner instead of granular permissions. In AWS, this looks like IAM Users with PowerUserAccess. In Azure, it's overly broad roles at the Management Group level, which are inherited downward. In GCP, it's Service Accounts with the Editor role across the entire organization. 2. Long-lived access keys: AWS Access Keys that are never rotated (replace them with STS Temporary Credentials), Azure Service Principal secrets in code (use Managed Identities), and GCP Service Account JSON keys in repositories (use Workload Identity Federation). 3. Toxic combinations: Sets of permissions that allow escalation. In AWS, for example, iam:PutUserPolicy + iam:CreateAccessKey = the ability to create an admin. 4. No MFA: Accounts with console access but no multi-factor authentication. Phishing is the most common attack method. 5. No Conditional Access: Failing to enforce context (device compliance, trusted IPs) in Azure Entra ID or AWS Verified Access. Remediation: Use CIEM (Cloud Infrastructure Entitlement Management) tools such as AWS IAM Access Analyzer, Azure Entra Permissions Management and GCP Policy Intelligence to find and rightsize permissions.

What is CSPM, and why does it matter for NIS2 compliance?

CSPM (Cloud Security Posture Management) is a category of tools that automatically find security misconfigurations and track compliance with benchmarks such as CIS, NIST and ISO 27001. Why does it matter for NIS2? The NIS2 Directive (Article 8) requires entities to carry out continuous security monitoring and vulnerability management. In cloud environments that scale up and down constantly, with hundreds of AWS accounts or Azure subscriptions, manual audits are not possible. How CSPM works: It scans resource configurations (S3 buckets, Security Groups, NSGs, IAM policies) and flags risks such as unencrypted disks, public S3 buckets, overly permissive Security Groups (0.0.0.0/0 SSH) and disabled CloudTrail or logging. It also generates alerts and compliance reports. Tools: AWS Security Hub (integrates GuardDuty, Inspector and Macie), Microsoft Defender for Cloud (formerly Azure Security Center) and GCP Security Command Center. Third-party: Wiz, Orca Security and Prisma Cloud offer a unified view across multiple clouds. Best practice: Turn on CSPM on day one of your cloud migration. It catches 80% of the most common mistakes before they turn into incidents.

What is the difference between CMK and Platform Managed Keys?

Platform Managed Keys (PMK): The cloud provider generates and manages the encryption keys automatically. The customer has no control over the key's access policy, rotation or location. Pros: Free, no operational overhead, automatic rotation. Cons: No crypto-shredding (making data unreadable by deleting the key), no sovereignty (the key lives in the provider's infrastructure), and it doesn't meet some regulatory requirements (e.g., GDPR for sensitive data). Use cases: Non-critical data and dev/test environments. Customer Managed Keys (CMK): The customer creates the key in a KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) and controls the access policy (who can use the key), rotation and lifecycle. Pros: Crypto-shredding (deleting the key makes the data unreadable immediately), audit control (CloudTrail/Azure Monitor show who used the key and when), and compliance (NIS2, HIPAA, GDPR). Cons: Cost (AWS KMS: $1/key/month + $0.03 per 10k operations) and management overhead (rotation, backup). Use cases: Production data, PII, financial records and compliance-driven industries. HYOK/EKM (Bring Your Own Key): The key stays on-premises (e.g., in an HSM) and the provider never sees it. This gives maximum sovereignty, but at the highest cost and complexity. It suits sensitive sectors such as defense, intelligence and banking.

How do you implement a Zero Trust Architecture in the cloud?

Zero Trust in the cloud follows the principle of "never trust, always verify" and has to be implemented across four layers: 1. Identity: This is the foundation of Zero Trust. Enforce phishing-resistant MFA (FIDO2/WebAuthn, not SMS). Use Conditional Access (Azure) or Verified Access (AWS) to block access from unmanaged devices and untrusted IPs. Get rid of long-lived keys and use temporary credentials (AWS STS AssumeRole, Azure Managed Identities, GCP Workload Identity). Apply Just-in-Time access (PIM in Azure) so admin rights are granted only on request. 2. Device: Enforce device compliance (Microsoft Intune, Jamf) so that only managed devices can connect, and use Device Trust (Chrome Enterprise, Azure AD joined). 3. Network: Use microsegmentation and don't trust the internal network. In GCP, use Firewall Rules bound to Service Accounts rather than IPs. In AWS/Azure, use Application Security Groups (ASGs) instead of traditional Security Groups. Use VPC Service Controls (GCP) or Private Link (AWS/Azure) so that traffic to PaaS never leaves the private network. 4. Workload: End-to-end encryption, mutual TLS (mTLS) between services and Zero Trust workload security (Illumio, Google BeyondCorp). Tools: BeyondCorp (Google), Azure AD Conditional Access, AWS Verified Access, Palo Alto Prisma Access.

How do you secure a multi-cloud environment (AWS + Azure + GCP)?

A multi-cloud security strategy: 1. Unified identity plane: Centralize IAM through federation. Use a single identity provider (Azure Entra ID, Okta) as the single source of truth and configure SAML/OIDC federation to AWS (AssumeRoleWithSAML), Azure (native) and GCP (Workload Identity Federation). Benefit: One place to manage users, shared Conditional Access policies and easier offboarding. 2. Centralized logging and SIEM: Send logs from every cloud to a single SIEM (Splunk, Microsoft Sentinel, Chronicle): AWS CloudTrail + Azure Activity Log + GCP Cloud Audit Logs. The risk without it: No visibility into cross-cloud attacks, such as lateral movement from AWS to GCP using stolen credentials. 3. Unified CSPM: Use tools that cover all providers (Wiz, Orca, Prisma Cloud) instead of three separate ones (AWS Security Hub, Defender, SCC). You get one compliance dashboard and consistent policy enforcement. 4. Network isolation: Don't connect VPCs/VNets across clouds without segmentation and inspection. Use Cloud Interconnect (GCP), ExpressRoute (Azure) or Direct Connect (AWS) with firewalling (Palo Alto VM-Series, Fortinet). 5. Consistent tagging and policy: Use the same naming convention and tags (CostCenter, Environment, DataClassification) in every cloud. This makes automation and compliance tracking possible. 6. Cross-cloud disaster recovery: Don't assume any single cloud is a "safe haven". Keep a backup strategy in a second cloud (e.g., AWS RDS snapshots → Azure Blob cold storage).

What are the key network security differences between AWS, Azure and GCP?

Network models compared: AWS (Security Groups, stateful): Security Groups are virtual firewalls at the ENI (Elastic Network Interface) level. Stateful means return traffic is allowed automatically. Network ACLs are stateless (you have to allow responses explicitly) and are rarely used, mostly as a fallback. Use VPC Flow Logs to monitor traffic and Private Link to reach AWS services without going over the internet. Azure (NSG + ASG): Network Security Groups (NSGs) are also stateful, and Application Security Groups (ASGs) let you group VMs logically (e.g., "WebServers", "DBServers") and write rules without IPs ("Allow ASG:WebServers to ASG:DBServers port 3306"). Azure Firewall provides centralized inspection (OSI Layer 7). Private Endpoints cover PaaS services. GCP (Firewall Rules + VPC Service Controls): Firewall Rules can be bound to Service Accounts instead of IPs. This is the closest of the three to true Zero Trust, because the firewall works at the identity level rather than the network level. VPC Service Controls put a logical perimeter around managed services (BigQuery, Storage), so even stolen credentials won't let anyone pull data from outside the defined perimeter. Hierarchical Firewall Policies apply at the organization and folder level. Key differences: AWS/Azure follow a traditional model of IP-based rules plus private connectivity. GCP has the most advanced model, combining identity-based rules with Service Controls. Multi-cloud best practice: Use each cloud's native controls. Don't try to "unify" them behind a third-party firewall unless you actually need to.

How do you automate security in DevOps (DevSecOps)?

Shift-left security means building security into every stage of CI/CD rather than adding it at the end. 1. Pre-commit (IDE): Use linters and IDE plugins that detect secrets (git-secrets, TruffleHog) to keep credentials out of the repo, and run static code analysis (SonarQube, Semgrep) to catch vulnerabilities such as SQL injection and XSS. 2. Code repository (GitHub/GitLab): Secret scanning (GitHub Advanced Security, GitGuardian) automatically detects leaked API keys and passwords in commits and PRs. Dependency scanning (Dependabot, Snyk) finds vulnerabilities in libraries (npm, pip, Maven). 3. CI pipeline (build): IaC scanning (Checkov, Terraform Sentinel, CloudFormation Guard) blocks deployments with unencrypted S3 buckets or disks, Security Groups open to 0.0.0.0/0 on SSH, or buckets without MFA delete. Container scanning (Trivy, Anchore, built-in AWS ECR/Azure ACR scanning) finds CVEs in images before they are pushed to the registry. 4. CD pipeline (deploy): Policy-as-code (OPA – Open Policy Agent, Azure Policy, AWS Config Rules) enforces guardrails such as "deploy only to approved regions" or "every VM must have a CostCenter tag". DAST (Dynamic Application Security Testing) tools such as OWASP ZAP and Burp Suite scan the running application in staging. 5. Runtime (production): Runtime security (Falco, Aqua, Sysdig) detects anomalies in workloads, such as unauthorized process execution or file modification. Continuous CSPM (AWS Security Hub, Defender for Cloud, SCC) scans production 24/7. End-to-end tools: GitHub Advanced Security, GitLab Ultimate, Snyk, Aqua Security, Prisma Cloud.

Do small businesses need CSPM and advanced cloud security controls?

Yes. Even small businesses need at least basic CSPM, for four reasons: 1. Compliance requires it (NIS2/GDPR): NIS2 covers companies with 50 or more employees or annual turnover of EUR 10 million or more, so many SMBs fall within its scope. It requires continuous security monitoring and vulnerability management. Without CSPM, you have no evidence of compliance when an audit comes. 2. Default configurations are dangerous: Out of the box, the cloud is insecure by default: S3 buckets can be public, Security Groups can allow 0.0.0.0/0, and logging is turned off. The typical IT admin doesn't know every security control. CSPM catches these mistakes automatically. 3. The risk of a data breach is high: Ransomware-as-a-Service goes after everyone. A leaked S3 bucket full of customer data can mean a GDPR fine of up to 4% of global turnover, plus the damage to your reputation. 4. Low cost relative to the risk: AWS Security Hub costs $0.0010 per check (the first 10k checks per month are free), Microsoft Defender for Cloud has a free tier for basic posture management, and the GCP Security Command Center standard tier is free. The alternative: External security audits cost more ($5–20k per audit) and are one-off. Options for SMBs: Minimum setup (free): Turn on AWS Security Hub (free tier), Azure Defender for Cloud (free tier) and GCP SCC standard, enable logging (CloudTrail/Azure Monitor/Cloud Logging) and set up alerts for critical events (IAM changes, Security Group changes, public S3 buckets). Managed security (paid): Outsource to an MSSP that offers CSPM-as-a-Service (monitoring + remediation) for USD 500–2,000/month. Bottom line: For a small business, CSPM is the baseline, not a luxury. Going without it is like driving without a seatbelt.

How do you manage cloud security costs?

Cloud security costs come from four areas, and each one can be optimized: 1. Tooling: CSPM: AWS Security Hub ($0.001/check after the 10k free tier), Defender for Cloud ($15/server/month for advanced plans), Wiz/Orca ($$$$, enterprise pricing). Optimization: In small environments, use the free tiers of native tools instead of third-party vendors. Consolidate tools, with one SIEM instead of a separate one per cloud. Turn off security services you don't use, such as GuardDuty in regions where you have no resources. 2. Data and logging: CloudTrail, Azure Monitor Logs and GCP Cloud Logging produce gigabytes of logs every day. Keeping them for a year in S3/Blob/GCS costs thousands of USD a month. Optimization: Keep logs for 90 days in a hot tier and move long-term retention (1–7 years for compliance) to a cold/archive tier, which is 10x cheaper. Filter what you log; for example, enable S3 data events only for sensitive buckets. Use log aggregation and send only alerts to Splunk/Sentinel, not raw logs. 3. Encryption (KMS): AWS KMS costs $1/CMK/month + $0.03 per 10k API calls. 100 keys + 1 million operations = $130/month. Optimization: Reuse CMKs (one key for many resources of the same type), use envelope encryption (data key wrapping) instead of calling KMS directly for every operation, and use free Platform Managed Keys for non-critical data. 4. Personnel: Cloud security engineers are expensive ($100–200k/year). Optimization: Automate (SOAR, auto-remediation in Security Hub/Defender), outsource Tier 1/2 to an MSSP and keep only strategic Tier 3 work in-house, and train your existing IT team (AWS/Azure/GCP certifications) instead of adding headcount. Security ROI: According to IBM's 2024 report, the average data breach costs $4.88M. A well-configured CSPM + IAM + encryption setup costs $10–50k per year. That's a 100x ROI.

What are the best practices for disaster recovery in the cloud?

Cloud disaster recovery (DR) requires a strategy at four levels: 1. Defining RTO/RPO: RTO (Recovery Time Objective) is the maximum acceptable downtime: how long do you have to recover? RPO (Recovery Point Objective) is the maximum acceptable data loss: how old can the restored data be? Tier 1 (critical): RTO <1h, RPO <15min = expensive (multi-region active-active). Tier 2 (important): RTO <4h, RPO <1h = moderate cost (automated failover). Tier 3 (non-critical): RTO <24h, RPO <24h = inexpensive (manual restore from backups). 2. Backup strategy (the 3-2-1 rule): 3 copies of your data (production + 2 backups), on 2 different media (e.g., disk + tape/cold storage), with 1 copy off-site (another region or cloud). In the cloud: Take automated snapshots (EBS/Azure Disks/GCP Persistent Disks) every 6–12 hours, replicate across regions (S3 CRR, Azure GRS, GCP dual-region buckets), and use immutable backups (AWS Backup Vault Lock, Azure Immutable Blobs) to protect against ransomware. 3. Multi-region architecture: Active-Passive: Production runs in one region with a standby in another (Route53/Traffic Manager failover). Cost: Medium; RTO: 15–60 min. Active-Active: Production runs in 2+ regions at once (Global Load Balancer). Cost: High (double the resources); RTO: <5 min. Pilot Light: Minimal infrastructure in the DR region (only the database is replicated), and everything else starts on demand. Cost: Low; RTO: 1–4h. 4. DR testing: Run a full failover test at least twice a year, not just a backup restore. Tabletop exercise: Simulate a disaster (e.g., "the entire us-east-1 region is down") and have the team walk through the procedures. Automated testing: AWS Resilience Hub, Azure Site Recovery drills. Common mistakes: A DR plan that exists only on paper and has never been tested. Backups in the same region as production, so a regional outage wipes out everything. No offline documentation (how do you fail over if you can't reach the wiki that lives in the cloud?). Best practice: Keep one copy of your backups in a different cloud (AWS → Azure Blob Archive) for maximum resilience.