Just sent out the latest issue of Unvalidated Ideas, here's one of the ideas that was in there:
Somehow, Azure Blob Storage doesn't have an official AWS S3 SDK compatible Object Storage API. Yes, you read that right.
If you try and find it you'll find guides that recommend using gaul/s3proxy, and devblogs.microsoft.com posts from 2016! Along with gaul/s3proxy, there are other vendors (Minio, Apache jclouds, Zenko) trying to bolt on S3 object compatibility to Azure Blob Storage.
At this point, the programming interface SDK for S3 is the way that people deal with object storage over the internet, and programs are written primarily with S3 in mind, depending on compatibility from other providers (Backblaze, Wasabi, etc). It's a massive oversight to have Blob Storage not support this API natively, it would become a sticking point for any migration or app deployment.
Azure is a somewhat unloved/under-appreciated cloud provider, and effectively marketing yourself as the S3 provider for Azure (that uses blob storage, whether it's yours or the customers') is probably a great way to offer some benefit. Make it easy to try, use and scale your solution and you'll grow right along with Azure itself (which is the fastest growing cloud provider as of late).
One of the largest risks to this idea is Microsoft offering S3-compatible object storage on top of Azure Blob Storage themselves, and there's not much you can do about that. Having a good plan on how you'd respond -- would you pivot to serving your solution on top of Microsoft's? what additional value could you offer? -- is probably all you can do.
I honestly don't know why Microsoft hasn't built something native to do this yet... Maybe people are fine with using Azure Blob Storage as-is? Or maybe Microsoft wants to keep this as a point of lock-in (difficulty migrating in == difficulty migrating out).
You're brave enough to subscribe to the newsletter
NOTE: Subscribing does not guarantee that anyone will build this idea and save you from interfacing with Azure Blob Storage.