Amazon DVA-C02: Archiviazione, Amazon S3, CloudFront e File System (EFS, FSx) — Guida allo studio

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

Fondamenti di Amazon S3, controlli di sicurezza e pattern per sviluppatori

Amazon S3 è il servizio di object storage durevole per antonomasia. Gli sviluppatori dovrebbero progettare le API basandosi su PutObject/GetObject/HeadObject e sugli upload multiparte (CreateMultipartUpload, UploadPart, CompleteMultipartUpload) per payload di grandi dimensioni, e usare le funzioni di supporto degli SDK come generate_presigned_url('get_object') o generate_presigned_post di boto3 per upload temporanei da parte dei client. Proteggere gli oggetti usando la crittografia lato server (SSE-S3, SSE-KMS tramite PutObject con x-amz-server-side-encryption o imponendo la crittografia di default del bucket con PutBucketEncryption), richiedere il TLS imponendo aws:SecureTransport nelle policy del bucket, e bloccare l’accesso pubblico accidentale con S3 Block Public Access e deny espliciti nelle policy del bucket. Le trappole comuni includono i deny espliciti di IAM che hanno la precedenza sui permessi dei ruoli, le URL pre-firmate che ereditano i privilegi del firmatario ma sono comunque soggette alle policy del bucket e alle policy degli endpoint VPC, e configurazioni errate del CORS durante l’upload diretto dai browser (configurare con PutBucketCors). Usare le regole di lifecycle (PutBucketLifecycleConfiguration) per spostare gli oggetti su Intelligent-Tiering, GLACIER, o far scadere le versioni non correnti, e abilitare il versioning (PutBucketVersioning) prima di fare affidamento sulle regole per le versioni non correnti. Per l’audit e il ripristino, abilitare i log di accesso al server di S3 o gli S3 Access Points, e usare Object Lock con una modalità di conservazione per la ritenzione immutabile. Progettare tenendo conto della consistenza finale (eventual consistency) per le sovrascritture tramite PUT e per le nuove chiavi (la lettura dopo la scrittura è garantita per i PUT di nuovi oggetti, ma gli aggiornamenti a chiavi esistenti possono manifestare consistenza finale in scenari limite).

S3 avanzato: Object Lambda, flussi con URL pre-firmate, policy e sfumature del lifecycle

S3 Object Lambda permette di trasformare le risposte di GetObject associando una funzione Lambda a un S3 Object Lambda Access Point; la Lambda riceve un GetObjectContext e deve chiamare WriteGetObjectResponse (tramite l’API S3 Object Lambda/Control) per restituire i byte trasformati. I pattern tipici sono il ridimensionamento di immagini al volo, l’oscuramento di dati (redaction) o la conversione di formato senza duplicare gli oggetti. Per gli upload dal browser, generare POST pre-firmati (generate_presigned_post negli SDK) con una policy restrittiva (content-length-range, prefisso della chiave) per evitare abusi. Le policy dei bucket e le policy degli endpoint VPC (Gateway/Interface) sono strumenti potenti per limitare l’accesso: preferire allow espliciti con condizioni sulla risorsa (aws:SourceVpce, aws:Referer con cautela) ed evitare principal con wildcard aperte. Le insidie del lifecycle includono le transizioni per i bucket con versioning — configurare esplicitamente noncurrentVersionTransitions e noncurrentVersionExpiration — e la regola abort-incomplete-multipart-upload per evitare perdite di storage. Quando si impone la crittografia in transito, richiedere l’header x-amz-server-side-encryption o usare PutBucketPolicy per negare le richieste senza TLS. Per la conformità che richiede immutabilità, abilitare Object Lock prima di caricare gli oggetti. Quando è richiesta un’applicazione programmatica delle regole, combinare gli eventi S3 (SNS, EventBridge) con Lambda per applicare tag o eseguire convalide post-upload.

CloudFront, strategie di caching e edge compute (Lambda@Edge vs CloudFront Functions)

CloudFront accelera la distribuzione globale dei contenuti e protegge le origini. Per le origini S3, preferire l’Origin Access Control (OAC) con Sigv4 rispetto alla vecchia Origin Access Identity per firmare le richieste all’origine e negare l’accesso pubblico diretto a S3. L’ottimizzazione del comportamento della cache (cache behavior) si basa su Cache-Control/Expires, sull’inoltro dell’header Authorization e su chiavi di cache basate su query string/cookie; privilegiare il whitelisting delle chiavi di cache o l’uso di Cache Policy e Origin Request Policy per ridurre la frammentazione della cache. Per contenuti privati, usare URL firmati o cookie firmati di CloudFront (creati tramite cloudfront.create_signer o le funzioni di supporto degli SDK). Usare CloudFront Functions per manipolazioni leggere (sotto il millisecondo) a livello di viewer request/response e Lambda@Edge per logiche più complesse che richiedono runtime Node/Python e si agganciano a origin-request o origin-response; ricordare che le funzioni Lambda@Edge vengono distribuite da us-east-1 e comportano possibili cold start e un ritardo di replica regionale. L’invalidazione ha un costo e una latenza — preferire il versioning delle chiavi degli oggetti (distribuire nuovi nomi di file o aggiungere una versione nella query string) per evitare le invalidazioni. Strumentare CloudFront con i log in tempo reale e le metriche di CloudWatch per il rilevamento di anomalie quasi in tempo reale, e attivare Lambda per risposte automatiche. Le trappole comuni includono l’inoltro eccessivo di header/cookie che invalidano la cache (cache busting) e dare per scontata la propagazione immediata dell’invalidazione.

File system condivisi: criteri di scelta, mount e insidie di EFS e FSx

Scegliere EFS per file system NFSv4.1 conformi a POSIX, montati in modo concorrente su client Linux; scegliere le varianti di FSx quando si necessita di funzionalità SMB/Windows o delle alte prestazioni di Lustre. EFS supporta la crittografia at-rest tramite KMS, la crittografia in-transit utilizzando l’opzione di mount TLS e gli access point per il mapping UID/GID per singola applicazione. Montare utilizzando amazon-efs-utils (mount -t efs -o tls,accesspoint=fsap-0123456789 fs-12345678:/ /mnt) o il client NFS per carichi di lavoro ad alto throughput. Selezionare la modalità di performance (generalPurpose vs maxIO) e la modalità di throughput (bursting vs provisioned) in base ai pattern di throughput/IOPS. FSx for Windows si integra con Active Directory ed espone condivisioni SMB con ACL NTFS, namespace DFS e semantica nativa di Windows—montare usando net use \fs-xxxx\share o tramite client EC2 Windows; le insidie comuni includono la complessità nell’unione ad AD e la risoluzione DNS. FSx for Lustre è ideale per il calcolo ad alte prestazioni e può collegarsi in modo trasparente a S3 tramite data repository task per importare/esportare set di dati. Attenzione al networking: aprire le porte NFS/SMB nei security group, usare mount target in ogni AZ per EFS e assicurarsi che le policy IAM non possano essere usate per limitare l’accesso a livello NFS—i permessi POSIX e i security group sono i punti di applicazione delle regole. Per i backup, preferire snapshot automatizzati (EFS Backup, snapshot di FSx) e testare regolarmente i ripristini.

Problema Pratico: Scenario d’Uso

Scenario: AcmeAnalytics gestisce una dashboard statica rivolta ai clienti, ospitata in un bucket S3 e distribuita globalmente tramite una distribuzione CloudFront. Il team di ingegneri deve distribuire file di dati privati, eseguire conversioni al volo da CSV a JSON per alcuni oggetti e garantire che le nuove build della dashboard invalidino le cache con un costo minimo.

Sfida: Implementare la distribuzione sicura di oggetti privati, la trasformazione dinamica senza duplicare lo storage e una strategia a basso costo per gli aggiornamenti della cache.

Approccio Consigliato:

1. Creare un bucket S3 con PutBucketEncryption (SSE-KMS) e una PutBucketPolicy per negare le connessioni non-TLS e consentire l’accesso solo dal CloudFront Origin Access Control (creare un OAC e associarlo alla distribuzione); usare PutBucketVersioning per abilitare il versioning.
2. Configurare un S3 Object Lambda Access Point; implementare una funzione Lambda che gestisca il GetObjectContext, recuperi l’originale tramite S3 GetObject, trasformi il CSV in JSON in memoria e restituisca il risultato usando s3control.write_get_object_response.
3. Configurare i comportamenti della cache di CloudFront: instradare /private/* verso l’S3 Object Lambda Access Point (come origine), impostare una Cache Policy che metta in cache basandosi sull’header Accept se necessario, e abilitare TTL minimi; per gli asset della dashboard, usare nomi di file versionati per evitare le invalidazioni.
4. Per le invalidazioni necessarie ma poco frequenti, chiamare cloudfront.create_invalidation(DistributionId=…, InvalidationBatch={…}) dalla CI dopo il deploy; altrimenti, per le modifiche di routine, caricare gli asset con un content-hash nel nome del file per aggirare i costi di invalidazione.

Motivazione: Limitare l’accesso a S3 solo a CloudFront tramite OAC e imporre SSE-KMS protegge i dati in-flight e at-rest. S3 Object Lambda fornisce la trasformazione al volo senza duplicare gli oggetti, e l’uso del versioning degli oggetti o di nomi di file con content-hash evita costose invalidazioni preservando l’efficienza della cache.

← Monitoraggio · Tutti i domini · Database e Caching (RDS →

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

Sfoglia Amazon →