A cloud security checklist for AWS, Azure and Google Cloud

Most cloud breaches are not the result of a sophisticated attacker defeating strong controls. They are the result of ordinary mistakes: an over-privileged account, a storage bucket left public, a database exposed to the internet, logging that was never turned on. The good news is that the same short list of controls prevents the large majority of these incidents, and they are the same in spirit across AWS, Azure and Google Cloud. This article is that list, written so an engineering lead can work through it and know where they stand.

The problem

The cloud gives you enormous power with a few clicks, and it gives an attacker the same power if they get in. A single over-permissioned key or one publicly readable bucket can expose everything. Because cloud environments change constantly — new services, new accounts, new resources spun up under deadline — security drifts unless something holds it in place. Teams discover the gap only when an auditor, a customer's security questionnaire, or an actual incident forces them to look.

Why it happens

Cloud misconfigurations accumulate for three predictable reasons:

• Defaults favour convenience. Broad permissions and open access get things working fastest, so they are chosen under pressure and rarely tightened later.
• The shared responsibility model is misread. The provider secures the cloud itself; you are responsible for how you configure what runs on it. Teams often assume more is handled for them than actually is.
• No guardrails. Without automated policies that prevent risky configurations, security depends on every engineer remembering every rule on every change, which never holds at scale.

The core checklist

These controls map across all three clouds. The principle is identical; only the service name changes.

Control	AWS	Azure	Google Cloud
Central identity, least privilege	IAM roles, least-privilege policies	Entra ID, RBAC	IAM roles, least privilege
MFA on the top-level account	MFA on root, avoid using root	MFA on Global Admins	MFA on Organization admins
Audit logging on everywhere	CloudTrail (all regions)	Azure Monitor / Activity Log	Cloud Audit Logs
No public object storage	Block Public Access on S3	Storage firewall, no public blobs	Uniform bucket access, no allUsers
Encryption at rest and in transit	KMS + TLS	Key Vault + TLS	Cloud KMS + TLS
Private networking for data stores	Private subnets, security groups	Private endpoints, NSGs	VPC, private service access
Threat detection	GuardDuty, Security Hub	Microsoft Defender for Cloud	Security Command Center
Guardrails / policy	Service Control Policies	Azure Policy	Organization Policy

Identity is the new perimeter

More than anything else, control who and what can do what. Use central identity, grant the least privilege that lets each person and workload do its job, and give workloads their own identities (roles, managed identities, service accounts) rather than shared keys. Protect the top-level account with multi-factor authentication and stop using it for daily work. Most serious cloud incidents trace back to an identity that could do far more than it needed to.

Close the two most common exposures

Two misconfigurations cause a large share of real breaches: public storage and internet-facing data stores. Turn on the account-wide setting that blocks public access to object storage, and keep databases, caches and internal services in private networks reachable only through controlled paths. These two fixes alone remove the majority of "how did they get in" answers.

Turn on logging before you need it

You cannot investigate an incident you did not record. Enable audit logging across every region and account, send it somewhere central and tamper-resistant, and keep it for long enough to matter — in India, CERT-In directions require certain logs to be retained for 180 days. Logging is cheap; not having it during an incident is not.

Hold it in place with guardrails

Manual review does not scale, and cloud environments drift. Use preventive policies — Service Control Policies, Azure Policy, or Organization Policy — to make risky configurations impossible rather than merely discouraged: deny public buckets, require encryption, restrict regions. A guardrail that blocks a mistake is worth more than a dashboard that reports it after the fact.

What to do this week

• Enable multi-factor authentication on your root or top-level administrative accounts today, and stop using them for routine work.
• Turn on the account-wide setting that blocks public access to object storage, then review any bucket that needed an exception.
• Confirm audit logging is on across all regions and accounts, centralised, and retained for at least 180 days.
• Check that no database or internal service is reachable from the public internet.
• Turn on the native threat-detection service for your cloud and review what it surfaces.

When to bring in a partner

A checklist tells you what good looks like; keeping an active, growing environment there is the harder part. Running continuous configuration monitoring, guardrails and threat detection as an ongoing service is what our managed security service does, and a point-in-time vulnerability assessment is the fastest way to find where you stand right now. If you operate across more than one cloud, a partner brings a single, consistent security baseline to all of them, so you are not maintaining three different mental models of "secure."