V1 Support of FIPS endpoints

[xiakunhou]

Describe the feature

From the official document, only V2 supports FIPS endpoints. Do we have plan to support FIPS in V1?
The reason that does not migrate to V2 is that V2 is still not stable, and many performance and reliability issues opened.

Cannot risk migrating to V2 and exposing regression behaviors.

Use Case

FIPS

Proposed Solution

Support FIPS

Other Information

No response

Acknowledgements

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

AWS Java SDK version used

1

JDK version used

11,17

Operating System and version

Linux

[debora-ito]

In V1 you can override the endpoint configuration and use the FIPS endpoint:

        AmazonAthena athenaClient = AmazonAthenaClientBuilder.standard()
                .withEndpointConfiguration(
                        new AwsClientBuilder.EndpointConfiguration(
                                "athena-fips.us-east-1.amazonaws.com", 
                                "us-east-1"))
                .build();

In V2 the FIPS endpoint support is a setting in the service client, it is more simple.

The reason that does not migrate to V2 is that V2 is still not stable, and many performance and reliability issues opened.

I'm curious to know which performance issues you're referring to, can you link them here?

[xiakunhou]

Review the issues with label p1, p2 and parity with V1 https://github.com/aws/aws-sdk-java-v2/issues?q=is%3Aopen+is%3Aissue+label%3Ap1%2Cp2%2C%221.x+Parity%22+. There are more than 100 issues still.

For example the memory issue,
aws/aws-sdk-java-v2#3726

For FIPS in V1, in offical document https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html, it claims that FIPS is not supported in V1.
And in your code, you assume the FIPS endpoints are never changed, would this be true ? Seems to be not a official way to support FIPS endpoint.
While to support FIPS in V1 should be quick but of high-value enhancement.

[debora-ito]

@chatgpter thank you for the replies. Let's clarify some points:

(1) We are aware of the 1.x Parity gaps in Java v2. Currently there's 18 features we are tracking as parity (search result here) and we know some of them are blockers for customers to migrate to v2.

(2) p1, p2 and p3 are priority labels, they will be applied to all the issues, parity or not. High priority does not mean reliability problem, other variables are considered.

(3) We have only one p1 bug related to memory issues in v2 using TransferManager and the CRT-based S3 client, it's the one you referenced (aws/aws-sdk-java-v2#3726).
A fix is already in the works (via aws/aws-sdk-java-v2#3800). Besides this one, there's no other known stability issue.

(4) When the FIPS doc page says Java v1 does not support FIPS, it refers to the AWS_USE_FIPS_ENDPOINT environment variable and use_fips_endpoint system setting, Java v1 does not support those forms of settings. You can still customize the EndpointConfiguration to use a fips endpoint directly as I showed in the example in my last comment.
Java v2 does support the AWS_USE_FIPS_ENDPOINT / use_fips_endpoint variables, and you can also set it programmatically in the client:

//Java v2 code sample
S3Client client = S3Client.builder()
                          .fipsEnabled(Boolean.TRUE)
                          .build();

If you ever have the chance to migrate to v2 and experience any regression, please let us know. We perform stability tests and benchmarks before releasing a new product to guarantee we are improving the developer experience.

We are interested to hear your feedback.

[xiakunhou]

@debora-ito I suggest enhancing V1 to support FIPS endpoint similart to V2.
Instead of providing the hard-coded FIPS endpoint, we just use a flag to specify this. Because the hard-coded way is not stable and is really a bad practice, considering may need code change with later changes on the AWS side.

[debora-ito]

We don't have plans to add support for the FIPS settings in V1.

If you don't want to use V1 EndpointConfiguration I recommend you migrate to V2. And I agree that hard-coding the endpoint is not ideal, but I wouldn't worry much about it changing in the future. Changing a service endpoint is a breaking change, and it would break everybody that relies on the endpoint. We don't do backwards incompatible changes.

[github-actions]

COMMENT VISIBILITY WARNING

Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.