Running Claude Code Agents Against AWS: The Right Way

Claude Code is remarkably effective at AWS operations. It can write CloudFormation templates, debug Lambda functions, manage S3 buckets, configure ECS services, and troubleshoot networking issues. Give it AWS credentials and a task, and it will figure out the API calls needed.

That’s the appeal and the danger. “Figure out the API calls” means the agent will use whatever permissions you’ve given it to accomplish the task most efficiently. If the shortest path involves creating a public S3 bucket, modifying a security group, or spinning up an expensive instance type — the agent does it. Not maliciously. Efficiently.

The Admin Credential Anti-Pattern

Most common Claude Code + AWS setup: the developer exports their AWS profile with AdministratorAccess into the agent’s environment. Every AWS API is available. Every resource is within reach.

Real examples of what follows:

The cleanup incident. An agent tasked with deploying a new service notices “unused” resources and helpfully deletes an old Lambda, removes an “empty” S3 bucket, and terminates an EC2 instance. The Lambda was processing webhook events. The bucket was holding nightly database backups. The EC2 instance was a bastion host.

The cost escalation. An agent optimizing database performance decides the current RDS instance is undersized and modifies it to a db.r6g.4xlarge. Monthly cost goes from $400 to $3,200. Nobody notices for two weeks.

The security exposure. An agent debugging connectivity creates a security group rule allowing all inbound traffic on 443 from 0.0.0.0/0. Problem solved. A public internet access hole created.

None of these are Claude Code bugs. The agent did exactly what it thought was needed. Nothing constrained its scope.

IAM Least Privilege for Claude Code

Building proper IAM policies requires thinking about what the agent actually needs for each specific task.

Start with the task, not the service. An agent deploying a Lambda function needs lambda:UpdateFunctionCode on that specific function ARN. Not lambda:* on *.

Scope to specific resources:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-app-deployments/builds/*"
}

This agent can read and write objects in one specific prefix of one specific bucket. It cannot list the bucket, delete objects, modify bucket policies, or access any other bucket.

Separate read from write. Many agent tasks only need read access — analyzing logs, reviewing configurations, checking resource status. Create separate IAM roles for read-only and read-write. Default to read-only. Escalate only when the specific task requires it.

Use conditions for additional constraints:

{
  "Condition": {
    "StringEquals": {
      "ec2:InstanceType": ["t3.micro", "t3.small", "t3.medium"]
    }
  }
}

The agent can launch EC2 instances, but only small ones. It can’t spin up a p4d.24xlarge because the policy doesn’t allow it. These constraints are invisible to the agent — it simply gets a permission error.

Temporary Credential Vending

Long-lived access keys are the biggest IAM anti-pattern for Claude Code. The right approach is STS AssumeRole with session credentials.

When an agent session starts, a credential vending service calls sts:AssumeRole to generate temporary credentials with a specific duration (1 hour is usually sufficient). When the session ends or credentials expire, access stops automatically.

Session tags make this powerful:

{
  "Tags": [
    {"Key": "agent-session", "Value": "sess_a8f3b21c"},
    {"Key": "developer", "Value": "jordan"},
    {"Key": "project", "Value": "backend-api"}
  ]
}

Now every CloudTrail entry shows “assumed-role/agent-deploy-role/sess_a8f3b21c” with tags identifying Jordan’s backend API session. Attribution is automatic.

What Happens When Things Go Wrong

Even with proper IAM scoping, agents occasionally do unexpected things within their allowed permissions.

Real-time CloudTrail monitoring. Set up event rules that fire when agent-tagged sessions perform specific actions. You might not care about S3 GetObject calls, but you definitely care about IAM changes, security group modifications, or resource deletions.

Session kill switch. If an agent is actively causing problems, revoking STS session credentials is instant — aws sts revoke-session-credentials invalidates all temporary credentials for that role session. The agent’s next AWS API call fails immediately.

Automated rollback. For critical resources, AWS Config rules can detect drift and trigger automated remediation. Agent modifies a security group → Config detects the change → rule reverts it automatically.

The Gateway Approach

All of this — IAM role management, credential vending, CloudTrail monitoring, session controls — can be managed manually. But it doesn’t scale well when multiple developers run multiple agents against multiple AWS accounts.

A gateway centralizes this. The agent doesn’t get AWS credentials directly. It makes requests through a gateway that:

1. Checks the request against a policy engine
2. Injects temporary, scoped credentials for the specific operation
3. Logs the operation with full session context
4. Enforces rate limits and cost controls

The agent never sees the AWS credentials. It can’t leak them, cache them, or use them for operations outside the policy. The IAM policy is the floor. The gateway policy is the ceiling.

Getting Started

If you’re running Claude Code against AWS today without proper controls:

1. Stop using admin credentials — create a task-specific IAM role with only what the agent needs
2. Switch to temporary credentials — STS AssumeRole instead of access keys
3. Add session tags — identify every API call by agent session, developer, and project
4. Set up CloudTrail alerting — know when agent sessions perform sensitive operations
5. Test the kill switch — practice revoking session credentials before you need to

These five steps use standard AWS features. They reduce your blast radius dramatically while you evaluate whether you need a more comprehensive solution.