- AWS's shared responsibility model sets the boundary: testers attack the resources you configured, never the hypervisor, the physical data centres, or the internals of a managed service.
- Most cloud pentest findings in UAE and GCC engagements are IAM privilege escalation paths, exposed storage, and instance metadata abuse, not novel exploits against AWS itself.
- AWS does not require prior authorization to test most of your own resources, but denial-of-service simulation and a handful of network stress tests still need advance coordination with AWS.
- A pentest is a snapshot on the day it ran. Pair it with continuous configuration monitoring for the gaps between engagements.
What "penetration testing AWS" actually tests
AWS's shared responsibility model splits the stack in two. AWS secures the cloud: physical facilities, the hypervisor, the network fabric, and the managed control planes behind services like RDS or Lambda. The customer secures everything built in the cloud: IAM policies, security group rules, the operating systems on EC2 instances you manage, the applications you deploy, and how you configure every managed service you turn on.
A penetration test only has authority over the second half. Testers attack the application running on your EC2 fleet, the permissions attached to your IAM roles, the exposure of your S3 buckets, the trust relationships between your accounts, and the code you have written or deployed. They cannot, and should not, attempt to break the isolation between AWS tenants or attack AWS's own infrastructure. Any vendor proposing that scope has misunderstood the model.
This distinction matters commercially too. Buyers in Dubai and across the wider GCC sometimes expect a cloud pentest to validate that "AWS is secure." It cannot, because AWS's side of the model is already independently audited under SOC 2, ISO 27001, and other certifications you can request directly from AWS Artifact. What a pentest validates is whether your side of the line holds up.
The rules AWS actually sets
AWS publishes a customer support policy for penetration testing that lists the resource types you may test without asking permission first, covering the core compute, database, storage, and networking services most environments run on. Anything outside that published list needs prior authorization from AWS before you test it, so check the current policy when scoping an engagement rather than assuming last year's list still applies.
A short list of activities is still restricted regardless of target, most notably anything that constitutes or simulates a denial-of-service attack. If a scope calls for load or resilience testing that could look like a DDoS, that goes through AWS's separate simulated event submission process, not the standard pentest policy.
There is a practical wrinkle that gets missed in scoping calls: GuardDuty and Security Hub will very likely flag the testing activity as malicious, because from a detection standpoint it is indistinguishable from a real attacker doing reconnaissance. Decide before the engagement starts whether the SOC will be told in advance (a validated, low-noise test) or kept blind (a genuine detection and response exercise). Running a full-scope test without telling anyone, then being surprised when GuardDuty stayed silent, tells you something real about your detection coverage. Running it without deciding at all just wastes everyone's time triaging alerts that were expected.
Where the findings actually cluster
Identity and access management
IAM is where most real compromise paths live, and it is also the least visible part of the attack surface to anyone who is not deliberately mapping it. Common findings include wildcard resources in IAM policies ("Resource": "*" attached to an otherwise narrow-looking policy), long-lived access keys committed to source control or baked into CloudFormation templates, and privilege escalation chains built from permissions that look harmless individually: iam:PassRole combined with lambda:CreateFunction, or the ability to attach an existing managed policy to your own user. None of these require a zero-day. They require reading the policy documents attached to every role and asking what the union of permissions actually allows.
Storage exposure
Public S3 buckets are the cliche for a reason: they keep showing up, usually through a bucket policy or ACL set permissively during initial setup and never revisited, or a bucket made public temporarily for a one-off data transfer and left that way. The less obvious variant is EBS and RDS snapshots shared publicly or across an unintended account, which hands over a full disk image or database backup without touching the running resource at all.
Web applications behind ALB and API Gateway
Most AWS-hosted applications sit behind an Application Load Balancer, API Gateway, or CloudFront, and the application itself is where a cloud pentest usually starts, not where it stops. Standard web testing methodology still applies in full: injection flaws, authentication and session handling defects, broken access control, and the OWASP Top 10 categories generally, tested directly against the application regardless of what infrastructure sits underneath it. AWS WAF in front does not remove that scope, it changes how testers reach it. A managed rule group blocks the obvious payloads, so the work shifts to encoding variations, request smuggling between the load balancer and the origin, and parameter handling the rule set was not tuned to catch. A WAF bypass alone proves nothing; it matters once it reaches a real vulnerability behind the rule.
What makes AWS-hosted web app testing different from an on-premises app is where the findings lead. An authentication bypass or injection flaw is rarely the end point; it is usually the entry into the infrastructure issues already described above. An SSRF flaw that reaches the instance metadata service turns a web bug into IAM credential theft. A file upload or command injection flaw that gets code execution on the EC2 instance behind the ALB hands the tester whatever role is attached to that instance. Scoping a web application pentest and a cloud infrastructure pentest as two unrelated engagements misses this chain almost every time; the web app tester needs the same account and network context the infrastructure tester has, or neither report reflects the real risk.
The instance metadata service
Every EC2 instance can query 169.254.169.254 to retrieve its temporary IAM credentials. If a web application on that instance has a server-side request forgery flaw, and the instance is still running IMDSv1 (which answers metadata requests without any token), an attacker who only meant to read a local file can pivot straight to the instance's IAM role and everything that role can reach. IMDSv2 requires a session token for every metadata request and closes this specific path, but plenty of AMIs and Auto Scaling launch templates still default to allowing both versions, which defeats the point.
Network boundaries and secrets
Security groups open to 0.0.0.0/0 on administrative ports, flat VPCs with no separation between production and non-production workloads, and load balancers that leak the origin server's real IP address all still turn up regularly. So does the practice of putting database credentials or API keys directly into Lambda environment variables or EC2 user-data scripts instead of Secrets Manager or Systems Manager Parameter Store, where they end up readable by anyone with describe permissions on the function or instance.
Tools do the scanning, judgement does the assessing
Open-source scanners such as Prowler and ScoutSuite baseline an account against the CIS AWS Foundations Benchmark in minutes and are a reasonable first pass for configuration drift. They are not a substitute for a manual assessment, because they report findings in isolation. The value in a proper cloud pentest is chaining low-severity items a scanner lists separately into the path an attacker would actually take: an S3 bucket that leaks internal hostnames, combined with an over-permissioned EC2 instance role, combined with a trust policy that lets that role assume a cross-account role in a connected AWS Organization account. Mapping that chain by hand, often with tools like Pacu to enumerate and test IAM privilege escalation paths, is where the engagement earns its cost.
Where a point-in-time test fits with ongoing posture
A penetration test answers one question well: could an attacker with a given starting position reach a given objective, on the day the test ran. It does not answer whether a new S3 bucket created the following week is public, or whether a developer just attached an overly broad policy to a new Lambda role. That is the job of continuous cloud security posture management, running alongside the periodic test rather than instead of it. Vulnerability scanning tools like Nessus cover the OS and application layer on your EC2 fleet; a dedicated VAPT engagement, whether scoped in Dubai or elsewhere in the GCC, covers the exploitation and chaining that scanners cannot do on their own; and automated adversary emulation platforms such as Pentera run continuously between formal tests to catch new drift before it becomes a finding in next year's report. None of these replace each other. Treating any single one as sufficient is the most common gap in UAE and GCC AWS cloud security programmes.
What assessors actually ask for
Auditors working against ISO 27001, NESA, or CBUAE expectations in the UAE and wider GCC are not looking for a clean scan output. They want a signed scope and rules-of-engagement document, a dated report with a defensible severity rating for each finding, evidence that critical and high findings were retested and closed (not just a remediation plan that was never verified), and a mapping from findings back to the relevant control set. A test that is more than twelve months old, or that predates a major infrastructure change such as a new account, a new production VPC, or a migration to containers, gets flagged as stale regardless of how clean the original result was.
Frequency and terminology
VAPT and penetration testing are often used as if they were the same thing, and in casual usage they are close enough. Strictly, a vulnerability assessment identifies and rates weaknesses without exploiting them, while a penetration test goes further and demonstrates what an attacker could actually do with those weaknesses chained together. Most serious engagements do both in sequence: assess broadly, then exploit selectively to prove impact. In UAE and GCC RFPs this distinction gets blurred often: buyers request a vulnerability assessment and a penetration test as interchangeable line items, then ask why the exploitation-based scope costs more.
On frequency, annual testing is the common baseline, but the honest answer is event-driven: retest after a new production account is created, after a major architecture change, after a security incident, or after any change to the account's trust boundaries, such as a new cross-account role or a new third-party integration with access to your environment.
The decision that actually matters
Scope a cloud pentest around trust boundaries and identity paths, not around a list of resource counts. Before signing a statement of work for a UAE or GCC engagement, confirm four things: whether the tester will map IAM privilege escalation paths and not just run a config scanner, whether the SOC's awareness of the test (blind or informed) has been explicitly agreed, whether the scope includes cross-account trust relationships if you run an AWS Organization, and whether the deliverable includes a retest of closed findings rather than a one-time list. A report that misses any of those four is a compliance artefact, not a security assessment.
