AWS ARN Structure
Luke Hebert
- 2 minutes read - 333 wordsUnderstanding how AWS ARNs are structured saves time when writing IAM policies, debugging permission errors, or referencing resources across accounts. Below is a component-by-component breakdown of the standard ARN format, along with a worked example you can use as a template.
Understanding AWS ARNs: Every resource in AWS is uniquely identified by an Amazon Resource Name (ARN). ARNs are used in IAM policies, API calls, and resource references to precisely specify which resource an action applies to. The image above breaks down the standard ARN format into its individual components, making it easy to read and construct ARNs for your own policies and configurations.
AWS ARN Breakdown
An AWS ARN follows this general structure:
arn:partition:service:region:account-id:resource| Component | Description | Example |
|---|---|---|
| arn | Literal prefix that identifies the string as an ARN. | arn |
| partition | The AWS partition. aws for the standard commercial region, aws-cn for China, aws-us-gov for GovCloud. | aws |
| service | The AWS service namespace (e.g., iam, s3, ec2, lambda). | iam |
| region | The AWS Region code. Left empty for global services like IAM or Route 53. | (empty) or us-east-1 |
| account-id | The 12-digit AWS account number that owns the resource. | 123456789012 |
| resource | The specific resource type and identifier. Format varies by service. | user/username or bucket-name/key |
Example
arn:aws:iam::123456789012:user/DevOpsAdmin- arn → ARN identifier
- aws → Standard commercial partition
- iam → IAM service
- :: (empty) → IAM is a global service, so no region
- 123456789012 → The owning AWS account
- user/DevOpsAdmin → The specific IAM user
Why It Matters
- IAM Policies: ARNs are used in the
Resourceelement to scope permissions to exact objects. - Cross-Account Access: The account-id segment lets you reference resources owned by a different AWS account.
- Service-Specific Variations: Some services (S3, Lambda, KMS) have additional sub-delimiters (
/or:) within the resource segment to distinguish between the resource type and its ID.
When writing IAM policies, always use the full ARN rather than * unless you truly intend to grant access to all resources of that type. This follows the principle of least privilege.