Must my AWS account ID be kept secret? Can anything at all be done using just the AWS account ID?

From the AWS documentation:

The AWS account ID is a 12-digit number, such as 123456789012, that you use to construct Amazon Resource Names (ARNs). When you refer to resources, such as an IAM user or an Amazon Glacier vault, the account ID distinguishes your resources from resources in other AWS accounts.


An AWS Account ID can be shared, when required.

Like the documentation says, the main thing anyone can use your AWS Account Number for is to construct ARN's. For example, if I had an AWS Account which held an AWS Lambda function, and someone on another account, who I had explicitly granted permission to, wanted to manipulate it, they would use by account number in the ARN.


Again, this is totally limited by the permissions applied on your account. Even if I had a full ARN, unless you give my AWS account access, I won't be able to do anything with it.

API Keys are the things that grant remote control of things, and are dangerous.

| improve this answer | |
  • That’s correct. AWS now allow you to share publicly available lambda layers, that are shared via ARNs that contain your account id. While it’s always better to not share anything unless you have to — something you just have to share your account id in the form of an ARN. – keithRozario Sep 9 '19 at 15:48

Knowing an AWS account ID doesn't expose you to any attack in itself, but it can make it easier for an attacker to obtaining other compromising information.

Rhino Security Labs demonstrate a potential compromise vector via misconfigured IAM roles in a blog post here:

AWS account IDs uniquely identify every AWS account and are more sensitive than you might think. While divulging the ID does not directly expose an account to compromise, an attacker can leverage this information in other attacks. A reasonable effort should be made to keep AWS account IDs private, but in practice, they are often exposed to the public unintentionally.


This post — and the accompanying script we have released – address using an AWS account ID to identify existing roles. As an extension of this concept, attackers can go a step further and assume misconfigured IAM roles to gain unauthorized access.

This will only be effective in the case where a user allows role assumption from * or from a too-wide range of resources, but in my experiences IAM permissions are complex and reasonably hard to audit well, and attacks like this are hard to detect:

This bruteforcing technique and script will generate a large amount of “iam:AssumeRole” CloudTrail logs in the account you are using for enumeration. Any account you target will not see anything in their CloudTrail logs until you successfully assume a misconfigured role, so that means enumeration is completely log-free on the target account.

In other words - it's not intrinsically a risk, but it does meaningfully reduce the attack surface of your account to keep the ID out of the public eye.

| improve this answer | |
  • 2
    I've read that article too, that post embellishes things a bit, they needed to have a real IAM cred + the AWS acct. I'd say if someone has a login to the acct it's already getting into game over type of situation. Leaking of the AWS acct ID is hardly what precipitated the attack. – slm Feb 21 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.