AWS ARN Format Explained: How to Read and Build ARNs

If you've spent any time working with Amazon Web Services (AWS), you have likely run into an ARN, or Amazon Resource Name. ARNs are the fundamental way AWS uniquely identifies every single resource across all of its services and regions.

Whether you are writing IAM policies, setting up event triggers in EventBridge, or configuring an S3 bucket, understanding the AWS ARN format is essential to managing permissions and resources securely.

In this guide, we'll break down the anatomy of an ARN, look at real-world examples, and explain how to piece them together for your infrastructure.

The Anatomy of an ARN

The general ARN format looks intimidating at first glance, but it follows a strict, predictable syntax consisting of six distinct parts separated by colons (:):

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

Let's break down each component:

1. arn: This is always the literal string arn. It signals to AWS that what follows is a resource identifier.
2. partition: The partition the resource is located in. For standard AWS regions, this is aws. If you are working in regions like China, it will be aws-cn. For the US GovCloud, it is aws-us-gov.
3. service: The AWS product identifying the resource (e.g., s3, iam, lambda, ec2, dynamodb).
4. region: The AWS region code where the resource resides (e.g., us-east-1, eu-west-2). Note: For global services like IAM or Route53, this part is often left blank.
5. account-id: The 12-digit AWS account number that owns the resource. Like the region, this is sometimes omitted for resources that don't require it (such as S3 buckets which have globally unique names).
6. resource or resource-type/resource-id: The specific identifier for the resource. This format varies heavily depending on the service. For example, an S3 bucket is just the bucket name, while an IAM user includes the user/ prefix.

Common AWS ARN Examples

Let's look at how this format applies to some of the most frequently used AWS services.

1. Amazon S3 (Simple Storage Service)

S3 ARNs are unique because buckets are globally unique and don't require a region or account ID.

Bucket ARN:

arn:aws:s3:::my-production-bucket

Notice the three consecutive colons :::? That indicates the region and account ID were omitted.

Object ARN:

arn:aws:s3:::my-production-bucket/images/logo.png

2. IAM (Identity and Access Management)

IAM is a global service, so the region is omitted, but the account ID is required.

IAM User:

arn:aws:iam::123456789012:user/Johndoe

IAM Role:

arn:aws:iam::123456789012:role/DeployRole

3. AWS Lambda

Lambda functions are regional and bound to an account, so every field is utilized.

arn:aws:lambda:us-west-2:123456789012:function:ProcessDataWorker

Using Wildcards in ARNs

When writing IAM policies, you rarely want to specify the exact ARN for every single object, especially in a service like S3 where millions of files might exist. AWS allows the use of wildcards (* and ?) in the resource section of an ARN.

• * matches any combination of zero or more characters.
• ? matches any single character.

Granting access to an entire S3 bucket's contents:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": ["arn:aws:s3:::my-production-bucket/*"]
}

Allowing a user to manage all EC2 instances in a specific region:

{
  "Effect": "Allow",
  "Action": ["ec2:*"],
  "Resource": ["arn:aws:ec2:us-east-1:123456789012:instance/*"]
}

Warning: Be extremely careful when using wildcards * in ARNs, specifically with IAM permissions. A poorly constructed wildcard ARN can accidentally grant administrative access across all resources in your account. Always follow the principle of least privilege.

Troubleshooting ARN Formats

If an AWS service rejects your ARN, check for these common pitfalls:

1. Incorrect service name: Some services have non-intuitive names in ARNs. For example, Elastic Load Balancing uses elasticloadbalancing rather than elb or alb.
2. Missing colons: Ensure you have the exact number of colons separating empty fields (like the ::: in S3).
3. Trailing slashes: arn:aws:s3:::my-bucket/ is different from arn:aws:s3:::my-bucket. If you mean to match the bucket and not its contents, leave the slash off.
4. Account ID typos: Ensure your 12-digit account ID has no hyphens or spaces. 1234-5678-9012 is invalid.

Conclusion

The AWS ARN format is the linchpin of AWS security and resource management. While it can initially appear confusing, remembering the arn:partition:service:region:account:resource structure helps demystify error messages and empowers you to write more secure, granular IAM policies.

Take the time to examine the ARNs across your cloud infrastructure—it's the first step toward mastering AWS identity and access management.