Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

GetResources (Resource Groups Tagging API) returns ARNs with the participant account ID instead of the owner account ID for RAM-shared VPC/subnet/security-group resources — bug or expected?

0

I'm seeing consistent behavior where the Resource Groups Tagging API (resourcegroupstaggingapi:GetResources) returns ARNs for RAM-shared EC2 networking resources (VPC, subnet, security group) using the calling/participant account ID instead of the actual resource-owner account ID.

Repro steps:

  1. In account 111111111111 (owner), create a VPC and share it via AWS RAM with the whole AWS Organization (didn't test with sharing with specific account).
  2. In account 222222222222 (participant), the shared VPC becomes visible. Tag it: shared=true.
  3. From account 222222222222, run:

aws --profile 222222222222 resourcegroupstaggingapi get-resources --tag-filters Key=shared,Values=true

Result:

"ResourceARN": "arn:aws:ec2:region:222222222222:vpc/vpc-123"

Note the account ID is 222222222222 (the participant/caller), not 111111111111 (the actual owner). describe-vpcs correctly reports OwnerId: 111111111111 for the same resource, so the tagging API clearly has access to (or could derive) the correct owner account ID — it just isn't using it in the ARN it returns.

Additionally:

  • Calling get-resources --resource-arn-list arn:aws:ec2:region:111111111111:vpc/vpc-123 (the "real" owner ARN) returns an empty result.
  • Calling it with arn:aws:ec2:region:222222222222:vpc/vpc-123 (participant account ID) successfully returns the resource.
  • This happens uniformly across every account the resource is shared with — each sees its own account ID baked into the ARN.
  • Same behavior occurs for subnets and security groups
  • resourcegroupstagging/TagResources API call works both with correct ARN with owner id and with incorrect ARN with participant id (so both aws --profile 222222222222 resourcegroupstaggingapi tag-resources --tags TESTTAG=TESTVALUE --resource-arn-list arn:aws:ec2:region:222222222222:vpc/vpc-123 and aws --profile 222222222222 resourcegroupstaggingapi tag-resources --tags TESTTAG=TESTVALUE --resource-arn-list arn:aws:ec2:region:111111111111:vpc/vpc-123 will work)

Questions:

  1. Is this documented/expected behavior for the Resource Groups Tagging API specifically for VPC/subnet/security-group resource types, or is it a bug?
  2. If expected, is there a doc page that describes this? I haven't been able to find one.

Thanks in advance — happy to provide full CLI output/logs if useful.

Topics
ComputeSecurity, Identity, & Compliance
Tags
TaggingAmazon EC2AWS Resource Access Manager
Language
English

asked a month ago49 views

1 Answer
-1

Based on the available documentation, the Resource Groups Tagging API's GetResources operation is designed to return tagged resources in the specified AWS Region for the calling account. The behavior you're observing appears to be related to how the API represents shared resources from the perspective of the participant account.

The GetResources operation returns resources that are tagged or previously tagged in your account's context. When you tag a RAM-shared VPC from the participant account and then query it using GetResources, the API returns the resource with an ARN that reflects the calling account's perspective, even though the underlying resource is owned by a different account.

This behavior is consistent with the API's design principle of returning resources "for the account" making the call. The API focuses on returning resources that are accessible and tagged within the context of the calling account, rather than necessarily preserving the original owner's account ID in all cases.

However, I should note that the specific documentation about how GetResources handles RAM-shared resources and ARN formatting for cross-account shared resources is not explicitly detailed in the available sources. The core documentation focuses on the general behavior of returning tagged resources for the calling account and filtering capabilities, but doesn't specifically address the nuances of RAM-shared resource ARN representation.

For definitive clarification on whether this is intended behavior or a bug, and for any workarounds or best practices when working with RAM-shared resources in the Resource Groups Tagging API, I'd recommend opening a case in the AWS Support Center at https://console.aws.amazon.com/support/ where the support team can investigate this specific scenario with the service team and provide authoritative guidance.
Sources
GetResources - Resource Groups Tagging API
get_resources - botocore 1.43.15 documentation
get_resources - Boto3 1.43.15 documentation

answered a month ago

EXPERT

reviewed a month ago

  • ndrkrtshv
    a month ago

    From https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html :

    1. "Amazon Resource Names (ARNs) uniquely identify AWS resources"
    2. "account-id - The ID of the AWS account that owns the resource"

    Resource tagging API must return correct ARNs so I can use it in other API calls, using different API creds of another account. Obviously, ARN with previous caller account id won't work in API call with another account creds. Resource tagging API is first-party AWS service which should have access to owner id.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content