Zusammenfassung

  • Laut DigitalOcean speichert das Spaces CDN vorsignierte Anfragen nicht im Cache. Jede wird zum Ursprung weitergeleitet, auch mit CDN- oder eigener Domain.
  • Diese Ausnahme ist etwas anderes als eine geringe Wiederverwendung durch wechselnde URL-Parameter. Eine längere gewöhnliche Cache-Dauer hebt sie nicht auf.
  • Ein enthaltenes CDN bedeutet keinen unbegrenzten Transfer. Kosten- und Kontinuitätsannahmen müssen zu geschützten Downloads passen, nicht nur zum sichtbaren Hostnamen.

Kontinuität setzt eine verfügbare Kopie voraus

Die Erwartung an ein CDN reicht oft über Geschwindigkeit hinaus. Eine Kopie am Netzrand soll einen Teil der Arbeit vom Ursprung übernehmen. Doch ob diese Erwartung für einen bestimmten Download begründet ist, entscheidet nicht die Schreibweise seiner Adresse.

DigitalOcean erklärt in seiner Funktionsübersicht, dass bereits am Rand zwischengespeicherte Inhalte bei vorübergehend nicht verfügbarem Ursprung weiter ausgeliefert werden können. Die Bedingung ist die vorhandene Cache-Kopie. Daraus folgt keine pauschale Zusage für jede Anfrage unter einer CDN-Domain.

Der am 3. September überprüfte Spaces-CDN-Leitfaden zieht für vorsignierte URLs eine klare Grenze. Diese Anfragen werden nicht vom Spaces CDN gecacht, sondern jeweils an den Ursprung weitergereicht. Das gilt auch mit CDN-Hostname oder eigener Domain. Als hauptsächlichen Nutzen nennt der Anbieter die Einheitlichkeit des Hostnamens statt Cache-Treffern oder deren Latenzvorteil.

Für diese Anfrageklasse ist damit keine Ausweichmöglichkeit über einen Spaces-CDN-Cache-Treffer nachgewiesen. Das belegt weder einen Ausfall noch eine bestimmte Fehlerquote und verändert keine SLA. Es begrenzt die Übertragung eines Arguments: Die Kontinuität einer vorhandenen gewöhnlichen Cache-Kopie darf nicht für einen dokumentierten Weiterleitungspfad vorausgesetzt werden.

Ein gemeinsamer Name vereinheitlicht keine Ausführung

Öffentliche Bilder und geschützte Kundendokumente können in einer Anwendung unter derselben Domain erscheinen. Für Marke und Integration ist das praktisch. Für eine Abhängigkeitsanalyse können sie trotzdem verschiedenen Gruppen angehören.

Ein schneller Abruf eines öffentlichen Bildes ist keine Messung des geschützten Downloads. Ein erfolgreicher signierter Abruf bestätigt wiederum, dass der Zugriff bei dieser Anfrage funktioniert hat. Er weist nicht nach, dass ein Randserver unabhängig vom Ursprung die Datei geliefert hat.

Die Unterscheidung ist kein Vorwurf gegen den Dienst. Der beschriebene Link kann genau den beabsichtigten Zweck erfüllen. Problematisch wird es, wenn die Beschaffung Hostnamen-Konsistenz kauft und im eigenen Plan zusätzlich eine nicht belegte Entkopplung einträgt.

Ein Abnahmetest sollte deshalb Zugriff, Kompatibilität und Cache-Auslieferung als getrennte Ergebnisse führen. Die erfolgreiche Antwort ist ein sinnvoller Befund, aber kein vollständiger Nachweis des Arbeitsorts. Gerade eine unveränderte Domain kann verbergen, dass geänderte Zugriffsanforderungen eine andere Anfrageklasse auswählen.

Nicht jede fehlende Wiederverwendung ist ein Schlüsselproblem

Bei gewöhnlichem Spaces-CDN-Caching zählt jede eindeutige URL einschließlich Abfrageparametern als eigenes Asset. Häufig wechselnde Schlüssel können daher die Wiederverwendung zulässiger Inhalte erschweren. Dieses Muster zu untersuchen ist vernünftig, solange es sich tatsächlich um cachefähige Anfragen handelt.

Vorsignierte Anfragen beschreibt der Leitfaden anders. Sie werden nicht unter einem bloß ungünstigen Schlüssel gespeichert; sie werden nicht gespeichert. Dieselbe vorsignierte URL wiederholt zu verwenden begründet deshalb keinen Spaces-CDN-Treffer entgegen dieser Regel.

Auch eine längere TTL ist keine nachgewiesene Abhilfe. Die gewöhnliche Einstellung regelt, wie lange zugelassene Inhalte vor einer Aktualisierung im Cache bleiben. Sie ist nicht als Schalter dokumentiert, der eine ausgeschlossene Anfrageklasse zulässt. Schlüsselzerstückelung und Cache-Umgehung erfordern unterschiedliche Diagnosen.

Die Aussage muss zugleich auf ihren Belegumfang begrenzt bleiben. Es geht um das Spaces CDN, nicht um sämtliche Browser, Vermittler oder S3-kompatiblen Dienste. Eine getrennte Architektur müsste Zugriff, Aktualisierung und Invalidierung selbst überprüfen. Ein allgemeines Verbot jeglicher Zwischenspeicherung ist aus diesen Unterlagen nicht ableitbar.

Die unterstützte URL hat eigene Bedingungen

DigitalOcean beschreibt folgenden Ablauf: Die vorsignierte GetObject-URL wird zunächst für den Nicht-CDN-Endpunkt erzeugt; danach wird der Hostname durch den CDN- oder eigenen Namen ersetzt. Unterstützt ist der virtuelle Hoststil, bei dem der Bucketname im Hostnamen steht. Beim Pfadstil, beispielsweise mit aktiviertem forcePathStyle, funktioniert diese Nutzung des CDN-Hostnamens nicht.

Das sind Bedingungen für eine unterstützte Adresse. Sie versprechen keine Cache-Beschleunigung signierter Anfragen. Die Prüfung der SDK-Konfiguration darf daher nicht gleichzeitig als Beleg für eine bestimmte Auslieferungsleistung gelten.

Eine weitere Grenze betrifft die Speicherklasse. Spaces Cold Storage unterstützt weder CDN-Integration noch eigene CDN-Endpunkte. Der hier behandelte Pfad gehört zur unterstützten Standard-Storage-Konfiguration. Ein Wechsel zu günstigerem Speicher erhält die Auslieferungsbedingungen nicht automatisch.

Für die Architekturprüfung müssen keine aktiven Signaturen veröffentlicht werden. Beauftragte Messungen sollten autorisiertes Testmaterial verwenden und tatsächlich zugriffsgewährende Kundenlinks aus gemeinsamen Berichten heraushalten. Schon die Einordnung der Anfrage klärt eine wesentliche Annahme.

Enthalten bleibt messbar

Die Preisseite von Spaces nennt monatlich 5 US-Dollar für Standard Storage, einschließlich 250 GiB Speicher und 1.024 GiB ausgehendem Transfer, den die Buckets gemeinsam nutzen. Zusätzlicher ausgehender Transfer kostet 0,01 US-Dollar je GiB. Ursprung und CDN verwenden dasselbe Kontingent; Transfer vom Ursprung zu Randservern wird ebenfalls angerechnet.

Das CDN verursacht somit keine gesonderte Zusatzgebühr, aber die Byte-Messung bleibt bestehen. Ein Budget für vorsignierte Downloads darf wiederholte Nachfrage nicht vorab als Cache-Treffer des Spaces CDN abziehen. Relevant sind ausgelieferte Daten, gemessene Routen und die übrige Nutzung des gemeinsamen Kontingents.

Umgekehrt beweisen die Regeln keinen universell doppelten Preis pro signiertem Download. Dafür wären konkrete Mengen, Größen und Abrechnungsdaten erforderlich. Mögliche Wegabschnitte ohne Messung zusammenzuzählen würde eine Annahme in einen angeblichen Rechnungsbefund verwandeln.

Privater Spaces-Verkehr über den VPC-lokalen DNS-Resolver ist auf der Preisseite eine gesonderte Routingbedingung. Ein geschütztes Objekt oder eine signierte URL weist diese interne Route nicht allein durch seine Zugriffsbeschränkung nach. „Privat“ als Zugriffseigenschaft und „privat“ als Netzwerkpfad dürfen nicht zu einer einzigen Kostenbehauptung verschmelzen.

Die gekaufte Leistung richtig benennen

Die Dokumentation liefert einen belastbaren, begrenzten Schluss: Bei diesem signierten Pfad bleiben Ursprungseinbindung und Transferprüfung relevant. Sie liefert keinen beobachteten Kundenausfall, keinen Leistungsvergleich und keine Erklärung einer verborgenen Anbieterabsicht.

Das bestehende Angebot kann Anforderungen durchaus erfüllen. Die Beschaffungsdisziplin besteht darin, diese Anforderungen mit der tatsächlichen Anfrageklasse zu vergleichen. Eine beständige Domain ist ein wirklicher Nutzen; eine Cache-Kopie muss als zusätzliche Eigenschaft nachgewiesen werden, statt aus dem Namen mitgekauft zu werden.

Quellen