Amazon SAP-C02: Storage e gestione dei dati — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Storage a oggetti, ciclo di vita e tiering (Amazon S3 e servizi correlati)

Amazon S3 è la base per lo storage a oggetti durevole e ad alta disponibilità e dovrebbe essere considerato come l’archivio canonico a lungo termine per i dati non strutturati. Le decisioni di progettazione si concentrano sulla selezione della classe di storage, sulle regole del ciclo di vita, sulla semantica di consistenza e sulla data governance. Scegliere S3 Standard per gli oggetti ad accesso frequente, Intelligent-Tiering quando i pattern di accesso sono sconosciuti, Standard-IA o One Zone-IA per l’accesso sporadico e Glacier/Deep Archive per la conservazione a lungo termine con una latenza di ripristino più elevata. Implementare policy del ciclo di vita basate su tag o prefissi per trasferire automaticamente gli oggetti e far scadere le versioni obsolete; abilitare il versioning prima del ciclo di vita o della replica per evitare che gli oggetti vengano eliminati accidentalmente. Utilizzare la Cross-Region Replication (CRR) per la durabilità geografica e il posizionamento normativo, o la Same-Region Replication (SRR) per la conformità e la separazione delle responsabilità. Proteggere gli archivi critici con S3 Object Lock in modalità governance o compliance e abilitare MFA Delete dove appropriato. Le trappole comuni includono transizioni del ciclo di vita troppo aggressive che comportano costi di ripristino e ritardi da minuti a ore, non tenere conto dei costi o dei tempi di recupero da Glacier e affidarsi a endpoint pubblici anziché a endpoint VPC Gateway/Interface (che possono esporre i dati a Internet o comportare costi di NAT egress). Bilanciare i costi rispetto alla latenza di recupero e alla durabilità: applicare un tiering aggressivo per i dati freddi, ma predisporre l’accelerazione (CloudFront, S3 Transfer Acceleration, multipart upload) per l’ingresso di dati caldi e l’accesso a bassa latenza dove necessario.

File system condivisi e storage ad alte prestazioni (EFS, FSx)

Scegliere i file system condivisi quando le applicazioni richiedono semantica POSIX, bassa latenza o semantica SMB. Amazon EFS fornisce un file system NFS elastico con durabilità multi-AZ e consistenza POSIX, adatto per contenuti web, home directory e molti carichi di lavoro HPC che tollerano la semantica dei file di rete. EFS ha due modalità di prestazione (throughput in modalità Bursting o Provisioned) e transizioni del ciclo di vita verso EFS Infrequent Access. Amazon FSx offre file system appositamente creati: Windows File Server per l’integrazione con SMB/Active Directory e FSx for Lustre per una latenza inferiore al millisecondo e un throughput elevato per carichi di lavoro HPC e multimediali strettamente accoppiati; FSx Lustre può collegarsi in modo trasparente a S3 per un repository di dati durevole. Scegliere FSx for Windows quando si necessita di semantica NTFS, ACL di AD, namespace DFS o strumenti esclusivi per Windows; scegliere FSx for Lustre per render farm e training di ML che richiedono IOPS e throughput elevati. Gli errori operativi comuni includono presumere che EFS gestisca automaticamente i carichi di lavoro con metadati pesanti (potrebbe essere necessario il throughput provisioned), aprire ampiamente le porte NFS/SMB nei security group e trascurare le opzioni di mount e i timeout del client. Valutare i compromessi: FSx ha un costo più elevato ma offre prestazioni superiori e funzionalità di protocollo più ricche; EFS offre una scalabilità più semplice e una durabilità multi-AZ. Abbinare i pattern di I/O, la concorrenza e le esigenze di throughput del carico di lavoro al sistema scelto e dimensionare il throughput separatamente dove necessario.

Pattern di trasferimento ibridi e offline (Storage Gateway, DataSync, Snow family)

Le architetture ibride richiedono comunemente caching locale a bassa latenza, backup su cloud trasparenti o migrazione di dati in blocco. AWS Storage Gateway fornisce tre pattern: File Gateway espone S3 come NFS/SMB per consentire alle app on-premise di scrivere su S3; Volume Gateway espone volumi a blocchi per il DR; Tape Gateway sostituisce i nastri fisici. AWS DataSync automatizza lo spostamento di dati online, incrementale e parallelo tra on-premise e AWS (S3, EFS, FSx) con controlli integrati di filtraggio, pianificazione e larghezza di banda; rispetta i metadati POSIX se configurato. Per i trasferimenti offline e di grandi dimensioni, la famiglia Snow fornisce dispositivi di edge e trasporto che includono capacità di calcolo: Snowcone per piccole sedi remote, Snowball Edge per decine o centinaia di TB con Lambda/EC2 sul dispositivo e Snowmobile per importazioni di exabyte. Utilizzare DataSync per trasferimenti continui e automatizzati e Storage Gateway File Gateway quando le applicazioni legacy devono vedere i mount NFS/SMB localmente, pur archiviando i dati in S3. Le insidie comuni includono l’uso della modalità gateway errata (cached vs stored), la mancata pianificazione del throughput di rete che porta a migrazioni lunghe, la trascuratezza dei ruoli IAM e delle policy degli endpoint per un trasferimento sicuro e la sottovalutazione dei tempi di ingestione/egress dei dispositivi Snow. Scegliere DataSync per sincronizzazioni incrementali frequenti, Storage Gateway per la compatibilità con i protocolli locali e i dispositivi Snow per trasferimenti in blocco o remoti dove la larghezza di banda della rete è insufficiente.

Backup, replica, controllo degli accessi e governance operativa

Le scelte di backup e replica dovrebbero essere guidate dagli obiettivi RTO/RPO, dai controlli normativi e dai costi. Utilizzare AWS Backup per centralizzare le policy di backup tra EBS, RDS, DynamoDB, EFS e FSx, e configurare le transizioni del ciclo di vita da un vault warm a uno storage cold per risparmiare sui costi. Per i database, preferire i meccanismi nativi (snapshot di RDS, read replica o DMS per migrazioni eterogenee) abbinati alla copia cross-region degli snapshot e alla replica delle chiavi KMS o a policy di chiave separate. Per S3, abilitare il versioning, CRR/SRR, e considerare il replication time control (RTC) quando è richiesto un SLA di replica quasi in tempo reale. I pattern di accesso sicuro si basano su IAM con privilegi minimi (least-privilege), bucket policy, S3 Block Public Access, endpoint VPC di tipo Gateway/Interface con policy di endpoint, e KMS con grant granulari per l’accesso cross-account e la copia di snapshot. Monitorare con CloudTrail, S3 Access Logs, metriche CloudWatch, regole di AWS Config, e usare GuardDuty e Access Analyzer per il rilevamento delle minacce e delle configurazioni errate di IAM. Le trappole tipiche includono la mancata replica o concessione dell’accesso alle CMK di KMS tra account, il lasciare gli snapshot non crittografati o accessibili pubblicamente, e il non imporre tag o il posizionamento delle risorse con SCP e Tag Policy, il che complica l’allocazione dei costi e il ripristino. Decidere in base alle esigenze di resilienza: multi-region active-active per l’RTO più basso, pilot-light/warm standby per un DR efficiente in termini di costi, e failover completo quando l’RTO deve essere minimo.

Problema Pratico: Scenario d’Uso

Scenario: Atlas Media gestisce una AWS Organization multi-account con la produzione in us-east-1 e una regione secondaria in eu-west-1. Possiedono un archivio on-premise di 150 TB di asset video e gli artisti in Nord America ed Europa necessitano di uno storage condiviso ad alte prestazioni e di un accesso sicuro e a bassa latenza ai progetti correnti.

Sfida: Migrare l’archivio su AWS, fornire storage ad alto throughput per il rendering agli artisti, minimizzare i costi di storage correnti per gli asset “cold” e garantire un accesso cross-region sicuro con backup robusti.

Approccio Raccomandato:

Effettuare il provisioning di un bucket S3 in us-east-1 come archivio canonico, abilitare il versioning, la crittografia lato server con AWS KMS (SSE-KMS) e configurare la Cross-Region Replication verso eu-west-1 con la replica dei delete marker attivata.
Utilizzare dispositivi AWS Snowball Edge per importare i 150 TB iniziali su S3 (Snowball Edge ottimizzato per lo storage), quindi eseguire AWS DataSync per la sincronizzazione incrementale di eventuali modifiche delta e per convalidare l’integrità.
Per i set di lavoro attivi, distribuire Amazon FSx for Lustre in ogni regione e collegare il file system al bucket S3 (Data Repository Integration) in modo che gli artisti ottengano un throughput elevato e una bassa latenza mentre le scritture vengono sincronizzate nuovamente su S3; considerare l’uso di istanze FSx di breve durata per picchi di lavoro sui progetti.
Applicare un accesso sicuro con endpoint di interfaccia VPC per S3 e FSx, limitare l’accesso al bucket con ruoli IAM e bucket policy legati ai principal dell’Organization, gestire la distribuzione pubblica con CloudFront e URL firmati (signed URL) per i revisori remoti, e abilitare AWS Backup per FSx oltre alla replica cross-region di S3 e alle regole di ciclo di vita per la transizione degli asset “cold” verso Glacier Deep Archive.

Logica: Questo approccio separa lo storage di archiviazione durevole e a basso costo (S3 + Glacier) dallo storage performante per i progetti (FSx Lustre collegato a S3), utilizza Snowball e DataSync per ottimizzare l’ingestione massiva iniziale e i delta, e impone una sicurezza robusta e una resilienza cross-region, bilanciando al contempo costi, prestazioni e obiettivi di ripristino.

← Compute e Auto Scaling · Tutti i domini · Database e analytics →

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