[Pfhreak]

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.

[snagglegaggle]

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.

[fauigerzigerk]

>But I generally don't find this too hard to follow?

This is just the static picture though. What's harder to predict are the consequences of some innocuous looking code change.

[Pfhreak]

Sure, but surely teams have monitoring on their usage, right? With automated rollbacks or at least one click manual rollbacks?

[fauigerzigerk]

Sure, but rolling back work that was already done is a waste of development resources.

[Pfhreak]

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.

[fauigerzigerk]

We're obviously talking past each other.

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.