Introduction

An ARN identifies an AWS resource, but AWS does not provide one universal API that can fetch the full details of every possible resource type from any ARN. The ARN tells you which service owns the resource. After that, you usually need to call that service's own API, using the appropriate identifier format for that service. The important design point is that ARNs are naming syntax, not a cross-service object model.

Parse the ARN First

The first step is to inspect the ARN and identify the service, region, account, and resource segment.

1arn = "arn:aws:lambda:us-east-1:123456789012:function:demo-fn"
2parts = arn.split(":", 5)
3partition, service, region, account_id, resource = parts[1], parts[2], parts[3], parts[4], parts[5]
4print(service, region, account_id, resource)

Once you know the service is lambda, ec2, sns, or something else, you can choose the correct client and lookup call.

Dispatch to the Service-Specific API

A practical pattern is to parse the ARN and then route to a service-specific function.

1import boto3
2
3
4def get_lambda_function(function_arn):
5    client = boto3.client("lambda")
6    return client.get_function(FunctionName=function_arn)
7
8
9def get_sns_topic(topic_arn):
10    client = boto3.client("sns")
11    return client.get_topic_attributes(TopicArn=topic_arn)

The exact API differs because the resource models differ. Some services accept the full ARN directly. Others expect a name, ID, or separate parameter values derived from the ARN.

There Is No Universal "Get Anything" Call

This is the core limitation. AWS has common concepts such as ARNs, IAM policies, and tagging, but resource retrieval remains service-specific.

That is why a function named get_resource_by_arn in your own code usually ends up being a dispatcher, not a single SDK call. It is an integration layer you write on top of many service APIs.

Generic Discovery APIs Have Narrower Scope

AWS does have APIs that can help discover resources, but they do not replace service-specific reads. For example, the tagging API can enumerate tagged resources, and inventory-style tools can help locate things. Those are useful for search and indexing, but they are not a guaranteed full-detail fetch API for every ARN.

This distinction matters because developers often search for a universal ARN endpoint when what they actually need is either resource discovery or service-specific description calls.

Design a Dispatcher Explicitly

If you control the application, make the supported services explicit and fail clearly for unsupported ones.

1import boto3
2
3
4def get_resource_by_arn(arn):
5    parts = arn.split(":", 5)
6    service = parts[2]
7
8    if service == "lambda":
9        return boto3.client("lambda").get_function(FunctionName=arn)
10    if service == "sns":
11        return boto3.client("sns").get_topic_attributes(TopicArn=arn)
12
13    raise ValueError(f"Unsupported service in ARN: {service}")

This is much better than pretending every ARN can be handled identically. It also forces you to think about permissions, response normalization, and region selection.

Permissions Still Apply

Even with the correct ARN and correct service call, you still need the right IAM permissions. A valid ARN is only an identifier. It does not grant visibility or access on its own.

That means ARN parsing and authorization are separate concerns. Your code can identify the resource type successfully and still fail with an access error when it tries to fetch details.

Common Pitfalls

• Assuming AWS provides one SDK method that returns any resource by ARN.
• Forgetting to parse the service from the ARN before deciding which API to call.
• Expecting every service to accept the full ARN in the same parameter shape.
• Confusing discovery APIs with detailed resource retrieval APIs.
• Ignoring IAM permissions when debugging a lookup failure.

Summary

• An ARN identifies a resource, but it does not imply a universal fetch API.
• Parse the ARN first to determine the owning service.
• Use that service's own describe, get, or list API next.
• Build your own dispatcher when you need a single application-level lookup entry point.
• Treat discovery, retrieval, and authorization as separate concerns.