feat: CDK_S3_FORCE_PATH_STYLE forces S3 path-style addressing

[peter-smith-phd]

The AWS SDK addresses S3 buckets using virtual-hosted-style URLs by default (https://<bucket>.s3.amazonaws.com). When targeting custom or local S3-compatible endpoints (for example LocalStack or MinIO), path-style addressing (https://<endpoint>/<bucket>) is often required instead.

Setting the CDK_S3_FORCE_PATH_STYLE environment variable now enables path-style addressing on the S3 clients used for asset publishing (cdk-assets-lib) and by the toolkit (toolkit-lib). When the variable is unset, behavior is unchanged and the SDK default applies.

This follows the existing convention of CDK-specific environment variables such as CDK_DOCKER and CDK_HOME.

Checklist

• Unit tests added/updated
• Integration tests added/updated (if deploying new resource types or cross-service interactions)

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[rix0rrr]

Is there a way to autoderive the correct behavior here? Zero-conf is better than an option fleet...

[peter-smith-phd]

Is there a way to autoderive the correct behavior here? Zero-conf is better than an option fleet...

Great question. This option is solely necessary when the user sets a custom AWS_ENDPOINT_URL_S3 . If the URL they provide doesn't support subdomains properly (which is a problem for 127.0.0.1 or localhost), then S3 path-style addressing is required.

So, we could automatically set forcePathStyle if there's a change to AWS_ENDPOINT_URL_S3 (or AWS_ENDPOINT_URL that implicitly sets AWS_ENDPOINT_URL_S3). This is fine if the new URL refers to a non-AWS location (like an emulator), but could be problematic if the new URL points so something like a FIPS endpoint (prefers virtual host for performance reasons).

The most accurate solution would be to detect 127.0.0.1 and localhost explicitly, and automatically set the flag only in those cases. Would that be more acceptable?