AWS_S3_REGION bypasses the AWS SDK's standard region resolution #8

ConfigureAWS always passes region explicitly:

const client = new S3.S3Client({
  region: process.env.AWS_S3_REGION ?? "us-east-1",
  credentialDefaultProvider: defaultProvider,
});

Because a value is always supplied, the AWS SDK's own region resolution chain never runs — and that chain is what honours the conventional AWS_REGION / AWS_DEFAULT_REGION environment variables, plus the shared config file and IMDS.

The consequence: a deployment configured the standard way, with AWS_REGION=ap-south-1 and no AWS_S3_REGION, silently gets us-east-1. Requests then go cross-region — succeeding but slower and more expensive, or failing with an opaque error depending on the bucket. There is no warning, because from the SDK's point of view the caller asked for us-east-1.

This has already caught someone

README.md:213 documents the custom name, so AWS_S3_REGION looks deliberate:

- `AWS_S3_REGION`: AWS region (default: "us-east-1")

But the pre-existing test suite sets the standard variable against code that never reads it — src/file-store.spec.ts:43, :172 and :180 all use process.env.AWS_REGION. The test passes regardless, because the assertion never depended on the region actually being applied.

Suggested fix

Fall back through the conventional names before defaulting:

region: process.env.AWS_S3_REGION ?? process.env.AWS_REGION ?? "us-east-1",

This keeps AWS_S3_REGION working as documented and as an explicit override, while no longer silently ignoring the variable every other AWS tool in the environment already sets. Worth updating README.md:213 to describe the precedence.

ConfigureMinio has the same shape with MINIO_REGION, but there the endpoint is explicit and region is largely vestigial, so it is not affected in practice.