Amazon SAA-C03: Análisis, Data Lake, ML y Cargas de Trabajo Especializadas — Guía de estudio

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

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Fundamentos de Data Lake: Lake Formation y el Catálogo de Datos de Glue

El centro de gravedad para el análisis de AWS es el Catálogo de Datos de AWS Glue, un metastore compatible con Hive que Athena, Redshift Spectrum, EMR y Glue ETL consumen. Cada definición de tabla, partición, tipo de columna y configuración de SerDe vive aquí, y cada motor descendente lee de él. Si dos rutas de ingesta (por ejemplo, un rastreador de Glue y una instrucción manual CREATE EXTERNAL TABLE) no están de acuerdo sobre el esquema del mismo prefijo de S3, las consultas devuelven silenciosamente resultados incorrectos o fallan. El patrón correcto es designar una única autoridad por tabla: o el rastreador es el propietario del esquema, o su trabajo ETL escribe a través de glueContext.write_dynamic_frame.from_catalog, pero nunca ambos sin una estrategia de fusión. Cuando el ETL por lotes, la conversión de Firehose Parquet y el DDL manual escriben en la misma tabla, la deriva del catálogo es el asesino silencioso. Aplique un propietario por tabla, use el Registro de Esquemas de Glue para productores de streaming y ejecute rastreadores en modo LOG (no UPDATE_IN_DATABASE) en tablas propiedad de trabajos ETL para que detecten la deriva sin sobrescribir los esquemas curados.

AWS Lake Formation se encuentra por encima del Catálogo de Datos y reemplaza el modelo de políticas de bucket de IAM/S3 de grano grueso con una capa de permisos estilo base de datos. En lugar de otorgar s3:GetObject en un prefijo, usted GRANT SELECT ON customers.orders TO role/AnalystRole, y Lake Formation proporciona de forma transparente credenciales de corta duración cuando Athena o Redshift Spectrum tocan los objetos subyacentes. Su valor real es la autorización de grano fino: filtrado a nivel de columna, seguridad a nivel de fila a través de filtros de datos y control de acceso basado en etiquetas (LF-Tags) que se escala a miles de tablas. Una plataforma minorista con PII en una tabla de customers puede otorgar a los analistas acceso a customer_id, region, signup_date mientras bloquea email y ssn, aplicado en tiempo de consulta, sin necesidad de proliferación de vistas.

La configuración canónica para un lago gobernado:

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.

Los planos de Lake Formation son plantillas de flujo de trabajo preconstruidas que unen rastreadores, trabajos y disparadores para ingerir datos de fuentes JDBC o S3 en un lago curado, lo que reduce lo que serían docenas de recursos de Glue cableados manualmente a un flujo guiado por un asistente.

Un error frecuente es intentar aplicar restricciones a nivel de columna solo en QuickSight. QuickSight tiene seguridad a nivel de fila y columna vinculada a los conjuntos de datos, pero solo protege la superficie de QuickSight; cualquiera con acceso directo a Athena o S3 la elude. El control a nivel de columna debe aplicarse en la capa de datos (concesiones de Lake Formation, o separación física de columnas durante el ETL), y QuickSight hereda esa postura a través de su rol de IAM.

Athena: SQL sin servidor sobre S3

Athena es un motor Presto/Trino sin servidor de pago por consulta que lee directamente desde Amazon S3. No hay clúster que aprovisionar, no se requiere un paso de ETL antes de consultar y no hay costo cuando está inactivo: solo paga por los bytes escaneados (típicamente $5/TB). Esto convierte a Athena en la opción canónica para el análisis ad-hoc de archivos que ya se encuentran en S3, ya sean registros de aplicaciones JSON, exportaciones CSV o tablas de hechos Parquet. Athena necesita un esquema y un diseño de partición, que reside en el Catálogo de datos de Glue.

Dado que Athena factura por terabyte escaneado, el formato de almacenamiento tiene un impacto desproporcionado en el costo y la latencia. Las dos palancas son el formato y el particionamiento:

• Los formatos columnares (Parquet, ORC) permiten a Athena podar columnas y grupos de filas. Una consulta como SELECT sum(amount) FROM orders WHERE region='us-east-1' en Parquet lee solo las dos columnas referenciadas; en CSV lee cada byte de cada fila.
• El particionamiento en columnas de alta selectividad (por ejemplo, dt=2024-03-11/) colapsa un escaneo de tabla completa en una lectura dirigida. En registros de varios terabytes (CloudFront, ALB, VPC Flow Logs), esta es la diferencia entre una consulta de $0.15 y una de $30.

Convertir JSON o CSV sin procesar en Parquet particionado y comprimido con Snappy es casi siempre la primera palanca de costos a utilizar. Combinado con el LIMIT pushdown, Athena maneja la mayoría de las necesidades de análisis en S3 con infraestructura cero.

Un patrón rentable para una tabla de “lecturas” almacenada como Parquet particionado:

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

Saltarse el rastreador es un error común. Sin una entrada de catálogo, o bien escribe DDL CREATE EXTERNAL TABLE manual (frágil a medida que evolucionan los esquemas) o usa trucos de esquema en lectura que escanean cada archivo. Peor aún, sin MSCK REPAIR TABLE o proyección de particiones, Athena escanea todo el prefijo en cada consulta. Los rastreadores de Glue detectan nuevas particiones según un cronograma y actualizan el catálogo de forma atómica.

Athena en datos S3 cifrados. Athena admite SSE-S3, SSE-KMS y CSE-KMS, pero solo si la persona que llama tiene los permisos KMS correctos y el grupo de trabajo o cliente está configurado para el modo de cifrado en uso. Para CSE-KMS, el archivo se cifra del lado del cliente antes de la carga; el principal de IAM que ejecuta la consulta necesita kms:Decrypt y kms:GenerateDataKey en la CMK, y la política de claves debe ser recíproca. Un modo de falla común: cargar Parquet CSE-KMS, otorgar al rol de Athena solo permisos de lectura de S3 y luego obtener errores opacos de AccessDenied o HIVE_CANNOT_OPEN_SPLIT: el objeto es legible pero el texto cifrado no se puede desenvolver. Otro error frecuente es registrar la tabla con el modo de cifrado incorrecto (SSE-KMS en las propiedades de la tabla cuando los objetos se escribieron con CSE-KMS); Athena intenta el descifrado del lado del servidor durante GetObject y la carga útil regresa como texto cifrado sin procesar que falla las comprobaciones de números mágicos de Parquet.

Las consultas federadas de Athena le permiten unir datos de S3 con almacenes operativos (DynamoDB, RDS) sin mover datos. Reserve Athena para análisis ad-hoc orientados a la lectura; use trabajos de Glue para la conformación programada de zonas seleccionadas.

Rastreadores de Glue, trabajos de ETL y marcadores de trabajos

Los rastreadores de Glue escanean rutas de S3, infieren el esquema (incluidas las claves de partición de la estructura de directorios como year=2024/month=01/) y registran o actualizan tablas en el catálogo. Son la respuesta de bajo código a “dejamos archivos en S3, los hacemos consultables”. Programe un rastreador cada hora en un bucket de aterrizaje y Athena verá inmediatamente nuevas particiones.

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

Los trabajos de ETL de Glue (Spark, shell de Python o Ray) manejan la mitad de la transformación. Glue no tiene servidor (paga por hora de DPU con un mínimo de un minuto) y el tiempo de ejecución escala los trabajadores automáticamente. El patrón dominante es CSV/JSON de entrada, Parquet particionado de salida:

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

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

La característica operativa crítica es el marcador de trabajo: Glue persiste el estado sobre qué archivos o particiones ya ha procesado, por lo que las ejecuciones posteriores leen solo datos nuevos. Olvidarse de habilitar los marcadores significa que cada ejecución reprocesa todo el conjunto de datos desde el principio, inflando el costo y el tiempo de ejecución linealmente y, a menudo, produciendo resultados duplicados. Los marcadores se habilitan por trabajo y deben combinarse con opciones de origen que los admitan (las fuentes de S3 a través del lector DynamicFrame de Glue sí lo hacen; las lecturas arbitrarias de Spark no). Los marcadores requieren un argumento transformation_ctx en cada origen y job.init(...) / job.commit() entre corchetes:

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

Para la conversión de formato puro sin lógica, la opción de menor esfuerzo suele ser un rastreador de Glue en bruto más un trabajo de Glue creado en el editor visual (o una receta de DataBrew), sin necesidad de código Spark. Los clústeres EMR personalizados o los convertidores Lambda añaden una sobrecarga operativa que el modelo sin servidor de Glue elimina.

Un trabajo diario típico que organiza datos de S3 y carga 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/")

Configuraciones de seguridad de Glue y ETL multi-inquilino

Los rastreadores y trabajos de Glue necesitan la misma conciencia de cifrado que Athena. Las configuraciones de seguridad de Glue son paquetes con nombre que especifican cómo se cifran los destinos de S3, los registros de CloudWatch y los marcadores de trabajo, incluido CSE-KMS con una CMK específica. Un trabajo adjunto a una configuración de seguridad descifra de forma transparente la entrada de CSE-KMS y cifra las salidas de la misma manera, siempre que el rol de IAM del trabajo tenga permisos de KMS en las claves referenciadas.

Para ETL multi-inquilino (una plataforma SaaS que procesa los datos de cada cliente con la CMK de ese cliente), el patrón correcto es una configuración de seguridad por cliente (o un parámetro de trabajo que seleccione la CMK) más un rol de IAM con ámbito para esa CMK. Ejecutar a cada cliente a través de un solo trabajo con una única clave compartida anula la garantía de aislamiento que CSE-KMS pretende proporcionar.

Una disciplina relacionada: las tablas analíticas de producción no deben ser el objetivo directo de trabajos o notebooks exploratorios de Glue. Exporte una instantánea a un prefijo S3 de “análisis” y apunte Athena o Spark a la copia. Ejecutar transformaciones experimentales en la tabla en vivo conlleva riesgos de reescrituras a nivel de partición, corrupción de marcadores y contención de bloqueos, y difumina el límite de auditoría entre los datos operativos y los derivados analíticos.

AWS Glue DataBrew

DataBrew es el hermano de bajo código de Glue para usuarios que no pueden o no deben escribir Spark. Ofrece una interfaz de usuario estilo hoja de cálculo con más de 250 transformaciones predefinidas (imputación, enmascaramiento de PII, clasificación de valores atípicos, análisis de fechas). Sus diferenciadores son las recetas compartidas —artefactos JSON versionados que se pueden publicar y volver a aplicar en diferentes proyectos— y la visualización del linaje de datos que rastrea las columnas desde los conjuntos de datos de origen a través de recetas y trabajos hasta las ubicaciones de salida. Elija DataBrew cuando los analistas sean los dueños de la lógica de transformación; elija Glue Studio/scripts cuando los ingenieros sean los dueños y la canalización necesite código personalizado, streaming o uniones complejas.

Amazon EMR: Roles de tiempo de ejecución y de procesamiento por lotes distribuidos

Amazon EMR es una plataforma de clústeres gestionada que ejecuta Spark, Hadoop, Hive, Presto, HBase y Flink. Su punto fuerte son las cargas de trabajo interactivas o por lotes grandes y paralelizadas que leen conjuntos de datos de S3 a escala de petabytes y los unen con otro sistema de registro (a menudo Redshift) para su enriquecimiento. EMR puede ejecutar clústeres transitorios (iniciar, ejecutar, terminar) o de larga duración, y puede mezclar instancias bajo demanda, Spot y reservadas a través de flotas de instancias.

Un patrón canónico: un trabajo de Spark lee Parquet de S3, extrae tablas de dimensiones de Redshift a través de UNLOAD-to-S3, las une entre ejecutores y escribe la salida enriquecida de nuevo en 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 gana aquí porque Spark distribuye la unión entre docenas de nodos y la preparación a través de S3 evita un cuello de botella JDBC de un solo hilo. La trampa es recurrir de forma refleja a EMR siempre que los datos de S3 necesiten ser consultados. Para SQL ad-hoc en decenas o cientos de gigabytes, aprovisionar y ajustar un clúster de Spark es pura sobrecarga operativa: dimensionamiento del clúster, configuración de YARN, autoescalado, rotación de registros, parcheo. EMR solo se justifica cuando el volumen, el código personalizado o la flexibilidad del motor de ejecución lo justifican.

Roles de tiempo de ejecución de EMR. Históricamente, todos los pasos de un clúster heredaban el perfil de instancia de EC2 —un rol adjunto a los nodos subyacentes— lo que significaba que cada equipo que compartía un clúster tenía la unión de todos los permisos que cualquier equipo necesitaba. Los roles de tiempo de ejecución resuelven esto: cuando un usuario envía un paso, pasa --execution-role-arn, y EMR asume ese rol durante la duración del paso. El equipo A puede estar restringido a s3://team-a/*, el equipo B a s3://team-b/*. El perfil de instancia se convierte en un rol de arranque delgado que solo recupera artefactos del clúster.

Los roles de tiempo de ejecución también son el mecanismo para bloquear el acceso a IMDS. Cuando está habilitado (EMR 6.7+ con Spark/Hive en YARN), el código de usuario no puede acceder al servicio de metadatos de instancia —incluido IMDSv2— porque la plataforma intercepta esas llamadas. Esto cierra la ruta de escalada donde un trabajo podría llamar a http://169.254.169.254/latest/api/token y asumir el potente perfil de instancia de EC2.

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

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

La configuración de seguridad es lo que permite la aplicación de roles de tiempo de ejecución y el bloqueo de IMDS. Sin ella, asumir que las cargas de trabajo de EMR “usan automáticamente roles de privilegio mínimo” es incorrecto; por defecto, comparten el perfil de instancia y IMDS es accesible desde el código de usuario.

Amazon Redshift y Redshift ML

Redshift es un almacén de datos MPP columnar para cargas de trabajo analíticas sostenidas que requieren paneles en subsegundos, uniones complejas en miles de millones de filas y latencia consistente bajo usuarios de BI concurrentes. Los nodos RA3 desacoplan el cómputo del almacenamiento gestionado; Redshift Serverless factura en RPU-segundos contra una capacidad base configurada, escala bajo carga y se pausa cuando está inactivo, eliminando el problema tradicional del dimensionamiento del clúster.

Redshift participa en las canalizaciones de análisis en dos modos de enriquecimiento:

• Como origen: Spark en EMR extrae dimensiones a través de UNLOAD-to-S3, o Glue lee a través de la API de datos de Redshift.
• Como destino: Firehose o un trabajo de Glue COPIA los datos enriquecidos.

Redshift Spectrum extiende esto al permitir que Redshift SQL consulte S3 directamente a través del Catálogo de datos de Glue —el mismo catálogo que usa Athena— que es lo que hace que el patrón de lago de datos funcione. Ideal cuando ya tiene un clúster de Redshift y desea unir hechos almacenados en el almacén con el historial frío de S3 sin mover datos.

Las cargas por lotes usan COPY desde S3, paralelizadas entre los nodos de cómputo; los archivos deben dividirse en fragmentos aproximadamente iguales (un múltiplo del número de segmentos) para el paralelismo:

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

La ingesta de streaming generalmente fluye a través de Firehose (COPY con búfer) para una entrega sin operaciones.

Redshift ML permite a los usuarios de SQL crear, entrenar e invocar modelos a través de 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;

Internamente, Redshift exporta el conjunto de entrenamiento a S3, invoca SageMaker Autopilot (o un algoritmo especificado como XGBoost) e importa el modelo compilado para la inferencia en la base de datos. Potente cuando los analistas ya trabajan en SQL, pero no es un reemplazo para una plataforma ML completa: el movimiento de datos a S3 y el cómputo de entrenamiento de SageMaker se facturan por separado, los grandes conjuntos de entrenamiento pueden generar importantes cargos de egreso y tiempo de ejecución de Autopilot, y no hay un flujo de trabajo incorporado para almacenes de características, seguimiento de experimentos o despliegue A/B. Trate Redshift ML como inferencia democratizada sobre datos de Redshift, no como entrenamiento de propósito general.

Cómo elegir entre Athena y Redshift

Ingesta de Streaming: Kinesis Data Streams, Firehose y MSK

Los tres servicios de streaming de AWS resuelven problemas superpuestos con garantías materialmente diferentes:

Kinesis Data Streams utiliza shards (o modo bajo demanda); los registros con la misma clave de partición aterrizan en el mismo shard y se consumen en orden. Los consumidores utilizan GetRecords clásico o Enhanced Fan-Out (2 MB/s dedicados por consumidor). Una función Lambda adjunta como fuente de eventos se invoca con lotes por shard, preservando el orden. Esta es la elección correcta cuando la lógica descendente no es trivial, cuando múltiples consumidores independientes deben reproducir el historial, o cuando los volúmenes de clickstream son enormes, por ejemplo, un sitio que genera 30 TB/día fluiría a través de KDS hacia Firehose y aterrizaría en S3 para análisis con Athena/Spectrum.

Kinesis Data Firehose es una entrega gestionada de “disparar y olvidar”: almacena en búfer por tamaño o tiempo (por ejemplo, 5 MB / 300 segundos), opcionalmente invoca una Lambda para transformación, opcionalmente convierte JSON a Parquet/ORC usando el esquema de una tabla de Glue, y escribe en S3, Redshift (a través de S3 + COPY), OpenSearch o Splunk. Activar la conversión a Parquet en Firehose es la forma de bajo esfuerzo de hacer que los datos de streaming lleguen en un formato optimizado para consultas sin un trabajo de Glue descendente:

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 no tiene garantía de ordenamiento de extremo a extremo, no puede soportar múltiples consumidores reproducibles y sus destinos son sinks fijos. Elegir Firehose cuando el requisito dice “procesar cada registro en orden” o “múltiples consumidores independientes” es incorrecto en ambos aspectos. De manera similar, esperar que Firehose solo realice transformaciones complejas es una trampa: su único hook de transformación es una Lambda invocada por lote almacenado en búfer. Cualquier cosa que involucre enriquecimiento externo, agregación de múltiples registros o enrutamiento condicional debe residir en esa Lambda o moverse río arriba a Managed Service for Apache Flink.

Amazon MSK es Apache Kafka gestionado. Elígelo cuando ya tengas productores/consumidores de Kafka, necesites características específicas de Kafka (temas compactados, transacciones, Kafka Streams, Connect) o requieras un rendimiento más allá de lo que Kinesis basado en shards ofrece cómodamente.

Usar SQS o EventBridge como ruta de ingesta de análisis es un error: SQS no está ordenado por flujo y carece de reproducción; EventBridge está optimizado para el enrutamiento de eventos, no para la ingesta sostenida de múltiples MB/s.

Búsqueda en Tiempo Real: KDS + Firehose + OpenSearch + QuickSight

El reemplazo canónico para una pila local de Elasticsearch+Logstash es:

Firehose almacena en búfer los registros de streaming y los entrega directamente a un dominio de OpenSearch, manejando reintentos, copias de seguridad en S3 y transformación opcional con Lambda. OpenSearch Dashboards está incrustado y es gratuito con el dominio y es adecuado para operadores que monitorean flujos en tiempo real. QuickSight complementa esto para análisis orientados a negocios: consulta Athena, Redshift, RDS y OpenSearch directamente, y su motor columnar en memoria SPICE almacena en caché conjuntos de datos procesados para un rendimiento de panel en menos de un segundo.

Una división típica: OpenSearch Dashboards para operadores; QuickSight para ejecutivos que consumen conjuntos de datos agregados y curados provenientes del lago de Athena/Glue. A ambos se les debe otorgar acceso de lectura de IAM y, cuando corresponda, Decrypt de KMS en las CMK que protegen el almacenamiento subyacente; de lo contrario, la capa de visualización mostrará paneles vacíos con errores de permisos enterrados en los registros de consultas.

Control de Acceso de QuickSight

QuickSight construye conjuntos de datos (consultas lógicas más campos calculados y seguridad a nivel de fila), luego análisis sobre los conjuntos de datos, y luego publica paneles (vistas compartibles de solo lectura). El control de acceso es por capas y debe aplicarse en la capa correcta. La trampa es otorgar acceso amplio a nivel de panel, compartiendo con un grupo de toda la organización cuando solo un subconjunto debería ver los datos subyacentes.

El privilegio mínimo en QuickSight significa:

• Compartir el conjunto de datos solo con los usuarios/grupos que lo necesiten.
• Aplicar seguridad a nivel de fila a través de un conjunto de datos de permisos que filtra filas por nombre de usuario o grupo.
• Aplicar seguridad a nivel de columna para ocultar campos sensibles.
• Compartir paneles con usuarios, grupos específicos o (para análisis incrustados) espacios de nombres.

Hacer un panel público o compartirlo a nivel de cuenta anula la intención de los controles a nivel de conjunto de datos, porque los espectadores del panel heredan el acceso de lectura a los datos visualizados independientemente de los permisos de la fuente subyacente. Recuerde que la seguridad a nivel de columna de QuickSight solo protege la superficie de QuickSight; cualquiera con acceso directo a Athena o S3 la elude, por lo que los controles sensibles pertenecen a Lake Formation o ETL, no solo a QuickSight.

Los roles de QuickSight —Administrador, Autor, Lector— controlan lo que un usuario puede hacer, distinto de los permisos de compartición que controlan lo que puede ver. Un Lector consume a un costo por sesión más bajo que una licencia de Autor, por lo que las poblaciones de espectadores deben ser Lectores por defecto, y el acceso debe otorgarse a través de la membresía de grupo en lugar de la asignación individual.

Amazon Neptune para cargas de trabajo de grafos

Neptune es una base de datos de grafos gestionada que soporta el modelo de grafo de propiedades (Gremlin, openCypher) y RDF (SPARQL). Está diseñada específicamente para datos altamente conectados —relaciones sociales, redes de fraude, grafos de conocimiento, motores de recomendación— donde las uniones recursivas en una base de datos relacional se vuelven prohibitivas. Una plataforma social con usuarios, seguidores, “me gusta” y publicaciones se mapea naturalmente a vértices y aristas, y Neptune responde a las travesías de múltiples saltos (“amigos de amigos a quienes les gustó X”) en milisegundos.

Neptune Streams expone un registro ordenado basado en el tiempo de cada mutación al grafo. Una función Lambda o una aplicación que sondee el stream puede reaccionar a los cambios —recalcular recomendaciones, actualizar un índice de búsqueda, activar alertas de fraude— sin una pipeline de captura de datos de cambios (CDC) a medida. Reproducir esto en Aurora o DynamoDB requiere una travesía de grafo a nivel de aplicación más una infraestructura de CDC separada. Cuando el planteamiento del problema incluye tanto “analizar relaciones” como “monitorear cambios”, Neptune con Streams es la combinación directa.

SageMaker: ML personalizado de extremo a extremo

SageMaker proporciona el ciclo de vida completo: notebooks de Studio, trabajos de entrenamiento gestionados (con soporte spot), Model Registry, endpoints en tiempo real y sin servidor, transformación por lotes y Pipelines para MLOps. Un flujo típico carga los datos de entrenamiento en S3, lanza un trabajo de entrenamiento especificando un algoritmo incorporado o un contenedor personalizado, y SageMaker aprovisiona instancias efímeras, transmite los logs a CloudWatch y escribe el artefacto del modelo de vuelta a S3. La implementación es una única llamada a la API:

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

No hay Kubernetes, controlador de GPU o servidor de modelos que gestionar. Para los equipos cuyo requisito es “entrenar y exponer un modelo”, SageMaker es casi siempre la respuesta con menos sobrecarga en comparación con la implementación de inferencia en ECS/EC2.

Los SageMaker Savings Plans comprometen un gasto por dólar por hora en componentes elegibles (Studio, entrenamiento, procesamiento, inferencia en tiempo real) durante 1 o 3 años, lo que produce hasta un 64% de descuento sobre los precios bajo demanda. Son flexibles en cuanto a la familia de instancias, el tamaño, la región y el componente, pero no cubren Ground Truth, el almacenamiento o la transferencia de datos. Utilice los Savings Plans cuando el uso base de ML sea predecible; deje el entrenamiento de ráfagas en instancias spot para aumentar los ahorros.

Servicios de IA gestionados frente a ML personalizado

Amazon Rekognition (imágenes/video: detección de objetos y escenas, análisis facial, moderación), Textract (OCR más extracción de formularios y tablas) y Comprehend (PNL: reconocimiento de entidades, sentimiento, detección de PII, clasificación personalizada) exponen modelos preentrenados detrás de APIs simples. DetectEntities de Comprehend devuelve entidades tipificadas, incluida una categoría COMMERCIAL_ITEM, perfecta para extraer nombres de ingredientes de texto de recetas y alimentar una búsqueda en DynamoDB, sin datos de entrenamiento, sin alojamiento y con precios de pago por solicitud:

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

El modo de fallo común es la sobreingeniería: configurar trabajos de entrenamiento de SageMaker, etiquetar datos con Ground Truth y alojar endpoints cuando un servicio gestionado ya cubre el requisito a una fracción del costo operativo. El ML personalizado se justifica solo cuando la precisión en datos específicos del dominio es materialmente mayor, cuando los tipos de entidades necesarios no coinciden con el esquema gestionado (la clasificación/reconocimiento de entidades personalizado de Comprehend sigue siendo más barato que SageMaker sin procesar), o cuando las limitaciones de latencia y residencia de datos exigen un modelo privado.

Almacenamiento y redes HPC: FSx para Lustre y EFA

Las cargas de trabajo de HPC estrechamente acopladas —CFD, dinámica molecular, imágenes sísmicas, entrenamiento a gran escala— tienen dos requisitos no negociables: comunicación entre nodos de latencia extremadamente baja y almacenamiento compartido de alto rendimiento.

Elastic Fabric Adapter (EFA) es una interfaz de red disponible en familias específicas de EC2 (hpc7a, hpc6id, c6in, p4d/p5, otras). Omite la pila TCP/IP del kernel utilizando OS-bypass Libfabric, lo que permite a MPI y NCCL lograr latencias de microsegundos en cientos de nodos. EFA requiere instancias en la misma Zona de Disponibilidad y, para un ancho de banda máximo, en un grupo de ubicación de clúster.

FSx para Lustre es un sistema de archivos paralelo gestionado que ofrece cientos de GB/s de rendimiento y latencia de sub-milisegundos. Se integra de forma nativa con S3: un sistema de archivos FSx se puede vincular a un bucket para que los objetos aparezcan como archivos POSIX, y los resultados escritos en Lustre se pueden exportar de nuevo a S3. Las implementaciones persistentes de SSD son adecuadas para el almacenamiento temporal de larga duración; Scratch2 es más barato para los datos de trabajos efímeros.

El patrón incorrecto es usar EFS para HPC. EFS se basa en NFS, está optimizado para muchos clientes pequeños que realizan E/S de archivos de propósito general; no puede soportar el rendimiento agregado o las IOPS de metadatos que necesita un trabajo MPI de 500 nodos, y su diseño multi-AZ agrega latencia. Usar ENA estándar en lugar de EFA limita MPI a latencias TCP, multiplicando los tiempos de ejecución de allreduce-heavy varias veces. La combinación correcta es instancias habilitadas para EFA en un grupo de ubicación de clúster que montan FSx para Lustre, con S3 como almacenamiento en frío duradero vinculado al sistema de archivos.

← Bases de Datos y Caching · Todos los dominios · Integración de Aplicaciones →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →