Skip to content

Conversation

@perpil
Copy link

@perpil perpil commented Dec 27, 2023

STS has been multi-region for some time now. It's a best practice to use the regional endpoint for latency and availability reasons.

STS has been multi-region for some time now.  It's a best practice to use the regional endpoint: https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html

Although the global region still works, for some opt-in regions, it's required to use the regional endpoint.
@mhart
Copy link
Owner

mhart commented Apr 23, 2024

I appreciate this change – unfortunately it would be (arguably) backwards incompatible, so I suspect it would need to land on a major update (ie, when/if this moves to 2.x). I say arguably because it shouldn't break anything per se, but it would potentially change where people's requests are going, which may be unexpected.

Just as an FYI for anyone stumbling across this – you can specify your own host to override this behaviour and still have it work with multi-region STS. ie:

aws4.sign({ host: 'sts.us-west-2.amazonaws.com', path: '/?Action=AssumeRole' })

(it will pull out the service and region correctly from the host – but you can also supply them yourself as well, there's no harm in that, and generally if you give service, region and host you've got the highest chance of signing everything correctly)

@mhart mhart added the v2.x Requires a major version update label May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2.x Requires a major version update

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants