44 puntos por GN⁺ 2025-10-21 | 8 comentarios | Compartir por WhatsApp
  • Esta interrupción en la región AWS US-EAST-1 se analiza no como una simple falla técnica, sino como una señal de debilitamiento organizacional por la salida de personal clave
  • La causa de la falla resultó ser, una vez más, un clásico problema de DNS, y un error en el endpoint de la API de DynamoDB provocó la caída en cadena de otros servicios
  • Al renunciar ingenieros veteranos que recordaban los patrones históricos de fallas del sistema, quedó en evidencia que la identificación del problema y la velocidad de recuperación se ralentizaron de forma notable
  • Los despidos masivos dentro de Amazon y una alta “tasa de desvinculación lamentada (69~81%)” están actuando en conjunto, poniendo en duda la estabilidad operativa de AWS
  • Esto no es una crisis por obsolescencia tecnológica, sino por ausencia de personas, y se interpreta no como un solo incidente de AWS, sino como un presagio de un deterioro sostenido de la confianza

Falla de DNS e interrupción de servicios

  • Como dice la vieja broma entre administradores de sistemas, "It's always DNS", muchos incidentes de servicio tienen siempre a un problema de DNS en el centro
  • El 20 de octubre de 2025 a las 12:11AM (PDT), se reportó un aumento repentino en la tasa de errores de los servicios de AWS en la región US-EAST-1
    • A la 1:26AM, los fallos en solicitudes al endpoint de DynamoDB comenzaron a agravarse
    • A las 2:01AM, se confirmó que la causa era un error de resolución DNS en el endpoint de la API de DynamoDB, lo que llevó a múltiples servicios dependientes a una falla en cascada
  • DynamoDB es un servicio base de la infraestructura de AWS, y si los servicios de esa región colapsan, el impacto se extiende a buena parte de internet
    • Se registraron interrupciones a gran escala en bancos, juegos, redes sociales, servicios gubernamentales y las compras en Amazon.com
  • Desde que se detectó el problema hasta que se identificó la causa pasaron 75 minutos, una respuesta inusualmente lenta si se compara con la tradición de AWS de tener una “velocidad de recuperación ejemplar”
    • Se analiza que el tiempo transcurrido entre detectar la falla e identificar la causa no se debió tanto a falta de transparencia como a falta de experiencia
    • Durante ese tiempo, la página de estado solo mostraba el mensaje “operando con normalidad”, lo que generó críticas de la comunidad

El cumplimiento de la “profecía”: las advertencias de quienes se fueron

  • Tradicionalmente, AWS presumía una capacidad de operación de infraestructura de alto nivel, al punto de que una falla en una sola región ya se convertía en noticia importante; sin embargo, cuanto mayor es la complejidad y más se repiten incidentes similares a los del pasado, más importante se vuelve la experiencia en campo
  • El exingeniero de AWS Justin Garrison advirtió al salir en 2023 que “los eventos a gran escala (LSE) están aumentando”
    • También predijo que “habría una interrupción grave en 2024”, y esta situación se presenta como una validación de esa advertencia
  • La salida en cadena de personal técnico de alto nivel dentro de AWS ha continuado,
    junto con la pérdida de conocimiento tribal acumulado durante décadas (conocimiento interno basado en la experiencia)
  • En incidentes como una falla de DNS, más que alguien que simplemente conozca la causa técnica,
    se necesita personal que recuerde si “este sistema ya había provocado un problema similar en el pasado”
    • Pero quienes conservaban esa memoria se fueron de la empresa por el rechazo a la RTO (política de regreso a la oficina) y por los despidos

Evidencia de la fuga de talento

  • Entre 2022 y 2025, más de 27,000 empleados de Amazon fueron despedidos,
    y aunque la proporción por departamento no es pública, se estima que AWS también recibió un golpe directo
  • Según documentos internos, la “tasa de desvinculación lamentada” alcanzó entre 69~81%,
    lo que significa que se fueron personas que la empresa quería retener
  • Con la explosión del descontento por la orden de regreso a la oficina (Return to Office),
    múltiples reportes indican que una gran cantidad de ingenieros veteranos y experimentados renunciaron
  • Como resultado, AWS se reconfiguró con equipos de menor costo y menos experiencia,
    debilitando gradualmente su capacidad para operar infraestructura compleja

Problema estructural: la deformación de la ‘frugalidad’

  • En el pasado, Frugality (frugalidad) era un valor central de Amazon,
    una filosofía orientada a “maximizar la eficiencia con menos recursos”
  • Pero recientemente eso se deformó hasta significar “hacerlo todo casi sin recursos”
    • Los recortes de personal han llegado al punto de dificultar incluso el mantenimiento básico
  • Este no es un problema de que la tecnología esté vieja, sino de que quienes la mantienen son nuevos

Perspectiva a futuro

  • El mercado probablemente tratará esta interrupción como algo aislado, pero la estructura del problema persiste
    • Se van personas con experiencia, la complejidad del sistema crece,
      y se forma un ciclo en el que aumenta cada vez más la posibilidad del “próximo incidente”
  • Es probable que AWS presente este caso como una “interrupción aislada y única”,
    pero si el vacío interno sigue acumulándose, el riesgo de repetir fallas masivas similares será alto
  • Como dice la expresión “chickens are coming home to roost”,
    la pérdida de capital humano, más que la tecnología, está emergiendo como el mayor riesgo para AWS

8 comentarios

 
jjw9512151 2025-10-23

Al final, en eso todos somos iguales...

 
shakespeares 2025-10-21

Es una historia que aplica en todos los mercados.
Parece que habría que tratar el know-how de la tecnología de TI de forma similar al know-how de un soldador experimentado.

 
bus710 2025-10-21

Entre los textos que vi hace poco,
me viene a la mente eso de que en Amazon es realmente muy difícil pasar del nivel Senior Engineer 2 al siguiente, por alguna razón.
Me imagino que ese tipo de retiros lamentables ocurren especialmente mucho en ese tramo.

 
botplaysdice 2025-10-23

Por otro lado, quizá arriba piensen: "Vaya... recortaron tanto y aun así lograron arreglarlo hasta este punto..."

 
tujuc 2025-10-21

En Corea, una vez que los ingenieros llegan a cierto punto, todos terminan convirtiéndose en gerentes y ahí se corta todo...
En Estados Unidos, el problema es que despiden a todos los seniors bajo el pretexto de la eficiencia...
La verdad, no es nada fácil...

 
t7vonn 2025-10-21

Ya tenemos multi-az implementado... ¿también habrá que prepararse para fallas a nivel de región..?

 
skageektp 2025-10-22

Creo que también hay que considerar si ese costo realmente es mayor que el costo de las pérdidas.

 
GN⁺ 2025-10-21
Comentarios de Hacker News
  • Entre los empleados de ingeniería y los trabajadores de almacén, ya da la impresión de que, si siguen despidiendo gente, no falta mucho para que incluso se vayan todos los que alguna vez trabajaron en esta empresa
    Por más que haya cientos de miles de candidatos a ingenieros con visa H1-B y decenas de millones de trabajadores de almacén inmigrantes indocumentados, si una empresa tan grande hace despidos masivos con rapidez, al final es inevitable que se quede sin recursos humanos
    Esto me recuerda al episodio parodia de Star Wars de Robot Chicken. Ahí, los oficiales imperiales fingían que Darth Vader les hacía un force choke y se hacían los muertos para huir y evitar que los cortaran con el sable de luz, y después volvían con otro nombre; Amazon es peor que eso. Nadie quiere volver https://www.youtube.com/watch?v=fFihTRIxCkg

    • Si soy sincero, no he visto a ningún ingeniero medianamente competente que quiera volver a trabajar en Amazon por segunda vez

    • ¿De verdad hay tantos inmigrantes indocumentados en los almacenes? Según entiendo, Amazon verifica la identidad y revisa bien la documentación; puede haber casos ocasionales de robo de identidad, pero no parece que sean tantos

    • El problema no son solo los despidos; recuerdo que, en cuanto Amazon impuso RTO de forma total, me empezaron a llover correos de reclutadores

    • Parece que existe cierto prejuicio sobre la capacidad de los ingenieros solo por tener H-1B
      Yo también trabajé antes con H-1B, y ahora regresé a India para levantar mi negocio. Soy ex-Amazon. Era un lugar duro, pero a mediados de los 90 al menos había stock options, así que valía la pena trabajar ahí
      Apuesto a que programo mejor que bastantes de los que están aquí. Además, muchas veces la gente más talentosa a mi alrededor también venía de H-1B
      No hay que prejuzgar; hay que evaluar directamente la capacidad. Subestimar a la competencia al final solo te perjudica

  • Ahora mismo, la respuesta correcta es retener a los empleados y darles las mejores herramientas para que puedan trabajar bien
    Las herramientas de desarrollo mejoran todos los días, y aunque por ahora puedes recortar personal, el efecto no será inmediato
    Es cambiar el presente por una apuesta al crecimiento futuro y a la sostenibilidad de la organización. Aunque te engañes, eso no hará mejor el downsizing

    • En la práctica, la estrategia sí parece estar funcionando. Despidieron a una cuarta parte de los principal engineers junior, la acción subió, y cuando después hubo una caída grande del servicio, la acción volvió a subir. Por ahora, su estrategia parece funcionar

    • Incluso las big tech “jóvenes” de antes ya están entrando en su etapa de vieja gran corporación al estilo IBM

    • No es que no sepan que la rotación es mala, sino que parece que desde la planeación misma del campo buscan estandarizar a toda la plantilla a un nivel promedio y convertirla en un recurso humano intercambiable
      Ya estamos en un punto donde incluso ser muy bueno en lo que haces se despacha como “cultura vaquera”

  • Me pareció bastante sospechoso que el momento en que realmente empezó la resolución de la falla coincidiera con el inicio de la jornada en la costa oeste de EE. UU.
    Antes de eso, la actualización solo decía “monitoreando, mitigación en curso”, sin información concreta

    • Hasta donde sé, la recuperación fue como a las 4 a. m. hora de Seattle. La jornada normalmente empieza a las 9, aunque quizá en hora de Nueva York sí haya arrancado como a las 6 a. m.

    • Lo que leí esta mañana en Reddit ahora se siente mucho más significativo

  • AWS sigue siendo mi nube favorita y la uso de forma muy eficiente
    Yo también he pensado alguna vez que me gustaría trabajar en AWS, pero si no tengo claro que se resolvieron ciertas preocupaciones, me lo pensaría mucho

  1. Los rumores sobre una cultura corporativa dura, y el hecho de que los managers tengan que proteger a sus empleados de esa cultura (aunque no puedan arreglar de inmediato a todo Amazon o incluso a todo el white-collar, al menos dentro de los equipos de AWS haría falta reforzar la confianza de los candidatos)
  2. Incluso para ingenieros con mucha experiencia siguen siendo obligatorias pruebas de código sin mucho sentido o entrevistas de respuestas STAR sobre los principios de liderazgo
    Si un futuro manager ni siquiera puede proteger al candidato durante ese proceso, preocupa pensar que tampoco podrá protegerlo ante problemas culturales más serios
  3. El cambio a RTO y las afirmaciones de que se manejó de una manera que no va con los principios de alto nivel
  4. Al parecer solo cuando llegas a Principal te libras de la guardia, pero aun así habría que evitar sobrecargar a los colegas y cuidar que no se generen rarezas por tener distintos horarios de sueño
    Hay una idea que hoy aplicaría a todo FAANG: hace falta seguir reforzando la percepción de que son lugares a los que la gente realmente talentosa quiere ir
    Meta se ha posicionado sobre todo con mejor paga y con lanzamientos open source y open hardware, y Google ha enfatizado la superioridad técnica y una cultura corporativa más cálida (a.k.a. cultura de formación para recién llegados, aunque hoy ya sea más formalidad que otra cosa)
    AWS ya tiene mucho talento técnico del que puede presumir, y creo que necesita invertir en atraerlo y retenerlo mejor, además de comunicar esa imagen de forma activa a la industria
  • He visto exactamente lo mismo en startups
    Después de una adquisición, suele pasar que el talento clave se va cuando sus acciones hacen vesting, o que una gran empresa los echa para poner a otra gente en su lugar
    Los que de verdad conocen la tecnología se van todos, y al final solo queda una base de código caótica e imposible de mantener que nadie sabe arreglar

  • Me encanta cómo El Reg señala con precisión el fondo real del asunto

    • Apenas ahora me di cuenta de que quien escribió el artículo es Corey Quinn, que lleva mucho tiempo escribiendo sobre AWS

    • También me gusta que quienes escriben ahí mantengan bien el ingenio y la personalidad en sus textos

    • Esta gente siempre da en el blanco con la esencia de cualquier tema

  • “Se identificó la causa hasta un endpoint de servicio específico 75 minutos después de que ocurrió el problema”
    ¿De verdad eso tardó tanto? Yo no hago desarrollo web, pero encontrar en 75 minutos dónde está el problema me parece bastante rápido
    Cuando trabajaba como ingeniero de firmware, muchas veces tardábamos semanas solo en averiguar dónde se había roto algo

    • Si en realidad es un problema que ocurre el 0.01% de las veces, no tiene ninguna correlación y desaparece al reintentar, de verdad puede tomar semanas
      Pero normalmente eso no es un incidente de alta prioridad; los accidentes realmente urgentes suelen ser reproducibles y son de esos donde algo que estaba bien hace una hora de repente explota
      En general, si se trata de un sistema crítico para el negocio bien diseñado, el diagnóstico no debería tardar más de 75 minutos. Claro, arreglarlo sí puede tomar más tiempo
      Aunque tampoco se puede decir que esos sistemas ideales sean tan comunes en la vida real

    • En una empresa normal, 75 minutos quizá no sea mucho. Pero si hablamos de la nube más grande del mundo y de una caída que paralizó buena parte de internet, es otra historia

    • En realidad, aunque en el aviso oficial dijeran “seguimos investigando”, internamente quizá ya habían inferido la causa más rápido
      Tiene sentido ser cautelosos, porque si publicas actualizaciones apresuradas puedes confundir innecesariamente a los usuarios

    • Yo diría que 75 minutos es casi velocidad de primer nivel para diagnosticar cualquier problema serio

    • Amazon es conocida por tener infraestructura de primer nivel en la industria
      Como todas las demás empresas usan la infraestructura de Amazon, se espera que tengan talento de nivel SRE capaz de detectar este tipo de incidentes realmente rápido

  • La experiencia acumulada y el know-how que va desapareciendo dentro de una organización son precisamente un valor realmente importante que ni siquiera se puede poner fácilmente en una hoja de Excel

    • ¡Pero entonces al menos habría que calcular a cuántas líneas de código equivale ese know-how, o aunque sea cuántos tokens son, para usarlo como referencia al despedir gente!
  • Cuando una organización empieza a priorizar a quienes construyen su propia marca o a la contratación de escaparate por encima de la gente realmente capaz y de los expertos de largo recorrido, el núcleo técnico que sí entiende de verdad los sistemas empieza a quedar relegado
    Cuando ese desequilibrio crece en algo como AWS, los celebridades de LinkedIn y el personal DEI de checklist terminan desplazando a los verdaderos builders, y la calidad de ejecución, la responsabilidad y la solidez técnica se van debilitando gradualmente
    A estas alturas ya empieza a quedar claro que el liderazgo de Andy Jassy no está funcionando, y puede que Wall Street no tarde en pedir formalmente un reemplazo

    • Es increíble que le echen la culpa a DEI por una caída sin una sola prueba
  • Sobre eso de que The Register es un medio respetado, en realidad da la impresión de que ellos mismos no querrían ser descritos así…