PS Product SecurityKnowledge Base

☁️ AWSGoat — AWS Cloud Lab

Intro: AWSGoat is most useful when you want to see how web flaws, AWS IAM mistakes, storage exposure, metadata abuse, and container breakout can connect into one cloud attack path.

What this page includes

  • what AWSGoat is and what it teaches;
  • how to deploy it safely;
  • what to practice as a Product Security or Cloud Security learner;
  • how to turn the offensive path into defensive review notes.

What it is

AWSGoat is a deliberately vulnerable AWS environment that uses Terraform to deploy application and infrastructure components into your AWS account. It is designed to help teams practice:

  • cloud pentesting and red-teaming thinking;
  • IaC review;
  • secure coding review;
  • detection and mitigation thinking.

A key strength of AWSGoat is that it does not stay purely at the web layer. It connects classic application issues to AWS-native privilege paths.

Why it is valuable

Use AWSGoat when you want learners to stop thinking of AppSec and cloud security as separate tracks.

Good outcomes from this lab:

  • understanding how SSRF or credential exposure becomes a cloud incident;
  • learning how S3, IAM, API Gateway, Lambda, EC2, and ECS misconfigurations interact;
  • practicing both attack path review and control design.

Best fit

Persona Fit Why
AppSec engineer High Teaches how app flaws can lead into IAM or storage compromise
Cloud Security engineer High Good for IAM, metadata, and storage abuse reasoning
Product Security engineer High Great for review notes, threat models, and release-readiness learning
Newcomer Medium Valuable, but easier after Juice Shop or TerraGoat

Run model

AWSGoat is not a self-contained Docker lab. The normal pattern is:

  • use a Linux VM or workstation as the control point;
  • authenticate to a disposable AWS account;
  • deploy the vulnerable environment into AWS via Terraform.

That makes it highly realistic, but it also means you must plan for cost, IAM safety, and cleanup.

Prerequisites

  • isolated AWS account or training-only sub-account;
  • AWS CLI configured for the lab identity;
  • Terraform available on the host;
  • Linux shell available if you use the manual workflow;
  • willingness to destroy everything when finished.
  • use a dedicated AWS account or AWS Organization sandbox;
  • avoid using your main admin profile directly for day-to-day browsing;
  • tag everything with Owner, Purpose, and DestroyBy;
  • document the initial IAM permissions before deployment;
  • keep one teardown command ready before the first apply.

Manual setup example

git clone https://github.com/ine-labs/AWSGoat
cd AWSGoat
aws configure
cd modules/module-1
terraform init
terraform apply --auto-approve

Use the module approach when you want controlled learning scope. Start with one module, take notes, destroy it, then move on.

CI-driven deployment example

The project also supports a GitHub Actions-based deployment flow where AWS credentials are placed in repository secrets and a Terraform Apply workflow deploys a selected module. That is useful for demos, but for learning and review discipline I generally recommend the manual Terraform path first, because it forces the learner to see the infrastructure lifecycle directly.

Suggested first study pass

Session 1 — understand the environment

  • list AWS services involved;
  • identify the public entry points;
  • identify where credentials can appear;
  • draw the trust boundaries.

Session 2 — identify likely escalation paths

  • ask where application flaws could expose AWS execution context;
  • ask which roles, buckets, functions, or containers matter most;
  • identify what the blast radius would be if one component were compromised.

Session 3 — defender follow-up

  • write down the logs you would need;
  • write down the IAM conditions that would reduce the path;
  • write one release gate you would add to CI/CD;
  • write one cloud detection rule and one runtime detection rule.

What to practice in your notes

Use AWSGoat to answer questions like:

  • could this workload reach instance metadata or cloud API credentials?
  • what permissions are excessive for the compute identity?
  • what data stores are reachable after compromise?
  • what would be the earliest detection point?
  • what compensating controls would break the chain?

Good follow-up exercises

Common mistakes

  • deploying it in a shared account with real workloads;
  • treating the lab as a web challenge only and ignoring IAM and storage;
  • forgetting to record what permissions the lab required to create resources;
  • not destroying resources after the exercise.

Cleanup reminder

Destroy from the same module directory you used to deploy:

terraform destroy --auto-approve

Then confirm that no buckets, roles, instances, or other resources remain in the lab account.

References

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.