Les métadonnées et les balises sont toutes deux essentiellement des "métadonnées", mais il existe des différences importantes dans la manière dont elles peuvent (ou ne peuvent pas) être utilisées pour modifier le comportement du service et dans la manière dont leurs valeurs peuvent (ou ne peuvent pas) être consultées.
Un objet dans S3, y compris ses métadonnées, est -- à proprement parler -- immuable. La console vous donne la possibilité de "modifier" les métadonnées, mais ce n'est pas une description précise de ce qui se passe. Lorsque vous modifiez les métadonnées d'un objet, vous écrasez en fait l'objet avec une copie de lui-même, avec ses métadonnées modifiées. Si le seau est versionné, vous avez maintenant deux copies de l'objet avec deux dates différentes et des métadonnées modifiées.
Les balises sont une "sous-ressource" - dans un sens, "à côté" d'un objet - elles sont gérées séparément et peuvent être modifiées sans modifier l'objet lui-même.
Les métadonnées sont incluses dans le PUT comme en-têtes HTTP lors de la création de l'objet. Les étiquettes sont stockées en envoyant une deuxième demande. La prise en charge complète des balises jusqu'aux limites de nombre et de taille, ci-dessous, nécessite l'envoi d'une deuxième requête à l'interface utilisateur de l'utilisateur. ?tagging sur le point de terminaison de l'API, mais la sous-ressource PUT (Object) REST offre également une prise en charge limitée des balises, permettant de soumettre jusqu'à 2K de clés et de valeurs de balises codées en url, de type paramètre de requête, dans un seul appel REST. x-amz-tagging HTTP PUT l'en-tête de la demande. Par exemple, x-amz-tagging: hipaa_restrict=false&pci_restrict=true&owner=Accounting%20and%20Payroll . La documentation n'indique pas clairement si le 2K comprend la longueur d'octet du nom de l'en-tête, lui-même, ou si ce 2K est le même 2K que celui de l'en-tête de l'article. x-amz-meta-* balises de métadonnées de l'utilisateur. Il s'agit probablement de deux limites différentes de 2K, mais la limite de 2K pour les balises inclut probablement la forme codée en url des clés et des valeurs, ainsi que la longueur de l'en-tête.
Vous pouvez contrôler, séparément via une politique, si un utilisateur IAM peut lire ou écrire des objets + métadonnées ou des balises. Les objets et les métadonnées sont traités ensemble dans les autorisations (si vous pouvez faire l'un, vous pouvez toujours faire l'autre), mais les étiquettes sont des autorisations distinctes.
Quand vous GET un objet, les métadonnées réelles sont renvoyées dans les en-têtes de la réponse HTTP. Cela signifie qu'un utilisateur qui télécharge un objet peut voir les métadonnées s'il sait comment inspecter les en-têtes HTTP.
À l'inverse, les balises ne sont pas renvoyées dans les en-têtes en réponse à un message de type GET au lieu de cela, seul le x-amz-tagging-count: est retourné, indiquant le nombre de balises sur l'objet s'il est différent de zéro. Notez, cependant, que si les balises sont plus appropriées pour le stockage de l'objet propriétaire ils ne sont pas appropriés pour le stockage de données non cryptées. sensible données.
Le total de toutes les clés et valeurs de métadonnées pour chaque objet est le suivant limité à 2KB . Notez que la limite est exprimée en octets, de sorte que les caractères multi-octets consomment plus d'un octet par caractère vers la limite. Il n'y a pas de limite au nombre de clés de métadonnées -- seulement la limite totale de 2KB pour les métadonnées de l'utilisateur. Seuls les caractères US-ASCII sont entièrement pris en charge dans les clés et les valeurs des métadonnées des objets. et les métadonnées doivent être composées de caractères valides en tant qu'en-têtes HTTP, puisque c'est ainsi que les métadonnées des objets sont envoyées.
El les limites sur les étiquettes sont différentes . Chaque objet peut avoir jusqu'à 10 étiquettes, chaque clé d'étiquette est limitée à 128. caractères (et non des octets), et chaque valeur de balise est limitée à 256 caractères (pas d'octets), bien que les limites soient plus basses, comme indiqué ci-dessus, lorsque les balises accompagnent l'élément PUT demande. Contrairement aux métadonnées, les balises supportent UTF-8.
Les clés et les valeurs des métadonnées sont comptées comme des octets facturables contribuant à la taille facturée du stockage des objets. Les étiquettes sont facturées séparément avec une formule différente.
Ni les balises ni les métadonnées ne peuvent être utilisées pour "scanner" les objets. Il n'est pas possible de demander au service S3 une liste d'objets avec des balises ou des métadonnées spécifiques.
Les balises peuvent être utilisées pour modifier le comportement du service d'au moins deux façons importantes que les métadonnées ne peuvent pas (et, en fait, il y en a peut-être d'autres auxquelles je ne pense pas pour le moment) :
Les politiques IAM sur les buckets/utilisateurs/rôles peuvent tester les valeurs des tags à des fins de contrôle d'accès, mais ne peuvent pas tester les valeurs des métadonnées.
Il existe une politique IAM clés de condition qui permettent de contrôler l'accès aux objets sur la base de tags . Il n'existe pas de fonctions de contrôle d'accès similaires basées sur les métadonnées.
Les politiques de cycle de vie des buckets peuvent tester les valeurs des tags mais pas celles des métadonnées.
Politiques de cycle de vie peut être utilisé pour modifier la classe de stockage d'un objet (en standard/infréquenté ou glacier) ou purger les objets ou les versions après un intervalle de temps configurable. Avant l'introduction des balises d'objet, ces règles s'appliquaient soit à l'ensemble du panier, soit à un certain préfixe, tel que images/ . Désormais, les balises permettent d'appliquer des politiques de cycle de vie sur la base des balises d'objet, de sorte que (par exemple) les données transitoires peuvent être mélangées avec les données permanentes tout en appliquant les politiques de cycle de vie différemment sans qu'il soit nécessaire de stocker les objets dans des hiérarchies de clés différentes pour la correspondance des préfixes.
Dans la situation décrite dans la question, je serais enclin à stocker ces valeurs dans les métadonnées, à moins que le fait qu'elles soient visibles dans les en-têtes de réponse HTTP ne constitue pour vous un problème de sécurité.
Si vous utilisez S3 en conjonction avec CloudFront, vous pouvez utiliser un fichier Déclencheur Lambda@Edge Origin Response pour expurger ou supprimer les métadonnées d'objet des réponses en vol afin qu'elles ne soient pas visibles pour le navigateur. Un déclencheur de réponse d'origine est une fonction Lambda écrite en Node.js qui peut modifier de manière programmatique les réponses avant qu'elles ne soient stockées dans le cache de CloudFront, ce qui signifie qu'elle ne doit être exécutée que lorsque le cache est manqué. Une fonctionnalité similaire peut également être réalisée en acheminant les requêtes vers le seau par le biais d'un serveur proxy dans EC2, tel que HAProxy ou Nginx, mais pas si le seau est accédé directement. Le service S3 renvoie toujours les métadonnées dans les en-têtes de réponse HTTP, mais il ne renvoie qu'un nombre de balises (si l'objet en possède) et non les balises elles-mêmes, lorsqu'un objet est téléchargé.
