Amazon SAA-C03: Analytik, Data Lake, ML & Spezialisierte Workloads — Lernleitfaden

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

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Data Lake Foundations: Lake Formation und der Glue Data Catalog

Das Zentrum der AWS-Analytics ist der AWS Glue Data Catalog – ein Hive-Metastore-kompatibler Metastore, der von Athena, Redshift Spectrum, EMR und Glue ETL genutzt wird. Jede Tabellendefinition, Partition, jeder Spaltentyp und jede SerDe-Konfiguration befindet sich hier, und jede nachgelagerte Engine liest daraus. Wenn zwei Erfassungspfade (z. B. ein Glue-Crawler und eine manuelle CREATE EXTERNAL TABLE-Anweisung) sich über das Schema desselben S3-Präfixes nicht einig sind, liefern Abfragen stillschweigend falsche Ergebnisse oder schlagen fehl. Das korrekte Muster ist, eine einzige Autorität pro Tabelle festzulegen: Entweder ist der Crawler für das Schema verantwortlich, oder Ihr ETL-Job schreibt über glueContext.write_dynamic_frame.from_catalog, aber niemals beides ohne eine Merge-Strategie. Wenn Batch-ETL, Firehose-Parquet-Konvertierung und manuelle DDL alle in dieselbe Tabelle schreiben, ist Catalog Drift der stille Killer. Erzwingen Sie einen einzigen Besitzer pro Tabelle, verwenden Sie die Glue Schema Registry für Streaming-Produzenten und führen Sie Crawler im LOG-Modus (nicht UPDATE_IN_DATABASE) für Tabellen aus, die von ETL-Jobs verwaltet werden, damit sie Drift aufdecken, ohne kuratierte Schemata zu überschreiben.

AWS Lake Formation setzt auf dem Data Catalog auf und ersetzt das grobkörnige IAM/S3-Bucket-Policy-Modell durch eine datenbankähnliche Berechtigungsschicht. Anstatt s3:GetObject für ein Präfix zu gewähren, führen Sie GRANT SELECT ON customers.orders TO role/AnalystRole aus, und Lake Formation stellt transparent kurzlebige Anmeldeinformationen bereit, wenn Athena oder Redshift Spectrum auf die zugrunde liegenden Objekte zugreifen. Sein eigentlicher Wert liegt in der feingranularen Autorisierung: Filterung auf Spaltenebene, Sicherheit auf Zeilenebene durch Datenfilter und Tag-basierte Zugriffskontrolle (LF-Tags), die über Tausende von Tabellen skaliert. Eine Einzelhandelsplattform mit PII in einer customers-Tabelle kann Analysten Zugriff auf customer_id, region, signup_date gewähren, während email und ssn blockiert werden – durchgesetzt zur Abfragezeit, ohne dass eine unkontrollierte Vermehrung von Views erforderlich ist.

Der kanonische Aufbau für einen verwalteten 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 sind vorgefertigte Workflow-Vorlagen, die Crawler, Jobs und Trigger miteinander verknüpfen, um Daten aus JDBC-Quellen oder S3 in einen kuratierten Lake zu überführen. Dies reduziert, was Dutzende von manuell verdrahteten Glue-Ressourcen wären, auf einen assistentengesteuerten Ablauf.

Ein häufiger Fehler ist der Versuch, Einschränkungen auf Spaltenebene allein in QuickSight durchzusetzen. QuickSight verfügt über Sicherheit auf Zeilen- und Spaltenebene, die an Datasets gebunden ist, aber es schützt nur die QuickSight-Oberfläche – jeder mit direktem Athena- oder S3-Zugriff umgeht sie. Die Kontrolle auf Spaltenebene muss auf der Datenebene durchgesetzt werden (Lake-Formation-Berechtigungen oder physische Trennung von Spalten während des ETL), und QuickSight erbt diese Position durch seine IAM-Rolle.

Athena: Serverless-SQL über S3

Athena ist eine serverlose Pay-per-Query Presto/Trino-Engine, die direkt aus Amazon S3 liest. Kein Cluster, der bereitgestellt werden muss, kein ETL-Schritt vor der Abfrage erforderlich und keine Kosten im Ruhezustand – Sie zahlen nur für die gescannten Bytes (typischerweise 5 $/TB). Dies macht Athena zur kanonischen Wahl für Ad-hoc-Analysen von Dateien, die sich bereits in S3 befinden, seien es JSON-Anwendungsprotokolle, CSV-Exporte oder Parquet-Faktentabellen. Athena benötigt ein Schema und ein Partitionslayout, das sich im Glue Data Catalog befindet.

Da Athena pro gescanntem Terabyte abrechnet, hat das Speicherformat einen überproportionalen Einfluss auf Kosten und Latenz. Die beiden Hebel sind Format und Partitionierung:

• Spaltenorientierte Formate (Parquet, ORC) ermöglichen es Athena, Spalten und Zeilengruppen zu beschneiden (pruning). Eine Abfrage wie SELECT sum(amount) FROM orders WHERE region='us-east-1' auf Parquet liest nur die beiden referenzierten Spalten; bei CSV liest es jedes Byte jeder Zeile.
• Partitionierung nach Spalten mit hoher Selektivität (z. B. dt=2024-03-11/) reduziert einen vollständigen Tabellenscan auf einen gezielten Lesevorgang. Bei Protokollen mit mehreren Terabyte (CloudFront, ALB, VPC Flow Logs) ist dies der Unterschied zwischen einer 0,15-Dollar-Abfrage und einer 30-Dollar-Abfrage.

Die Konvertierung von rohem JSON oder CSV in partitioniertes, Snappy-komprimiertes Parquet ist fast immer der erste Kostenhebel, den man ziehen sollte. In Kombination mit LIMIT-Pushdown bewältigt Athena die meisten Analytics-on-S3-Anforderungen ohne jegliche Infrastruktur.

Ein kosteneffizientes Muster für eine „readings“-Tabelle, die als partitioniertes Parquet gespeichert ist:

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

Das Überspringen des Crawlers ist ein häufiger Fehler. Ohne einen Katalogeintrag schreiben Sie entweder manuelle CREATE EXTERNAL TABLE DDL (fragil, da sich Schemata weiterentwickeln) oder verwenden Schema-on-Read-Hacks, die jede Datei scannen. Schlimmer noch, ohne MSCK REPAIR TABLE oder Partition Projection scannt Athena bei jeder Abfrage das gesamte Präfix. Glue-Crawler erkennen neue Partitionen nach einem Zeitplan und aktualisieren den Katalog atomar.

Athena für verschlüsselte S3-Daten. Athena unterstützt SSE-S3, SSE-KMS und CSE-KMS, aber nur, wenn der Aufrufer die richtigen KMS-Berechtigungen hat und die Workgroup oder der Client für den verwendeten Verschlüsselungsmodus konfiguriert ist. Bei CSE-KMS wird die Datei vor dem Hochladen clientseitig verschlüsselt; der IAM-Prinzipal, der die Abfrage ausführt, benötigt kms:Decrypt und kms:GenerateDataKey für den CMK, und die Schlüsselrichtlinie muss dies erwidern. Ein häufiger Fehlermodus: Laden von CSE-KMS-Parquet, Gewähren von reinen S3-Leseberechtigungen für die Athena-Rolle und anschließendes Erhalten von undurchsichtigen AccessDenied- oder HIVE_CANNOT_OPEN_SPLIT-Fehlern – das Objekt ist lesbar, aber der Ciphertext kann nicht entschlüsselt werden. Ein weiterer häufiger Fehler ist die Registrierung der Tabelle mit dem falschen Verschlüsselungsmodus (SSE-KMS in den Tabelleneigenschaften, obwohl Objekte mit CSE-KMS geschrieben wurden); Athena versucht während des GetObject eine serverseitige Entschlüsselung, und die Nutzdaten kommen als roher Ciphertext zurück, der die Magic-Number-Prüfungen von Parquet fehlschlagen lässt.

Föderierte Abfragen in Athena ermöglichen es Ihnen, S3-Daten mit operativen Speichern (DynamoDB, RDS) zu verknüpfen, ohne Daten zu verschieben. Reservieren Sie Athena für leserorientierte Ad-hoc-Analysen; verwenden Sie Glue-Jobs für die geplante Aufbereitung von kuratierten Zonen.

Glue-Crawler, ETL-Jobs und Job-Bookmarks

Glue-Crawler scannen S3-Pfade, leiten das Schema ab (einschließlich Partitionsschlüssel aus der Verzeichnisstruktur wie year=2024/month=01/) und registrieren oder aktualisieren Tabellen im Katalog. Sie sind die Low-Code-Antwort auf die Anforderung: „Wir legen Dateien in S3 ab, machen Sie sie abfragbar.“ Planen Sie einen Crawler stündlich für einen Landing-Bucket, und Athena sieht sofort neue Partitionen.

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 oder Ray) übernehmen den Transformationsteil. Glue ist serverless – Sie zahlen pro DPU-Stunde mit einem Minimum von einer Minute – und die Laufzeitumgebung skaliert Worker automatisch. Das vorherrschende Muster ist CSV/JSON als Input und partitioniertes 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"})

Das entscheidende betriebliche Merkmal ist das Job-Bookmark: Glue speichert den Zustand darüber, welche Dateien oder Partitionen er bereits verarbeitet hat, sodass nachfolgende Läufe nur neue Daten lesen. Wenn man vergisst, Bookmarks zu aktivieren, bedeutet das, dass bei jedem Lauf der gesamte Datensatz von Anfang an neu verarbeitet wird, was Kosten und Laufzeit linear erhöht und oft doppelten Output erzeugt. Bookmarks werden pro Job aktiviert und müssen mit Quelloptionen gekoppelt werden, die sie unterstützen (S3-Quellen über den Glue DynamicFrame Reader tun dies; beliebige Spark-Leseoperationen nicht). Bookmarks erfordern ein transformation_ctx-Argument bei jeder Quelle und eine Umschließung durch job.init(...) / 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

Für eine reine Formatkonvertierung ohne Logik ist die Option mit dem geringsten Aufwand oft ein Glue-Crawler für die Rohdaten plus ein im visuellen Editor erstellter Glue-Job (oder ein DataBrew-Rezept) – kein Spark-Code erforderlich. Benutzerdefinierte EMR-Cluster oder Lambda-Konverter verursachen zusätzlichen Betriebsaufwand, den das serverlose Modell von Glue eliminiert.

Ein typischer täglicher Job, der S3-Daten kuratiert und in Redshift Serverless lädt:

# 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-Sicherheitskonfigurationen und mandantenfähiges ETL

Glue-Crawler und -Jobs benötigen das gleiche Bewusstsein für Verschlüsselung wie Athena. Sicherheitskonfigurationen in Glue sind benannte Bündel, die angeben, wie S3-Ziele, CloudWatch-Protokolle und Job-Bookmarks verschlüsselt werden – einschließlich CSE-KMS mit einem bestimmten CMK. Ein Job, der an eine Sicherheitskonfiguration angehängt ist, entschlüsselt CSE-KMS-Eingaben transparent und verschlüsselt Ausgaben auf die gleiche Weise, vorausgesetzt, die IAM-Rolle des Jobs verfügt über KMS-Berechtigungen für die referenzierten Schlüssel.

Für mandantenfähiges ETL – eine SaaS-Plattform, die die Daten jedes Kunden mit dem CMK dieses Kunden verarbeitet – ist das korrekte Muster eine Sicherheitskonfiguration pro Kunde (oder ein Job-Parameter, der den CMK auswählt) plus eine IAM-Rolle, deren Geltungsbereich auf diesen CMK beschränkt ist. Alle Kunden über einen einzigen Job mit einem einzigen gemeinsamen Schlüssel laufen zu lassen, hebt die Isolationsgarantie auf, die CSE-KMS eigentlich bieten soll.

Eine verwandte Disziplin: Analytische Produktionstabellen sollten nicht das direkte Ziel von explorativen Glue-Jobs oder Notebooks sein. Exportieren Sie einen Snapshot in ein S3-Präfix „analytics“ und verweisen Sie Athena oder Spark auf die Kopie. Das Ausführen experimenteller Transformationen auf der Live-Tabelle birgt das Risiko von Umschreibungen auf Partitionsebene, Beschädigung von Bookmarks und Lock-Konflikten und verwischt die Audit-Grenze zwischen Betriebsdaten und analytischen Ableitungen.

AWS Glue DataBrew

DataBrew ist das Low-Code-Pendant zu Glue für Benutzer, die keinen Spark-Code schreiben können oder sollten. Es bietet eine tabellenkalkulationsähnliche Benutzeroberfläche mit mehr als 250 vorgefertigten Transformationen (Imputation, PII-Maskierung, Ausreißer-Binning, Datums-Parsing). Seine Alleinstellungsmerkmale sind gemeinsam genutzte Rezepte (shared recipes) – versionierte JSON-Artefakte, die Sie veröffentlichen und projektübergreifend wiederverwenden können – und eine Visualisierung der Datenherkunft (Data Lineage), die Spalten von Quelldatensätzen über Rezepte und Jobs bis zu den Ausgabeorten verfolgt. Wählen Sie DataBrew, wenn Analysten die Transformationslogik verantworten; wählen Sie Glue Studio/Skripte, wenn Ingenieure sie verantworten und die Pipeline benutzerdefinierten Code, Streaming oder komplexe Joins benötigt.

Amazon EMR: Verteilte Batch-Verarbeitung und Runtime-Rollen

Amazon EMR ist eine verwaltete Cluster-Plattform, die Spark, Hadoop, Hive, Presto, HBase und Flink ausführt. Sein idealer Einsatzbereich sind große, parallelisierbare Batch- oder interaktive Workloads, die S3-Datensätze im Petabyte-Bereich lesen und sie zur Anreicherung mit einem anderen System of Record (oft Redshift) verknüpfen. EMR kann transiente (kurzlebige) Cluster (hochfahren, ausführen, beenden) oder langlebige Cluster betreiben und kann On-Demand-, Spot- und Reserved-Instances über Instance-Flotten mischen.

Ein kanonisches Muster: Ein Spark-Job liest Parquet aus S3, zieht Dimensionstabellen aus Redshift über UNLOAD-nach-S3, verknüpft sie über die Executors hinweg und schreibt den angereicherten Output zurück nach 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 ist hier im Vorteil, weil Spark den Join auf Dutzende von Knoten verteilt und das Staging über S3 einen Single-Threaded-JDBC-Engpass vermeidet. Die Falle besteht darin, reflexartig zu EMR zu greifen, wann immer S3-Daten abgefragt werden müssen. Für Ad-hoc-SQL auf zehn oder hunderten von Gigabytes ist die Bereitstellung und das Tuning eines Spark-Clusters reiner Betriebsaufwand – Cluster-Größenbestimmung, YARN-Konfiguration, Autoscaling, Log-Rotation, Patching. EMR macht sich nur dann bezahlt, wenn Volumen, benutzerdefinierter Code oder die Flexibilität der Ausführungs-Engine dies rechtfertigen.

EMR-Runtime-Rollen. Früher haben alle Schritte auf einem Cluster das EC2-Instanzprofil geerbt – eine einzige Rolle, die den zugrunde liegenden Knoten zugeordnet ist –, was bedeutete, dass jedes Team, das sich einen Cluster teilte, die Vereinigung aller Berechtigungen hatte, die irgendein Team benötigte. Runtime-Rollen lösen dieses Problem: Wenn ein Benutzer einen Schritt übermittelt, übergibt er --execution-role-arn, und EMR nimmt diese Rolle für die Dauer des Schritts an. Team A kann auf s3://team-a/* beschränkt werden, Team B auf s3://team-b/*. Das Instanzprofil wird zu einer schlanken Bootstrap-Rolle, die nur Cluster-Artefakte abruft.

Runtime-Rollen sind auch der Mechanismus zum Blockieren des IMDS-Zugriffs. Wenn aktiviert (EMR 6.7+ mit Spark/Hive auf YARN), kann der Benutzercode den Instanz-Metadatendienst – einschließlich IMDSv2 – nicht erreichen, weil die Plattform diese Aufrufe abfängt. Dies schließt den Eskalationspfad, über den ein Job andernfalls http://169.254.169.254/latest/api/token aufrufen und das mächtige EC2-Instanzprofil annehmen könnte.

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

Die Sicherheitskonfiguration ist das, was die Erzwingung von Runtime-Rollen und die IMDS-Blockierung ermöglicht. Ohne sie ist die Annahme, dass EMR-Workloads „automatisch Rollen mit den geringsten Rechten verwenden“, falsch – standardmäßig teilen sie sich das Instanzprofil und IMDS ist vom Benutzercode aus erreichbar.

Amazon Redshift und Redshift ML

Redshift ist ein spaltenbasiertes MPP-Data-Warehouse für nachhaltige Analyse-Workloads, die Dashboarding im Subsekundenbereich, komplexe Joins über Milliarden von Zeilen und konsistente Latenz bei gleichzeitigen BI-Benutzern erfordern. RA3-Knoten entkoppeln die Rechenleistung vom verwalteten Speicher; Redshift Serverless rechnet in RPU-Sekunden auf Basis einer konfigurierten Basiskapazität ab, skaliert unter Last und pausiert bei Inaktivität, wodurch das traditionelle Problem der Cluster-Dimensionierung entfällt.

Redshift nimmt an Analyse-Pipelines in zwei Anreicherungsmodi teil:

• Als Quelle: Spark auf EMR zieht Dimensionen über UNLOAD-nach-S3, oder Glue liest über die Redshift Data API.
• Als Ziel: Firehose oder ein Glue-Job lädt angereicherte Daten mittels COPY hinein.

Redshift Spectrum erweitert dies, indem es Redshift-SQL ermöglicht, S3 direkt über den Glue Data Catalog abzufragen – denselben Katalog, den auch Athena verwendet –, was das Lake-House-Muster ermöglicht. Ideal, wenn Sie bereits einen Redshift-Cluster haben und Fakten aus dem Warehouse mit kalten Verlaufsdaten in S3 verknüpfen möchten, ohne Daten zu verschieben.

Batch-Ladevorgänge verwenden COPY von S3, parallelisiert über die Compute-Knoten; Dateien sollten für die Parallelisierung in ungefähr gleich große Teile (ein Vielfaches der Anzahl der Slices) aufgeteilt werden:

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

Streaming-Ingestion fließt typischerweise durch Firehose (gepuffertes COPY) für eine Zero-Ops-Bereitstellung.

Redshift ML ermöglicht es SQL-Benutzern, Modelle über CREATE MODEL zu erstellen, zu trainieren und aufzurufen:

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;

Unter der Haube exportiert Redshift den Trainingsdatensatz nach S3, ruft SageMaker Autopilot (oder einen bestimmten Algorithmus wie XGBoost) auf und importiert das kompilierte Modell für In-Database-Inferenz. Dies ist leistungsstark, wenn Analysten bereits in SQL arbeiten, aber es ist kein Ersatz für eine vollständige ML-Plattform: Die Datenverschiebung nach S3 und die Rechenleistung für das SageMaker-Training werden separat abgerechnet, große Trainingsdatensätze können erhebliche Kosten für Egress und Autopilot-Laufzeit verursachen, und es gibt keinen integrierten Workflow für Feature Stores, Experiment-Tracking oder A/B-Deployments. Betrachten Sie Redshift ML als demokratisierte Inferenz über Redshift-Daten, nicht als allgemeines Training.

Wahl zwischen Athena und Redshift

Streaming-Ingestion: Kinesis Data Streams, Firehose und MSK

Die drei AWS-Streaming-Dienste lösen überlappende Probleme mit wesentlich unterschiedlichen Garantien:

Kinesis Data Streams verwendet Shards (oder den On-Demand-Modus); Datensätze mit demselben Partitionsschlüssel landen auf demselben Shard und werden der Reihe nach konsumiert. Konsumenten verwenden das klassische GetRecords oder Enhanced Fan-Out (dedizierte 2 MB/s pro Konsument). Eine als Event-Source angehängte Lambda-Funktion wird mit Batches pro Shard aufgerufen, wobei die Reihenfolge erhalten bleibt. Dies ist die richtige Wahl, wenn die nachgelagerte Logik nicht trivial ist, wenn mehrere unabhängige Konsumenten den Verlauf wiederholen müssen oder wenn die Clickstream-Volumen enorm sind – zum Beispiel würde eine Website, die 30 TB/Tag generiert, die Daten durch KDS in Firehose leiten, um sie in S3 für die Analyse mit Athena/Spectrum zu speichern.

Kinesis Data Firehose ist eine „Fire-and-Forget“-verwaltete Bereitstellung: Es puffert nach Größe oder Zeit (z. B. 5 MB / 300 Sekunden), ruft optional eine Lambda-Funktion zur Transformation auf, konvertiert optional JSON in Parquet/ORC unter Verwendung des Schemas einer Glue-Tabelle und schreibt nach S3, Redshift (über S3 + COPY), OpenSearch oder Splunk. Die Aktivierung der Parquet-Konvertierung in Firehose ist der einfachste Weg, Streaming-Daten in einem abfrageoptimierten Format zu speichern, ohne einen nachgelagerten Glue-Job zu benötigen:

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 hat keine End-to-End-Reihenfolgen-Garantie, kann nicht mehrere wiederholbare Konsumenten unterstützen, und seine Ziele sind feste Senken (Sinks). Firehose zu wählen, wenn die Anforderung lautet „jeden Datensatz der Reihe nach verarbeiten“ oder „mehrere unabhängige Konsumenten“, ist in beiden Punkten falsch. Ebenso ist es eine Falle zu erwarten, dass Firehose allein komplexe Transformationen durchführt – sein einziger Transformations-Hook ist eine Lambda, die pro gepuffertem Batch aufgerufen wird. Alles, was externe Anreicherung, Aggregation über mehrere Datensätze oder bedingtes Routing erfordert, muss in dieser Lambda-Funktion implementiert oder vorgelagert in den Managed Service for Apache Flink verlegt werden.

Amazon MSK ist verwaltetes Apache Kafka. Wählen Sie es, wenn Sie bereits Kafka-Producer/Consumer haben, Kafka-spezifische Funktionen benötigen (kompaktierte Topics, Transaktionen, Kafka Streams, Connect) oder einen Durchsatz benötigen, der über das hinausgeht, was shard-basiertes Kinesis bequem liefert.

Die Verwendung von SQS oder EventBridge als Ingest-Pfad für Analysen ist ein Fehler: SQS ist nicht pro Stream geordnet und bietet keine Wiederholungsfunktion (Replay); EventBridge ist für das Event-Routing optimiert, nicht für die nachhaltige Ingestion von mehreren MB/s.

Echtzeit-Suche: KDS + Firehose + OpenSearch + QuickSight

Der kanonische Ersatz für einen On-Premises Elasticsearch+Logstash-Stack ist:

Firehose puffert Stream-Datensätze und liefert sie direkt an eine OpenSearch-Domain, wobei es Wiederholungsversuche, S3-Backups und optionale Lambda-Transformationen übernimmt. OpenSearch Dashboards ist in die Domain integriert und kostenlos und eignet sich für Operatoren, die Echtzeit-Streams überwachen. QuickSight ergänzt dies für geschäftsorientierte Analysen – es fragt Athena, Redshift, RDS und OpenSearch direkt ab, und seine SPICE In-Memory-spaltenbasierte Engine zwischenspeichert verarbeitete Datensätze für eine Dashboard-Performance im Subsekundenbereich.

Eine typische Aufteilung: OpenSearch Dashboards für Operatoren; QuickSight für Führungskräfte, die aggregierte, kuratierte Datensätze aus dem Athena/Glue-Lake konsumieren. Beiden muss IAM-Lesezugriff und gegebenenfalls KMS Decrypt auf die CMKs gewährt werden, die den zugrunde liegenden Speicher schützen – andernfalls rendert die Visualisierungsschicht leere Panels mit Berechtigungsfehlern, die in den Abfrageprotokollen verborgen sind.

QuickSight-Zugriffskontrolle

QuickSight erstellt Datensätze (logische Abfragen plus berechnete Felder und Sicherheit auf Zeilenebene), dann Analysen auf Basis dieser Datensätze und veröffentlicht schließlich Dashboards (schreibgeschützte, teilbare Ansichten). Die Zugriffskontrolle ist mehrschichtig und muss auf der richtigen Ebene angewendet werden. Die Falle besteht darin, auf Dashboard-Ebene weitreichenden Zugriff zu gewähren – also die Freigabe für eine unternehmensweite Gruppe, obwohl nur eine Teilmenge die zugrunde liegenden Daten sehen sollte.

Das Prinzip der geringsten Rechte (Least Privilege) bedeutet in QuickSight:

• Den Datensatz nur mit den Benutzern/Gruppen teilen, die ihn benötigen.
• Sicherheit auf Zeilenebene über einen Berechtigungsdatensatz anwenden, der Zeilen nach Benutzername oder Gruppe filtert.
• Sicherheit auf Spaltenebene anwenden, um sensible Felder auszublenden.
• Dashboards mit bestimmten Benutzern, Gruppen oder (für eingebettete Analysen) Namespaces teilen.

Ein Dashboard öffentlich zu machen oder kontoübergreifend zu teilen, umgeht die Absicht der Kontrollen auf Datensatzebene, da Dashboard-Betrachter Lesezugriff auf die visualisierten Daten erben, unabhängig von den zugrunde liegenden Quellberechtigungen. Denken Sie daran, dass die Sicherheit auf Spaltenebene in QuickSight nur die QuickSight-Oberfläche schützt; jeder mit direktem Zugriff auf Athena oder S3 umgeht sie. Sensible Kontrollen gehören daher in Lake Formation oder den ETL-Prozess, nicht allein in QuickSight.

QuickSight-Rollen – Admin, Author, Reader – steuern, was ein Benutzer tun kann, und unterscheiden sich von Freigabeberechtigungen, die steuern, was er sehen kann. Ein Reader verursacht geringere Kosten pro Sitzung als eine Author-Lizenz, daher sollten Betrachter standardmäßig Reader sein, und der Zugriff sollte über Gruppenmitgliedschaften anstatt über individuelle Zuweisungen gewährt werden.

Amazon Neptune für Graph-Workloads

Neptune ist eine verwaltete Graph-Datenbank, die das Property-Graph-Modell (Gremlin, openCypher) und RDF (SPARQL) unterstützt. Sie ist speziell für stark vernetzte Daten konzipiert – soziale Beziehungen, Betrugsringe, Wissensgraphen, Empfehlungs-Engines – bei denen rekursive Joins in einer relationalen Datenbank unpraktikabel werden. Eine soziale Plattform mit Benutzern, Follows, Likes und Posts lässt sich natürlich auf Knoten (Vertices) und Kanten (Edges) abbilden, und Neptune beantwortet Multi-Hop-Traversierungen („Freunde von Freunden, denen X gefiel“) in Millisekunden.

Neptune Streams stellt ein geordnetes, zeitbasiertes Protokoll jeder Mutation des Graphen bereit. Ein Lambda oder eine Anwendung, die den Stream abfragt (Polling), kann auf Änderungen reagieren – Empfehlungen neu berechnen, einen Suchindex aktualisieren, Betrugswarnungen auslösen – ohne eine maßgeschneiderte Change-Data-Capture-Pipeline. Dies auf Aurora oder DynamoDB nachzubilden, erfordert Graphen-Traversierung auf Anwendungsebene plus eine separate CDC-Infrastruktur. Wenn die Problemstellung sowohl „Beziehungen analysieren“ als auch „Änderungen überwachen“ umfasst, ist Neptune mit Streams die direkte Lösung.

SageMaker: End-to-End Custom ML

SageMaker deckt den gesamten Lebenszyklus ab: Studio-Notebooks, verwaltete Trainingsjobs (mit Spot-Unterstützung), Model Registry, Echtzeit- und serverlose Endpunkte, Batch-Transformation und Pipelines für MLOps. Ein typischer Ablauf lädt Trainingsdaten nach S3 hoch, startet einen Trainingsjob, der einen integrierten Algorithmus oder einen benutzerdefinierten Container spezifiziert, und SageMaker stellt ephemere Instanzen bereit, streamt Protokolle zu CloudWatch und schreibt das Modell-Artefakt zurück nach S3. Das Deployment ist ein einziger API-Aufruf:

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

Es müssen kein Kubernetes, keine GPU-Treiber und kein Modell-Server verwaltet werden. Für Teams, deren Anforderung „ein Modell trainieren und bereitstellen“ lautet, ist SageMaker fast immer die Antwort mit dem geringsten Aufwand im Vergleich zu einer selbst erstellten Inferenzlösung auf ECS/EC2.

SageMaker Savings Plans sind eine Verpflichtung zu stündlichen Ausgaben in US-Dollar für qualifizierte Komponenten (Studio, Training, Verarbeitung, Echtzeit-Inferenz) für 1 oder 3 Jahre, was bis zu 64 % Rabatt auf On-Demand-Preise ermöglicht. Sie sind flexibel in Bezug auf Instanzfamilie, Größe, Region und Komponente – aber sie decken nicht Ground Truth, Speicher oder Datenübertragung ab. Nutzen Sie Savings Plans, wenn die grundlegende ML-Nutzung vorhersagbar ist; lassen Sie Burst-Training auf Spot-Instanzen laufen, um die Einsparungen zu erhöhen.

Verwaltete KI-Dienste im Vergleich zu benutzerdefiniertem ML

Amazon Rekognition (Bilder/Videos: Objekt- und Szenenerkennung, Gesichtsanalyse, Moderation), Textract (OCR plus Formular- und Tabellenextraktion) und Comprehend (NLP: Entitätserkennung, Stimmungsanalyse, PII-Erkennung, benutzerdefinierte Klassifizierung) stellen vortrainierte Modelle über einfache APIs bereit. Die DetectEntities-Funktion von Comprehend gibt typisierte Entitäten zurück, einschließlich der Kategorie COMMERCIAL_ITEM – perfekt, um Zutatennamen aus Rezepttexten zu extrahieren und sie in eine DynamoDB-Suche einzuspeisen, ohne Trainingsdaten, ohne Hosting und mit einem Pay-per-Request-Preismodell:

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

Ein häufiger Fehler ist das Over-Engineering – das Aufsetzen von SageMaker-Trainingsjobs, das Labeln von Daten mit Ground Truth und das Hosten von Endpunkten, obwohl ein verwalteter Dienst die Anforderung bereits zu einem Bruchteil der Betriebskosten abdeckt. Benutzerdefiniertes ML ist nur dann gerechtfertigt, wenn die Genauigkeit bei domänenspezifischen Daten wesentlich höher ist, wenn die benötigten Entitätstypen nicht mit dem Schema des verwalteten Dienstes übereinstimmen (Comprehend Custom Classification/Entity Recognition ist immer noch günstiger als reines SageMaker) oder wenn Latenz- und Datenresidenzanforderungen ein privates Modell erfordern.

HPC-Speicher und -Netzwerk: FSx for Lustre und EFA

Eng gekoppelte HPC-Workloads – CFD, Molekulardynamik, seismische Bildgebung, groß angelegtes Training – haben zwei unverzichtbare Anforderungen: eine extrem latenzarme Kommunikation zwischen den Knoten und einen gemeinsam genutzten Speicher mit hohem Durchsatz.

Elastic Fabric Adapter (EFA) ist eine Netzwerkschnittstelle, die für bestimmte EC2-Familien (hpc7a, hpc6id, c6in, p4d/p5, u.a.) verfügbar ist. Sie umgeht den TCP/IP-Stack des Kernels mithilfe von OS-Bypass Libfabric, wodurch MPI und NCCL Latenzen im Mikrosekundenbereich über Hunderte von Knoten hinweg erreichen können. EFA erfordert Instanzen in derselben Availability Zone und, für maximale Bandbreite, in einer Cluster Placement Group.

FSx for Lustre ist ein verwaltetes paralleles Dateisystem, das einen Durchsatz von Hunderten von GB/s und Latenzen im Sub-Millisekunden-Bereich liefert. Es ist nativ in S3 integriert: Ein FSx-Dateisystem kann mit einem Bucket verknüpft werden, sodass Objekte als POSIX-Dateien erscheinen, und Ergebnisse, die auf Lustre geschrieben werden, können zurück nach S3 exportiert werden. Persistente SSD-Deployments eignen sich für langlebigen Scratch-Speicher; Scratch2 ist günstiger für kurzlebige Job-Daten.

Das falsche Muster ist die Verwendung von EFS für HPC. EFS ist NFS-basiert und für viele kleine Clients optimiert, die allgemeine Datei-I/O-Vorgänge durchführen; es kann weder den aggregierten Durchsatz noch die Metadaten-IOPS aufrechterhalten, die ein 500-Knoten-MPI-Job benötigt, und sein Multi-AZ-Design führt zu zusätzlicher Latenz. Die Verwendung des Standard-ENA anstelle von EFA begrenzt MPI auf TCP-Latenzen, was die Laufzeiten von allreduce-intensiven Operationen um ein Vielfaches erhöht. Die korrekte Kombination sind EFA-fähige Instanzen in einer Cluster Placement Group, die FSx for Lustre mounten, mit S3 als langlebigem Cold Storage, der mit dem Dateisystem verknüpft ist.

← Datenbanken · Alle Domänen · Anwendungsintegration →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →