Cloud Infrastructure Penetration Testing: AWS / Azure / GCP
For the servers, containers, and services you run in the cloud. We review how they are configured, then with your authorization test what an attacker with a foothold could actually reach.
Get a Quote →What is a cloud infrastructure penetration test?
If you run servers, containers, data stores, or serverless functions in AWS, Azure, or Google Cloud, the way they are configured matters more than any single software version. Most cloud incidents come from configuration and identity mistakes, not from a vendor's exploit: a storage bucket left readable, a role with far more permission than it needs, a management interface open to the internet, or a secret committed into an image. A cloud infrastructure penetration test is an authorized review of those configurations combined with controlled, assumed-breach testing of what they would allow.
We start from the position of an attacker who already holds a modest foothold, because that is the realistic starting point, and we show how far that foothold reaches: which data it can read, which identities it can assume, and whether it can cross from one account into another.
What we review
Identity and Access
IAM roles and policies, privilege-escalation paths, unused permissions, and trust relationships between accounts.
Exposed Storage and Compute
Public buckets, blobs, snapshots, and internet-facing instances or management endpoints.
Network Controls
Security groups, network ACLs, peering, and segmentation between environments.
Secrets Handling
Keys and credentials embedded in code, images, environment variables, or configuration.
Containers and Serverless
Cluster and function configuration, over-broad execution roles, and workload isolation.
Logging and Monitoring
Whether an intrusion would be recorded, and whether anyone would see it.
How we test
Testing is scoped to the customer side of the shared responsibility model and to each provider's testing policy, with your written authorization and an agreed emergency contact. From an assumed-breach position we attempt to escalate privilege, reach sensitive storage and secrets, and move laterally between accounts, exploiting findings only where the Statement of Work permits. Destructive actions, denial-of-service, and anything that would touch production data integrity stay out of scope by default.
What you provide
The configuration review runs from a read-only security-audit role in each account. The assumed-breach phase uses one deliberately limited, developer-style identity that you provision. We agree the exact roles up front for AWS, Azure, and GCP alike. The full list is in our guide to what access a cloud test needs.
AWS, Azure, and Google Cloud
- —Each AWS account, Azure subscription, or GCP project counts separately
- —Development, staging, and production each count as distinct scope
- —IAM, storage, network, secrets, containers, serverless, and logging
- —Scoped to each provider's testing policy; authorization confirmed first
Priced by the number of accounts, subscriptions, or projects in scope. For eleven or more we scope it with you. Scope it in the quote builder →
Infrastructure, identity, or both
This test covers the resources you run in a cloud provider. If your email, files, and user sign-ins live in Microsoft 365 or Google Workspace, the cloud identity assessment covers that control plane, and the two are frequently scoped together. For background on the discipline, see our guide to cloud penetration testing.
Based in New York. Working Nationwide.
Grid32 is headquartered in Jersey City, New Jersey and tests cloud infrastructure for organizations across the United States. Engagements are led by senior, U.S.-based, certified engineers and conducted remotely. We work alongside your cloud and platform teams rather than around them, and coordinate every active step.