Move Endpoints out of internal directory

[ekristen]

Describe the feature

There's some use cases for the endpoints package externally for example in my project aws-nuke.

Use Case

There's use cases for accessing endpoints code from external systems.

Proposed Solution

I would suggest moving endpoints out of internal.

Actually I would encourage dropping internal entirely. There's a bunch of good content in internal and for an open source project internal prevents any external use. Usually the argument is "we don't want to support X", but just put that in the README, use at your own risk for things you don't want to support, but otherwise it means people have to duplicate code for zero reason.

Other Information

No response

Acknowledgements

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

AWS Go SDK V2 Module Versions Used

github.com/aws/[email protected] [email protected]

Go version used

go version go1.23.1 darwin/amd64

[lucix-aws]

The mega-table for endpoint information doesn't exist in v2 like it does in v1. We broke the table up across service client modules, because in-memory it was huge (something like 5mb - it was an oft-reported issue e.g. aws/aws-sdk-go#5310) and the whole thing would always exist in-memory even if you weren't using 99% of the services. So, the behavior aws-nuke was using in v1 is not possible to replicate against v2.

Beyond that - the decision to make it internal goes beyond just the Go SDK, it's a decision we've made in SDKs and Tools at large that new SDKs should not expose that information directly. The endpoints/partition table is internal metadata that was previously used to hint to the SDK how to select the endpoint for a given service / region. That process has since been retired in favor of per-service, rules-based endpoint resolution that SDK v2 uses today.

Two primary characteristics of the table that make it unsuitable for general-purpose use:

• Again, it's really just metadata that's meant to influence endpoint selection. It's not an authoritative listing of what services exist where.
• Lack of information in the table (e.g. a service not being shown in a region) does not mean the service isn't actually there. There was some "implicit" or fallback-style behavior in the old resolution scheme that worked around this for forwards compatibility reasons. For example, if a new region released, you could always start using it in an existing SDK right away, even if the region metadata for its services wasn't there yet (either because you hadn't updated your SDK or because the metadata updating lagged behind the region launch, which was common).

The usages of it in aws-nuke were not really correct in that sense, even if it worked incidentally. I'll follow up in the downstream PR with some recommendations.

As far as removing internal altogether is concerned - I'm just going to have to disagree, at least, in the context of this project. There's a ton of junk in internal that provides zero value to the end-user that I believe should be kept there. If there's anything in internal that is valuable, it's probably coupled to the SDK in some way that makes it unsuitable for true general-purpose use. We can always bring things out of internal and polish them on a case-by-case basis, but I just don't think it's appropriate to adopt an "all-exported, handshake-agreement" stance in this particular project.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.