Most cloud security incidents are not the result of a sophisticated attack. They are the result of a misconfigured setting that quietly sat exposed for months before anyone noticed — a storage bucket left public, an access key committed to a public repository, or a security group left open to the entire internet during a rushed deployment. This guide walks through the misconfigurations we see most often, how to check for them yourself, and what to fix first if you are working with limited time.
This is written for developers and small teams managing their own AWS or GCP infrastructure without a dedicated security engineer, not for large enterprises with existing security teams. For related reading, see our hardening guides and our tool reviews section.
Public storage buckets: the most common mistake
Amazon S3 buckets and Google Cloud Storage buckets are, by default in most modern account setups, private. But it remains extremely common to find buckets set to public — usually because a developer needed to quickly share a file, set the bucket to public to make that easier, and never reverted the setting afterward.
The fix is straightforward: audit every bucket in your account and confirm public access is blocked at the account level, not just the individual bucket level. AWS specifically offers an account-wide “Block Public Access” setting that overrides individual bucket permissions — enabling this as a default policy prevents the mistake from happening again even if someone toggles an individual bucket’s setting incorrectly in the future.
If you need to share files publicly on a genuine, ongoing basis, use signed URLs with an expiration time instead of making the entire bucket public — this gives you time-limited, revocable access rather than a permanently open door.
Overly permissive security groups and firewall rules
A security group (AWS) or firewall rule (GCP) that allows inbound traffic from 0.0.0.0/0 — meaning any IP address on the internet — on a sensitive port like SSH (22) or a database port is one of the fastest ways to get discovered and probed by automated scanning bots, often within hours of the resource going live.
Restrict SSH access to specific known IP ranges (your office, your VPN’s exit IP, or a bastion host) rather than leaving it open to the world. For database ports specifically, they generally should not be internet-facing at all — access them through a private network, a VPN, or an SSH tunnel rather than exposing the port directly, even with a strong password in place.
Long-lived access keys and credentials in code
Committing an access key directly into a code repository — even a private one — is a surprisingly common mistake, and once a key is committed to git history, deleting the file later does not remove it from the repository’s history unless you specifically rewrite that history. Automated bots actively scan public GitHub repositories for exposed credentials, and compromised keys have been used within minutes of being pushed in some documented incidents.
Use environment variables or a dedicated secrets manager (AWS Secrets Manager, GCP Secret Manager, or a third-party tool like HashiCorp Vault) instead of hardcoding credentials into your codebase. Set up pre-commit hooks or a secrets-scanning tool in your CI pipeline to catch accidental commits before they are pushed, since relying purely on developer discipline eventually fails.
For any long-lived access keys that already exist, rotate them on a schedule (every 90 days is a reasonable default) rather than treating a key as permanent once issued. Where possible, replace long-lived keys with short-lived, automatically rotating credentials using IAM roles (AWS) or service accounts with workload identity federation (GCP) instead.
Overly broad IAM permissions
It is common, especially under deadline pressure, to grant a service or user account broad administrative permissions just to unblock a task quickly, with the intention of tightening it later. In practice, that follow-up rarely happens, and accounts end up carrying far more access than they actually need indefinitely.
Apply the principle of least privilege: grant only the specific permissions a service or person needs to do their job, not broad administrative access as a default starting point. Both AWS and GCP provide tools to analyze actual permission usage over time (AWS IAM Access Analyzer, GCP’s Policy Analyzer) — run these periodically and remove permissions that have not actually been used in the last 90 days.
Missing multi-factor authentication on the root/owner account
The root account (AWS) or organization owner account (GCP) has unrestricted access to everything in your cloud environment. If this single account does not have multi-factor authentication enabled, it represents a single point of failure for your entire infrastructure. This should be one of the very first things configured on any new cloud account, before any actual infrastructure is deployed.
Beyond the root account, enforce multi-factor authentication as an organization-wide policy for every user with console access, not just admins. Both platforms support this as an enforceable setting rather than relying on individual users to enable it voluntarily.
Unencrypted data at rest
Modern cloud storage and database services generally support encryption at rest with minimal performance cost, and in most cases it can be enabled with a single setting. Despite this, it is still common to find databases, storage volumes, and backups running without encryption enabled, often because it simply was not turned on during initial setup and nobody revisited it afterward.
Audit your existing resources for encryption status and enable it going forward as a default for any new resource. For most small teams, using the cloud provider’s managed encryption keys is sufficient — customer-managed encryption keys add complexity that is usually only justified once you have specific compliance requirements (HIPAA, SOC 2, etc.) that mandate it.
Understanding the shared responsibility model
A common misunderstanding among teams new to cloud infrastructure is assuming the cloud provider handles security entirely. In reality, both AWS and GCP operate on a shared responsibility model: the provider secures the underlying physical infrastructure, hardware, and the core services themselves, while you remain responsible for how you configure those services — your access controls, your network rules, your data encryption settings, and your application-level security.
Nearly every misconfiguration covered in this guide falls squarely on the customer side of that line. The provider will not stop you from making a storage bucket public, leaving a database port open to the internet, or granting overly broad permissions — those are configuration choices within your control, and the responsibility for getting them right sits with your team, not the cloud provider.
Logging and monitoring: knowing when something goes wrong
Fixing misconfigurations addresses known risks, but you also need visibility into what is actually happening in your environment over time. AWS CloudTrail and GCP’s Cloud Audit Logs both record account activity — who accessed what, when, and from where — and are often disabled or left at minimal retention settings by default on new accounts.
Enable comprehensive logging early, even before you think you need it. Retroactively investigating an incident is far harder, sometimes impossible, if logging was not already running when the incident occurred. At minimum, set up alerts for high-risk events: root account logins, changes to IAM permissions, and changes to security group or firewall rules. These alerts, configured through AWS CloudWatch or GCP’s operations suite, give you a chance to catch a misconfiguration or intrusion attempt within minutes rather than discovering it months later during an unrelated audit.
Both platforms offer generous free tiers for basic logging and alerting, so cost is rarely a reasonable excuse to skip this step even for a small team on a tight budget.
Orphaned and unused resources
Old test instances, unused storage buckets from a discontinued project, and service accounts created for a contractor who finished work months ago tend to accumulate quietly in any active cloud account. Beyond the unnecessary cost, each of these is an additional resource that could be misconfigured or forgotten during future security reviews simply because nobody remembers it exists.
Periodically review your resource inventory against what your team can actually account for, and remove or properly decommission anything nobody can explain the current purpose of. This is a simple step that is easy to skip under time pressure, but it meaningfully shrinks the total area an attacker — or an automated scanning bot — could potentially exploit.
A practical starting checklist
If you only have an afternoon to spend on this, work through these in order:
1. Enable multi-factor authentication on the root/owner account, if it is not already on.
2. Enable account-wide public access blocking on storage buckets.
3. Audit security groups/firewall rules for any rule allowing 0.0.0.0/0 on sensitive ports.
4. Search your git history for accidentally committed credentials and rotate anything found.
5. Turn on comprehensive logging and set up alerts for high-risk account changes.
6. Set a recurring calendar reminder (quarterly is reasonable) to re-run this checklist, since new resources get added and misconfigured over time even after an initial cleanup.
For teams also managing credential storage across this process, our password manager comparison covers how to securely store and share the access keys and console logins this checklist involves.
Frequently asked questions
Do we need a dedicated cloud security tool, or is manual auditing enough?
For a small team with a modest cloud footprint, manual audits using the checklist above, run quarterly, are usually sufficient. Once your infrastructure grows past a certain size, dedicated cloud security posture management (CSPM) tools become worth the cost since manual auditing stops scaling.
How quickly do exposed resources actually get discovered by attackers?
Automated scanning bots continuously probe the public IP address ranges of major cloud providers, and in several documented cases, newly exposed resources with weak or default configurations were found and probed within hours of going live. This is why fixing misconfigurations proactively matters more than hoping nobody notices.
Is a smaller cloud footprint automatically safer?
Not necessarily — a small footprint with a single misconfigured public database can be just as exposed as a much larger, well-configured environment. Size matters less than whether the checklist items above have actually been addressed.
Should we hire a security consultant for a one-time audit?
For teams handling sensitive client or financial data, a one-time professional audit is a reasonable investment even on top of following this checklist yourself, since an external reviewer will often catch context-specific issues that a general checklist cannot cover.
How does this checklist differ between AWS and GCP?
The underlying principles — least privilege, encryption at rest, restricted network access, comprehensive logging — apply identically across both platforms. The specific menu paths and tool names differ (Security Groups vs firewall rules, IAM Access Analyzer vs Policy Analyzer), but a team comfortable auditing one platform can generally apply the same checklist logic to the other with minimal adjustment.
Read more about our testing approach on our about page, or browse the rest of our hardening guides for related topics as we continue publishing.