Amazon DOP-C02: Storage, Database e Gestione dei Dati — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Lo storage, i database e lo spostamento dei dati su AWS devono essere progettati per garantire durabilità, disponibilità, efficienza dei costi e automazione. La padronanza delle classi di storage e della replica di S3, della capacità e della distribuzione globale di DynamoDB, dei controlli di configurazione e dei modelli di backup di RDS/Aurora, della cache in-memory, dei file system condivisi e dei servizi di migrazione dei dati consente di creare sistemi affidabili e a bassa latenza con un comportamento di ripristino prevedibile e una spesa controllata.

Amazon S3: classi di storage, ciclo di vita, intelligent tiering e replica

Le classi di storage di S3 allineano i costi ai modelli di accesso:

Standard: multi-AZ, bassa latenza, nessun costo di recupero. Predefinita per dati ad accesso frequente (“hot”).
Intelligent-Tiering (S3 INT): multi-AZ con tiering automatico tra i livelli di accesso Frequente e Infrequente e livelli di archiviazione opzionali. È previsto un costo di monitoraggio e automazione per oggetto; gli oggetti più piccoli di 128 KB non vengono spostati automaticamente. I livelli Archive Access e Deep Archive Access sono opzionali (opt-in) con soglie basate sull’ultimo accesso; si applicano costi di recupero dai livelli non frequenti.
Standard-IA e One Zone-IA: costo di storage inferiore con costi di recupero; addebito minimo per 30 giorni di storage. One Zone-IA è single-AZ per dati ricreabili.
Glacier Instant Retrieval: accesso in millisecondi con i costi di un archivio; minimo 90 giorni.
Glacier Flexible Retrieval: recupero da minuti a ore, opzioni bulk/standard/expedited; minimo 90 giorni.
Glacier Deep Archive: recupero da ore a 12 ore; minimo 180 giorni. Scegliere il livello più “freddo” possibile, considerando i costi per la durata minima dello storage, i costi di recupero e i tempi di accesso richiesti.

Le policy del ciclo di vita automatizzano le transizioni e le scadenze utilizzando filtri (prefisso, tag) per un controllo granulare. Le azioni principali includono la transizione ai livelli IA/Glacier dopo soglie di inattività, la transizione/scadenza delle versioni non correnti nei bucket con versioning, la scadenza dei marcatori di eliminazione e l’interruzione degli upload multiparte incompleti. Il ciclo di vita e il tagging degli oggetti sono cruciali per applicare la conservazione dei dati e la cancellazione difendibile, insieme a S3 Object Lock (modalità governance/compliance) quando è richiesta l’immutabilità.

Intelligent-Tiering è ideale quando i modelli di accesso sono sconosciuti o variabili. Conserva le prestazioni (nessun ritardo nel recupero dai livelli ad accesso frequente/IA), elimina la necessità di riprogettare l’architettura quando i modelli cambiano e può opzionalmente archiviare automaticamente in livelli “deep” basati sull’ultimo accesso, fornendo la migliore combinazione di agilità e controllo dei costi per set di dati a lunga conservazione con accesso sporadico.

La replica S3 fornisce una copia durevole e asincrona degli oggetti:

Requisiti: versioning abilitato su origine e destinazione. La configurazione della replica definisce il bucket/account/regione di destinazione, il filtro per prefisso/tag, la replica dei metadati (ACL, tag, S3 Object Lock), la classe di storage e se replicare i marcatori di eliminazione e gli oggetti esistenti.
Replica nella stessa regione (SRR): conformità/sovranità dei dati, aggregazione di log, elaborazione atomica tra account diversi.
Replica tra regioni (CRR): DR, riduzione della latenza, distribuzione globale, conformità.
Oggetti crittografati con KMS: il ruolo di replica deve essere autorizzato a decrittografare con la chiave KMS di origine e a crittografare con la chiave KMS di destinazione. Specificare la chiave KMS della replica nella regola di replica in EncryptionConfiguration. Per la replica tra account, aggiornare la policy del bucket di destinazione per consentire al ruolo di replica di scrivere.
Oggetti esistenti: utilizzare S3 Batch Replication per il backfill.
Replication Time Control (RTC): aggiunge uno SLA di 15 minuti per il completamento della replica, con metriche di replica e notifiche per monitorare gli SLA. Utile per la conformità e RPO rigorosi.
Proprietà e accesso: quando si opera tra account diversi, abilitare “bucket owner preferred” o “bucket owner enforced” in Object Ownership per evitare la complessità delle ACL e garantire che l’account di destinazione sia il proprietario delle repliche.

Database su AWS: DynamoDB, RDS e Aurora

Modalità di capacità e scaling di DynamoDB:

On-demand: nessuna pianificazione della capacità; tariffazione per richiesta; ideale per carichi di lavoro impre

Migrazione dei dati: DMS, Snowball e DataSync

AWS Database Migration Service (DMS): migrazione online con tempi di inattività minimi utilizzando il caricamento completo più la Change Data Capture (CDC). Supporta migrazioni omogenee ed eterogenee tramite la conversione dello schema integrata (con AWS Schema Conversion Tool per conversioni complesse). Utilizzare per il lift-and-shift verso RDS/Aurora, verso DynamoDB (tramite mappatura JSON) o per la replica continua per l’offloading delle letture o cutover graduali. Dimensionare le istanze di replica per i picchi di change rate; assicurarsi che i log di origine (es. binlog/redo) conservino una cronologia sufficiente.
AWS Snowball (Edge Storage/Compute Optimized): trasferimento dati offline su scala petabyte quando le reti sono limitate/costose o quando è necessario popolare rapidamente dataset S3/EFS di grandi dimensioni. Concatenare più dispositivi per carichi di svariati petabyte. Utilizzare per caricamenti iniziali massivi, raccolta dati in sedi remote/edge o migrazione da data center con vincoli. I dati sono crittografati end-to-end con KMS; il tracciamento del dispositivo e i sigilli antimanomissione supportano la catena di custodia (chain of custody).
AWS DataSync: trasferimento online accelerato per NFS/SMB verso S3/EFS/FSx e tra servizi di storage/Region AWS. Gestisce il rilevamento incrementale delle modifiche, la parallelizzazione, la compressione, il controllo della larghezza di banda, la pianificazione e i controlli di integrità. Utilizzare per spostare delta ricorrenti, per flussi di lavoro ibridi e per sostituire script rsync personalizzati con un’automazione gestita. Distribuire l’agente DataSync on-premise per accedere allo storage locale.

Scenario pratico

Shopify deve modernizzare la sua pipeline globale per i media dei prodotti e i dati di catalogo, migliorando al contempo la resilienza e la latenza per gli acquirenti di tutto il mondo. L’azienda deve: replicare le immagini dei prodotti tra Region e account con un RPO rigoroso, ridurre la latenza di lettura di DynamoDB in Nord America ed Europa, migrare gli asset NFS on-premise con delta continui e semplificare le operazioni di RDS con backup affidabili.

Implementare S3 CRR con Replication Time Control dal bucket primario dei media in us-east-1 (account di merchandising) a un bucket di destinazione in eu-west-1 (account di delivery).

Perché: La CRR soddisfa la separazione cross-Region e cross-account per il principio del privilegio minimo (least privilege) e la sovranità dei dati. L’RTC fornisce uno SLA di replica di 15 minuti e monitoraggio per un RPO di livello compliance. La bucket policy cross-account garantisce che il ruolo di replica di origine possa scrivere e la specifica di una chiave KMS di destinazione mantiene i domini di crittografia.

Definire regole di replica S3 filtrate per prefisso e tag per separare originali, anteprime e log, e abilitare la replica dei delete marker. Usare S3 Batch Replication per il backfill degli oggetti preesistenti.

Perché: Lo scoping delle regole evita costi di replica non necessari e la replica dei delete marker mantiene le Region semanticamente coerenti. Batch Replication colma le lacune storiche senza script personalizzati.

Convertire il catalogo prodotti e l’inventario in una tabella globale DynamoDB distribuita tra us-east-1 e eu-west-1; passare le tabelle alla capacità on-demand e aggiungere cluster DAX per ogni Region per le API con carichi di lettura intensi.

Perché: Le tabelle globali forniscono scritture active-active con letture/scritture locali a bassa latenza e replica continua. La modalità on-demand elimina il rischio della pianificazione della capacità durante i picchi di traffico. DAX riduce le latenze P99 per le letture “calde” (hot reads), proteggendo DynamoDB da accessi a raffica (bursty).

Effettuare il replatforming del carico di lavoro relazionale degli ordini su Amazon Aurora MySQL con endpoint di scrittura (writer) e di lettura (reader); aggiungere un reader Aurora Serverless v2 di piccole dimensioni per analisi con picchi di carico (spiky analytics) e abilitare i backup automatici con una policy di conservazione di 14 giorni.

Perché: Gli endpoint di cluster/reader disaccoppiano lettura/scrittura e minimizzano le interruzioni durante la manutenzione o il failover. Serverless v2 assorbe i picchi di carico analitici imprevedibili in modo economicamente vantaggioso. I backup automatici offrono PITR (Point-In-Time Recovery) e processi di ripristino semplificati.

Introdurre ElastiCache for Redis (con modalità cluster abilitata) per l’archiviazione delle sessioni e la cache della disponibilità dei prodotti, con Multi-AZ e backup tramite snapshot; impostare i TTL in linea con gli SLA di business.

Perché: Le strutture dati di Redis e il failover Multi-AZ garantiscono sessioni stateful veloci e un’invalidazione della cache quasi in tempo reale. La modalità cluster scala orizzontalmente con la crescita delle dimensioni del catalogo e del traffico.

Creare un file system EFS di tipo Regional con mount target in ogni AZ dell’applicazione e Access Point per i carichi di lavoro che richiedono uno storage POSIX condiviso (es. processori di media). Abilitare le transizioni del ciclo di vita di EFS verso la classe IA dopo 30 giorni.

Perché: EFS fornisce storage condiviso elastico e multi-AZ; gli Access Point impongono l’isolamento per applicazione e le identità POSIX. La gestione del ciclo di vita riduce automaticamente i costi per gli asset “freddi” (cold) che rimangono accessibili.

Migrare le librerie multimediali NFS on-premise usando AWS DataSync con task pianificati per sincronizzazioni incrementali notturne verso S3 ed EFS.

Perché: DataSync gestisce il rilevamento delle modifiche, il parallelismo, la verifica dell’integrità e il controllo della larghezza di banda meglio di uno script rsync ad hoc, automatizzando i delta continui con un carico operativo minimo.

Spostare il catalogo legacy PostgreSQL su Aurora usando AWS DMS (caricamento completo più CDC) e l’AWS Schema Conversion Tool dove necessario; effettuare il cutover dopo che il lag della CDC si è azzerato.

Perché: DMS abilita una migrazione con tempi di inattività quasi nulli, con la replica continua che garantisce la parità dei dati al momento del cutover. SCT gestisce le conversioni specifiche del motore.

Popolare S3 con svariati petabyte di media storici usando dispositivi Snowball Edge, per poi passare a DataSync per gli incrementi continui.

Perché: Snowball accelera il trasferimento iniziale massivo senza saturare i collegamenti WAN; DataSync sostiene gli aggiornamenti continui post-popolamento con verifica e pianificazione.

Questa architettura riduce le latenze di lettura globali, fornisce RPO di replica prevedibili, semplifica le operazioni relazionali e i backup, centralizza lo storage condiviso con controlli di accesso e offre un percorso pragmatico dalla migrazione offline massiva al trasferimento dati incrementale e automatizzato.

← Architetture Guidate dagli Eventi e Automazione · Tutti i domini · Networking e Distribuzione di Contenuti →

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