Amazon SOA-C02: Archiviazione e gestione dei dati — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fa parte della AWS SysOps Administrator Associate SOA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Lo Storage e la gestione dei dati coprono la progettazione, la gestione e l’ottimizzazione dello storage a oggetti, a blocchi e di file in AWS per soddisfare i requisiti di disponibilità, costo e prestazioni. Include policy di lifecycle, crittografia e controlli di accesso, strategie di backup/snapshot e la selezione delle classi di storage o dei file system appropriati in base ai pattern di accesso. L’importanza operativa risiede nel controllo dei costi, nella garanzia della recuperabilità e nel rispetto degli SLA di prestazione, applicando al contempo sicurezza e conformità.

Lifecycle degli oggetti S3, versioning e classi di storage

S3 è uno storage a oggetti con un ricco set di classi di storage (STANDARD, INTELLIGENT_TIERING, STANDARD_IA, ONEZONE_IA, GLACIER_INSTANT_RETRIEVAL, GLACIER_FLEXIBLE_RETRIEVAL, DEEP_ARCHIVE) ottimizzate per diverse frequenze di accesso, latenze di recupero e resilienza. Scegli le classi in base al pattern di accesso (frequente vs infrequente), al tempo di recupero richiesto e alla durabilità cross-AZ. Usa le regole di lifecycle (dalla console o con

undefined

) per trasferire automaticamente gli oggetti; basa le transizioni sull’età dell’oggetto, sui tag o sul prefisso. Intelligent-Tiering elimina la necessità di fare ipotesi per pattern sconosciuti o variabili, ma comporta costi di monitoraggio; Standard-IA offre un costo di storage inferiore ma prevede un costo di recupero per GB e una durata minima di archiviazione.

Il versioning deve essere abilitato per i bucket critici (

undefined

). Con il versioning puoi conservare la cronologia degli oggetti, recuperare da eliminazioni accidentali e sfruttare S3 Object Lock (governance/compliance) e MFA Delete per una protezione più rigorosa. Le regole di lifecycle possono far scadere le versioni non correnti o ripulire i delete marker; testa le regole di lifecycle su un bucket di staging per evitare eliminazioni involontarie. Per i controlli di accesso, combina policy di bucket, policy IAM e S3 Block Public Access; preferisci SSE-KMS per l’auditabilità (SSE-KMS utilizza le CMK di KMS e produce log su CloudTrail per l’utilizzo delle chiavi) o SSE-S3 quando hai bisogno di una semplice crittografia lato server senza KMS.

Volumi EBS, gestione degli snapshot e prestazioni

EBS è uno storage a blocchi collegato alle istanze EC2 e fornisce tipi di volume mirati a costo e prestazioni: gp3/gp2 (general purpose SSD), io1/io2 (provisioned IOPS SSD), st1/sc1 (throughput-optimized HDD / cold HDD). Seleziona gp3 per disaccoppiare IOPS e throughput dalla dimensione (usa

undefined

per impostare IOPS/throughput). Monitora le metriche di CloudWatch VolumeReadOps, VolumeWriteOps, VolumeThroughput e VolumeQueueLength per rilevare la saturazione; usa istanze ottimizzate per EBS e driver ENA appropriati per throughput/IOPS elevati.

Gli snapshot sono incrementali: il primo snapshot copia tutti i blocchi, quelli successivi memorizzano solo i blocchi modificati, ma i costi degli snapshot possono aumentare se si accumulano molti blocchi modificati o se si conservano molte generazioni. Gestisci il lifecycle con Data Lifecycle Manager (DLM) o AWS Backup per pianificare, conservare e copiare gli snapshot tra le region. Usa

undefined

per snapshot ad-hoc; ripristina con create-volume da uno snapshot. Ricorda che gli snapshot catturano lo stato del dispositivo a blocchi dal punto di vista dell’host: metti in quiescenza i filesystem (fsfreeze o usa agenti application-consistent) per la coerenza del database o usa snapshot integrati con strumenti di backup.

File system: operazioni su EFS e FSx

EFS fornisce un servizio NFSv4 gestito (o NFSv4.1/4.2) per carichi di lavoro Linux, offrendo capacità elastica, molteplici modalità di throughput (bursting vs provisioned) e gestione del lifecycle per spostare i file su EFS Infrequent Access. Configura i mount target per ogni Availability Zone, le regole dei security group per NFS (TCP 2049) e abilita la crittografia a riposo con KMS e la crittografia in transito (TLS). Usa le Performance Modes (General Purpose vs Max I/O) a seconda delle esigenze di latenza e di throughput dei metadati e definisci il throughput per carichi di lavoro stabili ad alto throughput (

undefined

FSx offre SMB (FSx for Windows File Server) e Lustre (FSx for Lustre) con semantiche diverse: FSx for Windows si integra con AD per SMB e supporta ACL di Windows, DFS Namespaces e backup; FSx for Lustre è rivolto all’HPC ad alte prestazioni e può essere collegato a S3 per l’integrazione con un data repository. Configura backup giornalieri automatici, imposta la capacità di throughput e seleziona SSD o HDD secondo necessità. Usa i passaggi di configurazione di Active Directory e monta tramite SMB (

undefined

) per client Windows o client SMB Linux con cifs-utils.

Tiering dello storage, policy di lifecycle e archiviazione

Il tiering riduce i costi spostando i dati lungo un ciclo di vita: hot -> warm -> cold -> archive. Implementa il tiering tramite le regole di lifecycle di S3 e le policy di lifecycle di EFS, e usa strumenti di migrazione automatica (Intelligent-Tiering, EFS IA). Per l’archiviazione a lungo termine, scegli le classi Glacier in base agli SLA di recupero: Instant Retrieval per accessi rapidi e frequenti, Flexible Retrieval per ripristini massivi standard, Deep Archive per il costo più basso e finestre di ripristino di più ore. Per EBS, esporta gli snapshot in un archivio compatibile con S3 Glacier utilizzando Backup Vault Lock con copie cross-region per ottimizzare i costi.

Quando progetti le policy, considera le durate minime di archiviazione, i costi di recupero e di eliminazione anticipata, e i pattern di accesso. Per la conformità, combina S3 Object Lock (modalità governance/compliance) con transizioni di lifecycle impostate per la scadenza solo dopo il periodo di conservazione. Testa periodicamente le procedure di ripristino (esegui un ripristino da Glacier Flexible Retrieval/Deep Archive per convalidare tempi, costi e passaggi operativi) e automatizza i ripristini dove possibile utilizzando script batch di AWS CLI o l’orchestrazione con Lambda.

Durabilità dei dati, consistenza e pattern di accesso

Le scelte di durabilità e consistenza modellano l’architettura: S3 offre un’elevata durabilità (11 nove) e una consistenza strong read-after-write per le operazioni PUT/DELETE; EBS fornisce durabilità a livello di singola AZ per i volumi, con snapshot archiviati in S3 per la durabilità e copie cross-region per il DR; EFS offre una consistenza forte (strong consistency) per client concorrenti. Selezionare il tipo di storage in base al pattern di accesso:

A oggetti (S3): ideale per dati immutabili o append-only su larga scala, asset web, grandi dataset, landing zone per l’analytics.
A blocchi (EBS): ideale per sistemi operativi e database che richiedono letture/scritture casuali a bassa latenza e semantica single-writer.
A file (EFS/FSx): ideale per carichi di lavoro con file condivisi, home directory o applicazioni Windows SMB che richiedono semantica POSIX/ACL.

Progettare per la località di lettura/scrittura, considerare livelli di caching (Amazon ElastiCache, Amazon CloudFront per oggetti S3) e utilizzare il lifecycle e il tiering per allineare i costi alla frequenza di accesso. Crittografare i dati at-rest e in-transit (SSE-S3/SSE-KMS o client-side, crittografia EBS con KMS, chiavi KMS per EFS e crittografia SMB/SMB3 per FSx) e applicare il principio del privilegio minimo utilizzando IAM, policy dei bucket e VPC endpoint per l’accesso privato.

Errori Comuni e Criteri Decisionali

Non abilitare il versioning di S3 per dati critici: abilitare il versioning e, opzionalmente, applicare S3 Object Lock per la conservazione immutabile; usare regole di lifecycle per far scadere le versioni non correnti e controllare i costi.
Costi imprevisti per snapshot e storage: pianificare la potatura (pruning) degli snapshot con DLM/AWS Backup, monitorare il consumo di storage degli snapshot e ricordare che gli snapshot sono incrementali ma possono comunque fare riferimento a molti blocchi; eliminare gli snapshot non necessari e copiare tra le regioni solo quelli indispensabili.
Scegliere la classe di storage sbagliata per i pattern di accesso: usare Intelligent-Tiering per pattern sconosciuti, o analizzare i log di accesso e usare regole di lifecycle; evitare le classi profonde di Glacier per oggetti a cui si accede di frequente.
Presumere che gli snapshot EBS siano backup istantanei e consistenti a livello di applicazione: mettere in quiescenza i filesystem o usare backup application-aware per i database; utilizzare AWS Backup per catturare snapshot consistenti a livello di applicazione dove supportato.
Controlli di accesso mancanti per le chiavi di crittografia: quando si usa SSE-KMS, assicurarsi che le policy IAM e delle chiavi KMS consentano l’accesso agli utenti e ai servizi previsti; ruotare le chiavi e monitorare l’uso di KMS in CloudTrail.
Trascurare i limiti di throughput/IOPS: provisionare IOPS/throughput io1/io2 o gp3 secondo necessità, selezionare la modalità di performance EFS appropriata e scegliere la capacità di throughput di FSx per evitare colli di bottiglia a runtime.

Problema Pratico: Scenario d’Uso

DataCorp Analytics archivia i dump delle transazioni di fine mese in S3 e i risultati elaborati nottetempo su istanze EC2 con volumi EBS. L’azienda affronta costi di storage in aumento, sovrascritture accidentali e ripristini lenti dei dati archiviati.

Abilitare il versioning di S3 sul bucket e impostare Object Lock per la conservazione dei dataset regolamentati; aggiungere regole di lifecycle per spostare gli oggetti più vecchi su Intelligent-Tiering e poi su Glacier Flexible Retrieval dopo un periodo definito.
Analizzare i log di accesso di S3 e le metriche di CloudWatch per un periodo di 30 giorni; spostare gli oggetti realmente “freddi” (cold) su Glacier Deep Archive solo dopo aver confermato un basso numero di accessi.
Implementare policy DLM/AWS Backup per i volumi EBS con snapshot completi settimanali e una policy di retention; mettere in quiescenza i database prima degli snapshot e copiare gli snapshot critici in un’altra regione per il DR.
Introdurre Intelligent-Tiering per i dati con pattern di accesso sconosciuto e usare i tag di allocazione dei costi per tracciare i costi per ambiente; automatizzare gli allarmi per una crescita imprevista dello storage.
Validare trimestralmente le procedure di ripristino ripristinando dati di esempio da Glacier e dagli snapshot per assicurarsi che i tempi di ripristino e i costi soddisfino le aspettative.

Logica: Questo approccio abbina la classe di storage e il ciclo di vita degli snapshot ai pattern di accesso osservati, garantisce la recuperabilità con il versioning e ripristini testati, e utilizza strumenti automatizzati di lifecycle e backup per controllare i costi, soddisfacendo al contempo i requisiti di durabilità e conformità.

← Reti e distribuzione di contenuti · Tutti i domini · Elaborazione e Auto Scaling →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →