edit: Gbps not GBps
If you want to saturate network bandwidth with S3 that's the one tool I know that can do it.
I either missed it or OP didn't specify how many instances they was using at once to run their benchmark, but the more instances they used, the worse it will be per node.
This did not seem to be accounted for.
EDIT: OP says below it was from one instance, so what I said doesn't apply to this writeup.
Google Cloud Storage does not limit read or write throughput with the exception of our "Nearline" product (and even Nearline's limiting can be suspended for additional cost, a feature called "On-Demand I/O").
(Note that I have done some testing from AWS Lambda, where we had 1k lambda jobs all pulling down files from S3 at once. That's a bit harder to benchmark...)
It sounds like that wouldn't have been a factor, except for the cap you seem to have discovered on Amazon that you called out.
My only suggestion then is you may want to make it explicit that you ran the benchmarks from a single instance.
They explicitly mention the RPS per account limit in that doc, which is related.
Is this a limit that is hit anywhere near the 150GB discussed in this article, or is it something that you hit only if you are Netflix? We have TB in S3 and have not observed any limit other than EC2 instance bandwidth.
I'm not sure why anyone would build a server with less than 96GB on it these days, so its not at all unreasonable. Now your service provider my jerk you around but you can run two racks of machines (48 machines) in a data center with specs like that for about $25K/month (including dual gigabit network pipes to your favorite IP transit provider) So it isn't even all that huge of an investment.
[1] Consider your typical 'memcached' type service where data is named as a function of IP and offset.
The colors used for S3 and Azure Storage in the graphs are very near indistiguishable to me, as I have moderate red-green colorblindness. It's easier to tell apart on the bar graphs, since the patches of color are much larger, although I still have to work at it, and use the hints of the labels, but on the line graphs, it's basically impossible to tell apart. A darker shade of green would solve the problem for me personally, but I'm not all that bad a case, nor an expert on the best shades to pick for general color-blindness accessibility.
Just something to think about when presenting data like this.
The bigger point in the article is that these exact "take processing to the data" architectures operate exceedingly well on S3, GCS, Azure.
And, as a biased observer, these architectures operate on GCS the best due to great performance measured in the article, quick VM standup times, low VM prices, and per-minute billing.
EMR-on-S3 is the "copy the data to the processing nodes" variety.
Spinning up a cluster of VMs and use 10 seconds and they charge you min. 1 hour seems expensive to me.
These tests were done over a year ago so bandwidth limitations on EC2 may have changed since.
This testing was with https://github.com/rlmcpherson/s3gof3r
It's a private connection to AWS services including S3. You'd use the same URL as it's a routing basically. No idea if VPC endpoints would be better than IG though. P.S. Just tested and I get about half of the latency on VPC endpoint.
EFS supports NFSv4 so it should avoid being as routinely limited by server round-trip latency as NFSv3 tends to be but it'd be nice to see how well that works in practice.
