Virtuelles Hosting bei 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

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Virtuelles Hosting bei 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 Hosting von Amazon S3 verwenden, um mit dem HTTP-Header Host einen Bucket in einem REST-API-Aufruf anzusprechen. 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

Bei Verwendung von virtuell gehosteten Buckets mit SSL stimmt das SSL-Platzhalterzertifikat nur mit Buckets überein, 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. 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 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) — Um sicherzustellen, dass Kunden die Zeit haben, die sie für die Umstellung auf virtuell gehostete Systeme benötigen, haben wir beschlossen URLs, 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

In einer URL im virtuellen Hosting-Stil ist der Bucket-Name Teil des Domänennamens 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

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

Dieser Abschnitt enthält Beispiele und Anfragen. URLs

Beispiel — Pfadstil URLs und Anfragen

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 — Virtuell URLs gehostet — Stil und Anfragen

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 Regionen und Endpunkten von Amazon S3 finden Sie unter Anforderungsendpunkte 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 custom URLs with verwenden CNAMEs, müssen Sie sicherstellen, dass für jeden von Ihnen konfigurierten CNAME- oder Alias-Datensatz ein passender 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-Datensatz konfiguriert ist, der auf einen S3-Endpunkt ohne einen passenden 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

Die SOAP-Unterstützung über HTTP ist veraltet, SOAP steht über HTTPS aber noch zur Verfügung. Neue Amazon-S3-Funktionen werden unter SOAP nicht unterstützt. Anstatt SOAP zu verwenden, empfehlen wir, 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. Möglicherweise sehen Sie diese Endpunkte in Ihren Serverzugriffsprotokollen oder AWS CloudTrail -protokollen. 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 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.

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 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, auf einen Bucket mit dem globalen Legacy-Endpunkt oder einem anderen Endpunkt zuzugreifen, der nicht der Region entspricht, in der sich der Bucket befindet, erhalten Sie als Antwortcode einen „HTTP 307 Temporary Redirect“-Fehler und eine Meldung, die den richtigen URI für Ihre Ressource angibt. Wenn Sie beispielsweise https://s3.amazonaws.com/bucket-name für einen Bucket verwenden, der in der Region USA West (Oregon) erstellt wurde, wird ein „HTTP 307 Temporary Redirect“-Fehler angezeigt.