Virtuelles Hosting bei Buckets

Das virtuelle Hosting ist das beste Verfahren, um mehrere Websites mit einem Webserver zu unterstützen. Eine Möglichkeit, Websites in Ihren Amazon S3 REST API S3-Anfragen zu unterscheiden, besteht darin, den offensichtlichen Hostnamen der Anfrage zu verwenden — URI statt nur den Pfadnamen, der URI Teil von ist. Eine normale Amazon S3 REST S3-Anfrage spezifiziert einen Bucket unter Verwendung der ersten durch Schrägstrich getrennten Komponente des Request-Pfads. URI Stattdessen können Sie das virtuelle Amazon S3 S3-Hosting verwenden, um einen Bucket in einem REST API Aufruf mithilfe des HTTP Host Headers zu adressieren. In der Praxis interpretiert Amazon S3 Host so, dass die meisten Buckets automatisch (für begrenzte Anfragetypen) unter https://bucket-name.s3.region-code.amazonaws.com zur Verfügung stehen. Eine vollständige Liste der Amazon-S3-Regionen und -Endpunkte finden Sie unter Amazon-S3-Endpunkte und -Kontingente in der Allgemeine Amazon Web Services-Referenz.

Virtuelles Hosting hat auch andere Vorteile. Indem Sie Ihren Bucket nach Ihrem registrierten Domainnamen benennen und diesen Namen zu einem DNS Alias für Amazon S3 machen, können Sie Ihre Amazon S3 S3-Ressourcen vollständig anpassen, http://my.bucket-name.com/ z. B. URL Sie können auch im „Stammverzeichnis“ des virtuellen Servers Ihres Buckets veröffentlichen. Diese Fähigkeit kann wichtig sein, da viele vorhandene Anwendungen nach Dateien an diesem Standardspeicherort suchen. Beispielsweise wird erwartet, dass favicon.ico, robots.txt und crossdomain.xml im Stamm gefunden werden können.

Wichtig

Wenn Sie Buckets im Virtual-Hosting-Stil mit verwenden, stimmt das SSL Platzhalterzertifikat nur mit Buckets übereinSSL, die keine Punkte () enthalten. . Um diese Einschränkung zu umgehen, verwenden oder schreiben Sie Ihre eigene Logik zur Zertifikatsverifizierung. HTTP Weitere Informationen finden Sie unter Amazon S3 Path Deprecation Plan im AWS News Blog.

Anforderungen im Pfadformat

Derzeit unterstützt Amazon S3 sowohl virtuell gehosteten Zugriff als auch Pfadzugriff. URL AWS-Regionen Path-Style URLs wird jedoch in future eingestellt. Weitere Informationen finden Sie im folgenden wichtigen Hinweis.

In Amazon S3 URLs verwendet path-style das folgende Format:

https://s3.region-code.amazonaws.com/bucket-name/key-name

Wenn Sie beispielsweise einen Bucket mit dem Namen amzn-s3-demo-bucket1 USA West (Oregon) erstellen und auf das puppy.jpg Objekt in diesem Bucket zugreifen möchten, können Sie den folgenden Pfadstil verwenden: URL

https://s3.us-west-2.amazonaws.com/amzn-s3-demo-bucket1/puppy.jpg

Wichtig

Update (23. September 2020) — Um sicherzustellen, dass Kunden die Zeit haben, die sie für die Umstellung auf virtuell gehostete Systeme benötigen, haben wir beschlossenURLs, die Einstellung von Path-Style zu verzögern. URLs Weitere Informationen finden Sie unter Amazon S3 Path Deprecation Plan – The Rest of the Story im AWS News Blog.

Warnung

Vermeiden Sie beim Hosten von Website-Inhalten, auf die über einen Webbrowser zugegriffen wird, die Verwendung des Pfadformats, da dies das Sicherheitsmodell des Browsers „Selbe Origin“ beeinträchtigen URLs könnte. Zum Hosten von Website-Inhalten empfehlen wir, entweder S3-Website-Endpunkte oder eine Distribution zu verwenden. CloudFront Weitere Informationen finden Sie unter Website-Endpunkte und Bereitstellen einer React-basierten Einzelseitenanwendung für Amazon S3 und CloudFront in den AWS Perspective Guidance Patterns.

Anforderungen im virtuellen Hosting-Format

Bei einem virtuell gehosteten System ist der Bucket-Name URI Teil des Domainnamens in der. URL

Verwenden Sie im virtuellen Hosted-Stil von Amazon S3 das folgende Format: URLs

https://bucket-name.s3.region-code.amazonaws.com/key-name

In diesem Beispiel ist amzn-s3-demo-bucket1 der Bucket-Name, "US West (Oregon) (USA West (Oregon))" die Region und puppy.png der Schlüsselname:

https://amzn-s3-demo-bucket1.s3.us-west-2.amazonaws.com/puppy.png

HTTPHostHeader-Bucket-Spezifikation

Solange Ihre GET Anfrage den SSL Endpunkt nicht verwendet, können Sie den Bucket für die Anfrage mithilfe des HTTP Host Headers angeben. Der Host Header in einer REST Anfrage wird wie folgt interpretiert:

• Wenn der Host Header weggelassen wird oder sein Wert ists3.region-code.amazonaws.com, ist der Bucket für die Anfrage die erste durch Schrägstriche getrennte Komponente der Anfrage- URI und der Schlüssel für die Anfrage ist der Rest der Anfrage-. URI Dies ist die übliche Methode wie im ersten und zweiten Beispiel in diesem Abschnitt dargestellt. Das Weglassen des Host Headers ist nur für 1.0-Anfragen gültig. HTTP

• Wenn andernfalls der Wert des Host-Headers mit .s3.region-code.amazonaws.com endet, ist der Bucket-Name die führende Komponente im Wert des Host-Headers bis zu .s3.region-code.amazonaws.com. Der Schlüssel für die Anfrage ist Request-. URI Diese Interpretation stellt Buckets als Unterdomänen von .s3.region-code.amazonaws.com bereit (vgl. das dritte und vierte Beispiel in diesem Abschnitt).

• Andernfalls ist der Bucket für die Anfrage der Kleinbuchstabenwert des Host Headers, und der Schlüssel für die Anfrage ist der Request-URI. Diese Interpretation ist nützlich, wenn Sie denselben DNS Namen wie Ihren Bucket-Namen registriert und diesen Namen als kanonischen Namen (CNAME) -Alias für Amazon S3 konfiguriert haben. Das Verfahren zur Registrierung von Domainnamen und zur Konfiguration von CNAME DNS Datensätzen würde den Rahmen dieses Handbuchs sprengen. Das Ergebnis wird jedoch anhand des letzten Beispiels in diesem Abschnitt veranschaulicht.

Beispiele

Dieser Abschnitt enthält Beispiele URLs und Anfragen.

Beispiel — Pfadstil URLs und Anfragen

In diesem Beispiel wird Folgendes verwendet:

• Bucket-Name – example.com

• Region: USA Ost (Nord-Virginia)

• Schlüsselname – homepage.html

Das URL ist wie folgt:

http://s3.us-east-1.amazonaws.com/example.com/homepage.html

die Anforderung lautet wie folgt:

GET /example.com/homepage.html HTTP/1.1
Host: s3.us-east-1.amazonaws.com

Die Anfrage mit HTTP 1.0 und dem Weglassen des Host Headers lautet wie folgt:

GET /example.com/homepage.html HTTP/1.0

Informationen zu DNS -kompatiblen Namen finden Sie unter Einschränkungen. Weitere Informationen zu Schlüsseln finden Sie unter Schlüssel.

Beispiel — URLs Virtual-Hosted — Stil und Anfragen

In diesem Beispiel wird Folgendes verwendet:

• Bucket-Name – amzn-s3-demo-bucket1

• Region ‐ Europa (Irland)

• Schlüsselname – homepage.html

Das ist wie folgt: URL

http://amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com/homepage.html

die Anforderung lautet wie folgt:

GET /homepage.html HTTP/1.1
Host: amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com

Beispiel — CNAME Alias-Methode

Um diese Methode zu verwenden, müssen Sie Ihren DNS Namen als CNAME Alias für konfigurierenbucket-name.s3.us-east-1.amazonaws.com. Weitere Informationen finden Sie unter Amazon S3 URLs mit CNAME Datensätzen anpassen.

In diesem Beispiel wird Folgendes verwendet:

• Bucket-Name – example.com

• Schlüsselname – homepage.html

Das URL ist wie folgt:

http://www.example.com/homepage.html

Das Beispiel ist wie folgt:

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

Amazon S3 URLs mit CNAME Datensätzen anpassen

Abhängig von den Anforderungen können Sie die Anzeige von s3.region-code.amazonaws.com auf der Website oder im Service gegebenenfalls unterbinden. Wenn Sie beispielsweise Websiteabbilder auf Amazon S3 hosten, bevorzugen Sie möglicherweise http://images.example.com/ anstelle von http://images.example.com.s3.us-east-1.amazonaws.com/. Jeder Bucket mit einem DNS -kompatiblen Namen kann wie folgt referenziert werden: zum http://BucketName.s3.Region.amazonaws.com/[Filename] Beispiel. http://images.example.com.s3.us-east-1.amazonaws.com/mydog.jpg Durch die Verwendung CNAME können Sie einem Amazon S3 S3-Hostnamen zuordnen, sodass der vorherige zu werden URL http://images.example.com/mydog.jpg könnte. images.example.com

Ihr Bucket-Name muss mit dem CNAME identisch sein. Wenn Sie beispielsweise eine Zuordnung CNAME images.example.com zu erstellenimages.example.com.s3.us-east-1.amazonaws.com, http://images.example.com.s3.us-east-1.amazonaws.com/filename werden beide http://images.example.com/filename und identisch sein.

Der CNAME DNS Datensatz sollte Ihren Domainnamen mit dem entsprechenden Hostnamen im virtuellen Hosting-Stil verknüpfen. Wenn sich Ihr Bucket-Name und Ihr Domainname beispielsweise in der Region USA Ost (Nord-Virginia) befinden images.example.com und Ihr Bucket sich in der Region USA Ost (Nord-Virginia) befindet, sollte der CNAME Datensatz als Alias lauten. images.example.com.s3.us-east-1.amazonaws.com

images.example.com CNAME 			images.example.com.s3.us-east-1.amazonaws.com.

Amazon S3 verwendet den Host-Namen, um den Bucket-Namen zu ermitteln. Der Bucket-Name CNAME und der Bucket-Name müssen also identisch sein. Nehmen wir zum Beispiel an, dass Sie www.example.com als CNAME für konfiguriert habenwww.example.com.s3.us-east-1.amazonaws.com. Wenn Sie auf http://www.example.com zugreifen, empfängt Amazon S3 eine Anforderung, die in etwa wie folgt aussieht:

GET / HTTP/1.1
Host: www.example.com
Date: date
Authorization: signatureValue

Amazon S3 sieht nur den ursprünglichen Hostnamen www.example.com und weiß nichts von der CNAME Zuordnung, die zur Lösung der Anfrage verwendet wurde.

Sie können jeden Amazon S3 S3-Endpunkt in einem CNAME Alias verwenden. s3.ap-southeast-1.amazonaws.comKann beispielsweise in CNAME Aliasen verwendet werden. Weitere Informationen zu Endpunkten finden Sie unter Anforderungsendpunkte. Informationen zum Erstellen einer statischen Website mit einer benutzerdefinierten Domäne finden Sie unter Tutorial: Konfigurieren einer statischen Website mithilfe einer benutzerdefinierten bei Route 53 registrierten Domäne.

Wichtig

Wenn Sie custom URLs with verwendenCNAMEs, müssen Sie sicherstellen, dass für jeden CNAME von Ihnen konfigurierten Alias-Datensatz ein passender Bucket vorhanden ist. Wenn Sie beispielsweise DNS Einträge für Webinhalte erstellen www.example.com und diese mit S3 veröffentlichen login.example.com möchten, müssen Sie sowohl Buckets www.example.com als auch erstellen. login.example.com

Wenn ein Aliaseintrag CNAME oder ein Alias konfiguriert ist, der auf einen S3-Endpunkt ohne passenden Bucket verweist, kann jeder AWS Benutzer diesen Bucket erstellen und Inhalte unter dem konfigurierten Alias veröffentlichen, auch wenn die Eigentümerschaft nicht identisch ist.

Aus demselben Grund empfehlen wir, dass Sie beim Löschen eines Buckets den entsprechenden Alias CNAME oder Alias ändern oder entfernen.

Verknüpfen eines Host-Namens mit einem Amazon-S3-Bucket

So verknüpfen Sie mithilfe eines Alias einen Hostnamen mit einem Amazon S3-Bucket CNAME

1. Wählen Sie einen Host-Namen aus, der zu einer von Ihnen kontrollierten Domäne gehört.

   Dieses Beispiel verwendet die Unterdomäne images der Domäne example.com.

2. Erstellen Sie einen Bucket, der dem Host-Namen entspricht.

   In diesem Beispiel lauten der Host- und der Bucket-Name images.example.com. Der Bucket-Name muss exakt mit dem Host-Namen übereinstimmen.

3. Erstellen Sie einen CNAME DNS Datensatz, der den Hostnamen als Alias für den Amazon S3 S3-Bucket definiert.

   Beispielsweise:

   images.example.com CNAME images.example.com.s3.us-west-2.amazonaws.com

   Wichtig

   Aus Gründen der Weiterleitung von Anfragen muss der CNAME DNS Datensatz genau so definiert werden, wie im vorherigen Beispiel gezeigt. Andernfalls kann sich trotz richtig erscheinender Funktion unvorhersehbares Verhalten ergeben.

   Das Verfahren zur Konfiguration von CNAME DNS Datensätzen hängt von Ihrem DNS Server oder DNS Anbieter ab. Spezifische Informationen finden Sie in Ihrer Serverdokumentation oder erhalten Sie von Ihrem Anbieter.

Einschränkungen

SOAPSupport Over HTTP ist veraltet, aber SOAP immer noch verfügbar. HTTPS Neue Amazon S3 S3-Funktionen werden nicht unterstütztSOAP. Anstatt zu verwendenSOAP, empfehlen wir, entweder den REST API oder den zu verwenden AWS SDKs.

Abwärtskompatibilität

In den folgenden Abschnitten werden verschiedene Aspekte der Amazon S3 S3-Abwärtskompatibilität behandelt, die sich auf Anfragen im Pfadstil und auf virtuell gehostete Anfragen beziehen. URL

Legacy-Endpunkte

Einige Regionen unterstützen Legacy-Endpunkte. Möglicherweise finden Sie diese Endpunkte in Ihren Serverzugriffsprotokollen oder -protokollen. AWS CloudTrail Weitere Informationen finden Sie im folgenden Abschnitt. Eine vollständige Liste der Amazon-S3-Regionen und -Endpunkte finden Sie unter Endpunkte und Kontingente von Amazon S3 in der Allgemeine Amazon Web Services-Referenz.

Wichtig

Obwohl Sie möglicherweise Legacy-Endpunkte in Ihren Protokollen sehen, empfehlen wir Ihnen, immer die Standardendpunktsyntax für den Zugriff auf Ihre Buckets zu verwenden.

Verwenden Sie im virtuellen Hosted-Stil von Amazon S3 das folgende Format: URLs

https://bucket-name.s3.region-code.amazonaws.com/key-name

In Amazon S3 URLs verwendet path-style das folgende Format:

https://s3.region-code.amazonaws.com/bucket-name/key-name

S3‐Region

Einige ältere Amazon-S3-Regionen unterstützen Endpunkte, die einen Bindestrich (-) zwischen s3 und der Region (z. B. s3‐us-west-2) anstelle eines Punkts (z. B. s3.us-west-2) enthalten. Wenn sich Ihr Bucket in einer dieser Regionen befindet, wird in Ihren Serverzugriffsprotokollen oder CloudTrail -protokollen möglicherweise das folgende Endpunktformat angezeigt:

https://bucket-name.s3-region-code.amazonaws.com

In diesem Beispiel lautet der Bucket-Name amzn-s3-demo-bucket1 und die Region ist US West (Oregon):

https://amzn-s3-demo-bucket1.s3-us-west-2.amazonaws.com

Globaler Legacy-Endpunkt

Für einige Regionen können Sie den globalen Legacy-Endpunkt verwenden, um Anforderungen zu erstellen, die keinen regionsspezifischen Endpunkt angeben. Der globale Legacy-Endpunkt lautet wie folgt:

bucket-name.s3.amazonaws.com

In Ihren Serverzugriffsprotokollen oder CloudTrail -protokollen sehen Sie möglicherweise Anfragen, die den alten globalen Endpunkt verwenden. In diesem Beispiel lautet der Bucket-Name amzn-s3-demo-bucket1 und der globale Legacy-Endpunkt ist folgender:

https://amzn-s3-demo-bucket1.s3.amazonaws.com

Anforderungen im virtuellen Hosting-Format für USA Ost (Nord-Virginia)

Anforderungen, die über den globalen Legacy-Endpunkt gesendet werden, werden standardmäßig an USA Ost (Nord-Virginia) weitergeleitet. Daher wird manchmal der ältere globale Endpunkt anstelle des regionalen Endpunkts für USA Ost (Nord-Virginia) verwendet. Wenn Sie einen Bucket in USA Ost (Nord-Virginia) erstellen und den globalen Endpunkt verwenden, leitet Amazon S3 Ihre Anfrage standardmäßig an diese Region weiter.

Anforderungen im virtuellem Hosting-Format für andere Regionen

Der globale Legacy-Endpunkt wird auch für Anforderungen im virtuellen Hosting-Format in anderen unterstützten Regionen verwendet. Wenn Sie einen Bucket in einer Region erstellen, die vor dem 20. März 2019 gestartet wurde, und den alten globalen Endpunkt verwenden, aktualisiert Amazon S3 den DNS Datensatz, um die Anfrage an den richtigen Standort umzuleiten, was einige Zeit dauern kann. In der Zwischenzeit wird die Standardregel angewendet und Ihre Anfrage im virtuellen Hosting-Format wird an die Region USA Ost (Nord-Virginia) weitergeleitet. Amazon S3 leitet es dann mit einer temporären HTTP 307-Weiterleitung in die richtige Region weiter.

Bei S3-Buckets in Regionen, die nach dem 20. März 2019 gestartet wurden, leitet der DNS Server Ihre Anfrage nicht direkt an den Ort weiter, an AWS-Region dem sich Ihr Bucket befindet. Stattdessen wird der Fehler HTTP 400 Bad Request zurückgegeben. Weitere Informationen finden Sie unter Senden von Anforderungen.

Anforderungen im Pfadformat

Für die Region USA Ost (Nord-Virginia) können Sie den globalen Legacy-Endpunkt für Anforderungen im Pfadformat verwenden.

Für alle anderen Regionen erfordert die Syntax im Pfadformat, dass beim Zugriff auf einen Bucket der regionsspezifische Endpunkt verwendet werden muss. Wenn Sie versuchen, auf einen Bucket mit dem alten globalen Endpunkt oder einem anderen Endpunkt als dem für die Region zuzugreifen, in der sich der Bucket befindet, erhalten Sie den HTTP Antwortcode 307 Temporärer Umleitungsfehler und eine Meldung, die angibt, dass URI für Ihre Ressource der richtige ist. Wenn Sie beispielsweise https://s3.amazonaws.com/bucket-name für einen Bucket verwenden, der in der Region USA West (Oregon) erstellt wurde, erhalten Sie den Fehler HTTP 307 Temporary Redirect.