Risorse cloud senza proprietario: un inventario con tag prima di decidere cosa spegnere

Parliamo del tuo progetto →

Una risorsa cloud poco usata non è automaticamente inutile. Prima di spegnere o rimuovere qualcosa, serve un inventario che dica chi la usa, perché esiste e quali dipendenze potrebbe ancora avere.

AWS descrive i tag come metadati applicabili a molte risorse e utili per classificare, cercare e governare l’ambiente. Questa guida traduce quel principio in un metodo operativo: prima si chiariscono ownership e scopo, poi si decide se mantenere, approfondire o dismettere.

Perché partire dai tag

Nel linguaggio AWS, i tag sono coppie chiave-valore che aiutano a distinguere le risorse per scopo, team, ambiente o altri criteri di business. La documentazione li collega a usi pratici come monitoraggio dei costi, gestione operativa, controllo degli accessi e automazione amministrativa.

Per un team che eredita risorse senza un proprietario chiaro, questo cambia il punto di partenza. Non si parte dalla domanda “quanto costa?”, ma da “chi ne risponde?” e “a cosa serve davvero?”. Solo dopo si valuta se la risorsa è attiva, da approfondire o da dismettere.

Preparare una lista leggibile

Prerequisiti

accesso autorizzato a un perimetro limitato dell’account o degli account AWS;
inventario esportabile delle risorse del perimetro scelto;
convenzione minima sui tag da usare;
un referente capace di confermare uso, vincoli e dipendenze.

Procedura proposta da Dedaloop

Esporta un inventario ristretto e controllabile, non l’intero ambiente.
Per ogni risorsa annota identificativo, servizio, ambiente, proprietario e scopo dichiarato.
Applica pochi tag coerenti, per esempio owner, environment e service, con valori concordati.
Se un valore manca, marca la voce come “da verificare”, non come “da spegnere”.
Raccogli conferme da chi conosce il contesto applicativo o operativo.

Questa è una procedura editoriale, non una regola testuale di AWS. L’obiettivo è ridurre l’ambiguità prima di prendere decisioni irreversibili.

Tre esiti possibili

Una volta costruita la lista, ogni voce dovrebbe cadere in uno di questi stati:

Uso confermato: il proprietario conferma che la risorsa serve ancora.
Approfondimento necessario: mancano informazioni o ci sono dubbi sulle dipendenze.
Candidata alla dismissione: non emergono più usi attivi, ma servono verifiche finali.

Per il terzo gruppo non basta osservare l’ultimo periodo di attività o il costo recente. Una risorsa apparentemente ferma potrebbe sostenere un test periodico, una procedura di emergenza o un processo poco visibile. Prima della dismissione vanno elencati dipendenze, dati conservati, finestre di utilizzo e vincoli di compliance.

Dall’inventario alla decisione

Esempio simulato: un volume EBS risulta associato a un ambiente di test che non compare più tra i progetti correnti.

Prima di spegnerlo, le domande da fare sono semplici:

chi conferma che i dati non servano più?
esistono vincoli di conservazione o audit?
il volume è richiamato da script, backup o processi notturni?
ci sono riferimenti in documenti, ticket o runbook?

L’output atteso non è subito una cancellazione, ma uno stato documentato, il nome del referente, la data della verifica, le dipendenze note e la decisione finale con motivazione.

L’esempio è didattico: non descrive un caso reale del progetto, ma una sequenza di controllo ripetibile.

Controlli di accettazione

Per capire se il processo funziona, controlla questi elementi:

quante risorse hanno un proprietario verificato;
quante restano senza scopo dichiarato;
quante voci passano da “da verificare” a una decisione documentata;
chi approva la dismissione e quando;
se i tag usati sono coerenti tra team e ambienti.

Il controllo può essere fatto dal team cloud o operations al termine del censimento, e poi di nuovo prima di ogni dismissione. Se i tag influenzano permessi, policy o automazioni, la loro modifica è una modifica operativa: va trattata con approvazione e tracciabilità.

Limiti e attenzione pratica

AWS raccomanda di non inserire nei tag dati sensibili o informazioni personali non necessarie. È un limite importante: i tag devono aiutare la governance, non creare un archivio parallelo di segreti o PII. Inoltre, le tag policy e gli strumenti di governance aiutano a standardizzare, ma non eliminano la necessità di un controllo umano sui casi dubbi.

Il punto più utile, per una PMI o per un team IT snello, non è inventare una tassonomia enorme. È rendere obbligatori due dati al momento della creazione: proprietario e scopo. Se questi due campi mancano, la risorsa entra subito in una zona da verificare, invece di diventare una risorsa senza padrone che si ritrova mesi dopo in un inventario da ripulire.

Se vuoi, il passo successivo è descrivere il processo che vuoi migliorare: da lì si può trasformare questa traccia in una checklist operativa per inventario, tagging e revisione prima della dismissione.