AWS ARN Format Explained: Complete Guide to Amazon Resource Names

March 11, 2026 18 min read Suvom Das

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:

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 Now

Related 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.