Generate AWS ARNs & other AWS data

[douglasg14b]

Clear and concise description of the problem

Generating fake AWS arns is reasonably common when testing code that works with & interprets ARNs.

The process of generating an ARN generally means we will be enumerating many AWS constants, and maybe should be rolled into an entire AWS module.

Suggested solution

Reference script to get a list of all services & ARN formats: https://github.com/dannysteenman/aws-iam-arns

Spec:

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

API:

• faker.string.arn() or:

// Taking advantage of all the other generators needed in order to produce an ARN
faker.aws.
    accountId()
    arn()
    arnFormat()
    partition()
    region()
    resourceId()
    resourceType()
    service()

More Research

A full range of acceptable values and formats appears to be available by parsing a few sources, making is so generated ARNs could be precisely accurate to their real world counterparts. Which could be supported largely by codegen.

1. The CloudFormation resource specification for us-east-1 at https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-resource-specification.html
   • It looks like resource available is based on region, however that may be too granular for such a generaotr
2. The policies.js file at: https://awspolicygen.s3.amazonaws.com/js/policies.js

Alternative

¯\_(ツ)_/¯

Additional context

No response

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes (:+1:) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest