AWS access for agencies without sharing the root login

An AWS account can hold a client's servers, files, databases and the card that pays for all of it. AWS has built-in ways to let an agency in safely: your own named access, protected by multi-factor authentication and limited to the work, which the client can remove in a few clicks. Nobody needs the root login. This guide follows Theo at Northside Studio, who is moving the Harbor Fitness booking app onto AWS for Dana.

Console labels come from AWS documentation at the time of writing. The exact clicks are also on our AWS step by step page.

Keep the root login with the client

The root user is the email address and password that created the account, with complete access to every service and resource, billing included. AWS's root user best practices say not to share the root password, MFA or access keys with anyone except those with a strict business need, and to use the root user only for the few tasks that require it, such as changing the account's root email or closing the account. Those are owner decisions, so they stay with Dana.

AWS's own example of hiring an outside company is just as clear. Instead of an IAM user with long-term credentials, it recommends a role and its temporary credentials. AWS also suggests a business-managed group email address for the root user, so AWS can still reach the business if one person is away or leaves.

One link per client, with every step checked. Reserve a founding place

Option 1: an IAM Identity Center user for each person

This suits a team that works in the AWS console. Each person at Northside Studio gets a named user, signs in through the AWS access portal and receives short-lived credentials for the account.

One thing to know first: giving users access to AWS accounts needs an organization instance of IAM Identity Center. When a standalone account turns it on, AWS creates an organization with that account as the management account. AWS also notes that on a free tier account, creating an organization moves it to a paid, pay-as-you-go plan and the free tier credits end immediately, so Dana should check her plan first.

Dana signs in with administrator access, then:

1. She opens the IAM Identity Center console and chooses Enable. On a standalone account, AWS shows the Enable IAM Identity Center with AWS Organizations page, where she reviews the details and chooses Enable.
2. Under Multi-account permissions, she chooses Permission sets, then Create permission set. She selects Predefined permission set, picks PowerUserAccess, chooses Next, names it, then chooses Next and Create.
3. She chooses Users, then Add user, and enters Theo's username, email and name. She keeps Send an email to this user with password setup instructions, chooses Next twice, then Add user.
4. Under Multi-account permissions, she chooses AWS accounts, ticks the Harbor Fitness account and chooses Assign users or groups. She selects Theo on the Users tab, chooses Next, selects the permission set, chooses Next, then Submit.

Theo receives an email titled "Invitation to join AWS IAM Identity Center". It expires after seven days, and Dana can send a fresh one with Reset password.

Option 2: an IAM role your agency's account can assume

This suits an agency that works from its own AWS account with the command line or deployment tools. It is the setup AWS describes for third parties: the agency provides its AWS account ID and an external ID, the client creates a role, and the client sends back the role's ARN.

1. Theo sends Dana Northside Studio's AWS account ID and an external ID unique to Harbor Fitness. AWS doesn't treat the external ID as a secret, but it should never be guessable.
2. Dana opens the IAM console and chooses Roles, then Create role, then AWS account, then Another AWS account, and enters the account ID.
3. She ticks Require external ID and pastes Theo's external ID. She can also tick Require MFA.
4. She chooses Next, ticks PowerUserAccess, chooses Next again, names the role and chooses Create role.
5. She opens the new role and sends its ARN to Theo.

Two details matter. AWS says a role that requires an external ID can't be reached with the console's Switch role, only through the AWS CLI, SDKs or API, so choose Option 1 if your team needs the console. And creating the role is only the first half: Theo's own account must still allow his users to assume it.

Pick the smallest policy that does the job

AWS says its managed policies for job functions don't grant least privilege, so treat them as starting points. These three cover most agency work:

PowerUserAccess can't create IAM users or roles (service-linked roles aside), so if the build needs a new role, for a function say, Dana creates it or adds a narrow extra policy. AWS also notes that PowerUserAccess still allows every IAM Identity Center action when Identity Center is on, which Dana can limit with a custom permission set. To look around without reading stored data, AWS offers ViewOnlyAccess.

Sending this to a client? Send one link instead

Turn on multi-factor authentication

• Root user. AWS requires MFA on the root user for every account type and recommends registering more than one device. Dana keeps these herself.
• Identity Center users. By default, Identity Center asks for MFA every time someone signs in, and users without a device register one at sign-in. Dana can confirm this under Settings > Authentication > Multi-factor authentication > Configure.
• Roles. With Require MFA ticked, only users who signed in with MFA can assume the role.

AWS recommends phishing-resistant MFA, such as passkeys and security keys, and no longer supports setting up text message codes.

Skip the back and forth. Let one link walk your client through it

Removing access at the end

For an Identity Center user:

1. In the IAM Identity Center console, under Multi-account permissions, Dana chooses AWS accounts and selects the Harbor Fitness account.
2. Under Assigned users and groups, she selects Theo, chooses Remove access and confirms with Remove access.
3. She chooses Users, selects Theo and chooses Delete users.

AWS recommends removing a user's assignments before deleting the user, which is why the order above matters.

For a role:

1. In the IAM console, Dana chooses Roles and ticks the role made for Northside Studio.
2. She chooses Delete, checks when the role was last used, types the role name and chooses Delete.

Then she deletes any IAM users or access keys created during the project, and changes any passwords or keys the agency handled. Our project handover checklist covers the same clean-up for the client's other platforms.

Doing this for every client?

Get Set Keys gives each client one link that walks them through these AWS steps and checks each one is done. Porter, the AI setup helper on every link, answers their questions straight away and passes anything it can't answer to you. You can reserve a founding place before launch in November 2026.