Working in several AWS console accounts at the same time

For years the AWS Management Console enforced one identity per browser. Opening the staging account in a second tab logged the production account out of the first, and everyone developed a workaround: a second browser, a private window, a container extension, or a role switch that had to be undone before touching anything else. The workarounds were so universal that they stopped looking like workarounds.

That constraint has been lifted, but only partly, and the shape of what replaced it is worth understanding before rebuilding a workflow around it. There are now three mechanisms that all look like "being in several accounts", they have different limits, and two of them have a clock attached.

Multi-session, and its five identity ceiling

AWS documents this directly. The console supports signing in to up to five different identities simultaneously in a single web browser, and those identities can be any combination of root, IAM or federated roles, in different accounts or in the same account. Each identity opens its own instance of the console in a new tab.

It is opt in rather than default. The documentation describes turning it on either by choosing Turn on multi-session in the account menu inside the console, or by choosing Enable multi-session at console.aws.amazon.com. Adding an identity afterwards is three steps: choose the account name in the navigation bar, choose Add session, choose Sign in, and a new tab opens for the credentials.

Two details in that documentation matter more than they look.

The first is that turning multi-session on changes the console URL. AWS states that the console URL then contains a subdomain, giving the example https://000000000000-aaaaaaaa.us-east-1.console.aws.amazon.com/console/home?region=us-east-1, and says directly that bookmarks and console links should be updated. Any runbook, wiki page or alert that deep links into the console is written against the old form, and those links do not carry the session identity with them.

The second is that opting in is browser specific. The setting lives in browser cookies, which is also why clearing cookies turns it off. A laptop with Chrome for work and Safari for everything else has to be opted in twice, and a wiped profile is back to one identity.

Role switching, and the clock nobody reads

Role switching predates multi-session and still does a job multi-session does not: it uses one set of credentials to reach many accounts, which is the whole point of a central identity account.

The part that surprises people is the session duration. AWS documents that when switching roles in the console, the session lasts one hour by default, while IAM user sessions are twelve hours by default. The role session granted is the role's maximum session duration or the time remaining in the user session, whichever is less. The documentation gives the worked example: with a role maximum of ten hours and eight hours already spent signed in, the remaining four hours of the user session is what the role gets, not the ten.

Role chaining tightens it further. Using the credentials from one role to assume another limits the session to one hour regardless of the maximum session duration configured on the individual roles, and AWS states this applies to console role switching, the CLI and API operations alike.

There are also flat exclusions. The root user cannot switch roles. Users must be granted permission to switch roles by policy. And a role that requires an ExternalId value cannot be reached by switching in the console at all, only by calling the AssumeRole API, which supports that parameter.

The two mechanisms do combine. AWS notes that once opted in to multi-session, the path is to choose Add session and then select Switch role, so a role switch can open in its own tab rather than replacing the current identity.

Three mechanisms, three different jobs

Mechanism	What it gives	Ceiling	The catch
Multi-session	Several identities live at once in one browser	5 identities	Opt in per browser, console URLs gain a subdomain
Role switching	Many accounts from one set of credentials	Policy defined	1 hour default console session, 1 hour on role chaining
Separate browser sessions	Isolation at the browser level	None imposed	Separate cookie stores to manage and keep signed in
IAM Identity Center portal	Central place to federate into roles	Assignment defined	Still lands in the console, so the above still applies

The choice is less about preference than about what the work looks like. Occasional visits to an account, in an organisation with a proper identity account, belong in a role switch. Sustained parallel work in three or four accounts, such as comparing a production and a staging configuration side by side, is what multi-session is for. Work that spans several unrelated organisations, where the identities have nothing to do with each other, is where browser level separation keeps being necessary, because five identities in one browser assumes those five identities can safely share a browser.

Federating into more roles from the access portal

There is a fourth path in the same documentation, and it is the one most organisations of any size end up on. AWS describes an optional flow for federating into additional roles: sign in to the additional role from the AWS IAM Identity Center access portal or an existing single sign on portal, then choose the account name in the console to view the additional sessions available.

The distinction is worth holding on to. The access portal is where assignments live, so it is the place that decides which accounts and which permission sets a person can reach at all. The console is where the resulting sessions land. Multi-session governs how many of those sessions can be alive in one browser at the same time, which is five.

For a platform team, this ordering is what makes a large account estate workable. The number of accounts an engineer is entitled to reach can be large, because that is an assignment question. The number they can hold open at once is five, because that is a browser question. Building a runbook that assumes someone is simultaneously in seven accounts will not survive contact with the second limit, and splitting the work in stages, or across separated browser sessions, is what makes it run.

The workarounds people are still running

Multi-session did not retire the old habits, partly because the old habits predate it by years and partly because some of them still cover cases it does not.

Private windows remain the fastest way to reach one account once without disturbing anything. Storage is discarded on close, so nothing is left behind and nothing is overwritten. The cost is repeating the entire sign-in, including any multi-factor step, and that cost is paid every single time, which is why it stays a tool for one-off access rather than a way of working.

A second browser is the other durable habit. It is still genuinely useful when the boundary being enforced is organisational rather than technical, for example a customer's account that should never share a cookie jar with anything internal. The maintenance cost is real: the second browser accumulates its own extension set, its own update schedule and its own set of saved passwords, and the one that gets neglected is usually the one holding the most sensitive access.

Container extensions covered the gap before multi-session existed, by isolating cookies per named container inside one browser. They work, and they are also an extension, which means an additional piece of software with broad access to browsing sitting in the path of every console session. Whether that is acceptable is a security decision rather than a convenience one, and it is worth making deliberately rather than by default.

What none of these address is the rest of the browser. That is the part multi-session leaves untouched.

Where the browser is still the constraint

Multi-session solved the AWS console. It did not solve the day around it.

An engineer working across several AWS accounts is rarely only in the console. The IAM Identity Center access portal, a monitoring dashboard, a CI system, a source host, a customer's own admin panel and a ticket tracker are all in the mix, and several of them have exactly the problem the console used to have: one session per site, per browser profile. A contractor with two clients does not have two AWS logins, it has two of everything.

The standard answer has been browser profiles, and Chrome's documentation is accurate about what they give: separate bookmarks, history, passwords and other settings per profile. It works. The costs are that each profile is a full browser instance with its own memory and extension set, and that switching profiles switches every service at once, even when only the AWS account needed to change.

The alternative that has grown up around this pattern is to keep each service in its own container inside a single window, with its own cookie store and its own session. Two AWS consoles, two Identity Center portals and two of everything else become entries in a list rather than two browsers. Grouping those containers per client or per environment is the part worth looking at closely, and Workspaces describes how that grouping works. For an engineering workflow the adjacent question is what else can live next to the console in the same window, which is what Built-in terminal covers.

Telling production from staging before it matters

Every one of these mechanisms creates the same hazard: several near identical consoles open at once, differing only by a number in a corner.

A few habits reduce it to something manageable. Set a distinct account alias on every account so the sign-in page and the account menu carry a name rather than a twelve digit number. Keep one region per environment where the architecture allows it, because the region selector is far more visible than the account ID. Where separation is at the browser level, the container or the profile can be named and coloured, which puts the environment in the window frame rather than in a dropdown.

The bookmark question deserves its own pass. Once multi-session is on and URLs carry an account subdomain, a bookmark saved from one identity points at that identity's console instance. Shared runbook links written in the old format still resolve, but they resolve into whichever session the browser picks, which is exactly the ambiguity worth removing from a document that tells someone to delete something.

What to change first

Turn on multi-session in the browser used for AWS work and re-save the console bookmarks in their new subdomain form, then decide separately whether the identities involved belong in one browser at all. When the work spans two organisations rather than two accounts, the separation needs to sit below the console, and a browser that gives each service and each login its own container, such as SpaceDeck, is the shape that holds.