Cloud Security Compliance: AWS, Azure, and GCP Best Practices

Each cloud provider has a distinct security model, a different IAM architecture, and a different set of native compliance tooling. Treating AWS, Azure, and GCP as interchangeable compute substrates — and applying a single security policy uniformly across all three — is the root cause of most multi-cloud compliance failures. The misconfigurations are not random; they follow predictable patterns that map directly to the gaps between provider-specific controls and your compliance framework requirements.

This is a practical breakdown of what differs across the three major providers and where each one creates compliance blind spots that automated monitoring needs to fill.

AWS: The IAM Problem Is Worse Than You Think

AWS Identity and Access Management is the most flexible IAM system among the three major cloud providers. It is also the most misused. The fundamental issue is that AWS IAM supports three distinct attachment models — resource-based policies, identity-based policies, and permission boundaries — and the interactions between these layers are non-trivial. An engineer who understands identity-based policies may not understand how an S3 bucket policy can grant access that bypasses those policies entirely.

The compliance implications are significant. SOC 2 CC6.3 requires that access rights be assigned on a least-privilege basis. In AWS, least privilege is not a state you configure once — it is a property that degrades continuously as teams add permissions incrementally over months and years. The standard AWS Security Hub finding "IAM policies should not allow full '*:*' administrative privileges" catches the most egregious cases, but routine privilege creep — where a developer role accumulates permissions that are never revoked — does not trigger a Security Hub alert.

Three AWS-specific compliance controls worth automating:

• Unused IAM access key detection. AWS IAM credential reports are generated on demand, not continuously. Schedule automated credential report pulls every 24 hours and flag any access key that has not been used in 90 days. Keys that were generated for temporary use and never revoked are a persistent finding in AWS compliance audits.
• Service Control Policy (SCP) coverage. If you are using AWS Organizations, SCPs provide account-level guardrails that cannot be overridden by IAM policies within member accounts. Verify that your SCPs cover the six most common misuse patterns: preventing root account API key creation, blocking public S3 bucket policy changes, restricting VPC flow log disablement, preventing CloudTrail stop/delete, blocking public RDS snapshots, and restricting IMDSv1 usage.
• KMS key rotation compliance. AWS KMS customer-managed keys do not rotate by default. For keys protecting data subject to HIPAA, PCI DSS, or NIST guidelines, annual rotation is required. AWS Config has a managed rule (kms-cmk-rotation-enabled) that checks this, but the rule only evaluates at config change events — it does not alert on keys that should have rotated but have not been touched since they were created.

Azure: Conditional Access and the Identity Perimeter

Microsoft Azure's security model is fundamentally identity-first in a way that AWS and GCP are not. Azure Active Directory (now Microsoft Entra ID) is the control plane for everything — not just Azure resources, but Microsoft 365, Dynamics, and any third-party application connected via Azure AD B2B or B2C. This means that a misconfigured Conditional Access policy can have compliance implications that span far beyond your Azure subscription.

The most common Azure compliance gap is Conditional Access policy coverage. Organizations typically have a handful of well-configured policies protecting their most sensitive applications, and then a long tail of legacy conditional access configurations — or missing configurations — for lower-priority applications. SOC 2 CC6.7 and ISO 27001 Annex A.9.4 both require that access to systems processing sensitive data be protected by MFA. If your Azure AD has 200 enterprise applications and 30 of them lack conditional access enforcement, that is a compliance gap of measurable scope.

Azure-specific compliance controls worth monitoring continuously:

• Privileged Identity Management (PIM) adoption rate. Azure PIM implements just-in-time privileged access — users request elevated roles for a time-limited window rather than holding them permanently. Microsoft's own security benchmarks recommend that no user hold permanent Global Administrator, User Administrator, or Exchange Administrator assignments. Monitor the ratio of permanent to eligible role assignments in PIM. A ratio above 20% permanent is a compliance risk indicator.
• Legacy authentication protocol blocking. Legacy authentication protocols (SMTP AUTH, IMAP, POP3 with basic auth) bypass modern authentication and Conditional Access entirely. Microsoft has been progressively blocking these by default, but tenants migrated from older configurations may still have exceptions. Azure AD Sign-in logs filter on "Legacy Authentication Client" — any successful authentications using legacy protocols should generate compliance alerts.
• Guest account access reviews. Azure AD external collaboration (B2B guest accounts) accumulates over time in every organization with active partner relationships. Guest accounts that retain resource access after a project ends are a persistent GDPR and SOC 2 risk. Azure AD access reviews can automate the review cycle, but the reviews need to be configured — they are not enabled by default.

GCP: The Organization Policy Gap

Google Cloud Platform's compliance posture is shaped by a tension between its clean, hierarchical resource model and the default-open nature of many GCP services. GCP's resource hierarchy — organization, folders, projects — provides a clear structure for applying policies, but many GCP services are accessible externally by default unless Organization Policies explicitly restrict them.

The canonical example is Cloud Storage public access. In AWS, an S3 bucket must have public access explicitly granted through at least one of several mechanisms. In GCP, a Cloud Storage bucket created without an explicit uniform bucket-level access configuration may grant access to allUsers or allAuthenticatedUsers without triggering obvious warnings in the console. GCP's equivalent of AWS's S3 Block Public Access — the iam.allowedPolicyMemberDomains Organization Policy constraint — must be explicitly enabled at the organization level.

GCP-specific compliance controls to automate:

• Organization Policy constraint monitoring. GCP provides approximately 70 Organization Policy constraints covering everything from restricting resource location (for data residency compliance) to blocking external IP addresses on compute instances. Audit which constraints are enabled against a benchmark profile (CIS GCP Foundations Benchmark 1.3 is the standard starting point) and track drift continuously.
• Service account key age. GCP service accounts can have downloadable JSON key files associated with them. These key files are long-lived credentials that, once exported, are difficult to track or revoke. The GCP recommendation is to avoid service account keys entirely and use Workload Identity Federation instead. If keys exist, enforce a 90-day rotation policy and generate alerts for keys older than 30 days that have not been rotated.
• VPC Service Controls perimeter coverage. VPC Service Controls create a security perimeter around GCP APIs to mitigate data exfiltration risks. Not all projects need to be inside a perimeter, but projects handling regulated data (PHI, PII, cardholder data) should be. Map your project inventory against your data classification scheme and flag regulated-data projects that sit outside any service perimeter.

Cross-Cloud: Where Framework Requirements Get Complex

Compliance frameworks like SOC 2 and ISO 27001 were written before multi-cloud architectures were common. The control language is abstract enough to apply to any environment, but the evidence requirements for multi-cloud environments are additive — you need to demonstrate that each control is operating correctly across each cloud environment, not just in aggregate.

Three cross-cloud compliance challenges that require explicit attention:

Network traffic logging. All three providers support flow logging — VPC Flow Logs (AWS), NSG Flow Logs (Azure), and VPC Flow Logs (GCP). But the log formats differ, the APIs for retrieval differ, and the storage costs differ significantly. Centralizing flow logs from all three environments requires a normalization layer. Organizations that attempt to review flow logs in their native formats across three providers consistently report that the effort is high enough that review does not happen regularly — which means no evidence of network traffic review for the audit period.

Encryption key management. Each provider has its own KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS), and each has different defaults for which data is encrypted with customer-managed vs. provider-managed keys. For PCI DSS Requirement 3 or HIPAA encryption requirements, you need to document the encryption posture for data at rest across all three environments. This is harder than it sounds because encryption is applied at the resource level, not the environment level — an individual RDS instance, Azure SQL database, or GCP Cloud Spanner instance each has its own encryption configuration.

Identity federation boundaries. Most organizations use a single identity provider (Okta, Azure AD, or Google Workspace) federated to all three cloud environments. The federation itself introduces compliance requirements: you need to demonstrate that your IdP is the authoritative source for cloud access and that no accounts exist in the cloud environments without corresponding IdP identities. AWS IAM Identity Center, Azure AD SAML federation, and GCP Workforce Identity Federation each implement this differently, and the audit trail for access grants looks different in each.

Building a Unified Compliance View

The practical challenge for security teams is that native compliance tooling is provider-specific. AWS Security Hub understands AWS resources. Microsoft Defender for Cloud understands Azure. GCP Security Command Center understands GCP. None of them are designed to give a unified compliance status across all three environments simultaneously.

Building that unified view requires two things: a normalized data model for security findings and a control-mapping layer that translates provider-specific findings into framework control language. When AWS Security Hub reports "S3 bucket server-side encryption not enabled," that finding maps to ISO 27001 A.10.1.1 (cryptographic controls policy), PCI DSS 3.5 (protect stored cardholder data), HIPAA §164.312(a)(2)(iv) (encryption and decryption), and SOC 2 CC6.1 (logical access to assets). The same normalization needs to happen for every finding from every provider.

Once findings are normalized, you can produce a cross-cloud compliance status by framework in real time — not a quarterly snapshot, but a live dashboard showing which controls are passing, which are failing, and which are untested across your entire cloud estate.

That is the difference between having cloud security tools and having a cloud security compliance program. The tools are not the program. The unified view is the program.