Dal 5 ottobre 2026, Amazon EC2 permette ai proprietari di AMI di condividere tag specifici con altri account AWS tramite il prefisso ec2:SharedTag/, eliminando la necessità di workflow di replica manuale.
L'annuncio del 5 ottobre 2026 introduce una funzionalità che risolve un limite storico di Amazon EC2: l'impossibilità di trasferire i metadati dei tag insieme alle Amazon Machine Images (AMI), ovvero le immagini preconfigurate di sistemi operativi e software. In precedenza, quando un'immagine veniva condivisa con un altro account AWS, i tag associati rimanevano confinati nell'account del proprietario. Questo costringeva le organizzazioni a implementare sistemi complessi per replicare le informazioni, come l'uso di Amazon SNS e AWS Lambda, per copiare i tag in ogni account di destinazione dopo ogni pubblicazione di una nuova immagine. [1][2]
L'impatto principale per chi gestisce infrastrutture multi-account è l'eliminazione del carico operativo legato alla manutenzione di questi workflow di replica. Ora, i tag selezionati vengono condivisi automaticamente insieme all'AMI, indipendentemente dal fatto che la condivisione avvenga verso un singolo account, all'interno di un'intera organizzazione o rendendo l'immagine pubblica. Questo significa che le informazioni critiche, come lo stato di approvazione di un'immagine o la versione del sistema operativo, sono immediatamente disponibili per l'account ricevente senza interventi manuali o script di automazione aggiuntivi. [1][2]
Il funzionamento tecnico si basa sull'introduzione di una convenzione di denominazione specifica: per rendere un tag visibile agli account riceventi, il proprietario dell'AMI deve aggiungere il prefisso 'ec2:SharedTag/' alla chiave del tag. Qualsiasi tag che inizi con questa stringa viene automaticamente trattato come condiviso. Ad esempio, se un amministratore desidera segnalare che un'immagine è approvata per la produzione, creerà un tag con chiave 'ec2:SharedTag/status' e valore 'approved'. I tag che non presentano questo prefisso rimangono invece privati e visibili solo all'interno dell'account che ha creato l'immagine. [1][2]
Un aspetto cruciale riguarda la gestione dei permessi e delle quote. I tag condivisi sono rigorosamente in sola lettura per gli account che ricevono l'AMI; solo il proprietario originale ha l'autorità di creare, modificare o eliminare questi metadati. Dal punto di vista delle risorse, questi tag gravano esclusivamente sulla quota di 50 tag per risorsa del proprietario. Gli account riceventi non vedono ridotto il proprio limite di tag, potendo continuare ad aggiungere i propri tag privati all'immagine condivisa senza interferire con quelli impostati dall'owner. [1][2]
Processo di propagazione dei metadati tra account AWS
Questa funzionalità è particolarmente utile per i team di FinOps, sicurezza e governance che utilizzano l'Attribute-Based Access Control (ABAC), un sistema dove l'accesso alle risorse è regolato dagli attributi (tag) assegnati. In un contesto aziendale, un account centrale di 'Build Factory' può pubblicare immagini standardizzate e taggarle con versioni di patch o livelli di conformità. Gli account dei singoli dipartimenti possono quindi impostare policy IAM che permettono il lancio di istanze EC2 solo se l'AMI possiede il tag 'ec2:SharedTag/status' con valore 'approved', garantendo che nessuno utilizzi immagini non validate. [2]
Consideriamo un esempio illustrativo: un'azienda con 100 account di workload desidera che ogni istanza utilizzi solo immagini con kernel aggiornato. Invece di lanciare 100 funzioni Lambda per aggiornare i tag in ogni account, l'amministratore centrale crea l'AMI e applica il tag 'ec2:SharedTag/kernel-version' con valore '2026-10'. Il criterio di verifica per l'adozione consiste nel controllare se l'account ricevente ha policy di lancio basate su tag; se sì, l'adozione di questa funzione elimina il rischio di 'tag drift', ovvero la situazione in cui alcuni account non ricevono l'aggiornamento del tag a causa di fallimenti nelle chiamate API o throttling. [2]
L'implementazione può avvenire sia durante la creazione dell'immagine che in un secondo momento. Utilizzando l'interfaccia a riga di comando (CLI), è possibile applicare tag condivisi durante il comando 'create-image' tramite il parametro '--tag-specifications'. Se l'immagine esiste già, si utilizza 'create-tags' specificando la risorsa AMI e la chiave con il prefisso richiesto. Per monitorare quali immagini possiedono tag condivisi, l'amministratore può filtrare i risultati del comando 'describe-tags' o 'describe-images' cercando specificamente le chiavi che iniziano con 'ec2:SharedTag/*'. [2]
Per interrompere la condivisione di un metadato specifico, il proprietario deve semplicemente eliminare il tag con il prefisso 'ec2:SharedTag/'. Se l'obiettivo è trasformare un tag condiviso in un tag privato, l'operazione richiede l'eliminazione del tag originale e la successiva ricreazione della chiave senza il prefisso. Inoltre, quando un'AMI con tag condivisi viene copiata, questi vengono trasferiti alla nuova immagine a condizione che venga incluso il parametro '--copy-image-tags' durante l'operazione di copia, mantenendo così la continuità dei metadati tra le versioni dell'immagine. [2]
Nonostante l'automazione, l'adozione di questa funzione introduce una dipendenza fiduciaria tra l'account ricevente e il proprietario dell'AMI. Poiché i tag condivisi sono in sola lettura per chi riceve l'immagine, l'account di destinazione non può modificare i valori su cui si basano le proprie policy di sicurezza. Se un proprietario di AMI dovesse cambiare erroneamente un valore di tag, potrebbe inavvertitamente bloccare il lancio di tutte le istanze negli account dipendenti o, peggio, permettere il lancio di immagini non sicure se la policy si basa su un valore che il proprietario ha modificato senza coordinamento. [2]
Per mitigare questi rischi, AWS suggerisce di applicare una governance a livello di account per consumare AMI solo da provider fidati. Una strategia efficace consiste nell'utilizzare la funzione 'Allowed AMIs', che permette di definire criteri rigorosi, come una lista di ID account provider autorizzati, per filtrare quali immagini siano effettivamente scopribili e lanciabili. Questo approccio combina la comodità dei tag condivisi con un controllo granulare sull'origine delle risorse, evitando che tag apparentemente validi provenienti da account non autorizzati possano ingannare i sistemi di automazione. [2]
La funzionalità di condivisione dei tag per le AMI è stata resa disponibile in tutte le regioni AWS. Non comporta costi aggiuntivi per l'attivazione o per l'utilizzo, rendendola un aggiornamento puramente operativo per chi già utilizza il servizio EC2. Al momento del lancio, il supporto per la condivisione dei tag è limitato specificamente alle risorse di tipo AMI; non è specificata la disponibilità per altri tipi di risorse EC2 o servizi correlati, pertanto l'automazione basata su tag per altri componenti dell'infrastruttura deve continuare a seguire i metodi di gestione tradizionali. [1][2]
In sintesi, l'adozione di questa funzione è consigliata per le organizzazioni che gestiscono un numero elevato di account e che hanno implementato pipeline di build centralizzate. Chi opera in un singolo account o con pochissime immagini condivise potrebbe non riscontrare un beneficio immediato, poiché il carico di gestione manuale dei tag sarebbe minimo. Tuttavia, per chi combatte contro il throttling delle API di 'CreateTags' durante i picchi di pubblicazione di immagini, il passaggio a questo sistema nativo rappresenta un miglioramento significativo della stabilità del sistema di deployment. [2]
Apple introduce nuovi asset visivi per header di pagina e risultati di ricerca, insieme all'Asset Library e a un tool di anteprima in App Store Connect per migliorare la visibilità di app e giochi.
Dal 5 ottobre 2026, Amazon Redshift permette di creare viste materializzate basate su Apache Iceberg, rendendo i risultati di join e aggregazioni pesanti accessibili a qualsiasi motore compatibile con Iceberg via AWS Glue.
Analisi dell'aggiornamento SmartThings del 6 ottobre 2026: l'introduzione di SmartThings Now per l'interfaccia, l'evoluzione del controllo locale per ridurre la latenza e l'estensione del supporto Matter 1.6.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.