Yes, you are correct that API Gateway can replace the load balancing and firewall functions of the ALB, and it does support mTLS. With API Gateway, you can enable mTLS to authenticate client certificates, and you can also configure it to pass the client certificate information to your backend EC2 instances. This would allow you to move the authentication to the API Gateway and implement mTLS.
Regarding sticky sessions, you are right that API Gateway does not support sticky sessions by default. One way to implement sticky sessions in this scenario is to have the backend EC2 instances generate a unique identifier when they receive the initial request from the client. This identifier can be included in the response to the client, and subsequent requests from the client can include this identifier as a header. The API Gateway can then use this identifier to route the request to the same EC2 instance that served the initial request.
There are a few drawbacks to using API Gateway. One is the cost, which can be higher than using an ALB, especially at high volume. Additionally, API Gateway may introduce additional latency and overhead compared to a direct connection to the backend EC2 instances. However, these drawbacks may be outweighed by the benefits of using mTLS for authentication and offloading the load balancing and firewall functions to a managed service.
Another approach to this problem is to use a self-managed load balancer that supports mTLS, such as NGINX or HAProxy. This would allow you to terminate TLS and perform mTLS authentication at the load balancer, and then forward the requests to the backend EC2 instances. This approach may provide better performance and lower cost than using API Gateway, but it would also require more management overhead.
Elevate Your Expertise with Microservices Certification!