1

I have an ECS Fargate service mapped to an Application Load Balancer on AWS. In this service, there are several task that are frequently killed and restart. These tasks should be able to connect to a MongoDB Atlas cluster.

Which IP should I whitelist for my Atlas cluster? Is it possible to have an elastic IP or a range of IPs for my service to allow only IP(s) of my service in my Mongo Atlas cluster?

Sorry if this question is trivial, I'm struggle a bit on ECS, ALB and networking on AWS.

Howins
  • 113
  • 3

1 Answers1

1

You can have your Fargate tasks in a Private Subnet in the VPC and set up a NAT gateway in the Public Subnet. Then on the way out to the MongoDB Atlas (which I understand is not hosted in your VPC) all the traffic from the Fargate containers will appear to come from one of the NAT GW addresses.

NAT GW provides a fixed IP address in each Availability Zone - so with 3 AZs you'll only get to whitelist these 3 IPs on the Atlas side.

Hope that helps :)

MLu
  • 23,798
  • 5
  • 54
  • 81
  • +1 what @MLu mentioned is the easiest / most obvious way to make it work. You also have an option to create a MongoDB endpoint in your own VPC (hence making all calls from the task to the database "local and private"). You can read more about this option [here](https://aws.amazon.com/blogs/apn/connecting-applications-securely-to-a-mongodb-atlas-data-plane-with-aws-privatelink/) – mreferre Nov 08 '21 at 10:11
  • Thanks both of you for your answer, I don't know why but I couldn't comment the post of @MLu, maybe because my account is new. I tried the NAT solution, it seems that my task was able to reach Internet because they properly pull the Docker image. But when I couldn't access them through my ALB. Currently, each task is a FastAPI server. The Fargate service is behind an ALB and I can reach my backend through ALB. But when I deploy my service in private subnet and my ALB in public subnet I wasn't able to reach my backend container trough my ALB. – Howins Nov 10 '21 at 13:13
  • @Howins looks like a routing or a security group issue. Hard to tell from what you describe. Check the routing tables in both public and private subnets and check that the ALB SG can connect to the ECS task SG. – MLu Nov 10 '21 at 22:27
  • Sorry for the long time without answer, it was indeed a routing issue with the NAT and the private subnets – Howins Nov 29 '21 at 09:26