MIGRATION ISSUE: No programatic access to region descriptions used in pricing API

[rifelpet]

Pre-Migration Checklist

• [X] I've read the Migration Guide.
• [X] I've checked AWS Forums and StackOverflow for similar migration issues.

Go Version Used

Go 1.22

Describe the Migration Issue

The pricing.GetProducts API Action supports filtering on arbitrary product metadata. The example output in the AWS CLI docs shows a response with fields:

"locationType":"AWS Region","location":"Asia Pacific (Singapore)"

Note that the location value is not the region name ap-southeast-1 but a region description Asia Pacific (Singapore) that correspond to the values in this table in the AWS docs.

In the v1 SDK this field was available through exported methods:

https://github.com/aws/aws-sdk-go/blob/417f8a94adeed59918cfef686dcb3e438b77735b/aws/endpoints/defaults.go#L179-L181

In the v2 SDK there is no such way to map a region name to a region description, including with ec2.DescribeRegions.

Code Comparison

This repo in the AWS github org demonstrates the SDK v1 usage with pricing.GetProductsInput{}:

https://github.com/aws/amazon-ec2-instance-selector/blob/14d4dfcbaadfe9a1c389c823df8eb7b142f2c997/pkg/ec2pricing/odpricing.go#L275-L297

There is no such solution for SDK v2.

Observed Differences/Errors

I would expect the SDK v2 to offer a mapping between region names and these region descriptions like Asia Pacific (Singapore) so I can filter pricing products by location. Each region's pricing API returns results for all regions, so initializing the pricing API client with a specific region is insufficient.

Additional Context

I'm aware of the desire to treat region identifiers as opaque strings, however this makes the pricing.GetProducts API very difficult to filter by region.

As mentioned in https://github.com/aws/amazon-ec2-instance-selector/pull/158, this prevents the project from fully migrating off of the v1 SDK.

[RanVaknin]

Hi @rifelpet ,

Thanks for reaching out. I can see how having a programmatic list of region to region description names can be handy when wanting to filter on the results of the GetProducts API. Unfortunately we cannot re-introduce this programmatic mapping for a few reasons, one of them was mentioned in my answer that you linked, and but also discussed more in here.

The real problem here is that the getProducts API should not have used a region description and instead would use the region code which is ubiquitous across all AWS service. That would circumvent the need to rely on the list of the region data in the first place.

I know that the following is not really a solution but more of a workaround. You can hand maintain the list of region to region-descriptors yourself. In terms of the API usage, if you were a direct consumer of the API you would have needed to know those region descriptors ahead of time. Not that I'm advocating for this, but if this is truly how the API was designed to work maybe it was an intentional choice from the pricing API team.

What I can do is submit an internal feature request on your behalf to the pricing service team to ask them to add another filter field regionFilter or something of that sort, that would mirror the existing location filter but instead use the actual region code.

Let me know your thoughts. Thanks, Ran~

[rifelpet]

Hi Ran,

Thanks for the quick response. Maintaining a region to descriptor mapping ourselves is too unreasonable of a regression for me to pursue. In this case the region comes from a CLI flag so the expectation should be that our code shouldn't need to know all possible descriptor values ahead of time.

I agree that having the pricing API recognize region identifiers would be the best long term solution. Feel free to feature request and I suppose we'll keep using the v1 SDK until the pricing API fix is implemented. One additional concern here is if the v1 SDK reaches maintenance mode on July 31st 2024 and the feature request still hasn't been implemented. At that point the v1 SDK wont receive new regions, meaning we'll need to add more special casing into our pricing API calling code until the pricing API fix is implemented.

[RanVaknin]

Hi @rifelpet ,

I understand where you are coming from, and sympathetic to the need. I have created an internal feature request with the pricing service team V1378823017. I don't have visibility to when / if this would be implemented, but I will check with them periodically at least to make sure this has made it to their queue.

You can safely mix imports between v2 and v1, so if the only implementation detail holding you back from upgrading to v2 is this, you can simply import alias the package from v1 that has the region info until this is implemented.

If you have access to AWS support through the AWS developer console my advice would be to open a support ticket yourself and reference the ticket ID I shared above, that might help drive this feature forward.

All the best, Ran~