We have a www.domain.com which resolves to a AWS Load Balancer backed by AWS EC2 Nginx instance.
www.domain.com:8888 proxies to a AWS backend web application.
www.domain.com:443 serves static html from EC2's disk excepting:
/app/ path which proxies to a dynamic backend application running on an EC2- 404 responses which also proxy to the same dynamic backend EC2 for custom error pages.
Objective: to be able to serve our static html directly from S3 storage under the domain www.domain.com (we currently sync the S3 static files down to the disk of the Nginx server).
Options considered:
Cloudfront with a failover origin group will take care of the port 443 traffic nicely. But if we associate www.domain.com with cloudfront, obviously nothing will listen on www.domain.com:8888.
If we have a Load Balancer providing the listeners for www.domain.com we can deal with dynamic traffic on ports 443 and 8888. But it's not obvious how to have S3 as a Load Balancer target group. I believe this could be possible with a VPC endpoint for S3. But could this deal with 404 failovers? (Ref: https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/ )
We embark on a project to move www.domain.com:8888 traffic to alt.domain.com:443 and then use option 1. However, as long as we want to preserve links to www.domain.com:8888 I think we are barred from having cloudfront as the destination of www.domain.com.
Have a frontend Nginx proxy which proxies 8888 traffic to a Load Balancer, and 443 traffic to cloudfront. This would negate many of the plus points of using Cloudfront by forcing client traffic through a proxy to get there. Plus we'd need to handle SSL termination via Lets Encrypt outside Amazon ACM.
Option 3 seems like the cleanest option, but would not happen quickly or easily.. so we are looking for alternatives.
Are there other options we should be considering?
