Cloud Misconfigs: Top 10 AWS and GCP Mistakes

TL;DR: Cloud misconfigurations cause 82% of all cloud security incidents according to IBM's 2024 Cost of a Data Breach report. In our audits across AWS and GCP environments, we find the same ten mistakes repeated in nearly every engagement. Fixing them requires process changes, not expensive tooling, and prevents the average $4.88 million breach cost.

Why Do Cloud Misconfigurations Keep Happening?

Cloud providers ship hundreds of services, each with dozens of configuration parameters. AWS alone has over 300 services with thousands of IAM permission actions. GCP's resource hierarchy adds project-level, folder-level, and organization-level policies that interact in ways most teams never fully map. The result is a configuration surface so large that manual review cannot keep pace with deployment speed.

We see this in every engagement. Teams that write excellent application code deploy it into cloud environments configured by default settings, copy-pasted Terraform modules, or stack overflow answers from 2021. The infrastructure gets less scrutiny than the code running on it. According to Gartner's forecast, through 2027 at least 99% of cloud security failures will be the customer's fault, not the provider's (Gartner, 2023).

The core problem is not technical complexity. It is organizational. Cloud infrastructure is provisioned by developers, managed by platform teams, audited by security teams, and governed by compliance teams. Each group sees a partial view. Nobody sees the full picture unless they deliberately build visibility across all four perspectives.

When we run our cybersecurity scanning service against new cloud environments, we categorize findings into ten recurring patterns. Every environment has at least three. Most have six or more. Here they are, ordered by frequency of occurrence.

1. Are Your S3 Buckets and GCS Buckets Actually Private?

Public storage buckets remain the single most common cloud misconfiguration we encounter. Despite years of high-profile data exposures, we still find publicly readable buckets containing database backups, application logs, customer PII, and API credentials in roughly 35% of first-time audits.

AWS introduced S3 Block Public Access at the account level in 2019. GCP added uniform bucket-level access as a default for new projects in 2023. Both features exist. Both require explicit activation on existing resources. The gap between new-account defaults and existing infrastructure is where breaches happen.

The Verizon 2024 Data Breach Investigations Report found that misconfigured cloud storage was a contributing factor in 21% of breaches involving cloud assets (Verizon DBIR, 2024). Capital One's 2019 breach, which exposed 106 million records through a misconfigured WAF and overly permissive S3 access, remains the most cited example. But smaller, unreported exposures happen weekly.

The fix is two commands. For AWS: enable S3 Block Public Access at the account level and apply it retroactively to all existing buckets. For GCP: enable uniform bucket-level access and remove allUsers and allAuthenticatedUsers from IAM bindings. Then add a preventive control: an AWS SCP or GCP Organization Policy that denies public bucket creation entirely.

2. How Dangerous Is Overly Permissive IAM?

IAM misconfigurations are the second most frequent finding and the most dangerous by impact. A single overly permissive IAM role can turn a minor application vulnerability into a full account compromise.

The pattern we see constantly: developers create IAM roles during prototyping with AdministratorAccess (AWS) or roles/owner (GCP) attached, intending to scope them down later. "Later" never arrives. The role moves to staging, then production, carrying full administrative privileges through every environment. CrowdStrike's 2025 Global Threat Report found that identity-based attacks increased 583% year-over-year, with cloud IAM credential theft as the primary vector (CrowdStrike, 2025).

In AWS, the principle of least privilege means using IAM Access Analyzer to identify unused permissions and progressively tightening policies. In GCP, IAM Recommender serves the same function, suggesting reduced permission sets based on actual usage patterns over the past 90 days.

Start with service accounts. Every Lambda function, every Cloud Run service, every EC2 instance should have a dedicated IAM role with only the permissions it demonstrably needs. Shared roles across services create blast radius problems. When one service is compromised, the attacker inherits the union of all permissions assigned to that shared identity.

3. Is Your Network Segmentation Actually Enforced?

Flat networks in cloud environments are the third most common finding. Teams deploy VPCs and subnets but fail to enforce segmentation between tiers. The database accepts connections from the public internet. The admin panel is on the same subnet as the customer-facing API. Internal microservices communicate without authentication because "they're on the private network."

In AWS, we regularly find Security Groups with 0.0.0.0/0 ingress rules on ports 22, 3389, 3306, 5432, and 27017. Each one is an open invitation to brute force attacks or exploitation of unpatched database services. In GCP, firewall rules with 0.0.0.0/0 source ranges on default networks appear in the majority of environments we scan.

The Sophos 2024 Threat Report found that exposed RDP and SSH services accounted for 56% of initial access in cloud compromise incidents examined (Sophos, 2024). Attackers scan the entire IPv4 space in under 45 minutes using tools like Masscan. If your port is open, it will be found.

Remediation is straightforward. Replace broad CIDR ranges with specific IP allowlists. Move databases to private subnets with no internet gateway. Use AWS PrivateLink or GCP Private Service Connect for inter-service communication. Deploy a bastion host or use AWS Systems Manager Session Manager for administrative access, removing the need for SSH entirely.

4. Are Your Encryption Settings Actually Protecting Data?

Encryption at rest is enabled by default in most AWS and GCP services, but the default configuration often uses provider-managed keys that offer compliance coverage without meaningful security differentiation. The real issue is encryption in transit and key management practices.

We find three recurring problems. First, internal service-to-service communication over HTTP instead of HTTPS. Teams assume that traffic within a VPC is inherently secure. It is not. Any compromised instance on the same network segment can sniff unencrypted traffic. Second, customer-managed encryption keys (CMEK) that are never rotated. AWS KMS and GCP Cloud KMS both support automatic key rotation, but it must be explicitly configured. Third, EBS volumes and Persistent Disks attached to terminated instances that retain decrypted snapshots accessible to anyone with console access.

According to the IBM Cost of a Data Breach 2024 report, organizations using encryption extensively reduced their average breach cost by $237,000 compared to those with partial or no encryption deployment (IBM Security, 2024). That is a direct, measurable return on a configuration change.

Enforce HTTPS everywhere, including internal traffic. Enable automatic key rotation on all KMS keys. Use AWS Config rules or GCP Organization Policies to prevent the creation of unencrypted storage volumes. These are policy-level controls that apply automatically to every new resource.

5. What Logging Gaps Are Hiding Active Breaches?

Insufficient logging is the finding that concerns us most, because it means we cannot determine whether a breach has already occurred. If CloudTrail is disabled, if VPC Flow Logs are not captured, if GCP Audit Logs are not exported to a persistent destination, then an attacker who gained access last month could still be inside the environment with no evidence to trace.

We find CloudTrail disabled on secondary AWS accounts in roughly 25% of multi-account environments. GCP data access audit logs are disabled by default for most services and must be enabled per-service or via organization policy. Without them, API calls that read sensitive data leave no trace.

The Mandiant M-Trends 2024 report found that the global median dwell time for intrusions was 10 days, but organizations without centralized logging had a median dwell time of 45 days or more (Mandiant, 2024). The difference is visibility. You cannot detect what you do not log.

Enable CloudTrail in every AWS account and region, including management events and data events for S3 and Lambda. In GCP, enable data access audit logs at the organization level for all services. Export logs to a centralized, immutable destination: an S3 bucket with object lock, a GCS bucket with retention policies, or a SIEM platform. Set alerts on high-signal events: root account logins, IAM policy changes, security group modifications, and console logins from unfamiliar IP ranges.

6. How Exposed Are Your Secrets in Cloud Environments?

Hardcoded secrets in cloud environments extend beyond application code. We find credentials embedded in EC2 user data scripts, Lambda environment variables visible in the console, GCP Cloud Function source code deployed with API keys, and Terraform state files stored in unencrypted S3 buckets containing every secret value used during provisioning.

Terraform state files deserve special attention. Every resource and data block's attributes are stored in plaintext in the state file, including database passwords, API keys, and private certificates. Teams that store state in S3 without server-side encryption and access logging are exposing their entire infrastructure's secrets to anyone with bucket read access.

GitGuardian's 2023 report detected over 10 million secrets in public repositories, but the private infrastructure exposure is harder to quantify and likely larger (GitGuardian State of Secrets Sprawl, 2023). The volume in cloud metadata, provisioning scripts, and configuration management tools dwarfs what appears in git repositories.

Migrate all secrets to AWS Secrets Manager or GCP Secret Manager. Reference secrets by ARN or resource name, never by value. Enable automatic rotation for database credentials and API keys. Encrypt Terraform state with server-side encryption using a customer-managed KMS key, and restrict state bucket access to your CI/CD pipeline's service account exclusively.

7. Why Are Default VPC Configurations a Liability?

Every AWS account ships with a default VPC in every region. Every GCP project starts with a default network. These defaults prioritize connectivity over security. The default VPC in AWS includes an internet gateway, public subnets, and a permissive default security group that allows all outbound traffic and all inbound traffic from other instances in the same group.

Teams that deploy production workloads into default VPCs inherit these permissive settings. We have found production databases running in default subnets with public IP addresses assigned automatically. The database was reachable from the internet not because anyone intended it, but because nobody changed the default.

GCP's default network includes firewall rules allowing ICMP, SSH (port 22), and RDP (port 3389) from 0.0.0.0/0. These rules exist to make onboarding frictionless. They also mean that every VM created in the default network is immediately scannable and reachable on administrative ports from the entire internet.

Delete default VPCs in every AWS region. Delete default networks in every GCP project. Provision custom VPCs and networks with explicit, minimal firewall rules. Use an infrastructure-as-code template that enforces your security baseline on every new environment. Our AI-powered security audit flags default network usage as a high-priority finding because the blast radius is always larger than teams expect.

8. Do Your Serverless Functions Have Excessive Permissions?

Serverless functions (AWS Lambda, GCP Cloud Functions, Cloud Run) are deployed with execution roles that define their cloud API permissions. The convenience of serverless encourages rapid iteration, and rapid iteration encourages overly broad permissions.

The common anti-pattern: a developer needs the Lambda to read from one DynamoDB table. They attach AmazonDynamoDBFullAccess because it works immediately. That managed policy grants read, write, delete, and administrative access to every DynamoDB table in the account. If the function has an injection vulnerability or processes untrusted input that triggers an SSRF, the attacker inherits full DynamoDB access across the entire account.

In GCP, Cloud Functions using the default compute service account inherit the Editor role on the entire project. That single default grants read and write access to Compute Engine, Cloud Storage, BigQuery, Pub/Sub, and dozens of other services. One compromised function becomes a pivot point for the entire project.

Create dedicated IAM roles for every serverless function. Scope permissions to the exact resources and actions required. Use resource-level policies where available: specify the exact DynamoDB table ARN, the exact S3 bucket path, the exact SNS topic. Audit permissions quarterly using AWS IAM Access Analyzer or GCP IAM Recommender to identify and remove unused grants.

9. Are You Running Unpatched Container Images in Production?

Container image vulnerabilities are a cloud-specific variant of traditional patch management failures. Teams build images from base layers that contain known vulnerabilities at build time, and those images run in production for months without rebuilding.

We scan container registries as part of every cloud audit. The typical finding: 60% to 80% of images in ECR or GCR contain at least one critical CVE. Many are based on ubuntu:latest or node:18 tags that pulled a specific version months ago and have not been rebuilt since. The tag is mutable, but the local cached image is stale.

Sysdig's 2024 Cloud-Native Security Report found that 87% of container images in production had high or critical vulnerabilities, and 75% of those vulnerabilities had patches available that had not been applied (Sysdig, 2024). The patches exist. The rebuild automation does not.

Use minimal base images: distroless, alpine, or scratch where feasible. Pin image digests, not tags, to guarantee immutable builds. Enable vulnerability scanning in ECR (Inspector) or GCR (Artifact Analysis) and set policies that block deployment of images with critical findings. Automate weekly rebuilds of all production images against updated base layers. A scheduled pipeline that rebuilds and redeploys weekly closes the patch gap from months to days.

10. Is Your Cross-Account and Cross-Project Access Under Control?

Multi-account (AWS) and multi-project (GCP) architectures are security best practice for blast radius containment. But the cross-account access patterns that connect them often undo the isolation entirely.

We find AWS IAM roles with trust policies that allow sts:AssumeRole from *, meaning any AWS account in the world can assume that role if they know its ARN. We find GCP service accounts with domain-wide delegation enabled but no restrictions on which users can impersonate them. We find cross-account S3 bucket policies that grant access to an entire AWS organization rather than the specific account that needs it.

Each of these patterns creates lateral movement paths. An attacker who compromises one account can pivot to every connected account through these trust relationships. The Mandiant M-Trends 2024 report identified lateral movement through cloud trust relationships as a growing technique in financially motivated intrusions (Mandiant, 2024).

Audit every cross-account IAM trust policy. Replace wildcard account IDs with specific account numbers. Add ExternalId conditions on all cross-account role assumptions. In GCP, restrict service account impersonation to named principals. Use AWS Organizations SCPs and GCP Organization Policies to prevent the creation of overly permissive trust relationships at the organizational level.

What Should You Do Next?

Start with visibility. You cannot fix what you cannot see. Run AWS Config or GCP Security Command Center against your production environments today. Both services identify the majority of the misconfigurations described above within minutes of activation. The findings will be longer than you expect.

Prioritize by exploitability, not severity score. A publicly readable S3 bucket containing customer data is more urgent than a missing encryption-at-rest configuration on an internal logging bucket, even if the CVSS scores suggest otherwise. Focus remediation on findings that an external attacker can reach without prior access.

Implement preventive guardrails before detective controls. AWS Service Control Policies and GCP Organization Policies can prevent dangerous configurations from being created in the first place. Denying public S3 buckets, denying default VPC usage, requiring encryption on all storage volumes: these policies eliminate entire categories of findings permanently.

Automate configuration audits into your CI/CD pipeline. Tools like Checkov, tfsec, and Bridgecrew scan Terraform, CloudFormation, and Kubernetes manifests before deployment. A misconfiguration caught in a pull request costs five minutes to fix. The same misconfiguration caught in production after a breach costs millions.

For teams that need comprehensive coverage across both AWS and GCP environments, our AI-powered security audit scans cloud configurations, IAM policies, network rules, encryption settings, and logging completeness in a single pass. In first-time audits, we surface an average of 47 findings per environment, with 12% rated critical. The scan takes hours. Manual review of the same scope takes weeks.

Cloud security is not a product you buy. It is a set of configuration decisions you make correctly, verify continuously, and prevent from drifting. The ten mistakes in this article are well-understood, well-documented, and entirely preventable. The question is whether your team will fix them before an attacker finds them first.