ECS Fargate cross microservice communication options

user_11980720 0
Viewed 454

I have been looking into different ways of connecting multiple miscorservices within their own services/tasks using ECS Fargate.

Normally, if all microservices are defined in the same task definition, we can just use the local ip with corresponding ports but this means we cannot scale individual microservices. From what I can tell there are two 'main' ways of enabling this communication when we break these out into multiple services:

  1. Add a load balancer to each service and use the loadbalancers public ip as the single point of access from one service to another.

    Questions I have on this is:

    a. Do all the services that need to communicate need to sit in the same VPC and have the service's incoming rules set to the security group of the load balancer?

    b. Say we have now provisioned the entire set up and need to set one of the loadbalancer public DNS's in one microservices code base, whats the best way of attaining this, im guessing some sort of terraform script that 'assumes' the public DNS that will be added to it?

  2. Making use of AWS Service Discovery, meaning we can query service to service with a simple built up identifier.

    Question I have for this is:

    a. Can we still attach load balancers to the services and STILL use service discovery? Or does service discovery have an under the hood load balancer already configured?

Many thanks in advance for any help!

aws-fargate amazon-ecs amazon-web-services networking
1 Answers

1.a All services in the same VPC and their security groups (SGs)

I assume that you are talking about case where each service will have its own load balancer (LB). Since the LBs are public, they can be in any VPC, region or account.

SGs are generally setup so that incoming rules to services allow only connections from the SG of the LB.

1.b DNS

Each task can have environmental variables. This is a good way to pass the DNS values. If you are taking about terraform (TF), then TF would provision the LBs and then create the tasks and set the env variables with DNS values of the LBs. Thus, you would know the DNS of LBs as they would have been created before your services.

2.a Service discovery (SD)

SD is only for private communication between services. No internet is involved, so everything must be in same VPC or peered-VPCs. So its basically oposite of the first solution with LBs.

I think you should be able to also use public LB along with SD.

SD does not use a LB. Instead when you query a DNS of a service through SD you will get private IP addresses of the tasks in random order. So the random order approximates load balancing of connections between tasks in a service.

user_2488230
Related