There is no object store and no managed filesystem here, and neither is coming. An S3-compatible endpoint or a shared filesystem is something you run on a VM, on volumes.
One VM, its root disk for the OS and the service, one or more volumes for the data (which disk holds what).
POST /v1/vms {"name":"store1","ram_mb":4096,"disk_gb":40, ...}
POST /v1/volumes {"name":"bulk1","size_gb":2000}
POST /v1/volumes/{id}/actions {"type":"attach","vm_id":"vm_..."}
POST /v1/vms/{id}/actions {"type":"start"}
Then mount the volume by UUID and point the service at it: Volumes.
Serves the S3 API over one directory, which is your mounted volume. Any SDK that talks to S3 talks to it once you set the endpoint.
A volume attaches to one VM at a time — these are block devices, not a shared filesystem. So "several machines, same files" means one machine exporting and the others mounting, with the export scoped to your own addresses in the server's firewall.
Every VM has a public address and there is no private network between them, so either scope the export tightly or put the mesh in first: Build a private mesh.
Egress is metered at your VM's own interface, so serving another of your VMs costs the same as serving the Internet. Inbound is free. Reading a dataset repeatedly across the network costs more than putting it on the machine that reads it.
Volumes bill from creation to deletion, attached or not, and growing is one-way.
A snapshot is stored alongside the disk it covers, so it covers your own
deletes and nothing else. For anything you cannot lose, push copies off the
platform — restic or borg on a schedule to a target you hold elsewhere —
and test a restore.