This is an edge case, and as soon as multiple users are accessing the AWS Console in anyway, IAM is the only good option, but what if you only have one user?

I've always assumed that if only one person is accessing the account, and they need full privileges, then making a second account (IAM user) with full privileges would only be opening up another attack vector, and actually be less secure than just using the one account. But I started with "I've assumed" and I know it's just that.

If there is only one user, is it more secure to use a pseudo-root IAM user, or stick to just the root account? Why?

  • What do you mean "with full privileges"? Are you including in those "privileges" the billing details for your account? AFAIK, the root account has access to those billing details, whereas the IAM users do not.
    – hft
    Commented Aug 26, 2021 at 22:07
  • Is this helpful: stackoverflow.com/questions/29744235/…
    – hft
    Commented Aug 26, 2021 at 22:07
  • @hft not particularly, the scenario presented there isn't relevant to my situation in anyway - and I almost included a large parenthetical explanation of how IAM can't quite get to the same full access at root, but thought it excessive. Regardless, there's only one person managing everything from web servers, database design, and Cloudtrail, to account billing. For reference I've had a personal AWS account since 2011 - I run numerous small websites for the heck of it, and extensively use route 53 to manage domains for friends/family. It's just me... is there any benefit to an IAM user?
    – TCooper
    Commented Aug 26, 2021 at 22:24
  • If you don't want to create an IAM user, you don't have to. In your particular case, it seems like you think the costs outweigh the benefits. And, for you, maybe the costs do outweigh the benefits. That's fine, but that is a decision you must make.
    – hft
    Commented Aug 27, 2021 at 19:34
  • @hft I certainly do think so, but I know it's my assumption - just trying to challenge it. I have a decent understanding of/background in security, but nothing great. I'm really probing to see if there's a reason that can actually convince me - I like to adhere to best practices, but I'm also a pragmatist. If I thought it would be more secure in anyway, I would've done it already, but I'm just really not convinced (to date).
    – TCooper
    Commented Aug 27, 2021 at 20:36

3 Answers 3


Never design a system considering that it will never grow. If it never grows, you haven't learned how to properly design a system. If it does grow, you end up with a huge problem to solve.

It's insecure to have only one root user. If this user gets compromised, everything is compromised. If you compartmentalize privileges on different pseudo-users, one compromised user does not compromise everything. That's something called Blast Radius: the maximum amount of damage that a compromised account can create. A single account means total account destruction, and a large blast radius. An account for every workload means only one workload gets compromised, and a smaller blast radius.

If, for example, the network-manager user gets compromised, you delete that user, re-create all the networks (you backed up the network definitions, right?), and you are good to go. If you have only the root user, it's going to be very difficult to disinfect a compromised AWS account.

I am not saying that you should create an user for every single action, but create a few ones for relevant areas, and keep the root user out of use as much as possible.

  • Thanks for the answer, but I'm not sure it really addresses the question.(good frame challenge up front though) The root user exists anyway and cannot be deleted, is there evidence that using an account increases the likelihood it is compromised? Because otherwise the entire second paragraph is moot... "If this user gets compromised, everything is compromised" is true no matter how many pseudo users you create to delegate tasks. I'm still in the line of thinking that creating more access points to the account increases the likelihood of any compromise occurring.
    – TCooper
    Commented Aug 26, 2021 at 19:54
  • 1
    If your root user have a very long password, you store that password securely and don't use it daily, the chances of it being compromised are very small.
    – ThoriumBR
    Commented Aug 26, 2021 at 22:23
  • 24 character pseudo-random password with MFA ... but how does using it daily affect the chances of compromise? P.S. thanks for your time/input - I like to challenge ideas in general, don't mean to take away from the insight you're adding.
    – TCooper
    Commented Aug 26, 2021 at 22:26
  • Phishing, misconfigured access token, difficulty to audit every access, lack of visibility on its actions (too much to care for)...
    – ThoriumBR
    Commented Aug 26, 2021 at 22:28
  • phishing is easy to disregard, I don't configure any access tokens (I focus on limiting access points as main security effort), and how is auditing multiple accounts/viewing multiple logs more visible/less difficult than seeing it all in one place (single CloudTrail log for all actions). It seems more accounts is more to care for...?
    – TCooper
    Commented Aug 27, 2021 at 20:38

The best practice is to use AWS account root user only when it's needed. There are certain tasks that require root user credentials - see AWS docs. If you don't use root user, you can't do that, be it by mistake.

I'd recommend to use IAM user with PowerUser / Admin / custom permissions which will have elevated, but not full priviledges.


On theory there is same probability of root and IAM user (with admin access) getting compromise. So in one user scenario why still use IAM user and not root?
There are certain things that only root can do like closing your account. So if you use root and it gets compromised you will end up losing your account. That’s the worst that could happen and wouldn’t have happened with compromise of regular IAM user with administrator access.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .