VergleicheTechnologie

Bild-Hosting B2B-Auswahl 2026: 15-Punkte-Checkliste für die RFP-Bewertung

Veröffentlicht am14.4.202612 min read

Einen Image-Hosting-Dienst für das Unternehmen zu beschaffen ist vergleichbar mit der Auswahl einer Datenbank. Die Landingpage sagt nichts Brauchbares aus.

Mein Team bat mich, einen Ersatzanbieter zu evaluieren. Ich habe sämtliche Production-Incidents und Abrechnungsüberraschungen der letzten drei Jahre zusammengetragen und in eine Checkliste überführt. Dieses Dokument ist kein Vergleich nach dem Motto „welcher CDN hat mehr PoPs". Es ist die Art von Tabelle, die man ins RFP einfügt und vom Anbieter eine Antwort „Ja / Nein / Teilweise" pro Zeile verlangt. Unter der Oberfläche unterscheiden sich Image-Hosting-Dienste, die identisch aussehen, in ihrer Architektur erheblich.

Wer nur nach dem günstigsten oder kostenlosen Angebot sucht, findet Antworten im Vergleich kostenloser Image-Hosting-Dienste oder bei den Imgur-Alternativen. Dieser Artikel richtet sich an technische Leiter, SaaS-Einkauf und DevOps-Ingenieure.

Warum B2B Image Hosting eine völlig andere Disziplin ist

Privatnutzer fragen: „Kann ich hochladen? Lässt sich der Link einfach teilen?"

Unternehmen stellen einen ganz anderen Fragenkatalog. Enthält der Vertrag ein SLA? Wie degradiert die API bei Rate-Limit-Überschreitung? Können Egress-Kosten in einem Monat plötzlich doppelt so hoch ausfallen? Wenn der DSGVO-Auditor fragt, wie lange EXIF-Daten gespeichert werden — gibt es eine Antwort?

Ehrlich gesagt: B2B Image Hosting zu beschaffen bedeutet, drei Dinge zu kaufen: eine vorhersagbare Kostenkurve, überprüfbare Systemgarantien und integrierbare Protokollschnittstellen. Alle 15 Punkte unten drehen sich um diese drei Aspekte.

Nach einem Production-Ausfall habe ich gelernt: Ein kostenloser Tarif übersteht eine Demo, aber keinen Produktivbetrieb.

Die 15-Punkte-Checkliste für das RFP (direkt in die Beschaffungsunterlagen kopieren)

Unten steht die Tabelle, die ich tatsächlich bei Anbieter-Evaluierungen verwende. Jeder Punkt hat eine Verifikationsmethode. „Unterstützen Sie das?" zu fragen ist keine Verifikation — Anbieter antworten immer mit Ja.

#	Spezifikation	Verifikationsmethode	Bestehenskriterium
1	S3 API-Kompatibilität	`s3api list-objects-v2 --prefix` ausführen	Response-Schema stimmt mit AWS überein
2	Multipart Upload	500-MB-Datei hochladen, unterbrechen, fortsetzen	Part Retry wird unterstützt
3	Pre-signed URL	15-Minuten-URL erzeugen und Signatur prüfen	HMAC-SHA256, konfigurierbares TTL
4	Webhook Events	Upload/Delete-Events auslösen	HMAC-Signatur + Retry-Mechanismus
5	Rate-Limit-Policy	Burst-Test ausführen	429 + Retry-After Header
6	SLA-Bedingungen	MSA lesen	≥99,9 %, Service Credit enthalten
7	Multi-Region	Region-Liste anfordern	≥2 Regionen, Cross-Region-Sync
8	Egress-Preise	Preisblatt anfordern	Transparenter Stückpreis, Staffelrabatt
9	Bildverarbeitungs-Pipeline	On-the-fly-Transformation testen	WebP/AVIF, URL-Parameter
10	CDN Edge Nodes	Globalen Ping-Test ausführen	≥50 PoPs, EU-Standorte enthalten
11	EXIF / Metadata-Kontrolle	Foto mit GPS-Daten hochladen	Selektives Entfernen möglich
12	Authentifizierung	API-Dokumentation prüfen	OAuth2 + API-Key-Rotation
13	Audit-Logs	Log-Aufbewahrung erfragen	≥90 Tage, exportierbar
14	Compliance-Zertifikate	SOC 2 / ISO 27001 anfordern	Mindestens eines
15	Datenresidenz & Löschung	DPA-Bedingungen prüfen	Region wählbar, Hard Delete

Nicht einfach Ja/Nein ankreuzen. Jeder Punkt erfordert vom Anbieter einen Dokumentationslink oder technische Verifikationsschritte. Alles ohne Dokumentation ist in der Praxis „geplant, aber nicht umgesetzt".

Technische Details — wo Anbieter gerne vage bleiben

Die Tabelle ist das Gerüst. Die folgenden Punkte sind die Stellen, an denen Anbieter bei Vertragsverhandlungen am häufigsten ausweichen.

S3-Kompatibilität ist keine Ein-Satz-Aussage

„Wir sind S3-kompatibel" ist die meistgehörte Behauptung von Image-Hosting-Anbietern. Die S3 API hat allerdings über 200 Operationen. Entscheidend ist, ob die Teilmenge, die Sie tatsächlich nutzen, korrekt funktioniert.

GetObject und PutObject beherrscht jeder. Gehen wir tiefer:

# Test multipart
aws s3api create-multipart-upload --bucket test --key big.mp4 \
  --endpoint-url https://vendor.example.com

# Test versioning
aws s3api put-bucket-versioning --bucket test \
  --versioning-configuration Status=Enabled

# Test lifecycle
aws s3api put-bucket-lifecycle-configuration ...

Aus meiner Erfahrung bestehen weniger als 60 % der Anbieter alle drei Tests. Bucket Lifecycle und Object Lock fehlen am häufigsten — und genau diese beiden sind für die Compliance-Prüfung unverzichtbar.

Pre-signed URL: TTL und Signaturalgorithmus

Dies ist die gebräuchlichste Authentifizierungsmethode im B2B-Bereich. Endnutzer haben keine Zugangsdaten; Sie stellen ein zeitlich befristetes Ticket aus.

Der zugrundeliegende Mechanismus ist HMAC-SHA256: Method, Path, Ablaufzeit und Header werden zu einem String-to-Sign zusammengefasst und mit dem Secret Key signiert. Ein guter Anbieter bietet:

Konfigurierbares TTL (von 1 Minute bis 7 Tage)
IP-Einschränkung (aws:SourceIp-Condition)
HTTP-Method-Einschränkung
SigV4-Unterstützung (SigV2 ist veraltet; jeder Anbieter, der noch SigV2 verwendet, fällt automatisch raus)

Ein schlechter Anbieter liefert eine „nie ablaufende öffentliche URL" und nennt das „signed". Genau deshalb muss Pre-signed URL explizit im RFP stehen.

Webhook-Signaturprüfung — da habe ich Lehrgeld gezahlt

Webhooks sind die Grundlage jeder Event-driven Architecture. Upload abgeschlossen, Virenscan fertig, Transkodierung fertig — jedes Event muss an Ihr System gepusht werden.

Aber die Sicherheit von Webhooks ist der Punkt, an dem Anbieter am liebsten sparen. Schlechte Implementierungen, die mir begegnet sind:

Keine Signatur, einfach ein nackter POST
Signatur vorhanden, aber Secret im Query-String
Signatur vorhanden, aber mit MD5
Signatur vorhanden, aber ohne Timestamp — Replay-Angriffe sind trivial

Ein konformer Webhook muss haben:

HMAC-SHA256-Signatur im X-Signature Header
X-Timestamp Header, Requests älter als 5 Minuten ablehnen
Automatischer Retry bei Fehlern (Exponential Backoff, mindestens 3 Versuche)
Dead Letter Queue oder Replay API

So sieht die Webhook-Verifikation in Go aus:

func verifyWebhook(body []byte, sig, ts, secret string) bool {
    if time.Since(parseTS(ts)) > 5*time.Minute {
        return false
    }
    mac := hmac.New(sha256.New, []byte(secret))
    mac.Write([]byte(ts + "." + string(body)))
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(sig), []byte(expected))
}

Ohne die Timestamp-Prüfung gehen Replay-Angriffe direkt durch Ihr gesamtes Event-System.

Rate Limits: Zwei Ebenen der Bewertung

Rate Limits haben zwei Dimensionen: wie hoch Ihr Kontingent ist und was passiert, wenn Sie es überschreiten.

Das Kontingent ist leicht verhandelbar, meist per-second oder per-minute im Tarif festgelegt. Die entscheidende Frage ist das Verhalten bei Überschreitung:

Verhalten	Bewertung
Harter 503-Abbruch	Nicht bestanden
429 ohne Retry-After	Teilweise bestanden
429 + Retry-After Header	Bestanden
429 + Retry-After + Quota-Header	Ausgezeichnet

Bonuspunkte für X-RateLimit-Remaining Header, die es Ihrem Code ermöglichen, proaktiv zu drosseln statt passiv 429er zu kassieren.

SLA — der Teufel steckt in den Ausschlussklauseln

Alle schreiben 99,9 %. Das entspricht 43,2 Minuten Downtime pro Monat. 99,95 % sind 21,6 Minuten. 99,99 % sind 4,3 Minuten.

Aber der wahre Wert eines SLA liegt nicht in der Zahl, sondern in der Ausschlussklausel. Jede Zeile lesen:

Zählt geplante Wartung als Downtime?
Zählen regionale Ausfälle?
Zählen DDoS-Perioden?
Zählen Ausfälle von Drittanbieter-Abhängigkeiten (z. B. Upstream-DNS)?

Noch wichtiger: der Service-Credit-Mechanismus. Wie viel wird bei SLA-Verfehlung erstattet? Konto-Credit oder Bargeld? Verfällt der Credit oder ist er kumulierbar?

Ehrlich gesagt sehen die meisten SLAs auf dem Papier gut aus. Wenn tatsächlich ein Claim eingereicht wird, blocken die Ausschlussklauseln fast alles ab. Deshalb bei der Beschaffung nicht auf den Prozentsatz fixieren, sondern die tatsächliche Incident-Historie der letzten 12 Monate anfordern — das geht unter NDA.

Egress-Preise — die versteckte Kostenfalle

Egress (ausgehende Bandbreite) ist der Punkt, an dem Image-Hosting-Budgets explodieren. Der klassische Anbieter-Trick: günstiger Speicher, teurer Egress.

Die Zahlen zeigen, dass Egress-Preise unter den großen Anbietern um den Faktor 10 und mehr abweichen können. Cloudflare R2 bietet Zero Egress (innerhalb des eigenen Netzwerks), Cloudinary nutzt ein Credit-Modell, imgix berechnet pro Request. Was spart, hängt vollständig vom Traffic-Profil ab.

Vor der Unterschrift drei Dinge klären:

Gibt es Staffelrabatte nach Volumen? Typischerweise ab 10 TB/Monat relevant
Zählt interner Cross-Region-Traffic als Egress?
Zählen CDN Cache Hits als Egress? Manche Anbieter rechnen Cache Hits als abrechnungsrelevanten Traffic

Kleiner Tipp: Ich wurde hier kalt erwischt. In der Testumgebung liefen 200 GB/Monat problemlos. Nach dem Go-Live sprang der Traffic über Nacht auf 8 TB, und die Rechnung hatte eine Null mehr. Der Vertrag regelte kein Overage-Verhalten, also trugen wir die vollen Kosten.

Besonderheiten für den DACH-Markt

Für Unternehmen im deutschsprachigen Raum ist die DSGVO der zentrale Maßstab. Jeder Image-Hosting-Anbieter, der personenbezogene Daten verarbeitet (und GPS-Koordinaten in EXIF sind personenbezogene Daten), benötigt einen Auftragsverarbeitungsvertrag (AVV/DPA). Ohne AVV ist der Einsatz rechtswidrig.

Bevorzugen Sie Anbieter mit Rechenzentren in der EU — AWS Frankfurt (eu-central-1), Hetzner Cloud, oder IONOS Cloud kommen in Frage. Für besonders sensible Workloads bieten Anbieter wie Hetzner und IONOS den Vorteil, dass Daten Deutschland nicht verlassen. Achten Sie auch auf die Schrems-II-Konformität bei US-Anbietern: Cloudflare und AWS bieten EU-Standardvertragsklauseln, aber die rechtliche Lage bleibt dynamisch.

Kleiner Tipp: Fordern Sie vom Anbieter explizit ein Verarbeitungsverzeichnis (Art. 30 DSGVO) an. Wer das nicht liefern kann, nimmt Datenschutz nicht ernst genug.

Drei Spezifikationen, die gerne übersehen werden

Diese drei Punkte tauchen in den üblichen „Image-Hosting-Vergleich"-Artikeln nicht auf, verursachen aber in der Praxis Schmerzen.

EXIF und Metadaten — ein Compliance-Thema

EXIF enthält GPS-Koordinaten, Kamera-Seriennummern und Aufnahmezeitpunkte. Beim Upload auf einen öffentlichen Image Host werden alle Metadaten standardmäßig mitgeliefert.

Im B2B-Kontext muss man fragen:

Können EXIF-Felder selektiv entfernt werden (GPS entfernen, Copyright behalten)?
Wird IPTC/XMP-Metadaten-Manipulation unterstützt?
Erfolgt die Metadaten-Verarbeitung beim Upload oder on-the-fly?

Die DSGVO klassifiziert GPS-Koordinaten eindeutig als personenbezogene Daten. Fehlbehandlung überträgt das Compliance-Risiko direkt auf Ihr Unternehmen. Das Bayerische Landesamt für Datenschutzaufsicht hat hierzu bereits Bußgelder verhängt.

Hybride Authentifizierung: OAuth2 + API Key

Ältere Image-Hosting-Dienste bieten nur API Keys. Modernes B2B erfordert einen hybriden Ansatz:

System-zu-System: API Key + IP-Allowlist
Benutzer-SPA: OAuth2 PKCE Flow
Temporärer Zugriff: Pre-signed URL

Wenn ein Anbieter Ihnen einen einzigen permanenten API Key gibt und Sie die Scopes selbst verwalten sollen, schiebt er das Sicherheitsrisiko auf den Kunden. Eine ordentliche Lösung unterstützt Scoped Tokens, automatische Rotation und Revocation APIs.

Hard Delete und Datenaufbewahrung

DSGVO-Löschanfragen (Recht auf Vergessenwerden, Art. 17) müssen innerhalb von 30 Tagen umgesetzt werden. Viele Image Hosts sagen „wir löschen", meinen aber Soft Delete — das Objekt liegt weiterhin in S3, im CDN-Cache, auf Backup-Bändern.

Bei der Beschaffung unbedingt bestätigen:

Ist die Löschung im AVV/DPA festgeschrieben?
Haben Backup-Zyklen entsprechende Löschmechanismen?
Kann der Anbieter einen Löschnachweis erbringen?

Ich habe einen realen Fall bearbeitet: Ein Kunde erhielt eine DSGVO-Löschanfrage, aber die Cold-Storage-Backups des Anbieters hatten eine 365-Tage-Aufbewahrung, die nicht überschrieben werden konnte. Die juristische Klärung dauerte drei Monate.

CDN Edge Nodes und reale Latenz

PoP-Zahlen werden gerne aufgebläht. Ein Anbieter mit „300+ PoPs" hat möglicherweise 280 davon in Nordamerika und Europa und 5 im asiatisch-pazifischen Raum.

Die Verifikation ist einfach: Anycast-IP des Anbieters besorgen und mtr von VPS-Instanzen in verschiedenen Regionen (Frankfurt, London, Paris, US East, Singapur) laufen lassen. Alles über 80 ms RTT ist nicht akzeptabel.

Für den europäischen Mittelstand mit internationaler Kundschaft: Wenn Ihre CDN-Anfragen über den Atlantik geroutet werden, sind 120 ms+ keine Seltenheit. Frontend-Bildladezeiten leiden merklich. Im B2B-SaaS, besonders E-Commerce und Medien, wirkt sich das direkt auf die Conversion Rate aus.

Wo lpic.cc einzuordnen ist

Ehrlich gesagt: lpic.cc ist derzeit keine Enterprise-B2B-Lösung.

Wir richten uns an individuelle Entwickler, Blogger und Forum-Nutzer mit kostenlosem Upload, Passwortschutz und 30-Tage-Aufbewahrung. Das Backend läuft auf Cloud-Objektspeicher mit einer eigenen API, und die Architektur nutzt mehrere in diesem Artikel besprochene Techniken (Pre-signed URL, Webhooks, EXIF-Verarbeitung). Wir bieten aber kein Enterprise SLA, keine SOC-2-Zertifizierung und keinen AVV/DPA.

Wenn Sie als technischer Leiter ein Image Hosting für den Produktivbetrieb evaluieren, nehmen Sie diese Checkliste und wenden Sie sie auf Cloudinary, imgix, Cloudflare Images oder ImageKit an. Wenn Sie eine leichtgewichtige Lösung für den persönlichen Gebrauch oder ein kleines Team suchen, probieren Sie lpic.cc aus — laden Sie kostenlos etwas hoch und sehen Sie, ob es zu Ihrem Anwendungsfall passt.

FAQ

Q1: Braucht ein kleines Team wirklich Enterprise-Image-Hosting?

Nicht unbedingt. Unter 10K MAU und weniger als 500 GB/Monat lässt sich mit Cloudflare R2 + Workers eine funktionierende Schicht für unter 5 $/Monat aufbauen. Enterprise-Lösungen bieten Mehrwert durch SLA, Compliance und Support-SLA — was ein kleines Team möglicherweise nicht benötigt. Wenn Sie aber B2B-Kunden bedienen und deren Verträge einen AVV/DPA vorschreiben, gibt es keinen Workaround.

Q2: Ist S3-Kompatibilität wirklich wichtig?

Sehr. S3 ist die De-facto-Standard-API. Kompatibilität bedeutet, dass bewährte SDKs, Terraform-Provider und Backup-Tools nutzbar sind. Inkompatibilität bedeutet Bindung an eine proprietäre API mit hohen zukünftigen Migrationskosten. Das ist ein klassischer Vendor-Lock-in-Indikator.

Q3: Warum Webhooks statt Polling?

Polling bedeutet, alle N Sekunden „fertig?" zu fragen. Webhooks bedeuten, dass der Anbieter eine Benachrichtigung schickt, wenn etwas abgeschlossen ist. Der Unterschied liegt in der Latenz (Sekunden vs. Millisekunden) und den Kosten (Ihr API-Call-Kontingent vs. null). Für Events wie Upload-Abschluss, Transkodierung und Virenscans ist Echtzeit-UX ohne Webhooks nicht möglich.

Q4: Ist der Unterschied zwischen 99,9 % und 99,99 % SLA wirklich so groß?

Zahlenmäßig sind es 43 Minuten vs. 4 Minuten pro Monat. Ob das relevant ist, hängt vom Geschäft ab. Wenn die Bilder Produktfotos im E-Commerce-Checkout-Flow sind, ist jede Minute Downtime Umsatzverlust. Wenn es Bilder im internen Mitarbeiterhandbuch sind, reichen 99,9 % oder sogar 99 %. SLA-Anforderungen an den tatsächlichen Business-Impact koppeln, nicht blind höhere Zahlen jagen.

Q5: Cloudflare R2 hat Zero Egress — ist das immer die beste Wahl?

Nein. Zero Egress bei R2 gilt nur innerhalb des Cloudflare-Netzwerks (über Workers oder CDN). Daten aus R2 in eine andere Cloud zu ziehen kostet weiterhin. Zudem ist die Preisgestaltung der Class-A-Operationen (Schreibvorgänge) bei R2 nicht günstig. Bei schreiblastigen, leselastigen Workloads spart R2 möglicherweise kein Geld. Die Gesamtkosten auf Basis des tatsächlichen Read/Write-Verhältnisses berechnen.

Quellen

#Image Hosting API#S3-kompatibel#SLA#CDN#Webhook#IT-Beschaffung#DevOps#Signed URL#DSGVO

Verfasst von

Harvey Zhang

Mitgründer & CTO

Backend-Ingenieur und Systemarchitekt mit fundierter technischer Analyse von Bildhosting-Infrastrukturen.