Vouch for Startups

Set up a new AWS account with federated access instead of IAM users

A new AWS account does not need IAM users. IAM users come with long-lived access keys that never expire and can be committed to Git, leaked in logs, or compromised by malware. Rotation is a manual process, and offboarding requires finding and deleting every key the user created. AWS supports OIDC federation as an alternative: authentication happens through the identity system your team already uses.

If your team uses Google Workspace, Vouch bridges it directly into AWS. One vouch login gives every developer short-lived credentials for AWS, SSH, GitHub, Docker registries, databases, and more – all tied to their Google Workspace identity, all backed by a hardware key.

Already have AWS accounts and a growing team? This page is for day-one setups. For rolling Vouch out across an existing organization – service enablement checklists, onboarding blocks, offboarding – use the Team Rollout playbook. Comparisons with IAM Identity Center and Builder ID are at the end of this page.

What you get

After following this guide, your team will have:

• No IAM users – Every developer authenticates with their Google Workspace account + YubiKey.
• No access keys – AWS credentials are temporary (1 hour) and never written to disk.
• No credential files – No ~/.aws/credentials, no SSH keys to distribute, no GitHub PATs.
• Instant offboarding – When someone’s Google Workspace account is deactivated, their AWS access ends immediately.
• Full audit trail – Every AWS API call in CloudTrail shows which developer made it.

Step 1 – Get YubiKeys for the team

Order YubiKey 5 series (opens in new tab) keys for each team member. Any FIDO2-compatible security key works, but YubiKey 5 series is recommended.

Step 2 – Enroll the team

The first person to log into Vouch from your Google Workspace domain becomes the organization owner.

Owner enrollment:

# Install the CLI
brew install vouch-sh/tap/vouch
brew services start vouch

# Enroll (first person becomes the org owner)
vouch enroll --server https://us.vouch.sh

Team member enrollment:

Each team member installs the CLI and enrolls with the same server:

brew install vouch-sh/tap/vouch
brew services start vouch
vouch enroll --server https://us.vouch.sh

As long as they authenticate with the same Google Workspace domain, they join the same organization. No invite codes or admin approval needed for initial enrollment. (Enrolling an additional key later asks for a tap from a key that is already registered.)

Step 3 – Deploy AWS federation

Follow the AWS integration guide to register the OIDC provider and deploy a role with a *@yourcompany.com email-domain trust condition. For permissions, start with ReadOnlyAccess and broaden to exactly what your team needs – don’t default to PowerUserAccess. You can tighten access further later (see Tips for restricting access for single-user restrictions, ABAC session tags, and similar patterns).

When the role exists, copy its ARN – you’ll need it in Step 4.

Step 4 – Configure each developer’s CLI

Each developer runs one command to configure their AWS profile:

vouch setup aws --role arn:aws:iam::123456789012:role/VouchDeveloper

Replace the account ID with your own (printed in the CloudFormation stack outputs).

Step 5 – Log in and verify

vouch login
aws sts get-caller-identity --profile vouch

You should see your email address in the assumed role ARN:

{
  "UserId": "AROA...:alice@yourcompany.com",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/VouchDeveloper/alice@yourcompany.com"
}

From here, aws s3 ls --profile vouch, cdk deploy, terraform apply, and any other AWS tool works with no additional setup.

Step 6 – Add more integrations

With the same vouch login session, configure the rest of your toolchain:

Each integration is configured with one command. After setup, all integrations share the same vouch login session.

What happens when someone leaves

Deactivate their Google Workspace account and their Vouch-issued access ends. There are no access keys, authorized_keys entries, or PATs to find and revoke. The exact sequence, expiry timeline, and the optional AWS-side deny statement are in When someone leaves on the rollout playbook.

Scaling up

As your team grows, switch to the Team Rollout playbook – it covers service enablement, onboarding, and offboarding as an ongoing process. The usual thresholds:

• 5–15 people: Manual user management works fine. SCIM is optional.
• 15–50 people: Set up SCIM provisioning to automate onboarding and offboarding with Google Workspace.
• Multiple AWS accounts: See Multi-Account AWS Strategy for chaining into dev/staging/prod accounts through a single hub.
• CI/CD gates: Add human approval gates to production deployments.
• Compliance requirements: See Security and the Threat Model for details on how Vouch protects credentials.

Why not IAM Identity Center?

AWS IAM Identity Center (opens in new tab) (formerly AWS SSO) is AWS’s own solution for federated access. It is designed for organizations managing permission sets across multiple AWS accounts. The differences for a small team:

For 20+ people with per-account permission sets across multiple AWS accounts, use IAM Identity Center (Vouch can federate into it). For a small team, Vouch requires less setup: one CloudFormation template and one command per developer.

Why not AWS Builder ID?

AWS Builder ID (opens in new tab) provides individual developer identity for AWS services. The key difference: Builder ID is individual identity, not organizational identity. It does not know about your Google Workspace domain, your team structure, or your offboarding process. You cannot restrict AWS access to “people who work at my company” using Builder ID alone.

Vouch federates your organization’s identity (Google Workspace domain) into AWS, so access is tied to employment by design.