Módulo 1: What Is Sre And Reliability As A Feature
5. Dos incidentes reales, dos preguntas distintas
Descripción
Si viniste de terraform-and-iac-guide, cicd-and-gitops-on-aws-guide o cloud-security-and-guardrails-guide, esta es la cuarta vez que te encuentras con el mismo incidente: un agente de Claude Code corrió terraform destroy contra la infraestructura de producción de DataTalks.Club y borró 2,5 años de datos. Esta lección no lo vuelve a narrar desde cero para generar alarma otra vez —eso ya lo hicieron tres guías, cada una con su propio ángulo— la retoma con la pregunta que ninguna de las tres hizo todavía, porque ninguna de las tres tenía, hasta esta guía, el vocabulario para hacerla: ¿qué hubiera dicho un error budget de esto? Junto a ese caso, esta lección nombra —sin operarlo a fondo— un segundo incidente real, de una naturaleza completamente distinta: el outage de us-east-1 de octubre de 2025, un fallo que no tuvo nada que ver con un comando mal aprobado.
Conexión con el módulo
La lección 3 te dio el vocabulario del error budget. La lección 4 identificó, en el inventario real de Andes Cargo, que todo el sistema vive en una sola región —exactamente el tipo de exposición que el segundo caso de esta lección hace tangible—. Esta lección conecta ambas piezas con los dos incidentes reales que sostienen el resto de esta guía, y deja planteada la pregunta que la lección 6 contesta con un número real.
El primer caso, en las cifras exactas que ya conoces (recapitulado, no repetido)
Alexey Grigorev, fundador de DataTalks.Club —la plataforma de cursos gratuitos—, usaba Claude Code para migrar un sitio estático hacia la infraestructura de Terraform ya existente de la plataforma, reutilizando el mismo proyecto en vez de crear uno separado, para ahorrar entre cinco y diez dólares mensuales de infraestructura duplicada. El agente reemplazó el terraform.tfstate activo por una versión vieja, extraída de un .zip archivado. Con ese state desactualizado como referencia, interpretó buena parte de la infraestructura de producción real como recursos huérfanos, y corrió terraform destroy -auto-approve. El resultado: la VPC completa, el clúster de ECS, los balanceadores de carga, el bastion host, la base de datos RDS y sus snapshots automáticos, todos borrados. 2,5 años de datos de la plataforma desaparecieron con un solo comando; la tabla courses_answer, una de las afectadas, tenía 1.943.200 filas. La recuperación tomó cerca de 24 horas de trabajo con soporte empresarial de AWS, hasta encontrar un snapshot interno que ni siquiera aparecía listado en la consola. El detalle que ya conoces, si viniste de las guías hermanas: Claude Code había señalado el riesgo del destroy antes de ejecutarlo, y el humano al mando lo aprobó de todas formas.
Fecha exacta, verificada contra la fuente primaria de Grigorev: 26 de febrero de 2026. Si viniste de terraform-and-iac-guide o cicd-and-gitops-on-aws-guide, sus DISEÑO.md originales mencionaban "marzo de 2026" — una discrepancia corregida en las lecciones ya escritas de esas guías, y en el diseño de esta.
El ángulo nuevo: ¿qué hubiera dicho un error budget de esto?
terraform-and-iac-guide (Módulo 8, lección 5) contestó "¿qué pasó, y qué regla evita que vuelva a pasar?" — la disciplina de leer el plan completo. cloud-security-and-guardrails-guide (Módulo 1, lección 6) contestó "¿qué control automatizado lo hubiera detenido?" — la respuesta más directa: conftest evaluando el plan antes del apply, bloqueando sin depender de la atención humana. Ninguna de las dos preguntas es la de esta guía, y vale la pena decir con precisión por qué: un error budget no es un control preventivo. No hubiera bloqueado el destroy —esa función la cumple conftest, no una calculadora de error budget—. Lo que un error budget hace, que ningún control preventivo hace, es convertir el daño ya ocurrido en un número inmediato y objetivo, sin necesitar reconstruir toda la historia para que alguien entienda la magnitud.
Piénsalo así: si DataTalks.Club hubiera tenido, antes del incidente, un SLO mensual definido para su plataforma —cualquier número razonable, no necesariamente 99,9%— y alguien preguntara, el mismo día del incidente, "¿qué tan grave fue esto, en términos que el negocio entienda?", la respuesta con un error budget no sería una narración de 24 horas de trabajo con soporte de AWS. Sería un múltiplo: "esto consumió X veces el presupuesto de indisponibilidad de todo el mes, en un solo evento." La lección 6 de este módulo calcula ese múltiplo exacto, a mano, con la aritmética completa a la vista — y el resultado no es "un poco más de lo esperado". Es un número que, sin necesitar ningún contexto adicional, comunica de inmediato que esto no fue un mal día — fue un evento que se comió, muchas veces, todo el margen de un mes entero.
La honestidad que esta sección no puede saltarse: un error budget mide después de que algo pasó. No es un sustituto de conftest, ni de leer el plan, ni de ninguna de las salvaguardas preventivas que las guías hermanas ya construyeron. Es un instrumento distinto, que responde una pregunta distinta —no "¿cómo lo evitamos?", sino "¿qué tan grave fue, en un número que cualquiera pueda entender sin haber vivido las 24 horas?"—, y esa pregunta, hasta esta guía, ningún módulo de este ecosistema la había contestado con aritmética real.
El segundo caso, nombrado por contraste: el outage de us-east-1, octubre de 2025
Si el incidente de DataTalks.Club es un caso de causa dentro del sistema —un comando aprobado sin la atención suficiente, sobre infraestructura que el propio equipo controlaba—, este segundo caso es la categoría opuesta: un fallo que ocurrió por completo fuera del control de cualquier equipo cuya infraestructura viviera en la región afectada, sin que ningún conftest, ninguna política, ninguna disciplina de revisión de plan hubiera podido hacer nada al respecto.
El 19 y 20 de octubre de 2025, la región us-east-1 de AWS —la misma región donde vive, hoy, cada recurso de Andes Cargo, confirmado en la lección 4 de este módulo— sufrió una interrupción de aproximadamente 15 horas, con impacto en decenas de servicios de AWS y en miles de aplicaciones que dependían de ella en todo internet. La causa raíz, según la cobertura técnica verificada del incidente: una race condition en el sistema automatizado de gestión de DNS de DynamoDB, entre dos componentes internos —un DNS Planner, que monitorea el estado de los balanceadores de carga, y un DNS Enactor, que aplica los cambios de DNS a través de Route 53—. En algún momento, mientras un Enactor experimentaba una demora, otro Enactor comenzó un proceso de limpieza que eliminó un plan de DNS que en realidad todavía era válido, borrando de golpe todas las direcciones IP del endpoint regional de DynamoDB. Esa falla se propagó en cascada: servicios que dependen de DynamoDB internamente —incluidos EC2, Lambda, ECS, EKS y Fargate— empezaron a fallar también, sin que ninguno de esos servicios tuviera, por sí mismo, ningún problema técnico propio.
DOS INCIDENTES, DOS ORÍGENES COMPLETAMENTE DISTINTOS
CAUSA DENTRO DEL SISTEMA CAUSA FUERA DEL SISTEMA
(DataTalks.Club, feb 2026) (us-east-1, oct 2025)
Un agente con acceso legítimo Una race condition interna
corre un comando destructivo de AWS, en su propia
sobre infraestructura que el automatización de DNS
equipo controla directamente para DynamoDB
│ │
▼ ▼
Prevenible con disciplina y NO prevenible por ningún
controles propios: leer el plan, control del lado del cliente
`conftest`, `prevent_destroy` — la causa vive dentro de
(Módulos 2 y 4 de AWS mismo, no en
`cloud-security-and- `andes-cargo-infra/`
guardrails-guide`)
│ │
▼ ▼
La pregunta correcta: "¿qué La pregunta correcta: "¿qué
controles nuestros fallaron?" hacemos cuando el proveedor
mismo falla, y la causa
no es nuestra en absoluto?"Por qué esta guía nombra este caso, pero no lo opera a fondo como el de DataTalks.Club. Tres razones honestas, no una excusa: primero, este caso no le ocurrió a Andes Cargo ni a ningún proyecto de este ecosistema —es un caso de mercado citado, no un incidente con datos propios verificados por tres guías hermanas, como sí lo tiene el incidente Claude Code—. Segundo, la respuesta real a "¿qué hacemos cuando us-east-1 completo falla?" es arquitectura multi-región —failover activo entre regiones, réplicas de datos en tiempo real—, algo que está, por diseño, fuera del alcance $0 y de una sola región de esta guía y de todo este ecosistema. Tercero, y más importante: la disciplina que este caso exige —SLI, SLO, error budget, un ciclo de vida de incidente con roles y comunicación— es exactamente la misma que la guía ya construye con el caso de DataTalks.Club. La diferencia no está en las herramientas de respuesta, está en la causa raíz, y la causa raíz de este segundo caso simplemente no admite una solución de $0.
src/paths/aws-cloud-ecosystem/VALIDACION.md es preciso sobre por qué este caso importa para el mercado, más allá de si Andes Cargo puede operarlo a fondo: "el caso de estudio obligatorio ya existe: el outage de us-east-1 (oct-2025, 2.057 comentarios en HN) fue una race condition de DNS entre el Planner y el Enactor, sin versionado ni compare-and-swap — no un problema de capacidad". Es, en los hechos, el segundo incidente de referencia que cualquier conversación seria de SRE en 2026 necesita poder nombrar con precisión técnica, no solo como "AWS se cayó ese día".
Errores comunes
Buscar, en el segundo caso, una lección operativa que esta guía no construye (de expectativa). Qué pasa: alguien termina esta lección esperando que un módulo posterior enseñe a configurar failover multi-región para Andes Cargo, o algún mecanismo que hubiera protegido contra el outage de us-east-1. Cómo detectarlo: si buscas, en el resto de esta guía, algún recurso HCL de replicación entre regiones. Cómo corregirlo: este caso se nombra, con precisión técnica, para que puedas reconocerlo y explicarlo en una conversación real —una entrevista, una discusión de arquitectura— pero esta guía, honesta sobre su alcance $0 declarado desde la lección 1, no construye DR multi-región. Es exactamente la misma disciplina que finops-and-cost-guardrails-guide aplicó a Cost Explorer: nombrar con precisión un límite real, no fingir una solución que el alcance de la guía no permite.
Concluir que un error budget hubiera evitado el incidente de DataTalks.Club (de confusión de función). Qué pasa: alguien, después de leer la sección del ángulo nuevo de esta lección, cree que si DataTalks.Club hubiera tenido un error budget calculado de antemano, el destroy nunca se habría ejecutado. Cómo detectarlo: si tu resumen de esta lección es "un error budget habría prevenido esto". Cómo corregirlo: esta lección fue explícita en el punto contrario — un error budget mide, no previene. La pieza preventiva de este ecosistema ya existe, y vive en cloud-security-and-guardrails-guide (conftest, prevent_destroy). Lo que un error budget aporta, que esos controles preventivos no aportan, es la capacidad de cuantificar el daño después de que algo pasó, con un número inmediato — un instrumento distinto, no una versión mejor del mismo instrumento.
Tratar los dos casos como si tuvieran la misma causa raíz solo porque ambos afectan disponibilidad (de simplificación). Qué pasa: alguien agrupa ambos incidentes bajo la etiqueta genérica "cosas que pueden salir mal en AWS", sin distinguir que uno tiene una causa completamente controlable (un comando humano/agente mal aprobado) y el otro una causa completamente fuera del control del cliente (una falla interna de AWS). Cómo detectarlo: si tu explicación de "qué hacer para que no vuelva a pasar" es la misma para ambos casos. Cómo corregirlo: el diagrama de esta lección existe exactamente para esta distinción — la pregunta correcta frente al primer caso es "¿qué controles nuestros fallaron?"; frente al segundo, es "¿qué hacemos cuando el proveedor mismo falla, y la causa no es nuestra en absoluto?". Son preguntas distintas, con respuestas de ingeniería distintas, aunque ambas terminen midiéndose con el mismo vocabulario de SLI/SLO/error budget.
Ejercicios
Ejercicio 1 — Explica, sin usar la palabra "prevenir", qué aporta un error budget al caso de DataTalks.Club. Un compañero pregunta para qué sirve calcular un error budget sobre un incidente que ya pasó, si de todas formas no puede deshacer el daño. Responde con la función real que esta lección estableció.
Ver solución
Un error budget, aplicado después de un incidente, convierte una narración larga y compleja (24 horas de trabajo con soporte de AWS, un state corrupto, un snapshot no listado en consola) en un número único, objetivo y comparable: cuántas veces el presupuesto mensual completo de indisponibilidad se consumió en ese solo evento. Ese número le permite a cualquier persona —técnica o no— entender la magnitud real del incidente sin necesitar reconstruir la historia completa, y le da al equipo una base objetiva para decidir qué tan urgente es invertir en salvaguardas adicionales. No deshace el daño ni evita que vuelva a pasar —esa es la función de conftest y de las políticas preventivas—, pero mide el daño con una precisión que ninguna narración cualitativa logra igual.
Ejercicio 2 — Clasifica un incidente hipotético usando el diagrama de esta lección. Si un ingeniero de Andes Cargo, por error, corriera awslocal dynamodb delete-table --table-name Shipments en un entorno de producción real (no LocalStack) sin ninguna confirmación adicional, ¿ese incidente pertenece a la categoría "causa dentro del sistema" o "causa fuera del sistema"? Justifica con el criterio del diagrama.
Ver solución
Causa dentro del sistema, igual que el caso de DataTalks.Club. El criterio del diagrama no es "¿hubo un comando destructivo involucrado?" —los dos casos de esta lección lo tienen en algún punto—, es "¿la causa raíz está dentro del control directo del equipo, o depende de la infraestructura interna de AWS mismo?". Un delete-table corrido por un ingeniero (o un agente) de Andes Cargo, sin ninguna salvaguarda de por medio, es un error de disciplina propia —exactamente el tipo de fallo que conftest, la lectura del plan, o deletion protection podrían haber detenido—, no una falla de infraestructura de AWS fuera del control de nadie.
Ejercicio 3 — Explica por qué esta guía nombra el outage de us-east-1 en vez de ignorarlo, a pesar de no poder operarlo con las herramientas $0 de este ecosistema. Usando la cita de VALIDACION.md de esta lección, argumenta por qué omitir este caso sería una decisión de diseño peor que nombrarlo con honestidad sobre su alcance.
Ver solución
VALIDACION.md es explícito: este outage es "el caso de estudio obligatorio" que ninguno de los 18 temarios de competencia analizados cubre con precisión técnica —la mayoría lo trata, cuando lo menciona, como "AWS se cayó ese día", sin nombrar la causa raíz real (la race condition de DNS entre el Planner y el Enactor). Omitirlo por completo dejaría a quien complete esta guía sin poder participar, con credibilidad técnica, en una conversación de mercado donde este caso ya es una referencia estándar. Nombrarlo con precisión —la causa exacta, la duración, el alcance— sin fingir que esta guía construye una solución multi-región que está fuera de su alcance $0 declarado, es la misma disciplina de honestidad que sostiene cada caso representativo de este ecosistema: mejor un límite declarado con precisión que una omisión silenciosa o una promesa que la guía no puede cumplir.
Resumen y siguiente paso
En esta lección retomaste el incidente Claude Code destroy con un ángulo que ninguna de las tres guías hermanas usó todavía: qué aporta un error budget —no como control preventivo, sino como instrumento de medición inmediata y objetiva del daño ya ocurrido—. Nombraste, por contraste, el segundo caso de referencia obligatorio del mercado de 2026: el outage de us-east-1 de octubre de 2025, causado por una race condition de DNS entre el DNS Planner y el DNS Enactor de DynamoDB, con ~15 horas de impacto — un caso de causa completamente distinta al de DataTalks.Club, citado con precisión técnica pero no operado a fondo, por las tres razones honestas de esta lección.
Antes de avanzar deberías poder: explicar qué aporta un error budget al caso de DataTalks.Club sin decir que lo "previene"; nombrar la causa raíz técnica exacta del outage de us-east-1 (la race condition de DNS); y distinguir, con el diagrama de esta lección, cuándo un incidente tiene causa dentro del sistema y cuándo la tiene fuera.
La lección 6 hace lo que esta lección solo prometió: el cálculo real, a mano, de cuántas veces el presupuesto mensual de error se consumió en las 24 horas de recuperación del incidente Claude Code.
Recursos
- Alexey Grigorev — How I Dropped Our Production Database — el relato de primera mano del propio afectado; fuente primaria de las cifras exactas y de la fecha (26 de febrero de 2026), verificada para esta lección.
- Hacker News — hilo original del incidente Claude Code (#47278720) — la discusión pública que sacó el caso a la luz.
- incidentdatabase.ai — Incident 1424 — el registro estructurado e independiente del incidente Claude Code.
- The Register — A single DNS race condition brought AWS to its knees — cobertura técnica verificada del outage de
us-east-1, causa raíz y alcance, citada en esta lección. src/paths/aws-cloud-ecosystem/VALIDACION.md— la fuente de la cita sobre el outage deus-east-1como caso de estudio obligatorio del mercado.terraform-and-iac-guide, Módulo 8, lección 5;cloud-security-and-guardrails-guide, Módulo 1, lección 6 — las dos narraciones previas del incidente Claude Code en este ecosistema, que esta lección no repite sino que reencuadra con el vocabulario de error budget.