Websites herunterladen, die Amazon S3 nutzen

Über Amazon S3

Amazon S3 ist nichts, was eine Website ausführt. Der Dienst ist der Ort, an dem eine Website Dinge aufbewahrt, was ihn unter den Einträgen eines Technologie-Datensatzes ungewöhnlich macht. Nichts wird seinetwegen gerendert. Kein Besucher interagiert mit ihm. Ein Treffer bedeutet lediglich, dass irgendwo in der ausgelieferten Seite ein Verweis nicht auf den eigenen Server der Website zeigt, sondern auf Objektspeicher des Anbieters Amazon, und diese eine Tatsache verrät erstaunlich viel über die Organisation hinter der Domain.

Die Information betrifft die Architektur. Bilder, Videos, Dokumente, Downloads oder eine komplette statische Website aus einem Storage-Bucket auszuliefern, ist eine Entscheidung, die jemand getroffen hat, um Inhalte von Rechenleistung zu trennen, und sie geht meist mit einer insgesamt cloudorientierten Aufstellung einher. Teams, die ihre Assets dort ablegen, sind oft auch Teams mit Build-Pipelines, Infrastruktur als Code, einer Rechnung von einem Cloud-Anbieter und jemandem in der Technik, der weiß, was eine Region ist. Für alle, die Cloud-Tools, Kostenmanagement, Medienverarbeitung, Prüfungen der Sicherheitslage oder Migrationsdienste verkaufen, ist dieser Schluss bereits der Qualifizierungsschritt, und er ist von außen sichtbar, ohne dass man jemandem eine Frage stellen muss.

Bei der Erkennung muss man klar sagen, wo die Grenzen liegen, denn diese Kategorie gehört zu denen, die am stärksten untererfasst werden. Die Zuordnung hängt normalerweise davon ab, dass ein Storage-Hostname im Quelltext der Seite auftaucht. Sobald ein Team dem Bucket ein Content Delivery Network vorschaltet und alles von der eigenen Domain ausliefert, was das empfohlene und bei echtem Umfang übliche Muster ist, verschwindet der Beleg vollständig aus der Seite. Private Buckets, Backups, Datenpipelines und anwendungsinterne Abläufe tauchen in einem Abruf überhaupt nie auf. Ein großer Kunde kann hier also völlig unsichtbar sein, während eine kleine Website, die direkt auf eine hochgeladene Datei verlinkt hat, ganz selbstverständlich gezählt wird.

Die Folge sollte man ohne Beschönigung aussprechen. Der Bestand, den wir zeigen können, ist zugunsten direkter Verlinkung verzerrt, und direkte Verlinkung hängt mit einfacheren Setups, älteren Seiten, kleineren Teams und CMS-Plugins zusammen, die Medien direkt in einen Bucket hochladen. Anspruchsvolle Infrastruktur ist systematisch unterrepräsentiert. Stand Oktober 2026 erkennen wir den Dienst auf 381.790 Websites, und richtig gelesen ist diese Zahl eine Untergrenze der sichtbaren Nutzung und keine Schätzung der Kundenbasis, die kein externer Crawl messen kann.

Auch als Untergrenze betrachtet ergibt die Geografie ein stimmiges Bild für einen Dienst der Kategorie CDN, der seit 2006 unter der Lizenz Proprietary angeboten wird. Am häufigsten verorten wir Websites in den USA, insgesamt 271.385, und die Endung, die uns am häufigsten begegnet, ist .com, was eher zeigt, wo die Cloud-Nutzung begann und wo der Entwicklermarkt am größten ist, als wo ein bestimmtes Byte physisch gespeichert ist.

Der Grund, die Liste zu nehmen, statt Domains einzeln zu prüfen, ist, dass Architekturfragen Fragen an den gesamten Bestand sind. Welche Websites in einem Markt ihren Speicher direkt offenlegen. Welche Content-Management-Systeme Medien standardmäßig in Buckets schieben und dadurch den Hostnamen preisgeben. Welche Unternehmen Objektspeicher mit einem bestimmten Framework, einer E-Commerce-Plattform oder einem Auslieferungsnetz kombinieren. Jede dieser Fragen lässt sich durch Filtern einer Datei beantworten und über ein Suchfeld nicht, und die Zeilen enthalten Organisationen, von denen Sie nie gewusst hätten, dass Sie nach ihnen suchen sollten, und genau das kann ein Abfrage-Tool strukturell nicht leisten.