-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve documentation around client/credential caching #2775
Comments
Hi @stanhu, Our developer guide talks about this:
Regarding your question:
If you are using This isn't covered in the migration guide because the functionality in v1 and v2 is the same with regards to how credentials are rotated. The only difference is the re-naming of the config object, which in v1 was confusingly named "session" even though it does not really represent a session but rather a config object. I suppose we can add another section in the migration guide about the credential rotation behavior. Thanks, |
@RanVaknin Thanks, that helps clarify things!
Yes, that would be helpful. |
This issue is now closed. Comments on closed issues are hard for our team to see. |
Describe the issue
In https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/sessions.html, the guidance for caching
s3.Session
was clear:In https://aws.github.io/aws-sdk-go-v2/docs/migrating/ and https://aws.github.io/aws-sdk-go-v2/docs/making-requests/, I'm not clear on what could be cached. We have a long-lived application that might make hundreds of S3 calls over time, and we want to avoid hitting STS limits. If I understand correctly:
In this example:
1.
config.LoadDefaultConfig
: I think this might make a HTTP request to the instance metadata or STS endpoint if no static credentials are configured.2.
s3.Client
: This creates a new S3 client and loads the credentials from the config.Is it okay to cache
s3.Client
indefinitely? I presume that when the credentials are expired, it will automatically refresh them.It should also be okay to cache
config.LoadDefaultConfig
to avoid making an HTTP call, but it might just be easier to caches3.Client
.It'd be nice to update the documentation, especially in the migration guide, about this behavior.
Links
AWS Go SDK V2 Module Versions Used
The text was updated successfully, but these errors were encountered: