Amazon SAA-C03: Analytics, Data Lake, ML & Gespecialiseerde workloads — Studiegids

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

Onderdeel van de AWS SAA-C03 — Complete studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Data Lake-fundamenten: Lake Formation en de Glue Data Catalog

Het zwaartepunt van AWS analytics is de AWS Glue Data Catalog — een Hive-metastore-compatibele metastore die door Athena, Redshift Spectrum, EMR en Glue ETL wordt gebruikt. Elke tabeldefinitie, partitie, kolomtype en SerDe-configuratie bevindt zich hier, en elke downstream-engine leest hieruit. Als twee ingestion-paden (bijvoorbeeld een Glue-crawler en een handmatig CREATE EXTERNAL TABLE-statement) het niet eens zijn over het schema van dezelfde S3-prefix, geven queries stilzwijgend onjuiste resultaten terug of mislukken ze. Het correcte patroon is om één enkele autoriteit per tabel aan te wijzen: ofwel de crawler is eigenaar van het schema, ofwel je ETL-job schrijft via glueContext.write_dynamic_frame.from_catalog, maar nooit beide zonder een merge-strategie. Wanneer batch-ETL, Firehose Parquet-conversie en handmatige DDL allemaal naar dezelfde tabel schrijven, is ‘catalog drift’ de stille doder. Dwing één eigenaar per tabel af, gebruik de Glue Schema Registry voor streaming-producenten en voer crawlers uit in LOG-modus (niet UPDATE_IN_DATABASE) op tabellen die eigendom zijn van ETL-jobs, zodat ze drift aan het licht brengen zonder gecureerde schema’s te overschrijven.

AWS Lake Formation bevindt zich boven de Data Catalog en vervangt het grofmazige IAM/S3-bucketbeleidsmodel door een permissielaag in databasestijl. In plaats van s3:GetObject op een prefix toe te kennen, geef je GRANT SELECT ON customers.orders TO role/AnalystRole, en Lake Formation verstrekt transparant kortstondige credentials wanneer Athena of Redshift Spectrum de onderliggende objecten benadert. De echte waarde ervan is fijnmazige autorisatie: filteren op kolomniveau, beveiliging op rijniveau via datafilters en op tags gebaseerde toegangscontrole (LF-Tags) die schaalbaar is over duizenden tabellen. Een retailplatform met PII in een customers-tabel kan analisten toegang geven tot customer_id, region, signup_date terwijl email en ssn worden geblokkeerd — afgedwongen op het moment van de query, zonder dat een wildgroei aan views nodig is.

De canonieke opzet voor een ‘governed’ lake:

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.

Lake Formation-blueprints zijn vooraf gebouwde workflow-templates die crawlers, jobs en triggers aan elkaar koppelen om data van JDBC-bronnen of S3 op te nemen in een gecureerd lake — wat tientallen handmatig geconfigureerde Glue-resources reduceert tot een wizard-gestuurde flow.

Een veelgemaakte fout is proberen om beperkingen op kolomniveau alleen in QuickSight af te dwingen. QuickSight heeft beveiliging op rij- en kolomniveau die gekoppeld is aan datasets, maar dit beschermt alleen de QuickSight-interface — iedereen met directe toegang tot Athena of S3 omzeilt dit. Controle op kolomniveau moet worden afgedwongen op de datalaag (Lake Formation-grants, of het fysiek scheiden van kolommen tijdens ETL), en QuickSight erft die houding via zijn IAM-rol.

Athena: Serverless SQL op S3

Athena is een serverless, pay-per-query Presto/Trino-engine die rechtstreeks leest van Amazon S3. Geen cluster om te provisionen, geen ETL-stap nodig voor het uitvoeren van queries, en geen kosten wanneer het niet wordt gebruikt — je betaalt alleen voor de gescande bytes (doorgaans $5/TB). Dit maakt Athena de canonieke keuze voor ad-hoc-analyse van bestanden die al in S3 staan, of het nu gaat om JSON-applicatielogs, CSV-exports of Parquet-fact-tabellen. Athena heeft een schema en partitie-indeling nodig, die zich in de Glue Data Catalog bevinden.

Aangezien Athena factureert per gescande terabyte, heeft het opslagformaat een buitenproportionele impact op kosten en latency. De twee hefbomen zijn formaat en partitionering:

• Kolomgeoriënteerde formaten (Parquet, ORC) stellen Athena in staat om kolommen en ‘row groups’ te snoeien (‘prunen’). Een query zoals SELECT sum(amount) FROM orders WHERE region='us-east-1' op Parquet leest alleen de twee betreffende kolommen; op CSV leest het elke byte van elke rij.
• Partitionering op kolommen met hoge selectiviteit (bijv. dt=2024-03-11/) reduceert een volledige tabelscan tot een gerichte leesactie. Bij logs van meerdere terabytes (CloudFront, ALB, VPC Flow Logs) is dit het verschil tussen een query van $0,15 en een query van $30.

Het converteren van onbewerkte JSON of CSV naar gepartitioneerd, Snappy-gecomprimeerd Parquet is bijna altijd de eerste kostenbesparende maatregel die je moet nemen. Gecombineerd met LIMIT pushdown, kan Athena de meeste analytics-op-S3-behoeften aan zonder enige infrastructuur.

Een kosteneffectief patroon voor een ‘readings’-tabel opgeslagen als gepartitioneerd Parquet:

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';

Het overslaan van de crawler is een veelgemaakte fout. Zonder een catalogus-entry moet je ofwel handmatige CREATE EXTERNAL TABLE DDL schrijven (wat fragiel is als schema’s evolueren) of ‘schema-on-read’-hacks gebruiken die elk bestand scannen. Erger nog, zonder MSCK REPAIR TABLE of ‘partition projection’ scant Athena bij elke query de volledige prefix. Glue-crawlers detecteren nieuwe partities volgens een schema en werken de catalogus atomair bij.

Athena op versleutelde S3-data. Athena ondersteunt SSE-S3, SSE-KMS en CSE-KMS, maar alleen als de aanroeper de juiste KMS-permissies heeft en de workgroup of client is geconfigureerd voor de gebruikte versleutelingsmodus. Voor CSE-KMS wordt het bestand client-side versleuteld vóór de upload; de IAM-principal die de query uitvoert, heeft kms:Decrypt en kms:GenerateDataKey nodig op de CMK, en het key-beleid moet dit wederzijds toestaan. Een veelvoorkomend scenario waarin het misgaat: CSE-KMS Parquet laden, de Athena-rol alleen S3-leesrechten geven en vervolgens onduidelijke AccessDenied- of HIVE_CANNOT_OPEN_SPLIT-fouten krijgen — het object is leesbaar, maar de ciphertext kan niet worden ‘unwrapped’. Een andere veelgemaakte fout is het registreren van de tabel met de verkeerde versleutelingsmodus (SSE-KMS in de tabeleigenschappen terwijl objecten zijn geschreven met CSE-KMS); Athena probeert server-side decryptie tijdens GetObject en de payload komt terug als onbewerkte ciphertext die niet door de Parquet ‘magic-number’-controles komt.

Met Athena federated queries kun je S3-data joinen met operationele stores (DynamoDB, RDS) zonder data te verplaatsen. Reserveer Athena voor leesgeoriënteerde ad-hoc-analyses; gebruik Glue-jobs voor het gepland vormgeven van gecureerde zones.

Glue Crawlers, ETL Jobs en Job Bookmarks

Glue crawlers scannen S3-paden, leiden het schema af (inclusief partitiesleutels uit de directorystructuur zoals year=2024/month=01/), en registreren of updaten tabellen in de catalogus. Ze zijn het low-code antwoord op de vraag “we plaatsen bestanden in S3, maak ze queryable”. Plan een crawler die elk uur een landing bucket scant en Athena ziet onmiddellijk nieuwe partities.

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

Glue ETL-jobs (Spark, Python shell of Ray) verzorgen het transformatiegedeelte. Glue is serverless — je betaalt per DPU-uur met een minimum van één minuut — en de runtime schaalt workers automatisch. Het dominante patroon is CSV/JSON als input, en gepartitioneerde Parquet als 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"})

De kritieke operationele feature is de job bookmark: Glue bewaart de status van welke bestanden of partities het al heeft verwerkt, zodat volgende runs alleen nieuwe data lezen. Als je vergeet bookmarks in te schakelen, herverwerkt elke run de volledige dataset vanaf het begin, wat de kosten en runtime lineair verhoogt en vaak dubbele output produceert. Bookmarks worden per job ingeschakeld en moeten worden gecombineerd met bronopties die ze ondersteunen (S3-bronnen via de Glue DynamicFrame-reader doen dit wel; willekeurige Spark-reads niet). Bookmarks vereisen een transformation_ctx-argument bij elke bron en een job.init(...) / job.commit()-omlijsting:

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

Voor pure formaatconversie zonder logica is de optie met de minste inspanning vaak een Glue-crawler op de onbewerkte data plus een Glue-job die is gemaakt in de visuele editor (of een DataBrew-recept) — geen Spark-code vereist. Aangepaste EMR-clusters of Lambda-converters voegen operationele overhead toe die het serverless model van Glue elimineert.

Een typische dagelijkse job die S3-data cureert en in Redshift Serverless laadt:

# 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/")

Glue Security Configurations en Multi-Tenant ETL

Glue-crawlers en -jobs hebben hetzelfde encryptiebewustzijn nodig als Athena. Glue security configurations zijn benoemde bundels die specificeren hoe S3-doelen, CloudWatch-logs en job bookmarks worden versleuteld — inclusief CSE-KMS met een specifieke CMK. Een job die aan een security configuration is gekoppeld, decodeert transparant CSE-KMS-input en versleutelt outputs op dezelfde manier, op voorwaarde dat de IAM-rol van de job KMS-permissies heeft op de betreffende sleutels.

Voor multi-tenant ETL — een SaaS-platform dat de data van elke klant verwerkt met de CMK van die klant — is het juiste patroon één security configuration per klant (of een jobparameter die de CMK selecteert) plus een IAM-rol die beperkt is tot die CMK. Alle klanten door één enkele job met één gedeelde sleutel laten lopen, ondermijnt de isolatiegarantie die CSE-KMS beoogt te bieden.

Een gerelateerde discipline: productieve analytische tabellen mogen niet het directe doelwit zijn van verkennende Glue-jobs of notebooks. Exporteer een snapshot naar een S3 ‘analytics’-prefix en richt Athena of Spark op de kopie. Het uitvoeren van experimentele transformaties op de live tabel brengt risico’s met zich mee zoals het herschrijven op partitieniveau, corruptie van bookmarks en lock-conflicten, en vervaagt de auditgrens tussen operationele data en analytische afgeleiden.

AWS Glue DataBrew

DataBrew is het low-code broertje van Glue voor gebruikers die geen Spark kunnen of mogen schrijven. Het biedt een spreadsheet-achtige UI met meer dan 250 vooraf gebouwde transformaties (imputatie, PII-maskering, outlier-binning, datum-parsing). De onderscheidende factoren zijn shared recipes — geversioneerde JSON-artefacten die je kunt publiceren en opnieuw kunt toepassen in verschillende projecten — en data lineage visualization die kolommen traceert van bron-datasets via recepten en jobs naar outputlocaties. Kies DataBrew wanneer analisten de transformatielogica beheren; kies Glue Studio/scripts wanneer engineers dit beheren en de pipeline aangepaste code, streaming of complexe joins vereist.

Amazon EMR: Gedistribueerde Batch en Runtime Roles

Amazon EMR is een beheerd clusterplatform dat Spark, Hadoop, Hive, Presto, HBase en Flink draait. De ‘sweet spot’ is voor grote, paralleliseerbare batch- of interactieve workloads die S3-datasets op petabyteschaal lezen en deze voor verrijking joinen met een ander ‘system of record’ (vaak Redshift). EMR kan ’transient’ clusters (opstarten, uitvoeren, beëindigen) of langlopende clusters draaien, en kan On-Demand, Spot en Reserved instances mixen via instance fleets.

Een canoniek patroon: een Spark-job leest Parquet uit S3, haalt dimensietabellen op uit Redshift via UNLOAD-naar-S3, joint deze over meerdere executors, en schrijft de verrijkte output terug naar 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 is hier de winnaar omdat Spark de join verdeelt over tientallen nodes en de staging via S3 een single-threaded JDBC-bottleneck vermijdt. De valkuil is om reflexmatig voor EMR te kiezen telkens als S3-data gequeryd moet worden. Voor ad-hoc SQL op tientallen of honderden gigabytes is het provisioneren en tunen van een Spark-cluster pure operationele overhead — cluster-sizing, YARN-configuratie, autoscaling, logrotatie, patchen. EMR bewijst zijn waarde alleen wanneer het volume, de aangepaste code of de flexibiliteit van de execution engine dit rechtvaardigt.

EMR runtime roles. Historisch gezien erfden alle steps op een cluster het EC2 instance profile — één rol gekoppeld aan de onderliggende nodes — wat betekende dat elk team dat een cluster deelde de vereniging had van alle permissies die elk team nodig had. Runtime roles lossen dit op: wanneer een gebruiker een step indient, geeft hij --execution-role-arn mee, en EMR neemt die rol aan voor de duur van de step. Team A kan beperkt worden tot s3://team-a/*, Team B tot s3://team-b/*. Het instance profile wordt een minimale bootstrap-rol die alleen clusterartefacten ophaalt.

Runtime roles zijn ook het mechanisme om IMDS-toegang te blokkeren. Wanneer ingeschakeld (EMR 6.7+ met Spark/Hive op YARN), kan gebruikerscode de instance metadata service niet bereiken — inclusief IMDSv2 — omdat het platform die aanroepen onderschept. Dit sluit het escalatiepad af waarbij een job anders http://169.254.169.254/latest/api/token zou kunnen aanroepen en het krachtige EC2 instance profile zou kunnen aannemen.

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

De security configuration is wat de handhaving van runtime roles en het blokkeren van IMDS mogelijk maakt. Zonder dit is de aanname dat EMR-workloads ‘automatisch least-privilege rollen gebruiken’ onjuist — standaard delen ze het instance profile en is IMDS bereikbaar vanuit gebruikerscode.

Amazon Redshift en Redshift ML

Redshift is een kolomgeoriënteerd MPP-datawarehouse voor aanhoudende analytics-workloads die dashboarding met sub-seconde responstijden, complexe joins over miljarden rijen en consistente latentie onder gelijktijdige BI-gebruikers vereisen. RA3-nodes ontkoppelen compute van beheerde opslag; Redshift Serverless rekent af in RPU-seconden op basis van een geconfigureerde basiscapaciteit, schaalt op onder belasting en pauzeert wanneer het inactief is, waardoor het traditionele probleem van clusterdimensionering wordt geëlimineerd.

Redshift neemt deel aan analytics-pipelines in twee verrijkingsmodi:

• Als een bron: Spark op EMR haalt dimensies op via UNLOAD-to-S3, of Glue leest via de Redshift Data API.
• Als een doel: Firehose of een Glue-job voert een COPY uit van verrijkte data.

Redshift Spectrum breidt dit uit door Redshift SQL in staat te stellen S3 rechtstreeks te bevragen via de Glue Data Catalog — dezelfde catalogus die Athena gebruikt — wat het lake-house-patroon mogelijk maakt. Ideaal wanneer u al een Redshift-cluster hebt en feiten uit het warehouse wilt joinen met koude S3-historie zonder data te verplaatsen.

Batch-ladingen gebruiken COPY vanuit S3, geparallelliseerd over de compute nodes; bestanden moeten worden opgesplitst in ongeveer gelijke stukken (een veelvoud van het aantal slices) voor parallellisatie:

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

Streaming ingestion verloopt doorgaans via Firehose (gebufferde COPY) voor een levering zonder operationeel beheer.

Redshift ML stelt SQL-gebruikers in staat om modellen te creëren, trainen en aan te roepen via 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;

Onder de motorkap exporteert Redshift de trainingsset naar S3, roept SageMaker Autopilot (of een gespecificeerd algoritme zoals XGBoost) aan en importeert het gecompileerde model voor in-database inferentie. Krachtig wanneer analisten al in SQL werken, maar het is geen vervanging voor een volledig ML-platform: dataverplaatsing naar S3 en de compute voor SageMaker-training worden apart in rekening gebracht, grote trainingssets kunnen aanzienlijke egress- en Autopilot-runtimekosten genereren, en er is geen ingebouwde workflow voor feature stores, experiment tracking of A/B-deployment. Beschouw Redshift ML als gedemocratiseerde inferentie over Redshift-data, niet als een algemeen trainingsplatform.

Kiezen tussen Athena en Redshift

Streaming Ingestion: Kinesis Data Streams, Firehose en MSK

De drie streamingdiensten van AWS lossen overlappende problemen op met wezenlijk verschillende garanties:

Kinesis Data Streams gebruikt shards (of on-demand modus); records met dezelfde partitiesleutel komen op dezelfde shard terecht en worden in volgorde geconsumeerd. Consumers gebruiken de klassieke GetRecords of Enhanced Fan-Out (toegewijde 2 MB/s per consumer). Een Lambda-functie die als event source is gekoppeld, wordt aangeroepen met batches per shard, waarbij de volgorde behouden blijft. Dit is de juiste keuze wanneer de downstream logica niet-triviaal is, wanneer meerdere onafhankelijke consumers de historie moeten kunnen herhalen, of wanneer de clickstream-volumes enorm zijn — bijvoorbeeld, een site die 30 TB/dag genereert, zou dit via KDS naar Firehose laten stromen om in S3 te landen voor Athena/Spectrum-analyse.

Kinesis Data Firehose is ‘fire-and-forget’ beheerde levering: het buffert op grootte of tijd (bijv. 5 MB / 300 seconden), roept optioneel een Lambda aan voor transformatie, converteert optioneel JSON naar Parquet/ORC met behulp van het schema van een Glue-tabel, en schrijft naar S3, Redshift (via S3 + COPY), OpenSearch of Splunk. Het inschakelen van Parquet-conversie in Firehose is de manier met de minste inspanning om streaming data in een voor queries geoptimaliseerd formaat te landen zonder een downstream Glue-job:

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 heeft geen end-to-end volgordegarantie, kan geen meerdere herhaalbare consumers ondersteunen en de bestemmingen zijn vaste sinks. Kiezen voor Firehose wanneer de vereiste “verwerk elk record in volgorde” of “meerdere onafhankelijke consumers” is, is in beide gevallen onjuist. Evenzo is het verwachten dat Firehose alleen complexe transformaties uitvoert een valkuil — de enige transformatie-hook is een Lambda die per gebufferde batch wordt aangeroepen. Alles wat externe verrijking, aggregatie over meerdere records of conditionele routing inhoudt, moet in die Lambda leven of stroomopwaarts worden verplaatst naar Managed Service for Apache Flink.

Amazon MSK is beheerde Apache Kafka. Kies hiervoor als u al Kafka-producers/consumers hebt, Kafka-specifieke functies nodig hebt (compacted topics, transactions, Kafka Streams, Connect), of een doorvoer vereist die verder gaat dan wat Kinesis op basis van shards comfortabel kan leveren.

Het gebruik van SQS of EventBridge als een analytics-ingestiepad is een fout: SQS is niet geordend per stream en mist replay-mogelijkheden; EventBridge is geoptimaliseerd voor het routeren van events, niet voor aanhoudende ingestie van meerdere MB/s.

Real-time zoeken: KDS + Firehose + OpenSearch + QuickSight

De canonische vervanging voor een on-premise Elasticsearch+Logstash-stack is:

Firehose buffert streamrecords en levert ze rechtstreeks aan een OpenSearch-domein, en handelt daarbij retries, S3-back-ups en optionele Lambda-transformaties af. OpenSearch Dashboards is ingebed en gratis bij het domein en is geschikt voor operators die real-time streams monitoren. QuickSight vult dit aan voor bedrijfsgerichte analyses — het voert rechtstreeks query’s uit op Athena, Redshift, RDS en OpenSearch, en zijn SPICE in-memory kolommenengine cachet verwerkte datasets voor dashboardprestaties van minder dan een seconde.

Een typische verdeling: OpenSearch Dashboards voor operators; QuickSight voor leidinggevenden die geaggregeerde, gecureerde datasets gebruiken die afkomstig zijn uit het Athena/Glue-lake. Beide moeten IAM-leestoegang krijgen en, waar van toepassing, Decrypt-permissies op de CMK’s die de onderliggende opslag beveiligen — anders geeft de visualisatielaag lege panelen weer met permissiefouten diep in de querylogs.

Toegangsbeheer in QuickSight

QuickSight bouwt datasets (logische query’s plus berekende velden en beveiliging op rijniveau), vervolgens analyses bovenop datasets, en publiceert dan dashboards (alleen-lezen deelbare weergaven). Toegangsbeheer is gelaagd en moet op de juiste laag worden toegepast. De valkuil is het verlenen van brede toegang op dashboardniveau — door te delen met een organisatiebrede groep terwijl slechts een subset de onderliggende data zou mogen zien.

Least privilege in QuickSight betekent:

• Deel de dataset alleen met gebruikers/groepen die deze nodig hebben.
• Pas beveiliging op rijniveau toe via een permissie-dataset die rijen filtert op gebruikersnaam of groep.
• Pas beveiliging op kolomniveau toe om gevoelige velden te verbergen.
• Deel dashboards met specifieke gebruikers, groepen of (voor embedded analytics) namespaces.

Een dashboard openbaar maken of accountbreed delen omzeilt de bedoeling van de controles op datasetniveau, omdat dashboard-kijkers leestoegang tot gevisualiseerde data overerven, ongeacht de permissies van de onderliggende bron. Onthoud dat beveiliging op kolomniveau in QuickSight alleen de QuickSight-interface beschermt; iedereen met directe toegang tot Athena of S3 omzeilt dit, dus gevoelige controles horen thuis in Lake Formation of ETL, niet alleen in QuickSight.

QuickSight-rollen — Admin, Author, Reader — bepalen wat een gebruiker kan doen, wat verschilt van deelmachtigingen die bepalen wat ze kunnen zien. Een Reader verbruikt tegen lagere kosten per sessie dan een Author-licentie, dus kijkerspopulaties zouden standaard Readers moeten zijn, en toegang moet worden verleend via groepslidmaatschap in plaats van individuele toewijzing.

Amazon Neptune voor grafiek-workloads

Neptune is een beheerde grafiekdatabase die het property-graph-model (Gremlin, openCypher) en RDF (SPARQL) ondersteunt. Het is speciaal gebouwd voor sterk verbonden data — sociale relaties, fraudekringen, kennisgrafen, aanbevelingsengines — waar recursieve joins in een relationele database onuitvoerbaar worden. Een sociaal platform met gebruikers, volgers, likes en posts kan op natuurlijke wijze worden gemapt naar vertices (knopen) en edges (verbindingen), en Neptune beantwoordt multi-hop traversals (“vrienden van vrienden die X leuk vonden”) in milliseconden.

Neptune Streams stelt een geordend, tijdgebaseerd logboek van elke mutatie in de grafiek beschikbaar. Een Lambda of applicatie die de stream pollt, kan reageren op veranderingen — aanbevelingen herberekenen, een zoekindex bijwerken, fraudealarmen activeren — zonder een op maat gemaakte change-data-capture-pipeline. Dit reproduceren op Aurora of DynamoDB vereist grafiektraversal op applicatieniveau plus aparte CDC-implementatie. Wanneer de probleemstelling zowel “analyseer relaties” als “monitor veranderingen” omvat, is Neptune met Streams de directe match.

SageMaker: End-to-end custom ML

SageMaker biedt de volledige levenscyclus: Studio-notebooks, beheerde trainingstaken (met spot-ondersteuning), Model Registry, real-time en serverless endpoints, batch transform en Pipelines voor MLOps. Een typische flow uploadt trainingsdata naar S3, start een trainingstaak die een ingebouwd algoritme of een custom container specificeert, en SageMaker provisioneert tijdelijke instances, streamt logs naar CloudWatch en schrijft het modelartefact terug naar S3. Implementatie is een enkele API-call:

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")

Geen Kubernetes, GPU-driver of modelserver om te beheren. Voor teams wier vereiste is “train en exposeer een model”, is SageMaker bijna altijd het antwoord met de minste overhead vergeleken met het zelf opzetten van inferentie op ECS/EC2.

SageMaker Savings Plans leggen een uitgave van een bepaald dollarbedrag per uur vast voor in aanmerking komende componenten (Studio, training, processing, real-time inference) voor 1 of 3 jaar, wat tot 64% korting oplevert ten opzichte van on-demand prijzen. Ze zijn flexibel over instance family, grootte, regio en component — maar dekken geen Ground Truth, opslag of dataoverdracht. Gebruik Savings Plans wanneer het basisgebruik van ML voorspelbaar is; laat piekbelasting voor training op spot instances draaien om de besparingen te vergroten.

Beheerde AI-Services versus Aangepaste ML

Amazon Rekognition (afbeeldingen/video: object- en scèneherkenning, gezichtsanalyse, moderatie), Textract (OCR plus extractie van formulieren en tabellen), en Comprehend (NLP: entiteitsherkenning, sentiment, PII-detectie, aangepaste classificatie) bieden voorgetrainde modellen aan via eenvoudige API’s. Comprehend’s DetectEntities retourneert getypeerde entiteiten, inclusief een COMMERCIAL_ITEM-categorie — perfect voor het extraheren van ingrediëntnamen uit receptteksten en deze door te geven aan een DynamoDB-lookup, zonder trainingsdata, zonder hosting, en met een pay-per-request prijsmodel:

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

De meest voorkomende fout is over-engineering — het opzetten van SageMaker training jobs, het labelen van data met Ground Truth, en het hosten van endpoints wanneer een beheerde service de vereiste al dekt tegen een fractie van de operationele kosten. Aangepaste ML is alleen gerechtvaardigd wanneer de nauwkeurigheid op domeinspecifieke data materieel hoger is, wanneer de benodigde entiteitstypes niet overeenkomen met het beheerde schema (Comprehend Custom Classification/Entity Recognition is nog steeds goedkoper dan pure SageMaker), of wanneer latency- en data-residentiebeperkingen een privaat model vereisen.

HPC Storage en Netwerken: FSx for Lustre en EFA

Nauw gekoppelde HPC-workloads — CFD, moleculaire dynamica, seismische beeldvorming, grootschalige training — hebben twee niet-onderhandelbare vereisten: extreem lage latency voor communicatie tussen nodes en gedeelde opslag met hoge doorvoersnelheid.

Elastic Fabric Adapter (EFA) is een netwerkinterface die beschikbaar is op specifieke EC2-families (hpc7a, hpc6id, c6in, p4d/p5, en andere). Het omzeilt de kernel TCP/IP-stack met behulp van OS-bypass Libfabric, waardoor MPI en NCCL latencies van microseconden kunnen bereiken over honderden nodes. EFA vereist instances in dezelfde Availability Zone en, voor maximale bandbreedte, in een cluster placement group.

FSx for Lustre is een beheerd parallel bestandssysteem dat honderden GB/s aan doorvoersnelheid en sub-milliseconde latency levert. Het integreert native met S3: een FSx-bestandssysteem kan worden gekoppeld aan een bucket zodat objecten verschijnen als POSIX-bestanden, en resultaten die naar Lustre worden geschreven, kunnen terug worden geëxporteerd naar S3. Persistent SSD-implementaties zijn geschikt voor langlevende scratch-opslag; Scratch2 is goedkoper voor kortstondige job-data.

Het verkeerde patroon is het gebruik van EFS voor HPC. EFS is gebaseerd op NFS, afgestemd op veel kleine clients die algemene bestands-I/O uitvoeren; het kan niet de geaggregeerde doorvoersnelheid of de metadata-IOPS ondersteunen die een 500-node MPI-job nodig heeft, en het multi-AZ-ontwerp voegt latency toe. Het gebruik van de standaard ENA in plaats van EFA beperkt MPI tot TCP-latencies, wat de runtimes van allreduce-intensieve taken vele malen vermenigvuldigt. De juiste combinatie is EFA-enabled instances in een cluster placement group die FSx for Lustre mounten, met S3 als duurzame koude opslag die aan het bestandssysteem is gekoppeld.

← Databases · Alle domeinen · Applicatie-integratie →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Amazon →