I’m experimenting with named tunnels, and have followed the guided tutorials on setting up a named tunnel, this has worked as expected.
For my next test I copied the config + UUID.json + cert.pem into a toy container image running a web application, this worked beautifully!
Then I got curious as to what would happen if I had 2 containers of the same image, so I spun up 2 identical containers and then started the same named tunnels in BOTH containers (manually one after the other).
It appears that the although both tunnels seemed to successfully “connect” (at least I didn’t see any errors being printed), only the tunnel that “connects” first gets any traffic.
I have did a few more tests and this is consistent, so for example I stopped the tunnels on both and then booted them in the reverse order the the other container would then get traffic.
I guess what I was expecting (perhaps incorrectly) is that the traffic should round robin since there are two clients using the same tunnel?
So I guess my main question is what is the best practice for this?
The reason I ask is that eventually these tunnels would be all setup in automated scripts when an AWS EC2 machines are provisioned, and it would be totally wonderful and cool if the same tunnel could be re-used, because that way say for example 10 EC2’s are booted up, then the traffic could automatically round robin between those 10, or say if a few were killed/crashed etc.
Having to have 1 tunnel per EC2 machine seems problematic in terms of automation and provisioning?
Hi there - Glad to hear named tunnels are working well for you!
When you run a Tunnel, our connector, cloudflared, will establish 4 long-lived connections to the Cloudflare network. By running the same named tunnel in two separate containers you effectively spawned a replica connector which can also proxy traffic to your private resources. The result of this action is establishing 4 new connections to Cloudflare (for a total of 8 available connections). The expected behavior is that traffic will be randomly routed across these available connections. If you’re looking “steer” traffic in any way we would recommend implementing Load Balancers to handle smart routing decisions.
Did you happen to test which connections your request would be routed over from the same machine? If so, I would expect your machine to follow the same connection more often than not.
For the cert, it may be helpful to note that the cert.pem is not required to run the tunnel, only to create it. You should be able to do everything you’re looking to accomplish by simply sharing the config + UUID.json amongst your origins.
Just to confirm that I’ve understood what you have said: in theory it should route randomly across those 8 connections.
second question, so are there limits to how many connections?
finally would you say it’s an anti-pattern and not best practise to spin up lots of replica connections?
would say that it would be better to have one tunnel into 1 EC2 and then that EC2 can act as a load balancer? would that be a better approach?
So if the tunnels are free, does that include the outbound data transfer?
or is the only costs related to the the number of DNS/sites being protected by cloudflare?
That’s correct. For each Tunnel, you can have up to 100 active connections. My recommendation would be to use as many replicas as necessary, but if you’re looking to round-robin, weight, or make other smart routing decisions to integrate a Cloudflare Load Balancer or something comparable. If you go with a load balancer, you could create two tunnels and create load balancing rules between each. You could then also have additional replicas of each tunnel for redundancy. Just a thought.
Tunnels are completely free and I’d also recommend the Cloudflare and Cloudflare for Teams free plan to create Zero Trust security policies to protect your resources if that is a requirement. The Teams plan is also free for up to 50 users
