Volví a AWS y recordé por qué me fui
(fourlightyears.blogspot.com)- Aunque apoyé a AWS desde sus inicios, dejé de apreciarlo por la acumulación de frustraciones, como su complejo sistema de cobros y la complejidad general de toda la plataforma*
- Considera que el alto costo de DynamoDB, las tarifas de egreso de hasta 9 centavos por gigabyte y los cobros dobles o triples por el movimiento interno de datos siguen siendo caros y difíciles de entender
- Volvió para probar Claude en AWS Bedrock y hacer benchmarks con una máquina de 192 núcleos, pero la actividad repentina en una cuenta inactiva generó una alerta por posible incidente de seguridad, y la cuenta quedó suspendida
- Debido a la suspensión de la cuenta, también se interrumpió AWS WorkMail para su negocio, y la cuenta no fue restaurada durante 4 días bajo el plan gratuito de soporte
- Llegó a la conclusión de que debía migrar incluso los servicios que aún mantenía en AWS y abandonarlo por completo
Del apoyo inicial a AWS al distanciamiento
- 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 organizó en Melbourne el primer evento donde un representante de AWS en EE. UU. fue a presentar la plataforma
- La computación en la nube fue un gran cambio que permitió a las startups poner en marcha sus propios sistemas informáticos en minutos, sin tener que instalar ni operar sistemas en un centro de datos
- Durante unos 15 años creyó firmemente en AWS, pero con el tiempo se fueron acumulando elementos incómodos y, en algún momento, dejó de gustarle
Molestias con AWS que se acumularon con el tiempo
-
Bibliotecas cliente y la transición a 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, lo que se percibió como trasladar esa carga a programadores que invertían su tiempo gratis
- También quedó como una gran frustración que AWS tardara demasiado en pasar de Python 2 a Python 3
-
DynamoDB y la experiencia con los costos
- El primer día usando DynamoDB recibió un cargo de 75 dólares, y no solo el costo, sino también el sistema mismo le pareció implementado de la peor manera imaginable
-
Costos de transferencia de datos y cobros complejos
- El costo de salida de datos en AWS era antes de 20 centavos por GB y luego bajó a 9 centavos por GB, pero aun así lo considera muy caro
- Incluso el movimiento de datos entre sistemas internos de AWS tiene cargos y, en algunos casos, la estructura se siente como un cobro doble o triple, por lo que es difícil evitar trampas de facturación sin entenderla a fondo
-
IAM y la complejidad general
- IAM (el sistema de autenticación y control de acceso) es extremadamente complejo
- Quienes defienden AWS dicen que hay que usarlo porque operar Linux, hardware, redes y seguridad por cuenta propia es demasiado complejo, pero 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
- Le atrajo la ventaja de que “escala”, pero los cold starts lentos y la enorme complejidad de desarrollo son un problema
- No ofrece una ventaja real frente a un servidor web propio y tiene más desventajas; además, al salir de AWS, Lambda fue la parte más difícil de desmantelar, lo que muestra un fuerte vendor lock-in
-
Proyectos de código abierto y ganancias del hosting
- Considera que AWS impulsó OpenSearch, Valkey y DocumentDB aun cuando proyectos como Elasticsearch, Redis y MongoDB habían mostrado que no querían que sus productos fueran replicados y monetizados
- Después de que esas comunidades y empresas crearon el mercado, AWS se quedó con los ingresos de los servicios hospedados, y eso, en su opinión, aumentó las licencias defensivas como SSPL, Elastic License y RSAL, además del modelo source-available
Algunos servicios que dejó después de salir de AWS
- Después de perderle el aprecio a AWS, movió casi todo fuera de la plataforma y cerró casi todas sus cuentas
- Aun así, dejó algunos servicios que en ese momento consideraba realmente adecuados
- Mantuvo los dominios en Route53, algunos respaldos en S3 y el correo empresarial en AWS WorkMail
- AWS WorkMail ya había sido notificado de que cerrará dentro de 12 meses
Por qué volvió brevemente a AWS
- Hace poco volvió a iniciar sesión en AWS para investigación y pruebas
- Quería comprobar qué tan bien funcionaba Claude/Anthropic en AWS Bedrock, y según Claude Code funciona igual, pero más lento y mucho más caro que una suscripción a Anthropic
- Su equipo doméstico más rápido tenía una CPU de 20 núcleos y 32 GB de RAM, y quería hacer benchmarks para ver qué tan rápido corría su código en una máquina con 192 núcleos y 1 TB de RAM
- Hace aproximadamente un mes, la prueba de AWS Bedrock terminó sin problemas y luego apagó todo
- AWS Bedrock puede ser útil si se necesita privacidad, pero por costo no volvería a usar Claude allí
Restricción de la cuenta durante una prueba con EC2 Spot
- Después, mientras ejecutaba una instancia EC2 Spot de 192 núcleos y hacía pruebas durante unas 3 horas, recibió un correo de AWS con el asunto “Suspected security breach of your account”
- Considera posible que las alertas internas de seguridad de AWS se hayan activado porque una cuenta que estaba casi inactiva empezó de repente a usar recursos de cómputo costosos
- Entiende y valora positivamente que AWS intente proteger a los usuarios
- Pero AWS suspendió o restringió la cuenta y, como resultado, la cuenta principal de correo de su negocio que usaba con AWS WorkMail dejó de funcionar
- Nadie podía seguir enviándole correos y tampoco podía crear ningún recurso de AWS, por lo que no pudo continuar con las pruebas que quería hacer originalmente
Respuesta del soporte y retrasos
- Respondió a la alerta de soporte de AWS para informar que la cuenta no había sido hackeada y que no había problemas ni anomalías de cobro, pero no recibió respuesta
- Como no usaba soporte premium, tuvo que esperar el plazo de respuesta de 24 horas que AWS indicaba, y aun después de 3 días no llegó ninguna respuesta del soporte
- Tras pedir ayuda en el foro de AWS, recibió la recomendación de seguir las instrucciones del correo y usar el chat en vez de la web
- Realizó todas las acciones solicitadas, como cambiar la contraseña, eliminar tokens de acceso y revisar la facturación, y después de esperar unos 30 minutos para conectarse al chat, habló durante largo rato con un representante de AWS
- El representante parecía satisfecho y dijo que pediría a un equipo interno que lo procesara, pero incluso 24 horas después la restricción no se había levantado
- Ocho horas después, cuando hizo una consulta de seguimiento, solo recibió como respuesta que debía esperar
Una conclusión que volvió a confirmarse
- Incluso 4 días después de que se restringiera la cuenta, aún tenía tareas que quería probar en equipos grandes, y ya le preocupaba tener que volver a pedir una solicitud de “quota” para hacerlo
- El sistema de correo de su negocio seguía sin funcionar
- Esta experiencia de regreso volvió a confirmar por qué se fue de AWS, y concluyó que debe salir de AWS WorkMail, mover también los dominios de Route53 y no volver jamás
- Le pareció una gran suerte haber sacado antes la mayor parte de sus cosas de AWS, pero el sistema de correo en el que había confiado y que dejó allí se interrumpió durante este regreso a AWS, causando un perjuicio real
- Puede que AWS levante la restricción de la cuenta en algún momento, pero no se sabe cuándo
1 comentarios
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.
Hasta ahora no me he llevado sorpresas con la facturación.
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.
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.
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.
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.
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.
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.
Se merecen pasar por Valkey.
Todavía me acuerdo de JBoss y de Marc Fleury.
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.
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.
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.
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.
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.
No deberías usar un alegre almacén clave-valor como si fuera una base de datos.
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 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.
Algunas cosas ya son claramente un estándar, y aun así mucha gente se niega a invertir tiempo en aprenderlas bien.
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.
No hace falta implementar todos los patrones enterprise.
Tiene todo lo que necesito y el precio es razonable.
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.
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.