Seit einiger Zeit haben wir fast alle statischen Dateien unserer Seiten bei Amazon S3 ausgelagert. Dies hat den Vorteil, dass diese immer performant ausgeliefert werden und gleichzeitig unseren Server entlasten. Und das für einen wirklich guten Preis und relativ Wartungsfrei.
Nun haben wir aber bemerkt, dass die Header-Informationen (Metadaten) der ausgelieferten Bilder nicht optimal für die Cache-Nutzung der Browser waren. So haben wir zwar den Cache-Control Header gesetzt, welcher aber offensichtlich erst in Kombination mit einem Expires Header wirklich gut funktioniert. So haben die Browser die Bilder zwar aus dem Cache genommen, dennoch aber immer eine Request an Amazon S3 geschickt. Diese wurden mit „not modified“ quittiert. Da sich unsere Bilder aber kaum ändern ist auch diese Request unnötig.
Wir wollten nun mit der Software „Bucket Explorer“ zu allen Dateien die entsprechenden MetaDaten hinzufügen. Da es für uns aussah als sei das eine recht unkritische Änderung haben wir alle Dateien markiert und die Software machen lassen was nötig ist. Mit über 3.000 Dateien dauert der Vorgang etwas – und während der „Bucket Explorer“ wild die auf Amazon S3 ausgelagerten Bilder änderte stellten wir fest, das einige Bilder schon nicht mehr verfügbar waren.
Natürlich haben wir den Vorgang erstmal beendet, um eine Ausbreitung des Problems zu verhindern.
Nach genauerer Analyse stellte sich heraus, dass Amazon S3 jede Anfrage auf eine unserer Dateien mit
<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>DA60AA9F2FACFC28</RequestId><HostId>9pU1s5bXZYv439VkUIk5LQVbDTGYA5p7YSkomxNgoR0sctrM7/+PPVPAIzMlRp6</HostId></Error>
quittierte.
Auch wenn man eine Datei in das S3 Bucket schon, sie auf public setze erschien diese Meldung. In einem zum Test angelegten Bucket funktionierte aber alles wunderbar. Alle Rechte-Änderungen haben nichts gebracht – auch Tipps aus dem Netz, dass man per FTP die Owner Daten zurücksetzt und wieder korrekt setzt haben keine Wirkung gezeigt. Amazon S3 gabe immer die obige Fehlermeldung zurück.
Letztendlich haben wir versucht das komplette Bucket zu kopieren … nach einiger Zeit (denn auch das dauert bei über 3.000 Dateien seine Zeit) stellten wir fest, dass der Zugriff auf diese Dateien dann möglich war.
Unsere Lösung war also die Dateien komplett in ein neues Bucket zu kopieren und dort wieder auf public zu setzen. Leider ein sehr langwieriger Prozess.
Nun noch die Amazon CloudFront Subdomain ändern löschen und neu anlegen, den Nameserver Eintrag auf dem Server anpassen und alles läuft wieder. Einen Arbeitstag später … 🙁
Hi Sven,
vielen Dank!
wir haben das gleiche „Access Denied“ Problem dank deinem Beitrag zügig gelöst.