Nutzung von AWS Cloudfront für Domänen, die auf einem anderen Port als 443 lauschen

Question

Wir haben eins www.domain.com, das in einen AWS Load Balancer aufgelöst wird, der von einer AWS EC2 Nginx-Instanz unterstützt wird.

www.domain.com:8888Proxys zu einer AWS-Backend-Webanwendung.

www.domain.com:443stellt statisches HTML von der Festplatte von EC2 bereit, mit Ausnahme von:

• /app/Pfad, der zu einer dynamischen Backend-Anwendung führt, die auf einem EC2 läuft
• 404-Antworten, die auch für benutzerdefinierte Fehlerseiten auf dasselbe dynamische Backend EC2 weiterleiten.

Ziel: Wir möchten unser statisches HTML direkt aus dem S3-Speicher unter der Domäne bereitstellen können www.domain.com(derzeit synchronisieren wir die statischen S3-Dateien mit der Festplatte des Nginx-Servers).

Erwogene Optionen:

• Cloudfront mit einer Failover-Ursprungsgruppe kümmert sich gut um den Verkehr auf Port 443. Aber wenn wir eine Verbindung www.domain.commit Cloudfront herstellen, hört offensichtlich nichts zu www.domain.com:8888.

• Wenn wir einen Load Balancer haben, der die Listener bereitstellt, www.domain.comkönnen wir mit dynamischem Datenverkehr auf den Ports 443 und 8888 umgehen. Es ist jedoch nicht offensichtlich, wie wir S3 als Zielgruppe für den Load Balancer nutzen können. Ich glaube, dies könnte mit einem VPC-Endpunkt für S3 möglich sein. Aber könnte dies mit 404-Failovern umgehen? (Ref: https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/ )

• Wir starten ein Projekt zur Umleitung www.domain.com:8888des Datenverkehrs nach alt.domain.com:443und verwenden dann Option 1. Solange wir jedoch die Links zu beibehalten möchten, www.domain.com:8888ist es uns meiner Ansicht nach untersagt, Cloudfront als Ziel von zu verwenden www.domain.com.

• Besitzen Sie einen Frontend-Nginx-Proxy, der 8888-Datenverkehr an einen Load Balancer und 443-Datenverkehr an Cloudfront weiterleitet. Dies würde viele der Vorteile von Cloudfront zunichte machen, da der Client-Datenverkehr über einen Proxy geleitet werden müsste, um dorthin zu gelangen. Außerdem müssten wir die SSL-Terminierung über Lets Encrypt außerhalb von Amazon ACM abwickeln.

Option 3 scheint die sauberste Lösung zu sein, wäre aber weder schnell noch einfach umzusetzen, daher suchen wir nach Alternativen.

Gibt es andere Optionen, die wir in Betracht ziehen sollten?