Cloud Security Assessments: What to Test in AWS, GCP, and Azure Before Something Goes Wrong

If your organization runs workloads in AWS, GCP, or Azure, there is a statistically overwhelming chance that something is misconfigured right now. This is not an exaggeration. Industry research consistently finds that over 90% of organizations have cloud misconfigurations, and that misconfiguration is the leading cause of cloud data breaches. The defaults are not secure. The shared responsibility model means your cloud provider secures the physical infrastructure, the hypervisor, and the network fabric. Everything above that line is on you.

Most teams don't have dedicated cloud security expertise. They have engineers who are very good at building things and shipping features, but who learned cloud infrastructure on the job and inherited configurations from whoever set up the account three years ago. A cloud security assessment exists to find the gaps before an attacker or an auditor does.

Your cloud is probably misconfigured (and that's normal)

The numbers are stark. Gartner has projected that through 2025, 99% of cloud security failures would be the customer's fault. Multiple breach analysis reports from the past two years confirm this trend is holding. The most common root causes are not sophisticated attacks. They are storage buckets left open to the public, IAM policies granting wildcard access, logging services that were never turned on, and security groups that allow the entire internet to reach sensitive ports.

The shared responsibility model is conceptually simple but operationally confusing. AWS secures the infrastructure. You secure what you deploy on it. Azure secures the physical data centers. You secure your virtual machines, identity configuration, and data. GCP secures the global network. You secure your project-level IAM, your Cloud Storage permissions, and your firewall rules.

The problem is that "you secure it" is doing an enormous amount of heavy lifting. Cloud providers offer hundreds of services, each with their own permission models, encryption options, and networking configurations. A single AWS account might use EC2, S3, RDS, Lambda, ECS, API Gateway, CloudFront, and a dozen other services. Each one has security-relevant settings. Each one can be misconfigured independently. And the defaults are almost always optimized for ease of use, not security.

What a cloud security assessment actually covers

A cloud security assessment is not a traditional penetration test. A pentest focuses on exploitation: can an attacker break in, move laterally, and access sensitive data? A cloud security assessment is broader. It reviews your configuration, your architecture, and your operational practices against established benchmarks like CIS Benchmarks and cloud provider best practices.

The assessment typically covers eight major domains:

• IAM policies and identity management: Who can access what, how are permissions structured, and are there unused or over-permissioned accounts?
• Network architecture: How are your VPCs, subnets, security groups, and firewall rules configured? Is there proper segmentation between environments?
• Storage permissions: Are your S3 buckets, GCS buckets, or Azure Blob containers properly restricted? Is public access disabled where it should be?
• Encryption configuration: Is data encrypted at rest and in transit? Are you managing your own keys or using provider-managed keys, and is that decision intentional?
• Logging and monitoring: Is CloudTrail, Cloud Audit Logs, or Azure Monitor enabled and configured correctly? Are logs being sent to a tamper-proof destination?
• Secrets management: Are API keys, database credentials, and certificates stored in a secrets manager, or are they hardcoded in environment variables and config files?
• Container security: If you're running ECS, EKS, GKE, or AKS, are your container images scanned, are pods running as root, and are there network policies in place?
• Serverless function security: Are your Lambda functions, Cloud Functions, or Azure Functions using least-privilege execution roles, and are they exposing sensitive data in environment variables?

The output is not a list of exploitable vulnerabilities. It's a prioritized report of configuration weaknesses, architectural risks, and compliance gaps, with specific remediation guidance for each finding.

The IAM problem: over-permissioned everything

If there is one finding we see in virtually every cloud security assessment, it's this: IAM policies are too permissive. It is the single most common and most dangerous class of cloud misconfiguration, and it exists because granting broad access is easy while scoping precise permissions is tedious.

The patterns repeat across every provider and every engagement:

• Wildcard policies: IAM policies with Action: "*" and Resource: "*", granting full administrative access to every service in the account. These often exist because an engineer needed to "get something working" during development and never scoped the policy down.
• Unused IAM roles: Service accounts and roles that were created months or years ago for a specific project that no longer exists. They still have permissions. They are still valid credentials. They are attack surface.
• Service accounts with admin privileges: Application service accounts running with the equivalent of root access when they only need to read from a single S3 bucket or write to a single database.
• Root or owner account used for daily work: The AWS root account or GCP organization owner used for routine tasks instead of being locked away with MFA and only used for account-level operations.
• MFA not enforced on privileged accounts: Administrative IAM users without multi-factor authentication. This is the simplest security control to implement and one of the most frequently skipped.
• Cross-account access without guardrails: IAM roles that allow access from other AWS accounts or GCP projects without condition keys, IP restrictions, or external ID requirements.

The fix is not complicated in theory: implement least privilege. In practice, it requires auditing every IAM policy, analyzing actual usage patterns (AWS IAM Access Analyzer, GCP IAM Recommender, and Azure AD access reviews help here), and scoping permissions down to what each principal actually needs. It's tedious work, but it eliminates the most common path an attacker uses to escalate from initial access to full account compromise.

Storage misconfigurations that lead to breaches

Cloud storage breaches make headlines with predictable regularity. A major financial institution lost over 100 million customer records because of a misconfigured WAF and overly permissive IAM role that allowed access to S3 buckets containing sensitive data. A major gaming and streaming platform had its entire source code and internal tools exposed through a misconfigured server that provided access to cloud storage. These are not obscure companies with underfunded security teams. They are well-resourced organizations that still got the basics wrong.

The storage misconfigurations we find most frequently include:

• Public access enabled: S3 buckets, GCS buckets, or Azure Blob containers with public access enabled, sometimes intentionally (for static website hosting) and sometimes accidentally (because the default was changed during troubleshooting and never reverted).
• Missing encryption at rest: Storage containing sensitive data that is not encrypted with a customer-managed key. Provider-managed encryption is often enabled by default, but for compliance purposes (SOC 2, ISO 27001, HIPAA), customer-managed keys with proper rotation policies are typically required.
• No access logging: S3 server access logging, GCS audit logs, or Azure Storage analytics not enabled. Without access logs, you have no way to know who accessed what data, when, or from where. If a breach occurs, you have no forensic trail.
• Overly permissive bucket policies: Bucket policies that grant access to Principal: "*" or use conditions that are too broad. A policy that allows any authenticated AWS user to read your bucket is effectively public to anyone with an AWS account.
• No lifecycle policies for sensitive data: Sensitive data stored indefinitely without retention policies. Data that should be deleted after 90 days sits in buckets for years, expanding your breach radius and your compliance exposure.

All three major providers now offer account-level settings to block public access to storage (S3 Block Public Access, GCS Uniform Bucket-Level Access, Azure Storage account public access settings). These should be enabled at the account or organization level and only overridden for specific, documented use cases like public static asset hosting.

Network and VPC security

Cloud networking is where traditional infrastructure security concepts meet cloud-specific abstractions, and the result is a configuration surface that most teams don't fully understand. The most common network security findings in cloud assessments fall into predictable categories.

Security groups allowing 0.0.0.0/0 on sensitive ports. We find this in nearly every assessment. SSH (port 22), RDP (port 3389), database ports (3306, 5432, 27017), and sometimes even administrative interfaces wide open to the entire internet. The security group was created during development, the engineer added 0.0.0.0/0 to test connectivity, and it was never scoped down.

Default VPC usage. AWS creates a default VPC in every region with default subnets that auto-assign public IP addresses. Running production workloads in the default VPC is a common anti-pattern because the default configuration prioritizes convenience over security. Production environments should use custom VPCs with intentional subnet design, private subnets for backend services, and public subnets only for load balancers and bastion hosts.

No network segmentation. Development, staging, and production environments running in the same VPC or project with no network-level isolation. A compromised development workload can reach production databases because there's no boundary between them.

Public-facing resources that should be private. Databases, caches, and internal APIs with public IP addresses or internet-facing load balancers when they should only be accessible from within the VPC. This is often a result of "it works" engineering where the path of least resistance was to make the resource publicly accessible.

Missing VPC flow logs. VPC Flow Logs (AWS), VPC Flow Logs (GCP), and NSG Flow Logs (Azure) provide network-level visibility into traffic patterns. Without them, you cannot detect lateral movement, unusual traffic patterns, or data exfiltration. They are essential for incident response and compliance, but they are not enabled by default.

Access patterns for administration. Bastion hosts with SSH open to the internet instead of using AWS Systems Manager Session Manager, GCP Identity-Aware Proxy, or Azure Bastion for secure administrative access without exposing management ports.

Logging, monitoring, and the gaps nobody checks

Logging is the security control that everyone agrees is important and nobody verifies is working correctly. In a cloud security assessment, we consistently find that logging is partially configured, meaning it is enabled in some regions but not all, or it is logging to a destination that can be tampered with, or it is not being monitored for suspicious activity.

CloudTrail not enabled in all regions. AWS CloudTrail can be configured as a single-region trail or an all-regions trail. A single-region trail only captures API calls made in that specific region. If an attacker creates resources in a region you're not logging, you won't see it. Multi-region trails should be the default, and they should be logging to a dedicated, restricted S3 bucket with object-level logging enabled.

Logs not sent to a tamper-proof destination. If CloudTrail logs are stored in an S3 bucket in the same account, an attacker who compromises that account can delete the logs. Best practice is to send logs to a separate logging account with a bucket policy that prevents deletion, or to use CloudTrail Lake or a SIEM integration that provides immutable storage.

No alerting on critical events. Logging without alerting is forensics preparation, not security monitoring. At minimum, you should have alerts for root account usage, IAM policy changes, security group modifications, unauthorized API calls, and console logins from unusual locations. AWS CloudWatch Alarms, GCP Cloud Monitoring, and Azure Monitor can all be configured for these use cases, but they rarely are by default.

Logs not retained long enough for compliance. SOC 2 typically requires one year of audit log retention. ISO 27001 requires log retention appropriate to your risk assessment. Many cloud accounts have default log retention of 90 days or less. If an auditor asks for logs from eight months ago and they've been deleted, that's a compliance finding.

Cloud security by provider

Each cloud provider implements security controls differently. The following comparison maps equivalent services and highlights common pitfalls specific to each platform. Understanding these differences matters when your assessment covers multi-cloud environments or when you're evaluating which provider-native tools to enable.

A cross-provider pattern worth noting: every cloud provider offers a built-in security posture assessment tool (Security Hub, Security Command Center, Defender for Cloud). These tools are often available at no additional cost for basic functionality, yet we frequently find them disabled or unreviewed. Enabling these tools and addressing their high-severity findings is one of the highest-value, lowest-effort improvements you can make.

When to run a cloud security assessment

A cloud security assessment is not a one-time exercise. Your cloud environment changes constantly. New services are deployed, new team members make configuration changes, and new features introduce new security surface. The right cadence depends on your rate of change and your compliance requirements, but there are specific inflection points where an assessment is especially valuable.

After initial cloud migration. You've moved workloads from on-premises or from another provider. The migration was focused on functionality: does everything work? Security configuration was secondary. An assessment immediately after migration catches the shortcuts and compromises that were necessary to hit the migration deadline.

Before a SOC 2 or ISO 27001 audit. Auditors will ask about your cloud security controls. An assessment gives you a chance to find and fix issues before the auditor finds them for you. A finding in your own assessment is a remediation item. A finding in an audit report is a qualification or exception that your customers will see.

After major architecture changes. You moved from EC2 to ECS. You added a new region. You implemented a multi-account strategy. You adopted Terraform or Pulumi for infrastructure as code. Any significant architectural change introduces new configuration that may not match your security baseline.

After a security incident. If you've experienced a breach, a near-miss, or even a suspicious event that turned out to be benign, an assessment validates that the root cause has been addressed and identifies other weaknesses that could lead to similar incidents.

Annually as a baseline. Even without a specific trigger, annual cloud security assessments establish a baseline and track your security posture over time. They're also a common requirement for compliance frameworks and investor due diligence.

After onboarding new infrastructure team members. A new DevOps engineer or platform team member will make configuration changes based on their experience and preferences. An assessment a few months after onboarding validates that those changes align with your security requirements, and it's a non-confrontational way to verify that institutional knowledge was transferred correctly.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.