7 Cloud Misconfigurations to Fix First in AWS, Azure and Google Cloud

Cloud providers secure the underlying platform, but how you configure your own accounts remains your responsibility. That is the shared responsibility model. With many teams creating resources quickly, risky settings build up easily. These seven checks apply to all the major clouds and give you a sensible place to begin.

The seven checks

• 1. Public storage

  Look for storage buckets and blobs that anyone can read or list. Turn on account-level public access blocks where available.

• 2. Open management ports

  SSH, RDP and database ports should not be open to the entire internet. Use a bastion, VPN or provider session tools.

• 3. Excessive permissions

  Replace wildcard and administrator roles with permissions based on what each person or service actually uses.

• 4. Long-lived access keys

  Find old keys and remove them. Use short-lived credentials and workload identities, and scan your code for leaked secrets.

• 5. Weak root and admin access

  Require strong MFA on root and global admin accounts, keep their use rare, and alert whenever they are used.

• 6. Missing logs

  Enable audit logs across all accounts and regions, store them centrally, and protect them against changes.

• 7. Unencrypted or public backups

  Check snapshots, images and backups as well as live systems. A forgotten public snapshot can expose an entire database.

Stop them coming back

A one-time cleanup slowly falls apart as new resources appear. Fixes last when they are built into how your teams work.

• Organization-level guardrails

  Service control policies, Azure Policy and Google organization policies can block risky settings before they are created.

• Checks in CI/CD

  Scan infrastructure as code so problems are found in review instead of in production.

• Continuous posture scanning

  Run scans against CIS Benchmarks and send findings to the team that owns each resource.

• Clear ownership

  Tag every resource with an owner. An issue with no owner rarely gets fixed.

Why these mistakes happen

Cloud misconfigurations are rarely caused by carelessness alone. Developers can create resources in minutes, teams work across many accounts, and a temporary setting made during an urgent fix can easily stay in place for years. Default settings have also changed over time, so older accounts may behave differently from new ones.

This is why a good program does not rely on one expert checking settings by hand. It combines visibility, sensible defaults and clear ownership, so a safe configuration becomes the easiest one for your teams to use.

Where to look in each cloud

Every major cloud provides native tools that can be turned on before you buy anything new. Names and features change, so confirm current details in the provider's documentation.

• AWS

  Use S3 Block Public Access at the account level, IAM Access Analyzer for external and unused access, CloudTrail for audit logs, and Security Hub or AWS Config for posture checks. Require IMDSv2 on EC2 instances to reduce the risk of stolen instance credentials.

• Microsoft Azure

  Use Microsoft Defender for Cloud for posture findings, Azure Policy for guardrails, Activity Logs for auditing and Entra ID Conditional Access and Privileged Identity Management for admin access.

• Google Cloud

  Use Security Command Center for findings, Organization Policy for guardrails, Cloud Audit Logs for visibility and IAM Recommender to reduce excess permissions. Enforce public access prevention on Cloud Storage where appropriate.

How to prioritize the findings

A first scan often produces hundreds or thousands of findings, and severity ratings alone can mislead you. A critical issue on an isolated test system may matter less than a medium issue on an internet-facing production system holding customer data. Rank each finding by asking four questions.

• Is it reachable?

  Anything exposed to the public internet goes to the top of the list.

• What data or power does it have?

  Consider sensitive data, production workloads and permissions that could lead to wider control.

• Is it being actively exploited?

  Check whether the weakness has known attacks, for example through the CISA Known Exploited Vulnerabilities catalog.

• Can it chain with something else?

  A low-privilege server with a role that can read all storage is a much bigger risk than either fact alone.

A 30-day cleanup plan

You do not need a long program to make meaningful progress. A focused month can remove much of the most obvious risk.

• Week 1: Get visibility

  List every account and subscription, including forgotten ones. Turn on audit logs and native posture tools, and assign an owner for each environment.

• Week 2: Remove public exposure

  Close public storage and management ports, unless there is a documented reason. Check snapshots and databases, too.

• Week 3: Fix identity

  Require strong MFA for administrators, remove old access keys, and reduce wildcard permissions on the highest-risk roles.

• Week 4: Prevent repeats

  Apply organization-level policies for your top issues, add infrastructure as code scanning, and start a monthly review of new findings.

Test changes safely

Security fixes can break production when an application silently depends on a risky setting. Before closing a port or removing a permission, check logs to see what actually uses it. Apply the change in a test environment first, roll it out in stages and keep a clear way to reverse it. For permissions, use access history to shorten the policy gradually instead of removing everything at once.

Guardrails also need a documented exception process. If teams cannot get a legitimate exception quickly, they will look for ways around the rule. Every exception should have an owner, a reason and an expiry date.

Where NPLUS Global helps

Our cloud security review checks your accounts against recognized benchmarks, ranks findings by real exposure, and helps your team fix them and set guardrails so the same issues do not return.