URL für öffentliche Amazon S3 Eimer

Question

Ich habe einen Amazon S3 Eimer, die ich mit einer Politik wie diese

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Sid": "Allow Public Access to All Objects", 
      "Effect": "Allow", 
      "Principal": "*", 
      "Action": "s3:GetObject", 
      "Resource": "arn:aws:s3:::bucket/*" 
     } 
    ] 
} 

Mein Eimer, um ihre Eimer öffentlich machen wird nun sichtbar als http://bucket.s3-website-us-east-1.amazonaws.com/

ich andere sehen verweisen als http://s3-us-east-1.amazonaws.com/bucket/

Ich würde die 2. URL bevorzugen, aber es gibt einen Zugriff verweigert.

Wie kann ich meine Richtlinie ändern, um die 2. URL zuzulassen?

Answer 1

Die URL-Struktur, auf die Sie sich beziehen, wird im Gegensatz zum Website-Endpunkt als REST-Endpunkt bezeichnet.

---

Hinweis: Da diese Antwort ursprünglich geschrieben wurde, hat S3 dualstack Unterstützung auf REST-Endpunkten ausgerollt, neuen Host-Namen verwenden, während die bestehenden Host-Namen in Ort und Stelle belassen. Dies ist jetzt in den unten angegebenen Informationen integriert.

---

Wenn Ihr Eimer wirklich in ist us-east-1-Region von AWS - which the S3 documentation formerly referred to as the "US Standard" region, but was subsequently officially renamed to the "U.S. East (N. Virginia) Region" - dann ist http://s3-us-east-1.amazonaws.com/bucket/ nicht die richtige Form für diesen Endpunkt, obwohl es sieht aus wie es sein sollte. Das richtige Format für diese Region lautet entweder http://s3.amazonaws.com/bucket/ oder http://s3-external-1.amazonaws.com/bucket/. ¹

Das Format, das Sie verwenden, gilt für alle anderen S3-Regionen, aber nicht US-Standard US East (N. Virginia) [US-Ost-1].

S3 verfügt nun auch über dual-stack endpoint hostnames für die REST-Endpunkte. Im Gegensatz zu den ursprünglichen Endpoint-Hostnamen haben diese Namen ein konsistentes Format über Regionen hinweg, z. B. s3.dualstack.us-east-1.amazonaws.com. Diese Endpunkte unterstützen sowohl die IPv4- als auch die IPv6-Konnektivität und die DNS-Auflösung, sind aber ansonsten funktionell äquivalent zu den vorhandenen REST-Endpunkten.

Wenn Ihre Berechtigungen und Konfiguration so eingerichtet sind, dass der Website-Endpunkt funktioniert, sollte auch der REST-Endpunkt funktionieren.

Allerdings ... die beiden Endpunkte bieten nicht die gleiche Funktionalität. Der REST-Endpunkt ist grob gesagt besser für den Maschinenzugriff geeignet und der Website-Endpunkt eignet sich besser für den menschlichen Zugriff, da der Website-Endpunkt freundliche Fehlermeldungen, Indexdokumente und Weiterleitungen bietet, während der REST-Endpunkt dies nicht tut t. Auf der anderen Seite bietet der REST-Endpunkt HTTPS und Unterstützung für signierte URLs, der Endpunkt der Website hingegen nicht.

Wählen Sie die richtige Art von Endpunkt (REST oder Website) für Ihre Anwendung:

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff

---

¹ s3-external-1.amazonaws.comhas been referred to als "Northern Virginia Endpunkt," im Gegensatz zu „Global Endpunkt "s3.amazonaws.com.Es war inoffiziell möglich, bei neuen Objekten in dieser Region eine Schreib-nach-Schreib-Konsistenz zu erhalten, wenn der Hostname "s3-external-1" verwendet wurde, da dies Sie zu einer Teilmenge möglicher physikalischer Endpunkte senden würde, die diese Funktionalität bereitstellen könnten. Dieses Verhalten wird nun offiziell auf diesem Endpunkt unterstützt, daher ist dies in vielen Anwendungen wahrscheinlich die bessere Wahl. Zuvor s3-external-2had been referred to als "Pacific Northwest Endpunkt" für US-Standard, obwohl es jetzt ein CNAME in DNS für s3-external-1 ist, so scheint s3-external-2 keinen Zweck außer der Abwärtskompatibilität zu haben.