Versioning, MFA Delete e replica

S3 Versioning consente di conservare, recuperare e ripristinare ogni versione di ogni oggetto archiviato in un bucket. Quando il versioning è abilitato, ogni PUT crea una nuova versione con un version ID univoco; la versione precedente viene conservata e non sovrascritta. Se un oggetto viene eliminato, S3 aggiunge un delete marker come versione corrente, mantenendo tutte le versioni precedenti. Questo protegge da sovrascritture accidentali, eliminazioni accidentali e corruzione involontaria dei dati a livello applicativo, gli scenari di perdita dei dati più comuni negli ambienti di produzione.

Un bucket S3 può trovarsi in uno dei tre stati del versioning: Unversioned (predefinito, senza version ID), Versioning-enabled (tutti i nuovi oggetti ricevono version ID univoci e tutte le sovrascritture creano nuove versioni) oppure Versioning-suspended (i nuovi oggetti ricevono un version ID null, ma le versioni esistenti vengono conservate). Non è possibile eliminare il versioning dopo averlo abilitato: è possibile solo sospenderlo. Gli oggetti creati prima dell'abilitazione del versioning hanno un version ID null e non vengono modificati finché non vengono sovrascritti o eliminati.

Per ripristinare una versione precedente di un oggetto sottoposto a versioning, sono disponibili due opzioni. Opzione 1: copi il version ID della versione precedente sulla stessa chiave; in questo modo crea una nuova versione che è una copia del contenuto precedente e la rende quella corrente. Opzione 2: elimini la versione corrente o il delete marker per rendere corrente la versione precedente. Quando si 'elimina' un oggetto in un bucket con versioning tramite la console senza specificare un version ID, S3 aggiunge un delete marker: l'oggetto appare eliminato nelle richieste senza versioning, ma tutte le versioni sono ancora presenti.

MFA Delete aggiunge un ulteriore livello di protezione per i bucket con versioning. Quando è abilitato, l'eliminazione permanente di una versione specifica o la modifica dello stato del versioning (enabled → suspended) richiede credenziali MFA valide nella richiesta API. Questo protegge da un attaccante che abbia compromesso le credenziali AWS e tenti di eliminare permanentemente versioni critiche, dall'eliminazione accidentale o automatizzata di versioni di oggetti conservate intenzionalmente e da minacce interne che tentino di distruggere i percorsi di controllo. MFA Delete può essere abilitato e disabilitato solo dall'utente root tramite la CLI.

S3 Object Lock applica un modello write-once-read-many (WORM) per la conformità normativa. Gli oggetti protetti con Object Lock non possono essere eliminati o sovrascritti durante un periodo di conservazione specificato, neppure dall'utente root dell'account. Sono disponibili due modalità: Governance mode (gli utenti con autorizzazioni speciali possono ignorare o rimuovere il blocco) e Compliance mode (nessuno, nemmeno AWS, può eliminare l'oggetto durante il periodo di conservazione: è il livello di protezione più elevato). Object Lock deve essere abilitato quando si crea il bucket e richiede il versioning.

Cross-Region Replication (CRR) replica automaticamente i nuovi oggetti e gli aggiornamenti da un bucket di origine in una Region a un bucket di destinazione in una Region diversa. Casi d'uso: conformità (conservare una copia dei dati in un paese specifico), disaster recovery (ridurre l'RPO per i dati critici mantenendo una copia in una seconda Region) e riduzione della latenza (distribuire gli oggetti dalla Region più vicina agli utenti). CRR richiede il versioning abilitato sia sul bucket di origine sia su quello di destinazione, oltre a un ruolo IAM con le autorizzazioni di replica necessarie.

Same-Region Replication (SRR) replica gli oggetti all'interno della stessa Region. Casi d'uso: aggregazione dei log (replicare i log da più bucket di origine in un unico bucket centrale), sincronizzazione degli ambienti di test (mantenere una copia dei dati di produzione in un bucket di sviluppo nella stessa Region) e conformità alla sovranità dei dati all'interno di un singolo paese con più AZ AWS. Come CRR, SRR richiede il versioning su entrambi i bucket e un ruolo IAM. Solo i nuovi oggetti creati dopo l'abilitazione della replica vengono replicati automaticamente: per replicare gli oggetti esistenti, utilizzi S3 Batch Replication.

La replica S3 replica: nuovi oggetti, metadati, tag, ACL e stato della crittografia. Per impostazione predefinita, la replica non replica: gli oggetti esistenti prima dell'abilitazione della replica (utilizzi S3 Batch Replication per questi oggetti), i delete marker (a meno che non abiliti Delete Marker Replication), gli oggetti in Glacier (non replicabili: devono prima essere ripristinati) e gli oggetti replicati (non è prevista una replica a cascata tra tre bucket). Comprendere questi limiti è importante per progettare strategie DR complete, in cui devono essere replicati anche i dati storici e gli eventi di eliminazione.

Replication Time Control (RTC) è un componente aggiuntivo opzionale per CRR che fornisce uno Service Level Agreement: il 99,99% degli oggetti viene replicato entro 15 minuti, con metriche di replica e notifiche in CloudWatch. Senza RTC, la replica non offre alcuna garanzia sui tempi: la maggior parte degli oggetti viene replicata rapidamente, ma per alcuni casi possono essere necessarie ore. RTC è essenziale quando i requisiti di DR o conformità specificano un Recovery Point Objective (RPO) massimo per i dati in S3. Prevede un costo di replica per GB, aggiuntivo rispetto al normale costo di trasferimento dei dati della replica.

L'attivazione del versioning aumenta i costi di archiviazione perché S3 conserva ogni versione di ogni oggetto finché non viene eliminata esplicitamente. Un file da 100 MB sovrascritto 10 volte occupa ora 1.000 MB di spazio di archiviazione. Per ridurre questo impatto, utilizzi regole del ciclo di vita che facciano scadere automaticamente le versioni non correnti dopo un numero prestabilito di giorni (ad esempio, eliminando le versioni non correnti più vecchie di 30 giorni) oppure che spostino le versioni non correnti verso classi di archiviazione più economiche, come Glacier. In produzione, associ sempre il versioning alle regole del ciclo di vita per tenere sotto controllo i costi di archiviazione.

Il versioning di S3 combinato con Object Lock (modalità Compliance) offre una solida protezione dal ransomware. Se un aggressore crittografa o elimina i Suoi oggetti, il versioning garantisce la conservazione delle versioni precedenti (a meno che l'aggressore non le elimini definitivamente: per questo Object Lock impedisce l'eliminazione definitiva durante il periodo di conservazione). Per ottenere la massima protezione: attivi il versioning, attivi MFA Delete, applichi Object Lock in modalità Compliance ai dati critici e replichi i dati in una seconda Regione con credenziali IAM separate, così da impedire che la compromissione di un singolo account distrugga tutte le copie.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: il versioning conserva tutte le versioni di ogni oggetto e protegge dalle eliminazioni accidentali, MFA Delete e Object Lock offrono un'immutabilità aggiuntiva per la conformità e la protezione dal ransomware e CRR e SRR replicano gli oggetti in altri bucket per soddisfare i requisiti di DR e conformità. Ora esamineremo le classi di archiviazione S3 e le policy del ciclo di vita per ottimizzare i costi.