Amazon SAA-C03: Trasferimento e Migrazione 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.

La decisione: larghezza di banda o spedizione fisica

Ogni migrazione inizia con un calcolo matematico. Calcola il tempo di trasferimento teorico prima di scegliere uno strumento:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

I numeri non perdonano. A 100 Mbps sostenuti, per 1 TB sono necessarie circa 24 ore; a 1 Gbps, circa 2,5 ore. Un collegamento da 15 Mbps limitato al 70% di utilizzo trasferisce solo ~113 GB al giorno, quindi per 20 TB sarebbero necessari più di 175 giorni. Trasferire 150 TB durante la notte (10 ore all'80% di 100 Mbps) produce ~360 GB a notte, ovvero 10,5 TB al mese — ben lontano da una scadenza di 30 giorni. Anche con una saturazione completa 24/7, 100 Mbps spostano solo ~1 TB al giorno, quindi per 150 TB sono necessari un minimo di 150 giorni. Su scala petabyte, il quadro peggiora: un collegamento da 500 Mbps con un’efficienza reale offre un throughput teorico di circa 5,4 TB al giorno, il che significa che per 10 PB sarebbero necessari più di cinque anni di trasferimento continuo — più tempo di quanto ne richieda il provisioning della maggior parte dei circuiti Direct Connect.

Una regola pratica ragionevole:

La singola risposta errata più comune negli scenari di migrazione è la scelta di un trasferimento WAN che matematicamente non può essere completato entro i tempi previsti. L’errore correlato — “lo eseguiremo semplicemente ogni notte sulla WAN” — non è solo più lento. Consuma la larghezza di banda di produzione, rischia trasferimenti parziali o corrotti che richiedono nuovi caricamenti e, in genere, costa di più una volta conteggiati i costi della larghezza di banda e il tempo degli ingegneri. Il costo di un’unità Snowball più la spedizione è una voce di spesa fissa e prevedibile.

La famiglia Snow per il trasferimento massivo offline

I dispositivi Snowball Edge sono disponibili in due varianti:

Snowcone è il fattore di forma ridotto (~8 TB SSD), rinforzato e spedibile tramite corriere, utile per siti con spazio limitato e precaricato con agenti DataSync per la sincronizzazione all’edge. Snowmobile — un container da 45 piedi che trasporta fino a 100 PB — era destinato a evacuazioni di data center su scala exabyte, ma è stato deprecato nella maggior parte delle region a favore di flotte parallele di Snowball Edge. Selezionare Snowmobile per qualsiasi cosa al di sotto di un petabyte è una risposta fuorviante.

La variante Compute non è solo un disco più capiente. Esegue localmente AMI EC2, funzioni Lambda e carichi di lavoro Greengrass, rendendola la scelta giusta quando i dati devono essere trasformati, filtrati o le PII (informazioni di identificazione personale) devono essere oscurate prima dell’ingestione, quando un carico di lavoro deve riprendere immediatamente in AWS dopo l’ingestione, o quando il sito è disconnesso o connesso a intermittenza (navi, siti minerari remoti, impieghi tattici, ricerca in aree remote). Scegliere la versione Compute Optimized quando è richiesta l’elaborazione sul dispositivo; scegliere la versione Storage Optimized quando il carico di lavoro è una pura copia massiva.

Ogni dispositivo Snow esegue la crittografia a 256 bit dei dati a riposo (at-rest) utilizzando chiavi KMS che non lasciano mai AWS. Gli involucri sono a prova di manomissione (tamper-evident), con un’etichetta di spedizione E Ink e un Trusted Platform Module hardware. I dati sul dispositivo vengono scritti utilizzando il client Snowball, l’endpoint compatibile con S3 o un mount NFS; il protocollo TLS protegge i dati in transito durante l’ingestione e lo scambio del manifesto di spedizione. Al rientro, il contenuto viene ingerito in S3 e il dispositivo viene cancellato crittograficamente secondo lo standard NIST 800-88.

Per lavori su scala petabyte per sito, il parallelismo è il modello da seguire. Un ufficio con una capacità di collegamento di 1–2 Gbps impiegherebbe comunque mesi di saturazione continua per spostare 1 PB online; una flotta di circa 13 dispositivi Storage Optimized per sito (da 80 TB ciascuno) spediti in parallelo consente di rispettare una scadenza di quattro settimane, risparmiando il collegamento Internet dell’ufficio. Per un lavoro da 600 TB in due settimane su un collegamento saturo da 100 Mbps, una piccola flotta in parallelo è l’unica risposta corretta — anche ignorando i costi, le leggi della fisica rendono impossibili DataSync o un nuovo Direct Connect.

DataSync per Trasferimenti Online, Verificati e Incrementali

DataSync è lo strumento giusto quando la larghezza di banda è sufficiente ma le caratteristiche del carico di lavoro — milioni di file di piccole dimensioni, alberi di directory profondi, sincronizzazioni incrementali continue o migrazioni tra file system diversi — metterebbero in crisi strumenti più semplici. Una directory con 20 milioni di file da 4 KB copiata con aws s3 cp ha come collo di bottiglia la latenza di round-trip, non il throughput; ogni PutObject comporta un round-trip TLS/HTTP e un addebito per la richiesta API. Raggruppare i file in archivi funziona, ma fa perdere l’indirizzabilità per singolo file. L’agente di DataSync parallelizza il trasferimento su molti stream TCP, gestisce i metadati in modo nativo, verifica ogni file end-to-end con un checksum SHA-256, esegue i tentativi di ritrasmissione in modo trasparente e invia report a CloudWatch, raggiungendo fino a ~10 Gbps per agente con un prezzo prevedibile per GB.

Le origini e le destinazioni includono NFS, SMB, HDFS, object store autogestiti, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS e FSx for NetApp ONTAP. I trasferimenti utilizzano TLS 1.2 in transito e possono passare attraverso endpoint di interfaccia VPC per rimanere al di fuori della rete internet pubblica.

Un dettaglio fondamentale: DataSync richiede un agente per le origini on-premise NFS/SMB. L’agente viene eseguito come VM su VMware, Hyper-V o KVM, su EC2 o su Snowcone. Credere che DataSync sia agentless per l’on-premise è una trappola comune: è agentless solo quando entrambi gli endpoint sono servizi nativi AWS.

Una configurazione minima:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Due funzionalità operative sono importanti. La limitazione della larghezza di banda (BytesPerSecond) evita di saturare un collegamento condiviso, rispondendo direttamente a scenari del tipo “collegamento da 1 Gbps condiviso con altri reparti”. Filtri e pianificazione consentono sincronizzazioni fuori orario e l’esclusione di file temporanei. Su una connessione Direct Connect da 10 Gbps con utenti che continuano a leggere e scrivere, la pianificazione di attività ripetute è il pattern canonico: la scansione iniziale trasferisce la maggior parte dei dati, le esecuzioni incrementali successive catturano le differenze (delta), e un volume di 700 TB può essere trasferito in molto meno di una settimana anche con un utilizzo parziale.

Una trappola più sottile riguarda la fedeltà dei metadati. DataSync preserva un insieme selezionato di attributi POSIX o SMB — UID/GID/mode/timestamp per NFS, proprietà e DACL per SMB — ma non cattura ogni attributo proprietario del NAS. ACL specifiche del fornitore, attributi estesi oltre a quelli esposti dal protocollo, snapshot e metadati di deduplica non rientrano nel suo ambito di applicazione. Quando la conformità richiede una replica esatta del NAS che includa le funzionalità del fornitore, il solo DataSync non è sufficiente; è necessario un percorso compatibile con NetApp, come FSx for ONTAP con SnapMirror, o un lift-and-shift tramite Storage Gateway.

DataSync completa anche Snowball: Snowball sposta i 150 TB iniziali, e DataSync gestisce successivamente il delta settimanale di un working set da 500 GB.

Storage Gateway: Presentazione Ibrida, non Migrazione

Storage Gateway non è uno strumento di migrazione, ma un livello di presentazione ibrido. Le applicazioni on-premise continuano a comunicare tramite NFS, SMB, iSCSI o iSCSI-VTL, mentre i dati vengono archiviati in S3, S3 Glacier o come snapshot EBS. Confondere Storage Gateway con DataSync è un errore frequente: File Gateway non è progettato per spostare 70 TB in fretta, e DataSync non presenta una condivisione persistente ai client on-premise.

File Gateway è il cavallo di battaglia. Scrivendo \\gateway\share\reports\2024\report.pdf si produce s3://bucket/reports/2024/report.pdf, un oggetto utilizzabile nativamente da Athena, Lambda, EMR o qualsiasi client S3. Questa mappatura uno-a-uno da file a oggetto è un vantaggio significativo rispetto alle destinazioni di backup a scatola chiusa (black-box). La cache locale permette di restituire i file utilizzati di frequente alla velocità della LAN, mentre i file meno recenti vengono trasmessi in streaming da S3 su richiesta.

La cache è il punto focale dell’appliance. Le letture dei dati utilizzati di frequente vengono servite localmente; le scritture vengono prima salvate sul disco locale e poi caricate in modo asincrono. Un errore di progettazione comune è presumere che il backend su S3 implichi che ogni lettura comporti una latenza di round-trip su internet: non è così, a condizione che il working set rientri nella cache. Al contrario, un sottodimensionamento della cache causa continui cache miss e il carico di lavoro appare “lento”. Come regola generale: cache = 20% del dataset totale o 100% del working set attivo, a seconda di quale sia il valore maggiore.

La trappola della modalità Cached rispetto a quella Stored merita un’attenzione particolare. La modalità Cached mantiene la copia primaria in S3, con i blocchi usati di frequente in locale: è una soluzione economica ed elastica, ma un cache miss comporta un round-trip sulla WAN. La modalità Stored mantiene la copia primaria sul disco locale, con snapshot asincroni su S3 come snapshot EBS: ogni lettura è locale e a bassa latenza, ma l’intero dataset deve poter essere ospitato on-premise. Per un requisito di sostituzione del backup come “accesso locale a tutti i dati mentre ne viene eseguito il backup su AWS”, la modalità Stored è quella corretta; la modalità Cached violerebbe tale requisito. Scegliere la modalità Cached per un carico di lavoro che necessita dell’intero dataset a bassa latenza vanifica il design; scegliere la modalità Stored quando il sito non può ospitare l’intero dataset è impossibile per definizione.

Tape Gateway risponde a un’esigenza molto specifica: ritirare una libreria a nastri fisica mantenendo intatti i workflow di Veeam, NetBackup o Commvault, presentando una VTL tramite iSCSI, con un ciclo di vita dei dati che li sposta da S3 a Glacier o Deep Archive. È uno strumento preziosissimo quando i requisiti normativi sulla conservazione dei dati sono definiti in termini di supporti a nastro e il software di backup esistente non può essere modificato.

AWS Transfer Family

Transfer Family fornisce endpoint completamente gestiti per SFTP, FTPS, FTP e AS2, supportati da S3 o EFS. La proposta di valore consiste nel preservare i contratti di protocollo rivolti ai partner: i sistemi dei fornitori che emettono file solo tramite SFTP continuano a farlo senza modifiche, mentre l’endpoint di ricezione è S3 nativo, con policy di lifecycle, trigger Lambda e integrazione con strumenti di analisi.

La trappola qui è presumere che un fornitore legacy possa semplicemente “passare alle API di S3”. Molti sistemi dei fornitori sono appliance, feed HL7 ospedalieri, sistemi batch bancari o pipeline EDI B2B il cui client SFTP è integrato nel firmware o in binari firmati. I costi di change management, revisione della sicurezza e ricertificazione per modificarli spesso superano l’intero costo della migrazione ad AWS. Transfer Family aggira completamente questo problema. Il supporto AS2 abilita inoltre carichi di lavoro EDI con ricevute MDN e firma/crittografia dei messaggi per la conformità B2B.

L’autenticazione supporta utenti gestiti dal servizio, AWS Directory Service (Managed Microsoft AD o AD Connector per AD on-premise), o un identity provider personalizzato tramite API Gateway/Lambda, permettendo alle credenziali aziendali esistenti di rimanere la fonte di verità. Un authorizer Lambda può restituire ruoli IAM, mappature di home directory e policy di sessione specifici per utente, fornendo isolamento per ogni fornitore senza un’infrastruttura dedicata per ciascuno.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow è il livello di integrazione gestito per il trasferimento di dati da SaaS ad AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk e decine di altri possono essere trasferiti in S3, Redshift o Snowflake. Gestisce la paginazione, l’estrazione incrementale, la mappatura dei campi, il filtraggio, il mascheramento e la validazione senza la necessità di un processo ETL scritto manualmente.

La funzionalità critica per la sicurezza è l’integrazione con PrivateLink per i connettori supportati (in particolare Salesforce). Invece di uscire sulla rete internet pubblica per raggiungere il tenant SaaS e tornare in AWS, il flusso attraversa un endpoint VPC privato, eliminando l’esposizione su internet dei dati estratti e semplificando la postura di audit per carichi di lavoro sanitari, finanziari e con dati PII. I flussi possono essere pianificati, attivati da eventi di modifica dei record nel SaaS, o eseguiti on-demand, e supportano fino a 100 GB per esecuzione.

AppFlow opera a un livello superiore rispetto a DataSync o Storage Gateway: è lo strumento giusto quando la sorgente è un SaaS basato su API, non un filesystem o un database.

Migrazione di Database: DMS e SCT

AWS Database Migration Service replica i dati tra database di origine e di destinazione mentre la sorgente rimane pienamente operativa. Supporta migrazioni omogenee (MySQL → RDS MySQL, Oracle → RDS Oracle) ed eterogenee (Oracle → Aurora PostgreSQL, SQL Server → MySQL), e le destinazioni si estendono oltre RDS includendo Aurora, Redshift, S3, DynamoDB e Kinesis. Le sorgenti includono Oracle, SQL Server, MySQL, PostgreSQL, MongoDB e Db2.

Un task opera in una delle tre modalità:

Il motore del cutover a downtime minimo è il Change Data Capture. Durante un’operazione di caricamento completo + CDC, DMS esegue una copia massiva delle righe esistenti mentre estrae dati dal transaction log della sorgente — redo log di Oracle, binlog di MySQL, MS-CDC o MS-Replication di SQL Server. Una volta completato il caricamento completo, il CDC applica le modifiche in coda e mantiene la destinazione continuamente aggiornata fino al momento del passaggio dell’applicazione. Non abilitare il CDC quando l’applicazione deve rimanere scrivibile è un errore architetturale comune: la modalità di solo caricamento completo rende la destinazione obsoleta non appena il caricamento termina.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Per il lavoro eterogeneo, l’AWS Schema Conversion Tool (o il suo equivalente cloud DMS Schema Conversion) traduce DDL, stored procedure, viste e funzioni, segnalando gli elementi che richiedono una riscrittura manuale. DMS sposta i dati; SCT converte lo schema. Saltare il report di valutazione di SCT è il modo in cui le migrazioni falliscono tre giorni prima del cutover.

I prerequisiti e le limitazioni specifici di ogni motore di database possono creare seri problemi se ignorati. I LOB di Oracle superiori a 64 KB richiedono la modalità LOB limitata (limited LOB mode) con un massimo fisso; LONG RAW ha delle avvertenze. PostgreSQL richiede wal_level=logical e un ruolo di replicazione. MySQL richiede il binary logging in formato ROW con un binlog_row_image sufficiente e privilegi elevati per il CDC (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, i comportamenti specifici di RAC e gli assembly CLR di SQL Server sono comunemente non supportati. Il TLS è applicato tra l’istanza di replicazione e gli endpoint, con le modalità SSL require, verify-ca o verify-full.

DMS Serverless è la scelta corretta quando il profilo del carico di lavoro è imprevedibile o soggetto a picchi — ad esempio, un sistema Oracle on-premise con picchi diurni e notti tranquille. Si definiscono MinCapacityUnits e MaxCapacityUnits in DCU (DMS Capacity Units) e DMS scala la capacità di replicazione in base alla pressione su CPU e memoria:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Una trappola frequente è presumere che un’istanza DMS provisioned (ad es., dms.c5.4xlarge) si auto-scalerà. Non lo farà — le istanze provisioned sono host EC2 di dimensioni fisse. Se il throughput supera la capacità, il ritardo di replicazione (replication lag) aumenta e bisogna modificare manualmente la classe dell’istanza, riavviando i task. DMS provisioned è adatto a migrazioni a stato stazionario con throughput noto; Serverless è adatto a quelle imprevedibili.

Per una migrazione MySQL da 20 TB con una finestra di due settimane e tempi di inattività ridotti, DMS con caricamento completo più CDC verso Aurora MySQL o RDS MySQL è la soluzione più conveniente. I ripristini nativi con mysqldump/mysqlpump comportano tempi di inattività inaccettabili; Snowball aggiunge latenza di spedizione e intervalli di disconnessione.

DMS Fleet Advisor rileva gli inventari dei database on-premise, utile per la pianificazione a ondate (wave planning).

Migrazione di server: AWS Application Migration Service (MGN)

AWS Application Migration Service è il servizio principale per il lift-and-shift (“rehost”) e ha sostituito CloudEndure Migration e Server Migration Service per la maggior parte dei casi d’uso. MGN installa un leggero AWS Replication Agent su ogni server di origine (fisico, VMware, Hyper-V o un altro cloud). L’agente esegue uno snapshot iniziale a livello di blocco in un’area di staging a basso costo nel VPC di destinazione — piccole istanze T3 con volumi EBS collegati — e poi replica continuamente le modifiche a livello di blocco in modo asincrono. Poiché la replica è continua e a livello di blocco, il cutover si misura in minuti: MGN converte i volumi di staging in istanze EC2 di produzione del tipo di istanza di destinazione al momento del cutover.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

I lanci di test sono essenziali e spesso vengono saltati. MGN avvia istanze di test isolate dallo stato di replica corrente senza interrompere la replica in corso. Si convalida il comportamento dell’applicazione, si scarta il test, si itera e si avvia il cutover solo quando i test hanno esito positivo — il cutover interrompe la replica, lancia l’istanza finale e contrassegna la wave come completata.

L’approccio sbagliato consiste nell’esportare manualmente le VM in formato OVF, caricarle tramite aws ec2 import-image e reinstallare le applicazioni su istanze EC2 appena provisionate. Questo processo è lento, soggetto a errori, richiede un downtime per ogni VM pari alla durata dell’esportazione, non fornisce alcuna replica delta e non offre test non distruttivi. MGN elimina tutto questo: il server di origine continua a funzionare fino all’ultimo secondo del cutover finale e la deriva (drift) tra origine e destinazione è essenzialmente zero.

La linea guida generale del portfolio è di eseguire prima il rehost, per poi passare al re-platform o al refactor all’interno della Region, dove il costo dell’iterazione è inferiore. Eseguire refactor e migrazione simultaneamente moltiplica i rischi senza un beneficio che li compensi.

Connettività ibrida: Direct Connect e VPN

AWS Direct Connect fornisce un circuito dedicato di Livello 2 da un router on-premise a una location Direct Connect, offrendo una larghezza di banda costante (1, 10, 100 Gbps dedicati; sotto 1 Gbps tramite connessioni ospitate da partner) e una latenza prevedibile. Le Virtual Interface (VIF) partizionano il circuito:

• Private VIF — accesso a un singolo VPC tramite un Virtual Private Gateway.
• Transit VIF — accesso a molti VPC tramite un Direct Connect Gateway collegato a un Transit Gateway. Questo è il pattern canonico per ambienti di grandi dimensioni con più VPC e più siti.
• Public VIF — accesso agli endpoint dei servizi pubblici AWS (S3, DynamoDB) senza passare per Internet.

DX non è, di per sé, ad alta disponibilità: un singolo circuito in una singola location DX dipende da un unico percorso in fibra. Sono importanti due pattern di resilienza:

1. DX + backup con VPN Site-to-Site su Internet è l’alta disponibilità minima praticabile. BGP gestisce il failover automatico con AS-path prepending, MED o local-pref per preferire DX in condizioni normali (steady state).
2. Doppio circuito DX in location DX separate è il pattern a massima resilienza per carichi di lavoro mission-critical ed è richiesto per lo SLA di DX.

Non predisporre alcun percorso di backup è una trappola ben nota: quando DX si guasta e non c’è una VPN, le app ibride, i job di DataSync e gli upload di Storage Gateway si bloccano per tutta la durata della riparazione da parte del carrier. Una soluzione solo VPN è accettabile per carichi di lavoro a basso throughput o come soluzione ponte mentre si attende il provisioning di DX, che può richiedere settimane.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Laddove è richiesta la crittografia a livello fisico, scegliere una connessione DX con MACsec abilitato. La combinazione di DX per la larghezza di banda, DataSync per l’orchestrazione e Storage Gateway per l’accesso locale continuo è il pattern ibrido canonico per dataset di grandi dimensioni e attivi che non possono tollerare una finestra di downtime.

AWS Outposts per l’infrastruttura AWS on-premise

Outposts estende l’infrastruttura AWS all’interno della struttura di un cliente come un rack (o server Outposts 1U/2U) completamente gestito. Esegue localmente un insieme selezionato di servizi — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — con le stesse API della Region madre. Le operazioni del control plane ritornano alla Region madre tramite un service link composto da tunnel crittografati ridondanti; un’interruzione della WAN impedisce temporaneamente il lancio di nuove istanze ma non ferma i carichi di lavoro in esecuzione.

La suddivisione della responsabilità condivisa è la trappola in cui cadono gli operatori. AWS fornisce e manutiene l’hardware, l’hypervisor e i servizi gestiti. Il cliente è responsabile di:

• Spazio fisico, alimentazione, raffreddamento e networking che soddisfino le specifiche di Outposts (alimentatori ridondanti, switch upstream, PDU appropriate).
• Sicurezza fisica della struttura.
• Configurazione della rete locale — il Local Gateway (LGW) per il traffico on-premise e l’uplink del service link.
• Aspetti legati al sistema operativo e alle applicazioni dei carichi di lavoro, esattamente come nella Region.
• Connettività WAN adeguata verso la Region madre.

Outposts non elimina le operazioni, ma ne sposta l’astrazione. Presumere che AWS sia responsabile dell’alimentazione del data center o della rete upstream è un errore di interpretazione fondamentale. Inoltre, non significa “eseguire qualsiasi servizio AWS on-premise”: l’elenco dei servizi supportati è finito e servizi come Route 53 o IAM rimangono basati sulla Region.

Per una modernizzazione di Hadoop/Spark in cui i dati devono rimanere on-premise per motivi normativi, EMR on Outposts è il pattern corretto: cluster Spark gestiti ed elastici con gli strumenti della Region e la residenza dei dati locale. Storage Gateway o DataSync non soddisfano il requisito di residenza; un lift-and-shift verso EMR nella Region non rispetta la conformità.

Distribuzione di Contenuti a Flotte Edge

Quando server Outposts, negozi al dettaglio o dispositivi edge scaricano ripetutamente lo stesso payload di grandi dimensioni — ad esempio una release software notturna — il download diretto da un bucket S3 in una singola Regione satura gli uplink e aumenta i tempi di deployment. Il pattern corretto è CloudFront con un’origine S3 e URL firmati:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

Il primo dispositivo in una regione “riscalda” la cache edge; ogni dispositivo successivo scarica con la latenza dell’edge. Gli URL firmati impediscono download non autorizzati senza la necessità di credenziali IAM per ogni dispositivo, e non c’è una flotta di repliche regionali da gestire.

Due anti-pattern da evitare: ospitare la release su un singolo server web EC2 (un disastro in termini di scalabilità e latenza), e replicare il bucket S3 in ogni Regione tramite Cross-Region Replication solo per ridurre la latenza di download (costi di storage non necessari e complessità operativa che la cache di CloudFront risolve gratuitamente).

Riepilogo delle Decisioni

← Storage e Ciclo di Vita dei Dati · Tutti i domini · Networking e Connettività →

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

Sfoglia Amazon →