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.
ConfigureAWSalways passesregionexplicitly: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_REGIONenvironment variables, plus the shared config file and IMDS.The consequence: a deployment configured the standard way, with
AWS_REGION=ap-south-1and noAWS_S3_REGION, silently getsus-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 forus-east-1.This has already caught someone
README.md:213documents the custom name, soAWS_S3_REGIONlooks deliberate:But the pre-existing test suite sets the standard variable against code that never reads it —
src/file-store.spec.ts:43,:172and:180all useprocess.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:
This keeps
AWS_S3_REGIONworking as documented and as an explicit override, while no longer silently ignoring the variable every other AWS tool in the environment already sets. Worth updatingREADME.md:213to describe the precedence.ConfigureMiniohas the same shape withMINIO_REGION, but there the endpoint is explicit and region is largely vestigial, so it is not affected in practice.