Continuing the discussion from Is it possible to increase the timeout to 120 sec.
We do charge for bandwidth between VMs on the internal network, both between regions and in the same region.
1 Like
Thanks. Makes sense to charge for bandwidth between regions (since it is essentially VPC-peering, to borrow from AWS parlance). Within the same region however feels a bit too on the nose, especially since it is likely for UDP workloads, some form of steering would be needed by the apps themselves.
I don’t think we inspect the traffic closely enough to determine that at this point, but I’ll bring this up internally.
1 Like
We usually have two choices with this stuff, we can either push bandwidth prices down or do the engineering work necessary to do clever billing.
Since we pay for bandwidth by the GB, it makes sense for us to also charge for it. It also makes sense to decrease bandwidth prices whenever we can!
That’s understandable. I won’t revolt!
Having said that, the problem I find is, I am both forced to impl steering UDP traffic intra-region and made to pay egress fees for my troubles. At least solve one of those…? 
One thing that seems necessary is the ability to redirect user to specific instance (like Fly-Prefer-Region but instance specific) in order to be able to avoid cross-instance traffic when multiple users need to connect to single resource.
My use case is an Elixir-based real-time IO game in which updates go at 30 fps from specific node that runs given game instance. Now, with the pricing confirmed above, even if all users are connected to the same region but land in multiple instances, I’ll pay twice for their traffic (once for cross-node internal communication and then for client-server communication).
Is there anything like that possible?
2 Likes