Cloud World Model
Simulate AWS, GCP & DigitalOcean without paying the bill
Start new thread

Cloud prices stayed flat. What happens when traffic triples?

by
•

We just published our September cloud pricing update, with a simulation to put the numbers in context.

The 33 list prices we track across AWS, GCP, Azure, OCI and DigitalOcean didn’t change. We made two small corrections to our records, but found no provider price changes.

Then we modeled a load balancer, two app servers and a MySQL database in Cloud World Model, increasing traffic from 100 to 300 requests per second.

With infrastructure held fixed, modeled costs rose

  • AWS: about 48%

  • GCP: about 54%

  • DigitalOcean: about 12%

All of the modeled increase came from egress.

These are simulation estimates, not measured bills or a ranking of providers. The database sizes differ across clouds, and real egress depends on response sizes, destinations and bandwidth allowances.

For me, this is a useful example of why we’re building Cloud World Model. Knowing the rates is one part of planning. Exploring what happens when usage changes is another.

The write-up includes the assumptions and exact configuration so you or your agent can rerun it through MCP or REST:

When you estimate cloud costs, how do you account for traffic growth? Do you model it before deploying, or adjust once you see the bill?

35 views

Add a comment

Replies

Best

we model it before deploying but traffic growth isn't the variable that bites us, call concurrency is. we run voice agents, so "300 requests per second" doesn't map cleanly onto our load, a single call holds a connection open for minutes, not milliseconds, so the thing that scales badly isn't request count, it's concurrent open connections times average call duration. egress-dominated cost makes sense for request/response traffic, but for anything streaming (audio, video, long-polling) the bandwidth is sustained per connection rather than per request, so the same 3x traffic number can mean wildly different cost depending on whether it's 3x more short requests or 3x more long-lived streams. does Cloud World Model's simulation have a way to model held-open connections, or is it built around the request/response shape?

 Thanks, Gal. I checked. CWM has some concurrency modeling, but it doesn’t yet fully model long-lived voice sessions and their sustained bandwidth. The blog example is request-based, so those results wouldn’t answer your workload question.

Would a simulation that lets you vary concurrent calls, call duration and bandwidth per call, then explore the modeled cost and capacity impact, be useful to you?

If so, would you be open to sharing a representative setup and trying it with us as we work through the model? I’d want to understand what decision it could help you make and what would make the results useful in practice. Thanks, for the honest response and feedback. This is helpful.

Honestly the “nothing threw, nothing alerted” part is what makes this scary. The bug basically passed its own performance review.

Does the model flag when those two app servers or the database can no longer handle the extra traffic?

I would separate the egress increase from the cost of keeping response times acceptable. Holding infrastructure fixed is useful but it can hide the next capacity step

 Good point, Aleksandr. Yes, CWM can model overload signals such as CPU, latency, errors and database connection pressure. But the blog post holds infrastructure fixed, with autoscaling disabled, and only presents the cost results.

You’re right that the egress increase should be separated from the additional infrastructure cost needed to keep response times acceptable. These results don’t show that next capacity step.

AWS performance uses our owned benchmark calibration; GCP and DigitalOcean use documentation-based estimates, so the capacity thresholds aren’t equally validated. We’re adding our own benchmarks over time and using the results to recalibrate the engine. Another AWS benchmark run is underway now.

Would you be interested in trying a comparison on a representative setup, looking at where it starts missing your response-time target and how scaling changes the modeled cost?

Could you publish that comparison for the same example stack first?

Showing the response-time target and where another app replica stops helping because the database becomes the bottleneck would make the scaling cost much easier to judge