Customers are also to blame, when comparing the costs of two services they tend to look at the cost of an instance hour, or lambda execution and often don't look at transfer costs.
Even if a cloud provider had competitive transfer costs they likely wouldn't attract any new customers and would have less margin left over to subsidize the main cost customers look at, $ per instance hour.
The less attention is paid to transfer costs the better for AWS/GCP/Azure. Why hasn't a spot-market for transfer been introduced? Same reason why I can't sell my unused home internet bandwidth to my neighbors, the money is in controlling the means of transportation/communication and the providers want to keep as tight a control on that as possible.
This seems a little deliberately obtuse -- for example, showing two arrows from an EC2 instance to an EC2 instance that exits the VPC. But I generally don't find this too hard to follow? Traffic within an AZ is generally free, but there are some cases where it's not and they generally make sense to me (leaving the VPC, pushing data from your CDN back upstream, etc.)
Then again, I worked for AWS for years, so maybe I'm just used to thinking this way so I'm not really surprised by it.
There was a time when you paid for available bandwidth. Then network operators realized they could oversell their capacity and not spend the money to upgrade their network.
You still see paying for bandwidth with residential connections, though some operators (like Comcast) are trying to do away with it.
Disagree. It's much more wasteful to have an outage. Roll back asap, fix the issue, roll forward, do post mortem, grow as an organization. Never repeat the same mistake.
What I'm saying is that for a hosting architecture to make it difficult to predict the cost of any code change is a downside compared to an architecture that makes such predictions easy and intuitive.
Of course you will try to mitigate any downsides and learn what you can from any mistakes. But unpredictability makes learning far more difficult than it should, which inevitably means a waste of development resources.
I don't think this is true. At $JOB the extent of our cloud cost management is me reading a breakdown by SKU and looking for obvious inefficiencies, and we are very aware of transit fees. I would imagine that anyone in the 5MM+ range has actual models that account for this stuff.
I think this has more to do with collusion than consumer behavior. On average consumers are very rational, even if their rationality is hard to explain.
The issue with per-bit pricing is that a fair agreement for network use would probably look like paying a fee that makes up for the amortization of the network equipment. Anything else is an artificially restricted market created in an attempt to extract more value out of consumers by having them bid against each other.
At some point, yes, we will run out of places to put the switches and routers and then the cost of connectivity will be closer to the cost of land use and will mimic rent, but we are a ways away from that.
Why do you think that bandwidth costs should only cover the hardware? What about the electricity, rent, payroll, sales, marketing, administrative staff, insurance, accountants, lawyers, etc.
Even if a cloud provider had competitive transfer costs they likely wouldn't attract any new customers and would have less margin left over to subsidize the main cost customers look at, $ per instance hour.
The less attention is paid to transfer costs the better for AWS/GCP/Azure. Why hasn't a spot-market for transfer been introduced? Same reason why I can't sell my unused home internet bandwidth to my neighbors, the money is in controlling the means of transportation/communication and the providers want to keep as tight a control on that as possible.