ByteBulletin

[tooling] · · 2 min read

awsmux runs one AWS CLI command across hundreds of accounts in parallel — safely

A new open-source tool fans out AWS CLI commands across a fleet of accounts with STS verification, an approval gate for mutations, and built-in MCP support for AI agents.

By ByteBulletin Editors · Editorial Team

[tooling]

Running the same AWS CLI command across dozens or hundreds of accounts has typically meant writing brittle shell loops, waiting ages for sequential execution, or stitching together custom orchestration. A new open-source tool called awsmux aims to fix that with a single binary that fans out commands across your entire fleet in parallel — safely.

By default, awsmux uses 100 parallel workers (configurable with --concurrency), verifies every identity with STS before running anything, and streams merged results back to the terminal. It discovers profiles from your existing ~/.aws/config and ~/.aws/credentials files, with SSO, static keys, and credential_process all working unchanged because awsmux always executes through the aws CLI.

Safety as a first-class feature

What sets awsmux apart from ad-hoc scripts is its safety model. Mutating operations are blocked by an approval boundary: the tool categorizes every AWS API call as read-only, mutating, or destructive, and anything destructive (or mutating, depending on config) returns a plan that requires manual approval via awsmux approve <plan-id>. The approval token is bound to the plan's SHA-256 hash, so tampering is refused. This even works for commands whose risk isn't obvious from their name — s3 mv is destructive because it deletes the source, and sts assume-role* is considered mutating because it mints credentials.

Stable exit codes (0 = all succeeded, 1 = some failed, 2 = config error, 3 = approval required, 4 = stopped by threshold) make it CI- and agent-friendly.

Built for AI agents

awsmux ships with a Model Context Protocol (MCP) server via awsmux mcp, giving AI agents five structured tools (list_aws_targets, plan_aws_operation, execute_aws_plan, get_aws_execution, cancel_aws_execution) instead of a raw shell. The agent uses them autonomously: ask "find every security group open to the world" and it will fan out a read-only call across all accounts, then propose a destructive fix as a plan for you to approve.

In a benchmark with 150 sessions comparing Claude Opus 4.8 agents against a raw-shell baseline across a 100-account sandbox fleet, the awsmux arm was 1.3x–2.9x cheaper, 2.3x–5.4x faster, and used up to 7.4x fewer output tokens (all Holm-adjusted p < 0.05). The tool also includes a fully local sandbox fleet (100 emulated accounts on LocalStack) for zero-risk testing.

Getting started

Prerequisites are Go, Docker, and the aws CLI. Clone the repo and run:

make build

This builds ./bin/awsmux. For the sandbox fleet:

make build fleet-up

Then point awsmux at a profile from the sandbox config. Or for real AWS, just run:

awsmux run -- ec2 describe-security-groups

For the MCP server, register with Claude Code or add to your claude_desktop_config.json:

{
  "mcpServers": {
    "awsmux": {
      "command": "/absolute/path/to/awsmux",
      "args": ["mcp"]
    }
  }
}

awsmux is MIT-licensed and available on GitHub.

SHARE

← All stories