Cloud Misconfiguration Checklist: The Most Common Settings to Review Across AWS, Azure, and GCP

Overview

This article gives you a reusable cloud misconfiguration checklist that works across AWS, Azure, and GCP. It is not a control catalog and it is not meant to replace provider benchmarks. Its purpose is narrower and more useful in day-to-day operations: help your team review the high-risk settings that repeatedly cause avoidable exposure.

A good cloud configuration review should answer a few simple questions:

• Who can access this environment, and do they need that level of access?
• What is reachable from the internet, and was that exposure intentional?
• Where does sensitive data live, and is it protected the way your policies require?
• Can you detect misuse, drift, and incidents quickly enough to respond?
• Are your controls still aligned with the current architecture rather than last quarter’s design?

That framing matters because cloud misconfiguration is usually a shared responsibility problem in practice. Providers secure the platform, but customers still decide how identities are granted, how storage is exposed, how logs are retained, and how secrets are managed. If you need a broader grounding in that boundary, see Shared Responsibility Model by Cloud Service: What AWS, Azure, and Google Cloud Customers Still Need to Secure.

For teams with privacy obligations, this checklist also supports cloud privacy compliance and data protection compliance work. A misconfiguration can become more than a security issue if it weakens access controls, expands data exposure, or breaks internal retention rules. That is why the most effective reviews connect security settings to data handling decisions.

Checklist by scenario

Use this section as the core checklist. The scenarios are written to be revisited whenever your environment changes.

1. Identity and privileged access

• Review human admin accounts. Confirm there are no stale administrators, emergency accounts without clear ownership, or long-lived identities tied to former staff or old vendors.
• Reduce broad roles. Look for project-wide, subscription-wide, or account-wide permissions that were granted for speed and never narrowed afterward.
• Separate daily use from privileged use. Admin actions should not happen routinely from the same identity used for email, tickets, and development work.
• Require strong authentication for privileged paths. Make sure high-impact roles, consoles, and control-plane actions are protected by enforced multifactor authentication where supported.
• Inspect service accounts and workload identities. Remove unused identities, rotate credentials where applicable, and check whether machine identities have broader permissions than the workloads they serve.
• Check trust relationships. Cross-account or cross-project access should be documented, intentional, and periodically reapproved.

This is one of the highest-value areas in any AWS security checklist, Azure security checklist, or GCP security checklist because excessive privileges amplify every other mistake.

2. Public exposure and network boundaries

• Inventory internet-facing assets. List public load balancers, application gateways, public IPs, exposed virtual machines, managed databases with public endpoints, and externally reachable storage services.
• Confirm exposure is intentional. If a service is public, identify the business reason, owner, and compensating controls.
• Review overly permissive security rules. Watch for any inbound rule that allows broad source ranges to management ports, database ports, or internal services.
• Limit administrative access paths. SSH, RDP, bastion access, and management APIs should be restricted to approved sources and monitored.
• Inspect egress controls. Many teams focus on inbound access and ignore unrestricted outbound connectivity, which can matter during data exfiltration or malware activity.
• Use segmentation where practical. Separate production, development, and sensitive workloads so one mistake does not expose everything at once.

3. Storage and object access

• Check for public buckets, containers, and objects. Public read or write access should be rare and documented.
• Review default object permissions. A safe bucket can still contain objects with unsafe access settings.
• Inspect sharing links and external principals. Temporary access often becomes semi-permanent if nobody expires it.
• Turn on versioning and recovery features where needed. This helps with accidental deletion, ransomware response, and change review.
• Confirm encryption settings. At-rest encryption should align with your internal baseline, and key management choices should be understood by the team.
• Apply lifecycle and retention rules carefully. Retention should support both operational recovery and data minimization goals.

Storage misconfigurations often create the most visible incidents, but the quieter problem is governance drift: old backups, exported logs, or analytics files left in places nobody actively reviews.

4. Databases and managed data services

• Disable unnecessary public endpoints. Managed databases should usually be private unless there is a clear exception.
• Review authentication methods. Check whether local database users, password auth, or legacy access paths remain enabled when stronger identity integration is available.
• Enforce TLS where possible. Sensitive data in transit should not depend on optional client behavior.
• Audit backup access. Snapshots, exports, replicas, and analytical copies may be less protected than the primary store.
• Check parameter changes. Debug settings, permissive network modes, or verbose logging can expose sensitive data if left enabled.

5. Logging, monitoring, and detection

• Enable control-plane audit logs. You should be able to see who changed permissions, network rules, storage policies, and key settings.
• Collect key data-plane logs where justified. Focus on the services that hold sensitive data or face the internet.
• Protect log integrity. Logs should be retained long enough for investigation and protected from casual tampering or deletion.
• Alert on high-risk changes. Prioritize events such as new admin role grants, public exposure changes, disabled logging, deleted keys, and unusual service account use.
• Test whether alerts reach people. A nominal alert pipeline is not the same as a working incident response path.

If your organization is refining its response process, pair technical logging reviews with communication planning. Two useful reads are Automating Incident Communications Without Sacrificing Accuracy: Tools, Workflows, and Guardrails and The CISO-Comms Playbook: How Security and PR Leaders Should Coordinate During a Breach.

6. Encryption, keys, and secrets

• Identify where secrets are stored. Check code repositories, CI variables, startup scripts, container images, and unmanaged files on virtual machines.
• Move secrets into managed secret storage where possible. This improves rotation, access review, and auditability.
• Review key policies and key users. Keys that protect sensitive data should not be widely usable by default.
• Inspect rotation practices. Rotation should apply to the credentials and keys that meaningfully reduce risk, not just the ones that are easiest to rotate.
• Watch for hardcoded fallback credentials. Temporary development shortcuts tend to survive long after launch.

7. Compute, containers, and serverless workloads

• Remove default openness. Review instance metadata access controls, administrative ports, and permissive startup configurations.
• Check image hygiene. Container and machine images should not carry embedded credentials, old agents, or unnecessary packages.
• Limit runtime permissions. Serverless functions and container workloads often inherit broader privileges than intended.
• Review execution environments. Debug modes, anonymous endpoints, and test hooks should not remain enabled in production.
• Patch management should match exposure. Prioritize externally reachable systems and systems handling regulated or sensitive data.

8. Backup, recovery, and resilience settings

• Confirm backups exist for critical systems. Many teams discover a recovery gap only during an incident.
• Review backup access and immutability options. Backups are valuable targets if an attacker wants leverage or persistence.
• Test restore paths. A successful backup job does not prove recoverability.
• Separate backup privileges from production admin privileges. This can reduce the blast radius of compromised accounts.

9. Data governance and privacy-sensitive configuration

• Map sensitive data stores. Know which workloads handle personal data, credentials, customer records, support exports, or regulated content.
• Check regional placement and transfer paths. Cross-region replication, support access, analytics exports, and third-party integrations can quietly change where data goes.
• Apply least access to data operations. Access to raw datasets, backups, and admin consoles should be narrower than access to application dashboards.
• Review retention settings. Logging and backup decisions should support security needs without creating unmanaged long-term storage of personal data.
• Inspect subprocessors and integrations. Data forwarded to SaaS tools, observability platforms, and AI-enabled services should match your approved data handling model.

This is where cloud security best practices and privacy by design start to overlap. If your team is adding AI-enabled tooling, it is worth reviewing Technical Controls to Enforce Legal Compliance Without Sacrificing User Privacy in Generative AI.

What to double-check

This section covers the settings that teams often think they reviewed, but did not fully validate.

• Inherited permissions. A resource may look safe until you trace inherited roles from a parent group, folder, management group, project, or account structure.
• Defaults that changed over time. Cloud providers update service defaults, but old resources may still reflect legacy behavior.
• Shadow assets. Temporary projects, test subscriptions, personal sandboxes, and migration leftovers are common blind spots.
• Exception paths. Security teams may approve a temporary exception, but nobody confirms when it should expire.
• Nonproduction environments. Development and staging environments often hold realistic datasets and broad credentials while receiving less scrutiny.
• Third-party deployment tooling. Infrastructure created by CI pipelines, marketplace images, MSP scripts, or SaaS connectors may not follow your baseline by default.
• Deleted or disabled safeguards. Alert rules, guardrails, or policy assignments can be turned off during troubleshooting and forgotten afterward.

A practical technique is to review settings in two passes. In the first pass, verify the intended configuration. In the second, ask how that configuration could be bypassed by inheritance, exceptions, alternate endpoints, copied data, or old resources.

Common mistakes

The most common cloud misconfiguration mistakes are not always technical failures. Many are process failures with technical symptoms.

• Treating the first hardening pass as finished work. Cloud environments drift constantly. A one-time review is not enough.
• Checking controls without checking coverage. It is easy to confirm that a policy exists somewhere and miss the fact that key workloads are out of scope.
• Granting temporary access without an expiry mechanism. The access itself may be justified. The lack of cleanup is the problem.
• Focusing only on internet exposure. Internal over-permission, excessive data replication, and weak service identities can be just as damaging.
• Ignoring operational convenience risks. Engineers under delivery pressure often add broad access or debugging shortcuts that are understandable in context but risky if left in place.
• Separating security review from data review. A setting can be technically functional and still create unnecessary privacy or governance risk.
• Assuming provider-native means properly configured. Managed services reduce operational burden, but they do not remove customer configuration responsibility.

The remedy is usually straightforward: define a small review set, assign owners, use change-driven rechecks, and document exceptions with dates. A lean, repeated review beats an ambitious checklist no one revisits.

When to revisit

This checklist is most useful when it becomes part of an operating rhythm. Revisit it at specific moments rather than waiting for an audit or incident.

• Before major releases. New public endpoints, APIs, storage flows, and service accounts often appear during launch preparation.
• After architectural changes. Migrations, multi-cloud expansion, account restructuring, and new identity models can invalidate old assumptions.
• When workflows or tools change. New CI systems, observability tools, SaaS integrations, or AI assistants can introduce new permissions and data paths.
• Before seasonal planning cycles. Use quarterly or half-year planning to review stale exceptions, inherited access, and unowned resources.
• After incidents or near misses. Update the checklist to reflect what actually created confusion, delay, or exposure.
• When compliance scope changes. If your team starts handling more customer data, enters a new region, or signs larger customers, your baseline may need to become stricter.

To make this operational, keep a short action list:

1. Choose one owner for the checklist and one backup owner.
2. Map each checklist item to a review method: manual inspection, policy-as-code, cloud-native rule, or ticketed signoff.
3. Record exceptions with a reason, approver, and expiry date.
4. Review production monthly and lower environments on a lighter but defined schedule.
5. After each review, update the checklist based on what your team actually found, not what you expected to find.

The value of a cloud configuration review is not in producing a perfect spreadsheet. It is in reducing preventable risk before a small oversight becomes a public incident, a customer issue, or a compliance problem. Keep the checklist short enough to use, specific enough to matter, and flexible enough to change as AWS, Azure, and GCP evolve.