branchway

Dateispeicher mit S3-Schnittstelle

Hochgeladene Dateien gehören nicht ins Projektverzeichnis: Beim nächsten Deployment ist das ersetzt. Der Speicher liegt daneben, überdauert jedes Deployment und ist aus allen Instanzen gleichzeitig erreichbar.

S3, ohne Amazon

Die Schnittstelle folgt der S3-API. Das heißt praktisch: Das AWS-SDK, boto3, rclone, s3cmd und die Upload-Bibliothek deines Frameworks funktionieren unverändert. Du tauschst den Endpunkt aus, nicht deinen Code.

endpoint: "https://branchway.io/s3"
region:   "de-fal-1"
forcePathStyle: true

Unterstützt werden Hochladen, Lesen, Kopfdaten, Löschen, Kopieren und das Auflisten mit Präfix und Begrenzung. Dazu die drei Dinge, an denen Werkzeuge sonst scheitern:

  • Mehrteilige Uploads. Große Dateien lädt jedes SDK von selbst in Stücken hoch – bricht die Leitung ab, muss nur das betroffene Stück noch einmal.
  • Bereichsanfragen. Video- und PDF-Anzeigen im Browser, fortgesetzte Downloads und parallele Überträge brauchen sie.
  • Vorsignierte Adressen. Ein zeitlich begrenzter Link zum Laden oder Hochladen, den du weitergeben kannst, ohne einen Schlüssel aus der Hand zu geben.

Die Signatur wird nach AWS Signature Version 4 geprüft; Anfragen, die älter als 15 Minuten sind, werden abgelehnt.

Preis: 2 Cent je Gigabyte und Monat

Berechnet wird der tatsächlich belegte Platz, gemittelt über den Monat – wer am 15. löscht, zahlt nicht den ganzen Monat. Das erste Gigabyte je Team ist frei.

  • Kein Preis für Datenverkehr. Weder hinein noch hinaus.
  • Kein Preis je Anfrage. Eine Million kleine Dateien kosten so viel wie ihre Bytes.
  • Kein Preis fürs Löschen. Auch nicht für früh gelöschte Objekte.

Zum Vergleich: Amazon S3 Standard kostet in Frankfurt rund 2,45 Cent je Gigabyte und Monat – und dazu Gebühren je 1000 Anfragen sowie für ausgehenden Datenverkehr, der bei einer Bilderseite schnell den größeren Teil der Rechnung ausmacht. Genau diese beiden Posten fallen hier weg.

Öffentlich oder privat

Ein Speicher ist privat, solange du nichts anderes einstellst: Jeder Zugriff braucht einen Zugangsschlüssel. Wer Bilder direkt auf einer Website einbinden will, schaltet ihn auf öffentlich lesbar – dann ist das Lesen ohne Schlüssel möglich, Schreiben und Löschen bleiben geschützt.

Zugangsschlüssel gibt es je Speicher beliebig viele, wahlweise nur mit Leserecht. So bekommt ein Sicherungsskript einen eigenen Schlüssel, den du einzeln zurückziehen kannst, ohne die App zu stören.

Häufige Fragen

Wo liegen die Dateien?

Auf unseren Servern in Deutschland – im selben Rechenzentrum wie deine Apps. Es gibt keine Kopie außerhalb der EU.

Wie groß darf eine einzelne Datei sein?

Bis 5 GB je Objekt. Für größere Dateien ist ein Objektspeicher ohnehin selten das richtige Werkzeug.

Wie gebe ich eine einzelne Datei weiter, ohne einen Schlüssel herauszugeben?

Mit einer vorsignierten Adresse. Dein SDK erzeugt sie ohne Anfrage an uns (getSignedUrl beim AWS-SDK, generate_presigned_url bei boto3); sie gilt so lange, wie du festlegst, höchstens aber 24 Stunden. Amazon erlaubt sieben Tage – uns ist das zu lang: So eine Adresse landet am Ende in Chatverläufen und Browser-Verläufen und wirkt dort weiter. Wer sie sofort entwerten will, löscht den Zugriffsschlüssel, mit dem sie unterschrieben wurde.

Gibt es eine Obergrenze je Speicher?

Ja. Anders als bei Amazon steht hinter der Schnittstelle eine einzelne Platte, deshalb hat jeder Speicher ein Kontingent: 10 GB zu Beginn, in der Console bis 100 GB selbst erhöhbar, darüber hinaus über den Support. Bezahlt wird weiterhin nur der belegte Platz. Ist das Kontingent ausgeschöpft, werden Uploads mit 507 abgelehnt – Lesen und Löschen gehen weiter.

Brauche ich den Speicher, wenn meine App schon ein Datenverzeichnis hat?

Für kleine Mengen reicht das Verzeichnis unter /daten. Der Speicher lohnt sich, sobald Dateien öffentlich ausgeliefert werden sollen, mehrere Apps darauf zugreifen oder es um Gigabytes geht.

Weiterlesen