This is the big question, I'm not even sure most of CF staff can answer, it's been asked before sev
This is the big question, I'm not even sure most of CF staff can answer, it's been asked before several times in last few months and no one from CF has chimed in, my understanding/guess is that writing to R2 would be egress because you are going through the frontdoor (no worker level bindings).. my guess is that only invoking worker to the container traffic is not counted because that can work with internet egress turned off. One way to determine this would be disable internet egress https://developers.cloudflare.com/containers/faq/#how-do-i-allow-or-disallow-egress-from-my-container and see if you can still talk to R2.
The other option is instead of just proxying plain old http calls through the worker to the container you have a bi-directional communication websocket that allow you to push to R2 via the invoking worker and derive your http response at the worker. It was mentioned earlier they are looking at a container to worker fetch setup.
But it's not even clear if the invoking worker to container traffic is consider egress.
And then since if you're talking to the frontend endpoints of Cloudflare (for R2, rest api for kv, rest api for D1) presume you never going to leave the local zone since the anycast IPs will ingest at that point anyway, so is the egress charged based on the placement of the container then... rather than the underlying target (say R2 is hosted in a different continent for example)
It's possible they are still flushing out the billing, has anyone actually been charged egress yet? @kian
In fairness fly.io is also pretty useless in explaining their egress charging, made worse by two separate billing patterns depending on which generation your account is.
The other option is instead of just proxying plain old http calls through the worker to the container you have a bi-directional communication websocket that allow you to push to R2 via the invoking worker and derive your http response at the worker. It was mentioned earlier they are looking at a container to worker fetch setup.
But it's not even clear if the invoking worker to container traffic is consider egress.
And then since if you're talking to the frontend endpoints of Cloudflare (for R2, rest api for kv, rest api for D1) presume you never going to leave the local zone since the anycast IPs will ingest at that point anyway, so is the egress charged based on the placement of the container then... rather than the underlying target (say R2 is hosted in a different continent for example)
It's possible they are still flushing out the billing, has anyone actually been charged egress yet? @kian
In fairness fly.io is also pretty useless in explaining their egress charging, made worse by two separate billing patterns depending on which generation your account is.
