Amazon SAA-C03: Analítica, Data Lake, ML y cargas de trabajo especializadas — Guía de estudio

By Laurynas Brazys · 16 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 Glue Data Catalog

El centro de gravedad para la analítica en AWS es el AWS Glue Data Catalog: un metastore compatible con el metastore de Hive que consumen Athena, Redshift Spectrum, EMR y Glue ETL. Toda definición de tabla, partición, tipo de columna y configuración de SerDe reside aquí, y cada motor de procesamiento posterior lee de él. Si dos rutas de ingesta (por ejemplo, un crawler de Glue y una sentencia manual CREATE EXTERNAL TABLE) no concuerdan sobre el esquema del mismo prefijo de S3, las consultas devuelven resultados incorrectos silenciosamente o fallan. El patrón correcto es designar una única autoridad por tabla: o el crawler 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 un ETL por lotes, la conversión a Parquet de Firehose y DDL manuales escriben todos en la misma tabla, la deriva del catálogo (catalog drift) es el asesino silencioso. Imponga un único propietario por tabla, use el Glue Schema Registry para productores de streaming y ejecute los crawlers en modo LOG (no UPDATE_IN_DATABASE) en tablas que son propiedad de trabajos ETL para que expongan la deriva sin sobrescribir los esquemas curados.

AWS Lake Formation se sitúa por encima del Data Catalog y reemplaza el modelo de políticas de bucket de IAM/S3 de grano grueso con una capa de permisos al estilo de base de datos. En lugar de conceder s3:GetObject en un prefijo, usted ejecuta 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 escala a miles de tablas. Una plataforma de retail con PII en una tabla customers puede conceder a los analistas acceso a customer_id, region, signup_date mientras bloquea email y ssn, lo que se aplica en el momento de la 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 blueprints de Lake Formation son plantillas de flujos de trabajo preconstruidas que unen crawlers, trabajos y disparadores (triggers) para ingerir datos desde fuentes JDBC o S3 en un lago curado, reduciendo lo que serían docenas de recursos de Glue conectados 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 datasets, pero solo protege la superficie de QuickSight; cualquiera con acceso directo a Athena o S3 puede eludirla. El control a nivel de columna debe aplicarse en la capa de datos (permisos de Lake Formation, o separando físicamente las 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 y de pago por consulta que lee directamente desde Amazon S3. Sin clúster que aprovisionar, sin paso de ETL requerido antes de consultar y sin costo cuando está inactivo: solo paga por los bytes escaneados (normalmente $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 logs de aplicaciones en JSON, exportaciones en CSV o tablas de hechos en Parquet. Athena necesita un esquema y una disposición de particiones, que residen en el Glue Data Catalog.

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

• Formatos columnares (Parquet, ORC) que permiten a Athena podar columnas y grupos de filas. Una consulta como SELECT sum(amount) FROM orders WHERE region='us-east-1' sobre Parquet lee solo las dos columnas referenciadas; sobre CSV lee cada byte de cada fila.
• Particionamiento en columnas de alta selectividad (p. ej., dt=2024-03-11/) colapsa un escaneo de tabla completa en una lectura dirigida. En logs 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 a Parquet particionado y comprimido con Snappy es casi siempre la primera palanca de costos que se debe accionar. Combinado con el LIMIT pushdown, Athena maneja la mayoría de las necesidades de analítica sobre S3 con cero infraestructura.

Un patrón rentable para una tabla de “lecturas” (readings) 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';

Omitir el crawler es un error común. Sin una entrada en el catálogo, o bien se escribe DDL manual CREATE EXTERNAL TABLE (frágil a medida que los esquemas evolucionan) o se usan trucos de esquema en lectura (schema-on-read) que escanean cada archivo. Peor aún, sin MSCK REPAIR TABLE o proyección de particiones (partition projection), Athena escanea todo el prefijo en cada consulta. Los crawlers de Glue detectan nuevas particiones de forma programada y actualizan el catálogo de forma atómica.

Athena sobre datos de S3 cifrados. Athena soporta SSE-S3, SSE-KMS y CSE-KMS, pero solo si la entidad que realiza la llamada tiene los permisos de KMS correctos y el grupo de trabajo (workgroup) o el cliente está configurado para el modo de cifrado en uso. Para CSE-KMS, el archivo se cifra en el lado del cliente antes de la carga; la entidad principal de IAM que ejecuta la consulta necesita kms:Decrypt y kms:GenerateDataKey sobre la CMK, y la política de la clave debe corresponder. Un modo de fallo común: cargar Parquet con CSE-KMS, conceder al rol de Athena solo permisos de lectura de S3 y luego obtener errores opacos como 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 la operación GetObject y la carga útil (payload) regresa como texto cifrado sin procesar que falla las comprobaciones del número mágico de Parquet.

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

Rastreadores de Glue, trabajos de ETL y marcadores de trabajo (Job Bookmarks)

Los rastreadores (crawlers) de Glue escanean rutas de S3, infieren el esquema (incluyendo claves de partición a partir 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 la necesidad de “dejamos archivos en S3, haz que se puedan consultar”. Programa un rastreador cada hora contra un bucket de aterrizaje (landing bucket) y Athena verá inmediatamente las 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, Python shell o Ray) se encargan de la parte de la transformación. Glue es serverless (sin servidor) —pagas por DPU-hora con un mínimo de un minuto— y el entorno de ejecución escala los workers 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 (job bookmark): Glue persiste el estado sobre qué archivos o particiones ya ha procesado, de modo que las ejecuciones posteriores solo leen datos nuevos. Olvidar 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 de forma lineal y, a menudo, produciendo resultados duplicados. Los marcadores se habilitan por trabajo y deben combinarse con opciones de origen que los admitan (los orígenes de S3 a través del lector Glue DynamicFrame los admiten; las lecturas arbitrarias de Spark no). Los marcadores requieren un argumento transformation_ctx en cada origen y el uso de job.init(...) / job.commit() para delimitar el código:

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 una conversión de formato pura sin lógica, la opción de menor esfuerzo suele ser un rastreador de Glue sobre los datos brutos 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 de EMR personalizados o los convertidores de Lambda añaden una sobrecarga operativa que el modelo serverless de Glue elimina.

Un trabajo diario típico que cura datos de S3 y carga en 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 logs de CloudWatch y los marcadores de trabajo, incluyendo CSE-KMS con una CMK específica. Un trabajo asociado a una configuración de seguridad descifra de forma transparente la entrada CSE-KMS y cifra las salidas de la misma manera, siempre que el rol de IAM del trabajo tenga permisos de KMS sobre las claves referenciadas.

Para un 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 alcance limitado a esa CMK. Ejecutar a todos los clientes a través de un único 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 destino directo de trabajos o notebooks de Glue exploratorios. Exporta una instantánea a un prefijo de S3 de “analítica” y apunta 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 desdibuja el límite de auditoría entre los datos operativos y los derivados analíticos.

AWS Glue DataBrew

DataBrew es la contraparte de bajo código de Glue para usuarios que no pueden o no deben escribir código Spark. Ofrece una interfaz de usuario estilo hoja de cálculo con más de 250 transformaciones predefinidas (imputación, enmascaramiento de PII, agrupación de valores atípicos, análisis de fechas). Sus diferenciadores son las recetas compartidas (artefactos JSON versionados que puedes publicar y reutilizar 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. Elige DataBrew cuando los analistas son los dueños de la lógica de transformación; elige Glue Studio/scripts cuando los ingenieros son los dueños y el pipeline necesita código personalizado, streaming o joins complejos.

Amazon EMR: Lotes distribuidos y roles de tiempo de ejecución

Amazon EMR es una plataforma de clústeres gestionada que ejecuta Spark, Hadoop, Hive, Presto, HBase y Flink. Su caso de uso ideal son las cargas de trabajo por lotes (batch) o interactivas, grandes y paralelizables, 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 (se inician, ejecutan y terminan) o de larga duración, y puede mezclar instancias bajo demanda (On-Demand), Spot y reservadas mediante flotas de instancias (instance fleets).

Un patrón canónico: un trabajo de Spark lee Parquet desde S3, extrae tablas de dimensiones de Redshift mediante UNLOAD a S3, las une a través de los 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 es la mejor opción aquí porque Spark distribuye el join entre docenas de nodos y el almacenamiento intermedio (staging) a través de S3 evita un cuello de botella JDBC de un solo hilo. La trampa es recurrir reflexivamente a EMR cada vez que se necesita consultar datos en S3. Para SQL ad-hoc sobre 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 logs, aplicación de parches. EMR solo vale la pena 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 en un clúster heredaban el perfil de instancia de EC2 (un rol asociado 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 solucionan esto: cuando un usuario envía un paso, pasa el argumento --execution-role-arn, y EMR asume ese rol durante la duración del paso. El equipo A puede estar restringido a s3://team-a/*, y el equipo B a s3://team-b/*. El perfil de instancia se convierte en un rol de bootstrap ligero que solo obtiene los artefactos del clúster.

Los roles de tiempo de ejecución son también 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 alcanzar el servicio de metadatos de la instancia —incluido IMDSv2— porque la plataforma intercepta esas llamadas. Esto cierra la ruta de escalada por la que 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 los roles de tiempo de ejecución y el bloqueo de IMDS. Sin ella, asumir que las cargas de trabajo de EMR “utilizan automáticamente roles de privilegio mínimo” es incorrecto; por defecto, comparten el perfil de instancia y el IMDS es accesible desde el código de usuario.

Amazon Redshift y Redshift ML

Redshift es un data warehouse columnar de procesamiento masivo en paralelo (MPP) para cargas de trabajo de analítica sostenidas que requieren paneles de control con respuesta por debajo del segundo, joins complejos sobre 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 de dimensionamiento de clústeres.

Redshift participa en canalizaciones (pipelines) de analítica en dos modos de enriquecimiento:

• Como origen: Spark en EMR extrae dimensiones mediante UNLOAD a S3, o Glue lee a través de la API de datos de Redshift.
• Como destino: Firehose o un trabajo de Glue introduce datos enriquecidos con COPY.

Redshift Spectrum amplía esto permitiendo que el SQL de Redshift 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 lake-house funcione. Ideal cuando ya tienes un clúster de Redshift y quieres unir hechos almacenados en el warehouse con el historial frío en S3 sin mover los datos.

Las cargas por lotes (batch) usan COPY desde S3, paralelizadas entre los nodos de cómputo; los archivos deben dividirse en trozos de tamaño aproximadamente igual (un múltiplo del número de slices) para lograr 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 en streaming generalmente fluye a través de Firehose (COPY en búfer) para una entrega sin operaciones (zero-ops).

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;

Bajo el capó, Redshift exporta el conjunto de entrenamiento a S3, invoca a SageMaker Autopilot (o un algoritmo específico como XGBoost) e importa el modelo compilado para la inferencia dentro de la base de datos. Es potente cuando los analistas ya viven en SQL, pero no es un reemplazo para una plataforma de ML completa: el movimiento de datos a S3 y el cómputo de entrenamiento de SageMaker se facturan por separado, los conjuntos de entrenamiento grandes pueden generar cargos significativos de egreso y de tiempo de ejecución de Autopilot, y no hay un flujo de trabajo integrado para feature stores, seguimiento de experimentos o despliegue A/B. Considera a Redshift ML como una inferencia democratizada sobre los datos de Redshift, no como un entrenamiento de propósito general.

Cómo elegir entre Athena y Redshift

Ingesta en streaming: Kinesis Data Streams, Firehose y MSK

Los tres servicios de streaming de AWS resuelven problemas que se solapan con garantías materialmente diferentes:

Kinesis Data Streams usa 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 usan el clásico GetRecords o Enhanced Fan-Out (2 MB/s dedicados por consumidor). Una función Lambda adjunta como origen de eventos es invocada con lotes por shard, preservando el orden. Esta es la elección correcta cuando la lógica descendente (downstream) 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 su análisis con Athena/Spectrum.

Kinesis Data Firehose es una entrega gestionada de tipo fire-and-forget: almacena en búfer por tamaño o tiempo (p. ej., 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 (vía S3 + COPY), OpenSearch o Splunk. Activar la conversión a Parquet en Firehose es la forma de bajo esfuerzo para depositar datos de streaming 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 con capacidad de reproducción (replayable), 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 casos. Del mismo modo, esperar que Firehose por sí solo realice transformaciones complejas es una trampa — su único hook de transformación es una Lambda invocada por cada lote en búfer. Cualquier cosa que implique enriquecimiento externo, agregación de múltiples registros o enrutamiento condicional debe vivir en esa Lambda o moverse aguas arriba (upstream) 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 (topics compactados, transacciones, Kafka Streams, Connect), o requieras un rendimiento que vaya más allá de lo que Kinesis basado en shards puede ofrecer cómodamente.

Usar SQS o EventBridge como una ruta de ingesta para analítica es un error: SQS no está ordenado por flujo y carece de capacidad de reproducción (replay); 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 (on-premises) de Elasticsearch+Logstash es:

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

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

Control de acceso en QuickSight

QuickSight crea conjuntos de datos (consultas lógicas más campos calculados y seguridad a nivel de fila), luego análisis sobre esos conjuntos de datos, y finalmente publica paneles de control (vistas de solo lectura que se pueden compartir). El control de acceso se organiza en capas y debe aplicarse en la capa correcta. La trampa es conceder un acceso amplio a nivel del panel de control, compartiéndolo con un grupo de toda la organización cuando solo un subconjunto debería ver los datos subyacentes.

El principio de 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 mediante un conjunto de datos de permisos que filtra las filas por nombre de usuario o grupo.
• Aplicar seguridad a nivel de columna para ocultar campos sensibles.
• Compartir los paneles de control con usuarios, grupos o (para análisis integrados) espacios de nombres (namespaces) específicos.

Hacer público un panel de control o compartirlo con toda la cuenta anula el propósito de los controles a nivel de conjunto de datos, porque quienes ven el 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 puede eludirla, por lo que los controles sensibles deben estar en Lake Formation o en el ETL, no solo en QuickSight.

Los roles de QuickSight —Admin, Author, Reader— controlan lo que un usuario puede hacer, a diferencia de los permisos para compartir, que controlan lo que puede ver. Un Reader consume a un costo por sesión más bajo que una licencia de Author, por lo que las poblaciones de espectadores deberían ser Readers por defecto, y el acceso debería concederse a través de la pertenencia a grupos en lugar de asignaciones individuales.

Amazon Neptune para cargas de trabajo de grafos

Neptune es una base de datos de grafos gestionada que soporta el modelo de grafos 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 los joins recursivos en una base de datos relacional se vuelven prohibitivos. Una plataforma social con usuarios, seguidores, “me gusta” y publicaciones se mapea de forma natural a vértices y aristas, y Neptune responde a recorridos de múltiples saltos (“amigos de amigos a los que les gustó X”) en milisegundos.

Neptune Streams expone un registro ordenado y cronológico de cada mutación en el grafo. Una función Lambda o una aplicación que sondea el stream puede reaccionar a los cambios —recalcular recomendaciones, actualizar un índice de búsqueda, activar alertas de fraude— sin necesidad de un pipeline de captura de datos de cambio (CDC) a medida. Reproducir esto en Aurora o DynamoDB requiere un recorrido del grafo a nivel de aplicación más una infraestructura de CDC separada. Cuando el enunciado del problema incluye tanto “analizar relaciones” como “monitorear cambios”, Neptune con Streams es la solució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 para instancias spot), Model Registry, endpoints en tiempo real y sin servidor, transformación por lotes (batch transform) y Pipelines para MLOps. Un flujo típico consiste en cargar los datos de entrenamiento a S3, lanzar un trabajo de entrenamiento especificando un algoritmo integrado o un contenedor personalizado, y SageMaker aprovisiona instancias efímeras, transmite los registros a CloudWatch y escribe el artefacto del modelo de vuelta en S3. El despliegue 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 que gestionar Kubernetes, ni drivers de GPU, ni un servidor de modelos. Para los equipos cuyo requisito es “entrenar y exponer un modelo”, SageMaker es casi siempre la respuesta con la menor sobrecarga administrativa en comparación con implementar la inferencia por cuenta propia en ECS/EC2.

SageMaker Savings Plans comprometen a un gasto en dólares 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 el precio bajo demanda. Son flexibles entre familias de instancias, tamaños, regiones y componentes, pero no cubren Ground Truth, el almacenamiento ni la transferencia de datos. Use Savings Plans cuando el uso base de ML sea predecible; deje el entrenamiento en ráfagas (burst) para las instancias spot para acumular ahorros.

Servicios de IA administrados versus 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 (NLP: reconocimiento de entidades, análisis de sentimiento, detección de PII, clasificación personalizada) exponen modelos preentrenados a través de API sencillas. El comando DetectEntities de Comprehend devuelve entidades tipificadas que incluyen una categoría COMMERCIAL_ITEM, perfecta para extraer nombres de ingredientes del texto de una receta y alimentar una búsqueda en DynamoDB, sin datos de entrenamiento, sin alojamiento y con un precio 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: levantar trabajos de entrenamiento en SageMaker, etiquetar datos con Ground Truth y alojar endpoints cuando un servicio administrado ya cubre el requisito a una fracción del costo operativo. El ML personalizado solo se justifica cuando la precisión con datos específicos del dominio es materialmente mayor, cuando los tipos de entidad necesarios no coinciden con el esquema administrado (Comprehend Custom Classification/Entity Recognition sigue siendo más barato que SageMaker puro) o cuando las restricciones de latencia y residencia de datos exigen un modelo privado.

Almacenamiento y redes para HPC: FSx for Lustre y EFA

Las cargas de trabajo de HPC fuertemente 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, entre otras). Omite la pila TCP/IP del kernel mediante OS-bypass con Libfabric, lo que permite a MPI y NCCL alcanzar latencias de microsegundos en cientos de nodos. EFA requiere que las instancias estén en la misma Zona de Disponibilidad y, para obtener el máximo ancho de banda, en un grupo de ubicación de clúster (cluster placement group).

FSx for Lustre es un sistema de archivos paralelo administrado que ofrece un rendimiento de cientos de GB/s y una latencia inferior al milisegundo. Se integra de forma nativa con S3: un sistema de archivos FSx puede vincularse a un bucket para que los objetos aparezcan como archivos POSIX, y los resultados escritos en Lustre pueden exportarse de nuevo a S3. Los despliegues de SSD persistente son adecuados para datos scratch de larga duración; Scratch2 es más económico para los datos efímeros de los trabajos.

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

← Bases de datos y almacenamiento en caché · Todos los dominios · Integración de aplicaciones →

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

Explorar Amazon →