April 4, 2026 · Tim Fraser, Cloud Operations Lead

Managing Client AWS Accounts as an MSP — A Practical Guide

If you manage AWS infrastructure for multiple clients, you already know the daily friction. Five browser tabs with five different AWS consoles. Credential switching. Trying to remember which client has that NAT Gateway you meant to check. A mental map of who's running what, tracked in spreadsheets that are always slightly out of date.

This is the reality for most MSPs and cloud consultants managing 5-20 client accounts. It works when you have three clients. By the time you have eight, things start to slip through.

Here's a practical guide to staying on top of it.

The cross-account access pattern

If you're still logging into each client's AWS console with separate IAM users, stop. The correct pattern is cross-account IAM roles.

Your setup should look like this:

• Your management account has your IAM identity (user or SSO)
• Each client account has an IAM role (e.g. MSP-ReadOnly or MSP-Operations) that trusts your management account
• You assume the role into each client account as needed, using the CLI or console role-switching

This gives you a single identity, a clear audit trail in each client's CloudTrail, and the ability to revoke access cleanly when an engagement ends.

The trust policy on the client side should include an ExternalId condition — a unique string per client that prevents confused deputy attacks. This matters more than most MSPs realise, especially when your management account ID is known to multiple clients.

Naming and tagging discipline

Across multiple accounts, you need consistent conventions or you'll lose hours tracking down basic information.

At minimum, tag every resource with:

• Client — which engagement this belongs to
• Environment — prod, staging, dev
• Owner — the team or person responsible
• ManagedBy — your MSP name, so it's clear what you're responsible for

Tag discipline is tedious. It's also the single biggest time-saver when a client calls asking "what are we paying for?" and you need an answer in ten minutes, not two hours.

The monitoring problem

Each client probably has their own monitoring setup — or none at all. Some use CloudWatch alarms. One has Datadog. Another has nothing and relies on you to notice when things break.

The temptation is to standardise everyone onto one monitoring platform. In practice, this is hard to enforce when clients have their own preferences and budgets. What you actually need is a reliable way to review each client's environment regularly without spending your entire week clicking through AWS consoles.

A weekly review across eight accounts — checking security groups, cost trends, resource health, and recent changes — done manually, that's an entire day. Every week.

Credential management that won't get you fired

Some ground rules:

• Never store client credentials in plain text. Use AWS SSO, or at minimum ~/.aws/credentials with named profiles and MFA enforced.
• Rotate regularly. If you're using long-lived access keys (you shouldn't be), rotate them quarterly at minimum.
• Principle of least privilege. You probably don't need AdministratorAccess in every client account. For monitoring and reporting, read-only is sufficient. Separate your "look at things" access from your "change things" access.
• Offboard cleanly. When a client engagement ends, remove the cross-account role. Don't leave it sitting there for "just in case."

Keeping track of who has what

Beyond the console, you need a register of your client environments. It doesn't need to be fancy — a spreadsheet or Notion table with:

• Client name and AWS account ID
• Role ARN and External ID
• Key services running (EC2, RDS, ECS, Lambda)
• Monthly spend range
• Last review date
• Any known risks or open items

Update it weekly. When a client calls, you can answer questions without fumbling through console tabs trying to remember their setup.

Setting up plainfra per client

The approach that works best for MSPs is simple: set up a separate plainfra Core subscription for each client's AWS account. Each subscription costs $79/month, and each one connects to one client account using the same read-only cross-account IAM role pattern described above — with a unique ExternalId per client.

Once connected, each client gets an automated weekly health report delivered by email as a PDF. The report covers security posture, cost trends, and operational risks, prioritised by severity. You can forward the report to the client directly, or review it yourself first and act on the findings.

Between reports, you can log into each client's plainfra and ask questions in plain English: "Show me all security groups with public ingress." "Which RDS instances don't have automated backups?" "What changed this week?" The answers come back in seconds, not hours.

The weekly reports are where this pays for itself. That day-long manual review across all your clients becomes a focused session: scan each report, note what changed, flag what needs attention. The structure is consistent across clients, so you're not context-switching between different monitoring tools — just working through each report in turn.

For an MSP managing multiple accounts, it's the difference between proactive management and hoping nothing breaks before you get around to checking.