Classi di archiviazione S3 spiegate: scegliere l'opzione giusta per il costo

Amazon Simple Storage Service (S3) è l'archivio di oggetti predefinito per molti carichi di lavoro AWS perché si adatta bene e offre diverse classi di archiviazione per diversi modelli di accesso. Tuttavia, non tutti i dati vengono acceduti allo stesso modo. Archiviare dati critici e frequentemente acceduti nella stessa classe di dati di archivio acceduti raramente può portare a spese cloud significative e non necessarie. Comprendere le sfumature tra le varie classi di archiviazione S3 è fondamentale per progettare un'architettura ottimizzata in termini di costi.

Comprendere la durabilità e la disponibilità di S3

Prima di addentrarci nelle classi, è importante definire due metriche fondamentali per S3:

• Durabilità: La probabilità che i tuoi dati rimangano intatti nel tempo. S3 è progettato per una durabilità del 99,999999999% (11 nove) nell'infrastruttura utilizzata per una determinata classe.
• Disponibilità: La percentuale di tempo in cui i tuoi dati sono accessibili per il recupero. Di solito viene misurata annualmente (ad esempio, 99,9%).

Queste metriche variano leggermente a seconda della specifica classe di archiviazione scelta.

Le classi di archiviazione S3 principali: un confronto dettagliato

AWS offre diverse classi di archiviazione ottimizzate per diverse frequenze di accesso e tolleranza ai tempi di inattività. Ecco uno sguardo dettagliato alle opzioni più comuni.

1. S3 Standard

S3 Standard è la classe di archiviazione predefinita e per uso generico, più adatta per dati acceduti frequentemente.

• Caso d'uso: Dati attivi, distribuzione di contenuti, contenuti generati dinamicamente e applicazioni mobili/di gioco.
• Durabilità: 11 nove.
• Disponibilità: 99,99% (Alta disponibilità).
• Tempo di recupero: Millisecondi.
• Prezzi: Costo di archiviazione più alto tra i livelli ad accesso frequente, ma nessuna tariffa di recupero.

Buona pratica: Usalo per dati che necessitano di accesso immediato con latenza minima.

2. S3 Intelligent-Tiering (S3-IT)

S3 Intelligent-Tiering è progettato per dati con modelli di accesso sconosciuti o mutevoli. Sposta automaticamente gli oggetti tra due o più livelli di accesso in base all'utilizzo, ottimizzando i costi di archiviazione senza sovraccarico operativo.

• Caso d'uso: Data lake, dati con modelli di accesso imprevedibili o quando si desidera garantire un accesso immediato ottimizzando i costi nel tempo.
• Come funziona: Monitora l'accesso. Se un oggetto non viene acceduto per 30 giorni consecutivi, viene spostato al livello di Accesso Infrequente (IA). Se viene acceduto di nuovo, torna al livello di Accesso Frequente.
• Livelli inclusi: Accesso Frequente, Accesso Infrequente, Accesso Istantaneo all'Archivio (opzionale).
• Fattore di costo: Include una piccola tariffa mensile di monitoraggio e automazione per oggetto, oltre ai costi di archiviazione, che cambiano in base al livello in cui risiede l'oggetto.

Suggerimento pratico: Se non sei sicuro della frequenza con cui i dati verranno acceduti, S3 Intelligent-Tiering offre spesso il miglior equilibrio tra risparmio sui costi e coerenza delle prestazioni.

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

Questa classe è ideale per dati acceduti raramente ma che richiedono un recupero rapido, simile a S3 Standard-IA, ma con una differenza sostanziale nella disponibilità.

• Caso d'uso: Backup secondari, dati ricreabili (ad esempio, dati che possono essere rigenerati da una fonte) o archiviazione di dati non sufficientemente critici per il business da giustificare la ridondanza multi-AZ.
• Durabilità: 11 nove.
• Disponibilità: 99,5% (Disponibilità inferiore rispetto a Standard).
• Posizione di archiviazione: I dati vengono archiviati in modo ridondante in una singola Zona di Disponibilità (AZ) AWS, a differenza di altre classi che si estendono su più AZ.
• Fattore di costo: Costo di archiviazione significativamente inferiore rispetto a Standard, ma il recupero dei dati comporta una tariffa.

⚠️ Avvertenza su One Zone-IA: Poiché i dati risiedono in una sola AZ, se quella specifica AZ subisce un evento catastrofico (ad esempio, un grave guasto elettrico o un disastro naturale), i tuoi dati in questo livello potrebbero andare persi. Ecco perché è fondamentale solo per dati non critici e facilmente sostituibili.

4. Classi di archiviazione S3 Glacier (Archivio)

Le classi di archiviazione Glacier sono ottimizzate per l'archiviazione a lungo termine in cui sono accettabili tempi di recupero da minuti a ore.

S3 Glacier Instant Retrieval (S3 Glacier IR)

Colma il divario tra Accesso Infrequente e archivio profondo.

• Caso d'uso: Dati acceduti una volta al trimestre o meno, ma che richiedono un recupero in millisecondi quando necessario (ad esempio, immagini mediche, archivi di media di notizie).
• Tempo di recupero: Millisecondi (latenza simile alle classi IA).
• Fattore di costo: Costo di archiviazione molto basso, con tariffe di recupero.

S3 Glacier Flexible Retrieval (Ex S3 Glacier)

Questa è un'opzione di archiviazione a lungo termine quando è accettabile un recupero da minuti a ore.

• Caso d'uso: Archivi di conformità normativa, dati di disaster recovery che vengono raramente, se non mai, necessari.
• Opzioni di recupero (e latenza):
  • Accelerato: 1–5 minuti
  • Standard: 3–5 ore
  • Massivo: 5–12 ore
• Fattore di costo: Costo di archiviazione estremamente basso, ma si applicano tariffe di recupero e richiedono tempo.

S3 Glacier Deep Archive

L'opzione di archiviazione a costo assolutamente più basso in AWS S3.

• Caso d'uso: Dati che potrebbero essere acceduti solo una o due volte all'anno, tipicamente per conformità.
• Opzioni di recupero (e latenza):
  • Standard: 12 ore
  • Massivo: 48 ore
• Fattore di costo: Tariffa di archiviazione più bassa disponibile, tariffe di recupero più alte e finestre di recupero più lunghe richieste.

Come scegliere: un quadro decisionale

La scelta della classe giusta dipende dalla risposta a tre domande chiave sul ciclo di vita dei tuoi dati:

Domanda	Considerazione primaria	Percorso di classe consigliato
Con quale frequenza viene acceduto?	Frequenza di accesso	Frequente $\rightarrow$ Standard; Poco frequente $\rightarrow$ IA o Glacier
Qual è il tempo di inattività/perdita accettabile?	Durabilità/Disponibilità	Critico $\rightarrow$ Standard/Intelligent-Tiering; Monouso $\rightarrow$ One Zone-IA
Con quale rapidità devo recuperarlo?	Requisito di latenza	Millisecondi $\rightarrow$ Standard/Intelligent-Tiering/Glacier IR; Ore $\rightarrow$ Glacier Flexible/Deep Archive

Scenario di esempio: risorse multimediali aziendali

Un team di marketing carica centinaia di file video grezzi ogni giorno:

1. Modifiche/promozioni correnti (Ultimi 30 giorni): S3 Standard (Accesso elevato, bassa latenza).
2. Risorse più vecchie che necessitano di revisione occasionale (30 giorni a 1 anno): S3 Intelligent-Tiering (Per catturare risparmi sui costi dopo il periodo iniziale di attività).
3. Master finali completati e verificati (Più vecchi di 1 anno): S3 Glacier Deep Archive (Costo più basso, necessari solo per audit di conformità).

Scenario di esempio: log, backup e caricamenti utente

Una singola azienda ha spesso tre modelli S3 molto diversi.

Per i log delle applicazioni, i dati recenti sono preziosi perché gli ingegneri li cercano durante gli incidenti. Dopo che la finestra dell'incidente è passata, la maggior parte dei log diventa dati di conformità o di tendenza. Un ciclo di vita ragionevole potrebbe mantenere da 30 a 90 giorni in Standard o Standard-IA, spostare i log più vecchi in un livello di archivio e far scadere i log di debug di basso valore dopo un periodo di conservazione fisso. I numeri esatti dovrebbero provenire dalla tua politica di conservazione e dalla frequenza con cui le persone interrogano davvero i vecchi prefissi.

Per i backup del database, la classe di archiviazione dovrebbe seguire la promessa di ripristino. Se il team afferma che un ripristino di produzione deve iniziare entro pochi minuti, mantieni i backup più recenti in una classe con recupero immediato. Le copie mensili o annuali più vecchie possono essere spostate in livelli più freddi se sono lì per la conservazione degli audit piuttosto che per un rapido ripristino. Testa i ripristini dalla classe scelta; una politica di backup che non è mai stata ripristinata è per lo più una regola di fatturazione.

Per i caricamenti utente, l'accesso è più difficile da prevedere. Una foto del profilo potrebbe essere minuscola ma recuperata costantemente. Un grande video originale potrebbe essere scaricato una volta, transcodificato e raramente toccato di nuovo. Archivia le risorse derivate e gli originali sotto prefissi separati in modo che le regole del ciclo di vita possano trattarli diversamente. Non fare in modo che la politica delle miniature erediti la stessa regola di archivio degli originali multi-gigabyte, a meno che non sia realmente ciò di cui il prodotto ha bisogno.

Domande da porsi prima di modificare un bucket

Prima di aggiungere una regola del ciclo di vita, chiediti chi legge i dati, come li legge e cosa succede se il recupero viene ritardato. Gli ingegneri spesso conoscono meglio il percorso di scrittura rispetto al percorso di lettura perché i caricamenti fanno parte dell'applicazione, mentre le letture avvengono in seguito tramite analisi, strumenti di supporto, esportazioni di conformità o risposta manuale agli incidenti.

Cerca job batch che scansionano vecchi prefissi. Un job notturno che elenca ogni oggetto, apre i metadati o campiona file vecchi può cancellare parte del risparmio derivante da una classe più fredda. Se il job necessita solo di un manifest, S3 Inventory potrebbe essere meglio che elencare ripetutamente il bucket. Se gli analisti interrogano i log con Athena, considera il layout delle partizioni e la compressione prima di spostare i dati in una classe che richiede passaggi di ripristino.

Presta attenzione alla dimensione degli oggetti. Le classi di archiviazione con dimensioni minime fatturabili degli oggetti possono essere poco adatte per un numero elevato di file minuscoli. In questi casi, compattare i dati in oggetti più grandi, utilizzare Parquet per l'analisi o far scadere oggetti non necessari può essere meglio di un cambio di classe di archiviazione.

Infine, scrivi le regole del ciclo di vita in un modo che tu possa spiegare durante un incidente. Una regola di prefisso denominata archivia-vecchi-log-dopo-90-giorni è più facile da comprendere rispetto a una regola a livello di bucket che sposta silenziosamente tutto dopo 30 giorni. L'ottimizzazione dei costi dovrebbe rendere il sistema più economico senza rendere misterioso il recupero.

Un altro controllo pratico è la proprietà. Negli account reali, il proprietario del bucket, l'account di caricamento, il ruolo di replica e l'account di analisi non sono sempre gli stessi. Prima di spostare i dati in una classe di archivio, conferma chi può ripristinarli e chi paga per il recupero. I bucket cross-account con crittografia KMS possono fallire al momento del ripristino se il ruolo che necessita dell'oggetto può elencare il bucket ma non può utilizzare la chiave. Questa è una brutta sorpresa durante un audit.

Anche il versioning cambia i calcoli. Le regole del ciclo di vita possono trasferire o far scadere le versioni correnti e non correnti in modo diverso. Se un'applicazione sovrascrive la stessa chiave ogni ora, le versioni non correnti potrebbero diventare la parte più grande del bucket. Rivedile separatamente invece di presumere che il conteggio degli oggetti correnti racconti l'intera storia.

Implementazione delle policy del ciclo di vita

Spostare manualmente gli oggetti tra le classi è inefficiente. Il modo più efficace per gestire i costi tra questi livelli è utilizzare le Policy del ciclo di vita di S3.

Le policy del ciclo di vita ti consentono di definire regole che trasferiscono automaticamente gli oggetti a livelli di archiviazione più freddi o li fanno scadere definitivamente dopo un numero definito di giorni.

Esempio di regola del ciclo di vita (transizione):

<Rule>
    <ID>Sposta_in_IA_Dopo_30_Giorni</ID>
    <Status>Abilitato</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

Questa configurazione sposta automaticamente qualsiasi oggetto nel prefisso logs/ in Glacier Instant Retrieval 30 giorni dopo la creazione, riducendo significativamente i costi di archiviazione a lungo termine mantenendo al contempo capacità di recupero rapide, se necessario.

Trappole di costo che le persone perdono

La decisione sulla classe di archiviazione non è solo un confronto mensile per GB. Le spese di recupero, le spese di richiesta, la durata minima di archiviazione, la dimensione minima fatturabile dell'oggetto, la replica, le richieste di transizione del ciclo di vita e le tariffe di monitoraggio possono cambiare la risposta. Un archivio di oggetti minuscoli con milioni di chiavi può comportarsi in modo molto diverso da un piccolo numero di file di backup di grandi dimensioni.

Ad esempio, i log delle applicazioni vengono spesso scritti una volta e letti raramente, quindi una regola del ciclo di vita da Standard a Glacier Instant Retrieval o Glacier Flexible Retrieval può avere senso. Ma se il tuo processo di incidente scansiona frequentemente i vecchi log con Athena, un'archiviazione aggressiva può creare ripristini lenti e costi di recupero a sorpresa. In tal caso, partizionare i log per data, far scadere i prefissi di basso valore rumorosi e mantenere i mesi recenti in una classe adatta alle query può far risparmiare più denaro che spostare ciecamente tutto in archivio dopo 30 giorni.

I backup hanno una forma diversa. Un dump del database che testi una volta al mese necessita di un comportamento di ripristino prevedibile. Se il tuo obiettivo del tempo di recupero è misurato in minuti, Deep Archive è probabilmente il posto sbagliato per l'unica copia ripristinabile, anche se è economico a riposo. Se lo stesso dump è la terza copia conservata solo per la conservazione degli audit, Deep Archive può essere ragionevole.

I team multimediali spesso necessitano di risorse vecchie in modo imprevedibile. Intelligent-Tiering può essere una buona opzione predefinita per quei modelli sconosciuti, specialmente quando gli oggetti sono abbastanza grandi che la tariffa di monitoraggio non è il fattore determinante. Per un gran numero di miniature minuscole, la tariffa e il comportamento della dimensione minima dell'oggetto meritano un esame più attento prima di attivarlo ovunque.

Un modo pratico per scegliere è campionare un bucket, esportare S3 Inventory, raggruppare per prefisso, conteggio oggetti, byte totali, data dell'ultima modifica e modello di accesso noto, quindi scrivere regole del ciclo di vita per prefisso. Evita una regola a livello di bucket a meno che il bucket non contenga realmente un solo tipo di dato.