Hey folks! I've developed a Node.js backend using Docker and have it all set up for microservices. Locally, I've been using NGINX as a reverse proxy that handles requests based on dynamic subdomains (like `something.localhost`), fetching resources from S3 as needed. Now, I'm looking to take this setup to AWS for production. Here's what I have in mind:
1. The landing page for `dumcel.app` is already hosted elsewhere.
2. I want `something.dumcel.app` to point to my reverse proxy service.
3. The reverse proxy needs to dynamically handle subdomains and fetch resources from S3, similar to how it's working locally.
Could anyone shed light on these questions:
- Which AWS service is best suited for hosting this setup? Should I go with ECS (Fargate), EC2, EKS, or something else?
- How can I configure Route 53, ALB, and NGINX to support wildcard subdomains (`*.dumcel.app`) and route them correctly to my reverse proxy?
- Any recommendations for scaling and securing this architecture?
I appreciate any insights from those who have tackled similar challenges. Thanks!
6 Answers
Have you explored using Lambda@Edge? It can be a game changer for handling reverse proxy functions directly even before the request hits your main service!
Have you thought about using CloudFront? You can set it up with two origins: one for your ECS Fargate service and one for S3. This way, you might not even need a custom reverse proxy since CloudFront acts as a reverse proxy itself. It simplifies things a bit!
I’d recommend running your reverse proxy in ECS Fargate. It strikes a good balance between managed infrastructure and container flexibility without the complexities of EKS. For DNS, just create a wildcard record in Route 53 pointing to your ALB. Then the ALB can forward the traffic to your ECS service running NGINX, which should handle subdomains just like you’ve set up locally. A few best practices: 1) Terminate SSL at ALB with a wildcard ACM cert, 2) Use IAM roles for ECS tasks to pull from S3 securely, 3) Add autoscaling based on CPU/memory for your ECS service, and 4) Enable WAF on ALB for basic protection against attacks.
For your architecture, consider using CloudFront along with a wildcard SSL cert for `*.dumcel.app`. Just make sure you forward the `Host` header to ALB so that your reverse proxy sees the correct subdomain. CloudFront can also manage caching and DDoS protection, which is a huge plus. If the main task is mapping subdomains to S3 prefixes, you could even skip the proxy altogether using Lambda@Edge for rewriting requests!
I faced something similar recently. I split the services into different ports (3000 for the landing page and 3001 for the API) in the Docker setup and managed the routing in ECS with a target group for each port on ALB. For instance, `dumcel.app` goes to port 3000, and `something.dumcel.app` goes to port 3001. It's worked great for me!
Absolutely! Setting up CloudFront as a front for both the ALB and your S3 bucket is a solid solution. I found some blogs that might help:
1. [CloudFront setup with SSL and custom domain](https://www.stormit.cloud/blog/setup-an-amazon-cloudfront-distribution-with-ssl-custom-domain-and-s3/)
2. [CloudFront for EC2 ALB setup](https://www.stormit.cloud/blog/cloudfront-distribution-for-amazon-ec2-alb/)
Let me know if you’d like more details on any specific part!
That's interesting! Can you share more details about how to implement CloudFront for this setup?