Amazon SAA-C03: Analytics, Data Lake, ML e Carichi di Lavoro Specializzati — 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.

Fondamenti del Data Lake: Lake Formation e il Glue Data Catalog

Il centro di gravità per l’analytics su AWS è l’AWS Glue Data Catalog — un metastore compatibile con Hive Metastore che viene utilizzato da Athena, Redshift Spectrum, EMR e Glue ETL. Ogni definizione di tabella, partizione, tipo di colonna e configurazione SerDe risiede qui, e ogni motore a valle legge da esso. Se due percorsi di ingestione (ad esempio, un crawler di Glue e un’istruzione manuale CREATE EXTERNAL TABLE) non sono d’accordo sullo schema dello stesso prefisso S3, le query restituiscono silenziosamente risultati errati o falliscono. Il pattern corretto è designare un’unica autorità per tabella: o il crawler è proprietario dello schema, oppure il job ETL scrive tramite glueContext.write_dynamic_frame.from_catalog, ma mai entrambi senza una strategia di unione (merge). Quando ETL batch, conversioni Parquet di Firehose e DDL manuali scrivono tutti sulla stessa tabella, la deriva del catalogo (catalog drift) è una minaccia silenziosa. Imponi un unico proprietario per tabella, usa il Glue Schema Registry per i producer di dati in streaming ed esegui i crawler in modalità LOG (non UPDATE_IN_DATABASE) sulle tabelle gestite da job ETL, in modo che evidenzino la deriva senza sovrascrivere gli schemi curati.

AWS Lake Formation si posiziona al di sopra del Data Catalog e sostituisce il modello di policy a grana grossa di IAM/bucket S3 con un livello di permessi in stile database. Invece di concedere s3:GetObject su un prefisso, si esegue GRANT SELECT ON customers.orders TO role/AnalystRole, e Lake Formation fornisce in modo trasparente credenziali a breve termine quando Athena o Redshift Spectrum accedono agli oggetti sottostanti. Il suo vero valore è l’autorizzazione a grana fine: filtraggio a livello di colonna, sicurezza a livello di riga tramite filtri sui dati e controllo degli accessi basato su tag (LF-Tags) che scala su migliaia di tabelle. Una piattaforma di e-commerce con PII (dati personali) in una tabella customers può concedere agli analisti l’accesso a customer_id, region, signup_date bloccando al contempo email e ssn — una regola applicata al momento della query, senza la necessità di creare una proliferazione di viste.

La configurazione canonica per un data lake governato:

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

I blueprint di Lake Formation sono template di workflow preconfigurati che orchestrano crawler, job e trigger per ingerire dati da sorgenti JDBC o S3 in un data lake curato, riducendo quelle che sarebbero dozzine di risorse Glue collegate manualmente a un flusso guidato da un wizard.

Un errore frequente è tentare di applicare restrizioni a livello di colonna solo in QuickSight. QuickSight dispone di sicurezza a livello di riga e di colonna legata ai dataset, ma protegge solo l’interfaccia di QuickSight: chiunque abbia accesso diretto ad Athena o S3 può aggirarla. Il controllo a livello di colonna deve essere applicato al livello dei dati (permessi di Lake Formation o separazione fisica delle colonne durante l’ETL), e QuickSight eredita questa configurazione di sicurezza tramite il suo ruolo IAM.

Athena: SQL Serverless su S3

Athena è un motore serverless basato su Presto/Trino, con un modello di pagamento per query, che legge i dati direttamente da Amazon S3. Nessun cluster da provisionare, nessun passaggio di ETL richiesto prima di eseguire le query e nessun costo quando è inattivo: si paga solo per i byte scansionati (tipicamente 5 $/TB). Questo rende Athena la scelta canonica per l’analisi ad-hoc di file già presenti in S3, che si tratti di log applicativi in JSON, esportazioni in CSV o tabelle di fatti in formato Parquet. Athena necessita di uno schema e di una struttura di partizionamento, che risiedono nel Glue Data Catalog.

Poiché Athena fattura per terabyte scansionato, il formato di archiviazione ha un impatto enorme su costi e latenza. Le due leve su cui agire sono il formato e il partizionamento:

• Formati colonnari (Parquet, ORC) consentono ad Athena di escludere colonne e gruppi di righe (row group). Una query come SELECT sum(amount) FROM orders WHERE region='us-east-1' su dati Parquet legge solo le due colonne di riferimento; su CSV leggerebbe ogni byte di ogni riga.
• Il partizionamento su colonne ad alta selettività (es. dt=2024-03-11/) trasforma una scansione dell’intera tabella in una lettura mirata. Su log di svariati terabyte (CloudFront, ALB, VPC Flow Logs), questa è la differenza tra una query da 0,15 $ e una da 30 $.

La conversione di dati grezzi JSON o CSV in formato Parquet partizionato e compresso con Snappy è quasi sempre la prima leva di ottimizzazione dei costi da azionare. In combinazione con il pushdown della clausola LIMIT, Athena gestisce la maggior parte delle esigenze di analytics su S3 con zero infrastruttura.

Un pattern efficiente in termini di costi per una tabella “readings” archiviata come Parquet partizionato:

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

Saltare l’uso del crawler è un errore comune. Senza una voce nel catalogo, si è costretti a scrivere DDL manuali CREATE EXTERNAL TABLE (una soluzione fragile man mano che gli schemi evolvono) o a usare espedienti di “schema-on-read” che scansionano ogni file. Peggio ancora, senza MSCK REPAIR TABLE o la proiezione delle partizioni (partition projection), Athena scansiona l’intero prefisso a ogni query. I crawler di Glue rilevano nuove partizioni secondo una pianificazione e aggiornano il catalogo in modo atomico.

Athena su dati S3 crittografati. Athena supporta SSE-S3, SSE-KMS e CSE-KMS, ma solo se il chiamante (caller) ha i permessi KMS corretti e il workgroup o il client è configurato per la modalità di crittografia in uso. Per CSE-KMS, il file viene crittografato lato client prima dell’upload; il principal IAM che esegue la query necessita dei permessi kms:Decrypt e kms:GenerateDataKey sulla CMK, e la policy della chiave deve concedere a sua volta i permessi necessari. Un tipico scenario di fallimento: caricare dati Parquet con crittografia CSE-KMS, concedere al ruolo di Athena solo i permessi di lettura S3 e ricevere errori poco chiari come AccessDenied o HIVE_CANNOT_OPEN_SPLIT — l’oggetto è leggibile, ma il testo crittografato (ciphertext) non può essere decifrato. Un altro errore frequente è registrare la tabella con la modalità di crittografia sbagliata (SSE-KMS nelle proprietà della tabella quando gli oggetti sono stati scritti con CSE-KMS); Athena tenta la decrittografia lato server durante la GetObject e il payload restituito è un testo crittografato grezzo che non supera i controlli del magic number di Parquet.

Le query federate di Athena consentono di unire dati S3 con database operazionali (DynamoDB, RDS) senza spostare i dati. Riserva Athena per analisi ad-hoc orientate alla lettura; usa i job di Glue per la modellazione pianificata delle zone curate.

Crawler, Job ETL e Job Bookmark di Glue

I crawler di Glue scansionano i percorsi S3, inferiscono lo schema (incluse le chiavi di partizione dalla struttura delle directory come year=2024/month=01/) e registrano o aggiornano le tabelle nel catalogo. Sono la risposta low-code alla necessità “depositiamo file in S3 e li rendiamo interrogabili”. Pianifica un crawler con esecuzione oraria su un bucket di destinazione (landing bucket) e Athena vedrà immediatamente le nuove partizioni.

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

I job ETL di Glue (Spark, Python shell o Ray) gestiscono la parte di trasformazione. Glue è serverless — si paga per DPU-ora con un minimo di un minuto — e il runtime scala automaticamente i worker. Il pattern dominante è CSV/JSON in input e Parquet partizionato in output:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

La funzionalità operativa fondamentale è il job bookmark: Glue mantiene lo stato di quali file o partizioni ha già elaborato, così le esecuzioni successive leggono solo i dati nuovi. Dimenticare di abilitare i bookmark significa che ogni esecuzione rielabora l’intero dataset dall’inizio, gonfiando linearmente costi e tempi di esecuzione e spesso producendo output duplicati. I bookmark sono abilitati per singolo job e devono essere abbinati a opzioni di origine che li supportano (le origini S3 tramite il reader DynamicFrame di Glue lo fanno; le letture Spark arbitrarie no). I bookmark richiedono un argomento transformation_ctx su ogni origine e l’incapsulamento tra job.init(...) e job.commit():

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

Per la pura conversione di formato senza logica, l’opzione che richiede meno sforzo è spesso un crawler di Glue sui dati grezzi più un job di Glue creato nell’editor visuale (o una ricetta DataBrew) — non è richiesto codice Spark. Cluster EMR personalizzati o convertitori Lambda aggiungono un sovraccarico operativo che il modello serverless di Glue elimina.

Un tipico job giornaliero che cura i dati S3 e carica Redshift Serverless:

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Security Configuration di Glue e ETL Multi-Tenant

I crawler e i job di Glue necessitano della stessa consapevolezza sulla crittografia di Athena. Le security configurations di Glue sono pacchetti nominativi che specificano come le destinazioni S3, i log di CloudWatch e i job bookmark vengono crittografati — inclusa la CSE-KMS con una CMK specifica. Un job associato a una security configuration decrittografa trasparentemente l’input CSE-KMS e crittografa gli output allo stesso modo, a condizione che il ruolo IAM del job abbia i permessi KMS sulle chiavi referenziate.

Per l’ETL multi-tenant — una piattaforma SaaS che elabora i dati di ogni cliente con la CMK di quel cliente — il pattern corretto è una security configuration per cliente (o un parametro del job che seleziona la CMK) più un ruolo IAM con ambito limitato a quella CMK. Elaborare i dati di ogni cliente tramite un unico job con una singola chiave condivisa vanifica la garanzia di isolamento che la CSE-KMS intende fornire.

Una prassi correlata: le tabelle analitiche di produzione non dovrebbero essere l’obiettivo diretto di job o notebook esplorativi di Glue. Esporta uno snapshot su un prefisso S3 “analytics” e punta Athena o Spark alla copia. Eseguire trasformazioni sperimentali sulla tabella live rischia riscritture a livello di partizione, corruzione dei bookmark e contesa di lock, e sfuma il confine di audit tra i dati operativi e i derivati analitici.

AWS Glue DataBrew

DataBrew è il parente low-code di Glue per gli utenti che non possono o non dovrebbero scrivere codice Spark. Offre un’interfaccia in stile foglio di calcolo con più di 250 trasformazioni predefinite (imputazione, mascheramento di PII, binning di outlier, parsing di date). I suoi elementi distintivi sono le ricette condivise (shared recipes) — artefatti JSON versionati che si possono pubblicare e riapplicare tra progetti diversi — e la visualizzazione del lineage dei dati (data lineage visualization) che traccia le colonne dai dataset di origine, attraverso ricette e job, fino alle destinazioni di output. Scegli DataBrew quando la logica di trasformazione è di competenza degli analisti; scegli Glue Studio/script quando è di competenza degli ingegneri e la pipeline necessita di codice personalizzato, streaming o join complessi.

Amazon EMR: Batch Distribuito e Runtime Roles

Amazon EMR è una piattaforma di cluster gestiti che esegue Spark, Hadoop, Hive, Presto, HBase e Flink. Il suo caso d’uso ideale sono i workload batch o interattivi, di grandi dimensioni e parallelizzabili, che leggono dataset S3 su scala petabyte e li uniscono (join) con un altro system of record (spesso Redshift) per l’arricchimento. EMR può eseguire cluster transienti (avvia, esegui, termina) o di lunga durata, e può combinare istanze On-Demand, Spot e Reserved tramite le instance fleets.

Un pattern canonico: un job Spark legge Parquet da S3, estrae tabelle dimensionali da Redshift tramite UNLOAD-to-S3, le unisce (join) tra gli executor e scrive l’output arricchito di nuovo su S3:

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

EMR è la scelta vincente qui perché Spark distribuisce la join su dozzine di nodi e lo staging tramite S3 evita il collo di bottiglia di un JDBC single-threaded. La trappola è ricorrere istintivamente a EMR ogni volta che i dati S3 devono essere interrogati. Per SQL ad-hoc su decine o centinaia di gigabyte, il provisioning e il tuning di un cluster Spark è puro sovraccarico operativo — dimensionamento del cluster, configurazione di YARN, autoscaling, rotazione dei log, patching. EMR si giustifica solo quando il volume, il codice personalizzato o la flessibilità del motore di esecuzione lo richiedono.

Runtime roles di EMR. Storicamente, tutti gli step su un cluster ereditavano l’instance profile EC2 — un unico ruolo associato ai nodi sottostanti — il che significava che ogni team che condivideva un cluster aveva l’unione di tutti i permessi necessari a qualsiasi team. I runtime role risolvono questo problema: quando un utente invia uno step, passa il parametro --execution-role-arn, e EMR assume quel ruolo per la durata dello step. Il Team A può essere limitato a s3://team-a/*, il Team B a s3://team-b/*. L’instance profile diventa un ruolo di bootstrap minimale che si occupa solo di recuperare gli artefatti del cluster.

I runtime role sono anche il meccanismo per bloccare l’accesso all’IMDS. Quando abilitato (EMR 6.7+ con Spark/Hive su YARN), il codice utente non può raggiungere l’instance metadata service — incluso IMDSv2 — perché la piattaforma intercetta tali chiamate. Questo chiude il percorso di escalation in cui un job potrebbe altrimenti chiamare http://169.254.169.254/latest/api/token e assumere il potente instance profile EC2.

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

La security configuration è ciò che abilita l’applicazione dei runtime role e il blocco dell’IMDS. Senza di essa, dare per scontato che i workload EMR “usino automaticamente ruoli con privilegi minimi” è sbagliato — per impostazione predefinita, condividono l’instance profile e l’IMDS è raggiungibile dal codice utente.

Amazon Redshift e Redshift ML

Redshift è un data warehouse colonnare MPP (Massively Parallel Processing) per carichi di lavoro di analisi sostenuti che richiedono dashboarding con tempi di risposta inferiori al secondo, join complessi su miliardi di righe e latenza costante con utenti BI concorrenti. I nodi RA3 disaccoppiano il calcolo (compute) dallo storage gestito; Redshift Serverless fattura in RPU-secondi rispetto a una capacità di base configurata, scala sotto carico e si mette in pausa quando è inattivo, eliminando il tradizionale problema del dimensionamento dei cluster.

Redshift partecipa alle pipeline di analisi in due modalità di arricchimento:

• Come sorgente: Spark su EMR estrae le dimensioni tramite UNLOAD su S3, oppure Glue legge tramite la Redshift Data API.
• Come destinazione: Firehose o un job di Glue importa i dati arricchiti con COPY.

Redshift Spectrum estende questa funzionalità consentendo a Redshift SQL di interrogare S3 direttamente attraverso il Glue Data Catalog — lo stesso catalogo utilizzato da Athena — il che rende possibile il pattern lake-house. Ideale quando si dispone già di un cluster Redshift e si desidera unire i fatti presenti nel warehouse con i dati storici “freddi” su S3 senza spostare i dati.

I caricamenti batch utilizzano COPY da S3, parallelizzati tra i nodi di calcolo; i file dovrebbero essere suddivisi in blocchi di dimensioni approssimativamente uguali (un multiplo del numero di slice) per la parallelizzazione:

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

L’ingestion in streaming passa tipicamente attraverso Firehose (COPY bufferizzato) per una consegna senza operazioni di gestione (zero-ops).

Redshift ML consente agli utenti SQL di creare, addestrare e invocare modelli tramite CREATE MODEL:

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

Sotto il cofano, Redshift esporta il set di addestramento su S3, invoca SageMaker Autopilot (o un algoritmo specifico come XGBoost) e importa il modello compilato per l’inferenza all’interno del database. È una funzionalità potente quando gli analisti lavorano già in SQL, ma non sostituisce una piattaforma di ML completa: lo spostamento dei dati su S3 e il calcolo per l’addestramento su SageMaker vengono fatturati separatamente, set di addestramento di grandi dimensioni possono generare costi significativi di egress e di runtime di Autopilot, e non esiste un flusso di lavoro integrato per feature store, tracciamento degli esperimenti o deployment A/B. Considerate Redshift ML come un mezzo per democratizzare l’inferenza sui dati di Redshift, non per l’addestramento generico.

Scegliere tra Athena e Redshift

Ingestion in Streaming: Kinesis Data Streams, Firehose e MSK

I tre servizi di streaming di AWS risolvono problemi parzialmente sovrapposti con garanzie sostanzialmente diverse:

Kinesis Data Streams utilizza shard (o la modalità on-demand); i record con la stessa chiave di partizione finiscono sullo stesso shard e vengono consumati in ordine. I consumer utilizzano il classico GetRecords o l’Enhanced Fan-Out (2 MB/s dedicati per consumer). Una funzione Lambda collegata come sorgente di eventi viene invocata con batch per ogni shard, preservando l’ordine. Questa è la scelta corretta quando la logica a valle non è banale, quando più consumer indipendenti devono riprodurre la cronologia, o quando i volumi di clickstream sono enormi — ad esempio, un sito che genera 30 TB/giorno farebbe fluire i dati attraverso KDS in Firehose per poi atterrare su S3 per l’analisi con Athena/Spectrum.

Kinesis Data Firehose è una consegna gestita di tipo fire-and-forget: bufferizza per dimensione o tempo (es. 5 MB / 300 secondi), opzionalmente invoca una Lambda per la trasformazione, opzionalmente converte JSON in Parquet/ORC utilizzando lo schema di una tabella Glue, e scrive su S3, Redshift (tramite S3 + COPY), OpenSearch o Splunk. Attivare la conversione in Parquet in Firehose è il modo più semplice per salvare i dati di streaming in un formato ottimizzato per le query senza un job di Glue a valle:

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose non ha garanzie di ordinamento end-to-end, non può supportare più consumer con capacità di replay, e le sue destinazioni sono sink fissi. Scegliere Firehose quando il requisito richiede di “elaborare ogni record in ordine” o “più consumer indipendenti” è sbagliato in entrambi i casi. Allo stesso modo, aspettarsi che Firehose da solo esegua trasformazioni complesse è una trappola: il suo unico hook di trasformazione è una Lambda invocata per ogni batch bufferizzato. Qualsiasi operazione che coinvolga arricchimento esterno, aggregazione multi-record o routing condizionale deve risiedere in quella Lambda o essere spostata a monte su Managed Service for Apache Flink.

Amazon MSK è Apache Kafka gestito. Sceglietelo quando avete già producer/consumer Kafka, necessitate di funzionalità specifiche di Kafka (topic compattati, transazioni, Kafka Streams, Connect), o richiedete un throughput superiore a quello che Kinesis basato su shard può fornire agevolmente.

Utilizzare SQS o EventBridge come percorso di ingestione per l’analisi è un errore: SQS non è ordinato per stream e manca della funzione di replay; EventBridge è ottimizzato per il routing degli eventi, non per l’ingestione sostenuta di più MB/s.

Ricerca in tempo reale: KDS + Firehose + OpenSearch + QuickSight

Il sostituto canonico per uno stack on-premise Elasticsearch+Logstash è:

Firehose memorizza nel buffer i record dello stream e li consegna direttamente a un dominio OpenSearch, gestendo i tentativi di ripetizione (retry), il backup su S3 e la trasformazione opzionale tramite Lambda. OpenSearch Dashboards è integrato e gratuito con il dominio ed è adatto agli operatori che monitorano stream in tempo reale. QuickSight completa questa architettura per l’analisi rivolta al business: esegue query direttamente su Athena, Redshift, RDS e OpenSearch, e il suo motore colonnare in-memory SPICE mette in cache i set di dati elaborati per prestazioni delle dashboard inferiori al secondo.

Una suddivisione tipica: OpenSearch Dashboards per gli operatori; QuickSight per i dirigenti che consultano set di dati aggregati e curati provenienti dal data lake su Athena/Glue. A entrambi deve essere concesso l’accesso in lettura tramite IAM e, ove applicabile, il permesso KMS Decrypt sulle CMK che proteggono lo storage sottostante; in caso contrario, il livello di visualizzazione mostrerà pannelli vuoti con errori di autorizzazione nascosti nei log delle query.

Controllo degli accessi in QuickSight

QuickSight costruisce set di dati (query logiche più campi calcolati e sicurezza a livello di riga), poi analisi basate su tali set di dati, e infine pubblica dashboard (viste condivisibili di sola lettura). Il controllo degli accessi è stratificato e deve essere applicato al livello corretto. La trappola è concedere un accesso ampio a livello di dashboard, condividendola con un gruppo esteso a tutta l’organizzazione quando solo un sottoinsieme dovrebbe vedere i dati sottostanti.

Il principio del privilegio minimo (least privilege) in QuickSight significa:

• Condividere il set di dati solo con gli utenti/gruppi che ne hanno bisogno.
• Applicare la sicurezza a livello di riga (row-level security) tramite un set di dati di permessi che filtra le righe per nome utente o gruppo.
• Applicare la sicurezza a livello di colonna (column-level security) per nascondere i campi sensibili.
• Condividere le dashboard con utenti, gruppi specifici o (per l’analisi integrata) namespace.

Rendere una dashboard pubblica o condividerla a livello di account aggira l’intento dei controlli a livello di set di dati, poiché chi visualizza la dashboard eredita l’accesso in lettura ai dati visualizzati, indipendentemente dai permessi sulla fonte sottostante. Ricorda che la sicurezza a livello di colonna di QuickSight protegge solo l’interfaccia di QuickSight; chiunque abbia accesso diretto ad Athena o S3 la aggira, quindi i controlli sui dati sensibili devono risiedere in Lake Formation o nell’ETL, non solo in QuickSight.

I ruoli di QuickSight — Admin, Author, Reader — controllano ciò che un utente può fare, a differenza dei permessi di condivisione che controllano ciò che può vedere. Un Reader ha un costo per sessione inferiore rispetto a una licenza Author, quindi gli utenti visualizzatori dovrebbero essere Reader di default, e l’accesso dovrebbe essere concesso tramite l’appartenenza a gruppi piuttosto che con assegnazioni individuali.

Amazon Neptune per carichi di lavoro su grafo

Neptune è un database a grafo gestito che supporta il modello property-graph (Gremlin, openCypher) e RDF (SPARQL). È progettato specificamente per dati altamente connessi — relazioni sociali, reti di frode, knowledge graph, motori di raccomandazione — dove i join ricorsivi in un database relazionale diventano proibitivi. Una piattaforma social con utenti, ‘follow’, ’like’ e post si mappa naturalmente su vertici e archi, e Neptune risponde a query di attraversamento multi-hop (“gli amici degli amici a cui è piaciuto X”) in millisecondi.

Neptune Streams espone un log ordinato cronologicamente di ogni modifica (mutation) al grafo. Una funzione Lambda o un’applicazione che esegue il polling dello stream può reagire ai cambiamenti — ricalcolare le raccomandazioni, aggiornare un indice di ricerca, attivare allarmi di frode — senza una pipeline di change-data-capture (CDC) personalizzata. Riprodurre questo comportamento su Aurora o DynamoDB richiederebbe l’attraversamento del grafo a livello di applicazione più un’infrastruttura CDC separata. Quando il problema richiede sia di “analizzare le relazioni” sia di “monitorare i cambiamenti”, Neptune con Streams è la soluzione più diretta.

SageMaker: ML personalizzato end-to-end

SageMaker copre l’intero ciclo di vita: notebook in Studio, processi di addestramento gestiti (con supporto per istanze spot), Model Registry, endpoint in tempo reale e serverless, trasformazione batch e Pipelines per MLOps. Un flusso tipico prevede il caricamento dei dati di addestramento su S3, l’avvio di un processo di addestramento specificando un algoritmo integrato o un container personalizzato; SageMaker si occupa di provisionare istanze effimere, inviare i log a CloudWatch e salvare l’artefatto del modello di nuovo su S3. Il deployment consiste in una singola chiamata API:

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

Nessun Kubernetes, driver GPU o server per i modelli da gestire. Per i team il cui requisito è “addestrare ed esporre un modello”, SageMaker è quasi sempre la risposta con il minor carico di gestione (overhead) rispetto a una soluzione di inferenza personalizzata su ECS/EC2.

I SageMaker Savings Plans impegnano a una spesa oraria in dollari su componenti idonei (Studio, addestramento, elaborazione, inferenza in tempo reale) per 1 o 3 anni, offrendo fino al 64% di sconto rispetto ai prezzi on-demand. Sono flessibili per famiglia di istanze, dimensione, regione e componente, ma non coprono Ground Truth, lo storage o il trasferimento di dati. Utilizza i Savings Plans quando l’utilizzo di base del ML è prevedibile; lascia i picchi di addestramento (burst training) su istanze spot per massimizzare i risparmi.

Servizi di IA gestiti e ML personalizzato a confronto

Amazon Rekognition (immagini/video: rilevamento di oggetti e scene, analisi dei volti, moderazione), Textract (OCR più estrazione di moduli e tabelle) e Comprehend (NLP: riconoscimento di entità, sentiment, rilevamento di PII, classificazione personalizzata) espongono modelli pre-addestrati tramite semplici API. La funzione DetectEntities di Comprehend restituisce entità tipizzate, inclusa la categoria COMMERCIAL_ITEM, perfetta per estrarre nomi di ingredienti dal testo di una ricetta e alimentare una ricerca in DynamoDB, senza dati di addestramento, senza hosting e con un modello di prezzo pay-per-request:

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

L’errore più comune è l’over-engineering, ovvero l’avvio di processi di addestramento con SageMaker, l’etichettatura dei dati con Ground Truth e l’hosting di endpoint quando un servizio gestito copre già il requisito a una frazione del costo operativo. Il ML personalizzato si giustifica solo quando l’accuratezza sui dati specifici del dominio è materialmente superiore, quando i tipi di entità necessari non corrispondono allo schema gestito (Comprehend Custom Classification/Entity Recognition è comunque più economico di SageMaker “puro”), o quando i vincoli di latenza e residenza dei dati richiedono un modello privato.

Storage e networking per HPC: FSx for Lustre ed EFA

I carichi di lavoro HPC strettamente accoppiati (tightly coupled) — CFD, dinamica molecolare, imaging sismico, addestramento su larga scala — hanno due requisiti non negoziabili: comunicazione tra nodi a latenza estremamente bassa e storage condiviso ad alto throughput.

Elastic Fabric Adapter (EFA) è un’interfaccia di rete disponibile su specifiche famiglie di istanze EC2 (hpc7a, hpc6id, c6in, p4d/p5, altre). Bypassa lo stack TCP/IP del kernel utilizzando l’OS-bypass di Libfabric, consentendo a MPI e NCCL di raggiungere latenze nell’ordine dei microsecondi su centinaia di nodi. EFA richiede che le istanze si trovino nella stessa Availability Zone e, per la massima larghezza di banda, in un cluster placement group.

FSx for Lustre è un file system parallelo gestito che offre un throughput di centinaia di GB/s e una latenza inferiore al millisecondo. Si integra nativamente con S3: un file system FSx può essere collegato a un bucket in modo che gli oggetti appaiano come file POSIX, e i risultati scritti su Lustre possono essere riesportati su S3. Le implementazioni Persistent SSD sono adatte per lo scratch a lunga durata; Scratch2 è più economico per i dati di processi effimeri.

L’approccio errato è usare EFS per l’HPC. EFS è basato su NFS, ottimizzato per molti client di piccole dimensioni che eseguono I/O generico su file; non può sostenere il throughput aggregato o gli IOPS dei metadati richiesti da un processo MPI a 500 nodi, e la sua architettura multi-AZ aggiunge latenza. L’uso di ENA standard invece di EFA limita MPI alle latenze TCP, moltiplicando di diverse volte i tempi di esecuzione pesantemente dipendenti da operazioni allreduce. La combinazione corretta è istanze abilitate per EFA in un cluster placement group che montano FSx for Lustre, con S3 come storage a freddo (cold storage) durevole collegato al file system.

← Database e Caching · Tutti i domini · Integrazione di Applicazioni →

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

Sfoglia Amazon →