Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen DEA-C01. Lee de arriba a abajo o salta a una sección.
Elija un servicio de Kinesis para la ingesta de streaming.
Procesamiento controlado por el consumidor en subsegundos → Kinesis Data Streams. Entrega totalmente administrada a S3/Redshift/OpenSearch con conversión de formato opcional → Kinesis Data Firehose.
Por qué: KDS retiene registros (24h-365d) y admite múltiples consumidores. Firehose no tiene repetición; sacrifica la repetición por una entrega sin operaciones.
El stream alcanza errores de ProvisionedThroughputExceeded durante el pico.
Refragmentar. Cada shard admite 1 MB/s o 1,000 registros/s de ingesta, 2 MB/s de salida. Use claves de partición uniformes; habilite Enhanced Fan-Out para >2 MB/s por consumidor.
Por qué: Las claves de partición "calientes" concentran el tráfico en un solo shard. Las claves aleatorias o basadas en hash distribuyen la carga.
La carga de trabajo de streaming es irregular e impredecible; la refragmentación manual es un problema operativo.
Kinesis Data Streams en modo de capacidad bajo demanda. Se autoescala a 200 MB/s por defecto; se paga por volumen de datos.
Múltiples consumidores que leen el mismo stream alcanzan el límite de lectura de 2 MB/s/shard.
Enhanced Fan-Out. Cada consumidor obtiene 2 MB/s/shard dedicados a través de HTTP/2 SubscribeToShard basado en push.
Maximizar el rendimiento de la ingesta desde la aplicación del lado del productor.
Kinesis Producer Library (KPL) con agregación + colección. Agrupa múltiples registros de usuario en un solo registro de Kinesis de hasta 1 MB; reduce el costo de PUT.
Por qué: PutRecord de un solo registro tiene límite de velocidad y es costoso a 50k eventos/s. KPL agrega en el lado del cliente.
Almacenar clickstream JSON en S3 como Parquet, particionado por tiempo de evento.
Firehose con conversión de formato de registro (JSON → Parquet) usando una tabla de Glue Data Catalog + particionamiento dinámico por timestamp de evento.
Por qué: Parquet + particionamiento reduce drásticamente el costo de escaneo de Athena. El particionamiento dinámico evita un paso ETL separado.
Algunos registros fallan en la transformación o entrega de Firehose; es necesario capturarlos para su repetición.
Configure el backup de S3 con `AllData` o `FailedDataOnly`. Los registros fallidos se almacenan en el prefijo configurado con metadatos de error.
Asegurar que no haya pérdida de datos en MSK si falla una AZ de broker.
Factor de replicación ≥ 3 en 3 AZs y `min.insync.replicas=2` con `acks=all` del productor. Habilite Multi-AZ a través de KRaft sin ZooKeeper o mediante la colocación de brokers en 3 AZs.
Transmitir desde MSK a S3, OpenSearch o RDS sin administrar un clúster de Kafka Connect.
MSK Connect con conector administrado (Confluent S3 Sink, Debezium para CDC). Autoescala los workers por WCU.
El tema almacena la última versión de un registro por clave; las versiones antiguas pueden descartarse.
Configure el tema `cleanup.policy=compact`. Kafka retiene el valor más reciente para cada clave; los registros más antiguos con la misma clave son elegibles para la compactación.
Transferencia semanal recurrente de 10 TB desde NFS on-prem a S3 a través de Direct Connect.
AWS DataSync con agente on-prem + tarea programada. Verifica la integridad de los datos, admite transferencias incrementales, en paralelo.
Por qué: DataSync es más rápido que aws-cli sync y maneja la limitación de ancho de banda, los reintentos y la verificación de forma nativa.
Extraer datos de APIs SaaS (Salesforce, ServiceNow, Zendesk) a S3 según un cronograma.
AWS AppFlow. Conectores administrados, OAuth gestionado, programado o activado por eventos, escribe Parquet en S3.
Replicar cambios continuos de SQL Server on-prem a Aurora MySQL con tiempo de inactividad mínimo.
AWS DMS con tarea de carga completa + CDC. Utilice Schema Conversion Tool (SCT) para la conversión de esquemas/código heterogéneos antes de DMS.
La instancia de replicación de DMS falla - la replicación se interrumpe.
Habilite Multi-AZ en la instancia de replicación. Standby síncrono en otra AZ; failover automático.
Se necesita análisis casi en tiempo real de datos OLTP de Aurora sin pipeline ETL.
Integración Aurora zero-ETL con Redshift. Replicación continua de datos de Aurora a Redshift; las consultas ven los nuevos datos en segundos.
Por qué: Elimina los pipelines DMS / Glue / CDC personalizados para el caso de uso de OLTP a data warehouse.
Mover 100 TB de archivo histórico desde on-prem a S3; ancho de banda limitado.
AWS Snowball Edge Storage Optimized. Dispositivo físico enviado al sitio; copie los datos; envíelo de vuelta.
El JSON de origen tiene arrays anidados; el análisis relacional posterior necesita filas aplanadas.
Transformación `Relationalize` de Glue PySpark (o `explode()` en DataFrame) aplana arrays anidados en filas/tablas separadas.
Glue Crawler infiere tipos ambiguos (`choice<int,string>`) de datos CSV desordenados.
Aplique la transformación `ResolveChoice` - convierta a un tipo específico o proyecte a una estructura. O corrija en el origen aplicando un esquema.
El trabajo ETL de Glue se ejecuta cada hora en datos de S3 en crecimiento; es necesario procesar solo archivos nuevos.
Habilite los marcadores de trabajo de Glue. Glue rastrea los archivos/particiones procesados y los omite en las nuevas ejecuciones.
Por qué: Evita el reprocesamiento de todo el conjunto de datos. Requerido para pipelines ETL incrementales.
El trabajo Spark de Glue falla con OutOfMemoryError en el controlador durante grandes agregaciones.
Cambie a workers G.2X o G.4X (más memoria de controlador) o habilite los predicados push-down `--enable-glue-datacatalog` para reducir los datos barajados.
Ejecute Spark Structured Streaming continuo contra una fuente de Kinesis con infraestructura administrada.
Trabajo ETL de streaming de AWS Glue. Spark Structured Streaming internamente; checkpointing a S3.
Un analista de negocios necesita limpiar y transformar datos sin escribir código.
AWS Glue DataBrew. Transformaciones visuales basadas en recetas (más de 250), perfilado, linaje. Salida a S3, Redshift, RDS.
Ejecutar el trabajo ETL de Glue solo después de que Crawler actualice con éxito el Data Catalog.
Flujo de trabajo de Glue con triggers condicionales. Éxito de Crawler → activar trabajo ETL. Falla → omitir / alarma.
Crawler infiere todas las columnas CSV como `string` - necesita tipos de fecha y número.
Agregue un clasificador de Glue personalizado (patrón Grok o sugerencia de columna) antes del crawling. Alternativamente, escriba previamente una fila de encabezado con tipos explícitos.
Múltiples productores/consumidores en Kafka necesitan evolución de esquemas sin romperse entre sí.
AWS Glue Schema Registry con reglas de compatibilidad (BACKWARD/FORWARD/FULL). Los productores registran el esquema; los consumidores lo obtienen + validan.
Elija entre EMR y Glue para Spark ETL.
Spark personalizado de larga duración con ajuste profundo, múltiples frameworks (Hive, Presto, Flink) → EMR. ETL serverless de pago por trabajo con integración de Glue Data Catalog → Glue. Spark irregular/impredecible → EMR Serverless.
Trabajos intermitentes de Spark/Hive; se desean cero operaciones de clúster y ningún cómputo inactivo.
EMR Serverless. Pools de capacidad preinicializados para inicios de baja latencia; escala por trabajo; paga por hora de vCPU.
Mezclar nodos de tarea spot y core bajo demanda para EMR optimizado en costos.
Instance Fleets con capacidad objetivo por tipo. Flota de core bajo demanda para estabilidad de HDFS; flota de tarea spot con tipos de instancia diversificados.
Estandarizar en Kubernetes; se desea que los trabajos de EMR Spark compartan el clúster con otras cargas de trabajo.
EMR on EKS. Spark se ejecuta como pods en el clúster EKS existente; comparte infraestructura y roles de IAM a través de IRSA.
Streaming con estado con agregaciones por ventana y semántica exactamente una vez.
Kinesis Data Analytics for Apache Flink. Tiempo de ejecución de Flink administrado; checkpoints a S3; autoescala.
Transformación ligera por registro en un stream de Kinesis (<1 ms cada uno).
Lambda con Event Source Mapping en KDS. Ajuste `BatchSize`, `MaximumBatchingWindowInSeconds` y `ParallelizationFactor`.
Por qué: Lambda es más barato que KCL/Glue Streaming para trabajos pequeños por registro.
Un paso de Step Functions falla ocasionalmente por limitación transitoria; reintentar y luego alertar.
Agregue un bloque `Retry` con `ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2`. Además, `Catch` a un estado de notificación.
Procesar 500,000 archivos JSON en paralelo a través de la transformación Lambda.
Estado de Map distribuido de Step Functions con `MaxConcurrency` y ItemReader desde S3. Distribución en miles de invocaciones paralelas de Lambda.
DAG complejo con dependencias entre servicios (Glue + Redshift COPY + Lambda + correo electrónico) y requisitos de linaje.
Amazon MWAA (Managed Workflows for Apache Airflow). Operadores nativos de Airflow para servicios de AWS; sincronización de DAGs impulsada por Git.
Necesidad de revertir cambios en DAGs si un despliegue causa fallos.
Almacene los DAGs en un bucket S3 versionado + sincronice a través del versionamiento de S3. O mantenga el repositorio de DAGs en Git con un entorno por rama + sincronización con S3 a través de CI.
Datos crudos "calientes" durante 30 días, acceso ocasional durante los siguientes 90 días, archivo durante 7 años.
Ciclo de vida de S3: 0-30 días Standard, transición a los 30 días a Standard-IA, transición a los 120 días a Glacier Flexible Retrieval, expira después de 7 años.
Patrones de acceso impredecibles; la política de ciclo de vida manual es una elección incorrecta.
S3 Intelligent-Tiering. Mueve objetos automáticamente entre Frequent / Infrequent / Archive Instant Access / Archive / Deep Archive basándose en el patrón de acceso. Tarifa de monitoreo por objeto; sin tarifas de recuperación en Frequent/IA.
Las consultas de Athena en el data lake son lentas; la partición tiene miles de archivos JSON de 1-5 KB.
Compacte archivos pequeños a través de un trabajo de Glue/EMR en archivos Parquet de ~256 MB. Utilice Iceberg `OPTIMIZE` o la compactación de Hudi para formatos de tabla administrados.
Por qué: El overhead por archivo de Athena/Spark domina con archivos pequeños. El punto óptimo es ~128-512 MB de Parquet.
Un bucket; múltiples equipos necesitan diferentes patrones de acceso con ámbito de prefijo.
S3 Access Points - endpoint nombrado por equipo con su propia política vinculada a un prefijo. Más simple que una política de bucket gigante.
Diferentes consumidores necesitan diferentes vistas del mismo objeto S3 (PII redactado, resumido).
S3 Object Lambda Access Point. Una solicitud GET invoca una Lambda que transforma el objeto sobre la marcha; el consumidor ve la vista transformada.
Se necesitan transacciones ACID, evolución de esquemas y "time-travel" en el data lake de S3.
Tablas Apache Iceberg (Glue Catalog + almacenamiento S3). Commits atómicos, MERGE/UPDATE/DELETE, aislamiento de snapshot, evolución de particiones.
Por qué: S3 de solo anexar estilo Hive no admite actualizaciones a nivel de fila. Iceberg/Hudi/Delta resuelven esto.
Múltiples escritores y lectores en una tabla de data lake; se necesita consistencia transaccional y control de acceso a nivel de fila.
Tablas gobernadas por Lake Formation (respaldadas por Iceberg) con LF-Tags para permisos.
Athena, Redshift Spectrum, EMR y Glue ETL necesitan un almacén de metadatos compartido.
AWS Glue Data Catalog. Un único metastore compatible con Hive consumido por cada servicio de análisis.
El clúster de Redshift necesita escalar el almacenamiento independientemente del cómputo.
Nodos RA3 con almacenamiento administrado (RMS). Almacenamiento respaldado por S3; el cómputo escala por separado. Requerido para AQUA, Concurrency Scaling, Federated Queries.
La consulta de Redshift filtra frecuentemente por `created_at`; los escaneos de tabla completa son lentos.
Defina una clave de clasificación en `created_at` (o una clave de clasificación compuesta que incluya `created_at`). Redshift utiliza mapas de zona para omitir bloques durante el escaneo.
Joins frecuentes entre `orders` y `order_items`; los shuffles de consulta causan lentitud.
Utilice la misma DISTKEY (`order_id`) en ambas tablas. Las filas co-ubicadas evitan el shuffle de red durante el join.
Por qué: La distribución KEY co-ubica las filas de unión en el mismo nodo de cómputo.
La carga de 32 archivos CSV gzip (~1 GB cada uno) en un clúster de Redshift de 4 nodos es lenta.
COPY en paralelo desde un único manifiesto. Apunte a #archivos = múltiplo del número de slices (slices = nodos × vCPU). 4 nodos ra3.xlplus = 8 slices → 32 archivos = 4 por slice.
Unir 5 TB de datos Parquet "fríos" en S3 con tablas de hechos "calientes" de Redshift; no se desea cargarlos.
Redshift Spectrum. Tablas externas en Glue Catalog; las consultas leen S3 directamente con el cómputo de Redshift.
Las consultas del equipo de informes durante el pico ralentizan las cargas de trabajo ETL; ambas se ejecutan en el mismo clúster.
Habilite Concurrency Scaling en la cola WLM relevante. Redshift enruta transparentemente las consultas de desbordamiento a clústeres escalados horizontalmente.
Una consulta de panel une repetidamente 3 tablas grandes y agrega; la latencia es alta.
Vista materializada con auto-actualización. Redshift mantiene el resultado precalculado; la consulta lee de los datos materializados.
Carga de trabajo analítica intermitente; el clúster aprovisionado permanece inactivo.
Amazon Redshift Serverless. Auto-aprovisiona y escala RPUs por carga de trabajo; se paga por hora de RPU. Cero operaciones.
Se necesita unir datos de Redshift con datos en vivo de Aurora MySQL sin ETL.
Redshift Federated Queries. CREATE EXTERNAL SCHEMA apuntando a Aurora; las consultas envían predicados sobre la conexión RDS en vivo.
El panel une pedidos + clientes + productos en cada renderizado; el esquema estrella es demasiado lento.
Desnormalice en una tabla de hechos ancha o vista materializada. Las cargas de trabajo de BI favorecen las uniones en tiempo de lectura resueltas en tiempo de escritura.
S3 particiona por `año/mes/día/hora`; `MSCK REPAIR TABLE` toma más de 30 minutos.
Habilite la proyección de particiones de Athena (sin entradas de partición de Glue Catalog). Defina los tipos de claves de partición + rangos en las propiedades de la tabla.
Por qué: Athena calcula las ubicaciones de las particiones en tiempo de consulta a partir de las reglas de proyección - sin MSCK, sin limitación de la API de Glue.
Convierta los resultados de la consulta de Athena a Parquet, particionados, en una sola operación.
CREATE TABLE AS SELECT (CTAS) con `format=PARQUET`, `partitioned_by=ARRAY['region']`, `external_location` configurado en el prefijo S3 de destino.
La misma plantilla de consulta se ejecuta con diferentes valores de parámetros a lo largo del día.
Sentencias preparadas de Athena: `PREPARE`, `EXECUTE` con valores de parámetros. Evita el re-análisis y proporciona una parametrización limpia.
Lecturas de dispositivos IoT; se necesitan (1) todas las lecturas para un dispositivo en una ventana de tiempo, (2) la última lectura por dispositivo.
PK = `device_id`, SK = `timestamp`. GSI con PK = `device_id`, SK = `timestamp` invertido (o use Query con `ScanIndexForward=false LIMIT 1`).
La tabla de sesiones crece sin límites; las sesiones antiguas pueden eliminarse después de 7 días.
Habilite DynamoDB TTL en un atributo de época `expires_at`. DynamoDB elimina elementos caducados sin costo (dentro de ~48h).
Datos de sensores IoT: consultas "calientes" en los últimos 7 días, consultas ocasionales en 2 años.
Amazon Timestream. Almacén en memoria para datos recientes (consultas rápidas); auto-tiering a almacén magnético para históricos.
Almacén compatible con Cassandra para series de tiempo de alta escritura con retención de 90 días.
Amazon Keyspaces con TTL en filas. Compatible con Cassandra CQL; capacidad serverless, sin gestión de clústeres.
El costo de almacenamiento de OpenSearch crece; los índices antiguos rara vez se consultan.
Las políticas ISM de OpenSearch organizan los datos por niveles: hot → UltraWarm (respaldado por S3) → Cold. El nivel Cold está separado pero es searchable bajo demanda.
Valide que la salida de ETL tenga ≥1,000 filas y una tasa de nulos de columna <2% antes del consumo posterior.
Reglas de AWS Glue Data Quality (DQDL): `RowCount >= 1000`, `Completeness "col" > 0.98`. El pipeline se detiene si la regla falla.
Framework de calidad de datos personalizado basado en Spark en EMR; se necesitan comprobaciones estadísticas a nivel de columna.
Librería AWS Deequ en Spark. Defina restricciones (`isComplete`, `hasMin`, `isContainedIn`); Deequ se ejecuta como un trabajo Spark y emite métricas.
Los analistas necesitan descubrir, solicitar acceso y comprender el linaje de los productos de datos entre cuentas.
Amazon DataZone. Catálogo de datos con glosario de negocio, flujos de trabajo de acceso, linaje; abarca Lake Formation, Redshift, RDS.
Lambda emite métricas de procesamiento por registro; los costos de CloudWatch PutMetricData son altos.
CloudWatch Embedded Metric Format (EMF). Registre JSON en el esquema EMF; CloudWatch extrae métricas de los logs sin costo por PutMetricData.
Encuentre todos los trabajos de Glue cuya duración superó 1 hora en los últimos 7 días.
Consulta de CloudWatch Logs Insights: `fields @timestamp, @message | filter @message like /JobRunDuration/ | parse @message "duration=*" as d | filter d > 3600`.
El trabajo de Glue es lento; se necesita saber si tiene pocos recursos o un shuffle sesgado.
Habilite las métricas + observabilidad de los trabajos de Glue. CloudWatch muestra el uso máximo de DPU, la utilización del ejecutor, la lectura/escritura del shuffle por etapa.
Los tamaños de los trabajos Spark de Glue varían 10 veces entre ejecuciones; sobreaprovisionado para entradas pequeñas.
Habilite el autoescalado de Glue (Glue 3.0+). Los workers se añaden/eliminan durante la ejecución según el paralelismo de la etapa.
Athena escanea 5 TB para responder consultas que tocan un día de datos; el costo es demasiado alto.
Particione por fecha y asegúrese de que la cláusula WHERE use claves de partición. Valide con `EXPLAIN` mostrando la poda de particiones.
Las consultas de Athena en el data lake JSON son lentas y costosas.
Convierta a Parquet (columnar) o ORC. Lee solo las columnas necesarias; la compresión nativa reduce tanto el costo como el tiempo de escaneo.
Optimización de costos del clúster EMR sin riesgo de pérdida de datos.
Nodos core en On-Demand (alojan HDFS / shuffle). Nodos de tarea en Spot a través de Instance Fleets con tipos de instancia diversificados.
El clúster de Redshift funciona 24/7; el precio bajo demanda es caro.
Nodos reservados de Redshift (1 año o 3 años, pago inicial total/parcial/sin pago). Hasta ~75% de descuento frente a bajo demanda para cargas de trabajo de estado estable.
Elija entre Athena, Redshift y EMR para 500 GB diarios / 50 consultas.
Ad-hoc, infrecuente → Athena (por TB escaneado). Paneles de BI predecibles → Redshift (RA3 + Reservado). Spark personalizado intensivo → EMR.
Por qué: Athena factura por datos escaneados; Redshift factura por hora de clúster; EMR por hora de instancia. Empareje la facturación con el patrón de acceso.
Un trabajo de Glue se activa múltiples veces concurrentemente; se desea limitar a una ejecución a la vez.
Establezca `MaxConcurrentRuns=1` en el trabajo de Glue. Los triggers subsiguientes esperan; elimina la corrupción del estado concurrente.
Los reintentos de Glue ETL producen filas de salida duplicadas en el destino S3.
Idempotencia: escriba a un prefijo temporal por ejecución, luego renombre atómicamente a través de S3 multipart `CompleteMultipartUpload` o use Iceberg/Hudi MERGE para upserts.
Una mala ejecución de ETL escribió filas corruptas en Aurora MySQL; recuperar a un punto en el tiempo minutos atrás.
Aurora Backtrack (solo compatible con MySQL). Retrocede el clúster a un tiempo objetivo sin restaurar desde un snapshot.
El pipeline sobrescribió objetos S3 correctos con datos corruptos.
Versionamiento de bucket S3 + restaurar versión anterior. Combine con MFA Delete para prevenir la expiración accidental de versiones.
Automatizar la creación, retención y copia entre regiones de snapshots de EBS para recuperación ante desastres.
Amazon Data Lifecycle Manager (DLM) con política por etiqueta: programación, retención, copia entre regiones.
Los consumidores de MSK se quedan atrás de los productores; es necesario detectarlo y alertar.
Métrica de CloudWatch `MaxOffsetLag` por grupo de consumidores. Alarma cuando > umbral; escale el número de consumidores o aumente el paralelismo de particiones.
El consumidor de Kinesis se está quedando atrás; se desea detectarlo.
Métrica de CloudWatch `GetRecords.IteratorAgeMilliseconds`. Una alarma > 60s suele significar que los consumidores tienen pocos recursos.
Identificar las consultas de Redshift más lentas de la última hora para optimizarlas.
Consulte `SVL_QLOG` / `STL_QUERY` / `SYS_QUERY_HISTORY` para las entradas de mayor tiempo transcurrido; use `SVL_QUERY_REPORT` para un desglose paso a paso.
Los equipos de ventas solo deben ver las filas de sus regiones asignadas en el data lake compartido.
Seguridad a nivel de fila de Lake Formation a través de filtro de datos: `region IN ('NA', 'EU')` por principal de IAM. Tabla única; vista filtrada por principal.
Tabla de atención médica - los analistas no deben ver las columnas de SSN y diagnóstico.
Permisos a nivel de columna de Lake Formation: GRANT SELECT en la tabla EXCEPTO (`ssn`, `diagnosis_code`).
Muchos equipos + muchas tablas; las concesiones por tabla son inmanejables.
LF-Tags de Lake Formation. Etiquete tablas/columnas; otorgue permisos basados en etiquetas a los principales. Agregar una nueva tabla solo necesita la etiqueta correcta.
La Cuenta A tiene el data lake; los analistas de la Cuenta B necesitan acceso de lectura a tablas específicas.
Compartir entre cuentas de Lake Formation a través de RAM. La Cuenta A otorga permisos al principal/cuenta de IAM de B; B accede a través de Athena/Redshift Spectrum.
Seguridad a nivel de fila dentro de Redshift (no Lake Formation).
Políticas RLS nativas de Redshift: `CREATE RLS POLICY` con predicado que hace referencia al contexto de la sesión (`current_user`, `session_role`). Adjunte la política a la tabla.
El cumplimiento requiere una clave administrada por el cliente con pista de auditoría para el cifrado de Redshift.
Clúster de Redshift cifrado con clave KMS administrada por el cliente. Rotación de claves habilitada; CloudTrail captura cada operación de Decrypt contra la CMK.
Cifrar las entradas/salidas de los trabajos ETL de Glue con una clave administrada por la empresa.
Configuración de seguridad de Glue con CMK para S3 + CloudWatch Logs + marcadores de trabajo. Rol de Glue con permisos `kms:Decrypt`/`Encrypt` en la clave.
Descubrir y clasificar PII (nombres, SSN, correos electrónicos) que residen en el data lake de S3.
Amazon Macie. Descubrimiento de datos sensibles en S3 basado en ML; produce hallazgos con la ubicación del objeto y el tipo de PII.
Auditar cada GetObject / PutObject de S3 en el bucket del data lake.
Eventos de datos de CloudTrail para el bucket. CloudTrail por defecto solo registra eventos de administración; los eventos de datos deben habilitarse explícitamente.
Por qué: Los eventos de datos se facturan por evento; limite el alcance al bucket sensible solo para controlar los costos.
Se necesita saber quién/cuándo/IP para cada acceso a S3; los eventos de datos de CloudTrail son demasiado caros.
Registro de acceso al servidor S3. Gratuito; los logs se entregan a un bucket de logging separado; menos detalle que CloudTrail pero cubre el solicitante + IP + ruta.
Evitar que cualquier bucket en la cuenta se haga público accidentalmente, incluso si una política de bucket lo permite.
S3 Block Public Access a nivel de cuenta. Anula cualquier política a nivel de bucket; se aplica como una barrera.
Redshift en VPC debe leer desde S3 sin pasar por Internet público.
S3 Gateway Endpoint en la tabla de rutas de la subred de Redshift. El tráfico se enruta a través de la red troncal de AWS; sin NAT, sin IGW.
El trabajo ETL de Glue necesita acceder a RDS en la subred privada Y llamar a las APIs de Glue Data Catalog.
Conexión de Glue en la VPC de RDS + Endpoints de VPC de Interfaz para `glue.amazonaws.com` + S3 Gateway Endpoint.
Glue ETL necesita lectura de S3, escritura de Redshift, lectura de Secrets Manager.
Un único rol de ejecución de Glue con políticas de mínimo privilegio: `s3:GetObject` en el prefijo de origen, `redshift-data:ExecuteStatement`, `secretsmanager:GetSecretValue` en el ARN del secreto específico.
Detectar patrones de acceso a datos inusuales - descarga grande por un usuario de IAM sin acceso previo al data lake.
Protección S3 de GuardDuty. Líneas base de comportamiento por principal de IAM; hallazgos sobre volúmenes/patrones de acceso anómalos.
El cumplimiento requiere retención WORM (write once, read many) en datos financieros durante 7 años.
S3 Object Lock con modo Compliance + período de retención de 7 años. Ni siquiera el root puede eliminar; cumple con SEC 17a-4 / FINRA.
Recopilación continua de evidencia de cumplimiento para auditorías HIPAA / SOC 2.
AWS Audit Manager con frameworks predefinidos. Recopila automáticamente evidencia de CloudTrail, Config, Security Hub; produce informes listos para auditorías.