Three URL shapes for the same object

S3 has represented the same bucket-and-key concept in several different URL shapes over the service's lifetime, and all of them still appear in the wild simultaneously: the s3:// URI scheme used by AWS CLI/SDK tooling internally, virtual-hosted-style URLs where the bucket name is a subdomain (the modern default), and path-style URLs where the bucket name is the first path segment instead. AWS has been deprecating path-style access for newly created buckets for years, but a large amount of existing infrastructure, older SDKs, and third-party tools still generate or expect path-style URLs, so any tool that only recognizes the modern form will fail on a meaningful fraction of real S3 URLs it encounters.

Why the region often isn't in the URL at all

The legacy us-east-1 virtual-hosted and path-style forms omit the region segment entirely — a holdover from when S3 didn't expose per-region endpoints the way it does now. That means a URL by itself doesn't always carry enough information to determine the bucket's region; when this tool can't recognize a region segment in the URL, it labels the region as the us-east-1 legacy default or as not encoded in that URL form, rather than guessing, since guessing wrong would be worse than admitting the URL alone doesn't say.