(Application Autoscaling): Access the ARN or "unique identifier" of a ScalableTarget

[Liversticks]

Describe the feature

Currently, for the Application Autoscaling ScalableTarget, there is the scalableTargetId field. This represents the ResourceId in a request made to the RegisterScalableTarget API.

If possible, we would like to access the ARN or the unique id of the scalable target itself, as described in the "Resources" subsection of the "Identity-based policies" section here

Use Case

We want to create identity-based policies for IAM roles to better control access to auto-scaling. We would like to create these roles using CDK because we have a multi-region architecture and need to set up these roles in multiple accounts per region. In order to create the roles, we need to access the Application Autoscaling unique identifier or ARN (like arn:aws:application-autoscaling:us-east-1:123456789012:scalable-target/1234abcd56ab78cd901ef1234567890ab123). We want to avoid using wildcards in the resource field because each account manages multiple auto scaling targets.

Proposed Solution

No response

Other Information

We could implement this by using a custom Lambda-based CloudFormation resource that calls the Application Autoscaling API directly. However, if possible, we would like to avoid using custom resources as the code that implements the custom functionality is separated from the code that defines the rest of our stacks.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.115.0

Environment details (OS name and version, etc.)

macOS 13.6.2

[pahud]

Understand but if you look at the CFN spec, it does not return the ARN of the resource
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html#aws-resource-applicationautoscaling-scalabletarget-return-values

CDK could build and return the ARN in the constructor for known resources such as ecs services based on known props. This might be a very handy in your use cases but I guess you still can build the ARN based on all the information you have. Making this a p2 and we welcome more ideas here.