Wie richte ich AWS Cloudfront für eine dynamische Anzahl von Domänen für eine dynamische Site ein?

Question

DAS SETUP
Wir haben ein webs/wix/etc-ähnliches Website-Managementsystem, das wir mit CloudFront verwenden möchten. Es hat die folgenden Domänen und Subdomänen.
- ourdomain: unsere Hauptwebsite
- admin.ourdomain: die Administrationsoberfläche für jede Website, verfügbar über https
- images.ourdomain: ein S3-Bucket
- router.ourdomain: siehe unten
- [customersomething].ourdomain: die Subdomänen für unsere kostenlosen Benutzer
- [customersomething.com]: Domänen für unsere Premium-Kunden

Das System funktioniert so, dass die meisten Domänen per CNAME auf router.ourdomain geändert werden (weil das für unsere Kunden mit ihren unterschiedlichen Domänen-Registraren usw. der einfachste Weg war) und router.ourdomain mit einem A-Alias ​​auf unseren ELB verknüpft wird und dann das PHP auf unseren EC2s die Sites basierend auf den HTTP_HOST-Werten verarbeitet, während die Bilder von S3 kommen.

UNSER PLAN
Und jetzt wollen wir das Ganze hinter CloudFront stellen. Das meiste davon ist trivial. Es war einfach, S3 hinter CF zu stellen. Es war einfach, jede ourdomain/*.(js|css) über eine asset.ourdomain-Subdomain hinter CF zu stellen. Es ist schön, dass wir *.images.ourdomain verwenden können, um zwischen Subdomains im Handumdrehen zu sharden, was die Ladezeit auf der Clientseite verringert usw. usw. Wir könnten sogar alle *.ourdomain-Sachen, einschließlich der dynamischen PHP-freien Sites, hinter CF stellen, indem wir „*.ourdomain“ in die CF-Parameter einfügen.

DAS PROBLEM
Aber wir können nicht herausfinden, wie wir alle dynamisch erstellten PHP-Sites mit benutzerdefinierten Domänen hinter CF platzieren können. Zur Erinnerung: Diese sind per CNAME auf router.ourdomain umbenannt. Jede Domäne in die CF-Parameter zu setzen, ist keine Option, da wir Zehntausende Domänennamen verarbeiten müssen und dies ohne manuelle Konfiguration für jeden einzelnen tun müssen.

Wir dachten also, wir sollten router.ourdomain als alternativen Domänennamen in die CF-Konfiguration einfügen, router.ourdomain auf die CF in Route 53 verweisen und die CF auf unseren ELB als Ursprung verweisen. Das ist, wie wir herausfanden, eine nette Möglichkeit, jedes Mal diese Meldung zu erhalten: „FEHLER: Die Anforderung konnte nicht erfüllt werden. Ungültige Anforderung. Generiert von CloudFront (CloudFront)“. Tatsächlichnicht jederZeit, als diewww.ourdomain funktioniert wie vorgesehen (es wird per CNAME in router.ourdomain geändert), aber jede andere Subdomain führt zu dem oben genannten Fehler (*.ourdomain wird per CNAME in router.ourdomain geändert, aber das Gleiche gilt auch für die Subdomains, die einzeln per CNAME in router.ourdomain geändert werden, außer dem www und natürlich dem Router). Im Moment haben wir also nicht nur keine Ahnung, wie wir das Problem lösen sollen, wir verstehen auch nicht, warum es für das www funktioniert, wenn es für alle anderen nicht funktioniert oder umgekehrt.

Ich bin für alle Gedanken und Ideen dankbar, danke.

Answer 1

Zur Erinnerung: Diese sind CNAME-d zu router.ourdomain

Ja, das haben Sie erwähnt. Und das ist die Sache dazu:

Es spielt keine Rolle.

Ja, CloudFront bezeichnet alternative Hostnamen als CNAMEs. Ja, ein CNAME-DNS-Eintrag ist die typische Methode, mit der Sie den Datenverkehr einer bestimmten Site zu CloudFront umleiten. Aber nein, die Konfiguration eines Hostnamens als CNAME, der auf Ihre CloudFront-Verteilung verweist, ist für die Funktionsweise von Cloudfront oder HTTP im Allgemeinen nicht relevant.

Wenn ein Browser eine Verbindung zu einem Webserver herstellen möchte, sucht er die IP-Adresse im DNS. Wenn der Pfad einen CNAME enthält, wird diese Information verworfen. Den Browser interessiert nur: „Mit welcher IP-Adresse verbinde ich mich?“

Angenommen, www.example.org wäre ein CNAME für webfarm.example.com. Der Browser sucht nach www.example.org und erhält die IP-Adresse für webfarm.example.com.

Mit der vorliegenden Antwort stellt der Browser eine Verbindung zum Webserver her und sendet eine Anfrage.

GET / HTTP/1.1
Host: www.example.com

Der Host:Header in der vom Browser gesendeten HTTP-Anfrage enthält den Hostnamen, wie er in der Adressleiste angezeigt wird. Die CNAME-Informationen sind völlig nicht verfügbar und weder dem Browser noch dem Webserver bekannt.

Inwiefern wäre der CNAME also für die Anforderungsanalyse und das Layer-7-Routing relevant? Das kann nicht sein. Das CNAME-Ziel wird nur als Pfad verwendet, um die IP-Adresse zu finden, mit der eine Verbindung hergestellt werden soll.

Ihre Distribution ist nicht die einzige, die diese IP-Adressen bei Cloudfront verwendet. Es gibt Hunderte oder Tausende anderer. Es kommt auf den Host:Header an.

Die Liste der „CNAMEs“ (alternative Hostnamen) ist eine Reihe von Hostnamen, die CloudFront im eingehenden Host:Header abgleichen muss, um zu bestimmen, dass eine Anfrage als zugehörig betrachtet werden solldeinVerteilung. Es handelt sich um eine Liste von Host:Headern, die ein Browser senden kann. Solange der Host:Header nicht mit einem konfigurierten Wert in einer Verteilung abgeglichen wird, ist die mit dieser Anfrage verknüpfte Verteilung unbekannt und undefiniert.

Was macht Cloudfront, wenn es einen eingehenden Host:Header keiner Verteilung zuordnen kann?

HTTP/1.1 400 Bad Request

Das Verhalten, das Sie sehen, ist also erwartungsgemäß und korrekt. Platzhalter funktionieren in der CloudFront-Konfiguration, solange sie das einzige Element ganz links in der Konfigurationszeile für den alternativen Hostnamen bilden. Dies hat jedoch nichts mit dem DNS zu tun.

Sie kommen nicht umhin, andere, kundeneigene Domänennamen in CloudFront zu konfigurieren, wenn Sie möchten, dass diese Ihre Distribution nutzen.

Sie können sie jedoch statt manuell auch programmgesteuert über die API ändern:

http://docs.aws.amazon.com/AmazonCloudFront/latest/APIReference/PutConfig.html

Es besteht ein Limit von 100 solcher Aliase pro Verteilung, aber Sie können eine Erhöhung beantragen, indem Sie ein Formular an den AWS-Support senden. Tatsächlich wäre es jedoch genauso gut, diese auf mehrere Verteilungen aufzuteilen, da CloudFront das Objekt nicht unter einem bestimmten Pfad mit einem Host in den Anforderungs-Edern zwischenspeichert und es als zwischengespeicherte Antwort für einen anderen Host zurückgibt, selbst in derselben Verteilung, wenn Sie den Host-Header an den Ursprungsserver weiterleiten (was Sie tun müssen, wenn der Ursprungsserver den Unterschied erkennen soll). Dies ist nicht möglich, da sich ein wichtiger Parameter in der Anforderung von einer Anforderung zur anderen geändert hat.