Remove ServiceMetadata usage from AwsClientEndpointProvider in generated client builders

[S-Saranya1]

Motivation and Context

When creating any AWS service client (e.g., DynamoDbClient.builder().region(...).build()), the SDK resolves a default client endpoint by calling ServiceMetadata.of(servicePrefix). This triggers the static initialization of GeneratedServiceMetadataProvider, which eagerly instantiates all 310 service metadata classes — even though only one is needed. This adds 350-500ms of cold start latency, significantly impacting Lambda and other latency-sensitive
applications.

The endpoint resolved by ServiceMetadata is ultimately replaced by Endpoints 2.0 at request time anyway, making this initialization cost entirely wasted.

Modifications

AwsClientEndpointProvider.java

• Added buildIfOverridePresent() method to the Builder. This checks only endpoint overrides and environment sources (system properties, env vars, profile config) and returns Optional.empty() if none are configured, without ever touching ServiceMetadata.
• Added resolveFromOverridesAndEnvironment() — same resolution chain as existing resolveClientEndpoint() but without the ServiceMetadata fallback.

BaseClientBuilderClass.java (codegen template)

• Changed the generated finalizeServiceConfiguration() method to use a three-step approach:

  1. Call buildIfOverridePresent() — if the user configured an override or environment endpoint, use it directly.
  2. Best-effort resolve using the service's own Endpoints 2.0 provider with client-config params (region, fips, dualstack). This succeeds for 95%+ of services and produces a real, debuggable endpoint.
  3. If Endpoints 2.0 resolution fails (e.g., S3 requires request-bound params like bucket, forcePathStyle), fall back to a https://localhost placeholder that gets replaced at request time.

• Added host validation after successful resolution to preserve fail-fast behavior for invalid regions (e.g., US_EAST_1 with underscores).

• useDualStack/useFips params are only set conditionally based on whether the service's endpoint rules model declares those built-ins.

Testing

• Added unit tests for buildIfOverridePresent() covering override path, environment path, and empty result when no override is configured.
• Verified existing endpoint resolution and invalid region validation tests continue to pass.

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

[dagnir]

Can we add or update tests in codegen-generated-classes-test to test this behavior on a generated client?

[dagnir]

This is a pretty awkward API. Can we just introduce a method that only returns the endpoint resolved from the overrides, and the client builders can check that instead?

[S-Saranya1]

yeah, the resolution methods (clientEndpointFromClientOverride, etc.) were instance methods, so the Builder couldn't call them directly, hence the workaround of constructing a full provider. Agreed it's unnecessary. Made those methods static (they never used instance state anyway) and added resolveFromOverrides() method to return the endpoint resolved from the overrides.

[dagnir]

This is expected for services that require request-bound

Is this always accurate? (i.e. could the params be from somewhere other than request bound (e.g. context params). Should we just say "expected for services with required parameters besides region/dualstack/fips"?

[S-Saranya1]

Right, updated it.

[S-Saranya1]

Can we add or update tests in codegen-generated-classes-test to test this behavior on a generated client?

Added the test.

[dagnir]

Nice job

[github-actions]

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.