Virtuelles Hosting bei Buckets - Amazon Simple Storage Service

Dieses Handbuch wird nicht mehr aktualisiert. Aktuelle Informationen und Anweisungen finden Sie im neuen Amazon S3 Benutzerhandbuch.

Virtuelles Hosting bei Buckets

Das virtuelle Hosting ist das beste Verfahren, um mehrere Websites mit einem Webserver zu unterstützen. Eine Möglichkeit, zwischen den Websites zu unterscheiden, ist die Verwendung des Hostnamens in der Anforderung 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. Alternativ 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://bucketname.s3.Region.amazonaws.com zur Verfügung stehen. Eine vollständige Liste der Amazon S3-Regionen und -Endpunkte finden Sie unter Amazon S3-Regionen und -Endpunkte in der Allgemeinen AWS-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.bucketname.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, 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. Um dies zu umgehen, verwenden Sie HTTP oder schreiben Sie Ihre eigene Logik zur Verifizierung von Zertifikaten. Weitere Informationen finden Sie unter Amazon S3-Pfad-Veraltungsplan.

Anforderungen im Pfadformat

Derzeit unterstützt Amazon S3 den Zugriff in virtuell gehosteten und im Pfad-Stil in allen Regionen, dies wird jedoch geändert (siehe den folgenden wichtigen Hinweis.

Amazon S3-URLs im Pfad-Stil haben das unten gezeigte Format.

https://s3.Region.amazonaws.com/bucket-name/key name

Wenn Sie beispielsweise einen Bucket namens mybucket 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/mybucket/puppy.jpg
Wichtig

Update (23. September 2020) – Wir haben das Veralten von URLs im Pfadformat verschoben, damit Kunden die nötige Zeit haben, um zu virtuellen URLs im Host-Format zu wechseln. Weitere Informationen finden Sie unter Amazon S3-Pfad-Veraltungsplan – Der Rest der Geschichte.

Virtuell gehostete Anforderungen

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

Amazon S3-URLs im virtuellen Hosting-Stil haben das unten gezeigte Format.

https://bucket-name.s3.Region.amazonaws.com/key name

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

https://my-bucket.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.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 Auslassen des Host-Headers ist nur bei HTTP 1.0-Anforderungen möglich.

  • Wenn andernfalls der Wert des Host-Headers mit .s3.Region.amazonaws.com endet, ist der Bucket-Name die führende Komponente im Wert des Host-Headers bis zu .s3.Region.amazonaws.com. Der Schlüssel für die Anforderung ist die Anforderungs-URI. Diese Interpretation stellt Buckets als Unterdomänen von .s3.Region.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 Namen so konfiguriert haben, dass er ein CNAME-Alias für Amazon S3 ist. Das Verfahren zum Registrieren von Domänennamen und Konfigurieren von DNS 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 Pfadformat

In diesem Beispiel wird Folgendes verwendet:

  • Bucket-Name ‐ awsexamplebucket1.net

  • Region: USA Ost (Nord-Virginia)

  • Schlüsselname - homepage.html

Die URL lautet wie folgt:

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

die Anforderung lautet wie folgt:

GET /awsexamplebucket1.net/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 /awsexamplebucket1.net/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 Virtueller Hosting-Stil

In diesem Beispiel wird Folgendes verwendet:

  • Bucket-Name ‐ awsexamplebucket1.eu

  • Region ‐ Europa (Irland)

  • Schlüsselname - homepage.html

Die URL lautet wie folgt:

http://awsexamplebucket1.eu.s3.eu-west-1.amazonaws.com/homepage.html

die Anforderung lautet wie folgt:

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

Beispiel CNAME-Methode

Um diese Methode zu verwenden, müssen Sie den DNS-Namen als CNAME-Alias für bucketname.s3.us-east-1.amazonaws.com konfigurieren. Weitere Informationen finden Sie unter Anpassen von Amazon S3-URLs mit CNAMEs. In diesem Beispiel wird Folgendes verwendet:

  • Bucket-Name ‐ awsexamplebucket1.net

  • Schlüsselname - homepage.html

Die URL lautet wie folgt:

http://www.awsexamplebucket1.net/homepage.html

Das Beispiel ist wie folgt:

GET /homepage.html HTTP/1.1 Host: www.awsexamplebucket1.net

Anpassen von Amazon S3-URLs mit CNAMEs

Abhängig von den Anforderungen können Sie die Anzeige von s3.Region.amazonaws.com auf der Website oder im Service gegebenenfalls unterbinden. Wenn Sie beispielsweise Websiteabbilder auf Amazon S3 hosten, bevorzugen Sie möglicherweise http://images.awsexamplebucket1.net/ anstelle von http://images.awsexamplebucket1.net.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.awsexamplebucket1.net.s3.us-east-1.amazonaws.com/mydog.jpg. Durch die Verwendung von CNAME können Sie images.awsexamplebucket1.net einem Amazon S3-Host-Namen zuordnen, sodass die vorherige URL als http://images.awsexamplebucket1.net/mydog.jpg angezeigt wird.

Der Bucket-Name muss dem CNAME entsprechen. Wenn Sie z. B. einen CNAME für die Zuordnung von images.awsexamplebucket1.net zu images.awsexamplebucket1.net.s3.us-east-1.amazonaws.com erstellen, sind http://images.awsexamplebucket1.net/filename und http://images.awsexamplebucket1.net.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.awsexamplebucket1.net lauten und sich Ihr Bucket in der Region USA Ost (Nord-Virginia) befindet, sollte der CNAME-Datensatz einen Alias für images.awsexamplebucket1.net.s3.us-east-1.amazonaws.com erstellen.

images.awsexamplebucket1.net CNAME images.awsexamplebucket1.net.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 können alle Amazon S3-Endpunkte verwendet werden. Beispielsweise kann s3.ap-southeast-1.amazonaws.com in CNAMEs verwendet werden. Weitere Informationen zu Endpunkten finden Sie unter Anforderungsendpunkte.

So verknüpfen Sie einen Host-Namen unter Verwendung von CNAMEs 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 awsexamplebucket1.net.

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

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

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

    Beispiel:

    images.awsexamplebucket1.net CNAME images.awsexamplebucket1.net.s3.us-west-2.amazonaws.com

    Wichtig

    Aus Gründen des Anforderungs-Routings muss der CNAME-Datensatz 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 DNS 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

SSL

Virtuelle gehostete URLs werden nur für Nicht-SSL-(HTTP)-Anforderungen unterstützt.

SOAP

Die SOAP-Unterstützung über HTTP ist veraltet, steht über HTTPS aber noch zur Verfügung. Die neuen Amazon S3-Funktionen werden unter SOAP nicht unterstützt. Wir empfehlen, entweder die REST API oder die AWS SDKs zu verwenden.

Abwärtskompatibilität

Legacy-Endpunkte

Einige Regionen unterstützen Legacy-Endpunkte. Möglicherweise werden diese Endpunkte in Ihren Serverzugriffsprotokollen oder CloudTrail-Protokollen angezeigt. Weitere Informationen finden Sie unten. Eine vollständige Liste der Amazon S3-Regionen und -Endpunkte finden Sie unter Amazon S3-Regionen und -Endpunkte in der Allgemeinen AWS-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 im virtuellen Hosting-Stil haben das unten gezeigte Format.

https://bucket-name.s3.Region.amazonaws.com/key name

Amazon S3-URLs im Pfad-Stil haben das unten gezeigte Format.

https://s3.Region.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 Serverzugriffsprotokollen oder CloudTrail-Protokollen angezeigt:

https://bucket-name.s3-Region.amazonaws.com

In diesem Beispiel lautet der Bucket-Name my-bucket und die Region USA West (Oregon):

https://my-bucket.s3-us-west-2.amazonaws.com

Globaler Legacy-Endpunkt

Für einige Regionen kann der globale Legacy-Endpunkt verwendet werden, 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-Logs sehen Sie möglicherweise Anforderungen, die den globalen Legacy-Endpunkt verwenden. In diesem Beispiel lautet der Bucket-Name my-bucket und wird der globale Legacy-Endpunkt angezeigt:

https://my-bucket.s3.amazonaws.com

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

Anforderungen, die mit dem globalen Legacy-Endpunkt gemacht 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 mit virtuellem Hosting für andere Regionen

Der globale Legacy-Endpunkt wird auch für virtuell gehostete Anforderungen 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 älteren globalen Endpunkt verwenden, aktualisiert Amazon S3 das DNS so, dass die Anforderung an den richtigen Speicherort umgeleitet wird. Dies kann eine Weile dauern. In der Zwischenzeit gilt die Standardregel, und Ihre Anfrage im virtuellen Hosting-Stil geht an die Region USA Ost (Nord-Virginia). Amazon S3 leitet sie dann mit einer HTTP 307-Weiterleitung an die richtige Region um. Für S3-Buckets in nach dem 20. März 2019 gestarteten Regionen leitet der DNS 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 Anforderungsumleitung und die REST API.

Anforderungen im Pfadformat

Für die Region USA Ost (Nord-Virginia) kann der ältere globale Endpunkt für Anforderungen im Pfad-Stil verwendet werden.

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 sich von dem für die Region unterscheidet, 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.