Switching Cloud Accounts: AWS, GCP and Azure Fast

Amaresh Pelleti
switching cloud accounts across AWS, GCP and Azure with a single shell function

Switching cloud accounts across AWS, GCP and Azure is three unrelated problems wearing one trenchcoat. AWS calls them named profiles. GCP calls them configurations. Azure barely gives you a name for it at all — you’re switching subscriptions inside one login, or isolating state directories if you actually need two separate identities. Nobody remembers three different mechanisms, so most people end up running aws sts get-caller-identity before every deploy just to check they’re not about to hit the wrong account.

This is the actual mechanism behind each one, verified on the CLI, plus a shell function that switches all three at once so you stop needing to remember any of it.

Switching Cloud Accounts on AWS: Named Profiles

AWS profiles, documented here, live in two files: ~/.aws/config (settings) and ~/.aws/credentials (keys), both INI-formatted with [profile name] sections (the default profile skips the profile prefix in config, but not in credentials):

# ~/.aws/config

[default]

region = us-east-1



[profile work]

region = us-east-1

sso_start_url = https://example.awsapps.com/start

sso_region = us-east-1

sso_account_id = 111122223333

sso_role_name = DeveloperAccess



[profile personal]

region = us-west-2

List what’s actually configured, and check what a given profile resolves to, before you trust it:

$ aws configure list-profiles

default

work

personal



$ aws configure list --profile personal

NAME       VALUE                    TYPE                    LOCATION

profile    personal                 manual                  --profile

access_key ****************EST2     shared-credentials-file

secret_key ****************EST2     shared-credentials-file

region     us-west-2                config-file             ~/.aws/config

Every AWS CLI command takes --profile name, but typing that on every command gets old fast. Set AWS_PROFILE instead and every subsequent command in that shell uses it:

$ export AWS_PROFILE=personal

$ aws configure list

NAME       VALUE      TYPE  LOCATION

profile    personal   env   AWS_PROFILE

AWS_PROFILE beats whatever’s in the config file, which is exactly what you want for a per-terminal override.

⚠️ The SSO gotcha: an SSO-based profile with no cached session fails with Error loading SSO Token: Token for <url> does not exist — not a permissions error, not a typo, just an expired or missing session. Run aws sso login --profile work to fix it, not aws configure.

Switching Cloud Accounts on GCP: Named Configurations

gcloud’s configurations are the equivalent — a full bundle of account, project and defaults, switchable by name. :

$ gcloud config configurations create work

Created [work].



$ gcloud config configurations create personal

Created [personal].



$ gcloud config configurations list

NAME      IS_ACTIVE  ACCOUNT  PROJECT  COMPUTE_DEFAULT_ZONE  COMPUTE_DEFAULT_REGION

default   True

personal  False

work      False

Set values inside a specific configuration without activating it first:

$ gcloud config set project work-project-id --configuration=work

Updated property [core/project].

Switch which one is active:

$ gcloud config configurations activate personal

Activated [personal].

And the same environment-variable escape hatch as AWS exists here too — CLOUDSDK_ACTIVE_CONFIG_NAME overrides the active configuration for that shell without touching the persisted state:

$ CLOUDSDK_ACTIVE_CONFIG_NAME=work gcloud config get-value project

Your active configuration is: [work]

work-project-id

This matters for scripts and CI: you can run a one-off command against a different configuration without permanently activating it and without a --configuration flag on every gcloud subcommand that supports one.

Switching Cloud Accounts on Azure: Subscriptions, Not Profiles

Azure doesn’t really do named profiles. az login authenticates one identity, and that identity can see every subscription its account has access to. Switching “accounts” day to day usually means switching subscriptions within that one login:

$ az account list --output table

Name          SubscriptionId    State    IsDefault

Work-Prod     11111111-...      Enabled  True

Work-Staging  22222222-...      Enabled  False



$ az account set --subscription "Work-Staging"

That covers most people. But if you genuinely need two separate identities — a work tenant and a personal tenant, logged in simultaneously without one az login clobbering the other — Azure CLI reads its entire state from a directory controlled by AZURE_CONFIG_DIR, documented at learn.microsoft.com (default ~/.azure). Point it somewhere else and you get a fully isolated Azure CLI, tokens and all:

$ AZURE_CONFIG_DIR=~/.azure-work az login

$ AZURE_CONFIG_DIR=~/.azure-personal az login

Each one logs in and caches its session independently. Set AZURE_CONFIG_DIR before any az command and that command runs against that identity’s isolated state, the same shape as AWS_PROFILE and CLOUDSDK_ACTIVE_CONFIG_NAME.

The Part Nobody Automates: Switching All Three at Once

Here’s the actual fix for “the problem is remembering them”: one shell function that sets all three environment variables together, so a single word switches your entire terminal’s cloud identity.

# ~/.bashrc or ~/.zshrc

cloudenv() {

  case "$1" in

    work)

      export AWS_PROFILE=work

      export CLOUDSDK_ACTIVE_CONFIG_NAME=work

      export AZURE_CONFIG_DIR="$HOME/.azure-work"

      ;;

    personal)

      export AWS_PROFILE=personal

      export CLOUDSDK_ACTIVE_CONFIG_NAME=personal

      export AZURE_CONFIG_DIR="$HOME/.azure-personal"

      ;;

    *)

      echo "usage: cloudenv work|personal" >&2

      return 1

      ;;

  esac

  echo "cloudenv -> $1"

}
$ cloudenv work

cloudenv -> work

$ cloudenv personal

cloudenv -> personal

$ cloudenv bogus

usage: cloudenv work|personal

Add more cases as you add accounts. This is a plain shell function, not a plugin or a tool to install — it works in bash and zsh as-is, and every AWS, gcloud and az command you run after calling it picks up the right identity automatically, because all three tools read these same environment variables.

Make the Active Account Visible in Your Prompt

The environment-variable approach has one real failure mode: you switch, forget you switched, and run something against the wrong account an hour later. Fix it by putting the active profile in your prompt so it’s always visible, not something you have to remember to check:

# ~/.bashrc

PS1='[\${AWS_PROFILE:-none}] \w \$ '

That renders as [work] ~/project $ — updates automatically every time cloudenv changes AWS_PROFILE, no extra step required. Extend the same pattern to show $CLOUDSDK_ACTIVE_CONFIG_NAME if you’re switching GCP configs just as often.

What This Doesn’t Solve

This pattern switches default identity for a shell. It doesn’t stop you from overriding it per-command with --profile or --subscription, and it doesn’t replace credential rotation or least-privilege IAM — a cloudenv work that quietly has admin access everywhere is still a cloudenv work you should fix at the IAM layer, not just the shell layer.

If you’re also juggling Kubernetes clusters alongside these cloud accounts, that’s a separate switching problem with its own tool — see our kubectx guide for the equivalent pattern with kubectl contexts. And if .bashrc itself has become the thing you’re afraid to touch, our Linux file permissions guide and finding what’s using a port cover two other everyday shell headaches the same way — real commands, real gotchas, not just theory.

Frequently Asked Questions

Q: What’s the difference between AWS_PROFILE and –profile?
A: --profile name sets it for one command. export AWS_PROFILE=name sets it for every command in that shell session until you change or unset it. Both read from the same ~/.aws/config and ~/.aws/credentials files.

Q: Does gcloud have something like AWS_PROFILE?
A: Yes — CLOUDSDK_ACTIVE_CONFIG_NAME. Set it as an environment variable and it overrides whichever configuration is currently active via gcloud config configurations activate, without changing the persisted state.

Q: How do I run two Azure identities at once without logging out?
A: Point AZURE_CONFIG_DIR at two different directories and run az login in each. Azure CLI reads its entire state — tokens included — from that directory, so each one stays fully isolated.

Q: Why does my AWS SSO profile fail with a token error?
A: The cached SSO session expired or was never created. Run aws sso login --profile <name> to fix it — aws configure won’t help here, since the profile’s settings are already correct.

Q: Is a shell function safer than a tool like direnv for this?
A: A manual cloudenv work is explicit — you know exactly when your identity changed. Directory-based auto-switching (direnv, etc.) is convenient but can silently activate the wrong account just by cd-ing into a folder. For anything touching production, explicit beats automatic.

Quick Summary:
– AWS: named profiles in ~/.aws/config/credentials, switch with --profile or export AWS_PROFILE=name
– GCP: named configurations via gcloud config configurations, override per-shell with CLOUDSDK_ACTIVE_CONFIG_NAME
– Azure: subscriptions within one login via az account set, or fully isolated identities via AZURE_CONFIG_DIR
– All three read from environment variables, so one shell function (cloudenv) can switch all three together
– Put the active profile in PS1 so you see which account you’re in instead of having to remember or re-check it

Stop running aws sts get-caller-identity as a paranoia check before every command. Switching cloud accounts shouldn’t require remembering three different mechanisms — put the account name in your prompt, and you’ll see it before you need to ask.

Related guides

Leave a Reply