If you never use anything that ties this stuff together (like IAM), then there is practically no point in using AWS at all, it's way too expensive to use as a 'dumb pipe'.
That said, I'm personally a fan of using things that would technically also work outside of AWS, but not shying away from the AWS-specific optimisations. I'm not going to use Kubernetes on AWS without EKS for example (plain EC2). Or Kubernetes on AWS without the Amazon's CNI, that's not a thing I'd enjoy in production either.
When managed Kafka was announced, that was another great example of "nice, now I don't have to mess with EC2 node contents anymore", but I still can if I want to, including outside of AWS.
The most AWS-native thing (or two things) that make most other offerings not work out all that great is the integrated IAM and Security Groups. Kludging those together with some crappy port to AD or NSX is just a waste of time and sanity.
> The most AWS-native thing (or two things) that make most other offerings not work out all that great is the integrated IAM and Security Groups
SGs are easily covered by kubernetes network policies. What do you need iam for if you’re not using any manager stuff? Sounds like circular argument to me (“you need managed bc you need iam bc you need managed…)
S3 isn't just "I have many files and it needs a lot of disk space". Like I wrote, if you just use base S3 API primitives then no, you're not really using anything AWS-specific, and making a comparison between something that does more than you need seems odd to me. Edge storage, cold storage, cheaper storage based on reductions of redundancy or access times, mirroring, versioning, multi-level IAM (integrated with the rest of your IAM) are all things that make the difference between "look at my virtual USB disk" (most MinIO configurations out there, the unsupported ones that is) and "durable and reliable multi-level object storage, configured for my needs".
Must cheap providers have crappy networks compared to AWS.