DevOps Multi-Accounting: AWS, GCP, Azure Client Consoles

GetAntik editorial team · October 7, 2026 · 9 min read

How DevOps teams managing multiple clients' AWS, GCP, Azure and Cloudflare consoles use isolated browser profiles to avoid session mix-ups and MFA chaos.

The problem an incognito tab won't fix

An engineer supporting 10–15 clients typically juggles 2–3 cloud accounts per client: production AWS, staging, sometimes a separate billing account. Add Cloudflare, Vercel, DigitalOcean, and monitoring dashboards like Datadog or Grafana Cloud, and you end up with 40–60 web consoles that need regular logins — often from different devices and by different people on the team.

The default approach is to keep all sessions in one browser and switch accounts via logout/login or account-switcher extensions. That works fine for five clients. At fifteen, specific problems show up:

• Cross-contaminated cookies and cache. The browser stores tokens and local console settings in one shared profile. The AWS console sometimes "remembers" the last-used region or IAM role from a different account — an engineer changes a security group in the wrong place without realizing it.
• MFA codes mixed together. If TOTP secrets sit in a single password manager without context, it's easy to type a code into the wrong window — especially at the end of a shift.
• No audit trail of who logged in when. When a client's support ticket says "someone deleted an S3 bucket at 11:40 PM," the answer "someone on the team" satisfies nobody.
• Handing off a client to another engineer. Resignation, vacation, rotation — and now you need to quickly figure out which 8 consoles that person had access to, then either revoke access or hand the sessions to a colleague without re-doing MFA enrollment everywhere.

None of this gets solved by opening an incognito tab. Incognito just doesn't persist cookies after you close it — that's amnesia, not isolation.

What a profile-based approach actually changes

An antidetect browser in this scenario isn't about "fooling" AWS or Cloudflare — there's no rule-bypassing here, nor should there be: every client cloud account is a legitimate, separately billed account, and the agency or freelancer works in it under contract. The tool solves a different problem: giving each client an isolated browser container — separate cookies, separate MFA storage, separate history — so sessions physically can't cross over, instead of relying on an engineer's discipline and memory.

In practice it looks like this: one profile equals one client context (for example, "Client A — AWS prod" and "Client A — AWS staging" kept separate if the risk levels differ). In GetAntik, a profile stores:

• cookies and local session storage for the console — nothing gets lost between launches, no need to log in fresh every day;
• an entry in the 2FA key vault tied to that specific profile — the TOTP code is generated right next to the console it belongs to, not in a shared authenticator app where lines are easy to confuse;
• bookmarks to the relevant console sections — handy for routine billing or quota checks;
• when needed, a dedicated outbound IP through an attached proxy — useful if a client has an IP allow-list for console access, or if you need to check how a regional Cloudflare edge behaves.

Where this pays off the most

IP allow-lists. Some companies restrict access to a cloud console or VPN panel to a list of approved addresses. If an engineer works from a laptop that switches networks often (coffee shop, home, office), that's a constant headache — asking to add an IP one day, getting locked out at a bad moment the next. A profile with a fixed proxy solves this: the IP seen by the client's console stays stable regardless of which network the engineer is physically on. For more on picking the right proxy type for this kind of job, see choosing a proxy type for the task.

Handing clients off between engineers. Rotation on a project is routine: one specialist goes on vacation, another picks up support. Without profile isolation, that means collecting passwords again, re-doing MFA enrollment in each of the client's 5–8 consoles, updating access in the task tracker. With profiles, transferring access is just a change of profile ownership: the colleague gets a working session with all the bookmarks and saved keys intact, and the previous engineer loses access at the same moment.

Incident investigation. If something goes wrong in a client's cloud console — a resource gets deleted, a firewall config changes — it helps to quickly pull up who logged into that profile and when. The team's activity log shows this per profile, not as one combined browser history on an engineer's machine.

Automating routine checks. Part of DevOps routine is scripts that log into a console to pull metrics, check quotas, or download billing reports where there's no decent API or it's paywalled/limited. Running this inside isolated profiles with a local API for Puppeteer or Playwright over CDP means the script runs in the same context as a live engineer — same cookies, same IP — without the console flagging it as a suspicious login from a new device. This is covered in more detail in the piece on automating profiles with Puppeteer and Playwright.

How to organize profiles in practice

For a team of 4–6 engineers and 15–20 clients, a sensible scheme looks like this:

1. One profile per client environment, not one profile per client overall. Production and staging go in separate profiles if the access level or IP restrictions differ.
2. Group by client, not by platform. It's easier to search "Client B" and see all their consoles — AWS, Cloudflare, Grafana — together than to dig through an "AWS" tab across twenty different clients.
3. A role, not a shared password. The team sets roles: who can only log in and view metrics, who can change infrastructure, who has billing access. This isn't a replacement for IAM roles inside AWS itself — it's a filter at the level of "who on the team can even open this profile."
4. Profile limits per person. An intern or junior shouldn't physically be able to open the production console of a client they don't work with — easier to enforce this at the profile level than to rely on them not finding the password.

For structuring this once you're dealing with not 20 but 200+ profiles, there's a separate breakdown in the article on organizing large profile pools.

Table: what changes compared to a shared browser

Common mistakes

One shared root account for the whole team. The temptation to set up a single admin-level account and hand the password to everyone saves time at the start and creates a problem for years: there's no way to tell who did what, and you can't revoke one person's access without breaking it for everyone else. Even if the cloud provider already has separate IAM users configured, it matters just as much that each engineer has their own browser container with its own MFA binding, rather than a shared logged-in profile on a passed-around laptop.

MFA secret shared in a group chat or ticket. A QR code or TOTP secret for a client's console sometimes gets dropped into Slack "just in case" — and it stays there forever, visible to everyone who's ever been in that channel. Attaching a 2FA key to a specific profile with data encrypted on the device removes that temptation: the key never needs to be sent as plain text, it lives alongside the session itself.

Forgetting to cut access during offboarding. An engineer leaving a project is exactly when "temporary" access tends to linger longest: the task tracker access gets revoked, but they can still open the client's console because the browser session on their personal device was never reset. If profiles are objects in a shared team pool rather than personal files on a laptop, revoking access is a single click, not a round of messages asking "who else has the password for this client?"

Mixing production and staging in one profile. Saving on profile count backfires when an engineer changes a limit in production thinking they're in staging, because the console UI looks identical and the wrong tab happened to be open.

What a small team should start with

If you have 2–3 engineers and 8–10 clients, you don't need a full role hierarchy on day one. A reasonable minimum setup:

• create a profile for each client environment (prod separate from staging);
• move MFA for cloud consoles out of a shared authenticator into these profiles;
• assign the "admin" role to people who actually touch infrastructure, and "member" with a limited profile set to everyone else;
• turn on the activity log so there's something to check during an incident instead of guessing after the fact.

All of this fits comfortably on a plan up to 100 profiles — usually plenty for a small team with a dozen clients. Current limits and prices are on the pricing page, and the profile manager with roles and permissions is described on the team features page.

FAQ

Does this violate AWS's or Cloudflare's terms of service? No, as long as these are legitimate, separate client accounts you have contractual access to. The antidetect part of the browser just isolates sessions and fingerprints between profiles — it's not an attempt to pass off one account as several or bypass a block, it's a way to avoid mixing up accounts that are genuinely separate.

Do I need a separate proxy for every console? Not always. A proxy matters specifically where a client has an IP allow-list configured, or where the login region matters (checking CDN behavior, for instance). For ordinary consoles without such restrictions, you can work without an attached proxy — cookie and MFA isolation already solves the main problem.

What about syncing profiles between a work laptop and a home computer? Profiles sync across devices on the same account, with data encrypted locally using the account password — the server can't read it. If you have specific questions about this scenario, it's worth checking the article on syncing profiles across devices.

What about automated checks that need to run without a human — overnight billing checks, for example? The same profile used for live engineering work can be run through the local API — via Puppeteer, Playwright, or Selenium over CDP. It's not a separate headless session starting from scratch that the console might flag as a suspicious new device, but a continuation of the same session with the same cookies and fingerprint.

devopsmulti-accountingcloud consolesteam access2fa