Einer unserer Kunden wollte kürzlich für einen S3-Bucket S3 Transfer Acceleration aktivieren – einen Service, der Datenübertragungen zu und von Amazon Simple Storage Service (S3) beschleunigt – und stieß dabei auf einen unerwarteten Fehler (Access Denied).
Zunächst tippten wir auf ein Problem mit den IAM-Berechtigungen, eine Service Control Policy oder eine S3-Bucket-Policy und nahmen genau diese Punkte unter die Lupe.
Bei der Analyse zeigte sich:
- Dem Konto war außer der Full-AWS-Access-SCP, die den Zugriff erlaubt, keine Deny-SCP zugeordnet.
- Für den S3-Bucket war keine Bucket-Policy hinterlegt – also auch kein explizites Deny auf Bucket-Ebene.
- Die Namenskonvention des Buckets erfüllte die Anforderungen für S3 Transfer Acceleration.
- Der Benutzer verfügte über IAM-Admin-Rechte. Auch ein Versuch mit dem Root-Benutzer des AWS-Kontos schlug mit derselben Fehlermeldung fehl.
- Amazon S3 Transfer Acceleration wurde in den Regionen des S3-Buckets unterstützt.
Eine kurze Google-Suche zeigte: Derselbe Fehler wurde in mehreren Foren gemeldet – eine Lösung gab es jedoch nirgends.
Glücklicherweise ließ sich das Verhalten in einigen unserer privaten AWS-Konten reproduzieren. Wir gruben tiefer, fanden die Ursache aber zunächst nicht. Was uns dabei auffiel:
- Der Fehler trat gehäuft in Konten auf, die über AWS Organizations erstellt wurden.
- Es gab keinen klaren Zusammenhang mit dem Alter der Konten.
- In AWS CloudTrail fand sich kein Hinweis auf die Ursache.
- Auch der Versuch, die AWS Organization zu verlassen und das Konto eigenständig zu betreiben, brachte keine Lösung.
Beim weiteren Stöbern in der AWS-Dokumentation stießen wir darauf, dass Amazon S3 Transfer Acceleration die weltweit verteilten Edge Locations von Amazon CloudFront nutzt.
Also versuchten wir, eine neue CloudFront-Distribution anzulegen – auch das schlug mit folgendem Fehler fehl:
An diesem Punkt waren wir kurz davor aufzugeben und unseren AWS Support Plan upzugraden. Im Zeitalter der Kostenoptimierung wollten wir uns zusätzliche Ausgaben aber gerne sparen.
Dann kam uns der Gedanke, dass es am Security Score des AWS-Kontos liegen könnte (manchmal zahlt sich frühere AWS-Erfahrung eben aus ;) – und wir probierten es kurzerhand aus.
Wir starteten ein paar EC2-Instanzen in der Region N. Virginia (us-east-1) – t2.micro reicht völlig – und ließen sie 2–3 Stunden laufen, bis eine E-Mail wie die folgende eintraf:
Nach Erhalt dieser E-Mail (siehe Screenshot oben) versuchten wir erneut, Transfer Acceleration zu aktivieren – und es funktionierte!
Das Fazit: Bevor Sie Amazon S3 Transfer Acceleration nutzen können, muss das Konto explizit in der Region N. Virginia (us-east-1) verifiziert sein. Eine Verifizierung in einer anderen Region reicht nicht aus.
AWS könnte hier sowohl die Dokumentation als auch die Fehlermeldung verbessern, damit Anwender die Ursache nachvollziehen können – und nicht unnötig für AWS Support bezahlen müssen.
Dieser Blogbeitrag ist gemeinsam mit meinem Kollegen und Security-Experten entstanden.
.
Senior Cloud Architect bei DoiT International
Autor
Glad it helped you, i will add the error to the text .
--
Antworten
Wish google indexed this page. Can you add the error in the page as text so people can find this?
Thanks for saving the day!!
--
Antworten
von
[Setting up SAML Authentication to Stream Amazon Workspaces using Auth 0 as your identity provider.\ \
23. Nov. 2023
von
[Building AWS Architecture with MCP Servers and Strands Agents\ \
22. Sep. 2025
von
[JA3 and JA4 Fingerprints in AWS WAF and Beyond\ \
10. Apr. 2025
[AWS VPN Concentrators: Simplifying Large-Scale Hybrid Connectivity\ \
22. Jan.
von
[A Complete Guide for URL Redirection using AWS CloudFront, S3, and Route53\ \
1. Okt. 2025
[Migrating from Serverless Framework to AWS SAM\ \
7. Okt. 2025
[S3\ \
4. Okt. 2025
[AWS S3 Bucket\ \
19. Dez. 2025
[Web Application with EC2, S3, CloudFront, and RDS\