Amazon SAA-C03: Storage e Ciclo di Vita dei Dati — Guida allo studio

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Classi di storage S3 e lo spettro costo/latenza

Le classi di storage S3 si collocano su uno spettro che bilancia la latenza di recupero, la durata minima di archiviazione e le tariffe di recupero per GB rispetto al costo di archiviazione per GB. Scegliere correttamente è la leva più importante per l’ottimizzazione dei costi sullo storage a oggetti.

S3 Standard è l’opzione predefinita: durabilità di undici 9 su tre o più AZ, latenza nell’ordine dei millisecondi, nessuna tariffa di recupero, prezzo per GB più alto. Standard-IA e One Zone-IA riducono il costo di archiviazione di circa il 40–50% ma aggiungono una tariffa di recupero per GB, una durata minima fatturabile di 30 giorni e una dimensione minima dell’oggetto di 128 KB (gli oggetti più piccoli vengono fatturati come 128 KB, il che erode i risparmi). One Zone-IA riduce ulteriormente i costi archiviando i dati in una singola AZ — appropriato solo per copie secondarie riproducibili dove la perdita di una singola AZ è tollerabile.

S3 Intelligent-Tiering è la scelta corretta quando i pattern di accesso sono sconosciuti, imprevedibili o variabili su un corpus di dati di grandi dimensioni. Migra automaticamente gli oggetti tra i livelli frequent, infrequent, archive-instant, archive e deep-archive in base all’accesso osservato, addebitando una piccola tariffa di monitoraggio per oggetto. Poiché non ci sono costi di recupero tra i livelli frequent e infrequent e nessuna durata minima, è l’opzione predefinita più sicura per data lake e carichi di lavoro misti con oggetti ≥128 KB. È la scelta sbagliata quando si sa già che gli oggetti sono permanentemente ad accesso frequente (costo di monitoraggio extra) o permanentemente ad accesso sporadico per un decennio (Deep Archive è molto più economico).

Glacier Instant Retrieval fornisce accesso in millisecondi a prezzi da archivio per dati a cui si accede trimestralmente o meno — immagini mediche, PDF di conformità che devono essere prodotti immediatamente su richiesta. Glacier Flexible Retrieval offre un recupero in minuti o ore. Glacier Deep Archive è il livello più economico in AWS a circa 1 $/TB/mese, con un recupero standard di 12 ore (o 48 ore in modalità bulk) e un minimo di 180 giorni — la risposta corretta per la conservazione normativa di 7–10 anni e la sostituzione dei nastri.

Le due principali trappole di costo sono errori opposti. Selezionare Standard per dati a lungo termine letti raramente spreca denaro perché Standard non ha una riduzione di prezzo per lo storage “cold” — un dataset di 5 TB conservato per anni in Standard costa svariate volte di più degli stessi dati in Deep Archive. Al contrario, spostare oggetti appena creati direttamente in Standard-IA o Glacier è una trappola perché i costi minimi di 30/90/180 giorni, sommati alle tariffe di recupero, superano i risparmi quando gli oggetti sono ancora ad accesso frequente (“hot”). Glacier Flexible o Deep Archive sono anche assolutamente incompatibili con qualsiasi carico di lavoro che si aspetti una lettura sincrona — un utente in attesa di una richiesta HTTP GET non può tollerare un SLA di recupero da minuti a 12 ore. Glacier Instant Retrieval è l’unico livello Glacier compatibile con l’accesso immediato.

Policy del ciclo di vita e gestione delle versioni

La configurazione del ciclo di vita è un file dichiarativo JSON/YAML associato a un bucket che trasferisce o fa scadere gli oggetti in base all’età, a un tag o a un prefisso. Le transizioni vengono valutate una volta al giorno e si attivano solo dopo che l’età specificata è stata raggiunta — una transizione Days: 30 significa che le tariffe di Standard si applicano per i primi 30 giorni. Le transizioni devono spostarsi verso livelli progressivamente più “cold”, e gli oggetti più piccoli di 128 KB non vengono trasferiti da Standard a IA perché i costi generali per oggetto superano i risparmi; consolidare prima gli oggetti piccoli tramite tar/zip o S3 Batch Operations.

Una policy canonica per un carico di lavoro che è “hot” per 30 giorni, “cold” in seguito, che necessita di accesso immediato per tutto il tempo, conservato per quattro anni, con una corretta igiene:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Una trappola frequente nella gestione delle versioni: su un bucket con versionamento, una regola del ciclo di vita che fa scadere gli oggetti correnti si limita a inserire dei “delete marker”; le versioni precedenti si accumulano silenziosamente e continuano a generare costi. Le versioni non correnti richiedono le proprie regole esplicite NoncurrentVersionTransitions e NoncurrentVersionExpiration. Allo stesso modo, includere sempre AbortIncompleteMultipartUpload — le parti di caricamenti multipart orfane sono invisibili nell’elenco della console e accumulano costi di archiviazione a tempo indeterminato.

Per pattern di accesso misti — ad esempio, telemetria IoT che è “hot” per il training di ML il primo mese, poi interrogata trimestralmente per un anno, e infine archiviata — la risposta giusta è Intelligent-Tiering per il primo anno (lasciando che la classe si ottimizzi automaticamente tra i picchi di training e i giorni di inattività), seguita da una transizione pianificata a Deep Archive al giorno 365.

Versioning, MFA Delete e Object Lock

Una volta abilitato, il versioning può essere solo sospeso; non può essere disattivato. Ogni operazione PUT crea un nuovo ID di versione; DELETE inserisce un marcatore di eliminazione (delete marker) invece di rimuovere i dati. Il versioning protegge dalla sovrascrittura accidentale ma non è immutabilità: qualsiasi principal con il permesso s3:DeleteObjectVersion può rimuovere permanentemente una versione specifica. MFA Delete aggiunge il requisito che l’account root presenti un token MFA per rimuovere permanentemente le versioni o modificare lo stato del versioning, colmando la lacuna della cancellazione accidentale per i bucket di alto valore, ma non impedendo comunque a un attore autorizzato di distruggere i dati.

La vera immutabilità richiede S3 Object Lock, che a sua volta necessita del versioning e deve essere generalmente abilitato alla creazione del bucket. Ha due modalità che vengono spesso confuse:

La retention può essere applicata per singolo oggetto (Retain-Until-Date) o tramite un Legal Hold, che non ha scadenza. Per i registri contabili che richiedono un anno di accesso “hot”, nove anni di archiviazione e nessuna cancellazione per dieci anni, il pattern corretto è Object Lock in modalità Compliance con una retention di dieci anni, combinato con una transizione del ciclo di vita a Deep Archive al giorno 365. La modalità Governance non è un sostituto accettabile per un mandato legale: un’autorità di regolamentazione non accetterà “qualcuno con i permessi avrebbe potuto cancellarlo” come prova di immutabilità.

Per applicare la retention a un corpus esistente di PDF in un unico processo, si utilizza S3 Batch Operations guidato da un manifest di S3 Inventory. Batch Operations è la soluzione gestita per le mutazioni su larga scala — retention, tagging, re-crittografia tramite PUT-copy, invocazione di Lambda — su miliardi di chiavi; gli script di iterazione scritti a mano non sono il pattern corretto.

Crittografia: SSE-S3, SSE-KMS e Bucket Keys

Ogni bucket ha una crittografia predefinita. SSE-S3 (AES-256, chiavi gestite da S3) è gratuito e non richiede alcuna amministrazione delle chiavi. SSE-KMS utilizza una customer master key (CMK) di KMS, abilitando audit trail per singola chiave su CloudTrail, policy di accesso alle chiavi basate su IAM e controllo della rotazione delle chiavi, al costo delle chiamate API di KMS e, cosa più critica, del throttling delle richieste a KMS che può creare un collo di bottiglia per i carichi di lavoro di lettura ad alto throughput. Scegliere SSE-KMS quando si ha effettivamente bisogno di tali controlli (attestazione normativa, separazione dei compiti, condivisione di chiavi tra account). Impostare SSE-KMS di default “per sicurezza” aggiunge costi e complessità inutili quando SSE-S3 soddisfa già il requisito.

Le S3 Bucket Keys risolvono il problema dei costi delle richieste a KMS con SSE-KMS. S3 genera una chiave a livello di bucket di breve durata dalla CMK e deriva localmente le chiavi dati per oggetto, evitando una chiamata GenerateDataKey/Decrypt a KMS per ogni oggetto e riducendo i costi delle richieste a KMS fino al 99%:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Passare a SSE-S3 per “evitare i costi di KMS” è la soluzione sbagliata quando il requisito impone l’uso di KMS: le Bucket Keys soddisfano sia gli obiettivi di conformità che di costo senza abbandonare KMS.

Abilitare la crittografia predefinita del bucket assicura che tutti i caricamenti futuri siano crittografati (le richieste PUT non crittografate vengono crittografate in modo trasparente). Per rifiutare del tutto le richieste PUT non crittografate, si negano le scritture prive dell’header:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

La crittografia predefinita non ha alcun effetto sugli oggetti non crittografati esistenti. Per ricrittografarli, si utilizza S3 Inventory + Batch Operations eseguendo un job di Copy che sovrascrive ogni chiave sul posto: questo è il pattern standard per la re-crittografia di massa.

La crittografia lato client ad-hoc è inferiore alla crittografia predefinita più KMS: distribuisce la gestione delle chiavi tra i team applicativi, non può essere auditata centralmente tramite gli eventi KMS di CloudTrail e non può utilizzare le Bucket Keys.

Cross-Region Replication e chiavi KMS multi-Region

La Cross-Region Replication (CRR) copia in modo asincrono gli oggetti in un bucket in una Region diversa per motivi di conformità, DR o latenza. La Same-Region Replication (SRR) serve per la separazione a fini di conformità, l’aggregazione dei log e le copie tra account. Entrambe richiedono il versioning sui bucket di origine e di destinazione e un ruolo IAM che il bucket di origine assume. CRR è la risposta a basso sforzo ogni volta che un bucket deve essere replicato in un’altra Region: creare script con aws s3 sync, collegare Lambda a ObjectCreated o eseguire copie batch pianificate introduce overhead operativo, race condition e fallimenti silenziosi. Né CRR né SRR replicano gli oggetti esistenti per impostazione predefinita; utilizzare S3 Batch Replication per il backfill (riempimento a posteriori).

Le interazioni con la crittografia sono il punto in cui le architetture falliscono comunemente:

• Gli oggetti SSE-S3 vengono replicati in modo trasparente.
• Gli oggetti SSE-KMS non vengono replicati di default: è necessario abilitare esplicitamente l’opzione, specificare una chiave KMS di destinazione nella Region di destinazione e concedere al ruolo di replica i permessi kms:Decrypt sulla chiave di origine e kms:Encrypt sulla chiave di destinazione. Una chiave single-Region non può crittografare oggetti in un’altra Region.
• Gli oggetti con crittografia lato client vengono replicati come testo cifrato opaco; la Region di destinazione non ne ricava alcun vantaggio a meno che il materiale della chiave del client non sia disponibile lì.

L’attrito storico legato alla gestione di due CMK indipendenti è risolto dalle chiavi multi-Region di AWS KMS, che presentano lo stesso materiale crittografico e lo stesso ID di chiave (con un prefisso di Region) in più Regioni. Un oggetto replicato può quindi essere decifrato nella Region di destinazione senza chiamate KMS cross-Region e senza dover eseguire nuovamente il wrapping della chiave dati. Questo è il pattern canonico per i bucket crittografati e replicati che devono rimanere utilizzabili in caso di failover regionale.

La condivisione di snapshot e oggetti tra account con una chiave KMS gestita dal cliente richiede che i principal dell’account di destinazione dispongano dei permessi kms:Decrypt, kms:CreateGrant, kms:DescribeKey e kms:ReEncrypt* sulla chiave di origine tramite la policy della chiave, oltre a permessi IAM corrispondenti. Le chiavi gestite da AWS (ad es. aws/ebs, aws/s3) non possono essere condivise tra account, quindi le chiavi gestite dal cliente sono obbligatorie per i flussi di lavoro cross-account.

Blocco dell’Accesso Pubblico e Restrizione dell’Accesso a CloudFront

S3 Block Public Access (BPA) ha quattro impostazioni — blocca nuove ACL pubbliche, ignora le ACL pubbliche esistenti, blocca nuove policy di bucket pubbliche, limita le policy di bucket pubbliche — configurabili per singolo bucket e, cosa più importante, a livello di account. Il BPA a livello di account prevale su qualsiasi policy di bucket che concederebbe l’accesso pubblico ed è il controllo corretto per garantire che “nessun oggetto in questo account possa essere pubblico”. Le policy a livello di bucket da sole sono fragili: un nuovo bucket potrebbe essere creato senza una di esse; il BPA a livello di account adotta un approccio fail-closed (blocco predefinito in caso di errore).

Per impedire a un amministratore in un account membro di disabilitare il BPA, si applica una Service Control Policy a livello di OU di Organizations o della root:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Per servire i contenuti di S3 esclusivamente tramite CloudFront, si collega un Origin Access Control (OAC) — il sostituto moderno del legacy OAI — alla distribuzione e si vincola la policy del bucket all’ARN della distribuzione:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

Il BPA rimane abilitato sul bucket. Per l’accesso a tempo limitato a oggetti privati da parte di un utente specifico (scadenza per upload/download), si genera una presigned URL la cui firma incorporata eredita i permessi del principal che l’ha firmata.

Percorsi di Rete Privati: Gateway Endpoint

Il traffico da EC2 a S3 all’interno di un VPC non utilizza automaticamente il backbone privato di AWS. Senza configurazione, le chiamate API a S3 vengono risolte verso endpoint pubblici e attraversano l’internet gateway o il NAT gateway, comportando costi di elaborazione dati del NAT ed esponendo il traffico a Internet. Un gateway VPC endpoint per S3 (e DynamoDB) è gratuito, viene aggiunto come rotta di tipo prefix-list nelle tabelle di routing specificate e mantiene il traffico sulla rete AWS. Esistono anche gli interface endpoint (PrivateLink) per S3, che sono a pagamento e utili quando l’accesso proviene da ambienti on-premise tramite Direct Connect. Si abbina l’endpoint a una condizione aws:SourceVpce nella policy del bucket per imporre che il bucket sia raggiungibile solo da VPC endpoint approvati — il pattern standard per i carichi di lavoro regolamentati.

Object Lambda per la Trasformazione On-the-Fly

S3 Object Lambda inserisce una funzione Lambda nel percorso delle richieste GET/HEAD/LIST, in modo che l’oggetto restituito al chiamante venga trasformato al momento della lettura. Questo evita di duplicare i dati per ogni variante (redatta, ridimensionata, riformattata) e mantiene un’unica fonte di verità (source of truth) nel bucket sottostante. Casi d’uso tipici: redazione di PII per gli analisti rispetto ai dati completi per gli auditor, aggiunta di watermark alle immagini per utente, conversione da XML a JSON per client legacy. Le policy IAM e del bucket continuano a controllare l’accesso all’oggetto sottostante; la Lambda vede solo ciò che il suo execution role le permette.

Notifiche di Eventi

S3 emette eventi (s3:ObjectCreated:*, s3:ObjectRemoved:*, eventi di replica e di lifecycle) verso Lambda, SQS, SNS o EventBridge. EventBridge è da preferire quando si necessita di target multipli, di filtrare sui metadati degli oggetti o di routing cross-account; le notifiche dirette sono più semplici ed economiche per pipeline con un singolo target, come la generazione di thumbnail all’upload. Le notifiche sono di tipo at-least-once (almeno una volta), quindi i consumer devono essere idempotenti.

Ottimizzazione del Throughput: Multipart Upload e Transfer Acceleration

Per oggetti superiori a 100 MB, il multipart upload è una best practice; sopra i 5 GB è obbligatorio. Le parti vengono caricate in parallelo, le parti fallite vengono ritentate indipendentemente e il throughput scala con la concorrenza. Le richieste GET con byte-range offrono un parallelismo equivalente per i download. Come già detto, è fondamentale associare sempre una regola di lifecycle AbortIncompleteMultipartUpload per evitare l’addebito per le parti orfane.

S3 Transfer Acceleration instrada gli upload attraverso l’edge di CloudFront più vicino, sfruttando il backbone di AWS — da usare per client distribuiti a livello globale che caricano file su un unico bucket. Per i download, si posiziona CloudFront davanti a S3 per la cache all’edge. Transfer Acceleration è orientato all’upload; CloudFront è orientato al download; risolvono problemi correlati ma distinti.

EBS: Tipi di volumi, crittografia e snapshot

I volumi EBS sono dispositivi a blocchi con scope a livello di AZ, collegati a una singola istanza EC2. gp3 è l’SSD general-purpose predefinito; il suo vantaggio cruciale rispetto a gp2 è che gli IOPS (fino a 16.000) e il throughput (fino a 1.000 MiB/s) vengono forniti indipendentemente dalla capacità, eliminando l’anti-pattern di gp2 che consisteva nel sovradimensionare lo storage solo per raggiungere gli obiettivi di performance. io2 Block Express offre fino a 256.000 IOPS con latenza inferiore al millisecondo per database sensibili alla latenza. st1 e sc1 sono basati su HDD per carichi di lavoro sequenziali orientati al throughput e per carichi di lavoro “cold”. La funzione Multi-Attach su io1/io2 esiste ma è limitata a 16 istanze nella stessa AZ che eseguono un file system cluster-aware: un’eccezione specifica, non un modello generale di “EBS condiviso”. Tentare di collegare un volume EBS a più istanze (ad esempio, dietro un load balancer) è un errore concettuale che produce esattamente il sintomo “alcuni documenti sono visibili al refresh, altri no”, poiché ogni volume è un dispositivo a blocchi privato.

I volumi EBS sono crittografati at-rest con AES-256 utilizzando chiavi dati gestite tramite KMS. La crittografia è trasparente: nessuna penalità sulle prestazioni, nessuna modifica all’applicazione. Una volta che un volume è crittografato, gli snapshot e i volumi derivati sono anch’essi crittografati; non è possibile decrittografare un volume esistente. Abilita la crittografia EBS di default per Regione in modo che ogni nuovo volume e snapshot sia crittografato, indipendentemente da ciò che ricorda lo sviluppatore:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

I volumi non crittografati esistenti non vengono crittografati retroattivamente: la soluzione richiede la creazione di uno snapshot, la sua copia con crittografia e la creazione di un nuovo volume dallo snapshot crittografato.

Gli snapshot sono backup incrementali a livello di blocco archiviati su un’infrastruttura gestita da S3, ma non sono gratuiti (si paga per i blocchi modificati conservati), non scompaiono quando il volume di origine viene eliminato e non vengono rimossi quando un’AMI che li referenzia viene deregistrata. Spostali nel tier EBS Snapshots Archive (75% più economico, ripristino in 24-72 ore) tramite aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) o AWS Backup. Fast Snapshot Restore (FSR) pre-carica uno snapshot in specifiche AZ in modo che le istanze avviate da esso offrano immediatamente le massime prestazioni: abilitalo per le AMI dietro gruppi di auto-scaling che devono gestire rapidi scale-out.

Il Recycle Bin (Cestino) cattura gli snapshot EBS e le AMI eliminate in una finestra di ripristino (da 1 giorno a 1 anno). Senza di esso, l’eliminazione di uno snapshot è immediata e permanente:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Affidarsi esclusivamente a snapshot EBS giornalieri per la conservazione dei dati a lungo termine per la conformità è un errore architetturale comune: il prezzo degli snapshot è più vicino a quello dello storage “warm” e richiedono transizioni esplicite verso l’archiviazione.

Amazon EFS: File system POSIX condiviso per flotte Linux

EFS è un file system NFSv4.1 completamente gestito, elastico e conforme a POSIX, montabile simultaneamente da migliaia di client EC2, ECS, EKS o Lambda in più AZ di una Regione, e da host on-premise tramite Direct Connect o VPN. La sua proprietà distintiva è che lo stesso file system, con identici file handle e semantica a livello di byte, è visibile a ogni client contemporaneamente. EFS è quindi la risposta corretta ogni volta che una flotta Linux dietro un load balancer deve condividere un set comune di file: upload degli utenti, file di configurazione, home directory condivise.

I mount target risiedono in ogni sottorete di AZ configurata. L’utility amazon-efs-utils abilita la crittografia TLS in transito e l’autorizzazione al mount tramite IAM:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

Le classi di storage di EFS si estendono su due dimensioni. La gestione del ciclo di vita sposta i file non utilizzati per 7-90 giorni da Standard a Infrequent Access e, opzionalmente, ad Archive, riducendo i costi di storage fino al 92%; Intelligent-Tiering li riporta indietro al primo accesso. Le classi One Zone archiviano i dati in una singola AZ con un costo inferiore di circa il 47%: sono appropriate per ambienti di dev/test o per dati riproducibili, ma mai per dati la cui perdita durante un guasto di una AZ sarebbe inaccettabile. Una mossa per ottimizzare i costi per un carico di lavoro già su EFS Standard-IA è passare a EFS One Zone-IA senza alcuna modifica all’applicazione.

Le prestazioni hanno due controlli indipendenti. Modalità di performance (impostata alla creazione): General Purpose ha la latenza più bassa ed è corretta per il web serving con molti metadati; Max I/O è un’opzione legacy superata da Elastic. Modalità di throughput: Bursting scala con la dimensione (50 KB/s per GB di baseline, con crediti di burst quando si è al di sotto della baseline), Provisioned paga per un valore fisso di MB/s indipendente dalla dimensione, ed Elastic — l’attuale default — scala automaticamente fino a 10+ GB/s senza necessità di pianificazione della capacità. Un file system di piccole dimensioni sotto carico sostenuto può esaurire i crediti di burst e subire un throttling a una baseline bassa, quindi i carichi di lavoro con I/O intensivo ma di piccole dimensioni devono utilizzare la modalità Elastic o Provisioned.

EFS non è un sostituto per lo storage a blocchi ad alti IOPS. Ogni I/O su EFS è una chiamata RPC NFS sulla rete, quindi i carichi di lavoro di tipo single-writer, con latenza inferiore al millisecondo e simili a log transazionali, dovrebbero essere su EBS io2 Block Express: un singolo volume offre 256.000 IOPS con latenza sub-millisecondo, cosa che EFS non può eguagliare su base per-operazione. EFS è anche estremamente costoso per i dati “cold” rispetto a Deep Archive; conservare i dati di conformità su EFS “perché è facile” è ingiustificabile.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx è una famiglia di file system gestiti, selezionati in base al protocollo e al carico di lavoro:

FSx for Windows File Server fornisce SMB 2.0/3.1.1 nativo con ACL NTFS, DFS Namespaces, shadow copy e Kerberos su Active Directory. Le implementazioni Multi-AZ distribuiscono un file server attivo in una AZ con uno standby replicato in modo sincrono in un’altra e un unico nome DNS di failover. L’integrazione con AD non è opzionale: FSx deve unirsi a un AWS Managed Microsoft AD o a un AD autogestito raggiungibile, e i client si autenticano come utenti di dominio rispetto ai SID di dominio. Omettere l’AD, o puntare i client a un file system in una forest non attendibile senza un trust tra forest, produce il classico sintomo di accesso negato nonostante la condivisione sia visibile. FSx for Windows è la destinazione “drop-in” (pronta all’uso) per il lift-and-shift di condivisioni di file Windows.

FSx for Lustre è un file system POSIX parallelo per HPC, training di ML, EDA e genomica — migliaia di client, throughput di centinaia di GB/s, metadati con latenza inferiore al millisecondo. La sua caratteristica AWS fondamentale è l’associazione del repository di dati (data repository association) con S3: le chiavi degli oggetti appaiono come file nel namespace di Lustre e vengono caricate “lazy” (al primo accesso) o precaricate tramite

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

; i file nuovi/modificati vengono riesportati su S3 secondo una pianificazione o su richiesta. Il pattern canonico per l’HPC è:

1. Copiare i dataset on-premise su S3 (tramite DataSync o Storage Gateway).
2. Creare un file system Lustre collegato a quel bucket.
3. Montarlo su tutti i worker Spot; leggere input e scrivere output alla massima velocità.
4. Esportare i risultati su S3, che rimane il repository durevole a lungo termine.
5. Eliminare il file system Lustre al termine del processo.

Le implementazioni Lustre di tipo Scratch non hanno replica e perdono i dati in caso di guasto hardware — sono le più economiche e veloci, adatte per dati di processi transitori. Le implementazioni di tipo Persistent replicano i dati all’interno di una AZ per una maggiore durabilità. Il throughput viene fornito in MB/s per TiB (50/125/250/500/1000), disaccoppiando la capacità dalle prestazioni.

FSx for NetApp ONTAP è la risposta multi-protocollo: NFS, SMB e iSCSI simultaneamente sugli stessi dati, con snapshot, replica SnapMirror, FlexClone e deduplica. Scegliere ONTAP quando si consolidano condivisioni miste Linux NFS e Windows SMB che necessitano di accesso cross-protocollo con ridondanza Multi-AZ, o quando si migra da sistemi NetApp on-premise. FSx for OpenZFS copre una nicchia per carichi di lavoro Linux che necessitano di funzionalità ZFS (snapshot, cloni) su NFS. Non confondere la forza multi-protocollo di ONTAP con le altre varianti.

Scegliere male porta a un fallimento netto: EBS per un carico di lavoro condiviso, EFS per una condivisione SMB Windows, o Lustre per una condivisione Windows integrata con AD sono tutte scelte inadatte — abbinare prima il protocollo e il pattern di accesso.

Storage Gateway: Accesso Ibrido

Storage Gateway presenta lo storage cloud come se fosse locale. Questo è diverso da DataSync, che sposta i dati.

Per un’applicazione di rendering che ha spostato la sua libreria multimediale su S3 ma necessita ancora di letture a bassa latenza on-premise, S3 File Gateway è la soluzione adatta — accesso NFS/SMB, cache locale, oggetti ad accesso sporadico recuperati da S3 su richiesta. FSx File Gateway è la risposta per le filiali: una cache SMB a velocità LAN di una condivisione FSx cloud centrale, non una soluzione per l’accesso condiviso tra istanze EC2 (che dovrebbero montare FSx direttamente). Volume Gateway si applica quando il carico di lavoro utilizza il protocollo a blocchi iSCSI anziché semantiche di file. Tape Gateway sostituisce le librerie a nastro fisiche sotto il software di backup esistente.

Trasferimento e Migrazione dei Dati

AWS DataSync è un servizio di migrazione online basato su agent per NFS, SMB, HDFS e object store verso S3, EFS o FSx — fino a 10 volte più veloce degli strumenti open-source, con crittografia, verifica dell’integrità, pianificazione e conservazione dei metadati POSIX e degli ACL NTFS. Per una migrazione SMB su larga scala con milioni di file di piccole dimensioni e gerarchie profonde, la risposta con il minor overhead è DataSync verso FSx for Windows: il protocollo SMB viene preservato, ACL e timestamp rimangono intatti, il throughput per i file di piccole dimensioni è gestito tramite trasferimenti paralleli, nessuna modifica all’applicazione. Migrare un tale dataset direttamente in S3 è una trappola: l’object storage gestisce male l’elenco di file di piccole dimensioni in prefissi profondi e i client SMB non possono montare i bucket.

AWS Snow Family spedisce appliance fisiche per il trasferimento offline: Snowcone (fino a 8 TB, robusto per l’edge), Snowball Edge (fino a ~80 TB utilizzabili, con opzioni di calcolo) e Snowmobile (scala exabyte). Regola pratica: se il trasferimento via rete richiedesse più di una settimana, Snowball è più economico e veloce.

AWS Transfer Family espone SFTP, FTPS, FTP e AS2 supportati da S3 o EFS — la risposta giusta quando i partner esterni devono continuare a utilizzare protocolli di trasferimento file standard.

AWS Backup, Copia tra Regioni e Vault Lock

AWS Backup centralizza le policy tra EBS, EFS, FSx, RDS, DynamoDB, S3 e altro ancora. Un piano di backup definisce la pianificazione, la conservazione a caldo (warm retention), la transizione allo storage a freddo (cold storage) e le azioni di copia tra regioni/account:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

La transizione allo storage a freddo richiede almeno 90 giorni di conservazione a caldo più almeno 90 giorni a freddo; i cicli di vita configurati in modo errato vengono rifiutati. Per una vera conservazione normativa pluriennale, abbinalo a AWS Backup Vault Lock (WORM), che impedisce persino agli amministratori di abbreviare il periodo di conservazione, soddisfacendo così la normativa SEC 17a-4 e mandati simili. La copia tra regioni (Cross-Region) risponde alle esigenze di DR regionale; la copia tra account (cross-account) affronta scenari di ransomware e minacce interne isolando i backup dal raggio d’impatto (blast radius) dell’account di produzione.

Guida Rapida alla Scelta

← Architetture Serverless e Guidate dagli Eventi · Tutti i domini · Trasferimento e Migrazione dei Dati →

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

Sfoglia Amazon →