Managing Client AWS Accounts as a Freelancer: The Safe Way

A client emails you their AWS root credentials in a plaintext email. "Here's the login, can you set up the deployment pipeline?" You know this is wrong, but you're a freelancer and the client wants things done fast. You log in, get to work, and now you're personally operating a root account with no MFA, no audit trail, and no separation between your access and theirs.

This is how most freelancer-client AWS relationships start. Here's how to fix it — in a way that protects both you and your client, takes minimal ongoing maintenance, and doesn't require a 3-hour conversation about AWS Organizations.

The Risks You're Taking

When you operate a client's AWS account with shared root credentials, you're exposed to liability for anything that happens in that account (accidental deletion, billing spikes, data exposure), blame for incidents you didn't cause (no audit trail means everything looks like it could be you), financial risk if the account gets compromised through the shared credentials you're using, and a professional reputation risk if things go wrong and there's no evidence trail showing proper access management.

The 30-Minute Setup for Each Client

Step 1: Secure Their Root Account (5 minutes)

Before anything else, help the client enable MFA on their root account. Walk them through it on a call — you should not hold or know the root MFA device. The client owns root. You don't. This protects both of you: they retain ultimate control, and you're not liable for root-level actions.

Step 2: Create Your IAM Role (10 minutes)

Create a cross-account IAM role in the client's account that trusts your AWS account (or your IAM Identity Center identity). This lets you access their account without sharing credentials. Define the role's permissions based on what you actually need. If you're managing infrastructure, PowerUserAccess (everything except IAM) is usually sufficient. If you need IAM management, use AdministratorAccess but with a condition requiring MFA.

The client can see exactly what permissions you have, can revoke your access instantly by deleting the role, and every action you take is logged in CloudTrail with your assumed-role identity — not "root" or a shared user.

Step 3: Enable CloudTrail (5 minutes)

If CloudTrail isn't already enabled, set it up. One management trail, all regions, delivered to an S3 bucket. This gives both you and the client a complete audit log. If something goes wrong, the trail shows exactly who did what. This protects you as much as it protects them.

Step 4: Set Up Basic Monitoring (10 minutes)

At minimum, enable AWS Budgets with alerts (so the client knows immediately if costs spike), GuardDuty (so compromised credentials are detected), and Cost Anomaly Detection (free, catches slow-bleed cost issues).

Configure all alerts to go to both you and the client. Transparency builds trust, and it ensures you're not the only person who sees when something goes wrong.

Managing Multiple Client Accounts

When you're managing 3, 5, or 10 client accounts, logging into each one to check dashboards doesn't scale. You need a way to see all accounts at a glance.

The manual approach: configure AWS CLI profiles for each client account using cross-account role assumption. Write scripts that iterate over profiles and check key metrics. This works but requires ongoing maintenance as you add and remove clients.

The automated approach: use a monitoring tool that supports multi-account visibility. Vigilare's Agency plan ($199/month) lets you connect multiple client accounts to a single dashboard. Each account gets its own risk score, billing monitoring, and security alerts. You can see at a glance which accounts need attention and which are healthy — without logging into each one individually.

Billing Boundaries

Establish clear billing boundaries with every client. The client owns the AWS account and the payment method. You never have access to their billing information or payment details. Cost alerts go to both of you. If the client asks you to set up infrastructure, provide a cost estimate first and get written approval.

If possible, have the client set an AWS Budget with an action that restricts resource creation above a certain threshold. This prevents accidental or malicious overspend — from you, from them, or from a compromised credential.

When the Engagement Ends

When the project wraps up, clean up your access. Delete the cross-account IAM role you created. Remove any personal SSH keys from EC2 instances. Document what you built and hand it off. Confirm with the client that your access has been revoked — they can verify by checking IAM roles in their account.

The cross-account role approach makes offboarding clean: one role deletion and you're fully deprovisioned. Compare this to the root-credential-sharing approach, where offboarding requires the client to change their root password and hope you didn't leave any other access vectors.

Related Reading

• Multi-account monitoring architecture
• Cross-account access guide
• MSP account management best practices
• Tagging strategy for multi-client environments