Table of Contents
Introduction to AWS ARNs
Amazon Resource Names (ARNs) are the universal identification system used across Amazon Web Services. Every resource you create in AWS — whether it is an S3 bucket, an IAM role, a Lambda function, or an EC2 instance — receives a unique ARN that distinguishes it from every other resource in the AWS ecosystem. Understanding ARNs is not optional for anyone who works with AWS seriously; it is a fundamental skill that underpins security, automation, and infrastructure management.
ARNs appear everywhere in the AWS world. When you write an IAM policy, you specify the resources the policy applies to using ARNs. When you reference a resource in CloudFormation or Terraform templates, you use ARNs. When you invoke cross-account operations, subscribe to SNS topics, grant KMS key access, configure CloudWatch alarms, or use the AWS CLI and SDKs to interact with specific resources, ARNs are the mechanism by which you identify those resources unambiguously.
Despite their ubiquity, ARNs can be surprisingly confusing. Different services use different formats. Some ARNs include regions and account IDs; others omit them. Some use forward slashes as delimiters; others use colons. This guide will demystify the ARN format, walk through every component in detail, cover edge cases and gotchas, and provide dozens of real-world examples that you can reference in your daily work.
Whether you are debugging a permissions error in an IAM policy, writing infrastructure as code, building automation scripts, or preparing for an AWS certification exam, this guide will give you a thorough understanding of how ARNs work and how to use them correctly.
The ARN Format
Every ARN follows a structured format that encodes key information about the resource it identifies. The general syntax is:
arn:partition:service:region:account-id:resource-type/resource-id
Let us break down each component in detail:
arn:aws:s3:::my-example-bucket/photos/2026/march/photo.jpg
| | | | | |
| | | | | +-- Resource ID (object key)
| | | | +-- Resource Type (bucket name, acts as resource)
| | | +-- Account ID (omitted for S3)
| | +-- Region (omitted for S3, it's global)
| +-- Service namespace (s3)
+-- Partition (aws = standard commercial)
Component 1: "arn" Prefix
Every ARN begins with the literal string arn. This prefix is fixed and never changes. It signals to any parser or AWS service that the string following it is an Amazon Resource Name.
Component 2: Partition
The partition identifies which AWS infrastructure group the resource belongs to. For the vast majority of users, this will be aws, representing the standard commercial AWS regions. Other partitions exist for isolated or government environments. We cover partitions in detail in the next section.
Component 3: Service Namespace
The service namespace identifies which AWS service owns the resource. Examples include s3 for Amazon S3, ec2 for Amazon EC2, iam for AWS IAM, and lambda for AWS Lambda. Each service has a unique namespace, and AWS publishes a complete list in its documentation. We provide a comprehensive table of service namespaces in the Service Namespaces section.
Component 4: Region
The region identifies the AWS region where the resource is located. This follows the standard AWS region code format, such as us-east-1, eu-west-2, or ap-southeast-1. Some global resources, like IAM users and S3 buckets, omit the region (leaving it empty between the colons). See the Region Codes section for a full list.
Component 5: Account ID
The account ID is the 12-digit AWS account number that owns the resource. Like the region, some resources omit this field. S3 buckets, for instance, have globally unique names and do not need an account ID in their ARN. The account ID is always numeric and always 12 digits (padded with leading zeros if necessary).
Component 6: Resource Identifier
The resource identifier is the most variable component. It specifies the exact resource within the service. Different services format this section differently — some use a resource-type/resource-id pattern, some use resource-type:resource-id, and some use just the resource ID directly. We explore these variations in the Resource Identifiers section.
Here is a fully annotated example with all fields populated:
# Full ARN with all components
arn:aws:ec2:us-east-1:123456789012:instance/i-0abc1234def56789a
# Breakdown:
# arn - ARN prefix (always "arn")
# aws - Partition (standard commercial)
# ec2 - Service namespace (Amazon EC2)
# us-east-1 - Region (US East, N. Virginia)
# 123456789012 - Account ID (12 digits)
# instance - Resource type
# i-0abc... - Resource ID (instance identifier)
Partitions
AWS partitions represent isolated groups of AWS regions. Each partition has its own set of endpoints, its own IAM infrastructure, and its own resource namespace. Resources in one partition cannot directly reference resources in another partition using ARNs.
There are five AWS partitions:
aws (Standard Commercial)
The aws partition encompasses all standard commercial AWS regions worldwide. This includes regions like us-east-1, eu-west-1, ap-northeast-1, and all other publicly available regions. The overwhelming majority of AWS users operate exclusively within this partition.
arn:aws:s3:::my-bucket
aws-cn (China)
The aws-cn partition covers the AWS China Regions, which are operated by local partners (Sinnet for Beijing and NWCD for Ningxia) in compliance with Chinese regulations. These regions are isolated from the standard partition and require separate AWS accounts. Resources created in the China partition use the aws-cn partition identifier in their ARNs.
arn:aws-cn:s3:::my-china-bucket
aws-us-gov (GovCloud)
The aws-us-gov partition covers the AWS GovCloud (US) Regions, designed for US government agencies and contractors who need to meet compliance requirements such as FedRAMP, ITAR, and DoD SRG. GovCloud regions operate under a separate governance structure and require separate accounts.
arn:aws-us-gov:s3:::my-govcloud-bucket
aws-iso (ISO)
The aws-iso partition supports workloads classified at the Secret level for the US Intelligence Community. These regions are air-gapped from the public internet and have the strictest isolation requirements.
aws-iso-b (ISO-B)
The aws-iso-b partition supports workloads classified at the Top Secret level. Like the ISO partition, these regions are fully isolated and serve the most sensitive government workloads.
When writing IAM policies or CloudFormation templates that need to work across partitions, you can use the AWS::Partition pseudo parameter (in CloudFormation) or conditional logic to dynamically insert the correct partition rather than hardcoding aws.
AWS Service Namespaces
Each AWS service has a unique namespace identifier used in ARNs and IAM policy actions. These namespaces are lowercase strings that identify the service. Below is a comprehensive table organized by category, covering the most commonly used services.
Compute Services
Service Namespace
------- ---------
Amazon EC2 ec2
AWS Lambda lambda
Amazon ECS ecs
Amazon EKS eks
AWS Fargate ecs (shares ECS namespace)
AWS Batch batch
Amazon Lightsail lightsail
AWS Elastic Beanstalk elasticbeanstalk
AWS App Runner apprunner
Storage Services
Service Namespace
------- ---------
Amazon S3 s3
Amazon EBS ec2 (shares EC2 namespace)
Amazon EFS elasticfilesystem
Amazon FSx fsx
AWS Storage Gateway storagegateway
AWS Backup backup
Amazon S3 Glacier glacier
Database Services
Service Namespace
------- ---------
Amazon RDS rds
Amazon DynamoDB dynamodb
Amazon ElastiCache elasticache
Amazon Redshift redshift
Amazon Neptune neptune
Amazon DocumentDB docdb (or rds)
Amazon Keyspaces cassandra
Amazon MemoryDB memorydb
Amazon QLDB qldb
Amazon Timestream timestream
Networking Services
Service Namespace
------- ---------
Amazon VPC ec2 (shares EC2 namespace)
Elastic Load Balancing elasticloadbalancing
Amazon Route 53 route53
Amazon CloudFront cloudfront
Amazon API Gateway apigateway (REST/WebSocket)
execute-api (API execution)
AWS Direct Connect directconnect
AWS Transit Gateway ec2 (shares EC2 namespace)
AWS Global Accelerator globalaccelerator
Security and Identity Services
Service Namespace
------- ---------
AWS IAM iam
AWS STS sts
AWS KMS kms
AWS Secrets Manager secretsmanager
Amazon Cognito cognito-idp / cognito-identity
AWS Certificate Manager acm
AWS WAF wafv2
AWS Shield shield
Amazon GuardDuty guardduty
AWS Security Hub securityhub
Amazon Inspector inspector2
AWS SSO (IAM Identity Center) sso
Application Integration Services
Service Namespace
------- ---------
Amazon SQS sqs
Amazon SNS sns
Amazon EventBridge events
AWS Step Functions states
Amazon MQ mq
AWS AppSync appsync
Management and Monitoring Services
Service Namespace
------- ---------
Amazon CloudWatch cloudwatch
Amazon CloudWatch Logs logs
AWS CloudTrail cloudtrail
AWS CloudFormation cloudformation
AWS Systems Manager ssm
AWS Config config
AWS Organizations organizations
AWS Control Tower controltower
Developer Tools
Service Namespace
------- ---------
AWS CodeCommit codecommit
AWS CodeBuild codebuild
AWS CodeDeploy codedeploy
AWS CodePipeline codepipeline
AWS CodeArtifact codeartifact
This is not an exhaustive list — AWS has over 200 services — but it covers the namespaces you will encounter most frequently when working with ARNs. For a full reference, consult the AWS Service Authorization Reference.
Region Codes
AWS regions are geographically distributed data center clusters. Each region has a unique code that appears in ARNs, API endpoints, and AWS CLI commands. Here is a comprehensive list of AWS regions.
US Regions
Region Code Region Name
----------- -----------
us-east-1 US East (N. Virginia)
us-east-2 US East (Ohio)
us-west-1 US West (N. California)
us-west-2 US West (Oregon)
Europe Regions
Region Code Region Name
----------- -----------
eu-west-1 Europe (Ireland)
eu-west-2 Europe (London)
eu-west-3 Europe (Paris)
eu-central-1 Europe (Frankfurt)
eu-central-2 Europe (Zurich)
eu-north-1 Europe (Stockholm)
eu-south-1 Europe (Milan)
eu-south-2 Europe (Spain)
Asia Pacific Regions
Region Code Region Name
----------- -----------
ap-northeast-1 Asia Pacific (Tokyo)
ap-northeast-2 Asia Pacific (Seoul)
ap-northeast-3 Asia Pacific (Osaka)
ap-southeast-1 Asia Pacific (Singapore)
ap-southeast-2 Asia Pacific (Sydney)
ap-southeast-3 Asia Pacific (Jakarta)
ap-southeast-4 Asia Pacific (Melbourne)
ap-south-1 Asia Pacific (Mumbai)
ap-south-2 Asia Pacific (Hyderabad)
ap-east-1 Asia Pacific (Hong Kong)
South America, Middle East, Africa, and Canada
Region Code Region Name
----------- -----------
sa-east-1 South America (Sao Paulo)
ca-central-1 Canada (Central)
ca-west-1 Canada West (Calgary)
me-south-1 Middle East (Bahrain)
me-central-1 Middle East (UAE)
af-south-1 Africa (Cape Town)
il-central-1 Israel (Tel Aviv)
AWS GovCloud Regions
Region Code Region Name
----------- -----------
us-gov-east-1 AWS GovCloud (US-East)
us-gov-west-1 AWS GovCloud (US-West)
China Regions
Region Code Region Name
----------- -----------
cn-north-1 China (Beijing)
cn-northwest-1 China (Ningxia)
AWS continues to expand its infrastructure, so new regions are added periodically. Some regions are opt-in, meaning you must explicitly enable them in your account before you can use them. Opt-in regions include af-south-1, ap-east-1, ap-south-2, ap-southeast-3, ap-southeast-4, eu-central-2, eu-south-1, eu-south-2, il-central-1, me-central-1, and me-south-1.
Resource Identifiers
The resource identifier portion of an ARN is the most variable component, and its format depends on the service. There are three primary patterns used across AWS services.
Pattern 1: resource-type/resource-id (Forward Slash)
This is the most common pattern. The resource type and resource ID are separated by a forward slash. Many services use this format, and some resources have multiple levels of hierarchy using nested slashes.
# IAM user
arn:aws:iam::123456789012:user/johndoe
# IAM role with a path
arn:aws:iam::123456789012:role/application/my-app-role
# EC2 instance
arn:aws:ec2:us-east-1:123456789012:instance/i-0abc1234def56789a
# S3 object (bucket name + key with slashes)
arn:aws:s3:::my-bucket/folder/subfolder/file.txt
# Lambda function with version
arn:aws:lambda:us-east-1:123456789012:function:my-func/1
Pattern 2: resource-type:resource-id (Colon)
Some services use a colon to separate the resource type from the resource ID. This is common in older services and in situations where the resource ID itself might contain forward slashes.
# SNS topic
arn:aws:sns:us-east-1:123456789012:my-topic
# SQS queue
arn:aws:sqs:us-east-1:123456789012:my-queue
# Lambda function
arn:aws:lambda:us-east-1:123456789012:function:my-function
# DynamoDB table
arn:aws:dynamodb:us-east-1:123456789012:table/my-table
# ECS cluster
arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster
# Secrets Manager secret
arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret-AbCdEf
Pattern 3: resource-id Only (No Type)
Some services use just the resource ID without an explicit resource type prefix. This typically occurs when the service has a primary resource type that does not require disambiguation.
# S3 bucket (bucket name is the resource)
arn:aws:s3:::my-bucket
# SNS topic (topic name is the resource)
arn:aws:sns:us-east-1:123456789012:my-topic
# SQS queue (queue name is the resource)
arn:aws:sqs:us-east-1:123456789012:my-queue
Understanding which pattern a service uses is essential when constructing ARNs for IAM policies or programmatic access. Using the wrong delimiter is a common source of access-denied errors.
Special Cases and Gotchas
While the general ARN format is consistent, several services deviate from the standard pattern in ways that can trip you up. Knowing these special cases will save you from frustrating debugging sessions.
Amazon S3: No Region, No Account ID
S3 bucket names are globally unique across all AWS accounts and regions. Because of this global uniqueness, S3 ARNs omit both the region and account ID fields, leaving them empty:
# S3 bucket (note the empty region and account fields)
arn:aws:s3:::my-bucket
# S3 object
arn:aws:s3:::my-bucket/path/to/object.json
# Common mistake - including region and account:
# WRONG: arn:aws:s3:us-east-1:123456789012:my-bucket
# RIGHT: arn:aws:s3:::my-bucket
This is perhaps the most common ARN gotcha. If you include a region or account ID in an S3 ARN, your IAM policy will not match any resources, and you will get access-denied errors with no obvious explanation.
IAM: No Region
IAM is a global service — users, roles, policies, and groups are not scoped to a specific region. IAM ARNs omit the region field but include the account ID:
# IAM user (no region)
arn:aws:iam::123456789012:user/admin
# IAM role
arn:aws:iam::123456789012:role/MyRole
# IAM policy
arn:aws:iam::123456789012:policy/MyPolicy
# AWS-managed policy (special account "aws")
arn:aws:iam::aws:policy/AdministratorAccess
Note the special case of AWS-managed policies, where the account ID is replaced with the literal string aws instead of a 12-digit number.
STS: Global or Regional
AWS Security Token Service (STS) can operate as either a global service or a regional service. When using the global endpoint, ARNs omit the region. When using regional STS endpoints (which AWS recommends for reduced latency and better availability), ARNs include the region:
# STS global assumed role
arn:aws:sts::123456789012:assumed-role/MyRole/session-name
# STS regional (includes region)
arn:aws:sts:us-east-1:123456789012:assumed-role/MyRole/session-name
# Federated user
arn:aws:sts::123456789012:federated-user/my-user
CloudFront: Global Service
CloudFront is a global service. Its ARNs omit the region but include the account ID:
# CloudFront distribution
arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE
Route 53: Global with Special Patterns
Route 53 is global and has its own ARN conventions. Hosted zone ARNs omit the region and include the zone ID:
# Route 53 hosted zone
arn:aws:route53:::hostedzone/Z1234567890ABC
# Route 53 health check
arn:aws:route53:::healthcheck/abcdef12-3456-7890-abcd-ef1234567890
Note that Route 53 ARNs omit both the region and account ID — similar to S3.
Wildcards in ARNs
ARNs support wildcards (* and ?) when used in IAM policies. The asterisk matches any combination of characters, while the question mark matches any single character. Wildcards are not valid in ARNs themselves — they only work in IAM policy resource specifications:
# Match all objects in a bucket
arn:aws:s3:::my-bucket/*
# Match all Lambda functions in an account
arn:aws:lambda:us-east-1:123456789012:function:*
# Match all resources in all regions
arn:aws:ec2:*:123456789012:instance/*
# Match all DynamoDB tables starting with "prod-"
arn:aws:dynamodb:us-east-1:123456789012:table/prod-*
Elastic Load Balancing: Complex ARN Structure
ELB ARNs have a relatively complex structure, especially for Application Load Balancers and their components:
# Application Load Balancer
arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188
# Target Group
arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
# Listener
arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-alb/50dc6c495c0c9188/f2f7dc8efc522ab2
ARN Examples by Service
This section provides real-world ARN examples across a wide range of AWS services. These examples serve as a quick reference when you need to construct or validate ARNs for specific resource types.
Amazon S3
# S3 bucket
arn:aws:s3:::my-application-data
# S3 object
arn:aws:s3:::my-application-data/uploads/2026/report.pdf
# S3 access point
arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point
Remember: S3 bucket and object ARNs have no region or account ID. S3 access points, however, do include both.
AWS IAM
# IAM user
arn:aws:iam::123456789012:user/developers/jane
# IAM role
arn:aws:iam::123456789012:role/aws-service-role/lambda.amazonaws.com/AWSServiceRoleForLambda
# IAM policy (customer-managed)
arn:aws:iam::123456789012:policy/engineering/DeploymentPolicy
# IAM policy (AWS-managed)
arn:aws:iam::aws:policy/ReadOnlyAccess
# IAM group
arn:aws:iam::123456789012:group/developers
# Instance profile
arn:aws:iam::123456789012:instance-profile/EC2-WebServer-Profile
IAM supports paths in resource identifiers (like /developers/jane), which are useful for organizing resources and writing granular IAM policies.
Amazon EC2
# EC2 instance
arn:aws:ec2:us-east-1:123456789012:instance/i-0abc1234def56789a
# VPC
arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0abc1234def56789a
# Security group
arn:aws:ec2:us-east-1:123456789012:security-group/sg-0abc1234def56789a
# Subnet
arn:aws:ec2:us-east-1:123456789012:subnet/subnet-0abc1234def56789a
# EBS volume
arn:aws:ec2:us-east-1:123456789012:volume/vol-0abc1234def56789a
# AMI
arn:aws:ec2:us-east-1:123456789012:image/ami-0abc1234def56789a
# Elastic IP
arn:aws:ec2:us-east-1:123456789012:elastic-ip/eipalloc-0abc1234def56789a
AWS Lambda
# Lambda function (latest version)
arn:aws:lambda:us-east-1:123456789012:function:my-function
# Lambda function (specific version)
arn:aws:lambda:us-east-1:123456789012:function:my-function:42
# Lambda function alias
arn:aws:lambda:us-east-1:123456789012:function:my-function:PROD
# Lambda layer
arn:aws:lambda:us-east-1:123456789012:layer:my-layer:3
# Lambda event source mapping
arn:aws:lambda:us-east-1:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
Lambda uses colons to separate the function name from the version or alias qualifier. This is one of the services where the colon-vs-slash distinction matters significantly.
Amazon RDS
# RDS instance
arn:aws:rds:us-east-1:123456789012:db:my-database
# RDS cluster (Aurora)
arn:aws:rds:us-east-1:123456789012:cluster:my-aurora-cluster
# RDS snapshot
arn:aws:rds:us-east-1:123456789012:snapshot:my-snapshot
# RDS subnet group
arn:aws:rds:us-east-1:123456789012:subgrp:my-subnet-group
Amazon DynamoDB
# DynamoDB table
arn:aws:dynamodb:us-east-1:123456789012:table/my-table
# DynamoDB table index
arn:aws:dynamodb:us-east-1:123456789012:table/my-table/index/my-index
# DynamoDB stream
arn:aws:dynamodb:us-east-1:123456789012:table/my-table/stream/2026-03-11T00:00:00.000
# DynamoDB backup
arn:aws:dynamodb:us-east-1:123456789012:table/my-table/backup/01234567890123-abcdefgh
Amazon SQS
# SQS queue
arn:aws:sqs:us-east-1:123456789012:my-queue
# SQS FIFO queue
arn:aws:sqs:us-east-1:123456789012:my-queue.fifo
# SQS dead-letter queue
arn:aws:sqs:us-east-1:123456789012:my-queue-dlq
Amazon SNS
# SNS topic
arn:aws:sns:us-east-1:123456789012:my-topic
# SNS subscription
arn:aws:sns:us-east-1:123456789012:my-topic:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
# SNS FIFO topic
arn:aws:sns:us-east-1:123456789012:my-topic.fifo
Amazon ECS
# ECS cluster
arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster
# ECS service
arn:aws:ecs:us-east-1:123456789012:service/my-cluster/my-service
# ECS task
arn:aws:ecs:us-east-1:123456789012:task/my-cluster/a1b2c3d4567890abcdef
# ECS task definition
arn:aws:ecs:us-east-1:123456789012:task-definition/my-task:5
# ECS container instance
arn:aws:ecs:us-east-1:123456789012:container-instance/my-cluster/a1b2c3d4567890abcdef
Amazon EKS
# EKS cluster
arn:aws:eks:us-east-1:123456789012:cluster/my-eks-cluster
# EKS node group
arn:aws:eks:us-east-1:123456789012:nodegroup/my-eks-cluster/my-node-group/a1b2c3d4-abcd-1234
# EKS Fargate profile
arn:aws:eks:us-east-1:123456789012:fargateprofile/my-eks-cluster/my-fargate-profile/a1b2c3d4-abcd
AWS KMS
# KMS key
arn:aws:kms:us-east-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
# KMS alias
arn:aws:kms:us-east-1:123456789012:alias/my-key-alias
AWS Secrets Manager
# Secrets Manager secret
arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/database/credentials-AbCdEf
Secrets Manager appends a random 6-character suffix to the secret name in the ARN. When referencing secrets in IAM policies, you typically need a wildcard: arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/database/credentials-*.
Amazon CloudWatch Logs
# CloudWatch log group
arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/my-function:*
# CloudWatch log group (without wildcard)
arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/my-function
CloudWatch Logs ARNs often end with :* to include all log streams within the log group. This is a common source of confusion when writing IAM policies.
AWS Step Functions
# Step Functions state machine
arn:aws:states:us-east-1:123456789012:stateMachine:my-state-machine
# Step Functions execution
arn:aws:states:us-east-1:123456789012:execution:my-state-machine:my-execution-id
Amazon API Gateway
# REST API
arn:aws:apigateway:us-east-1::/restapis/a1b2c3d4e5
# REST API stage
arn:aws:apigateway:us-east-1::/restapis/a1b2c3d4e5/stages/prod
# API Gateway execution (for IAM policy)
arn:aws:execute-api:us-east-1:123456789012:a1b2c3d4e5/prod/GET/users
API Gateway is unusual because it uses two different service namespaces: apigateway for managing the API itself and execute-api for controlling who can invoke the API. The apigateway ARN also omits the account ID.
Using ARNs in IAM Policies
One of the most critical uses of ARNs is in IAM policies, where they define which resources a principal can access. Understanding how to correctly use ARNs in the Resource element of IAM policies is essential for implementing least-privilege security.
The Resource Element
The Resource element in an IAM policy statement specifies the AWS resources to which the actions apply. It accepts a single ARN or an array of ARNs:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
Using Wildcards for Flexible Matching
Wildcards allow you to create policies that match multiple resources without listing each one individually. The * character matches any combination of characters:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::my-bucket/uploads/*",
"arn:aws:s3:::my-bucket/processed/*"
]
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-bucket"
}
]
}
Notice that s3:ListBucket applies to the bucket itself (no trailing /*), while s3:GetObject and s3:PutObject apply to objects within the bucket (with /*). This is a crucial distinction — mixing them up is a very common source of access-denied errors.
Cross-Account Access
ARNs enable cross-account access by specifying the target account's resources:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::987654321098:role/CrossAccountRole"
}
]
}
Conditions with ARN Operators
IAM policies support ARN-specific condition operators, including ArnEquals, ArnLike, ArnNotEquals, and ArnNotLike. These are useful for restricting access based on the ARN of the requesting principal or resource:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"Condition": {
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/App*"
}
}
}
]
}
Policy Variables with ARNs
IAM policy variables allow dynamic ARN construction based on request context. This is powerful for creating user-specific or role-specific permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::company-bucket/home/${aws:username}/*"
}
]
}
In this example, each IAM user can only access objects under their own "home directory" in the S3 bucket. The ${aws:username} variable is replaced with the name of the authenticated user at evaluation time.
Common ARN Mistakes
Working with ARNs involves many small details, and getting any of them wrong can lead to silent policy failures or confusing access-denied errors. Here are the most common mistakes and how to avoid them.
Including Region or Account ID Where Not Expected
As discussed in the special cases section, some services omit the region, account ID, or both. Adding these fields when the service does not expect them causes the ARN to be invalid:
# WRONG - S3 does not use region or account ID
arn:aws:s3:us-east-1:123456789012:my-bucket
# CORRECT
arn:aws:s3:::my-bucket
# WRONG - IAM does not use region
arn:aws:iam:us-east-1:123456789012:user/admin
# CORRECT
arn:aws:iam::123456789012:user/admin
Wrong Separator (Colon vs. Slash)
Using the wrong separator between resource type and resource ID is a subtle but breaking mistake:
# WRONG - Lambda uses colon before function name
arn:aws:lambda:us-east-1:123456789012:function/my-function
# CORRECT
arn:aws:lambda:us-east-1:123456789012:function:my-function
# WRONG - EC2 uses slash before resource ID
arn:aws:ec2:us-east-1:123456789012:instance:i-0abc1234def56789a
# CORRECT
arn:aws:ec2:us-east-1:123456789012:instance/i-0abc1234def56789a
Account ID Typos
AWS account IDs are 12-digit numbers, and they must be exact. A single wrong digit means the ARN references a completely different account (or a nonexistent one). Always copy account IDs programmatically rather than typing them by hand. You can retrieve your account ID using:
# AWS CLI
aws sts get-caller-identity --query "Account" --output text
# Returns: 123456789012
Missing or Extra Colons
The number of colons in an ARN is significant. Every ARN has exactly five colons separating the six components (even when components are empty). Extra or missing colons will invalidate the ARN:
# WRONG - missing empty fields for S3
arn:aws:s3:my-bucket
# CORRECT - empty region and account fields preserved
arn:aws:s3:::my-bucket
# Count the colons:
# arn : aws : s3 : [empty] : [empty] : my-bucket
# 1 2 3 4 5
Using Wildcards in Non-Policy Contexts
Wildcards (*) are only valid in IAM policy Resource elements and certain other policy contexts. You cannot use wildcards in API calls or when referencing a specific resource:
# VALID in IAM policy Resource element
"Resource": "arn:aws:s3:::my-bucket/*"
# INVALID as an actual resource reference in an API call
aws s3 cp file.txt "arn:aws:s3:::my-bucket/*" # This does NOT work
Wrong Partition for the Environment
If you hardcode the aws partition and then deploy your infrastructure to GovCloud or China regions, all ARN references will break. Use partition-aware constructs in your IaC tools:
# CloudFormation - use the Partition pseudo parameter
!Sub "arn:${AWS::Partition}:s3:::${MyBucket}"
# Terraform - use the partition data source
data "aws_partition" "current" {}
"arn:${data.aws_partition.current.partition}:s3:::${aws_s3_bucket.my_bucket.id}"
Programmatic ARN Parsing
When building automation tools, writing infrastructure code, or processing AWS events, you often need to parse ARNs programmatically to extract individual components. Here are concise examples in Python and JavaScript.
Python
def parse_arn(arn):
"""Parse an ARN into its component parts."""
parts = arn.split(":", 5)
return {
"partition": parts[1],
"service": parts[2],
"region": parts[3],
"account_id": parts[4],
"resource": parts[5],
}
# Usage
arn = "arn:aws:lambda:us-east-1:123456789012:function:my-function"
parsed = parse_arn(arn)
print(parsed["service"]) # "lambda"
print(parsed["region"]) # "us-east-1"
print(parsed["account_id"]) # "123456789012"
print(parsed["resource"]) # "function:my-function"
Note the use of split(":", 5) with a maxsplit of 5. This is critical because the resource portion of the ARN may itself contain colons (as in the Lambda example above). Splitting with no limit would incorrectly break the resource into multiple parts.
JavaScript
function parseArn(arn) {
const parts = arn.split(':');
return {
partition: parts[1],
service: parts[2],
region: parts[3],
accountId: parts[4],
resource: parts.slice(5).join(':'),
};
}
// Usage
const arn = 'arn:aws:ec2:us-east-1:123456789012:instance/i-0abc1234def56789a';
const parsed = parseArn(arn);
console.log(parsed.service); // "ec2"
console.log(parsed.region); // "us-east-1"
console.log(parsed.accountId); // "123456789012"
console.log(parsed.resource); // "instance/i-0abc1234def56789a"
In JavaScript, we use parts.slice(5).join(':') to recombine any colons that appear in the resource portion. This approach handles all ARN formats correctly, whether the resource uses colons, slashes, or a combination of both.
AWS SDK and CLI
Many AWS SDKs also provide built-in ARN parsing utilities. For example, the AWS SDK for Go has arn.Parse(), and the AWS CDK provides Arn.split() across multiple languages. When working within the AWS ecosystem, prefer these built-in utilities over custom parsing code, as they handle edge cases and validation more robustly.
Using Our Free ARN Parser Tool
While understanding ARN structure is valuable, manually parsing and validating ARNs in your daily workflow is tedious and error-prone. That is why we built the QuickUtil AWS ARN Parser — a free, browser-based tool that instantly breaks down any ARN into its component parts.
The QuickUtil AWS ARN Parser provides:
- Instant Parsing: Paste any ARN and instantly see its partition, service, region, account ID, resource type, and resource ID broken out into clearly labeled fields.
- Validation: The parser validates the ARN format and highlights errors, helping you catch typos and formatting mistakes before they cause access-denied errors in production.
- Service Information: Get contextual information about the AWS service namespace, including links to relevant documentation.
- Batch Parsing: Parse multiple ARNs at once, which is invaluable when auditing IAM policies or analyzing CloudTrail logs.
- No Data Transmitted: Everything runs in your browser. Your ARNs — which may contain account IDs and resource names — are never sent to any server.
Whether you are debugging an IAM policy, reviewing CloudTrail events, writing CloudFormation templates, or simply trying to understand which resource an ARN points to, the QuickUtil ARN Parser saves you time and reduces errors.
Parse and Validate AWS ARNs Instantly
Stop guessing at ARN components. Use our free AWS ARN Parser to instantly break down, validate, and understand any Amazon Resource Name.
Try the ARN Parser NowRelated Articles
The Complete Guide to Kubernetes YAML Configuration
Master Kubernetes YAML configuration with this comprehensive guide covering Deployments, Services, StatefulSets, and best practices.
AWS IAM Policy Best Practices: Least Privilege Done Right
Learn how to write secure, maintainable IAM policies following the principle of least privilege.
AWS Security Checklist: Essential Controls for Every Account
Comprehensive checklist of security controls every AWS account should implement from day one.