One of the most important aspects of an AWS pentest (or any type of pentest, really) is determining the scope of the engagement. AWS engagements are difficult to scope in the sense of traditional scoping methods, such as the number of IP addresses, number of users, size of the web application, and so on. It requires a little bit of a more personal touch, because, sure, almost regardless of the size, we could just run some scanners and call it a day, but that's not what pentesting is all about and it will reflect poorly on your own company if this is how you take care of things. Lots of manual effort needs to go into an AWS pentest to really dig deep and find the vulnerabilities that are there, so it is important to scope appropriately so that you have enough time to perform an in-depth assessment, but not too much time where you are wasting your own time and your client's money.

It is difficult to provide an exact methodology behind scoping an AWS engagement, but the following list of questions can help provide context around the client's environment to help determine the size of it:

• Are you using multiple AWS accounts for this environment?
  • How many?
  • Are you interested in having them all tested, or just a portion?
• What kind of access will be provided to the environment?
• What/how many AWS services are you using?
• How many regions do your resources span across?
• How many EC2 instances/Lambda functions are in use?
• How many IAM users, roles, and groups do you have?
• How do your users access your environment? (regular IAM users, SSO | AssumeRole, and so on)

Beyond those questions, more specific questions can be asked about the other AWS services they are using. How many RDS databases do you have? It is not a useful question if they don't even use the RDS service, but something like—how many Lightsail instances do you have? might be. This might not normally come up, unless the client tells you that they use Lightsail.

These questions are meant to provide you with a basic idea of how large the AWS environment you are planning to attack is. This can then help you determine an estimated timeline that it would take to fully test.

These questions are very contextual, though, and they will likely vary on a per-client basis. This is because, for example, you might be testing an environment with 5,000 EC2 instances, 300 Lambda functions, and 100 RDS databases, but the client only wants to provide you access to a single user who has IAM permissions and some Lightsail permissions. The numbers behind EC2, Lambda, and RDS are nearly irrelevant at this point, because unless you can escalate your privileges in the environment, you won't be touching those services, based on the client's expectations.