A malformed ARN
A missing colon, located rather than reported as generally invalid
arn:aws:s3:my-bucket/key arn:aws:iam::123456789012:role/AppRole
AWS ARN Decoder
Paste one ARN or a hundred, one per line. Get every field split out and explained, plus the four mistakes that make an ARN match nothing at all while IAM says nothing about it.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Decode ARNs. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Real ARNs broken down
Partition, service, region, account and resource, including why S3 has no region
arn:aws:iam::123456789012:role/AppRole arn:aws:s3:::my-bucket/* arn:aws:lambda:eu-west-1:123456789012:function:processor
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Expecting every ARN to have a region and an account
S3 bucket ARNs have neither, because bucket names are globally unique. IAM ARNs have an account but no region.
Instead:Read the empty segments as meaningful rather than as a formatting error.
Using a wildcard account in a trust policy
arn:aws:iam::*:role/* trusts every AWS account in existence, which is one of the few genuinely catastrophic IAM mistakes.
Instead:Name the account, and add an ExternalId condition for third-party access.
Confusing the bucket ARN with the object ARN
arn:aws:s3:::bucket grants bucket-level actions and arn:aws:s3:::bucket/* grants object-level ones. A policy needs both for most workflows.
Instead:List both ARNs, with the actions each supports.
What it checks
Splitting an ARN on colons is easy. The useful part is knowing which fields a given service expects to be empty, because filling one in produces an ARN that is perfectly well-formed and matches nothing.
Every field, explained
Partition, service, region, account and resource, each split out with what it means. The resource is split further into its type and id, whether the ARN separates them with a slash or a colon, and the last line says in plain words what the ARN actually points at.
Partition and region disagreements
A cn- region in the aws partition, or a us-gov- region outside aws-us-gov. This is the mistake that costs an afternoon: the ARN looks right, IAM accepts the policy, and the request is simply denied with no indication why.
Regions on global services
IAM, S3, CloudFront, Route 53 and Organizations ARNs carry no region. Fill one in and the ARN matches nothing. S3 goes further and carries no account either, which is why bucket ARNs have three colons in a row.
Account ids that lost a digit
Account ids are always twelve digits, and a leading zero survives being pasted through a spreadsheet exactly never. Any account field that is not twelve digits, empty, or the literal aws is flagged.
Bucket versus object
arn:aws:s3:::bucket is the bucket itself and matches ListBucket. Object operations need bucket/*. Getting this backwards is the single most common reason an S3 policy denies something it was written to allow.
Many at once
Paste a whole column from a spreadsheet or a policy's Resource array, one per line. Each is checked and decoded separately, and findings carry the line they came from. Blank lines and # comments are skipped.
The failure mode is silence
A malformed ARN in an IAM policy does not produce an error. The policy saves, the deploy succeeds, and the statement simply never matches anything. There is no warning at write time and no message at request time beyond a generic access denied.
That is why a region on an IAM ARN, or the aws partition on a GovCloud region, can survive code review indefinitely. Both look completely reasonable. The only signal is that something does not work, weeks later, in a way nobody connects to the ARN.
Checking the shape takes a second and catches all of it, which is the entire argument for this page existing.
What is an ARN, and what are its parts?
An Amazon Resource Name uniquely identifies one thing in AWS. It is six colon-separated fields, and the reason it is worth explaining is that two of those fields are legitimately empty for some services, so a correct ARN often has a double colon in it, and an incorrect one usually does too.
Six fields, always in this order
The prefix is always the literal arn. The partition is aws for commercial regions, and differs in China and GovCloud. Service, region and account id do what they say. The last field is service-specific and is the part with no fixed shape, sometimes a name, sometimes a type and a name, sometimes a path.
arn:aws:iam::123456789012:role/deploy
| | | | | |
| | | | | +-- resource role/deploy
| | | | +--------------- account id 123456789012
| | | +------------------ region empty: IAM is global
| | +----------------------- service iam
| +--------------------------- partition aws
+------------------------------- prefix always "arn"The empty fields are usually correct
IAM, Route 53, CloudFront and S3 are global services, so their ARNs carry no region and you see a double colon. S3 goes further and omits the account id too, because bucket names are globally unique and identify the bucket on their own. A region on an IAM role, or an account id on an S3 bucket, is the error, not the empty field.
arn:aws:iam::123456789012:user/ada no region correct
arn:aws:s3:::my-bucket/path/file.txt neither correct
arn:aws:ec2:eu-west-1:123456789012:vpc/vpc-0abc both correct
arn:aws:s3:eu-west-1::my-bucket region on S3 wrongThe partition is not always aws
China uses aws-cn and GovCloud uses aws-us-gov. Getting this wrong is quiet: the ARN is syntactically valid, IAM parses it happily, and the policy simply matches nothing, so access is denied with no explanation of why. The same failure happens when the partition is right but the region belongs to a different one.
aws commercial regions
aws-cn cn-north-1, cn-northwest-1
aws-us-gov us-gov-west-1, us-gov-east-1Why a wrong ARN fails silently
IAM policies match ARNs as strings, with wildcards. There is no existence check when a policy is written, so an ARN with a typo, the wrong partition or a short account id is a perfectly valid policy that grants access to nothing. Nothing warns you, and the failure appears later as an access denied on an action you thought you had allowed, which is exactly why checking the shape of an ARN before it ships is worth doing.
More aws tools
AWS IAM Policy Validator & Analyzer Valid JSON? And what does it grant? AWS IAM Policy Evaluator Is this actually allowed? AWS S3 Bucket Policy Analyzer Is this bucket actually public? AWS S3 Bucket Policy Generator Pick a pattern, get a safe policy AWS ECS Task Definition Analyzer Two roles, and they are not the same AWS S3 Lifecycle Policy Analyzer Minimum durations you still pay AWS S3 Presigned URL Decoder It dies with the session AWS Lambda Configuration Analyzer Memory is the CPU dial AWS SQS Visibility Timeout Calculator Six times the function timeout AWS EventBridge Pattern Tester Every leaf value is an array AWS DynamoDB Capacity Calculator Every index costs a write AWS Resource Name Validator A dot in a bucket breaks TLS AWS CLI Profile Analyzer The prefix rule is opposite AWS IAM Trust Policy Analyzer Account root means the whole account AWS Access Key ID Identifier AKIA never expires, ASIA does AWS STS Assume Role Command Builder Chaining caps at one hour AWS KMS Key Policy Analyzer The one AWS mistake with no undo AWS Security Group Analyzer They cannot deny anything AWS Network ACL Return Traffic Checker Stateless, so replies need a rule