High Outbound Traffic, Postgres?

Questions / Help
, ,
1

Hey all,

I have an app with low external traffic but high database usage and I’m seeing extremely high outbound bandwidth usage on a daily basis. I’ve analyzed a packet capture in Wireshark and 95% of my outbound traffic is flowing to my Postgres cluster; the traffic isn’t quite enough to account for all the usage I’m seeing on the billing dashboard, but it accounts for the vast majority and my load is fairly consistent so the discrepancy can’t really be coming from spikes or the like. The app and database are all hosted on the same region (EWR), but in my searching around I’ve come across a lot of conflicting information about what outbound traffic is and isn’t charged.

These days, is outbound traffic between an app hosted in a region and a Postgres cluster hosted in the same region charged? And if the answer is no, is there anything else I should be looking out for to account for this inexplicable bandwidth usage I’m seeing?

1 Like
2

Bumping this. Would love some clarity here, since the outbound bandwidth numbers I’m seeing make no sense when compared to Wireshark captures on my machines.

3

At the moment, the logic is pretty basic: if your app has a public IP assigned to it, we assume all traffic is public.

We have ambitions to distinguish billing for different traffic kinds, but I couldn’t say when we might start working on that.

4

I see, thanks for the clarification. In my case, I have an app with two machines - one serves a public web app, and the other runs internal jobs. The jobs are very db-heavy, and that’s where I’m seeing the high bandwidth usage. And since they’re in the same “app”, they both share the same one public IP.

I suppose right now the only way to get around this would be to deploy a separate app with the same codebase dedicated solely to the internal jobs, and remove any public IPs from that app to ensure traffic is marked internal.

5

Yup, we have something similar and store two different fly.toml files in the repo, so deploying one or the other is just a case of fly deploy -c TOML_FILE.

Tip if you opt for this route: it might behove you to avoid naming either of these fly.toml, otherwise you might accidentally fly deploy, forgetting the -c and deploy to the wrong app. In other words, name them specifically main.toml and jobs.toml (or whatever you may choose).

1 Like
6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.