Unterschied zwischen Objekttags und Objektmetadaten?

Sowohl Metadaten als auch Tags sind im Wesentlichen "Metadaten", aber es gibt wichtige Unterschiede darin, wie sie verwendet werden können (oder nicht), um das Verhalten des Service zu ändern und wie auf deren Werte zugegriffen werden kann (oder nicht).

Ein Objekt in S3 einschließlich seiner Metadaten ist - streng genommen - unveränderlich. Die Konsole gibt Ihnen die Möglichkeit, Metadaten zu "bearbeiten", aber das ist keine genaue Beschreibung dessen, was passiert. Wenn Sie die Metadaten eines Objekts bearbeiten, überschreiben Sie das Objekt tatsächlich mit einer Kopie von sich selbst, wobei die Metadaten geändert werden. Wenn der Bucket versioniert ist, haben Sie jetzt zwei Kopien des Objekts mit zwei verschiedenen Daten und modifizierten Metadaten.

Tags sind eine "Unterresource" - gewissermaßen "von der Seite" eines Objekts - sie werden separat verwaltet und können geändert werden, ohne das Objekt selbst zu verändern.

Metadaten sind in der PUT -Anforderung als HTTP-Header enthalten, wenn das Objekt erstellt wird. Tags werden gespeichert, indem eine zweite Anfrage gesendet wird. Die vollständige Unterstützung von Tags bis zu den unten angegebenen Anzahl- und Größenbeschränkungen erfordert das Senden einer zweiten Anfrage an die ?tagging -Unterresource auf dem API-Endpunkt, aber die% co_de Der Aufruf von% (Object) REST hat auch eingeschränkte Unterstützung für Tags. Damit können bis zu 2K URL-codierte Tag-Schlüssel im Abfrageparameter-Stil und Werte in einem einzigen PUT HTTP x-amz-tagging -Anforderungsheader übergeben werden. Zum Beispiel PUT . Die Dokumentation ist unklar in Bezug darauf, ob die 2K die Byte-Länge des Header-Namens selbst enthält oder ob diese 2K die gleichen 2K ist wie die Metadaten-Tags x-amz-tagging: hipaa_restrict=false&pci_restrict=true&owner=Accounting%20and%20Payroll des Benutzers. Vermutlich sind es zwei verschiedene 2K-Limits, aber die 2K-Tag-Grenze umfasst wahrscheinlich die URL-codierte Form der Schlüssel und Werte sowie die Länge des Headers.

Sie können separat über Richtlinien steuern, ob ein IAM-Benutzer Objekte + Metadaten oder Tags lesen oder schreiben kann. Objekte und Metadaten werden zusammen in Berechtigungen gehandhabt (wenn Sie einen tun können, können Sie immer zum anderen), aber Tags sind separate Berechtigungen.

Wenn Sie x-amz-meta-* für ein Objekt angeben, werden die tatsächlichen Metadaten in den HTTP-Antwortheadern zurückgegeben. Dies bedeutet, dass ein Benutzer, der ein Objekt herunterlädt, die Metadaten sehen kann, wenn er weiß, wie er die HTTP-Header prüft.

Umgekehrt werden Tags in den Headern nicht als Antwort auf eine GET -Anforderung zurückgegeben; Stattdessen wird nur der Header GET zurückgegeben, der die Anzahl der Tags für das Objekt angibt, wenn es nicht null ist. Beachten Sie jedoch, dass Tags zwar besser zum Speichern proprietärer -Daten geeignet sind, aber nicht zum Speichern unverschlüsselter sensitiver -Daten.

Die Summe aller Metadatenschlüssel und -werte für jedes Objekt ist auf 2 KB begrenzt . Beachten Sie, dass das Limit in Bytes ausgedrückt wird, sodass Multibyte-Zeichen mehr als ein Byte pro Zeichen in Richtung des Limits verbrauchen. Es gibt keine Begrenzung für die Anzahl der Metadatenschlüssel - nur das Gesamtlimit von 2 KB für Benutzermetadaten.

Die Beschränkungen für Tags sind unterschiedlich . Jedes Objekt kann bis zu 10 Tags haben, jeder Tag-Schlüssel ist auf 128 Zeichen (keine Bytes) begrenzt, und jeder Tag-Wert ist auf 256 Zeichen begrenzt (nicht Bytes), obwohl die Grenzen niedriger sind, wie oben erwähnt, wenn die Tags mit der x-amz-tagging-count: -Anforderung mitfahren.

Metadatenschlüssel und -werte werden als abrechenbare Bytes gezählt, die zur abgerechneten Größe des Objektspeichers beitragen. Tags werden separat mit einem anderen Forum berechnet.

Weder Tags noch Metadaten können zum "Scannen" von Objekten verwendet werden. Es ist nicht möglich, den S3-Dienst nach einer Liste von Objekten mit bestimmten Tags oder bestimmten Metadaten zu fragen.

Tags können verwendet werden, um das Verhalten des Dienstes auf mindestens zwei wichtige Arten zu ändern, die Metadaten nicht können (und tatsächlich können hier andere sein, an die ich gerade nicht denke):

IAM-Richtlinien für Buckets / Benutzer / Rollen können Tag-Werte für Zugriffssteuerungszwecke testen, können aber keine Metadatenwerte testen.

Es gibt IAM-Richtlinien Bedingungsschlüssel die Zugriffssteuerung für Objekte erlauben basierend auf Tags . Es gibt keine ähnlichen Zugriffssteuerungsfunktionen, die auf Metadaten basieren.

Bucket-Lebenszyklusrichtlinien können Tag-Werte, aber keine Metadatenwerte testen.

Lebenszyklusrichtlinien können zum Ändern der Speicherklasse eines Objekts verwendet werden (nach Standard / seltenem Zugriff oder Gletscher) oder Säuberung von Objekten oder Versionen nach einem konfigurierbaren Zeitintervall. Vor der Einführung von Objekttags wurden diese Regeln entweder auf den gesamten Bucket oder auf ein bestimmtes Präfix angewendet, z. B. PUT .Mit Tags können Lebenszyklusrichtlinien nun basierend auf Objekttags angewendet werden. So können beispielsweise temporäre Daten mit permanenten Daten gemischt werden, während Lebenszyklusrichtlinien unterschiedlich angewendet werden, ohne dass die Objekte in verschiedenen Schlüsselhierarchien für die Präfixanpassung gespeichert werden müssen.

In der in der Frage beschriebenen Situation wäre ich geneigt, diese Werte in Metadaten zu speichern, es sei denn, die Tatsache, dass sie in HTTP-Antwortheadern sichtbar sind, wird von Ihnen als Sicherheitsproblem angesehen.

Mit der bevorstehenden Verfügbarkeit von Lambda @ Edge sollte es möglich sein, über eine CloudFront-Integration Metadaten aus den Antwortheadern zu redizieren, falls dies gewünscht wird. Im Moment kann dies nur erreicht werden, indem Anfragen über einen Proxy-Server in EC2 wie HAProxy oder Nginx an den Bucket weitergeleitet werden. Der S3-Dienst gibt immer die Metadaten in den HTTP-Antwortheadern zurück, aber nur eine Anzahl von Tags, nicht die Tags selbst.