@Rauan Mayemir and others, we were discussing a couple of weeks ago, the importance of looking deeply into vendor specs in the cloud to understand bottlenecks that are not necessarily in the app, here is another cool example. Does your application write/read a lot from disk? Is this disk an EBS volume (AWS speak for elastic blob storage - a SAN really, network attached storage)? So, by choosing specific instance types - called EBS Optimized instance types - you can increase your I/O throughput - because on these machines, the EBS is connected by a dedicated network card to a dedicated network, and throughput is not shared with regular network operations (HTTP requests, RPC etc...) - this for i/o intensive apps can be a significant boost (in other instance types the throughput is shared though) 👀 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html

At least on GCP, there was a weird thing that if your OS drive was HD, your SSD attached block storage would get throttled. A case where you have to read the specs with lawyer precision (like that kid in Suits) in order to determine bottlenecks.

AWS does limit it - provisioned IOPS. However for example using Aurora there is no declaration of limit, and with the right instance type you get super serving capacity without giving up on writes to disk (each write is sent to several disks in parallel (commit is done with disk quorum...