Work Across AWS Accounts Like Browser Tabs
Stop the AWS profile shuffle. Query prod in one tab, debug staging in another, check dev in a third. All your sessions, all at once.
The Daily AWS Profile Dance
Let me paint a picture that's probably happening on your screen right now:
# Terminal 1
export AWS_PROFILE=prod-read-only
aws dynamodb query --table-name Users --key...
# "Hmm, need to check staging"
# Terminal 2
export AWS_PROFILE=staging
aws dynamodb scan --table-name Users-staging...
# "Wait, what was that prod value again?"
# Terminal 3
export AWS_PROFILE=prod-read-only
# "No wait, I need the write profile"
export AWS_PROFILE=prod-admin
# "Actually, let me check dev first"
aws sso login --profile dev
# "Session expired. Of course."
Sound familiar? Here's what's actually happening:
The Real Cost
A senior engineer spends ~45 minutes/day managing AWS contexts.
- • That's 3.75 hours/week
- • 195 hours/year
$29,250 of engineering time annually
(at $150/hour)
What If AWS Profiles Worked Like Browser Tabs?
Here's the mental model: You don't log out of Gmail to check your work email. You just open another tab. That's exactly how Dynomate works with AWS.
Every Tab Is Its Own Universe
Each tab maintains its own:
- AWS profile and credentials
- Region selection
- Connection state
- Query history
- Results
The Result:
No cross-contamination.
No profile confusion.
No accidental prod queries.
How We Built This (And Why Others Haven't)
Most DynamoDB tools treat AWS profiles as a global setting. Change your profile? Everything switches. It's like if changing your Slack workspace logged you out of all your other workspaces.
// What others do (simplified)
class DynamoDBTool {
constructor() {
this.client = new DynamoDBClient({ profile: globalProfile });
}
switchProfile(newProfile) {
// Rebuilds everything 😱
this.client = new DynamoDBClient({ profile: newProfile });
this.clearAllQueries();
this.resetUI();
}
}
// What we do
class DynomateTab {
constructor(profile, region) {
// Each tab gets its own client
this.client = new DynamoDBClient({ profile, region });
this.sessionManager = new SessionManager(profile);
this.queryHistory = new QueryHistory();
}
// No global state to worry about
}
This isn't just a UI trick. It's a fundamental architectural decision that enables real multi-session work.
The Features That Actually Matter
SSO That Just Works™
Remember clicking "Allow" in your browser 47 times a day? We fixed that:
- Unified SSO flow: Authenticate once per profile, use everywhere
- Smart token refresh: We'll renew your session before it expires
- Visual expiration warnings: See exactly when each session expires
- One-click re-auth: Session died? Click to fix. No terminal required
Cross-Region Operations
Your data doesn't live in one region. Neither should your tools:
Morning standup checklist: ✓ US-East-1 (primary): Check user table health ✓ EU-West-1 (GDPR): Verify deletion jobs completed ✓ AP-Southeast-1: Monitor latency metrics ✓ US-West-2 (DR): Confirm replication lag Time with profile juggling: 12 minutes Time with multi-session: 90 seconds
Smart Profile Detection
We read your ~/.aws/config
and ~/.aws/credentials
. All your existing profiles just appear:
- Complex role chains: We handle them
- MFA requirements: Built-in prompt
- Temporary credentials: Full support
- Custom credential providers: If AWS CLI can use it, so can we
Real Impact Stories
The On-Call Engineer
"Last week's incident: user data inconsistency across regions. With Dynomate, I had all three regions open in tabs, comparing user records side-by-side. Found the issue in 5 minutes. The old way? I'd still be copying item IDs between terminals."
— Alex, SRE at a Gaming Company
The Migration Team
A fintech team used multi-session during their single-table design migration:
- Tab 1 Legacy table structure (prod)
- Tab 2 New single-table design (staging)
- Tab 3 Migration verification queries
- Tab 4 Rollback queries (just in case)
Result: 3-day migration completed without a single credential mix-up.
The Debugging Detective
Support engineer investigating customer issues:
- 1. Check production data (read-only profile)
- 2. Reproduce in staging (admin profile)
- 3. Test fix in dev (local profile)
- 4. Verify in production again
All in one window. Four tabs. Zero context switches.
The Cognitive Load Calculator
Let's quantify what profile switching actually costs:
Task | Traditional Way | Multi-Session |
---|---|---|
Check item in 3 environments | 3 profile switches + 3 queries | Open 3 tabs, run queries |
Compare prod vs staging | Copy data, switch profile, paste, compare | Side-by-side in 2 tabs |
Debug cross-region issue | 4+ terminal windows, constant switching | All regions visible at once |
Verify deployment | Script with profile loops | Visual verification across tabs |
The Bottom Line
18 min
Saved per debugging session
468 hrs
Saved per year (10 engineers)
$70,200
Recovered productivity
For a team of 10 engineers, each debugging 3x per week
But Wait, There's More (Actually Useful Stuff)
Tab Templates
Save your common tab configurations:
name: "Morning Health Check"
tabs:
- profile: prod-read
region: us-east-1
table: Users
query: "pk = 'STATS#DAILY'"
- profile: prod-read
region: eu-west-1
table: Users
query: "pk = 'STATS#DAILY'"
- profile: monitoring
region: us-east-1
table: MetricsTable
query: "pk = 'ALERTS#TODAY'"
One click, all tabs open with queries ready.
Session Status Bar
Always know where you are:
No more "which environment am I in?" moments at 2 AM.
Keyboard Navigation
Because reaching for the mouse breaks flow:
- Cmd+T New tab
- Cmd+1-9 Jump to tab
- Cmd+D Duplicate current tab
- Cmd+Shift+P Profile switcher
The Question You're Actually Asking
"Do I really need this, or can I just be more careful with profiles?"
You can absolutely be more careful. You can also:
- • Write more detailed runbooks
- • Add more confirmation prompts
- • Create better profile naming conventions
- • Hope everyone follows them
Or you can use tools that make the right thing the easy thing.
The best processes are the ones you don't have to think about. Multi-session doesn't make you better at managing profiles. It makes profile management invisible.
See It For Yourself
The best way to understand multi-session is to feel it. Open Dynomate, connect to three different AWS accounts, and watch how natural it feels. Like tabs should have always worked this way.
No credit card • Just better AWS workflows • Cancel anytime
The Technical FAQ
"How do you handle credential isolation?"
Each tab runs in its own credential scope. We use the AWS SDK's built-in credential providers but instantiate separate clients per tab. No credential leakage between tabs.
"What about rate limits?"
Each tab's requests are isolated. If you hit rate limits in prod, your staging tab keeps working fine.
"Does this work with AWS SSO, IAM roles, and temp credentials?"
Yes, yes, and yes. If AWS CLI supports it, we support it.
"Memory usage with many tabs?"
~8MB per tab. Open 20 tabs and use less memory than a single Slack window.
"Can I save my tab layout?"
Yes. Save workspace layouts and restore them later. Perfect for incident response playbooks.
Stop juggling profiles. Start shipping features.
— The Dynomate Team