Connect to database via AWS VPC

Hi,

We would like to integrate DataStax’s private endpoints. For that, it is normally required to setup some configuration on AWS VPC product.

We wonder if this might have any overlaps with Qovery. May the changes get override on deployment or something? Should we do anything else described on the documentation linked because we are running our cluster on Qovery?

Thank you!

I think it might overlap with the configuration we set but I’m not sure. One of our engineers could confirm or maybe @a_carrano @Julien_Dan

However, we support VPC peering. Setup VPC peering on AWS with Qovery | Qovery

Is it an option provided by DataStax?

So, it looks like that VPC Peering is not supported — only private endpoints.

Someone from the team will tell you if it’s overlapping with Qovery configuration or not.

@rophilogene When should we expecting an answer from “someone from the team”?

The DataStax provided these two other resouces:

I don’t think neither of those could be helpful for you guys, but just mentioning since they did.

Thank you.

Hello @enzoferey,

It should be ok and might not overlap but I would prefer to test it.
Do you have a test / dev cluster on which you can apply those settings first so we can test?

What I would like to do is:

  1. You do your custom setup on the VPC
  2. I will lock your cluster on Qovery so we cannot update it while testing
  3. I will do a manual test update on your cluster with Qovery config to check if there is anything clashing between two configurations

If everything is ok, then I will unlock your cluster and your configuration should be ok, but keep in mind that since it’s not managed by Qovery, it can eventually be clashing in the future with Qovery configuration.

Let me know what you think,

Cheers

Hi @bchastanier, thank you for your answer.

Unfortunately, we don’t have a test/dev cluster. Right now, spinning up one is quite a bit of work for us, so I don’t think we will be able to go this path.

Additionally, if we do the setup now but later Qovery collides with the config, it will be very hard to trace any change towards it, so your proposed solution sounds not ideal to us.

Could you see any other option here?

Thanks!

Hey @enzoferey,

Yes there is another option, using your own custom VPC so you can manage it and do whatever you want on it, Qovery won’t ever touch anything on it.
This option is set on cluster creation, so it requires you to create a new cluster with this option and clone your envs on new cluster.

Again, we didn’t tried yet custom VPC endpoints, looking at the doc, I think it won’t collides, we will introduce shortly some checks on our end preventing from deleting any non-qovery managed resources on update, so you should be fine.

I can loop internally to see if there is a way to integrate VPC endpoints support eventually in the meantime.

Cheers,

1 Like

Hi @bchastanier,

We had some issues to get the setup on AWS working, but I can confirm now that everything is good and new deployments on the cluster are not deleting this custom config.

What we did concretely:

  1. Create a VPC endpoint on the qovery-eks-workers VPC managed by Qovery. It is present on all subnets and has all the necessary security groups related to Qovery.
  2. Create a private hosted zone on Route53 to redirect the traffic that goes to DataStax’s URIs within the VPC towards the VPC endpoint.

That’s all.

Let me know if there is any danger or something to take into account.

Thanks!

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.