Cloud Security Audit: Evaluating AWS, Azure, and GCP Environments

Cloud security audits examine the configuration, access controls, logging, and compliance posture of infrastructure hosted on Amazon Web Services, Microsoft Azure, and Google Cloud Platform — the three providers that collectively hold the dominant share of enterprise cloud workloads in the United States. Audit scope spans identity federation, network segmentation, encryption key management, data residency, and the contractual division of security responsibilities under each provider's shared responsibility model. Regulatory frameworks including FedRAMP, NIST SP 800-53, PCI DSS, HIPAA Security Rule, and SOC 2 each impose distinct evidence requirements when cloud environments are in scope. This reference describes the service landscape, audit structure, classification boundaries, and control domains that define cloud security audit practice.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Audit Phase Sequence
• Reference Table: Control Domain Coverage by Provider

Definition and Scope

A cloud security audit is a structured examination of cloud-hosted infrastructure and services against a defined control framework, producing documented evidence of compliance, gap identification, and risk-rated findings. The audit population extends beyond virtual machines to encompass managed services — object storage (AWS S3, Azure Blob Storage, GCP Cloud Storage), serverless functions, container orchestration platforms (EKS, AKS, GKE), and database-as-a-service offerings — each of which carries distinct configuration risk profiles.

Scope boundaries are established through a cybersecurity audit scope definition process that maps cloud account structure, organizational units, landing zones, and data classification tiers before fieldwork begins. AWS organizes resources under accounts grouped in AWS Organizations; Azure uses management groups, subscriptions, and resource groups; GCP uses organizations, folders, and projects. An audit that does not align to this hierarchy will miss resource-level controls applied outside the primary console view.

The Shared Responsibility Model — published separately by AWS, Azure, and GCP — defines which security obligations belong to the provider and which belong to the customer. Auditors must operationalize that boundary: provider-managed controls (physical datacenter security, hypervisor patching) are typically satisfied through the provider's own compliance reports (SOC 2 Type II, ISO 27001 certificates, FedRAMP ATOs), while customer-managed controls require direct evidence collection from the customer's tenant configuration.

Core Mechanics or Structure

Cloud security audits are structured around five control domains applicable across all three major providers: identity and access management, network security, data protection, logging and monitoring, and configuration compliance.

Identity and Access Management (IAM): AWS IAM, Azure Entra ID (formerly Azure Active Directory), and GCP IAM each implement role-based and attribute-based access control. Auditors examine root/owner account usage, service account key rotation, least-privilege policy adherence, multi-factor authentication enforcement, and federation configurations. The identity and access management audit discipline and privileged access audit frameworks provide the primary control criteria.

Network Security: Virtual Private Clouds (AWS VPC), Virtual Networks (Azure VNet), and VPC Networks (GCP) define the perimeter. Auditors evaluate security group rules and network ACLs for overly permissive ingress (0.0.0.0/0 on port 22 or 3389 is a recurring finding), peering configurations, private endpoint adoption, and firewall policy inheritance.

Data Protection: Object storage bucket policies are among the highest-frequency misconfiguration findings across providers. Key Management Service configurations (AWS KMS, Azure Key Vault, Cloud KMS on GCP) are examined for key rotation schedules, access policy separation, and hardware security module (HSM) usage where regulatory mandates apply.

Logging and Monitoring: AWS CloudTrail, Azure Monitor / Diagnostic Settings, and GCP Cloud Audit Logs must be enabled across all regions and organizational units, with logs forwarded to immutable storage or a SIEM. NIST SP 800-92 (NIST Guide to Computer Security Log Management) defines retention and integrity requirements that apply regardless of provider.

Configuration Compliance: Provider-native tools — AWS Security Hub (aggregating findings from AWS Config, Amazon GuardDuty, and Amazon Inspector), Microsoft Defender for Cloud, and GCP Security Command Center — produce benchmark compliance scores against CIS Benchmarks and provider security foundations. Auditors validate that these tools are enabled, findings are tracked to remediation, and suppression rules are documented.

Causal Relationships or Drivers

Misconfigured cloud resources, not provider infrastructure failures, account for the predominant category of cloud security incidents. The Cloud Security Alliance's Cloud Controls Matrix (CCM) attributes the majority of cloud breaches to customer-side misconfigurations — a structural pattern driven by the speed of infrastructure provisioning, infrastructure-as-code template reuse, and insufficient separation between development and production environments.

Regulatory mandates are the primary external driver of formal cloud security audit engagements. FedRAMP (FedRAMP Authorization Act, enacted 2022) requires a cloud service offering used by a federal agency to hold an Authorization to Operate (ATO) based on NIST SP 800-53 Rev 5 controls — 325 base controls at the High baseline. HIPAA Security Rule (45 CFR §164.308–312) requires covered entities to evaluate cloud business associate configurations. PCI DSS v4.0 (published by the PCI Security Standards Council) extends cardholder data environment scope explicitly to cloud-hosted components.

Multi-cloud adoption increases audit complexity proportionally: organizations operating across AWS and Azure simultaneously cannot rely on a single native tool set and must either deploy a cloud security posture management (CSPM) platform spanning both environments or run parallel audit workstreams.

Classification Boundaries

Cloud security audits are classified along three primary axes:

By Engagement Type: Compliance audits test controls against a named framework (SOC 2, FedRAMP, PCI DSS). Configuration audits assess technical posture independent of a compliance framework. Penetration-test-augmented audits combine configuration review with adversarial technique simulation — a distinction examined in cybersecurity audit vs penetration testing.

By Provider Scope: Single-provider audits examine one AWS organization, one Azure tenant, or one GCP organization. Multi-cloud audits span 2 or more providers and require normalized control mapping. Hybrid audits extend scope to on-premises infrastructure connected via Direct Connect, ExpressRoute, or Cloud Interconnect.

By Service Model: Infrastructure-as-a-Service (IaaS) audits assess operating system and application-layer controls the customer fully manages. Platform-as-a-Service (PaaS) audits focus on configuration of managed services where the provider handles OS patching. Software-as-a-Service (SaaS) audits — when the SaaS runs on one of the three major clouds — examine tenant isolation, API permissions, and OAuth token scope, rather than infrastructure controls.

Tradeoffs and Tensions

Native Tooling vs. Third-Party CSPM: AWS Security Hub, Microsoft Defender for Cloud, and GCP Security Command Center offer deep integration with their respective ecosystems but produce non-normalized finding formats. Third-party CSPM platforms normalize findings across providers but introduce an additional access permission surface that must itself be audited.

Agility vs. Control: Infrastructure-as-code pipelines (Terraform, AWS CloudFormation, Azure Bicep) enable rapid resource provisioning but propagate misconfigurations at scale if policy guardrails (AWS Service Control Policies, Azure Policy, GCP Organization Policies) are not applied upstream of deployment. Auditors must evaluate the pipeline, not just the deployed state — a scope expansion that increases fieldwork effort and is frequently contested during scope negotiations.

Immutability vs. Accessibility: Enabling immutable logging satisfies audit integrity requirements but creates operational friction for log storage cost management. S3 Object Lock, Azure Immutable Blob Storage, and GCP Bucket Lock enforce write-once configurations; audit evidence must confirm these features are active and retention periods match regulatory minimums.

Provider Compliance Reports as Audit Substitutes: Organizations sometimes assert that AWS, Azure, or GCP SOC 2 Type II reports satisfy all audit requirements for cloud infrastructure. Provider reports cover only provider-managed controls; they do not evaluate customer tenant configuration. This substitution error is one of the most consequential misunderstandings in the sector.

Common Misconceptions

Misconception: A cloud provider's SOC 2 certification covers the customer's deployment.
Correction: Provider SOC 2 reports, ISO 27001 certificates, and FedRAMP ATOs address provider-managed infrastructure. Customer IAM policies, bucket permissions, encryption configurations, and logging settings are outside provider certification scope.

Misconception: Default cloud configurations are secure.
Correction: AWS, Azure, and GCP default settings are optimized for usability and ease of adoption, not for production security posture. Default S3 bucket configurations prior to 2023 permitted public access unless explicitly blocked. Default Azure storage accounts did not enforce HTTPS-only access without explicit configuration. Auditors cannot accept defaults as evidence of control satisfaction.

Misconception: Cloud security audits only apply to large enterprises.
Correction: PCI DSS, HIPAA, and state-level data protection laws apply based on data type and volume, not organization size. A 15-person healthcare SaaS company storing protected health information on AWS has the same HIPAA Security Rule obligations as a hospital system.

Misconception: Enabling a provider's security dashboard constitutes a completed audit.
Correction: Security Command Center, Defender for Cloud, and Security Hub are continuous monitoring tools, not audit substitutes. Audit practice requires independent evidence collection, control testing, and documented findings — as described in cybersecurity audit process phases.

Audit Phase Sequence

The following phase sequence reflects the operational structure of a cloud security audit engagement across AWS, Azure, or GCP environments. This is a descriptive reference, not prescriptive instruction.

1. Scope Definition — Document account/tenant/project hierarchy, data classification, regulatory frameworks in scope, and shared responsibility boundary for each service in use.
2. Access Provisioning — Establish read-only auditor access using provider-native roles: AWS SecurityAudit managed policy, Azure Security Reader role, GCP Security Reviewer role.
3. Configuration Baseline Pull — Export current configuration state using AWS Config snapshots, Azure Resource Graph queries, or GCP Asset Inventory. Capture IAM policy documents, network ACLs, storage bucket policies, and logging configurations.
4. Control Testing — Test each control against framework criteria. For CIS Benchmark alignment, compare findings against CIS Benchmarks for AWS, Azure, and GCP — published separately for each provider, with version-specific pass/fail criteria.
5. Logging and Monitoring Validation — Confirm CloudTrail/Diagnostic Settings/Audit Logs are enabled in all active regions, with integrity validation active and retention meeting the applicable regulatory minimum (PCI DSS v4.0 requires 12 months of log availability).
6. Findings Documentation — Classify findings by severity (Critical, High, Medium, Low) with control reference, evidence artifact, and risk narrative. Structure follows cybersecurity audit report structure conventions.
7. Remediation Tracking — Each finding is assigned ownership, target remediation date, and compensating control documentation where applicable. See cybersecurity audit findings remediation.
8. Closure and Evidence Archive — Final report package includes configuration snapshots, tool output artifacts, and auditor attestation, archived in accordance with applicable retention requirements.

Reference Table: Control Domain Coverage by Provider

References

• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems
• NIST SP 800-92 — Guide to Computer Security Log Management
• NIST SP 800-57 — Recommendation for Key Management
• FedRAMP Program Office — Authorization Documentation
• PCI Security Standards Council — PCI DSS v4.0
• Cloud Security Alliance — Cloud Controls Matrix (CCM)
• CIS Benchmarks for AWS, Azure, and GCP
• AWS Shared Responsibility Model
• Microsoft Azure Shared Responsibility
• Google Cloud Shared Responsibility Model
• HHS HIPAA Security Rule — 45 CFR §164.308–312
• FedRAMP Authorization Act — Division W of the James M. Inhofe NDAA FY2023