Data transfer cost - How to make sure the traffic between two ecs task stay private?
Hello all!
I am currently running two ECS services: an API and a Web App. The API needs to be accessed by remote hosts as well as the Web App. In an effort to optimize my data transfer costs, I want to keep traffic between the Web App and API private, without having to traverse a NAT Gateway and thus incur additional charges.
I thought of two options to solve this problem, but I'm not sure the first option guarantees that traffic remains private.
Option1:
Option 2:
Is the internal ALB needed in my case and ss this a good practice to have a "double setup" for both private and public routing?
Thank's in advance,
- 최신
- 최다 투표
- 가장 많은 댓글
Hello.
If the communication is within a service, it is possible to use "service discovery" to communicate without going through the public Internet.
https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/networking-connecting-services.html
Also, a few thoughts on the two options you are proposing.
Option 1 requires a NAT Gateway.
The reason for this is that ALB is created using internet facing, so even if it is registered in the private host zone, the IP address will use the global IP.
Therefore, a NAT Gateway is required for communication.
NAT Gateway is not required for option 2.
The IP address used is a private IP, as it communicates to the internal ALB.
In other words, NAT Gateway is not necessary because the communication is within the VPC.
Hi, why don't you just go directly between ECS Service API and ECS Web App on the private subnet in which both reside ?
That's straightforward and very efficient cost-wise.
Best,
Didier
Hi, thank you for your response.
Both services consist of multiple tasks, replicated across various AZ to ensure high availability. As per my understanding, a load balancer is required to distribute the requests evenly among all these tasks.
Are there any other solutions I might not be aware of?
No, you're right a load balancer is best for traffic coming from the outside. But, I was suggesting a different architecture for the internal traffic: a tight coupling between a pair of containers (Service API,Service WebApp) : the WebApp container would declare itself healthy only when its pair is healthy (he'd use the health check of the corresponding + his own to announce healthy or not).
Hello, Thank you for your detailed response. I will have a look at service discovery.