AWS ECS Private and Public Services

Question

I have a scenario where I have to deploy multiple micro-services on AWS ECS. I want to make services able to communicate with each other via APIs developed in each micro-service. I want to deploy the front-end on AWS ECS as well that can be accessed publicly and can also communicate with other micro-services deployed on AWS ECS. How can I achieve this? Can I use AWS ECS service discovery by having all services in a private subnet to enable communication between each of them? Can I use Elastic Load Balancer to make front-end micro-service accessible to end-users over the internet only via HTTP/HTTPS protocols while keeping it in a private subnet?

Answer 1

The combination of both AWS load balancer ( for public access) and Amazon ECS Service Discovery ( for internal communication) is the perfect choice for the web application.

Built-in service discovery in ECS is another feature that makes it easy to develop a dynamic container environment without needing to manage as many resources outside of your application. ECS and Route 53 combine to provide highly available, fully managed, and secure service discovery

Service discovery is a technique for getting traffic from one container to another using the containers direct IP address, instead of an intermediary like a load balancer. It is suitable for a variety of use cases:

• Private, internal service discovery
• Low latency communication between services
• Long lived bidirectional connections, such as gRPC.

Yes, you can use AWS ECS service discovery having all services in a private subnet to enable communication between them.

This makes it possible for an ECS service to automatically register itself with a predictable and friendly DNS name in Amazon Route 53. As your services scale up or down in response to load or container health, the Route 53 hosted zone is kept up to date, allowing other services to lookup where they need to make connections based on the state of each service.

Yes, you can use Load Balancer to make front-end micro-service accessible to end-users over the internet. You can look into this diagram that shows AWS LB and service discovery for a Web application in ECS.

You can see the backend container which is in private subnet, serve public request through ALB while rest of the container use AWS service discovery.

Amazon ECS Service Discovery

Let’s launch an application with service discovery! First, I’ll create two task definitions: “flask-backend” and “flask-worker”. Both are simple AWS Fargate tasks with a single container serving HTTP requests. I’ll have flask-backend ask worker.corp to do some work and I’ll return the response as well as the address Route 53 returned for worker. Something like the code below:

@app.route("/")
namespace = os.getenv("namespace")
worker_host = "worker" + namespace
def backend():
    r = requests.get("http://"+worker_host)
    worker = socket.gethostbyname(worker_host)
    return "Worker Message: {]\nFrom: {}".format(r.content, worker)

Note that in this private architecture there is no public subnet, just a private subnet. Containers inside the subnet can communicate to each other using their internal IP addresses. But they need some way to discover each other’s IP address.

AWS service discovery offers two approaches:

• DNS based (Route 53 create and maintains a custom DNS name which resolves to one or more IP addresses of other containers, for example, http://nginx.service.production Then other containers can send traffic to the destination by just opening a connection using this DNS name)
• API based (Containers can query an API to get the list of IP address targets available, and then open a connection directly to one of the other container.)

You can read more about AWS service discovery and use cases amazon-ecs-service-discovery and here