Use Ec2MetadataClient in defaults mode by S-Saranya1 · Pull Request #6301 · aws/aws-sdk-java-v2

S-Saranya1 · 2025-07-28T19:42:20Z

AutoDefaultsModeDiscovery changes to use Ec2MetadataClient

Motivation and Context

This change migrates IMDS-backed providers from using internal utilities to the public Ec2MetadataClient API.

AutoDefaultsModeDiscovery currently uses the internal EC2MetadataUtils class via HttpResourcesUtils, which doesn't respect certain IMDS client configurations
Lacks features like IMDS session token caching and auto-refresh
It replaces the basic HttpURLConnection with a HTTP client that offers much better debugging capabilities
Uses separate IMDS implementation instead of the public Ec2MetadataClient

This PR specifically addresses the Auto defaults mode discovery component, which is one of three planned migrations (along with InstanceProfileCredentialsProvider and InstanceProfileRegionProvider).

Github Feature Request: #5876

Modifications

Migrated AutoDefaultsModeDiscovery class to use Ec2MetadataClient from EC2MetadataUtils.
Created Ec2MetadataSharedClient, which creates a shared HTTP client that is shared among the providers.
Added DefaultEc2MetadataClientWithFallback for IMDSv1 compatibility.
Added imds module dependency to aws-core module's pom.xml

Testing

All existing tests pass - AutoDefaultsModeDiscoveryTest continues to validate original functionality
Added "AutoDefaultsModeDiscoveryEc2MetadataClientTest" which has unit tests that test the migration from EC2MetadataUtils to Ec2MetadataClient.

Screenshots (if appropriate)

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)

Checklist

I have read the CONTRIBUTING document
Local run of mvn install succeeds
My code follows the code style of this project
My change requires a change to the Javadoc documentation
I have updated the Javadoc documentation accordingly
I have added tests to cover my changes
All new and existing tests passed
I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

I confirm that this pull request can be released under the Apache 2 license

core/aws-core/pom.xml

...ain/java/software/amazon/awssdk/awscore/internal/defaultsmode/AutoDefaultsModeDiscovery.java

core/imds/src/main/java/software/amazon/awssdk/imds/internal/BaseEc2MetadataClient.java

...zon/awssdk/awscore/internal/defaultsmode/AutoDefaultsModeDiscoveryEc2MetadataClientTest.java

...src/main/java/software/amazon/awssdk/imds/internal/DefaultEc2MetadataClientWithFallback.java

...zon/awssdk/awscore/internal/defaultsmode/AutoDefaultsModeDiscoveryEc2MetadataClientTest.java

core/imds/src/main/java/software/amazon/awssdk/imds/internal/Ec2MetadataSharedClient.java

Adding the logic to close the client Addressing PR feedback

millems · 2025-08-01T14:29:38Z

...ain/java/software/amazon/awssdk/awscore/internal/defaultsmode/AutoDefaultsModeDiscovery.java

+            String ec2InstanceRegion = client.get(EC2_METADATA_REGION_PATH).asString();
            return Optional.ofNullable(ec2InstanceRegion);
-        } catch (Exception exception) {
+        } catch (SdkClientException e) {


What was this change for?

To fix a SpotBugs warning that complained about catching Exception when no exception was thrown and client.get() actually throws SdkClientException (and its subclasses), so changed this to more specific exception.

Should we do RuntimeException, instead? This would catch the same exceptions as before, but not upset spotbugs. Unless we want a potential behavior change?

...zon/awssdk/awscore/internal/defaultsmode/AutoDefaultsModeDiscoveryEc2MetadataClientTest.java

...src/main/java/software/amazon/awssdk/imds/internal/DefaultEc2MetadataClientWithFallback.java

millems · 2025-08-01T15:05:45Z

core/imds/src/main/java/software/amazon/awssdk/imds/internal/Ec2MetadataSharedClient.java

+            return this;
+        }
+
+        public synchronized Ec2MetadataClient build() {


This synchronized uses a different lock from the containing class's synchronized. Maybe we should just manually create a reentrant lock and share that?

Yes, Thanks for this, updated to use reentrant lock.

millems · 2025-08-01T15:10:31Z

core/imds/src/main/java/software/amazon/awssdk/imds/internal/Ec2MetadataSharedClient.java

+ * This provides resource efficiency by sharing a single HTTP client across all IMDS-backed providers
+ */
+@SdkProtectedApi
+public final class Ec2MetadataSharedClient {


Instead of having a separate protected class and API for this, should it be a feature of Ec2MetadataClient? E.g. if they do Ec2MetadataClient.builder().build(), we use a shared HTTP client instead of a new one? We'd still use reference counting to close the shared HTTP client when no metadata clients are using it anymore.

That would remove the need for another protected API we need to maintain/remember to use, and improve the creation time of multiple Ec2MetadataClients for customers.

If we make Ec2MetadataClient.builder().build() calls use a shared HTTP client, then client.close() would only decrement the reference count instead of actually closing resources, this would be a behavior change for users right? They expect their client to be fully closed but it's not closing. Alternatively, if we kept user-created clients separate from internal provider clients, we'd need to add a new public API feature to Ec2MetadataClient for providers to use shared clients, but that would be a public API change and users could also access.

If we changed the default to use a shared client, how would that behavior change negatively affect the customer?

core/imds/src/main/java/software/amazon/awssdk/imds/internal/RequestMarshaller.java

millems · 2025-08-01T15:15:27Z

...src/main/java/software/amazon/awssdk/imds/internal/DefaultEc2MetadataClientWithFallback.java

+ * An Implementation of the Ec2Metadata Interface with IMDSv1 fallback support.
+ * This client is identical to DefaultEc2MetadataClient but provides automatic fallback
+ * to IMDSv1 when IMDSv2 token retrieval fails (except for 400 errors).


Should this just be a feature of Ec2MetadataClient as well? Ec2MetadataClient.builder().v1FallbackAllowed(true).build()

It would remove the duplicated code between the two implementations, make the usage of v1 something customers can choose to use in their own Ec2MetadataClients, and reduce the number of APIs we need to manage/remember to use.

That would be a public API change, and we only want IMDSv1 fallback for backward compatibility in internal providers so didn't go for that approach.

If we can reduce the number of protected APIs and simplify the code, it might be worth having v1 fallback be a public API.

I'm concerned about the duplication and additional protected surface area the current approach creates. Can you think of other ways to reduce it, without making a public API for enabling v1 fallback?

millems · 2025-08-01T15:17:37Z

.../main/java/software/amazon/awssdk/core/internal/http/loader/DefaultSdkHttpClientBuilder.java

 */
-@SdkInternalApi
+@SdkProtectedApi
 public final class DefaultSdkHttpClientBuilder implements SdkHttpClient.Builder {


Darn, I see we already released something that uses this, so this is just backfilling it to mark it as protected. If we needed it to be protected, we should have moved it out of the internal package or ideally not have made it protected. Too late for that.

Yeah :(
Added the comment about it.

sonarqubecloud · 2025-08-01T23:27:27Z

Quality Gate failed

Failed conditions
77.4% Coverage on New Code (required ≥ 80%)
8.5% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

Refactoring BaseEc2MetadataClient constructor

L-Applin

Matt still has some concerns, but I think they were all part of the design that we reviewed while he was on vacation. It's all compromises for not introducing the v1 fallback available as a public API on the IMDS, which is what we agreed on during design.

github-actions · 2026-01-27T18:09:51Z

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.

Use Ec2MetadataClient in defaults mode

505479b

S-Saranya1 requested a review from a team as a code owner July 28, 2025 19:42

S-Saranya1 added 4 commits July 28, 2025 13:16

Adding changelog

8fb93a8

Fixing tests

d23900d

Fixing test failures

385d583

Additional changes

ad0fd27

L-Applin suggested changes Jul 30, 2025

View reviewed changes

L-Applin reviewed Jul 30, 2025

View reviewed changes

core/imds/src/main/java/software/amazon/awssdk/imds/internal/Ec2MetadataSharedClient.java Outdated Show resolved Hide resolved

S-Saranya1 added 3 commits July 31, 2025 13:49

Additional Changes:

8eef6e4

Adding the logic to close the client Addressing PR feedback

Addressing PR feedback

c82dc94

Fixing test failures

261d5f9

millems reviewed Aug 1, 2025

View reviewed changes

S-Saranya1 added 2 commits August 1, 2025 12:43

Addressing PR feedback

a9a68bb

Suppress architecture test violations

f7c7c59

Additional changes:

7024b85

Refactoring BaseEc2MetadataClient constructor

L-Applin approved these changes Aug 6, 2025

View reviewed changes

S-Saranya1 closed this Jan 27, 2026

github-actions bot locked as resolved and limited conversation to collaborators Jan 27, 2026

Conversation

S-Saranya1 commented Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation and Context

Modifications

Testing

Screenshots (if appropriate)

Types of changes

Checklist

License

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

S-Saranya1 Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Aug 1, 2025

Quality Gate failed

Uh oh!

L-Applin left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jan 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

S-Saranya1 commented Jul 28, 2025 •

edited

Loading

S-Saranya1 Aug 1, 2025 •

edited

Loading