Volví a AWS y recordé por qué me fui

• Aunque apoyé a AWS desde el principio, con el tiempo se fueron acumulando motivos por los que dejé de apreciarlo: el período en que dejó las bibliotecas cliente en manos de la comunidad, la demora en la transición a Python 3, la facturación compleja y IAM, y el lock-in de AWS Lambda
• Después de usar DynamoDB, terminé con un cobro de 75 dólares en un solo día; aunque el costo de salida de datos bajó de 20 centavos por GB a 9 centavos, sigo considerando que el esquema, que incluso cobra por mover datos dentro de la propia infraestructura, es caro y difícil de entender
• Tras dejar AWS, cerré la mayoría de mis cuentas, pero mantuve los dominios en Route53, algunos respaldos en S3 y AWS WorkMail; más tarde recibí un aviso de que WorkMail será descontinuado dentro de los próximos 12 meses
• Hace poco volví a iniciar sesión en AWS para probar cómo funcionaba Claude/Anthropic en AWS Bedrock y para hacer pruebas con EC2 Spot de 192 núcleos y 1 TB de RAM; concluí que Bedrock funciona igual, pero es más lento y mucho más caro que una suscripción a Anthropic
• Durante una prueba de unas 3 horas con EC2 Spot, tras una alerta de Suspected security breach, mi cuenta quedó restringida y se bloquearon tanto el correo empresarial en WorkMail como la creación de recursos; incluso después de seguir los pasos indicados y contactar al soporte por chat, la restricción no se levantó durante 4 días, así que decidí migrar también AWS WorkMail y Route53

---

Del apoyo inicial a AWS al alejamiento

• Apoyé con fuerza a AWS desde la época en que era un conjunto más pequeño de servicios centrado en SQS, S3, EC2 y SimpleDB, e incluso organicé en Melbourne uno de los primeros eventos donde un representante de AWS de Estados Unidos vino a darlo a conocer
• La computación en la nube fue un cambio enorme porque permitió a las startups poner en marcha sus propios sistemas informáticos en minutos, sin tener que instalar y operar infraestructura en un centro de datos
• Durante unos 15 años confié mucho en AWS, pero con el tiempo se fueron acumulando elementos incómodos y llegó un momento en que simplemente dejó de gustarme

Quejas sobre AWS que se fueron acumulando con el tiempo

• Bibliotecas cliente y transición de Python

  • Durante sus primeros 6 años, AWS no creó sus propias bibliotecas cliente y dejó que la comunidad implementara librerías para lenguajes como Python, algo que se percibió como trasladar la carga a programadores que invertían su tiempo gratis
  • También quedó como una gran molestia el tiempo excesivo que AWS tardó en pasar de Python 2 a Python 3

• DynamoDB y la experiencia con los costos

  • Después de usar DynamoDB, al terminar el día apareció un cobro de 75 dólares; no solo por el costo, sino porque el propio sistema se sintió como la peor forma imaginable de hacer las cosas

• Costos de transferencia de datos y facturación compleja

  • El costo de salida de datos de AWS era antes de 20 centavos por GB, y luego bajó hasta 9 centavos por GB, pero aun así se considera muy caro
  • También se cobra por mover datos entre sistemas dentro de AWS y, según el caso, la estructura puede sentirse como una doble o triple facturación, por lo que es difícil evitar trampas de cobro si no se entiende a fondo

• IAM y la complejidad general

  • IAM es el sistema que maneja la autenticación y las reglas de acceso, pero se percibe como una estructura excesivamente compleja
  • Quienes defienden AWS suelen decir que hay que usarlo porque operar Linux, hardware, redes y seguridad por cuenta propia es demasiado complejo, pero aquí se considera que casi todas las áreas de AWS también tienen una complejidad enorme y que al final igualmente se necesita un costoso equipo de especialistas

• AWS Lambda y el lock-in

  • AWS Lambda presume escalabilidad, pero obligaba a aceptar tiempos de arranque lentos y una gran complejidad de desarrollo
  • Se llegó a la conclusión de que, comparado con operar un servidor web propio, no ofrecía ventajas reales y sí muchas desventajas; además, al dejar AWS, lo más difícil de revertir fue precisamente AWS Lambda
  • Usar AWS Lambda dejó la sensación de que el lock-in del proveedor sí existe y de que era una elección que obligaba a convencerse constantemente de que seguía siendo mejor

• Proyectos open source e ingresos del hosting

  • Se considera que AWS impulsó OpenSearch, Valkey y DocumentDB aun cuando proyectos como Elasticsearch, Redis y MongoDB habían dejado clara su intención de no querer que se copiara y monetizara su trabajo
  • Después de que esas comunidades y empresas construyeron el mercado, AWS se quedó con los ingresos de los servicios gestionados, y eso habría contribuido al aumento de licencias defensivas como SSPL, Elastic License y RSAL, además del modelo source-available

Algunos servicios que quedaron después de salir de AWS

• Después de perder el aprecio por AWS, saqué todo fuera de la plataforma y cerré casi todas las cuentas
• Aun así, dejé algunos servicios que en ese momento sí me parecían una solución adecuada
• Lo que quedó fue: dominios en Route53, algunos respaldos en S3 y AWS WorkMail
• Más adelante llegó el aviso de que AWS WorkMail será descontinuado dentro de los próximos 12 meses

Por qué volví por un momento a AWS

• Hace poco volví a iniciar sesión en AWS para hacer investigación y pruebas
• Quería comprobar qué tan bien funcionaba Claude/Anthropic en AWS Bedrock y, en el caso de Claude Code, concluí que funciona igual, pero más lento y mucho más caro que una suscripción a Anthropic
• El equipo más rápido que tenía en casa contaba con una CPU de 20 núcleos y 32 GB de RAM, y quería medir qué tan rápido corría el código en una máquina de 192 núcleos y 1 TB de RAM
• Hace aproximadamente un mes, la prueba con AWS Bedrock terminó sin problemas y luego apagué todo
• AWS Bedrock puede ser útil si se necesita privacidad, pero por costo no volvería a usar Claude desde AWS Bedrock

Restricción de cuenta durante la prueba con EC2 Spot

• Después ejecuté una instancia EC2 Spot de 192 núcleos y, mientras hacía una prueba de unas 3 horas, recibí un correo de AWS con el asunto “Suspected security breach of your account”
• Se considera posible que las alertas internas de seguridad de AWS se activaran porque una cuenta que estaba casi inactiva de pronto comenzó a usar recursos de cómputo costosos
• La intención de AWS de proteger al usuario se entiende y se valora positivamente
• Sin embargo, AWS suspendió o restringió la cuenta y, como resultado, dejó de funcionar la cuenta principal de correo empresarial que usaba con AWS WorkMail
• Ya nadie podía enviar correos y tampoco era posible crear ningún recurso de AWS, por lo que tampoco pude continuar la prueba que quería hacer originalmente

Respuesta del soporte y demora

• Respondí a la alerta de soporte de AWS para informar que la cuenta no había sido hackeada y que no había ningún problema ni anomalía de facturación, pero no hubo respuesta
• Como no tenía soporte premium, tuve que esperar el plazo de 24 horas que AWS indicaba, pero incluso después de 3 días no llegó ninguna respuesta del soporte
• Después de pedir ayuda en los foros de AWS, me recomendaron seguir las instrucciones del correo y usar el chat en lugar de la web
• Hice todos los pasos solicitados, como cambiar la contraseña, eliminar tokens de acceso y revisar la facturación, y después de esperar unos 30 minutos para conectarme por chat, hablé largo rato con un representante de AWS
• El representante pareció quedar conforme y dijo que pediría al equipo interno correspondiente que lo atendiera, pero incluso después de 24 horas la restricción no se levantó
• Ocho horas después, cuando hice seguimiento, solo recibí la respuesta de que debía seguir esperando

La conclusión que volvió a confirmarse

• Incluso 4 días después de que la cuenta quedara restringida, seguían pendientes tareas que quería probar en equipos grandes, y empecé a preocuparme por tener que volver a pedir una “quota” para hacerlo
• El sistema de correo empresarial seguía sin funcionar
• Esta experiencia de regreso confirmó una vez más por qué había dejado AWS, y llegué a la conclusión de que debía salir de AWS WorkMail, mover también los dominios de Route53 y no volver nunca más
• Haber sacado antes casi todo de AWS fue un gran alivio, pero el hecho de que el sistema de correo en el que había confiado y que había dejado ahí se interrumpiera precisamente durante este regreso a AWS se sintió como un fracaso
• Puede que AWS levante la restricción de la cuenta en algún momento, pero no hay forma de saber cuándo

[GN⁺]

Comentarios de Hacker News

• Hace unos años me uní a una empresa para liderar el equipo de desarrollo y me pidieron lanzar el producto en 3 meses. Cuando fui a agregar una máquina nueva en AWS, el hecho mismo de que el precio no apareciera en la UI me pareció una señal de una relación hostil y explotadora.
  Había que abrir por separado la tabla de especificaciones y la tabla de precios para compararlas, y por experiencia pasada pensé que, si veía esas señales y aun así no me iba, después el resultado sería mi responsabilidad.
  Así que creé una cuenta en DigitalOcean, migré todo y también configuré CI/CD para desplegar ahí; luego me enfoqué en el producto durante los 2 meses restantes y lo lancé 1 mes antes de lo prometido.
  Hace tiempo vi un video donde cavaban un hoyo junto a un río y lo conectaban con una tubería para que los peces entraran solos a la trampa; se me quedó muy grabada la impresión de que elegir siempre el camino de menor resistencia y no revertir los errores es la receta para terminar como esos peces.

  • Una de las cosas que me gustan de Azure es que, aunque no te restriega precios exagerados cada vez que creas un recurso, en los elementos que pueden salir caros por lo general sí muestra el precio, y ese equilibrio me parece bueno.
    Hasta ahora no me he llevado sorpresas con la facturación.
  • Tengo la impresión de que la cultura de ingeniería de Amazon es bastante una cultura de producto guiada por ingenieros, así que muchas veces los desarrolladores terminan siendo responsables también del UX y del flujo.
    Una vez contraté a un desarrollador junior que acababa de terminar una pasantía en AWS, y me mostró un dashboard que hizo solo durante el verano, sin ayuda de un PM ni de un diseñador; se veía realmente terrible.
    Algunos desarrolladores tienen buen criterio de producto/UX, pero la mayoría es bastante débil en UX, así que es más probable que no fuera algo intencional sino simplemente una mala cultura de UX.
  • La forma correcta es elegir un proveedor de infraestructura que te ayude a lanzar.
    AWS es bueno, pero no es para todo el mundo; hay un punto intermedio entre servicios como Heroku y bare metal donde se abstrae mucho del mantenimiento pero todavía te dejan cierto control sobre la arquitectura de escalado.
    Es decir, como proveedor cloud, AWS ayuda a escalar, pero no es la herramienta para armar la configuración más barata y simple.
    Si tienes financiamiento VC y tu discurso es crecimiento, AWS puede ser una apuesta segura, y gracias a los créditos de startup por 2 años vía aceleradoras, durante los primeros 18 meses puedes concentrarte más en construir que en el presupuesto de infraestructura.
    Si eres bootstrapped o indie, te conviene elegir algo simple y manejable, y con Hetzner o DigitalOcean suele bastar.
  • AWS tiene una calculadora de precios bastante decente y presets útiles, pero claro, es una app totalmente separada.
    Amazon seguramente quiere que haya algo de fricción para consultar la información de precios con facilidad, pero la razón principal parece más bien la ley de Conway.
    AWS todavía sigue exportando su organigrama como producto.
  • Estoy de acuerdo hasta cierto punto, pero el precio de AWS no es tan simple como para calcular cuánto vas a pagar con un número estático mostrado en la UI.
    Si te molesta tener que abrir 2 pestañas para comparar costos, quizá te convenga evitar no solo AWS sino cualquier proveedor cloud.
    Cuando entran NAT Gateway, CloudFront, S3, auto scaling y load balancers, calcular costos se parece más a un arte que a una ciencia exacta.
    Si no vas a usar esas cosas, en realidad hay pocas razones para usar AWS, y proveedores de VPS baratos hay muchos.

• Si hablamos solo de OpenSearch y Valkey, decir que “AWS hizo un fork y eso provocó el cambio de licencia” es exactamente al revés.
  AWS hizo el fork solo después de que el proyecto upstream cambiara la licencia, y en particular Valkey fue creado por integrantes del antiguo equipo central de Redis.

  • Muchos de estos proyectos operan con un modelo de negocio donde liberan el producto principal como open source y luego ofrecen servicios premium, instalación, mantenimiento y servicios fully managed.
    Como AWS ofreció un servicio fully managed y los dejó fuera de la ecuación, en este caso termino poniéndome del lado de quienes crearon el proyecto.
    Básicamente, AWS les quitó el pan de la mesa, y no les quedó otra que cambiar la licencia.
  • Ese cambio de licencia fue precisamente una respuesta a que AWS monetizaba su trabajo de una forma insostenible para el proyecto upstream.
  • Me pregunto qué tanto impacto tendría si Amazon pagara apenas 1 centavo por período de facturación a los creadores y mantenedores del software open source que vende.
    También me pregunto si eso significaría una cantidad razonable de dinero para los equipos open source, y si los animaría a contribuir mejoras al producto sin asumir tanto riesgo.
  • Desde que envié mi primer parche a Redis y un committer ignoró mi mensaje, metió ese parche con su propio nombre y listo, perdí gran parte de mi empatía por la filosofía de muchos proyectos open source.
    Se merecen pasar por Valkey.
    Todavía me acuerdo de JBoss y de Marc Fleury.
  • Es obvio que AWS hizo el fork solo después de que cambiaron la licencia para impedir que siguiera ganando dinero con el código de ese proyecto.
    Ese es justamente el punto.

• He ido y venido varias veces entre servicios cloud y self-hosting.
  Al principio usé Vercel y, como el proyecto era en Next.js, la experiencia estuvo bien, pero pagar 20 dólares al mes por un proyecto con menos de 100 usuarios me parecía caro para un servicio con requisitos de rendimiento bajos.
  Después armé mi propio servidor con Hetzner y Coolify; como Coolify es open source, solo pagaba el costo del VPS, y con 5 dólares al mes podía correr una instancia de PostgreSQL y un servidor web.
  Pero aun así mantener PostgreSQL y Redis seguía dando trabajo, y pasar variables del sistema y variables de entorno entre servicios, incluso dentro de contenedores Docker, era engorroso.
  Más adelante me cambié a Cloudflare Workers, D1 Database y Cloudflare KV, y como se podían invocar directamente dentro del Worker ya no hacía falta pasar variables de entorno.
  La experiencia de desarrollo local es buena y el precio también es razonable, así que desde entonces sigo usando todo el stack de Cloudflare.

  • Lo que ofrece Cloudflare se ha acercado mucho más a lo que yo quería de AWS.
    El despliegue de apps full-stack y archivos básicos es muchísimo más simple, y AWS se ha vuelto incluso mucho más difícil que self-hosting.
  • Me da curiosidad si Docker realmente te facilitó la administración de PostgreSQL.
    El único problema que suelo tener con PostgreSQL es un poco de trabajo de migración al pasar a una nueva versión mayor.
    También me pregunto si Docker hizo más difícil pasar variables del sistema y variables de entorno entre servicios.
  • Quería que me gustara Cloudflare Workers, y seguro hay buenas razones técnicas para hacerlo, pero la forma en que tienes que usar un proyecto de Wrangler para cosas como activar email me hizo sentir que estaba a un paso del lock-in de plataforma.
    Para permitir email hay que configurar los bindings necesarios, pero parecía que eso no se podía hacer desde la consola, y una vez que Wrangler lo configuraba tampoco podías verlo ahí.

• Me sorprende que al autor no le guste DynamoDB.
  Es uno de mis servicios favoritos de AWS: tiene buena disponibilidad, no requiere carga operativa y cada vez que lo he usado el costo ha sido bastante bajo.
  Eso sí, hay que dedicar tiempo a diseñar el modelo de datos de antemano, y para eso necesitas leer y entender la documentación del servicio.

  • DynamoDB es bastante bueno si lo usas como fue diseñado.
    Básicamente hay que verlo como un almacén clave-valor relativamente simple, con buena durabilidad y escalado casi infinito del tamaño de tabla; no hay que intentar usarlo como si fuera una base de datos SQL.
    La manera más fácil de generar una factura de 75 dólares con código prototipo es hacer vibe coding tratándolo como una base SQL donde usas JOIN y GROUP BY.
    Donde realmente brilla es cuando necesitas 1 o 2 tablas pequeñas para almacenamiento persistente pero no quieres administrar un RDBMS completo, o cuando quieres consultar una tabla muy grande de forma simple sin forzarla a encajar en un RDBMS.
  • Varios servicios como DynamoDB y Lambda tienen casos de uso muy específicos.
    No deberías usar un alegre almacén clave-valor como si fuera una base de datos.
  • Hace unos años, al crear una app, necesitaba una base para guardar unos 50 millones de registros, con alrededor de 10 mil lecturas+escrituras al mes y 1 índice.
    El costo de carga inicial fue de unos 50 dólares, y después el costo de mantenimiento quedó en algo así como 10 centavos al mes.

• Este tipo de textos siempre me hace reír.
  Está bien y mal al mismo tiempo, y los sistemas deben hacerse “tan simples como sea posible, pero no más simples que eso”.
  Si crees que puedes pasar por alto los detalles, luego el problema vuelve como una molestia todavía mayor.
  IAM simplemente es complejo.
  No se me ocurre ningún caso en que usuarios, grupos, roles, políticas, proveedores de identidad y OIDC se hayan implementado de forma realmente simple.
  Una vez vi a alguien oponerse a adoptar Kubernetes porque “era demasiado complejo”, y al final terminó reinventando Kubernetes de forma torpe y provisional con Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash y saliva, cuerda y chicle, además de cometer muchos errores.
  Hay funciones que crees que no necesitas hasta que al final sí las necesitas.
  Habiendo trabajado como único responsable de infraestructura en una startup, AWS me parece algo que la mayoría puede aprender, y las partes horribles por lo general se pueden evitar.
  Si no te gusta Lambda, no la uses; usa EKS, ECS o EC2.

  • Visto desde adentro, IAM tiene como miles de opciones, pero la esencia es “a qué puede acceder este rol y qué puede hacer ahí (acción + recurso)” y “quién puede acceder a este rol”.
    Visto desde 10 mil pies de altura, eso es todo.
    Lo bueno de IAM es que aplica igual hacia afuera y hacia adentro.
    Un equipo interno de AWS no tiene más acceso por defecto; si obtiene permiso para hacer algo en la cuenta de un cliente con el fin de prestar cierto servicio, es porque el cliente puso el principal del servicio en una relación de confianza de IAM para permitir ese acceso, y el cliente puede verlo y auditarlo.
    Por ejemplo, Lambda tiene un rol de Lambda, porque no querrías que el servicio Lambda leyera un bucket de S3 solo por la lógica de “somos AWS, así que tenemos acceso automático”.
    Incluso el acceso interno de AWS queda explícito para que el cliente pueda verlo y controlarlo.
  • El patrón de bloquear la adopción de “X es demasiado complejo” y luego terminar reinventando X de forma chafa es sorprendentemente común en tecnología y software.
    Algunas cosas ya son claramente un estándar, y aun así mucha gente se niega a invertir tiempo en aprenderlas bien.
  • AWS puede ser más caro que self-hosting, pero ese ahorro se vuelve pequeño frente al costo de ingeniería.
    Si un buen ingeniero de infraestructura se pasa 2 meses en una configuración de OVH “para ahorrar dinero”, eso sale más caro que lo que podrías ahorrar simplemente por no usar Fargate o RDS.

• Me pregunto cuándo va a empezar a decirse lo mismo de empresas como Anthropic u OpenAI.
  La ola actual de IA huele un poco a los primeros días de AWS, y da la impresión de que todo el mundo se está subiendo para luego darse cuenta de que acumuló una gran dependencia difícil de quitar.

• Lambda es realmente genial, y me parece la mejor forma de operar un servicio desplegable con iteración rápida sin volverte loco.
  No hace falta que te vayas full microservicios ni que partas el código en miles de millones de repositorios diminutos.
  Mientras no esperes compartir estado del servidor entre requests, puedes mover un web server estándar a Lambda.

• No trabajo en ese sector, así que AWS solo lo toco de vez en cuando para proyectos personales por diversión, y cada vez es una pesadilla.
  Lo que quiero es montar un servidor experimental para un juego de cartas, no fundar una nueva institución financiera, pero todo parece hecho con la idea de escalar infinitamente mañana mismo y dando por sentado una organización de mil personas y presupuesto de VC.
  Por suerte existen servicios como Netlify que te tapan toda esa complejidad para que no tengas que hervir el océano.
  Algún día quizá tenga que aprender de verdad IAM, VPN y quién sabe qué más, pero hasta entonces, cada vez que toco AWS siento que se me van a salir los ojos.

  • Puedes simplemente levantar un VPS crudo en EC2 o Lightsail, asignarle una IP pública y listo.
    No hace falta implementar todos los patrones enterprise.
  • Sorprende lo bien que Heroku ya había dado en el clavo, hace casi 20 años, con lo que necesitaba la mayoría de las web apps.
  • Si nunca has usado Azure, es posible que solo AWS te parezca una pesadilla.
  • Me pasé a Cloudflare y de verdad sentí que podía respirar otra vez.
    Tiene todo lo que necesito y el precio es razonable.
  • AWS apunta a enterprise, no a proyectos personales.
    En los proyectos personales al final solo importa el costo, así que no le generan ingresos significativos a AWS.

• Desde 2023, AWS se ha estado vaciando sistemáticamente de personal técnico.
  Ha sido por despidos masivos o por 2 rondas de planes de mejora de desempeño, y muchos colegas competentes de preventa o soporte ya no están en AWS.
  En cambio, a menudo veo quedarse e incluso ascender a personas con historiales laborales mucho más ambiguos.
  Cada quien usa AWS bajo su propio riesgo, y Paul Vixie no va a llegar a salvarte.

• Desde hace mucho tiempo, ElastiCache me ha parecido especialmente irritante.
  RDS sí agrega valor en escalabilidad, configuraciones razonablemente optimizadas y backups de los que ni tienes que preocuparte, así que ahí puedo entender pagar más.
  Pero ElastiCache agrega muy poco valor y el precio se siente explotador.
  Comparado con una instalación básica de Redis, es más lento, está peor optimizado, es menos estable y, mientras Redis sin configurar soporta varias DB, ElastiCache solo soporta una.
  Hay algunas mejoras de escalabilidad, pero como Redis básico le saca tanta ventaja a ElastiCache en instancias comparables, son muy pocos los casos donde esa mejora de verdad hace falta.

  • ElastiCache definitivamente es uno de esos servicios donde sí vale la pena considerar self-hosting.
    AWS no aporta tanto en términos de API o nivel de acabado, y en cambio Redis/Valkey es uno de los servicios más simples de alojar por cuenta propia.