ARTIFACTORY: How to Resolve S3 "400 Bad Request" Startup Failures During Upgrades by Explicitly Specifying the AWS Region

Introduction

During an Artifactory upgrade (specifically to version 7.146.7 or later), the application may fail to initialize, leaving the service unable to start. Upon reviewing the artifactory-service.log, you will observe a Failed to initialize BinaryServiceImpl error, accompanied by an S3Exception: Bad Request (Service: S3, Status Code: 400) exception originating from a HeadBucket request. This issue affects environments using the S3 binary provider where the binarystore.xml configuration specifies an <endpoint> but omits the <region> parameter. The solution involves explicitly defining the region within your S3 provider configuration.

Problem

The root cause of this startup failure stems from a change in the default AWS SDK used by Artifactory. Starting with Artifactory version 7.146.7, the AWS SDK v2 is enabled by default for all new instances and upgrades, unless specifically disabled with <awsSdkV2>false</awsSdkV2>.

Under the older AWS SDK v1, if an <endpoint> was configured without a <region>, the SDK would automatically infer the region from the endpoint hostname (e.g. inferring us-west-2 from s3.us-west-2.amazonaws.com). However, AWS SDK v2 is stricter than v1: it does not infer the region from the endpoint hostname. When an <endpoint> is provided but the <region> is not, SDK v2 falls back through its standard region-resolution chain (JVM system property → AWS_REGION env var → AWS config file → EC2 IMDS). If that chain resolves to a region that does not match the bucket's actual region, SigV4 signing uses the wrong region. AWS rejects the request with HTTP 400 AuthorizationHeaderMalformed, which Artifactory shows as S3Exception: Bad Request at startup during the HeadBucket existence check.

For example, a configuration like the following will trigger this failure upon upgrading to 7.146.x because it defines <endpoint> without <region>:

<config version="2">
    <chain template="s3-storage-v3"/>
    <provider type="cache-fs" id="cache-fs">
        <maxCacheSize>5000000000</maxCacheSize>
    </provider>
    <provider type="s3-storage-v3" id="s3-storage-v3">
        <path>123456789</path>
        <bucketName>artifactory-bucket</bucketName>
        <endpoint>https://s3.us-west-2.amazonaws.com</endpoint>
        <credential>...</credential>
        <identity>...</identity>
    </provider>
</config>



Resolution 

To fix this issue, you need to update the binarystore.xml configuration to provide the missing region context required by AWS SDK v2.

Step-by-Step Instructions

Locate your configuration file: Open the binarystore.xml file located in $JFROG_HOME/artifactory/var/etc/artifactory/.

Add the missing region: Inside your S3 provider block (e.g. <provider type="s3-storage-v3" id="s3-storage-v3">), add the <region> element that accurately matches the physical region of your bucket. For example:

<config version="2">
    <chain template="s3-storage-v3"/>
    <provider type="cache-fs" id="cache-fs">
        <maxCacheSize>5000000000</maxCacheSize>
    </provider>
    <provider type="s3-storage-v3" id="s3-storage-v3">
        <path>123456789</path>
        <bucketName>artifactory-bucket</bucketName>
        <endpoint>https://s3.us-west-2.amazonaws.com</endpoint>
        <credential>...</credential>
        <identity>...</identity>
        <region>us-west-2</region>
    </provider>
</config>

Restart Artifactory: Save the binarystore.xml file. Then, restart the Artifactory services to trigger a fresh initialization.


Optional Workaround (Legacy Behavior): If you prefer to temporarily revert to the previous SDK v1 behavior while you plan your configuration changes, you can add <awsSdkV2>false</awsSdkV2> inside the <provider> block. Please note, AWS SDK v1 will reach its official end-of-support at the end of 2025. Therefore, disabling SDK v2 should only be used as a short-term workaround.