How can a consul client register itself to a consul server in a different network?

I’m kinda consul newbie here so please bare with me.

I’m running consul on AWS in a private subnet. I have no problem having my clients register themselves to the consul server. So far so good basically.

Now I’m planning to run VMs outside of AWS due to compliance reasons. I’m just not quite sure what’s the best way for the non-AWS consul agents to talk to consul server in AWS private subnet.

Should I be using bastion host? or is there any other best practices that I can follow?

Thank you in advance!

Hi Sean,

Thanks for posting, and welcome to Discuss!

Some quick questions:

  • Are you using AWS Direct Connect, or VPN tunneling between your on-prem/external cloud instances?
  • Are you running a Consul cluster in your on-prem/external cloud?

Depending on your needs, you may want look at WAN Federation which connects two datacenters together. If you are using the service mesh capabilities and will have services that need to talk to each other - look at Mesh Gateways in addition to WAN Federation.

I hope this helps, and thanks for the question!
Jono

Hi Jono,

Thank you for following up on my post.

We actually don’t have any on-prem infrastructure. The challenge we face is that we plan to open our service in Vancouver region and as a Canadian startup, compliance dictates that we cannot serve our customers from AWS us-west-2 region.

So we started to look for local cloud vendors in Vancouver region and found few vendors that provides OpenStack based VMs that I think we can run our service on.

Then I thought maybe it’ll be nice if we can manage services in Vancouver VMs from our central datacenter. I think I’ll have to ask the local cloud vendor if they provide direct connect and if they don’t provide it then we will just have to manage two separate datacenters running its own set of Consul and Nomad.

So to answer your question, I don’t know until I hear back from the local cloud vendor if they provide AWS Direct Connect. And yes, we are planning to run a Consul cluster in our external cloud.

I think I can take away from your comment that we are gonna need a dedicated line for safety which makes sense because we were reluctant to have our data cross public internet and that was the motivation of me posting here.

Again, thank you again for the kind and detailed feedback.
Sean

Hi @seanlee10! Thanks for the feedback, this gives me a lot of context. I am very happy to help :slight_smile:

In short, a Direct Connect line is the simplest route, as it provides traffic over a dedicated back end connection. That said, DirectConnect is pretty expensive.

The other option is the Mesh Gateway configuration , where you run two clusters - one in each cloud - and set up Mesh gateways in both clouds. This gives you mTLS encrypted traffic between Data centers for the cost of traffic, rather than additional service.

Here’s a brief blurb:

Mesh gateways enable routing of Connect traffic between different Consul datacenters. Those datacenters can reside in different clouds or runtime environments where general interconnectivity between all services in all datacenters isn’t feasible. These gateways operate by sniffing the SNI header out of the Connect session and then route the connection to the appropriate destination based on the server name requested. The data within the mTLS session is not decrypted by the Gateway.

I hope this helps your decision making process!
Best,
Jono

1 Like