The typical way to build and distribute Mapbox vector tiles has been by packing them into a sqlite database with individual rows for each Z/X/Y quad tree coordinate. This is what tools like tippecanoe typically produce.
The problem with this is it still requires a running server process colocated with that sqlite db in order to service requests for individual tiles, like what you'll receive from a client-side mapping library.
This project has a lot of different parts, but one of them is a spec for serving this type of data at low latency without a server by combining a custom packing format with S3 range-get requests to read individual tiles direct from blob storage. So that is certainly interesting for this kind of use-case.
OP author here; one thing I didn't touch on is the way that most map services license their basemap data explicitly disallows "caching" which would be inclusive of hosting basemaps yourself on your own storage. So for the cases where it makes engineering or product sense to have your maps on S3, it goes against the dominant map business model.
I’ve used the utility tippecanoe with success to generate vector tiles from geojson sources and am hosting them statically. It’s been overall pretty easy. The only gotcha I can remember is I needed to pass the no compression flag since mapbox gl can’t read compressed tiles (and the file host will gzip everything anyways).
What issues have you run into with gzipped tiles? I store a lot of gzipped individual tiles for use in Mapbox GL maps on S3 with no problem - the only necessary change was making sure that S3 was emitting `content-encoding` headers.
At least for simple GeoJSON you can use tippecanoe (https://github.com/mapbox/tippecanoe) with --output-to-directory to get individual .pbf tiles. Most rendering clients will have some scheme where you can provide a root url and then the tiles need to be stored in some defined structure beneath that (e.g. root/z/x/y.pbf)
The problem with this is it still requires a running server process colocated with that sqlite db in order to service requests for individual tiles, like what you'll receive from a client-side mapping library.
This project has a lot of different parts, but one of them is a spec for serving this type of data at low latency without a server by combining a custom packing format with S3 range-get requests to read individual tiles direct from blob storage. So that is certainly interesting for this kind of use-case.