2. To use the same deployment code everywhere. If you're multi-cloud, maintaining different storage backends is complex.
Also, you can deploy Minio backed by either your own storage (like AWS EBS) or as a layer in front of cloud storage (S3, GCS, etc). So even with the Minio interface on top, you are still using managed cloud storage.
But… you’re not. You’ve just taken a service that can scale to any request volume and slapped a slow proxy in front of it that you need to manage, patch, keep up, debug etc.
This completely defeats one of the major selling points of the service you’re proxying, whilst reducing everything down to the lowest common denominator that minio supports. How would an application running on GCP with minio generate a signed public URL to an object?
That and completely ignoring whatever IAM offerings your cloud has.
There are very few reasons to do this.