S3 como fundación del data lake: clases de almacenamiento, Glacier y durabilidad

Cada lakehouse de este curso se construye sobre una suposición: Amazon S3 es el sustrato. Glue lo rastrea, Athena lo escanea, Redshift Spectrum lo monta, Lake Formation concede sobre él, Macie lo inspecciona, QuickSight lo lee. Nada aguas abajo puede rescatar un lago cuya capa de almacenamiento se diseñó por accidente, y en S3, «por accidente» tiene un precio concreto. La clase de almacenamiento equivocada te factura una tarifa de recuperación por cada byte que lee un motor; el diseño de prefijos equivocado limita la ingesta a 3,500 escrituras por segundo; el tamaño de objeto equivocado añade 40 KB de metadatos de archivo por archivo; el diseño de retención equivocado convierte una regla de ciclo de vida en una puerta de un solo sentido con una factura mínima de 180 días.

La buena noticia es que el modelo de costes de S3 es conocible. Cada tarifa de esta lección proviene de la oferta del Price List de AWS para Amazon S3 en us-east-1 (fecha de publicación 2026-09-28, efectiva 2026-09-01, consultada octubre de 2026) más la guía de usuario de S3, la página de precios y la FAQ de AWS (consultadas en octubre de 2026). Haz la aritmética tú mismo; es la única manera de diseñar un lago que siga siendo asequible en el año siete.

En esta lección vas a:

• leer la tabla completa de clases de almacenamiento: las ocho clases más cada nivel de Glacier, con tiempo de recuperación, tarifa de recuperación y duración mínima de almacenamiento;
• recorrer el árbol de decisión de clases de almacenamiento y la cascada unidireccional de ciclo de vida como diagramas mermaid, y después ordenar la cascada tú mismo en un arrastrar y soltar interactivo;
• modelar versionado, replicación, Object Lock (WORM) y retenciones legales, incluyendo exactamente qué mutaciones la replicación no refleja;
• elegir entre SSE-S3, SSE-KMS, DSSE-KMS y SSE-C, y usar una S3 Bucket Key para reducir el coste de peticiones de KMS «hasta en un 99 por ciento»;
• diseñar buckets, prefijos y claves de partición al estilo Hive contra el modelo de ≥3,500 peticiones de escritura / ≥5,500 de lectura por segundo por prefijo;
• aplicar Block Public Access (cuatro ajustes) y los ocho patrones de política de bucket que necesita un lago privado;
• construir la tubería de gobernanza, S3 Inventory y S3 Batch Operations, que las reglas de ciclo de vida y la replicación en vivo no pueden hacer solas;
• calcular a mano cinco modelos de coste con cifras reales: la escalera de clases de 1 TiB, una restauración de Deep Archive de 50 TiB, un diseño de rendimiento de prefijo caliente, un TCO de 7 años de ciclo de vida a Deep Archive, un punto de equilibrio de Intelligent-Tiering y la trampa de metadatos de archivo de 40 KB;
• estudiar dos casos de clientes de AWS con nombre (Nasdaq y Siemens), leer el recuadro de actualizaciones de 2026 y practicar con 12 preguntas de estilo examen más cuatro comprobaciones interactivas.

---

1. Las ocho clases de almacenamiento: una durabilidad, ocho economías

1.1 La tabla comparativa (en oct 2026)

Amazon S3 ofrece ocho clases de almacenamiento actuales más una obsoleta. AWS las documenta lado a lado en la comparación de clases de la guía de usuario de S3 (consultada en oct 2026). Todas comparten una durabilidad diseñada de 99.999999999%, once nueves, así que la durabilidad nunca es el discriminador. Lo son el diseño de disponibilidad, la huella de AZ, la duración mínima de almacenamiento, el tamaño mínimo facturable de objeto y las tarifas de recuperación.

Tres detalles de esa tabla hacen más daño que cualquier otro:

1. S3 Express One Zone es una clase de directory buckets. Vive en un tipo de bucket distinto (directory buckets con --bucket-prefix), es de una sola AZ, y se precifica a $0.11/GB-mes, unas 4.8× el almacenamiento de S3 Standard, a cambio de una latencia consistente de un solo dígito de milisegundos. Es un nivel de servicio/scratch, nunca el lago de registro.
2. Intelligent-Tiering no tiene tarifa de recuperación en absoluto. Reemplaza esa tarifa con una cuota de monitoreo por objeto: $0.0025 por 1,000 objetos por mes (oferta del Price List de AWS, 2026-09-28). Los objetos menores de 128 KB no se monitorean y no pagan cuota: lo cual es a la vez una trampa y una pista (sección 10).
3. Las tres clases de Glacier no son «S3 más lento.» Dos de ellas (Flexible Retrieval, Deep Archive) no pueden leerse con GetObject en absoluto hasta que ejecutes un restore asíncrono. Ese único hecho impulsa cada diseño de archivo de este curso.

1.2 Ejemplo resuelto E1: la escalera mensual de 1 TiB

En oct 2026 (lista us-east-1). ¿Cuánto cuesta simplemente retener 1 TiB = 1,024 GB durante un mes en cada clase?

Dos lecturas de esa escalera importan. Primero, Deep Archive es 23× más barato que Standard para retener ($1.014 frente a $23.552), y exactamente por eso el nivel de archivo es una decisión de retención, no de rendimiento. Segundo, Express One Zone es 4.8× más caro que Standard para retener, y por eso aloja tablas de servicio gold y feature stores de ML, nunca bronze.

La FAQ de S3 lo dice claramente: «Desde solo $0.00099 por GB-mes … S3 Glacier Deep Archive ofrece el almacenamiento de menor coste en la nube» (consultada en oct 2026). Una advertencia que conviene llevar: la oferta del Price List de us-east-1 de 2026-09-28 contiene los SKUs de staging de Deep Archive y de Intelligent-Tiering Deep Archive Access pero ningún SKU independiente de almacenamiento Deep Archive, así que trata $0.00099 como publicado por AWS en lugar de confirmado por la lista de precios, y vuelve a verificarlo antes de comprometer un archivo de siete cifras.

• 📚 ¿Sabías que…? La Redundancia reducida (RRS) todavía aparece en la lista de precios de S3 a $0.0240→$0.0220/GB-mes, pero la guía de usuario de S3 solo dice: «Recomendamos no usar esta clase de almacenamiento» (consultada en oct 2026). Es más cara que S3 Standard con menos redundancia. Cualquier opción de estilo examen, deck de proveedor o runbook heredado que todavía enrute datos a RRS es incorrecto en oct 2026.

---

2. La familia Glacier: cada nivel, cada tarifa, cada reloj

«Glacier» son tres clases de almacenamiento y cinco niveles de restauración, y la diferencia entre ellas es la diferencia entre una consulta que devuelve en milisegundos y un ticket que se cierra mañana.

2.1 La tabla de archivo

Fuentes: comparación de clases de almacenamiento de S3 Glacier y viñetas de niveles (guía de usuario, consultada en oct 2026); precios de recuperación y peticiones de restore de la oferta us-east-1 de 2026-09-28; «Las recuperaciones y peticiones Bulk de S3 Glacier Flexible Retrieval son gratuitas» y «Las peticiones DELETE y CANCEL son gratuitas» (página de precios de S3, consultada en oct 2026).

Lee la tabla en vertical y salen tres reglas:

• Glacier Instant Retrieval es la única clase de archivo que un motor de consulta puede leer directamente: milisegundos, pero cada byte leído cuesta $0.03/GB, siete veces y media su propia tarifa de almacenamiento.
• El nivel Bulk de Glacier Flexible Retrieval es gratis pero lento: $0.00/GB, típicamente 5 to 12 horas. La FAQ lo redacta como «Las recuperaciones Bulk típicamente se completan dentro de 5 to 12 horas, y son gratuitas».
• Deep Archive no tiene nivel Expedited a través de S3. La ruta publicada más rápida es Standard a $0.02/GB «dentro de 12 horas»; Bulk a $0.0025/GB tarda «dentro de 48 horas». La tabla de comparación en otra parte de la misma guía cita el rango como «9 a 48 horas»: planifica contra las viñetas de niveles, no contra el mejor caso.

2.2 Un restore no es un GET

Este es el mecánico más malinterpretado de todo el modelo de precios de S3, así que tiene su propio diagrama.

La propia página de precios de AWS enuncia la consecuencia: «Cuando restauras un archivo, estás pagando tanto el archivo… como una copia… restaurada temporalmente (cobrada a la tarifa de almacenamiento de S3 Standard durante un tiempo que elijas» (consultada en oct 2026). Así que la factura completa de restore tiene cuatro componentes: almacenamiento del archivo (que sigue devengando) + la tarifa de recuperación por GB del nivel + la cuota de petición de restore por 1,000 + almacenamiento Standard en la copia temporal durante toda la duración elegida. El original archivado nunca cambia de clase: HeadObject sigue informando GLACIER o DEEP_ARCHIVE después de un restore exitoso.

2.3 Ejemplo resuelto E2: restaurar 50 TiB desde Deep Archive

Una casa de medios debe regurgitar una biblioteca de emisión de 50 TiB (51,200 GB) dentro de una ventana de cinco días. Retén la copia restaurada durante 5 días.

Veredicto: Bulk para recuperaciones planificadas; Standard solo cuando el reloj de negocio es más corto que 48 horas. La delta de $896 es pura tarifa de recuperación: el cargo de la copia temporal es idéntico en ambos casos, y por eso la copia temporal, no la tarifa de recuperación, domina cualquier retención larga. ¿Necesitas los datos en menos de 15 minutos? Deep Archive no puede ayudarte: no hay nivel Expedited vía S3, así que un SLA de la misma hora significa que los datos nunca debieron salir de Standard, Standard-IA o Glacier Instant Retrieval.

• 📚 ¿Sabías que…? El servicio Amazon Glacier vault independiente, un producto separado con sus propias APIs y ARNs de vault, «ya no acepta nuevos clientes desde el 15 de diciembre de 2025» (página de precios de S3 Glacier, consultada en oct 2026). AWS ahora recomienda: «Recomendamos usar las clases de almacenamiento S3 Glacier dentro del servicio Amazon S3 para todos tus datos a largo plazo». En 2026, «Glacier» en una conversación de diseño significa tres clases de almacenamiento en un bucket S3 normal, no un vault.

---

3. Elegir una clase: el árbol de decisión y la cascada

3.1 El árbol de decisión de clases de almacenamiento

La frecuencia de acceso, la latencia requerida y si el objeto es recreable deciden la clase: en ese orden. Las etiquetas de las hojas llevan el precio y el reloj al que te estás comprometiendo.

Dos ramas merecen el comentario:

• «Acceso desconocido» no significa automáticamente Intelligent-Tiering. Significa Intelligent-Tiering una vez que los objetos sean lo bastante grandes para monitorearse (≥128 KB) y lo bastante pocos que la cuota de monitoreo no sea toda la factura. Para un archivo de trimestre conocido, Glacier Instant Retrieval suele ser más barato: la sección 10.3 hace el punto de equilibrio.
• One Zone-IA es un intercambio de durabilidad, no solo un descuento. 99.5% de disponibilidad en una sola AZ significa una pregunta genuina de si los datos pueden recrearse. Los lagos la usan para datos derivados reproducibles, nunca para la única copia de datos de origen en bruto.

3.2 La cascada de ciclo de vida es unidireccional

Amazon S3 «soporta un modelo de cascada para transicionar entre clases de almacenamiento» (guía de usuario de ciclo de vida de S3, consultada en oct 2026). Los objetos fluyen hacia abajo; no vuelven hacia arriba. Las flechas de retroceso en el diagrama de abajo no son aristas de ciclo de vida: son operaciones de restore y copia que ejecutas a mano o a través de S3 Batch Operations, y cada una reinicia el reloj de duración mínima de la clase de destino y re-factura a la tarifa de destino.

Reglas que los docs de ciclo de vida de S3 ponen por escrito (consultados en oct 2026):

• «No puedes crear una sola regla de ciclo de vida que transicione objetos de una clase de almacenamiento a otra antes de que haya pasado el periodo de duración mínima de almacenamiento.»
• «La transición de objetos a la clase de almacenamiento S3 Glacier Deep Archive solo puede ir en una dirección.»
• «Un objeto es elegible solo para una acción de ciclo de vida de S3 por día. Cuando múltiples reglas coinciden, Amazon S3 aplica la acción menos costosa.»
• Precedencia: borrado permanente > transición > creación de marcadores de borrado. Cuando tanto una transición a Glacier Flexible Retrieval como una a Standard-IA son elegibles, «Amazon S3 elige la transición a S3 Glacier Flexible Retrieval».
• Una configuración puede contener hasta 1,000 reglas: «Este límite no es ajustable».
• Desde septiembre de 2024, «Los objetos menores de 128 KB no transicionarán por defecto a ninguna clase de almacenamiento».

---

4. Durabilidad, versionado y replicación

4.1 Versionado: tres estados, facturación de objeto completo

El versionado de S3 es a nivel de bucket y todo-o-nada, con exactamente tres estados: sin versionar (el por defecto), habilitado y suspendido. La guía de usuario de AWS es directa sobre la facturación: «Cada versión de un objeto es el objeto completo; no es solo un diff… si tienes tres versiones de un objeto almacenadas, se te cobra por tres objetos» (consultada en oct 2026).

El versionado es un prerrequisito para dos cosas que necesitarás más adelante: S3 Object Lock (que solo funciona en buckets con versionado) y S3 replicación (que requiere versionado en origen y destino).

4.2 Replicación: CRR, SRR y el muro de clases archivadas

La replicación entre Regiones (CRR) y la misma Región (SRR) son el mismo mecanismo con destinos distintos. El versionado debe estar habilitado en ambos lados. Qué se replica por defecto (docs de replicación de S3, consultados en oct 2026):

• Se replica: objetos nuevos creados después de la configuración, metadatos del objeto, etiquetas, anotaciones, actualizaciones de ACL, retención de Object Lock, y objetos cifrados con SSE-S3 / SSE-KMS / DSSE-KMS / SSE-C.
• No se replica por defecto: objetos que son en sí mismos réplicas (sin encadenamiento), marcadores de borrado cuando la configuración usa un elemento Filter, borrados permanentes de versión, cambios de subrecurso a nivel de bucket, y marcadores de borrado creados por ciclo de vida.
• No replicable en absoluto hasta restaurar: objetos en Glacier Flexible Retrieval, Glacier Deep Archive, Intelligent-Tiering Archive Access e Intelligent-Tiering Deep Archive Access. Las palabras exactas de AWS: «No puedes replicar estos objetos hasta que los restaures y los copies a una clase de almacenamiento diferente».

Tres consecuencias operativas para un lago:

1. CRR no es una copia de seguridad en vivo de cada mutación. Con la versión de configuración actual (un Filter), los marcadores de borrado no se replican a menos que habilites explícitamente la replicación de marcadores de borrado, y los borrados por ID de versión nunca se reflejan: deliberadamente, para que un principal comprometido no pueda borrar la copia DR borrando versiones en el origen.
2. El backfill retroactivo necesita S3 Batch Replication. La replicación en vivo solo cubre objetos creados después de la configuración; todo lo anterior es un job de Batch Operations.
3. El monitoreo cuesta $0.015 por 1 millón de objetos por mes en el bucket de origen (oferta de 2026-09-28). No hay un SKU separado de «$0.02 por GB replicado» en esa oferta: pagas almacenamiento del bucket de destino y transferencia de datos ordinaria entre Regiones además de la cuota de monitoreo. No enseñes la cifra por GB sin volver a verificar la pestaña de precios de Replicación.

• 📚 ¿Sabías que…? La replicación de S3 lleva la información de retención de Object Lock a las réplicas: «aplica esos mismos controles de retención a tus buckets de destino» (docs de replicación de S3, consultados en oct 2026). Eso es lo que convierte a CRR en una segunda copia de cumplimiento en lugar de meramente una segunda copia: la fecha de retain-until sobrevive el salto de Región.

---

5. Object Lock: WORM para zonas del lago reguladas

S3 Object Lock «usa un modelo write-once-read-many (WORM)» y «solo funciona en buckets que tienen habilitado S3 Versioning» (guía de usuario de S3, consultada en oct 2026). Protege una versión de objeto, no una clave, y esa distinción es donde fallan la mayoría de los diseños.

AWS ha tenido Object Lock «evaluado por Cohasset Associates para su uso en entornos sujetos a las regulaciones SEC 17a-4, CFTC y FINRA» (consultado en oct 2026), y exactamente por eso los relatos de datos regulados de este curso (archivos de vigilancia estilo FINRA, el nivel de cumplimiento de Nasdaq) lo buscan.

• 📚 ¿Sabías que…? Un límite de una sola regla que la mayoría pasa por alto: una configuración de ciclo de vida de S3 «puede tener hasta 1,000 reglas» y el filtro de cada regla puede usar «un prefijo de nombre de clave de objeto, una o más etiquetas de objeto, el tamaño del objeto, o cualquier combinación de estos» (docs del API de S3, consultados en oct 2026), y no puedes usar una política de bucket para prevenir borrados o transiciones por una regla de ciclo de vida. Object Lock detiene principales; la expiración de ciclo de vida es una acción del servicio, así que los diseños de zona auditada emparejan Object Lock con reglas de ciclo de vida que deliberadamente se detienen antes del límite de retención.

---

6. Cifrado: SSE-S3, SSE-KMS, DSSE-KMS, SSE-C y Bucket Keys

Desde el 5 de enero de 2023, «todas las subidas de objetos nuevos a Amazon S3 se cifran automáticamente sin coste adicional y sin impacto en el rendimiento»: ese por defecto es SSE-S3 (guía de usuario de S3, consultada en oct 2026). Todo lo demás es una actualización con un precio y una restricción.

Tres mejoras que un lago normalmente necesita:

1. Una S3 Bucket Key. «Usar una clave a nivel de bucket para SSE-KMS puede reducir tu coste de peticiones de AWS KMS hasta en un 99 por ciento» (guía de usuario de S3, consultada en oct 2026). A volúmenes de escritura de lago, cientos de miles de llamadas PutObject al día, la factura de peticiones de KMS es la diferencia entre que SSE-KMS sea asequible y sea una línea de factura.
2. Una CMK gestionada por el cliente para cualquier cosa entre cuentas. «Los objetos cifrados usando SSE-KMS con claves gestionadas por AWS no se pueden compartir entre cuentas. Si necesitas compartir datos SSE-KMS entre cuentas, debes usar una clave gestionada por el cliente». Concede kms:Decrypt a la cuenta consumidora y habilita la Bucket Key.
3. El cifrado sobrevive las transiciones de clase, pero nota la nota al pie de facturación: «Los objetos en S3 Glacier Flexible Retrieval y S3 Glacier Deep Archive se facturan a tarifas de la clase de almacenamiento S3 Standard cuando los subes usando uploads multiparte». Aterriza siempre en Standard (o completa el upload multiparte pronto) y deja que el ciclo de vida haga la transición.

Dos trampas de forma de petición que vale la pena memorizar: las peticiones SSE-KMS deben llegar por TLS con SigV4, y no debes enviar cabeceras de cifrado en GET/HEAD: S3 responde HTTP 400.

---

7. Buckets, prefijos y claves de partición: el modelo de rendimiento

7.1 S3 escala por prefijo, no por bucket

La documentación de rendimiento de S3 enuncia el modelo exactamente: «tu aplicación puede lograr al menos 3,500 peticiones PUT/COPY/POST/DELETE o 5,500 GET/HEAD por segundo por prefijo particionado de Amazon S3. No hay límite al número de prefijos en un bucket… si creas 10 prefijos… podrías escalar tu rendimiento de lectura a 55,000 peticiones de lectura por segundo» (consultada en oct 2026). El escalado es gradual, y los clientes ven errores de 503 Slow Down mientras sube.

El incidente compuesto que el material del laboratorio de Well-Architected de AWS describe coincide con esta forma: un job de ingesta de streaming escribía 800 objetos pequeños/segundo en s3://lake-prod/raw/events/2026-10-11/events.json.gz, un solo prefijo, el rendimiento colapsó a ~3,500 escrituras/s con 503 Slow Down sostenido, y re-particionar la clave del productor a 16 prefijos shard-{000..015} restauró el margen a ~56,000 escrituras/s sin ningún otro cambio. El esparcimiento de la partición es un control de rendimiento independiente de la semántica de la partición.

7.2 Las claves de partición son el diseño físico

Para tablas al estilo Hive, el diseño de la clave es el diseño físico de la partición: s3://lake/events/dt=2026-10-11/hour=07/part-…parquet. Reglas de diseño que se sostienen en Glue, Athena, EMR y Redshift Spectrum:

• 📚 ¿Sabías que…? Las peticiones LIST no son gratis y no se precifican como GET: «Las peticiones LIST para cualquier clase de almacenamiento se cobran a la misma tarifa que las peticiones PUT, COPY y POST de S3 Standard»: $0.005 por 1,000 (página de precios de S3 y oferta de 2026-09-28). Por el contrario, las peticiones DELETE y CANCEL son gratuitas. Ese es un segundo argumento, más silencioso, para un abanico moderado de prefijos: más prefijos significan más abanico LIST/GET en escaneos de bucket completo y más metadatos de partición de Glue, así que reparte a tus particiones de tiempo reales en lugar de sintéticamente al límite.

---

8. Cerrar el lago: Block Public Access y políticas de bucket

8.1 Block Public Access es el interruptor de parada

«Por defecto, los buckets, puntos de acceso y objetos nuevos no permiten acceso público.» Encima de ese por defecto, S3 Block Public Access proporciona cuatro ajustes, BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy y RestrictPublicBuckets, y «si los ajustes de bloqueo de acceso público… difieren, entonces Amazon S3 aplica la combinación más restrictiva» (guía de usuario de S3, consultada en oct 2026).

La recomendación de AWS para una cuenta de lago es inequívoca: «recomendamos que actives los cuatro ajustes… para tu cuenta». Recuerda la trampa de capas: deshabilitar BPA en un bucket no hace nada si la cuenta u organización todavía bloquea, y S3 siempre aplica la combinación más restrictiva. «Público» significa una ACL o política que concede a AllUsers/AuthenticatedUsers, o una política de bucket con un principal comodín no restringido por un aws:PrincipalArn, aws:PrincipalOrgID, aws:SourceAccount, aws:SourceArn, aws:SourceVpc, aws:SourceVpce, aws:SourceIp o s3:DataAccessPointArn fijo.

8.2 Ocho patrones de política de bucket para un lago privado

Block Public Access impide que el bucket se vuelva público; la política de abajo impide todo lo demás que un data lake realmente necesita rechazar. Una declaración Deny con "Principal": "*" restringe el acceso en lugar de concederlo, así que se compone limpiamente con los cuatro ajustes de BPA activados.

Notas sobre el JSON, porque cada declaración codifica una regla que es fácil de entender mal de forma sutil:

• Una condición por declaración para las comprobaciones SSE-KMS. Una sola declaración con dos claves StringNotEquals solo se aplica cuando ambas condiciones coinciden, lo que dejaría pasar una petición con la cabecera de cifrado correcta pero la clave equivocada. Dos declaraciones = dos negaciones independientes.
• La declaración 2 sola está incompleta sin la declaración 3: fijar el algoritmo no fija la clave, y una clave sin fijar es un radio de explosión sin fijar.
• La lista completa de patrones para un lago (docs de política de bucket y claves de condición de S3, consultados en oct 2026): (1) denegar no-TLS; (2) denegar PutObject salvo SSE-KMS; (3) fijar el ARN de la CMK; (4) denegar DeleteObjectVersion fuera del rol de retención; (5) concesiones limitadas por prefijo como arn:aws:s3:lakehouse-prod/raw/* para roles de ingeniería; (6) anclaje de Región con aws:RequestedRegion; (7) anclaje de organización con aws:PrincipalOrgID; (8) restricciones de fuente de principal de servicio (aws:SourceArn + aws:SourceAccount) para Lake Formation, Glue, Athena y Macie: más topes de retención vía s3:object-lock-remaining-retention-days.

---

9. La tubería de gobernanza: S3 Inventory y S3 Batch Operations

Las reglas de ciclo de vida y la replicación en vivo cubren el movimiento hacia adelante. Dos servicios cubren todo lo demás, y ambos son lo bastante baratos que omitirlos es una falsa economía.

9.1 S3 Inventory: la instantánea programada de metadatos

S3 Inventory produce «archivos de salida de valores separados por comas (CSV), Apache optimized row columnar (ORC) o Apache Parquet que listan tus objetos y sus metadatos correspondientes sobre una base diaria o semanal» (guía de usuario de S3, consultada en oct 2026). Las propiedades que importan para un lago:

Esa lista de campos es un pipeline de auditoría: quién está bloqueado, hasta cuándo, en qué nivel, replicado o no: consultable en Athena, sin una sola llamada ListObjectsV2 al bucket en vivo.

9.2 S3 Batch Operations: gobernanza retroactiva

S3 Batch Operations es dirigido por manifiesto: construye el manifiesto desde un informe de S3 Inventory, elige una operación, paga por job y por objeto. Lista us-east-1, en oct 2026: $0.25 por job y $1.00 por millón de objetos procesados (oferta de 2026-09-28).

Las operaciones que el ciclo de vida y la replicación en vivo no pueden hacer:

• Aplicar retroactivamente retención de Object Lock o holds legales a millones de objetos preexistentes;
• Restaurar millones de objetos de Glacier (la única manera sensata de ejecutar una recuperación masiva como E2 a escala);
• Batch Replication para backfill de objetos que son anteriores a la configuración de replicación;
• Aplicar SSE-KMS en masa después de un cambio de política de clave;
• Copiar, etiquetar, actualizar ACLs, o invocar una función Lambda por objeto.

El patrón a internalizar: Inventory es el lado de lectura (qué tenemos, en qué estado), Batch Operations es el lado de escritura (cambiar todo ello, una vez), y el ciclo de vida es la orden permanente (seguir haciendo esto a medida que envejecen los objetos). S3 Select, por cierto, no forma parte de este kit para diseños nuevos: AWS lo cerró a nuevos clientes el 25 de julio de 2024 y documenta Athena como el enfoque recomendado para la consulta de data lakes (AWS Storage Blog, 2024-07-25).

---

10. Matemáticas de coste de ciclo de vida: TCO de Deep Archive y la trampa de Intelligent-Tiering

10.1 Ejemplo resuelto E5, el titular: TCO de 7 años con una cascada de ciclo de vida

Un lago de cumplimiento mantiene 100 TiB (102,400 GB) de Parquet promediando 256 MB por objeto (≈409,600 objetos), escrito una vez, consultado durante 90 días, y luego archivado durante 7 años. Todos los precios son lista us-east-1, en oct 2026.

El ahorro de ~$185,000 es real, y es condicional a exactamente tres cosas: los datos permanecen genuinamente ≥180 días en Deep Archive (de lo contrario la duración mínima te factura de todos modos), un SLA de restore de 12 horas / 48 horas es aceptable, y los objetos son lo bastante grandes que el sobrecosto de 40 KB de metadatos se mantiene como un error de redondeo (lo es: ~$0.08/mes sobre 409,600 objetos). Falla cualquiera de los tres y el modelo se rompe, y por eso existe la sección 10.4.

10.2 Ejemplo resuelto E6: punto de equilibrio de Intelligent-Tiering

La misma pregunta que hace todo lago: 10 TiB (10,240 GB), acceso desconocido, 200 millones de objetos. ¿Debe ser Intelligent-Tiering, o una clase explícita?

10.3 Ejemplo resuelto E7: la trampa de metadatos de archivo de 40 KB

Cada objeto movido a Glacier Flexible Retrieval o Glacier Deep Archive lleva 40 KB de metadatos adicionales: «32 KB… cobrados a la tarifa por defecto para esa clase de almacenamiento» más «8 KB adicionales… cobrados a la tarifa de S3 Standard» (docs de almacenamiento de archivo de S3, consultados en oct 2026). En archivos Parquet de 256 MB eso es invisible. En un lago de archivos JSON pequeños es la factura.

10.4 La trampa de la cuota de monitoreo de Intelligent-Tiering

Una segunda trampa, más silenciosa, de la misma familia: los uploads multiparte a clases de Glacier se facturan a tarifas de almacenamiento de S3 Standard hasta que cada parte se completa y S3 aplica la clase real. Aterriza en Standard (o termina el upload pronto) y deja que el ciclo de vida transicione el objeto completado.

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

Caso A, Nasdaq: consulta en el lugar, con una salida de cumplimiento

Nasdaq (operador de bolsas, servicios financieros). Tal como describe el case study de AWS (página del año 2020, consultada en oct 2026), Nasdaq migró a Amazon Redshift en 2014, hizo crecer un clúster hasta 70 nodos para 2018, e ingería 30 to 55 mil millones de registros, más de 4 TB, cada noche desde miles de fuentes. La contención entre carga y consulta en el warehouse era la restricción. La solución fue el patrón que este curso llama lakehouse: un data lake de 15 TB en Amazon S3 consultable en el lugar vía Redshift Spectrum, que el propio Nasdaq llama «lake house architecture». AWS informa consultas de Redshift «32 por ciento más rápidas» y un 90% de finalización de carga de datos 5 horas antes, y un AWS Data Lab de enero de 2019 (cuatro días) soportó el salto «de 30 mil millones de registros a 70 mil millones de registros al día».

La razón por la que Nasdaq aparece en esta lección es la salida, no la aceleración: AWS posiciona el lago S3 con Glacier y Object Lock como el nivel de archivo/cumplimiento junto a los datos calientes consultables. Ese es el árbol de decisión de clases de almacenamiento hecho real: las ventanas recientes permanecen en S3 Standard para que Spectrum y Redshift escaneen, y la cola regulatoria de varios años es un archivo gestionado con ciclo de vida y bloqueado con Object Lock. El ángulo de la lección: el archivo es una decisión de retención con un SLA de restore adjunto, exactamente como en el ejemplo resuelto E5.

Resultados informados por el cliente de una página de AWS sin fecha; no es un compromiso de AWS. Ponles fecha: tal como AWS lo informó en 2020.

Caso B, Siemens: 5 to 7 TB al día, y logs de acceso de servidor S3 como rastro de auditoría

Siemens (manufactura industrial y tecnología; Cloud Security Operations). Según el case study de AWS (página sin fecha, consultada en oct 2026), Siemens gobierna más de 800 cuentas de AWS y onboardea 5 to 7 TB/día de datos de seguridad en Amazon Security Lake, reenviando solo 600 GB en adelante a Splunk, una reducción de volumen del 90%, para unos $1.3 millones de ahorro anual informados. El onboarding de logs nuevos bajó de «varias semanas» a 1 to 2 días, y el tiempo de identificación de causa raíz bajó 75%. Una investigación identificó los datos S3 afectados en 10 minutos frente a varios días.

El detalle relevante para la lección está en la lista de fuentes onboardeadas: VPC Flow Logs, logs de acceso de servidor S3 y logs de AWS WAF. El logging de acceso de servidor S3 es la propia caja negra del lago, cada petición registrada, en el lago, a tarifas de Standard, y es el complemento nativo de S3 para los eventos de datos S3 de CloudTrail. Observa la trampa de nombre de la que el propio AWS advierte: Amazon Security Lake es un servicio de agregación de logs de seguridad sobre S3; no es AWS Lake Formation, que gobierna permisos (lección 12).

---

Preguntas de Práctica (Practice Questions)