Virtuelles Hosting von Allzweck-Buckets - Amazon Simple Storage Service
Anforderungen im PfadformatAnforderungen im virtuellen Hosting-FormatBucket-Spezifikation für HTTP-Host-HeaderBeispiele Anpassen von Amazon-S3-URLs mit CNAME-EinträgenVerknüpfen eines Host-Namens mit einem Amazon-S3-BucketEinschränkungenAbwärtskompatibilität

Virtuelles Hosting von Allzweck-Buckets

Das virtuelle Hosting ist das beste Verfahren, um mehrere Websites mit einem Webserver zu unterstützen. Eine Möglichkeit, die Websites in Ihren REST-API-Anforderungen von Amazon S3 zu unterscheiden, ist die Verwendung des Hostnamens in der Anforderungs-URI anstelle des Pfadnamens in der URI. Eine gewöhnliche Amazon-S3-REST-Anfrage gibt einen Bucket an, indem sie die erste durch Schrägstrich abgetrennte Komponente des Pfads der Anfrage-URI verwendet. Stattdessen können Sie das virtuelle Amazon S3-Hosting verwenden, um einen Allzweck-Bucket in einem REST-API-Aufruf anzusprechen, indem Sie den HTTP-Header Host verwenden. 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. Wenn Sie Ihrem Bucket denselben Namen wie Ihrer registrierten Domäne geben und diesen Namen dann zu einem DNS-Alias für Amazon S3 machen, können Sie die URL Ihrer Amazon-S3-Ressourcen vollständig anpassen, z. B, http://my.bucket-name.com/. 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 virtuell gehostete Allzweck-Buckets mit SSL verwenden, passt das SSL-Platzhalterzertifikat nur auf Buckets, die keine Punkte enthalten (.). Zur Umgehung dieser Einschränkung verwenden Sie HTTP oder schreiben Sie Ihre eigene Logik zur Verifizierung von Zertifikaten. Weitere Informationen finden Sie unter Amazon S3 Path Deprecation Plan im AWS News Blog.

Anforderungen im Pfadformat

Derzeit unterstützt Amazon S3 den URL-Zugriff in allen AWS-Regionen sowohl im virtuellem Hosting- als auch im Pfadformat. URLs im Pfadformat werden jedoch in naher Zukunft eingestellt. Weitere Informationen finden Sie im folgenden wichtigen Hinweis.

In Amazon S3 verwenden URLs, die auf Pfaden basieren, das folgende Format:

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

Wenn Sie beispielsweise einen Bucket namens amzn-s3-demo-bucket1 in der Region USA West (Oregon) erstellen und in dem Bucket auf das Objekt puppy.jpg zugreifen möchten, können Sie die folgende URL im Pfad-Stil verwenden:

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

Update (23. September 2020) – Wir haben das Veralten von URLs im Pfadformat verschoben, um sicherzustellen, dass Kunden genügend Zeit haben, um zu URLs im virtuellen Hosting-Format zu wechseln. 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 Web-Browser zugegriffen wird, die Verwendung von URLs im Pfadformat, da dies das Browser-Sicherheitsmodell desselben Ursprungs beeinträchtigen könnte. Für das Hosten von Website-Inhalten empfehlen wir, entweder S3-Website-Endpunkte oder eine CloudFront-Verteilung zu verwenden. Weitere Informationen finden Sie unter Website-Endpunkte und Bereitstellen einer React-basierten Single-Page-Anwendung für Amazon S3 und CloudFront in den AWS-Perspective-Guidance-Mustern.

Anforderungen im virtuellen Hosting-Format

In einer URL im virtuellen Hosting-Stil ist der Bucket-Name Teil des Domänennamens in der URL.

Amazon-S3-URLs, die auf virtuellem Hosting basieren, verwenden das folgende Format:

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

Bucket-Spezifikation für HTTP-Host-Header

So lange Ihre GET-Anforderung nicht den SSL-Endpunkt verwendet, können Sie mit dem HTTP-Host-Header den Bucket für die Anforderung festlegen. Der Host-Header in einer REST-Anforderung wird folgendermaßen interpretiert:

  • Wenn der Header Host ausgelassen wird oder der Wert s3.region-code.amazonaws.com lautet, ist der Bucket für die Anforderung die erste durch Schrägstrich abgetrennte Komponente des Anforderungs-URI und der Schlüssel für die Anforderung bildet den Rest des Anforderungs-URI. Dies ist die übliche Methode wie im ersten und zweiten Beispiel in diesem Abschnitt dargestellt. Das Weglassen des Host-Headers ist nur bei HTTP-1.0-Anforderungen möglich.

  • 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 Anforderung ist die Anforderungs-URI. Diese Interpretation stellt Buckets als Unterdomänen von .s3.region-code.amazonaws.com bereit (vgl. das dritte und vierte Beispiel in diesem Abschnitt).

  • Ansonsten ist der Bucket für die Anforderung der klein geschriebene Wert des Host-Headers und die Schlüssel für die Anforderung ist die Anforderungs-URI. Diese Interpretation ist nützlich, wenn Sie als DNS-Namen Ihren Bucket-Namen registriert und diesen als kanonischen Namen (CNAME-Alias) für Amazon S3 konfiguriert haben. Das Verfahren zum Registrieren von Domänennamen und Konfigurieren von CNAME-DNS-Einträgen ist nicht Gegenstand dieses Leitfadens. Das Ergebnis wird jedoch im letzten Beispiel in diesem Abschnitt dargestellt.

Beispiele

In diesem Abschnitt finden Sie Beispiel-URLs und -anforderungen.

Beispiel – URLs und Anforderungen im Pfadformat

In diesem Beispiel wird Folgendes verwendet:

  • Bucket-Name – ‐ example.com

  • Region: USA Ost (Nord-Virginia)

  • Schlüsselname – ‐ homepage.html

Die URL lautet 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 Anforderung mit HTTP 1.0 unter Auslassen des Host-Headers lautet wie folgt:

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

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

Beispiel – URLs und Anforderungen im virtuellen Hosting-Format

In diesem Beispiel wird Folgendes verwendet:

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

  • Region ‐ Europa (Irland)

  • Schlüsselname ‐ homepage.html

Die URL lautet wie folgt:

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-Aliasmethode

Um diese Methode zu verwenden, müssen Sie den DNS-Namen als CNAME-Alias für konfiguriere bucket-name.s3.us-east-1.amazonaws.com. Weitere Informationen finden Sie unter Anpassen von Amazon-S3-URLs mit CNAME-Einträgen.

In diesem Beispiel wird Folgendes verwendet:

  • Bucket-Name – ‐ example.com

  • Schlüsselname ‐ homepage.html

Die URL lautet wie folgt:

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

Das Beispiel ist wie folgt:

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

Anpassen von Amazon-S3-URLs mit CNAME-Einträgen

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/. Auf Buckets mit einem mit DNS kompatiblen Namen kann wie folgt verwiesen werden: http://BucketName.s3.Region.amazonaws.com/[Filename], z. B. http://images.example.com.s3.us-east-1.amazonaws.com/mydog.jpg. Durch die Verwendung von CNAME können Sie images.example.com einem Amazon-S3-Host-Namen zuordnen, sodass die vorherige URL als http://images.example.com/mydog.jpg angezeigt wird.

Der Bucket-Name muss dem CNAME entsprechen. Wenn Sie z. B. einen CNAME für die Zuordnung von images.example.com zu images.example.com.s3.us-east-1.amazonaws.com erstellen, sind http://images.example.com/filename und http://images.example.com.s3.us-east-1.amazonaws.com/filename identisch.

Der CNAME DNS-Datensatz sollte einen Alias Ihres Domänennamens für den entsprechenden Host-Namen im Stil des virtuellen Hostings erstellen. Wenn der Bucket-Name und der Domänenname z. B. images.example.com lauten und sich Ihr Bucket in der Region USA Ost (Nord-Virginia) befindet, sollte der CNAME-Datensatz einen Alias für images.example.com.s3.us-east-1.amazonaws.com erstellen. 

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. CNAME und Bucket-Name müssen also identisch sein. Nehmen wir beispielsweise an, dass Sie www.example.com als CNAME für www.example.com.s3.us-east-1.amazonaws.com konfiguriert haben. 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 Host-Namen www.example.com und kennt die zum Auflösen der Anforderung verwendete CNAME-Zuordnung nicht.

In einem CNAME-Alias können Sie jeden beliebigen Amazon-S3-Endpunkt verwenden. Beispielsweise kann s3.ap-southeast-1.amazonaws.com in CNAME-Aliasnamen verwendet werden. Weitere Informationen zu Endpunkten finden Sie unter Anfrageendpunkte in der Amazon S3 API-Referenz. 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 benutzerdefinierte URLs mit CNAME-Einträgen verwenden, müssen Sie sicherstellen, dass für jeden von Ihnen konfigurierten CNAME- oder Alias-Eintrag ein entsprechender Bucket vorhanden ist. Wenn Sie beispielsweise DNS-Einträge für www.example.com und login.example.com erstellen, um Webinhalte mit S3 zu veröffentlichen, müssen Sie die beiden Buckets www.example.com und login.example.com erstellen.

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

Aus diesem Grund empfehlen wir, den entsprechenden CNAME oder Alias zu ändern oder zu entfernen, wenn Sie einen Bucket löschen.

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

So verknüpfen Sie einen Host-Namen unter Verwendung eines CNAME-Alias mit einem Amazon-S3-Bucket

  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-Eintrag, der den Host-Namen als Alias für den Amazon-S3-Bucket definiert.

    Zum Beispiel:

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

    Wichtig

    Aus Gründen des Anforderungs-Routings muss der CNAME-Eintrag genau wie im vorherigen Beispiel dargestellt definiert werden. Andernfalls kann sich trotz richtig erscheinender Funktion unvorhersehbares Verhalten ergeben.

    Das Verfahren für die Konfiguration von CNAME-DNS-Einträgen ist abhängig von Ihrem DNS-Server oder DNS-Anbieter. Spezifische Informationen finden Sie in Ihrer Serverdokumentation oder erhalten Sie von Ihrem Anbieter.

Einschränkungen

SOAP APIs für Amazon S3 sind für Neukunden nicht verfügbar und nähern sich am 31. August 2025 dem Ende des Lebenszyklus (EOL). Wir empfehlen, entweder die REST-API oder die AWS-SDKs zu verwenden.

Abwärtskompatibilität

Die folgenden Abschnitte behandeln verschiedene Aspekte der Amazon-S3-Abwärtskompatibilität, die sich auf URL-Anforderungen im Pfad- oder virtuellen Hosting-Format beziehen.

Legacy-Endpunkte

Einige Regionen unterstützen Legacy-Endpunkte. Sie sehen diese Endpunkte möglicherweise in Ihren Server-Zugriffsprotokollen oder AWS CloudTrail-Protokollen. Weitere Informationen finden Sie im folgenden Abschnitt. 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.

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.

Amazon-S3-URLs, die auf virtuellem Hosting basieren, verwenden das folgende Format:

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

In Amazon S3 verwenden URLs, die auf Pfaden basieren, 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 möglicherweise das folgende Endpunktformat in Ihren Server-Zugriffsprotokollen oder CloudTrail-Protokollen angezeigt:

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

In diesem Beispiel lautet der Bucket-Name amzn-s3-demo-bucket1 und die Region USA 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 Server-Zugriffsprotokollen oder CloudTrail-Logs sehen Sie möglicherweise Anforderungen, die den globalen Legacy-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 gelauncht wurde, und den globalen Legacy-Endpunkt verwenden, aktualisiert Amazon S3 den DNS-Eintrag so, dass die Anforderung an den richtigen Speicherort umgeleitet wird. Dies kann eine Weile dauern. 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 sie dann mit einer temporären HTTP-307-Weiterleitung an die richtige Region um.

Für S3 Buckets in Regionen, die nach dem 20. März 2019 gelauncht wurden, leitet der DNS-Server die Anforderung nicht direkt an die AWS-Region weiter, in der sich der Bucket befindet. Stattdessen wird ein "HTTP 400 Bad Request"-Fehler zurückgegeben. Weitere Informationen finden Sie unter Senden von Anforderungen in der API-Referenz zu Amazon S3.

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, mit dem alten globalen Endpunkt oder einem anderen Endpunkt auf einen Bucket zuzugreifen, der sich von dem Endpunkt für die Region, in der sich der Bucket befindet, unterscheidet, erhalten Sie einen HTTP-Antwortcode 301 Permanent Redirect-Fehler und eine Meldung, die den richtigen URI für Ihre Ressource angibt. Wenn Sie zum Beispiel https://s3.amazonaws.com/bucket-name für einen Bucket verwenden, der in der Region USA West (Oregon) erstellt wurde, erhalten Sie einen HTTP 301 Permanent Redirect-Fehler.