ConsoleMe: How Netflix Built a Self-Service AWS IAM Control Plane (Before Archiving It)

Hook

At peak usage, ConsoleMe managed IAM permissions across hundreds of AWS accounts at Netflix, yet the open-source version you can download today has significantly diverged from what actually runs in production—and it's being archived in March 2026.

Context

Managing AWS IAM at scale is a combinatorial nightmare. When you're operating 50+ AWS accounts (common in large enterprises practicing account-per-environment or account-per-team patterns), simple tasks become bottlenecks: developers need temporary access to debug production, engineers want to assume roles without juggling credential files, and security teams need visibility without drowning in CloudTrail logs.

Before tools like ConsoleMe, organizations typically built internal portals or forced developers through ticketing systems for every permission change. AWS console access required remembering account IDs and role ARNs. Local development meant managing ~/.aws/credentials with dozens of profiles. Netflix built ConsoleMe to solve these problems with a centralized web application that aggregates resources, provides one-click console access, and translates plain-English permission requests into properly scoped IAM policies. While AWS later introduced IAM Identity Center (formerly AWS SSO) for some of these use cases, ConsoleMe went further with self-service policy editing, automated policy generation, and flexible credential management through its companion CLI, Weep.

Technical Insight

ConsoleMe's architecture centers on resource caching and policy templating. The backend continuously syncs AWS resources (IAM roles, S3 buckets, SQS queues, SNS topics) from all connected accounts into a local cache, enabling fast search and policy suggestions without hammering AWS APIs during user interactions.

The self-service IAM wizard is where ConsoleMe shines. Instead of writing JSON policies manually, users describe their needs in structured form: "I need read access to S3 bucket production-logs in account 123456789012." ConsoleMe's policy generation engine translates this into properly scoped policies:

# Example policy generation pattern from ConsoleMe
policy_template = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                f"arn:aws:s3:::{bucket_name}",
                f"arn:aws:s3:::{bucket_name}/*"
            ]
        }
    ]
}

The system supports approval workflows, allowing administrators to review generated policies before they're applied. This is critical for compliance—changes are auditable, version-controlled, and tied to specific requesters.

Weep, the companion CLI tool, deserves special attention. It provides five different methods for serving AWS credentials locally, solving the "how do I get temporary credentials for this account" problem:

# Method 1: Credential process (most seamless)
# Add to ~/.aws/config:
[profile production]
credential_process = weep credential_process production-role

# Method 2: ECS credential provider (for Docker)
weep ecs_credential_provider

# Method 3: Metadata service (mimics EC2 metadata endpoint)
weep metadata

# Method 4: Export environment variables
eval $(weep export production-role)

# Method 5: Write to ~/.aws/credentials (traditional)
weep file production-role

Each method targets different workflows. Credential process works transparently with AWS SDKs. The metadata service approach allows legacy applications expecting EC2-style credentials to work unchanged. The flexibility is impressive—Weep detects which method suits your context and just works.

The React frontend uses a powerful visual policy editor built on top of the AWS IAM policy grammar. You can toggle between visual builder mode and raw JSON, with real-time validation against AWS policy syntax rules. The editor highlights overly permissive policies (like Resource: "*") and suggests least-privilege alternatives based on CloudTrail data if you've enabled that integration.

ConsoleMe's authentication layer supports multiple providers through a plugin architecture—ALB headers, OIDC, SAML. This matters in heterogeneous environments where different parts of your organization use different identity providers. The role credential generation happens server-side using AWS STS AssumeRole, with credentials cached briefly to reduce AWS API calls. One-click console access works by generating federated sign-in URLs with temporary credentials embedded in the token.

Gotcha

The elephant in the room: ConsoleMe is being archived in March 2026. No more feature development, bug fixes, or community support from Netflix. The announcement explicitly states the open-source version diverged significantly from Netflix's internal implementation after a major refactor, meaning you're not getting the battle-tested system actually running at Netflix.

Even before archival, ConsoleMe wasn't a simple deployment. It requires Redis for caching, a backing database (DynamoDB or SQLite), proper AWS IAM roles configured across every account you want to manage, and a non-trivial amount of configuration tuning. The documentation assumes significant AWS expertise—if you don't understand cross-account IAM role assumption, you'll struggle. Small teams (sub-10 engineers managing 2-3 AWS accounts) will find the operational overhead outweighs the benefits. AWS IAM Identity Center handles basic cross-account access with far less infrastructure. ConsoleMe's real value emerges at Netflix scale: hundreds of accounts, thousands of roles, and dedicated platform teams to maintain the system.

Verdict

Use if: You're managing 30+ AWS accounts with a platform team that can maintain forked code, you need self-service IAM with approval workflows that AWS Identity Center doesn't provide, or you're already running ConsoleMe and can commit to maintaining your own fork post-archival. The codebase is solid, the architecture patterns are instructive, and it solves real problems at scale. Skip if: You're starting fresh in 2024 or later without engineering resources to maintain a fork, you're managing fewer than 20 AWS accounts (use AWS IAM Identity Center instead), or you need vendor support and future feature development (consider commercial alternatives like Granted.dev for credential management or explore Noq as a potential successor).