Seeking Guidance on Connecting AKS Service to Elasticsearch Across Subscriptions

Question

We are from M365 Communication Compliance (CC). We are working on setting up a new service hosted on AKS in our own subscription. This service needs to connect to Elasticsearch, which is hosted on a VM in another subscription and behind a VNet.

To connect our AKS service to the Elasticsearch instance, we are seeking the best and compliant approach. Could you please assist us with this?

Approaches:

1. VNet Peering:

   - Based on our research, VNet peering might not be a compliant approach for transferring data between VNets. We are verifying this with our security team but would appreciate your input on this.

2. Azure Private Link / Azure VPN Gateway:

   - According to the documentation, this seems to be a viable approach. However, we are unsure if it is compliant or recommended for our scenario. Could you please share your thoughts.

3. Moving Elasticsearch and Related Resources to Our Subscription:

   - We would like to understand the risks, potential downtime, and migration time associated with moving Elasticsearch and all related resources to our subscription where AKS will be hosted.

Answer 1

@Deepak Kumar ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you would like to establish connectivity between VNETs across two subscriptions.

1.VNet Peering

• May I ask why do you think VNET Peering might not be a compliant approach?
• VNET Peering offers you a low-latency, high-bandwidth connection
• Network traffic between peered virtual networks is private. Traffic between the virtual networks is kept on the Microsoft backbone network.
• The only challenge is that you cannot have overlapping address spaces between the two VNETs.

Note : Azure VPN Gateway and Azure Private Link are two separate solutions.

2.a.Azure VPN Gateway

• This requires you that both the VNETs deploy a VPN Gateway of their own
• Also, the latency and bandwidth are dependant upon the regions and the SKU of the Gateway
  • See : Gateway SKUs by throughput
• This also means, these VNETs cannot be peered to other Virtual Networks with "Use Remote Gateway" option enabled.
• PROS :
  • While Public IP is involved, traffic is routed through Microsoft backbone if Microsoft global network is enabled on both the IPs of the VPN Gateway
  • Encrypted traffic meeting certain compliance requirements

You can find more details : Comparison of virtual network peering and VPN Gateway

Finally, the comparison boils to :

• VNET Peering : Data replication, database failover, and other scenarios needing frequent backups of large data.
• VPN Gateway : Encryption-specific scenarios that are not latency sensitive and do not need high throughout

2.b.Private Link Service

• PLS can be leveraged only when the service is running behind Azure Standard Load Balancer
• 
• I am not aware of how the 3rd party service is deployed into Azure VNET, but if it uses a Standard Load Balancer, you can go with PLS.
• Here , the Traffic is sent privately using Microsoft backbone. It doesn’t traverse the internet.
  • See : How is traffic being sent when using Private Link?

3.Moving Elasticsearch and Related Resources to Our Subscription

• This looks like something related to the 3rd party altogether.
• Please reach out to the 3rd party's forums or support to get more information on this

Please let us know if we can be of any further assistance here.

Thanks,

Kapil

---

Please Accept an answer if correct.

Original posters help the community find answers faster by identifying the correct answer.