Best Setup with AWS ALB and Tomcat

Our company currently operates a monolithic application that comprises multiple instances of Tomcat running on two servers. These instances are load balanced using Apache, where each instance listens on a different port and is then redirected to its respective endpoint (e.g., /payments, /orders, etc.).

We are in the process of migrating our infrastructure to AWS and considering replacing Apache with an Application Load Balancer (ALB). We would like to seek your opinion on whether this is a viable approach.

Additionally, we are considering creating individual EC2 instances for each Tomcat endpoint. For instance, having two servers with multiple instances dedicated to /payments, two servers for /orders, and so on. What are your thoughts on this approach?

Moreover, we are curious to know if ALB supports redirecting multiple ports to a single target. For instance, we would like to redirect ports 8090, 8091, 8092, and 8093 to the /payments endpoint.

Thanks!

Using an ALB / Application Load Balancer sounds appropriate for this use case. It's correct for most http(s) load balancing use cases in AWS, though some edge cases it can't do.

The ALB has a fairly flexible architecture in terms of listeners for incoming connections/port and target groups. You should be able to do what you need. However, once you get into AWS and understand how things are set up I'm not sure you'll need to do that, but it depends how your solution is architected.

Having one server per Tomcat instance sounds sensible to me. Put one in each availability zone for redundancy. Be aware that if you enable cross zone load balancing (default ON if created in the console) the load balancer in AZ-A can send traffic to the container in AZ-B which incurs inter-AZ traffic fees. AWS says it tries to keep traffic within the availability zone where possible. Keep an eye on your bill, turn the feature off if needed. You should be considering autoscaling and health checks.

Instead of instances you should consider containers, which you can run on EC2 instances you manage or Fargate containers. Fargate containers cost a little more but AWS manages them, so it saves you some effort. AWS Elastic Container Service (ECS) is more than sufficient for most use cases, you don't need EKS / K8S and all the complexity it brings for most use cases.

You could also simply migrate your servers into AWS. That usually works, but in many cases is a first step to rearchitecting a solution to work in a more cloud native manner.

If you don't understand some of the terms in my answer you're welcome to ask questions, but I also suggest getting some training. AWS is a complex enterprise environment and it's easy to get things wrong, run up a large bill, or miss something that creates security issues. Training for the AWS Architect Associate certificate would be suitable. There are plenty of training providers around, I like Adrian Cantrill training especially for beginners, but there's also Cloud Guru and many others.