Cloud Security Checklist: 12 AWS and Azure Misconfigurations

Most cloud breaches do not start with clever hackers. They start with a setting nobody noticed: a storage bucket left public, an access key committed to Git, or a developer with admin rights in production. This checklist covers the twelve misconfigurations we find most often in AWS and Azure, what recent data says about how common they are, how to check for each and how to stop them coming back.

Why misconfigurations cause most cloud breaches

Cloud platforms make it easy to create resources in minutes, and just as easy to create them insecurely. Teams move fast, defaults are not always safe, and nobody owns the full picture across dozens of accounts and subscriptions.

The numbers are stark. Intruder's 2026 Cloud Security Index, which analyzed misconfiguration data from 3,000 organizations, found weak identity and access controls in 87 to 97 percent of accounts across AWS, Azure and Google Cloud. Publicly exposed services appeared in 76 percent of AWS accounts and 64 percent of Azure accounts.

The shared responsibility model in plain language

AWS and Microsoft secure the data centers, hardware and core services. You secure everything you configure on top: who can sign in, what they can do, which ports are open, whether data is encrypted and whether anyone is logging activity. Most incidents happen on your side of that line.

Identity and access

• 1. No MFA on privileged accounts. Every human account with admin rights should require multi-factor authentication, starting with the root or global administrator. The 2026 index found Entra users without MFA in 55 percent of Azure accounts.
• 2. Over-privileged users and roles. Developers rarely need full admin in production. Use least-privilege roles, watch for IAM policies that allow privilege escalation, and review access quarterly.
• 3. Long-lived access keys. Static keys leak through code repositories and laptops. Prefer short-lived credentials and single sign-on, and rotate any keys that must exist.
• 4. Unused accounts. Former employees and old service accounts are an easy way in. Remove them as part of offboarding and review service accounts regularly.

Data protection

• 5. Public storage. Check every S3 bucket and Azure storage account, and block public access at the account level unless a bucket truly needs it. In Azure, disable public network access and shared access keys where you can.
• 6. Unencrypted data and data in transit. Turn on encryption at rest for storage, databases and backups, and enforce HTTPS. The 2026 index found S3 buckets that do not require HTTPS in 87 percent of AWS accounts.
• 7. Backups in the same account. If an attacker controls the account, they control the backups. Keep copies isolated, make them immutable where possible and test restores.

Network exposure

• 8. SSH or RDP open to the internet. Put management access behind a bastion, VPN or session manager instead. Security groups allowing inbound traffic to sensitive ports appeared in 84 percent of AWS accounts in the same study.
• 9. Flat networks. Separate production from development and segment sensitive workloads so one compromised server does not expose everything.
• 10. Forgotten resources. Old test servers, snapshots and load balancers often run unpatched. Inventory and remove what you do not use.

Visibility

• 11. Logging turned off. CloudTrail in AWS and activity logs in Azure should be on in every region and account, sent to a central location that attackers cannot delete.
• 12. No alerts on risky changes. Alert on events like new admin users, disabled logging, changed security groups or storage made public.

AWS vs Azure: different platforms, different weak spots

Each provider has its own pattern. In AWS, the most common problems involve S3 transport security, permissive security groups and IAM privilege escalation. In Azure, storage accounts dominate the list: access keys left enabled, keys never rotated and public network access switched on. Google Cloud tends to show fewer issues, largely because of safer default settings.

If you run more than one cloud, do not assume a checklist written for one covers the other. Build a baseline for each.

How to check your environment

Native tools give you a good starting point: AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center all score your configuration against best practices. These are cloud security posture management (CSPM) tools. The CIS Benchmarks for each cloud provider list the exact settings to verify.

The hard part is not running a scanner. It is deciding which of hundreds of findings matter, and fixing them without breaking production.

How to prioritize what to fix first

• Start with anything exposed to the internet: public storage, open management ports and public databases.
• Next, fix identity: MFA on every admin, remove unused accounts and rotate or remove static keys.
• Then turn on logging and alerting everywhere, so you can see what happens next.
• Finally, work through encryption, segmentation and clean-up of unused resources.

How to stop misconfigurations coming back

Fixing issues once is not enough, because new resources are created every day. Define your infrastructure as code with tools like Terraform or Bicep, add policy checks to your deployment pipeline, and use guardrails such as AWS Service Control Policies or Azure Policy to block risky settings before they reach production. Review your posture score monthly.

When to bring in cloud security consulting

• You have never had an independent review of your cloud setup.
• An audit, customer questionnaire or cyber-insurance renewal is coming up.
• Your team built quickly and nobody owns security full time.
• You run several accounts or subscriptions and lack a consistent baseline.
• You have just migrated workloads to the cloud or acquired a company.

A good consultant assesses with read-only access, ranks findings by real risk and helps your engineers fix them, ideally in infrastructure as code so fixes stay fixed. See how our cloud security consulting assessments work, and pair them with ongoing cloud infrastructure management to stop drift. For round-the-clock detection, add managed SOC and MDR coverage of your cloud accounts.