Cloud penetration testing and AWS, Azure, Google Cloud security audits: what is checked and how to prepare

A security check of AWS, Azure or Google Cloud looks for what exposes your data without anyone breaking the provider: excessive IAM rights, public storage, keys in code, open ports, missing logs, weak Kubernetes settings and CI/CD pipelines. There are two formats: a configuration review with a read-only role against the CIS Benchmarks, and a penetration test that checks whether those weak spots can actually be used.

Below I explain what the provider is responsible for and what you are, what is checked in each area, how a review differs from a pentest, which testing rules apply at AWS, Microsoft Azure and Google Cloud as of October 2026, what to prepare and what you get. General preparation for any test is covered in how to prepare for a pentest.

In short

• The provider secures the cloud itself, you secure what you configured in it. Data, accounts, access rights and settings are always on your side. ^{[5] [6]}
• A configuration review compares settings with the CIS Benchmarks through a read-only role and changes nothing. A cloud pentest actively checks how far an attacker gets from public access or from one stolen key.
• The most common findings are excessive rights, public storage, long-lived keys in code and pipelines, open management ports and logs nobody keeps beyond the default periods.
• Provider approval. AWS, Azure and Google Cloud do not require prior approval to test your own resources, but all of them prohibit DoS. AWS requires a separate request at least two weeks ahead for covert attack simulations, command and control (C2) and simulated phishing. ^{[1] [2] [4]}
• What you provide: a read-only role, the list of accounts, subscriptions or projects, and a contact who can stop the test.

What is checked in the cloud: table

Shared responsibility: what is yours and what is the provider’s

AWS puts it this way: the provider is responsible for security of the cloud, meaning hardware, network and data centers, and the customer for security in the cloud. On the customer side are the guest operating system of virtual machines, data and its encryption, IAM permissions and the security group (firewall) settings of each instance. ^[5]

Microsoft’s responsibility matrix states plainly that under every model, from virtual machines to ready-made services, the customer keeps data, accounts, access management and configuration. ^[6]

The practical conclusion is simple: most cloud incidents start not with a breach of the provider but with a customer setting. The provider will not fix a public bucket or an admin key in a repository for you.

Configuration review and cloud pentest: the difference

A configuration review looks at settings from the inside through a read-only role. The usual baseline is the CIS Benchmarks: secure configuration recommendations from the Center for Internet Security community, free for non-commercial use. There are separate documents for AWS Foundations, Microsoft Azure Foundations, Google Cloud Platform Foundation, Kubernetes, and for EKS, AKS and GKE. ^[7] A review is quick, breaks nothing and shows the full picture of settings, but it does not answer the question "what of this can actually be exploited".

A cloud pentest checks chains. For example: a public function returns an error containing an access key, the key can read storage, the storage holds a database backup. The tester works from two positions: from outside, like anyone on the internet, and from an agreed entry point, for example with the credentials of an ordinary developer or a compromised server. This shows how far an attacker gets if one key has already leaked.

For a first check a configuration review is usually enough: it finds the most common problems at the lowest cost. A pentest makes sense once basic settings are in order, or when a product with customer data runs in the cloud. They are often combined: a review of the whole environment plus a pentest of critical applications. More on automated checks versus manual testing in pentest or vulnerability scan.

1. IAM and excessive rights

IAM (identity and access management) is the main risk area in any cloud. Reviewers look at:

• who has admin rights: Owner in Azure, Owner or Editor in Google Cloud, AdministratorAccess in AWS;
• roles and policies allowing any action on any resource;
• unused users, roles and access keys;
• MFA for people and protection of the AWS root account;
• who can raise their own rights, for example by creating a new policy or granting themselves a role.

AWS recommends that people sign in through single sign-on with temporary credentials and that workloads use roles rather than long-lived keys. Unused roles, permissions and keys should be found regularly through last-used data and removed. ^[8]

2. Public storage

Storage open to "everyone" is still one of the easiest ways to lose data. In AWS new S3 buckets block public access by default, but a bucket policy or ACL can open it. So the check is whether S3 Block Public Access is on for the whole account, not just for individual buckets. ^[9] In Azure the review covers anonymous access to Blob Storage containers and SAS links (temporary links with rights) with long expiry. In Google Cloud it looks for buckets granting access to allUsers or allAuthenticatedUsers.

The reverse is checked too: whether your domain points to a deleted bucket or service. Such a DNS record lets another account claim the name and serve content in your name. During a test the record is only reported: AWS prohibits actually taking over a bucket or subdomain. ^[1]

3. Keys and secrets

A cloud access key in a repository, a Docker image, a function’s environment variables or a build log is effectively an admin password. Reviewers check:

• Git history, not just the current code: a deleted key stays in old commits;
• environment variables of functions and containers;
• secrets in key stores (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) and who can read them;
• the age of access keys and whether anyone ever rotated them.

A found key is not used to access systems that are not yours. Microsoft’s rules explicitly prohibit using credentials that are not your own, even if they leaked publicly. ^[3]

4. Network and security groups

Security groups in AWS, NSGs (network security groups) in Azure and VPC firewall rules in Google Cloud decide what is reachable from the internet. Typical findings: SSH (port 22), RDP (3389) or a database port open to the whole internet, forgotten test servers with public addresses, databases with public access. A good result: server management goes through a bastion, VPN or a provider service such as AWS Systems Manager, Azure Bastion or IAP in Google Cloud, and only web ports of services meant to be public are open to the internet.

An external scan of your public addresses shows the same from the attacker’s side. All three providers allow it for your own resources. ^{[1] [2] [4]}

5. Logs and monitoring

Without logs nobody can say after an incident who changed what and what was taken. What you get by default:

• AWS CloudTrail. Event history is on automatically, but it keeps only 90 days of management events per region and does not show data access events. Longer retention needs a trail or an event data store. ^[10]
• Azure Activity Log. Collected with no setup, but kept for 90 days. Longer only through a diagnostic setting exporting to Log Analytics or storage. Logs of actions inside resources (for example, reading a secret from Key Vault) are not collected by default. ^[11]
• Google Cloud Audit Logs. Admin Activity logs are always written and cannot be turned off. Data Access logs, except for BigQuery, are off by default. ^[12] Admin logs are kept for 400 days, the rest for 30 days by default. ^[13]

The review also checks whether logs from all accounts, subscriptions or projects are collected in one place, whether they are protected from deletion, and whether there are alerts on critical events: root sign-in, policy changes, logging turned off.

6. Kubernetes and managed services

For EKS, AKS and GKE the basics are checked: whether the cluster API is reachable from the whole internet, how rights inside the cluster are set up (RBAC), whether pods hold rights that lead into the cloud account, whether the cluster version is current. There are separate CIS Benchmarks for this too. ^[7] For managed databases, functions and queues the review covers public access, encryption and the rights of the service accounts they run with.

7. CI/CD and pipeline access

A build and deployment pipeline often has wider rights than any person on the team. If a long-lived admin key sits in GitHub Actions, GitLab CI or Azure DevOps secrets, anyone who can change the pipeline file gets that key. A better option is OIDC sign-in, where the provider issues a short token valid for one job only and no cloud key is stored in GitHub. AWS, Azure and Google Cloud support it. ^[14] The review also checks who can change the pipeline and whether deployment to production is limited to specific branches.

AWS, Azure and Google Cloud penetration testing rules

As of October 2026:

• AWS. No prior approval is needed for services on the permitted list, including EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS and Fargate. For other services you contact AWS Support. Prohibited: DoS and DDoS, including simulated ones, port, protocol and request flooding, DNS zone walking in Route 53, and S3 bucket and subdomain takeover. Covert attack simulations, command and control (C2), simulated phishing and malware testing need a separate request at least two weeks before the start. ^[1]
• Microsoft Azure. No pre-approval has been required since June 15, 2017, but the Microsoft Cloud Unified Penetration Testing Rules of Engagement apply. Prohibited: DoS of any kind, access to other tenants and storage, using credentials that are not your own, fuzzing with excessive traffic, phishing Microsoft employees or phishing others through Microsoft services, and post-exploitation against Microsoft’s own services. DDoS resilience can be tested through partners Microsoft recommends. ^{[2] [3]}
• Google Cloud. You do not need to notify Google. The test must affect only your projects and follow the Google Cloud Acceptable Use Policy and Terms of Service. ^[4]

All three sets of rules concern the provider’s infrastructure. Permission to test your resources comes not from the provider but from you: in writing, with scope and contacts. The rules change, so before the start open the current pages linked in the sources.

What we need from you

• Scope. The list of AWS accounts, Azure subscriptions or Google Cloud projects, regions and environments. Separately, what is out of scope: third-party SaaS services, partner accounts.
• A read-only role. In AWS this is usually the SecurityAudit and ViewOnlyAccess managed policies, in Azure the Reader and Security Reader roles at subscription or management group level, in Google Cloud the Viewer and Security Reviewer roles at organization or project level. Granted for the duration of the review and revoked afterwards.
• For a pentest. The list of public addresses and domains, an agreed entry point (for example, a developer-level account) and what is forbidden: changing data, deleting resources, testing during business hours.
• An architecture overview. Even a simple diagram: where the application runs, where the databases are, how deployment works.
• Contacts. Who receives urgent messages and who can stop the test.
• Written permission. Signed by someone with the authority to grant access to the company’s cloud accounts.

The full preparation checklist with a table of owners is in how to prepare for a pentest.

What you get

• A short summary for management: what was found, how it threatens the business, what to fix first.
• Each finding separately: which account or project, which resource, evidence, impact, severity and how to fix it, with a reference to the CIS Benchmarks item or provider guidance where relevant.
• For a pentest: attack paths described step by step from the entry point to the data.
• A list of what was and was not tested, so nobody assumes an account nobody looked at is safe.
• Immediate notice of critical issues, for example a public bucket with personal data, without waiting for the report.
• A retest (a repeat check after fixes), if it is part of the agreed scope.

What to do with the report next is covered in what to do after a pentest. A wider picture of company security, from processes to access, comes from a Security Assessment.

Checklist before a cloud review

• All accounts, subscriptions and projects are listed, including test ones.
• A read-only role is granted for the duration of the review.
• The AWS root account and all admins have MFA.
• S3 Block Public Access is on at account level, any public storage is explained.
• Repositories and pipelines are checked for long-lived cloud keys.
• SSH, RDP and databases are not open to the whole internet.
• Logs from all accounts are kept longer than the default 90 days in one protected place.
• Kubernetes cluster APIs are not reachable from the whole internet without need.
• Your provider’s current testing rules are checked.
• Permission is signed and a contact who can stop the test is named.

Download the preparation checklist (PDF)PDF · A4

FAQ

Do I need permission from AWS, Azure or Google Cloud for a pentest?

As of October 2026 no prior approval is needed to test your own resources, but each provider’s rules must be followed. AWS separately requires a request two weeks ahead for covert attack simulations, C2 and simulated phishing. DoS is prohibited at all three.

How does a configuration review differ from a cloud pentest?

A review through a read-only role shows what is misconfigured by comparing it with the CIS Benchmarks. A pentest checks whether those mistakes can be exploited and how far an attacker gets. A review is cheaper and safer, a penetration test gives evidence of real attack paths.

Can the check break the production system?

A configuration review cannot: it only reads settings. A pentest works within agreed limits with no DoS and no data deletion, and risky steps are agreed separately. A fresh backup and a contact who can stop the test are still needed.

Are the provider’s built-in tools enough?

AWS Security Hub, Microsoft Defender for Cloud and Security Command Center in Google Cloud are useful for ongoing configuration monitoring. But they do not see attack chains, the logic of your applications or keys in code outside the cloud. Turn them on, and run an independent check periodically.

How long does a cloud review take?

It depends on the number of accounts, subscriptions or projects and on whether a pentest is needed. A review of one small environment can take a few days, several environments with a pentest take longer. Timing and price are fixed before the start, once the scope is agreed.

References

1. AWS: Penetration Testing aws.amazon.com
2. Microsoft Learn: Penetration testing (Azure) learn.microsoft.com
3. Microsoft Cloud Unified Penetration Testing Rules of Engagement microsoft.com
4. Google Cloud Security FAQ support.google.com
5. AWS: Shared Responsibility Model aws.amazon.com
6. Microsoft Learn: Shared responsibility in the cloud learn.microsoft.com
7. Center for Internet Security: CIS Benchmarks cisecurity.org
8. AWS: Security best practices in IAM docs.aws.amazon.com
9. AWS: Blocking public access to your Amazon S3 storage docs.aws.amazon.com
10. AWS: Working with CloudTrail event history docs.aws.amazon.com
11. Microsoft Learn: Activity log in Azure Monitor learn.microsoft.com
12. Google Cloud: Cloud Audit Logs overview docs.cloud.google.com
13. Google Cloud: Cloud Logging quotas and limits docs.cloud.google.com
14. GitHub Docs: OpenID Connect docs.github.com