Support for FIPS flag with Service-Specific endpoints configuration

[juchavw]

Describe the feature

This feature request is asking for support to have the useFIPS flag and service-specific/custom endpoints to be able to be set together so that when the useFIPS flag is enabled, all endpoints resolved internally in the SDK use the FIPS variant unless there is an override via a custom endpoint for a given service.

Use Case

Currently, customers desiring to use FIPS endpoints for regulations and compliance purposes can enable the FIPS flag in the Java SDK V2 which results in the SDK generating fips endpoints regardless of whether the FIPS endpoint is available or supported for a given service or not.

A customer could then override a specific endpoint for a service (using custom endpoints) that does not have FIPS available (like Dynamo Streams) while keeping the FIPS flag enabled to make all other service endpoints use FIPS.

In Java SDK V2, the combination of the useFIPS flag and custom endpoint overrides results in an SDK Client Exception reporting the combination of both settings are is not allowed:

Invalid Configuration: FIPS and custom endpoint are not supported

This results in customers having to deal with additional overhead to maintain a list of endpoints they can customise for all the services they use, setting FIPS endpoints in the services they know are available and non-FIPS endpoints for services that do not have FIPS support.

In this way, the overhead of tailoring and maintaining long lists of custom endpoints is removed from the customer side, it reduces human error and maintenance at scale for customers deployed across multiple regions, and it helps make the SDK experience more pleasant for developers by reducing the amount of effort to adopt FIPS endpoints where they are supported.

Proposed Solution

No response

Other Information

Sample scenarios used to verify current behaviour:

• FIPS flag enabled, no override, calling DynamoDB Streams:

Exception in thread "main" software.amazon.awssdk.core.exception.SdkClientException:
Received an UnknownHostException when attempting to interact with a service.
See cause for the exact endpoint that is failing to resolve.
If this is happening on an endpoint that previously worked,
there may be a network connectivity issue or your DNS cache could be storing endpoints for too long.

Caused by: software.amazon.awssdk.core.exception.SdkClientException:
Unable to execute HTTP request: streams.dynamodb-fips.us-east-1.amazonaws.com

• FIPS flag enabled, overriding DynamoDB Streams to localhost:4444, calling DDB Streams

Exception in thread "main" software.amazon.awssdk.core.exception.SdkClientException:
Invalid Configuration: FIPS and custom endpoint are not supported

• FIPS flag disabled, overriding DynamoDB Streams to localhost:4444, calling DDB Streams

Caused by: org.apache.http.conn.HttpHostConnectException:
Connect to localhost:4444 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused

• FIPS flag disabled, no override, calling DDB Streams: all good ✅

Acknowledgements

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

AWS Java SDK version used

2.28.7

JDK version used

openjdk 18.0.2 2022-07-19 OpenJDK Runtime Environment Corretto-18.0.2.9.1 (build 18.0.2+9-FR) OpenJDK 64-Bit Server VM Corretto-18.0.2.9.1 (build 18.0.2+9-FR, mixed mode, sharing)

Operating System and version

macOS 13.6.7

[debora-ito]

so that when the useFIPS flag is enabled, all endpoints resolved internally in the SDK use the FIPS variant unless there is an override via a custom endpoint for a given service.

Just to confirm, you're proposing for the SDK to have an internal logic to: use the aws fips endpoint for that service, and if it's not available then fallback to the custom endpoint?

If so, I don't think this "fallback" is a behavior we want to support specially when it relates to the use of fips endpoints.

[debora-ito]

@juchavw I apologize, I understand this request has been raised to our team already. Even though the solution we end up adopting may not be exactly the one you described, we see the use case and will address the need to improve the FIPS configuration experience in some form.