AWS SAA-C03: Analytics, Data Lake, ML & Specialized Workloads — Study Guide

By Laurynas Brazys · 15 July 2026 · #amazon #aws #saa-c03 #analytics-ml #certification #exam-prep #study-guide

Part of the AWS SAA-C03 Complete Study Guide. Practice these concepts with verified answers in the AWS/Amazon exam hub, or take timed practice tests on ExamRoll.io.

Data Lake Foundations: Lake Formation and the Glue Data Catalog

The center of gravity for AWS analytics is the AWS Glue Data Catalog — a Hive-metastore-compatible metastore that Athena, Redshift Spectrum, EMR, and Glue ETL all consume. Every table definition, partition, column type, and SerDe configuration lives here, and every downstream engine reads from it. If two ingestion paths (say, a Glue crawler and a manual CREATE EXTERNAL TABLE statement) disagree about the schema of the same S3 prefix, queries silently return wrong results or fail. The correct pattern is to designate a single authority per table: either the crawler owns the schema, or your ETL job writes via glueContext.write_dynamic_frame.from_catalog, but never both without a merge strategy. When batch ETL, Firehose Parquet conversion, and manual DDL all write to the same table, catalog drift is the silent killer. Enforce one owner per table, use the Glue Schema Registry for streaming producers, and run crawlers in LOG mode (not UPDATE_IN_DATABASE) on tables owned by ETL jobs so they surface drift without overwriting curated schemas.

AWS Lake Formation sits above the Data Catalog and replaces the coarse-grained IAM/S3 bucket policy model with a database-style permissions layer. Instead of granting s3:GetObject on a prefix, you GRANT SELECT ON customers.orders TO role/AnalystRole, and Lake Formation transparently vends short-lived credentials when Athena or Redshift Spectrum touches the underlying objects. Its real value is fine-grained authorization: column-level filtering, row-level security through data filters, and tag-based access control (LF-Tags) that scale across thousands of tables. A retail platform with PII in a customers table can grant analysts access to customer_id, region, signup_date while blocking email and ssn — enforced at query time, no view proliferation required.

The canonical setup for a 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 are pre-built workflow templates that stitch together crawlers, jobs, and triggers to ingest data from JDBC sources or S3 into a curated lake — reducing what would be dozens of hand-wired Glue resources to a wizard-driven flow.

A frequent mistake is trying to enforce column-level restrictions in QuickSight alone. QuickSight has row- and column-level security tied to datasets, but it only protects the QuickSight surface — anyone with direct Athena or S3 access bypasses it. Column-level control must be enforced at the data layer (Lake Formation grants, or physically separating columns during ETL), and QuickSight inherits that posture through its IAM role.

Athena: Serverless SQL Over S3

Athena is a serverless, pay-per-query Presto/Trino engine that reads directly from Amazon S3. No cluster to provision, no ETL step required before querying, and no cost when idle — you pay only for bytes scanned (typically $5/TB). This makes Athena the canonical choice for ad-hoc analysis of files already sitting in S3, whether JSON application logs, CSV exports, or Parquet fact tables. Athena needs a schema and partition layout, which lives in the Glue Data Catalog.

Since Athena bills per terabyte scanned, storage format has an outsized impact on cost and latency. The two levers are format and partitioning:

• Columnar formats (Parquet, ORC) let Athena prune columns and row groups. A query like SELECT sum(amount) FROM orders WHERE region='us-east-1' on Parquet reads only the two referenced columns; on CSV it reads every byte of every row.
• Partitioning on high-selectivity columns (e.g., dt=2024-03-11/) collapses a full-table scan into a targeted read. On multi-terabyte logs (CloudFront, ALB, VPC Flow Logs), this is the difference between a $0.15 query and a $30 query.

Converting raw JSON or CSV into partitioned, Snappy-compressed Parquet is almost always the first cost lever to pull. Combined with LIMIT pushdown, Athena handles most analytics-on-S3 needs with zero infrastructure.

A cost-effective pattern for a “readings” table stored as partitioned 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';

Skipping the crawler is a common mistake. Without a catalog entry, you either write manual CREATE EXTERNAL TABLE DDL (fragile as schemas evolve) or use schema-on-read hacks that scan every file. Worse, without MSCK REPAIR TABLE or partition projection, Athena scans the entire prefix on every query. Glue crawlers detect new partitions on a schedule and update the catalog atomically.

Athena on encrypted S3 data. Athena supports SSE-S3, SSE-KMS, and CSE-KMS, but only if the caller has the right KMS permissions and the workgroup or client is configured for the encryption mode in use. For CSE-KMS, the file is encrypted client-side before upload; the IAM principal running the query needs kms:Decrypt and kms:GenerateDataKey on the CMK, and the key policy must reciprocate. A common failure mode: loading CSE-KMS Parquet, granting the Athena role only S3 read permissions, and then getting opaque AccessDenied or HIVE_CANNOT_OPEN_SPLIT errors — the object is readable but the ciphertext cannot be unwrapped. Another frequent mistake is registering the table with the wrong encryption mode (SSE-KMS in table properties when objects were written with CSE-KMS); Athena attempts server-side decryption during GetObject and the payload comes back as raw ciphertext that fails Parquet magic-number checks.

Athena federated queries let you join S3 data with operational stores (DynamoDB, RDS) without moving data. Reserve Athena for read-oriented ad-hoc analytics; use Glue jobs for scheduled shaping of curated zones.

Glue Crawlers, ETL Jobs, and Job Bookmarks

Glue crawlers scan S3 paths, infer schema (including partition keys from directory structure like year=2024/month=01/), and register or update tables in the catalog. They are the low-code answer to “we drop files in S3, make them queryable.” Schedule a crawler hourly against a landing bucket and Athena immediately sees new partitions.

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, or Ray) handle the transformation half. Glue is serverless — you pay per DPU-hour with a one-minute minimum — and the runtime scales workers automatically. The dominant pattern is CSV/JSON in, partitioned Parquet out:

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

The critical operational feature is the job bookmark: Glue persists state about which files or partitions it has already processed, so subsequent runs read only new data. Forgetting to enable bookmarks means every run reprocesses the entire dataset from the beginning, inflating cost and runtime linearly and often producing duplicate output. Bookmarks are enabled per-job and must be paired with source options that support them (S3 sources via the Glue DynamicFrame reader do; arbitrary Spark reads do not). Bookmarks require a transformation_ctx argument on every source and job.init(...) / job.commit() bracketing:

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

For pure format conversion with no logic, the least-effort option is often a Glue crawler on raw plus a Glue job authored in the visual editor (or a DataBrew recipe) — no Spark code required. Custom EMR clusters or Lambda converters add operational overhead that Glue’s serverless model eliminates.

A typical daily job that curates S3 data and loads 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/")

Glue Security Configurations and Multi-Tenant ETL

Glue crawlers and jobs need the same encryption awareness as Athena. Glue security configurations are named bundles specifying how S3 targets, CloudWatch logs, and job bookmarks are encrypted — including CSE-KMS with a specific CMK. A job attached to a security configuration transparently decrypts CSE-KMS input and encrypts outputs the same way, provided the job’s IAM role has KMS permissions on the referenced keys.

For multi-tenant ETL — a SaaS platform processing each customer’s data with that customer’s CMK — the correct pattern is one security configuration per customer (or a job parameter selecting the CMK) plus an IAM role scoped to that CMK. Running every customer through a single job with a single shared key defeats the isolation guarantee CSE-KMS is intended to provide.

A related discipline: production analytical tables should not be the direct target of exploratory Glue jobs or notebooks. Export a snapshot to an S3 “analytics” prefix and point Athena or Spark at the copy. Running experimental transforms on the live table risks partition-level rewrites, bookmark corruption, and lock contention, and blurs the audit boundary between operational data and analytical derivatives.

AWS Glue DataBrew

DataBrew is Glue’s low-code sibling for users who cannot or should not write Spark. It offers a spreadsheet-style UI with more than 250 prebuilt transformations (imputation, PII masking, outlier binning, date parsing). Its differentiators are shared recipes — versioned JSON artifacts you can publish and re-apply across projects — and data lineage visualization that traces columns from source datasets through recipes and jobs to output locations. Choose DataBrew when analysts own the transformation logic; choose Glue Studio/scripts when engineers own it and the pipeline needs custom code, streaming, or complex joins.

Amazon EMR: Distributed Batch and Runtime Roles

Amazon EMR is a managed cluster platform running Spark, Hadoop, Hive, Presto, HBase, and Flink. Its sweet spot is large, parallelizable batch or interactive workloads that read petabyte-scale S3 datasets and join them against another system of record (often Redshift) for enrichment. EMR can run transient clusters (spin up, execute, terminate) or long-running ones, and can mix On-Demand, Spot, and Reserved instances via instance fleets.

A canonical pattern: a Spark job reads Parquet from S3, pulls dimension tables from Redshift via UNLOAD-to-S3, joins them across executors, and writes enriched output back to 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 wins here because Spark distributes the join across dozens of nodes and staging via S3 avoids a single-threaded JDBC bottleneck. The trap is reflexively reaching for EMR whenever S3 data needs querying. For ad-hoc SQL on tens or hundreds of gigabytes, provisioning and tuning a Spark cluster is pure operational overhead — cluster sizing, YARN configuration, autoscaling, log rotation, patching. EMR earns its keep only when volume, custom code, or execution-engine flexibility justifies it.

EMR runtime roles. Historically all steps on a cluster inherited the EC2 instance profile — one role attached to the underlying nodes — meaning every team sharing a cluster had the union of every permission any team needed. Runtime roles solve this: when a user submits a step they pass --execution-role-arn, and EMR assumes that role for the step’s duration. Team A can be restricted to s3://team-a/*, Team B to s3://team-b/*. The instance profile becomes a thin bootstrap role that only fetches cluster artifacts.

Runtime roles are also the mechanism for blocking IMDS access. When enabled (EMR 6.7+ with Spark/Hive on YARN), user code cannot reach the instance metadata service — including IMDSv2 — because the platform intercepts those calls. This closes the escalation path where a job could otherwise call http://169.254.169.254/latest/api/token and assume the powerful EC2 instance profile.

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

The security configuration is what enables runtime role enforcement and IMDS blocking. Without it, assuming that EMR workloads “automatically use least-privilege roles” is wrong — by default they share the instance profile and IMDS is reachable from user code.

Amazon Redshift and Redshift ML

Redshift is a columnar MPP data warehouse for sustained analytics workloads requiring sub-second dashboarding, complex joins on billions of rows, and consistent latency under concurrent BI users. RA3 nodes decouple compute from managed storage; Redshift Serverless bills in RPU-seconds against a configured base capacity, scales under load, and pauses when idle, eliminating the traditional cluster-sizing problem.

Redshift participates in analytics pipelines in two enrichment modes:

• As a source: Spark on EMR pulls dimensions via UNLOAD-to-S3, or Glue reads via the Redshift Data API.
• As a target: Firehose or a Glue job COPYs enriched data in.

Redshift Spectrum extends this by letting Redshift SQL query S3 directly through the Glue Data Catalog — the same catalog Athena uses — which is what makes the lake-house pattern work. Ideal when you already have a Redshift cluster and want to join warehoused facts against cold S3 history without moving data.

Batch loads use COPY from S3, parallelized across compute nodes; files should be split into roughly equal chunks (a multiple of the slice count) for parallelism:

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

Streaming ingestion typically flows through Firehose (buffered COPY) for zero-ops delivery.

Redshift ML lets SQL users create, train, and invoke models 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;

Under the hood Redshift exports the training set to S3, invokes SageMaker Autopilot (or a specified algorithm like XGBoost), and imports the compiled model for in-database inference. Powerful when analysts already live in SQL, but it is not a replacement for a full ML platform: data movement to S3 and SageMaker training compute are billed separately, large training sets can generate significant egress and Autopilot runtime charges, and there is no built-in workflow for feature stores, experiment tracking, or A/B deployment. Treat Redshift ML as democratized inference over Redshift data, not general-purpose training.

Choosing Between Athena and Redshift

Streaming Ingestion: Kinesis Data Streams, Firehose, and MSK

The three AWS streaming services solve overlapping problems with materially different guarantees:

Kinesis Data Streams uses shards (or on-demand mode); records with the same partition key land on the same shard and are consumed in order. Consumers use classic GetRecords or Enhanced Fan-Out (dedicated 2 MB/s per consumer). A Lambda function attached as an event source is invoked with batches per shard, preserving order. This is the correct choice when downstream logic is non-trivial, when multiple independent consumers must replay history, or when clickstream volumes are enormous — for example, a site generating 30 TB/day would flow through KDS into Firehose and land in S3 for Athena/Spectrum analysis.

Kinesis Data Firehose is fire-and-forget managed delivery: it buffers by size or time (e.g., 5 MB / 300 seconds), optionally invokes a Lambda for transformation, optionally converts JSON to Parquet/ORC using a Glue table’s schema, and writes to S3, Redshift (via S3 + COPY), OpenSearch, or Splunk. Turning on Parquet conversion in Firehose is the low-effort way to land streaming data in query-optimized format without a 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 has no end-to-end ordering guarantee, cannot support multiple replayable consumers, and its destinations are fixed sinks. Choosing Firehose when the requirement says “process each record in order” or “multiple independent consumers” is wrong on both counts. Similarly, expecting Firehose alone to perform complex transformations is a trap — its only transform hook is a Lambda invoked per buffered batch. Anything involving external enrichment, multi-record aggregation, or conditional routing must live in that Lambda or move upstream to Managed Service for Apache Flink.

Amazon MSK is managed Apache Kafka. Choose it when you already have Kafka producers/consumers, need Kafka-specific features (compacted topics, transactions, Kafka Streams, Connect), or require throughput beyond what shard-based Kinesis comfortably delivers.

Using SQS or EventBridge as an analytics ingest path is a mistake: SQS is not ordered per stream and lacks replay; EventBridge is optimized for event routing, not sustained multi-MB/s ingestion.

Real-Time Search: KDS + Firehose + OpenSearch + QuickSight

The canonical replacement for an on-premises Elasticsearch+Logstash stack is:

Firehose buffers stream records and delivers them directly to an OpenSearch domain, handling retry, S3 backup, and optional Lambda transformation. OpenSearch Dashboards is embedded and free with the domain and suits operators watching real-time streams. QuickSight complements this for business-facing analytics — it queries Athena, Redshift, RDS, and OpenSearch directly, and its SPICE in-memory columnar engine caches processed datasets for sub-second dashboard performance.

A typical split: OpenSearch Dashboards for operators; QuickSight for executives consuming aggregated, curated datasets sourced from the Athena/Glue lake. Both must be granted IAM read access and, where applicable, KMS Decrypt on the CMKs protecting underlying storage — otherwise the visualization layer renders empty panels with permission errors buried in query logs.

QuickSight Access Control

QuickSight builds datasets (logical queries plus calculated fields and row-level security), then analyses on top of datasets, then publishes dashboards (read-only shareable views). Access control is layered and must be applied at the correct layer. The trap is granting broad access at the dashboard level — sharing to an org-wide group when only a subset should see the underlying data.

Least privilege in QuickSight means:

• Share the dataset with only users/groups that need it.
• Apply row-level security via a permissions dataset that filters rows by username or group.
• Apply column-level security to hide sensitive fields.
• Share dashboards with specific users, groups, or (for embedded analytics) namespaces.

Making a dashboard public or sharing account-wide bypasses the intent of dataset-level controls, because dashboard viewers inherit read access to visualized data regardless of underlying source permissions. Remember that QuickSight column-level security only protects the QuickSight surface; anyone with direct Athena or S3 access bypasses it, so sensitive controls belong in Lake Formation or ETL, not in QuickSight alone.

QuickSight roles — Admin, Author, Reader — control what a user can do, distinct from sharing permissions that control what they can see. A Reader consumes at a lower per-session cost than an Author license, so viewer populations should be Readers by default, and access should be granted through group membership rather than individual assignment.

Amazon Neptune for Graph Workloads

Neptune is a managed graph database supporting the property-graph model (Gremlin, openCypher) and RDF (SPARQL). It is purpose-built for highly connected data — social relationships, fraud rings, knowledge graphs, recommendation engines — where recursive joins in a relational database become prohibitive. A social platform with users, follows, likes, and posts maps naturally to vertices and edges, and Neptune answers multi-hop traversals (“friends of friends who liked X”) in milliseconds.

Neptune Streams exposes an ordered time-based log of every mutation to the graph. A Lambda or application polling the stream can react to changes — recompute recommendations, update a search index, trigger fraud alerts — without a bespoke change-data-capture pipeline. Reproducing this on Aurora or DynamoDB requires application-level graph traversal plus separate CDC plumbing. When the problem statement includes both “analyze relationships” and “monitor changes,” Neptune with Streams is the direct match.

SageMaker: End-to-End Custom ML

SageMaker provides the full lifecycle: Studio notebooks, managed training jobs (with spot support), Model Registry, real-time and serverless endpoints, batch transform, and Pipelines for MLOps. A typical flow uploads training data to S3, launches a training job specifying a built-in algorithm or custom container, and SageMaker provisions ephemeral instances, streams logs to CloudWatch, and writes the model artifact back to S3. Deployment is a single 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")

No Kubernetes, GPU driver, or model server to manage. For teams whose requirement is “train and expose a model,” SageMaker is nearly always the least-overhead answer versus rolling ECS/EC2 inference.

SageMaker Savings Plans commit to a dollar-per-hour spend across eligible components (Studio, training, processing, real-time inference) for 1 or 3 years, yielding up to 64% off on-demand. They are flexible across instance family, size, region, and component — but do not cover Ground Truth, storage, or data transfer. Use Savings Plans when baseline ML usage is predictable; leave burst training on spot instances to compound savings.

Managed AI Services Versus Custom ML

Amazon Rekognition (images/video: object and scene detection, face analysis, moderation), Textract (OCR plus form and table extraction), and Comprehend (NLP: entity recognition, sentiment, PII detection, custom classification) expose pretrained models behind simple APIs. Comprehend’s DetectEntities returns typed entities including a COMMERCIAL_ITEM category — perfect for pulling ingredient names out of recipe text and feeding a DynamoDB lookup, with no training data, no hosting, and pay-per-request pricing:

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

The common failure mode is over-engineering — standing up SageMaker training jobs, labeling data with Ground Truth, and hosting endpoints when a managed service already covers the requirement at a fraction of the operational cost. Custom ML is justified only when accuracy on domain-specific data is materially higher, when needed entity types don’t match the managed schema (Comprehend Custom Classification/Entity Recognition is still cheaper than raw SageMaker), or when latency and data-residency constraints demand a private model.

HPC Storage and Networking: FSx for Lustre and EFA

Tightly coupled HPC workloads — CFD, molecular dynamics, seismic imaging, large-scale training — have two non-negotiable requirements: extremely low-latency inter-node communication and high-throughput shared storage.

Elastic Fabric Adapter (EFA) is a network interface available on specific EC2 families (hpc7a, hpc6id, c6in, p4d/p5, others). It bypasses the kernel TCP/IP stack using OS-bypass Libfabric, letting MPI and NCCL achieve microsecond latencies across hundreds of nodes. EFA requires instances in the same Availability Zone and, for maximum bandwidth, in a cluster placement group.

FSx for Lustre is a managed parallel file system delivering hundreds of GB/s throughput and sub-millisecond latency. It integrates natively with S3: an FSx file system can be linked to a bucket so objects appear as POSIX files, and results written to Lustre can be exported back to S3. Persistent SSD deployments suit long-lived scratch; Scratch2 is cheaper for ephemeral job data.

The wrong pattern is using EFS for HPC. EFS is NFS-based, tuned for many small clients doing general-purpose file I/O; it cannot sustain the aggregate throughput or metadata IOPS a 500-node MPI job needs, and its multi-AZ design adds latency. Using standard ENA instead of EFA caps MPI at TCP latencies, multiplying allreduce-heavy runtimes several-fold. The correct pairing is EFA-enabled instances in a cluster placement group mounting FSx for Lustre, with S3 as durable cold storage linked to the file system.

← Previous: Databases · All domains · Next: Application Integration →

Practice Analytics questions → · Timed practice on ExamRoll.io →

Browse Amazon →