How IP Security Groups and Tailscale play together

Hi - we’ve got an AWS account with our own custom VPN setup and we’re looking at switching to Tailscale.

The main thing I’m trying to understand is how we should think about our use of Security Groups in this new world - the docs seem to suggest that you would just have one EC2 relay, which would imply that within my account all resources should be opened up to this single EC2 machine.

Is there a reasonable way to have multiple ec2 relays so that different parts of our infrastructure can still have segregated security groups for different groups of users, or is that going against best practices for tailscale?

The best way to deploy Tailscale is to install it on each EC2 VM. That does a couple things:

  • the encryption is end-to-end
  • Tailscale ACLs can control access based on Username, or ACLTag, or other factors not just IP address

If you want to have different access for some EC2 nodes, I’d recommend using Tags and controlling access based on the tag:

Tailscale is an overlay network. There is an entirely separate inner IP+TCP header which are encrypted inside the Wireguard tunnel, which is then carried in an outer IP+UDP header over the Internet. The AWS Security Groups only see the outer IP header. Enforcing access controls inside the tunnels is done with ACLs.

I’m thinking more about what happens inside my VPC when traffic emerges from the inner network - we have non-ec2 infra e.g a redshift cluster and various ALBs - currently they have security groups that allow traffic from different groups of people. With a single EC2 jump-box running tailscale I would end up with all traffic coming out of that box needing access to all resources in my account.

Basically do we lose the ability to segregate traffic coming out of the tailscale jump box inside our vpc via security groups? Or can I say that some people jump through box A, and others through box B so that security group rules can then take over as they talk to non-ec2 machines?

I suppose one way of doing this would be for these boxes to only advertise the specific IPs of the resources we want them to act as jump-points towards and then the outer tailscale routing will send people to the right one, but the endpoints of AWS infra have changing IPs so I’m not sure how to achieve that in a sensible way.

Or do you mention tags because I can have two machines advertise the same routes, and based on the tags on those machines we can route different users through the right jump box?

(complete tailscale beginner here, apologies If I’m grabbing the wrong end of the stick in a very obvious way)

If you’re thinking of how to make it work with your current system of restrictions and controls, that’s a conversation that can be had. There are ways to do what you’re talking about there. But, the benefits to a mesh VPN though is that you can run tailscale on each of your nodes, ignore the underlying topology altogether, and control all of your access through tailscale ACLs.

A tailscale node appears to be on the same network as the other nodes on your tailnet. You don’t need jumpboxes, or bastions, or concentrators.

You can tag your machines based on what they do, and then write your access rules based on what the people do. Then whatever device, and wherever in the world that person is connecting from, they have access to the resources they need.

Instead of thinking about tailscale like a VPN, I like to think about it as connecting everything together like you would a LAN, but your “switch”, through ACLs, has very powerful and fine-grained access control capabilities.

This is a good summary of the logic behind tailscale.

And whichever way you want to go, you can email us at and we’ll help you get it set up. But to start with, I’d recommend playing with it, it’s surprisingly straightforward compared to legacy VPNs.