Bewährte Praktiken für S3-Webhosting und eine Erklärung, warum

Es gibt eine Menge sehr guter Ressourcen, die erklären, wie man eine S3-Website einrichtet. Aber es wird nicht erklärt, warum Sie eine Option der anderen vorziehen sollten.

In diesem Artikel werde ich nicht Schritt für Schritt erklären, wie Sie eine S3-Website einrichten. Wenn Sie danach suchen, habe ich am Ende dieses Artikels einige Links hinzugefügt. Stattdessen werde ich Ihnen die besten Praktiken nennen und diese mit einer Erklärung unterstützen.

Ich beginne meinen Artikel mit den besten Praktiken und erläutere diese weiter unten im Artikel.

Bewährte Verfahren für das Hosting von S3-Websites

Die besten Praktiken für das Hosting Ihrer S3-Website mit SSL in Kürze:

Verwenden Sie einen öffentlichen Bucket anstelle eines privaten Buckets

Verwenden Sie einen öffentlichen Bucket und erlauben Sie nur Anfragen mit einem geheimen Referer-Header, um den direkten Zugriff auf Ihren S3-Bucket zu verhindern.

Verwenden Sie CloudFront anstelle von Route 53

Durch die Verwendung von CloudFront erhalten Sie SSL, Caching und eine höhere Geschwindigkeit Ihrer Website. Stellen Sie sicher, dass Sie auch eine zweite CloudFront-Distribution für alle umgeleiteten S3-Buckets einrichten

Verwenden Sie den Website-Hosting-Endpunkt anstelle des S3 REST api Endpunkts

Stellen Sie in CloudFront sicher, dass Sie Ihre Herkunftsdomäne so einrichten, dass sie zum S3-Endpunkt für das Website-Hosting geleitet wird. Verwenden Sie nicht den S3 REST api-Endpunkt, da Sie die Optimierungen für das Webhosting verlieren.

• Beispiel für den Endpunkt der S3-Website: example.com.s3-website.eu-west-1.amazonaws.com
• Beispiel für den REST-API-Endpunkt: example.com.s3.eu-west-1.amazonaws.com

Erläuterung der besten Praktiken

Im Folgenden finden Sie Erklärungen, warum ich die oben genannten bewährten Praktiken für die besten Praktiken halte :)

Privater Eimer vs. Öffentlicher Eimer

Ich wollte einen privaten Website-Bucket haben, auf den nur CloudFront zugreifen kann. Das ist mit einer Zugriffsidentität (OAI) möglich , lesen Sie hier mehr, hat aber einen Nachteil, dazu später mehr.

Ich habe darüber nachgedacht, ob der Bucket privat sein sollte. Ich bin zu dem Schluss gekommen, dass ein öffentlicher Bucket völlig in Ordnung ist, da Ihre statischen Website-Dateien bereits über CloudFront zugänglich sind. Und Sie sollten keine sensiblen Dateien in diesem Bucket haben. Sie werden also nicht viel gewinnen, wenn Sie den Bucket privat machen.

Ich wollte jedoch direkte Anfragen an meinen S3-Bucket verhindern und fand daher eine Lösung, die ich weiter unten beschreiben werde.

Durch Hinzufügen einer S3-Bucket-Richtlinie, die s3:GetObject Anfragen nur zulässt, wenn ein geheimer Referer-Header gesetzt ist. Dieser Header wird auch der CloudFront-Verteilung als benutzerdefinierter Header hinzugefügt. Auf diese Weise fügt CloudFront den Anfragen immer den Referer-Header hinzu und kann die Objekte aus dem Bucket abrufen.

Beispiel für die S3-Bucket-Richtlinie:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::example.com/*",
                "arn:aws:s3:::example.com"
            ],
            "Condition": {
                "StringLike": {
                    "aws:Referer": "ZJAibno2C7NjHqBmqh9Q"
                }
            }
        }
    ]
}

Nachteile der Verwendung von OAI mit CloudFront für Ihren Website-Bucket

Zunächst möchte ich darauf hinweisen, dass die Verwendung eines privaten Buckets mit CloudFront durch die Einrichtung von OAI vorzuziehen ist, wenn Sie die S3-Funktion zum Hosten von Websites nicht nutzen. In einigen Fällen, in denen eine Single Page Application gehostet wird, ist es möglich, einen privaten Bucket zu verwenden, was bedeutet, dass einige SPAs die unten beschriebenen Nachteile nicht erfahren. (Lesen Sie hier mehr über SPA's und S3-Hosting: Hosten einer einseitigen Anwendung oder Website auf S3 )

Der folgende Nachteil gilt nur für private Website-Buckets, bei denen Sie von CloudFront aus auf die S3 REST API zugreifen.

Der Amazon S3 Website-Endpunkt ist für den Zugriff über einen Webbrowser optimiert. Es handelt sich um einen öffentlichen Endpunkt, d.h. wenn Ihr Bucket privat ist, kann CloudFront nicht mehr über den Website-Endpunkt auf die Objekte zugreifen. Dies ist ein Beispiel für den S3 Website-Endpunkt: example.com.s3-website.eu-west-1.amazonaws.com.

Das bedeutet, dass Sie über den REST-API-Endpunkt auf Ihre S3-Website zugreifen müssen. Beispiel für den REST-API-Endpunkt: example.com.s3.eu-west-1.amazonaws.com Um über CloudFront auf den privaten Bucket zuzugreifen, müssen Sie eine Origin Access Identity (OAI) einrichten. Und Sie verlieren die S3 Website-Hosting-Funktionalität, d.h. Ihre Objekte werden ohne die Webhosting-Optimierungen bereitgestellt.

Dies führt dazu, dass Sie die Erweiterung .html zu Ihren URLs hinzufügen müssen. Das liegt daran, dass Sie direkt auf die Objekte zugreifen. Und die S3-Hosting-Funktion für Websites entfernt das .html nicht, wenn Sie auf das Objekt zugreifen. URLs mit der Erweiterung .html sehen IMO nicht sehr schön aus.

Ich höre Sie jetzt denken: "Aber Sie können das Problem lösen, indem Sie das Standard-Root-Objekt in Ihrer CloudFront-Distribution festlegen". Aber das funktioniert nur für das Root-Objekt. Lesen Sie hier mehr darüber: Wie Header mit Standard-Root-Objekten funktionieren. Wenn Sie ein Unterverzeichnis anfordern, müssen Sie die .html erneut hinzufügen, was wiederum nicht sehr schön aussieht.

Eine andere Möglichkeit wäre, die Erweiterung .html aus den Objekten im Bucket zu entfernen und etwas mit dem MIME-Typ zu machen. Aber das klingt für mich nicht nach einer sehr eleganten Lösung.

Route 53 vs. CloudFront für S3 Website-Hosting

Sie können Ihren S3-Website-Bucket so einrichten, dass ein direkter Zugriff über einen DNS-Eintrag in Route 53 möglich ist. Oder Sie können dem S3-Bucket eine CloudFront-Verteilung vorschalten. Im Folgenden erkläre ich Ihnen, warum Sie meiner Meinung nach CloudFront verwenden sollten.

Ich denke, dass CloudFront die beste Lösung ist, weil CloudFront folgende Vorteile bietet.

• Auslieferung Ihrer Website mit SSL (HTTPS)
• Die Anfrage wird zwischengespeichert
• Steigern Sie die Leistung Ihrer Website
• Die Möglichkeit, allgemeine Sicherheitskopfzeilen festzulegen

Wenn Sie Route 53 ohne CloudFront verwenden, steht Ihnen weder SSL noch Caching zur Verfügung. Ein weiterer potenzieller Nachteil ist, dass Ihr Bucket und Ihr Domainname identisch sein müssen. Lesen Sie hier mehr darüber, warum Ihr Domain- und Bucketname identisch sein müssen

Nützliche Links

• Tutorial: Konfigurieren einer statischen Website auf Amazon S3
• Wie verwende ich CloudFront für die Bereitstellung einer statischen Website, die auf Amazon S3 gehostet wird?
• Wie man CloudFront einrichtet: Beschleunigen Sie Ihre Website mit Amazon CloudFront

Bonus: Terraform-Vorlage

Ich habe eine Terraform-Vorlage erstellt, die diese Best Practices verwendet und die Sie hier finden können: GitHub - tiborhercz/s3-website-cloudfront-terraform