The connectivity to EC is working fine from the VPC with new URL (https://XXX.vpce.ap-southeast-2.aws.elastic-cloud.com:9243).
However, as the client is using CloudID there seems to be a problem. I suspect it default to the publicly accessible URL (https://XXX.ap-southeast-2.aws.found.io:9243).
Is there any way to get Private Link working with a Node client using Cloud ID?
Here's a sample of the client setup:
OR you can also add back / allow Public IPs in the traffic filter 0.0.0.0/0 which is perhaps a bit counter to setting up the PrivateLink in the first place.
We used to have URL in client's config the way you described but switched to Cloud ID as it has some benefits. I was wondering if cloud.id could somehow be aware of PrivateLink for the deployment and resolve to a private IP dynamically.
The cloud.id decodes to the public URL / Endpoint that is created when you create the deployment. I don't think it's possible for it to know ahead of time the new DNS VPC endpoint URL that's created by you the user when you create private link afterwards.
Refining / thinking a little bit further....You should be able to add IP traffic filters on the Elastic Cloud deployment to include the source ranges for your clients. Then you should be able to use the cloud.id from the clients.
That traffic would still go to the original public IP address the sources could be filtered.
Yep. Totally makes sense if we still need public access to Elastic Cloud.
That however defeat the purpose for using PrivateLink as you mentioned before.
Thanks again for the super prompt reply. Happy to join Elastic community
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.