CLOUD SECURITY
Cloud Penetration Testing Services for AWS and Azure
Senior pentesters test your AWS and Azure environments by hand, chaining identities, permissions and misconfigurations into proven attack paths, then show you exactly how to close them.
What a cloud test covers
- IAM, Entra ID and service principal privilege escalation
- Public storage, snapshots and exposed data
- Serverless functions, APIs and Kubernetes
- CI/CD pipelines, secrets and key management
- Visibility in CloudTrail and Azure Monitor logs
Fixed scope, fixed tester-days, fixed price, agreed before testing starts.
Scoped and quoted per engagement. Priced in tester-days, no hidden fees. How the test works · See a sample report
Cloud penetration testing is a manual, authorized attack simulation against your AWS or Microsoft Azure environment that shows what a real attacker could reach from a leaked key, an exposed service or a compromised identity. Senior pentesters chain misconfigurations into proven attack paths, then hand you the evidence and the fixes.
Your provider secures the underlying infrastructure, but you configure the identities, permissions, storage, network rules, pipelines and secrets. That’s where our cloud security testing focuses, always within the provider’s published rules and your written scope.
Key takeaways
- A cloud pentest targets what you control: identities, permissions, configuration, data and the services you deploy.
- AWS (for services on its permitted list) and Microsoft let customers test their own resources without pre-approval, and both ban denial-of-service testing.
- Manual testing proves exploitability by chaining issues: a leaked access key, then an over-permissive IAM role, then data in storage.
- You get an Executive Summary and a Technical Report with exploitation evidence and step-by-step fixes, and a retest is available after fixes.
Manual, not scanned
Senior pentesters chain misconfigurations into real attack paths and prove each one with evidence.
Within provider rules
Every test follows AWS and Microsoft testing policies and your written scope, with no denial-of-service testing.
Evidence you can act on
You get an Executive Summary and a Technical Report with exploitation evidence and step-by-step fixes, and a retest is available after fixes.
Clear timeline
Testing typically takes one to three weeks plus a few days for the report, with critical findings reported during the test.
What Is Cloud Penetration Testing?
Cloud penetration testing is a controlled attack on the resources you run in a public cloud, carried out with your written permission to find and prove exploitable weaknesses before someone else does. It targets the cloud control plane (identities, roles, policies and management APIs) as well as the workloads and data you host.
NIST SP 800-145 defines three cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). The model sets the scope: on IaaS the test covers operating systems, network rules and identities, while on PaaS, serverless and SaaS such as Microsoft 365 it concentrates on configuration, identity and access.
The shared responsibility model sets the boundary. AWS describes it as security “of” the cloud versus security “in” the cloud: AWS protects the infrastructure, while the customer configures security groups and uses IAM to apply permissions. Microsoft states that customers always retain responsibility for data, endpoints, accounts and access management. A cloud pentest tests exactly that customer side.
Know what you want tested?
Send us your scope and get the test type, tester-days, timeline and a fixed price in writing. Prefer to compare first? See our prices.
How is a cloud pentest different from a network test?
A cloud pentest attacks identities, permissions and managed services through the provider’s APIs, while a network test attacks hosts, ports and services reachable over IP. In the cloud, a stolen token often matters more than an open port. If you need testing of IP ranges, firewalls and internal hosts, see our network penetration testing service.
| Cloud pentest | Network test | |
|---|---|---|
| What’s tested | AWS accounts and Azure subscriptions: IAM, storage, serverless, containers, databases and pipelines | Hosts, network devices and services on external and internal IP ranges |
| Main attack surface | Identities, access keys, tokens, trust relationships and management APIs | Open ports, exposed services, unpatched software and weak protocols |
| Typical findings | IAM privilege escalation, public storage, secrets in functions or pipelines, cross-account trust abuse | Vulnerable services, default credentials, weak segmentation, legacy protocols |
| Access needed | Read-only audit role and test identities, plus an external or assumed-breach starting point | IP ranges or hostnames; VPN or on-site access for internal testing |
What we test in your cloud environment
We test identities, storage, network exposure, serverless, Kubernetes, pipelines, secrets and logging in every account you put in scope.
Identity and access management
We review IAM policies in AWS and role assignments in Microsoft Entra ID and Azure RBAC, then try to escalate privileges. Role chaining is a common path: one role can assume another, and the second can do far more than anyone intended.
Storage and data exposure
We look for S3 buckets and Azure Blob containers that are public, shared too widely or reachable through a compromised identity. Snapshots, backups and database exports get the same attention, because they can hold full copies of production data.
Network exposure and segmentation
We map what’s reachable from the internet and between environments through security groups, network security groups (NSGs), VPC and VNet peering and private endpoints.
Serverless functions and APIs
Lambda and Azure Functions can run with broad execution roles or service accounts and read secrets from environment variables. We test API gateways and function triggers for broken authorization and injection, then check what a compromised function could do with its role. Flaws in the API logic itself are covered by our API penetration testing.
Containers and Kubernetes
We test EKS and AKS clusters against the OWASP Kubernetes Top 10 (2025), including K02 Overly Permissive Authorization Configurations, K03 Secrets Management Failures and K08 Cluster To Cloud Lateral Movement. K08 matters most here: a pod that reaches the node’s cloud credentials can reach far beyond the cluster.
CI/CD pipelines, infrastructure as code and secrets
Pipelines usually hold highly privileged credentials because they deploy your infrastructure. We check pipeline permissions, the trust between your repositories and cloud roles, and infrastructure-as-code templates and state files, which can store secrets in plain text. We also test who can read secrets in AWS Secrets Manager and Azure Key Vault, and who can use or change encryption keys.
Logging and detection
We check whether our actions show up in AWS CloudTrail and Azure Monitor, and whether key log sources are enabled at all. If our actions leave no trace in these logs, that gap goes into the report as a finding.
AWS penetration testing
AWS penetration testing targets the resources in your AWS accounts, above all IAM, because identity is the main attack surface in AWS. A single over-permissive policy can turn a low-level foothold into administrator access.
Do you need AWS approval to run a penetration test?
No, not for most services. AWS lets customers test their own AWS infrastructure without prior approval for the services on its permitted services list, which includes Amazon EC2, Amazon RDS, AWS Lambda and Amazon API Gateway. Testing AWS’s own infrastructure or services is not allowed, and services outside the list need a conversation with AWS Support or your account team first.
The same policy prohibits DoS and simulated DoS or DDoS, port, protocol and request flooding, DNS zone walking and DNS hijacking via Route 53 hosted zones, and S3 bucket or subdomain takeover. Covert red team simulations and hosting command-and-control infrastructure require a Simulated Events form, submitted at least two weeks before the start. We check your scope against these rules before any work begins.
Typical AWS attack paths we test:
- Instance credentials: server-side request forgery or command execution on EC2 used to read role credentials from the Instance Metadata Service (IMDS), especially where IMDSv1 is still allowed.
- Over-permissive IAM: wildcard policies, iam:PassRole combined with rights to create or update Lambda functions or EC2 instances, and role trust policies that let a low-privilege identity assume an administrative role.
- Public S3 buckets and shared snapshots: data, EBS snapshots or RDS snapshots exposed publicly or to other accounts.
- Lambda secrets: credentials stored in function environment variables, often readable by any identity allowed to view the function configuration.
Here’s how those combine. An access key leaked in a public repository belongs to a CI user. That user can assume a deployment role, and the role can read a production S3 bucket. Each step alone might be rated medium. Together they lead straight to production data, and we prove it with evidence.
We’ve seen this in practice: in our Black Friday readiness case study, a black-box test of a retailer’s web store, mobile API and AWS environment found a publicly accessible S3 bucket whose backup logs held internal API keys that allowed lateral movement.
Azure penetration testing
Azure penetration testing focuses on Microsoft Entra ID, Azure role assignments and the services in your subscriptions, because in Azure a single identity can span cloud resources and Microsoft 365.
Do you need Microsoft’s permission to test Azure?
No. Since June 15, 2017, Microsoft no longer requires pre-approval or notification to pentest your own Azure resources. Every test must still follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement and stay within your own tenant. The rules prohibit any denial-of-service testing (including simulations), testing tenants you don’t own, using credentials that aren’t yours, network-intensive fuzzing against Azure assets, phishing Microsoft employees, and post-exploitation against Microsoft online services beyond an initial proof of concept. Vulnerabilities in Microsoft’s own services are reported to MSRC.
What we test in Azure:
- Entra ID and Microsoft 365 identity paths: app registrations and service principals with excessive API permissions, guest access, consent settings, and gaps in conditional access and MFA.
- Managed identities: what a compromised virtual machine, function or web app can do with the identity assigned to it.
- Storage account keys and SAS tokens: keys that grant full account access, and long-lived or over-scoped shared access signatures in code or URLs.
- NSGs and exposure: open management ports, public endpoints and VNet peering that breaks intended segmentation.
Running workloads on another cloud provider? Tell us about your environment and we’ll confirm what we can scope.
How a cloud penetration test runs
1. Scoping and provider rules check
We agree on accounts or subscriptions, services, testing perspectives and time windows, then check the scope against AWS and Microsoft rules. Anything that needs provider notice, such as an AWS Simulated Events form for red team work, is planned here.
2. Access setup
You grant a read-only audit role for configuration evidence and test identities for assumed-breach scenarios. Where the scope includes it, we also test from the outside with no credentials, to see what an external attacker finds.
3. Discovery and configuration review
We map identities, services, trust relationships and exposed endpoints using techniques such as Cloud Service Discovery (T1526) and Cloud Infrastructure Discovery (T1580). Misconfigurations become leads for the next stage, not findings on their own.
4. Manual exploitation and attack-path chaining
Testers turn leads into access, for example through Valid Accounts: Cloud Accounts (T1078.004), Steal Application Access Token (T1528) and Data from Cloud Storage (T1530).
5. Reporting
Critical findings are reported to you during the test, not held back for the final document. The full report follows a few days after testing ends.
6. Retest
Once you’ve fixed the issues, a retest is available to confirm which ones are closed.
Cloud penetration test vs cloud security assessment
A cloud security assessment checks your settings against a benchmark, while a cloud penetration test proves what an attacker can actually do with the weaknesses it finds. Some teams call the first one a cloud security audit or configuration review.
| Cloud penetration test | Cloud security assessment | |
|---|---|---|
| Goal | Show how far an attacker can get and what they can reach | Measure configuration against a security benchmark or policy |
| Method | Manual attack simulation that chains weaknesses across identities and services | Setting-by-setting review, usually with automated checks |
| Output | Proven attack paths with evidence and fixes | List of passed and failed controls |
| Proves exploitability? | Yes | No |
| When to choose | You need to know your real exposure, or need testing evidence for customers and auditors | You need broad coverage of settings against a baseline |
Many teams run both. The assessment gives breadth, and the pentest shows which gaps turn into real access.
What automated cloud scanners miss
Automated cloud scanners list individual misconfigurations, but they can’t prove how those issues combine into an attack path or what the exposed data means to your business. For the wider comparison, see penetration testing vs vulnerability scanning.
Chained permissions
A scanner may flag a user’s iam:PassRole permission and the same user’s right to create Lambda functions as two separate medium issues. A tester sees that together they let the user attach an administrator role to a new function and run code with it, and proves it.
Business context of data
A tool sees a readable bucket. A tester checks what’s inside, test fixtures or customer records, and rates the finding accordingly.
Identity federation and cross-account trust
Trust between AWS accounts, Entra ID tenants, identity providers and CI systems crosses boundaries that single-account checks don’t follow. An attack path can start in one account and end in another.
What you receive
You receive two documents: an Executive Summary for leadership and a Technical Report for your engineers.
- Executive Summary: overall risk in plain language and the most serious findings, written for the board and management.
- Technical Report: a list of vulnerabilities with exploitation evidence for each, including chained paths such as leaked key, CI user, deployment role, production bucket.
- Step-by-step remediation: fix steps for each finding in your AWS or Azure environment.
- Retest: once you’ve fixed the issues, a retest is available to confirm which ones are closed.
How long does a cloud penetration test take?
A typical cloud penetration test takes one to three weeks of testing plus a few days for the report, and critical findings reach you during the test. Effort is measured in tester-days and depends on:
- the number of AWS accounts or Azure subscriptions
- the services in scope, such as serverless, databases, storage and identity
- Kubernetes clusters and container workloads
- perspectives: external, assumed breach, or both
A single account with a handful of services sits at the lower end. Several accounts with Kubernetes and identity federation push the effort up. Complex infrastructure and cloud testing (AWS/Azure) at Pentestica is priced at $5,000–$12,000+, based on tester-days, with no hidden fees. For all ranges, see our prices, or request a pentest quote for your scope.
When do you need a cloud penetration test?
You need a cloud penetration test before a new environment goes live, after changes to who can access what, and whenever customers, investors or regulators ask for evidence of security testing.
Before go-live or migration
test a new environment, or one you’ve just moved from on-premises, before real data lands in it.
After a major architecture or IAM change
new accounts, a landing zone redesign, a new identity provider or a move to Kubernetes all create new paths.
Security questionnaires
enterprise customers and investors running due diligence may ask for a recent pentest report.
Compliance evidence
PCI DSS v4.0.1 requirement 11.4 calls for penetration testing at least every 12 months and after significant changes, DORA Articles 24 and 25 require financial entities to run a testing program, and NIS2 Article 21 requires risk-management measures (see NIS2 penetration testing). A pentest is evidence for your own audit and risk assessment, not a compliance certificate. Financial entities selected for advanced testing should look at threat-led penetration testing.
After an incident
confirm that the path an attacker used is closed and that no similar ones remain.
What can you check before you hire us?
Three things you can verify for yourself: what the report looks like, who does the testing, and how a real engagement went.
What does the report look like?
Every report opens with an executive summary for management, then one page per finding: severity and CVSS score, evidence of exploitation, business impact and step-by-step remediation. A retest is available after fixes, and the updated report shows which findings are closed. Browse our sample pentest report with every section explained.
Who tests your systems?
Senior pentesters from our team of 25, holding hands-on offensive security certifications such as OSCP and OSCE alongside CEH, CISA, CISM and CRISC.
Retail platform before Black Friday
A black-box test of a web store, mobile API and AWS environment ahead of peak traffic, with every finding fixed and confirmed in a retest.
Frequently asked questions
Does AWS allow penetration testing without approval?
Yes, for services on AWS’s permitted services list, such as EC2, RDS and Lambda, but not for AWS’s own infrastructure. DoS testing, request flooding and S3 bucket or subdomain takeover are prohibited. Covert red team simulations need a Simulated Events form submitted at least two weeks ahead.
Do I need Microsoft's permission to pentest Azure?
No. Microsoft dropped pre-approval on June 15, 2017, and notification isn’t required. You must follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement, test only your own tenant, and avoid prohibited activities such as denial-of-service testing and phishing Microsoft employees.
Can automated tools or AI replace a manual cloud pentest?
Not today. Automated tools and AI assistants help with discovery and check many settings quickly, but they report issues one at a time. A manual test chains permissions across accounts and services and proves each attack path with evidence.
How often should we run a cloud penetration test?
Plan on at least once a year and after significant changes, such as a migration, a new account structure or a major IAM redesign. That matches the PCI DSS interval. Fast-moving environments may justify testing key areas more often.
How much does a cloud penetration test cost?
Complex infrastructure and cloud testing (AWS/Azure) at Pentestica is priced at $5,000–$12,000+, in tester-days with no hidden fees. The price depends on accounts, services, Kubernetes clusters and perspectives in scope. For every range, see our penetration testing cost page.
Do you test Kubernetes and containers?
Yes. We test EKS and AKS clusters and container workloads against the OWASP Kubernetes Top 10 (2025), covering RBAC, secrets, workload configuration, segmentation and exposed components, with special attention to paths from a pod to cloud credentials.
Fixed-price quote
Request a cloud penetration test
Tell us what to test. You get a written scope, the number of tester-days and a fixed price before any testing starts. No hidden fees.
See a sample report first (18-page PDF, no email required)
Complex infrastructure and cloud tests (AWS/Azure): $5,000–$12,000+, priced in tester-days. All prices
See cloud pentest cost benchmarks for market ranges.
What happens after you send it
- Tell us what to test Tell us which AWS accounts or Azure subscriptions you run, your deadline and any compliance requirement.
- Get a written scope and price We reply by email with scoping questions or a fixed quote in tester-days.
- Test, report, retest Most tests take 1–3 weeks plus a few days for the report. Critical findings are reported during testing. Retesting after fixes is available.
- OSCP, OSCE and CISSP certified testers
- 500+ penetration tests
- Aligned with OWASP WSTG, PTES and NIST SP 800-115
- Executive summary and technical report