Optimización de costes y ciclo de vida: de los prefijos calientes a Glacier Deep Archive

Las lecciones 01 to 15 construyeron un lakehouse que funciona: almacenamiento, formatos, tablas, ingesta, catálogo, transformación, consulta, almacén, orquestación, gobernanza, tratamiento de PII, seguridad y observabilidad. Cada una de esas decisiones lleva un medidor asociado, y para ahora esos medidores se han fusionado en una única factura mensual que nadie puede leer línea por línea. La mala noticia: el coste es la única propiedad del lakehouse que se degrada en silencio, porque la factura llega un mes después de la decisión que la provocó. La buena noticia: a diferencia de la corrección, el coste tiene una escalera: un orden fijo de operaciones que las propias guías de Well-Architected de AWS implican y que sigue todo caso de costes publicado por AWS.

Esta lección enseña esa escalera de principio a fin: forma → temperatura → escala accidental → gasto sin atribuir → compromisos, en ese orden, con las tarifas de us-east-1 de octubre de 2026 que convierten cada peldaño en aritmética y no en consejo. La única regla que organiza todo lo que viene abajo: nunca compres un descuento sobre el tamaño equivocado, y nunca muevas un byte a una clase más fría antes de saber cuándo lo vas a leer de vuelta.

En esta lección aprenderás a:

• leer una tabla de formas de coste por servicio que nombra la unidad facturable de cada capa del lakehouse antes de tocar un solo palanca;
• recorrer la cascada de ciclo de vida de S3, cada clase de almacenamiento, duración mínima, tarifa de recuperación y vía de restauración, y calcular un TCO de tres a cinco años para una huella de 60 TB;
• caer a propósito, sobre el papel, en la trampa de la cuota de monitorización de Intelligent-Tiering con ocho millones de objetos diminutos, para que nunca lo hagas en producción;
• acotar la capa de consulta de Athena con cortes por grupo de trabajo, proyección de particiones, poda de columnas y ZSTD, y luego calcular una factura mensual de 500 analistas dos veces: antes y después de los reductores;
• ajustar Glue (DPU = 4 vCPU + 16 GB, $0.44/DPU-hora, mínimo de 1 minuto, timeout por defecto de 48 horas en Glue 4.0 y anteriores) y esbozar EMR Serverless frente a Glue en vCPU-horas y GB-horas;
• aplicar las palancas de Redshift: pausa/reanudación, Redshift Managed Storage a $0.024/GB-mes, créditos de Concurrency Scaling y reservas de Serverless;
• elegir entre el precio por usuario de QuickSight y la capacidad de sesencias de lector con un cálculo de punto de equilibrio, y evitar que la capacidad de SPICE suba sola;
• poner precio a las formas de streaming (horas de shard de Kinesis frente a GB a demanda, incrementos de 5 KB de Firehose, las cinco líneas de MSK Serverless) y a los multiplicadores silenciosos (solicitudes a KMS con y sin bucket keys, eventos de datos de CloudTrail, NAT frente a endpoints de puerta de enlace gratuitos);
• operar Cost Explorer, Budgets y Cost Anomaly Detection y etiquetar el estado con CostCenter / Layer / Project para que cada número posterior sea legible;
• estudiar GE Aerospace (ahorro anual estimado de más de 500,000 $ en Redshift) y Transport for NSW (reducción de ~80 % en costes de integración de datos con Glue), más un recuadro de actualizaciones de 2026 con fuentes;
• practicar con doce preguntas de estilo examen y cuatro comprobaciones interactivas (una gráfica de TCO, una asociación de palanca a servicio, un relleno de tarifas y un arrastrar y soltar de la propia escalera).

---

1. Anatomía de costes: el medidor de cada capa antes que la palanca

1.1 La escalera de cinco peldaños, y por qué el orden no es negociable

La disciplina de optimización de costes de AWS, documentada en el pilar de costes de Well-Architected y repetida en cada caso de costes que AWS publica, es una secuencia, no un menú. Cada peldaño es más barato y más seguro que el que tiene debajo:

1. Forma: deja de pagar por la forma equivocada de los datos. Los formatos columnares, la compresión y la proyección de columnas hacen que los escáneres lean menos bytes. En un medidor por escaneo, este es el cambio de mayor apalancamiento que existe, y no cuesta nada más que reescribir la ruta de escritura.
2. Temperatura: deja de pagar por la temperatura equivocada. Las reglas de ciclo de vida mueven los datos envejecidos a clases de almacenamiento más baratas con un coste de configuración de cero; solo pagas la solicitud de transición.
3. Escala accidental, deja de pagar por el gasto accidental: cortes de escaneo por grupo de trabajo, timeouts de job, presupuestos de Max RPU-hours, acciones de presupuesto. Son disyuntores, no optimizaciones, acotan la cola.
4. Atribución: deja de pagar por el gasto sin atribuir. Las etiquetas de asignación de coste por pipeline convierten una factura ilegible en N facturas legibles. Sin este peldaño, toda medición posterior es una conjetura.
5. Compromisos, solo ahora compra descuentos: nodos reservados de Redshift, Redshift Serverless Reservations, Savings Plans. Un compromiso baja el precio unitario y no hace nada por la cantidad, por eso el peldaño 5 sobre un estado sin optimizar es la forma de consolidar el desperdicio durante uno o tres años.

1.2 Formas de coste por servicio: la tabla que vuelve legible todo lo demás

Cada fila nombra primero la unidad facturable, después el ancla de tarifa de us-east-1 de octubre de 2026, y por último el modo de fallo que infla la factura. Una palanca que no ataca la unidad facturable de su servicio no es una palanca.

1.3 Etiquetado: el peldaño que vuelve legible cada número posterior

Cuatro claves de etiqueta cubren casi todas las necesidades de atribución de un lakehouse, aplicadas a todos los recursos que admiten etiquetas: buckets y prefijos de S3 (mediante etiquetas de objeto donde el servicio lo permite), jobs, crawlers y conexiones de Glue, grupos de trabajo de Athena, clústers y grupos de trabajo de Redshift, carpetas y datasets de QuickSight, streams de Kinesis, clústers MSK, NAT gateways y endpoints de VPC:

Tres reglas duras, todas documentadas por AWS:

1. Las etiquetas deben activarse como etiquetas de asignación de coste antes de aparecer en Cost Explorer o en un informe de asignación de coste, y la activación puede tardar hasta 24 horas en que la clave aparezca en la página de activación más otras hasta 24 horas en surtir efecto.
2. Las etiquetas no son retroactivas. Solo afectan a los informes de facturación desde el momento de la activación. Una estrategia de etiquetado desplegada en octubre de 2026 no te dice nada sobre septiembre.
3. En AWS Organizations, las etiquetas de asignación de coste se activan solo desde la cuenta de gestión (la que paga), y AWS recomienda un número pequeño de claves de etiqueta consistentes: la dispersión es en sí misma un coste, porque cada clave extra es un eje más con el que cuadrar.

1.4 Visibilidad antes que optimización: Cost Explorer, Budgets, Anomaly Detection

No puedes optimizar lo que no puedes ver, y los tres servicios de visibilidad de coste de AWS tienen tres trabajos distintos, y tres facturas distintas:

La forma operativa que documenta AWS: Budgets como disyuntor en tiempo real (umbral → SNS → acción con Lambda), Cost Anomaly Detection como red de seguridad semanal (es lento por diseño), Cost Explorer para la investigación cuando cualquiera de los dos dispara. Ninguno de los tres puede atribuir el gasto a un pipeline sin las etiquetas de la sección 1.3.

• 📚 ¿Sabías que…? La herramienta de FinOps más barata de tu cuenta es una acción de presupuesto, no un cuadro de mando: los primeros dos presupuestos con acciones son gratis, y una acción puede desactivar un grupo de trabajo de Athena o desvincular una política IAM en cuanto se dispare un umbral. Cost Anomaly Detection, por muy inteligentes que sean sus modelos, no puede detener nada, y puede tardar hasta 24 horas en notar una fuga que una acción de presupuesto habría cortado en minutos (documentación de AWS Budgets y Cost Anomaly Detection, consultado 2026-10-11).

---

2. S3: la cascada de ciclo de vida, y la factura de restauración que nadie modela

2.1 Cada clase, cada duración mínima, cada tarifa de recuperación

Esta es la tabla más valiosa de toda la lección. Las tarifas de almacenamiento son el titular; las duraciones mínimas y las tarifas de recuperación es donde vive el diseño.

A esto se suman los cargos del lado de la solicitud que completan el cuadro: las solicitudes de transición de ciclo de vida cuestan $0.01 por 1,000 a Standard-IA / One Zone-IA / Intelligent-Tiering, $0.02 por 1,000 a Glacier Instant Retrieval y $0.05 por 1,000 a Glacier Deep Archive; las tarifas de solicitud de restauración son $0.01 / $0.05 / $0.00 por 1,000 solicitudes para Expedited / Standard / Bulk; los objetos archivados además facturan 40 KB de metadatos por objeto; y toda clase archivada cobra su duración mínima entera: un objeto eliminado o retransitionado fuera de Deep Archive en el día 30 sigue facturando 180 días.

2.2 Reglas de ciclo de vida frente a Batch Operations frente a movimientos manuales

Una regla de ciclo de vida transición o caduca objetos existentes y nuevos que coincidan con un filtro, y la propia configuración es gratis: solo pagas la solicitud de transición ($0.01 to$0.05 por 1,000). AWS no cobra nada por que la regla siga coincidiendo con los objetos de mañana. S3 Batch Operations es la vía retroactiva dirigida por manifiesto: $0.25 por job más $1.00 por millón de operaciones de objeto, con un manifiesto que suele producir S3 Inventory a $0.0025 por millón de objetos listados. La resubida manual o el CopyObject de millones de objetos quema cargos de solicitudes PUT/COPY, necesita una flota de cómputo, y abre una ventana en la que ambas copias facturan.

La regla práctica: reclasificación por antigüedad = regla de ciclo de vida; reclasificación por etiqueta o manifiesto = Batch Operations. Casi nunca necesitas Batch Operations para reclasificar objetos que simplemente envejecen, y pagar para que haga el trabajo de una regla de ciclo de vida es una factura que te autoinfliges.

Tres acciones de ciclo de vida más pertenecen en todo bucket de producción, porque el versionado sin ellas es un multiplicador silencioso: caducar versiones no vigentes (NoncurrentDays), limitar cuántas versiones no vigentes se conservan (MaxNoncurrentVersions, válido 1 to 100) y abortar subidas multiparte incompletas. Con el versionado activado, cada PUT crea una nueva versión vigente mientras la versión anterior sigue facturándose íntegramente a la tarifa de su clase: un bucket con mucho churn puede facturar varias veces su tamaño «lógico» hasta que existan estas tres reglas.

2.3 Economía de la restauración: la copia temporal es la verdadera sorpresa

Restaurar un objeto archivado factura dos cosas, y solo una de ellas es intuitiva:

1. la tarifa de recuperación por GB del nivel de velocidad elegido (tabla de arriba), más la tarifa de solicitud de restauración; y
2. una copia restaurada temporal, cobrada a las tarifas de almacenamiento S3 Standard, durante la duración que decidas conservarla: encima del objeto archivado que sigues pagando.

Así que una restauración de Deep Archive es barata en la línea de recuperación ($0.0025/GB en Bulk) y cara en el plan: 48 horas de latencia, una copia temporal a $0.023/GB-mes prorrateada, y ninguna opción Expedited a ningún precio. Las restauraciones de Deep Archive deben, por tanto, programarse, nunca improvisarse: Bulk para backfills planificados, Standard solo para emergencias reales de 12 horas. Y recuerda el precipicio de la duración mínima a la inversa: si tu patrón de acceso dice «podríamos leer esto dentro de 90 días», el mínimo de 180 días de Deep Archive significa que la clase es la equivocada, no que debas aceptar el riesgo.

• 📚 ¿Sabías que…? Deep Archive no tiene nivel de recuperación Expedited: las opciones de velocidad se detienen en Standard (en 12 horas) y Bulk (en 48 horas). Cualquier diagrama de arquitectura que muestre una vía «instantánea» de salida de Deep Archive está inventando un nivel que AWS no vende (documentación de Amazon S3 Glacier, consultado 2026-10-11).

2.4 Ejemplo resuelto E1: un lakehouse de 60 TB, tres años, y luego cinco

El escenario: un lago operativo de 50 TiB, 20 TiB calientes curados en S3 Standard, 25 TiB templados en Standard-IA, 5 TiB fríos en Glacier Instant Retrieval, más 10 TiB de historial de cumplimiento en Glacier Deep Archive. Una huella de 60 TiB, mantenida tres años. AWS factura el GB como 1,073,741,824 bytes, así que de TiB a GB es ×1,024.

La brecha se ensancha en $591.46 cada mes y es enteramente una decisión del peldaño 2: no cambió código, no se ajustó ninguna consulta, no se compró ningún compromiso. Ahora los dos eventos que rompen los modelos de archivo, lecturas y la factura única de transición, que pertenecen en la misma hoja de cálculo que el almacenamiento.

2.5 Ejemplo resuelto E1b: escenarios de restauración y la factura única de transición

El mismo estado de 60 TiB. ¿Cuánto cuesta leer 1 TiB de vuelta, según la vía, y cuánto costó reclasificar 45 TiB existentes del mismo?

2.6 Intelligent-Tiering: la trampa de la cuota de monitorización en objetos diminutos

Intelligent-Tiering es el valor por defecto más seguro cuando los patrones de acceso son genuinamente desconocidos: sin duración mínima, sin tarifas de recuperación, movimiento automático entre los niveles Frecuente, Infrecuente, Archive Instant, Archive y Deep Archive Access según el acceso observado (los objetos 30 días inactivos pasan al nivel Infrecuente, 90 días a Archive Instant, y Deep Archive Access exige un mínimo de 180 días consecutivos de inactividad). Pero es un negocio de monitorización: cobra $0.0025 por 1,000 objetos al mes por monitorización y automatización, y solo los objetos de al menos 128 KB son elegibles para el auto-tiering en absoluto. Para objetos templados grandes la cuota es un error de redondeo; para millones de objetos diminutos es la factura.

2.7 Ejemplo resuelto E2: ocho millones de objetos diminutos «salvados» por Intelligent-Tiering

Un lago de eventos aterriza fragmentos diminutos en Intelligent-Tiering «para ahorrar dinero». Nada de este diseño ahorra dinero.

La regla de decisión que sale de E2: Intelligent-Tiering es para objetos grandes, templados, de acceso desigual y patrones desconocidos; las clases explícitas de ciclo de vida son para los objetos que entiendes; y ninguno de los dos pertenece a objetos de menos de 128 KB: esos deberían compactarse al escribir, lo que es una corrección de coste y una corrección de rendimiento de consulta en un solo movimiento.

2.8 La replicación puede apuntar a una clase más barata, pero factura dos veces

La clase de almacenamiento de destino es un ajuste de replicación de primera clase: puedes replicar directamente hacia Glacier Flexible Retrieval, Glacier Deep Archive, Intelligent-Tiering y las demás clases (el destino StorageClass de CloudFormation acepta DEEP_ARCHIVE, GLACIER, GLACIER_IR, INTELLIGENT_TIERING, ONEZONE_IA, STANDARD, STANDARD_IA; por defecto se conserva la clase de origen). La región de DR, por tanto, nunca paga tarifas de Standard por una copia que nadie lee.

La trampa es aritmética, no de capacidad: pagas por ambas copias, más los costes de las solicitudes de replicación, más $0.015 por millón de objetos al mes en el bucket de origen por la monitorización de replicación. La replicación hacia una clase más barata es un patrón de recuperación ante desastres y cumplimiento, no un descuento de almacenamiento: modélizalo como «la copia de DR es bastante barata para quedarse para siempre», nunca como «esto reduce mi factura de S3 a la mitad».

---

3. La capa de consulta: Athena factura los bytes escaneados, así que cada escaneo es una decisión de diseño

3.1 El medidor y los cuatro reductores multiplicativos

Athena SQL sobre S3 cuesta $5.00 por TB escaneado en us-east-1: se cobra tanto para consultas exitosas como fallidas (las federadas añaden un mínimo de 10 MB por consulta y agregan entre fuentes de datos), más las cargos ordinarios de solicitudes de S3 por escribir y leer resultados. En un modelo de precios por escaneo, ajustar es facturar. Cuatro reductores independientes se apilan multiplicativamente:

1. Particionado y proyección de particiones: solo se listan y leen las particiones que coinciden. La proyección calcula los valores de partición a partir de las propiedades de la tabla en vez del catálogo, lo que evita por completo la consulta de metadatos; actívala y Athena ignora los metadatos de partición del catálogo, así que necesita predicados en todas las claves proyectadas y se degrada donde más de la mitad de las particiones proyectadas están vacías. Athena puede leer como máximo 1 millón de particiones en un solo escaneo (las tablas de Glue admiten hasta 10 millones).
2. Proyección de columnas: Parquet y ORC leen solo las columnas referenciadas.
3. Compresión, pagas por los bytes escaneados antes de la descompresión, así que ZSTD/GZIP reducen a la vez la factura de consultas y la de S3. ZSTD es la compresión por defecto de las tablas Iceberg en la versión 3 del motor (nivel 3), y AWS recomienda el nivel 3 o 6 to 9 para escrituras Parquet/ORC; los niveles por encima de 19 necesitan memoria seria. Mantén los row groups de Parquet en los 128 MB por defecto y las stripes de ORC en 64 MB, reducirlos por debajo del valor por defecto no se recomienda.
4. Reutilización de resultados, las reejecuciones de una consulta idéntica en la versión 3 del motor y el mismo grupo de trabajo devuelven el resultado en caché con DataScannedInBytes: 0, hasta una antigüedad de 60 minutos por defecto y 7 días como máximo. El SQL no determinista (rand(), shuffle()) lo elude, y también lo eluden los permisos a nivel de fila/columna de Lake Formation y las consultas federadas, que siempre se reejecutan.

El propio ejemplo resuelto de AWS del mecanismo: 3 TB de texto sin comprimir, una columna seleccionada, sin comprimir = 3 × $5 = $15; con compresión 3:1 = $5; como Parquet con compresión 3:1 y selección de columnas 4:1 = $1.25. Tres palancas, doce veces más barato, la misma consulta.

3.2 Guardias de gasto por grupo de trabajo: disyuntores para la capa de consulta

Los grupos de trabajo son a la vez la unidad de aislamiento y la unidad de control de coste, y AWS documenta un patrón de producción con dos grupos de trabajo:

• Corte por consulta, BytesScannedCutoffPerQuery (mínimo de API 10,000,000 bytes = 10 MB) cancela una consulta desbordada en cuanto cruza el umbral. La consulta cancelada sigue facturando todo lo escaneado hasta el corte, el corte acota la cola, nunca descuenta la cabeza.
• Controles de uso por grupo de trabajo: dispara una alarma SNS, y la escalada documentada es una función Lambda que desactiva el grupo de trabajo cuando un máximo histórico se dispara.
• Etiquetas de asignación de coste en el grupo de trabajo: etiqueta cada grupo de trabajo (digamos Name=ad-hoc-users, Dept=analytics) para que el gasto de Athena aterrice bajo el CostCenter correcto en el Cost and Usage Report.

Athena también vende Capacity Reservations a $0.30 por DPU-hora (una reserva de 160 DPU para una hora pico de 15 minutos cuesta 160 × $0.30 × 0.25 = $12.00 en el ejemplo resuelto de AWS) y sesiones Spark a $0.35 por DPU-hora: la opción del peldaño 5 una vez que los peldaños 1 to 3 han hecho su trabajo. Existe un techo de 1,000 grupos de trabajo por región, que es capacidad para un grupo de trabajo por equipo o pipeline, no uno por usuario.

3.3 Ejemplo resuelto E3: 500 analistas, 50 GB al día, antes y después de los reductores

Este es el cálculo que todo equipo de analítica debería poder reproducir de memoria, porque es el que decide si Athena es una línea de factura o un error de redondeo.

La lección de E3 es la ratio: los reductores llevaron ~$2,563 hasta ~$154, una reducción de 16×, antes de que nadie comprara nada. Un equipo que negocia un compromiso mientras sigue ejecutando SELECT * sobre ficheros de texto se ha saltado los peldaños 1 y 2 para ahorrar monedas en el peldaño 5.

---

4. Transformación: ajuste de DPU en Glue, facturación por minuto y el esbozo de EMR Serverless

4.1 Qué factura Glue realmente, y dónde muerden los valores por defecto

Glue ETL cuesta $0.44 por DPU-hora, facturado por segundo con un mínimo de 1 minuto (los crawlers llevan un mínimo de 10 minutos; las tareas de Data Quality un mínimo de 1 minuto con un suelo de 2 DPU). Una DPU son 4 vCPUs de cómputo y 16 GB de memoria. Existen dos modelos de capacidad, separados por versión:

• Los jobs al estilo de Glue 1.0 especifican capacidad aprovisionada mediante MaxCapacity en DPUs (mínimo 2, máximo 100, por defecto 10).
• Los jobs de Glue 2.0 y posteriores no pueden fijar una capacidad máxima en absoluto: especifican un tipo de worker × número de workers: G.1X = 1 DPU, G.2X = 2 DPU, hasta G.16X; G.025X es una cuarta parte de DPU para streaming de bajo volumen a un cuarto del coste; los workers R.* son optimizados en memoria en M-DPU (4 vCPU + 32 GB); Z.2X es el worker de Ray (2 M-DPU, 8 workers de Ray). Los jobs de Spark asignan 2 a 100 DPUs, por defecto 10; los jobs de shell de Python usan 0.0625 o 1 DPU. Los jobs creados sin versión usan por defecto Glue 5.1.

Tres valores por defecto se esconden en esa tabla: una asignación por defecto de 10 DPUs, un timeout de job por defecto de 2,880 minutos (48 horas) en Glue 4.0 y anteriores (480 minutos en Glue 5.0 y posteriores; máximo absoluto justo por debajo de 7 días), y la clase de ejecución Flex a $0.29 por DPU-hora para capacidad interrumpible, facturada por tiempo de worker en lugar de capacidad máxima × tiempo en reloj. El dimensionamiento es una actividad medida: compara los ejecutores máximos necesarios contra los ejecutores máximos asignados, y deja de escalar cuando el tiempo en reloj deje de mejorar: en el propio ejemplo publicado por AWS el job mejora de 10 DPUs / 6 minutos a 55 DPUs / 3 minutos y 100 DPUs no compran nada más.

4.2 Ejemplo resuelto E4: un job desbordado, un job bien dimensionado, y la alternativa de EMR Serverless

• 📚 ¿Sabías que…? Glue publica una métrica de CloudWatch DPUHours por ejecución de job (las dimensiones incluyen JobName, JobRunId, JobType, GlueVersion y ExecutionClass), de modo que una alarma de presupuesto puede dispararse por DPU-horas consumidas, y no por tiempo en reloj: la única forma fiable de atrapar el desbordamiento de E4 antes de que lo haga el timeout. Activar métricas de job, logs de aplicación y logging continuo añade cargos propios de CloudWatch, así que actívalos donde el valor de la alarma supere el coste del log (AWS Big Data Blog, 2023-04-28).

---

5. Redshift: pausa/reanudación, almacenamiento gestionado, créditos de concurrencia, RPU de Serverless

La pata del almacén del lakehouse tiene tres medidores, y la mayoría de los argumentos de precio de etiqueta los confunden:

1. Cómputo, provisionado: los nodos RA3 y RG se facturan por hora (el propio ejemplo resuelto de AWS precifica ra3.4xlarge en $3.26 por nodo-hora a demanda: 4 nodos × $3.26 × 730 horas = $9,519.20 al mes). Los nodos reservados descuentan esto en torno a 20 % (sin pago inicial) hasta 42 to 76 % (pago total por adelantado).
2. Almacenamiento, siempre separado: Redshift Managed Storage factura $0.024 por GB-mes tanto si los datos están en SSD locales como en S3. Este es el punto de diseño de RA3: deja de pagar por disco local que solo estabas llenando de datos fríos. 10 TiB de almacenamiento gestionado = 10,240 GB × $0.024 = $245.76 al mes.
3. Cómputo Serverless, RPU-horas por segundo con un mínimo de 60 segundos a $0.375 por RPU-hora en us-east-1 (1 RPU ≈ 16 GB); la base de 4 RPU es $1.50 por hora; no hay cargo mientras no se ejecuten consultas, y Spectrum más Concurrency Scaling están incluidos. Acótalo con los ajustes de Max RPU-hours y de capacidad máxima; las Serverless Reservations reducen el cómputo hasta un 24 % (1 año) o un 45 % (3 años), la respuesta del peldaño 5 para una carga serverless estable.

Pausa/reanudación suspende la facturación de cómputo a demanda: mientras está en pausa solo pagas el almacenamiento de copias de seguridad: lo que hace baratos los clústers de desarrollo/pruebas y los de ventana de lote. La trampa: los cargos de nodos reservados siguen facturando durante la pausa, porque compraste el nodo, no el tiempo encendido. Concurrency Scaling gana una hora gratis de crédito de clúster transitorio cada 24 horas por clúster activo, acumulable hasta 30 horas (los créditos no caducan mientras viva el clúster), y después factura por segundo con un mínimo de un minuto solo mientras el clúster transitorio sirve consultas. Y Spectrum en clústers provisionados factura $5.00 por TB escaneado: el mismo medidor que Athena, así que el peldaño 1 (poda, diseño columnar) descuenta a ambos motores a la vez.

5.1 Ejemplo resuelto E5: el almacén que duerme

---

6. La capa de BI: los dos ejes de precio de QuickSight y el pool de SPICE

QuickSight precifica dos ejes a la vez, y un estado de cuadros de mando puede optimizarse en cualquiera de los dos:

• Por usuario (Enterprise): Author $24 por usuario-mes, Reader $3 por usuario-mes, más SPICE a $0.38 por GB-mes más allá de los 10 GB incluidos con cada Author aprovisionado. La edición Standard es $9 por usuario-mes anual (o $12 mensuales) con 10 GB por usuario incluidos y $0.25 por GB adicional. Cada dataset de SPICE en Enterprise admite un máximo de 1,000 millones de filas por 1 TB de tamaño.
• Capacidad: sesencias de lector vendidas en packs: 500 sesiones al mes por $250 ($0.50 por sesión), con niveles anuales hasta $0.40 a 50,000 sesiones/año, $0.28 a 200,000, $0.24 a 400,000,$0.20 a 800,000 y $0.16 por sesión a 1.6 millones de sesiones/año. Una sesión es un período de 30 minutos, no una visualización, y el precio por capacidad es obligatorio para la actualización programada de cuadros de mando.

El modelo por usuario gana con una población conocida y estable; la capacidad gana con un consumo picos, incrustado o programático. SPICE en sí es un pool compartido por región: la capacidad comprada en una región no puede usarse en otra, los datasets permanecen en SPICE hasta que alguien los elimina, y la compra automática de capacidad está activada por defecto en las cuentas creadas por consola, el clásico ratchet silencioso que sube tu pool y nunca lo baja (desactivarlo más tarde deja el pool actual como tu capacidad comprada). Por último, la elección del modo mueve el medidor: Import (SPICE) convierte el coste de consulta en un $/GB-mes fijo con retraso de actualización, mientras que Direct Query empuja cada interacción de visualización de vuelta a Athena/Redshift, la aritmética de bytes escaneados de la sección 3, multiplicada por el número de vistas de los cuadros de mando.

6.1 Ejemplo resuelto E6: 10 Authors, 400 Readers, 500 GB de SPICE

• 📚 ¿Sabías que…? El precio de Reader está escrito solo para interacciones de sesión manuales: AWS se reserva el derecho de facturar a un lector a la tarifa más alta de Author si las sesiones de lector se usan para consultas programáticas o automatizadas. El análisis incrustado que sondea los cuadros de mando con un temporizador es la vía documentada de la factura de susto, y es también exactamente el uso que requiere precio por capacidad en lugar de por usuario (precios y preguntas frecuentes de Amazon QuickSight, consultado 2026-10-11).

---

7. Formas de streaming: horas de shard, GB con suelo, incrementos de 5 KB, horas de clúster

Los servicios de streaming se parecen mucho en un diagrama de arquitectura y facturan cuatro unidades distintas. El resumen relevante para el lakehouse: Firehose + Kinesis son baratos por GB; MSK es caro por hora: elige MSK solo cuando necesites la semántica de Kafka que la alternativa no puede ofrecer.

• Kinesis Data Streams, provisionado: horas-shard a $0.015 por hora-shard, las unidades de payload PUT contadas en bloques de 25 KB a $0.014 por millón, retención extendida opcional a $0.020 por hora-shard, y enhanced fan-out a $0.015 por hora-shard por consumer-shard.
• Kinesis on-demand Standard: por GB, con un suelo a nivel de cuenta de 25 MB/s ingeridos y 25 MB/s recuperados en todos los streams a demanda, los streams pequeños pueden pagar por ancho de banda que nunca envían. On-demand Advantage (introducido el 2025-11-04) elimina el cargo por hora del stream y reduce la ingesta a $0.032/GB, con un mínimo comprometido de 25 MiB/s; la comparación publicada de AWS de 48 horas fue $2,071.75 (Standard) frente a $823.44 (Advantage), un ~60 % menor, en torno a $228,125 anualizados para esa carga de trabajo, y la propia advertencia de AWS es que las cargas con picos por debajo de 10 MiB/s deberían quedarse en Standard. La retención más allá de 24 horas cuesta en Standard +$0.10/GB hasta 7 días, frente a $0.023 por GB-mes en Advantage más allá de 24 horas hasta 365 días.
• Firehose: factura los GB ingeridos en incrementos de 5 KB (primeros 500 TB a $0.029/GB), un registro de 3 KB se factura como 5 KB, con complementos de conversión de formato, entrega en VPC y particionado dinámico, y $0.045/GB al entregar desde Kinesis a tablas Iceberg.
• MSK Serverless: cinco líneas de factura: horas de clúster $0.75, horas de partición $0.0015, data-in $0.10/GB, data-out $0.05/GB, almacenamiento $0.10/GB-mes. El ejemplo resuelto oficial de AWS (31 días, 100 particiones, 100 GB/día) suma $1,299.60: $558.00 + $111.60 + $310.00 + $310.00 + $10.00.

7.1 Ejemplo resuelto E7: tres formas de streaming, tres facturas

---

8. Los multiplicadores silenciosos: KMS, eventos de datos de CloudTrail y el impuesto NAT

8.1 Costes de solicitudes de KMS y la palanca de las bucket keys

SSE-KMS en un lago factura $1.00 por clave gestionada por el cliente al mes más $0.03 por 10,000 solicitudes por encima de un nivel gratuito mensual de 20,000 solicitudes. En un lago de alta QPS, la línea de solicitudes supera habitualmente a la línea de GET de S3: por eso las bucket keys de S3, que la documentación de AWS indica que reducen los costes de KMS hasta un 99 %, son higiene obligatoria y no una optimización. La palanca compañera son los eventos de datos de CloudTrail: la primera copia de los eventos de gestión es gratis (copias extra $2.00 por 100,000), pero los eventos de datos de S3 cuestan $0.10 por 100,000 eventos entregados: registrar eventos de datos de todo el bucket en un lago ocupado es una línea de cinco cifras, y la solución son los selectores de eventos avanzados acotados a prefijos sensibles (el análisis de agregación de eventos de datos cuesta más barato: $0.03 por 100,000). Los selectores de eventos avanzados nunca se mezclan con los selectores básicos en el mismo trail, y cada trail admite 500 de ellos.

8.2 NAT frente a endpoints: el ahorro de red de mayor confianza

Cada GB por un NAT gateway cuesta $0.045, más $0.045 por hora por AZ mientras esté aprovisionado y disponible. Los endpoints de puerta de enlace para S3 y DynamoDB son gratuitos, sin cargo por procesamiento de datos, sin cargo horario, y son la vía correcta para cualquier flota de ETL residente en VPC que hable con S3. Los endpoints de interfaz facturan en torno a $0.01 por hora por AZ más $0.01 por GB (primer PB, después $0.006 y$0.004), con cada hora de endpoint parcial facturada como una hora completa. Una flota de VPC que empuja el tráfico de S3 por el NAT arrastra un recargo no buscado de 3 to 5× en su red de ruta de datos y pierde la clave de condición aws:SourceVpce de la que depende el perímetro de red de la lección 14.

8.3 Ejemplo resuelto E8: las misiones laterales de cifrado, auditoría y red

---

9. Poner la escalera a trabajar: comprobaciones interactivas sobre las propias palancas

9.1 Comprobación interactiva: asocia cada palanca con el medidor que ataca

9.2 Comprobación interactiva: rellena las tarifas de las que depende el diseño

9.3 Comprobación interactiva: ordena la escalera antes de tocar una factura

• 📚 ¿Sabías que…? La replicación puede apuntar directamente a una clase de almacenamiento de destino más barata (DEEP_ARCHIVE, GLACIER, GLACIER_IR y compañía son destinos de replicación legales): un diseño genuino de DR, ya que la copia aterriza fría sin que una regla de ciclo de vida dispare nunca. Lo que no es, es un descuento: pagas por ambas copias más las solicitudes de replicación más $0.015 por millón de objetos al mes de monitorización (documentación de la replicación de Amazon S3, consultado 2026-10-11).

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

AWS publica cómo se ve esta escalera en producción. Todas las cifras de abajo son afirmaciones del cliente o de AWS y no auditadas, con la fuente nombrada para que puedas comprobarlas: el punto examinable es el patrón: qué peldaño se movió, y en qué dirección.

Caso A, GE Aerospace: modernizar un almacén operativo de datos en Redshift

Lee los 500,000 $ como la propia estimación de GE de su ahorro, nunca como una garantía de AWS ni como una tarifa que puedas aplicar a tu parque. El patrón transferible es la secuencia: PoC primero, nueve meses de migración por fases, el límite de cumplimiento (GovCloud) tratado como una entrada de arquitectura, y la victoria de coste llegando como un subproducto de modernizar la carga de trabajo, no como un descuento comprado sobre un sistema sobredimensionado.

Caso B, Transport for NSW: más de 400 workflows ETL movidos a Glue, ~80 % más baratos

La lectura de la lección 16 sobre TfNSW es que el 80 % vino del cambio de medidor y del cambio operativo juntos: una plataforma con licencia factura por existir, Glue factura por las DPU-segundos realmente usadas. Pero repara en lo que hizo la migración posible: el soporte de Python y la formación de más de 30 personas: que es una palanca de personas, no de precios. Un tercer punto de referencia del mismo corpus de AWS: Integral Ad Science ejecutó un grupo de trabajo de Athena por unidad de negocio con etiquetas de facturación por departamento y límites de consulta (AWS Big Data Blog, 2021-09-23): el diseño de las secciones 1.3 y 3.2, en producción.

• 📚 ¿Sabías que…? Los dos porcentajes principales son páginas de cliente sin fecha, así que llevan «consultado en octubre de 2026» en lugar de una fecha de publicación, y ambos describen migraciones específicas, no garantías de servicio. El >500,000 $ de GE Aerospace es una estimación; el ~80 % de TfNSW cubre solo los costes de integración de datos, no toda la factura de analítica. Citar cualquiera de los dos como «Redshift ahorra un 70 %» o «Glue es un 80 % más barato» es el tipo de deriva para la que existe la disciplina de fuentes de este curso (casos de estudio de AWS, consultado 2026-10-11).

---

Preguntas de Práctica (Practice Questions)