400 Bad Request-Fehler (selten) bei öffentlichen Amazon S3-Assets

Question

Wir hosten öffentliche S3-Assets (Bilder) unter einem lokalen Pfad mithilfe eines Reverse-Proxys von NGINX zu S3.

Wir haben in unseren Protokollen periodische Fehler (400 Fehler) festgestellt, die zwar sehr selten auftreten, aber den Besuchern Probleme bereiten. Wir können erkennen, dass es sich dabei um AWS-Fehler handelt, da der zurückgegebene Inhaltstyp application/xml ist. Das Laden dieser gleichen Assets direkt nach dem protokollierten Fehler gibt die richtige Antwort zurück.

Ich habe die Protokollierung für meine relevanten S3-Buckets aktiviert, aber beim Überprüfen der Protokolle werden für die Zeiträume, in denen die Fehler aufgetreten sind, keine 400 Fehler aufgelistet.

• Würde AWS unsere Anfragen drosseln, da sie von einer IP kommen (über den NGINX-Reverse-Proxy)?
• Welche Arten von 400-Status würde S3 für gültige öffentliche Objekte zurückgeben?
• Gibt es eine andere Stelle in der AWS-Konsole, an der diese 400-Fehler angezeigt werden, damit wir sie untersuchen können?

Aktualisierter spezifischer Beispielfall:

Beispiel für unseren lokalen Asset-Pfad: https://www.example.com/assets/images/Oasis_PalmImage_20210809_Web_v01.png

Öffentliche S3-URL: https://sb-oasis.s3.amazonaws.com/images/Oasis_PalmImage_20210809_Web_v01.png

Beispiel des NGINX-Protokolls während des protokollierten Fehlers:

response_content_type: application/xml

status: 400

content_length: 355 bytes