0

I have a set of containerized microservices behind an ALB serving as endpoints for my API. The ALB ingress is internet-facing and I have set up my path routing accordingly. Suddenly the need appeared for some additional (new) containerized microservices to be private (aka not accessible through the internet) but still be reachable from, and able to communicate with, the ones that are public (internally).

Is there a way to configure path based routing , or modify the ingress with some annotation to keep certain paths private?

If not, would a second ingress (an internal one this time) under the same ALB do the trick for what I want?

Thanks, George

George S.
  • 63
  • 1
  • 6
  • You can use [ecs service discovery](https://aws.amazon.com/blogs/aws/amazon-ecs-service-discovery/). Its not clear what is "second ingress" in your question. Second security group ingress rules? – Marcin Nov 09 '20 at 13:00
  • Thank you for your answer. I am using EKS however and that's kind of prerequisite in the case I'm working on. By second Ingress I mean the specification file. I have a deployment which is the ALB controller and one Ingress specification that specifies the paths along with that the paths are 'internet-facing' . So if I make a second ingress specification and declare it as 'internal' with the corresponding paths there , would that work? – George S. Nov 09 '20 at 19:58

1 Answers1

1

Turns out that (at least for my case) the solution is to ignore the internet-facing Ingress and let it do its thing. Internal facing REST API paths that should not be otherwise accessible can be used through their pods' Service specification.

Implementing a Service per microservice will allow internal access in their : without the need to modify anything in the initial Ingress which will continue to handle internet-facing API(s).

George S.
  • 63
  • 1
  • 6