Seguir la guía oficial de AWS Amplify terminó en un cobro de $1,100

• Tras probar con la guía oficial de integración con OpenSearch de AWS Amplify, el costo de Amazon OpenSearch Service subió hasta $1,124.88 en un mes, aun sin un uso elevado
• El costo se acumuló porque el dominio de OpenSearch creado por npx ampx sandbox seguía existiendo incluso después de cerrar o eliminar el sandbox, y en cada nueva ejecución se agregaba otro dominio
• La configuración oficial crea por defecto una instancia r5.large.search, y ese valor base de al menos $134 al mes no quedaba visible en el código boilerplate ni en la guía
• AWS Support otorgó un crédito único por OpenSearch y almacenamiento, y pidió configurar AWS Budgets para evitar que vuelva a ocurrir
• Si usas Amplify junto con OpenSearch, conviene revisar manualmente los recursos que quedan tras borrar el sandbox y también el tipo de instancia predeterminado para evitar cargos inesperados

---

Cargos inesperados de OpenSearch

• Después de seguir la guía oficial de integración con OpenSearch en AWS Amplify, unas semanas más tarde llegó una factura de AWS de más de $1,200
• El servicio identificado en el caso con Support fue Amazon OpenSearch Service, y el total mensual fue de $1,124.88
• Ya había usado Amplify y OpenSearch en 2020, y para uso personal normalmente costaba alrededor de $50 al mes; caro, pero no al nivel de $1,200
• Tras una revisión detallada, AWS Customer Support aplicó un ajuste de facturación como one time courtesy por los costos inesperados
• Durante el proceso con Support se otorgaron créditos para OpenSearch y almacenamiento, y también se pidió configurar AWS Budgets
  • AWS Budgets permite prever el gasto futuro de un servicio específico o de toda la cuenta de AWS, y enviar alertas si se espera que se supere el presupuesto

Recursos que crea la guía oficial

• El quickstart de Amplify crea una app de juguete para notas TODO con código provisto por AWS, y Amplify genera una base de datos DynamoDB y solicitudes CRUD autenticadas
• También es posible ejecutarlo en local, pero Amplify crea además un dominio accesible
• En la etapa de configuración de OpenSearch se escribe boilerplate en TypeScript para declarar los recursos de Amplify
  • Se toma la tabla de DynamoDB como variable para referenciarla en el pipeline
  • Se crean la instancia de OpenSearch, el índice y el indexMapping
  • Se escriben consultas para acceder a los datos en OpenSearch
  • Se crea un pipeline de OpenSearchIngestionService que copia datos de DynamoDB a OpenSearch
• La configuración relacionada se administra como TypeScript/JavaScript dentro del repositorio, junto con el código del frontend
• npx ampx sandbox levanta servicios de AWS y detecta cambios en la configuración para modificar automáticamente los servicios existentes

Dominios que quedan después de borrar el sandbox

• Esta configuración incluye varios recursos: la base de datos DynamoDB, un servicio de OpenSearch, un pipeline de OSIS, roles de IAM y más
• El boilerplate oficial crea por defecto una instancia de OpenSearch r5.large.search
  • Ese valor predeterminado no aparecía explícitamente ni en el boilerplate ni en la guía
  • r5.large.search cuesta como mínimo $134 al mes
• Al terminar la jornada, si se detiene el sandbox con CTRL-C, aparece un prompt preguntando si se quiere borrarlo de forma permanente, y el usuario puede elegir Y
• En ese momento DynamoDB sí se elimina, pero en la consola de AWS el dominio de OpenSearch sigue ahí
• Si al día siguiente se vuelve a ejecutar npx ampx sandbox, se crea una nueva instancia de OpenSearch, y npx ampx sandbox delete tampoco elimina la instancia original
• Si este proceso se repite, quedan varios dominios de OpenSearch en segundo plano dentro del mismo proyecto y los costos se van acumulando

Posible bug y tipo de instancia predeterminado

• Este comportamiento parecía un gran footgun, y aun después del ticket con AWS Support no se había resuelto en ese momento
• Había reportes antiguos de bugs relacionados, pero no se encontraron casos de menos de un año
  • Como ejemplo se menciona aws-amplify/amplify-cli issue #10523
• Es posible que en v1 los dominios de OpenSearch sí se borraran correctamente y en v2 ya no, pero no hay una causa confirmada
• El flujo actual ya no se ejecuta con Amplify CLI, sino mediante npx
• Que r5.large.search siga siendo el tipo de máquina por defecto también se considera un riesgo
  • Sería mejor que fuera un campo obligatorio, sin valor predeterminado
  • Si la guía mostrara r5.large.search como valor por defecto, los usuarios podrían notarlo con más facilidad
  • Como este valor no es exclusivo de Amplify sino parte de AWS CDK, no se considera responsabilidad solo del equipo de Amplify

Puntos a tener en cuenta al usar Amplify con OpenSearch

• Ya se esperaba que las herramientas que aceleran el desarrollo con tecnología nueva pudieran salir más caras que trabajar más cerca del bare metal, pero este costo fue mucho más allá de eso
• Usando la consola de budget de AWS se pueden recibir alertas cuando el gasto estimado vaya a superar el presupuesto
• Incluso si solo se sigue la sección de OpenSearch, se crean una cuenta de IAM, un dominio de OpenSearch, un pipeline de OSIS, un log group y almacenamiento en S3, por lo que hay muchos recursos ocultos
• OpenSearch es un servicio que suelen usar clientes empresariales, así que puede considerarse un servicio “avanzado”, y quizá se asume que el usuario entiende mejor el ecosistema de AWS
• Se usó OpenSearch por el soporte de consultas de bounding-box con geo_point, aunque no está claro si eso también habría sido posible con un producto más simple
• Según la actualización, la guía de AWS fue corregida después; no se había actualizado en los 3 meses desde que se reportó inicialmente el problema, pero antes de publicar el post parece que ya había comenzado el trabajo de PR en la documentación

[GN⁺]

Opiniones de Hacker News

• Las alertas de facturación son casi una broma; en la práctica deberían ofrecer límites duros de gasto.
  También deberían proporcionar una forma de configurar ese límite durante el onboarding.
  Construir un negocio sobre cheques en blanco y cobros accidentales es sospechoso, y además eleva mucho la barrera de adopción.
  Mientras más vean los desarrolladores casos como “seguí un tutorial de 20 minutos y me cobraron lo equivalente a los ahorros de toda mi vida; esta vez soporte al cliente me lo perdonó, pero la próxima parecía que hasta se iban a quedar con mi casa”, menos ganas dan de explorar productos de AWS.

  • No es un problema exclusivo de AWS; parece que, en general, los proveedores cloud se dividen en solo dos tipos:
    los que trasladan el riesgo al cliente, como AWS o DigitalOcean, y los que venden planes sospechosos de “ilimitado” o “sin medición”.
    Ninguno de los dos es lo que quiero.
    Me gustaría que existiera un proveedor que permita planificar capacidad correctamente con límites claros y documentados, donde el cliente asuma el riesgo de disponibilidad, pero el proveedor asuma el riesgo financiero.
    Si no fuera exagerado, estaría dispuesto a pagar una tarifa fija más alta.
  • Los límites duros de gasto son casi contraproducentes para los clientes empresariales, que son el público principal de AWS.
    Casi ningún cobro accidental barato es peor que provocar downtime o pérdida de datos en una aplicación crítica.
    Incluso si existieran solo como opción, el equipo de contabilidad podría presionar para usarlos, y si algo sale mal existe el riesgo de que termine en un incidente de pérdida de datos.
    Puede tener sentido para proveedores cloud enfocados en desarrolladores independientes o pymes.
  • En comentarios de HN apareció varias veces que el código de facturación de AWS es un enorme spaghetti code, y que internamente hay mucho miedo de tocar cambios grandes ahí.
    Entre las cosas internas que me enteré aquí, es de las más interesantes.
  • Me interesaba AWS, pero por razones como esta nunca me animé a meterme de lleno.
    Es más seguro usar un VPS barato y de tarifa fija que terminar arrepintiéndose.
  • Debería regularse.
    Pedirle a Amazon que haga algo no sirve de mucho.
    Hay que obligar por ley a Amazon y a otros proveedores a respetar el dinero de los usuarios.
    Las empresas, por defecto, no hacen lo que es ético o bueno para la economía, sino lo que da dinero.

• En comparación es algo menor, pero al intentar desplegar una app en ECS recibí una factura de 100 dólares y decidí no volver a usar AWS.
  El error por el que el servicio no levantaba era problema de mi app, pero los logs de CloudWatch solo mostraban alrededor del 20%, así que para obtener logs tuve que redesplegar cinco veces, corregir, y luego redesplegar otras cinco veces.
  Me cobraron por cada despliegue fallido y, después de sufrir unos dos días, borré la cuenta y desplegué en DigitalOcean App Platform.
  Ahí el despliegue también falló por el error de mi app, pero los logs aparecieron cada vez; lo arreglé y lo puse a correr en menos de 10 minutos, y el cobro total fue de unos cuantos centavos.
  Desde ese día me prometí que, si tengo alternativa, nunca usaré AWS ni lo recomendaré.

  • Solo he usado Azure, pero parece que ECS equivale a Azure Container Apps.
    Para desarrollo y pruebas, el modelo de facturación basado en consumo era muy barato.
    No sé cómo será con cargas grandes, pero que cobren por cada despliegue suena raro.
  • Abandoné AWS al enterarme de que no se pueden desplegar contenedores directamente en EC2 como en GCP.
    Para proyectos grandes quizá el soporte sea mejor, pero para escala pequeña a mediana, GCP es mucho mejor.
    Tiene componentes básicos que encajan con la forma en que se usan los contenedores hoy, y también está BigQuery.

• Parece haber un bug evidente en el script que ejecuta ese comando npx.
  El autor tiene razón: si es un tutorial, debería elegir sí o sí los recursos más baratos, y al ejecutar el subscript delete debería limpiar los recursos.
  No es justo esperar que, después de ejecutar algo así, un desarrollador revise paranoicamente toda su cuenta de AWS buscando recursos huérfanos.
  Si una startup actuara de esta manera, ¿lo dejaríamos pasar diciendo “estas cosas pasan, hay que tener cuidado”?
  No entiendo por qué aplicamos otro estándar con AWS.

  • Esa es precisamente una de las cosas más molestas de AWS.
    No hay una forma sencilla de ver todos los recursos por los que estoy pagando actualmente.
    Si existe, no la he encontrado.
    Sin un panorama fácil de entender, siento que no tengo control total sobre mi cuenta.
  • Cuando tengo que usar algo nuevo, lo primero que reviso es si puedo recibir una factura fija cada mes.
    También veo qué pasa si consumo más que eso y si puedo limitar cobros inesperados.
    Si no se puede, busco otra cosa.
    Desde el cambio de facturación de Google Maps hace unos años, también tenemos muchísimo cuidado con atarnos demasiado a servicios “gratuitos” de Google, y al final nos salió caro.
  • ¿Existe siquiera una forma simple de listar todos los recursos que hay en una cuenta de AWS?
    Siempre he tenido que revisar por servicio y por región, y es tedioso y propenso a errores.
  • Desde el punto de vista de Amazon, poder ganar fácilmente 1000 dólares no es un bug, es una feature.
    Incluso si lo consideraran un bug, tendría una prioridad mucho más baja que otros asuntos que sí afectan directamente sus propios resultados.
  • Estoy de acuerdo en que no es justo esperar que el desarrollador haga revisiones paranoicas.
    Pero, en la práctica, es razonable.
    Cuando construyo algo en AWS, trato a AWS como una institución financiera hostil fuera de control.

• Por casos como este llevo años posponiendo meterme a fondo con AWS.
  Debería existir un curso estándar de capacitación que no pida datos de tarjeta de crédito y permita a la gente experimentar gratis.
  En cambio, parece que hay oficinistas calculando que pueden sacarle miles de dólares a la gente aquí y allá por “errores del usuario”.
  Estos cobros son difíciles de disputar y, en algunos casos, directamente imposible.
  Seguro no soy el único que ha evitado el entorno de AWS por el temor razonable de despertar y encontrarse con una factura enorme.

  • Que AWS no haga un reembolso en una situación así es muy inusual, así que es difícil verlo como una estrategia para exprimir miles de dólares por errores del usuario.
    Es muy probable que hayan decidido que procesar reembolsos les resulta menos pesado que ofrecer tutoriales precisos y baratos.
    Eso no justifica la conducta, pero a mí incluso me cancelaron un cargo legítimo de 600 dólares que se generó usando AWS Textract.
    En ese momento yo trabajaba en una empresa de miles de millones de dólares.
  • Creo que la razón por la que la gente termina en estas situaciones de pago es que en realidad no profundiza en AWS.
    Las listas de precios son fáciles de consultar y no siempre son sencillas de entender, pero la mayoría de los costos crecen de forma casi lineal, así que son relativamente fáciles de probar.
    Conviene evitar los servicios envoltorio como AWS Amplify, CloudFormation y las distintas cosas tipo Stack.
    Basta con usar directamente los servicios principales.
    Todos los servicios tienen API, y obtener una clave de API asociada a un usuario de IAM es tan simple como hacer clic en un botón.
    Lo demás se puede gestionar con caché adecuada y alineando el modelo de costos con el modelo de ingresos.
    Hay que hacer que el costo de los servicios con autoescalado sea un porcentaje casi fijo de los ingresos, independientemente de la demanda actual.
    El ancho de banda sí es una verdadera pesadilla en AWS, pero la consola ofrece descuentos automáticos de largo plazo y, si pasas por un representante de ventas, también puedes conseguir descuentos contractuales algo mejores.
    Por eso creo que conviene evitar EC2; además, el ancho de banda interno de EC2 también es más caro, así que es mejor usar directamente Lambda + S3 + CloudFront.
    Después de unos 3 meses, se volvió bastante fácil predecir qué combinación de servicios sería la más rentable al implementar una nueva funcionalidad de cara al usuario.
  • A Cloud Guru / Pluralsight tiene una función que llaman “Cloud Playground” o “sandboxes”.
    Quizá sirva para ese uso, pero no la he probado directamente, así que no estoy seguro.
  • El dinero que sale de este tipo de errores de usuario probablemente sea una gota en el océano para AWS en conjunto.
    En mi experiencia, AWS más bien intentaba evitar problemas en los que el daño reputacional terminara costando más.
    AWS no es barato y, en algunos casos, especialmente en costos de transferencia de datos, es absurdamente caro, pero no creo que su forma de operar sea engañar a los clientes para que gasten accidentalmente unos cientos de dólares de más.

• Muy propio de AWS.
  Hace unos meses seguí la guía oficial de inicio rápido de SageMaker para correr Llama 2 y, aunque levantó realmente rápido, al día siguiente vi que se estaban yendo 400 dólares por día.
  Me cancelaron el cobro, pero aprendí con claridad que no hay que confiar en las guías oficiales.

  • SageMaker es de lo más decepcionante desde el punto de vista de producto y un caso claro de enshittification.
    En los primeros años del producto, 2017–2018, la configuración era bastante intuitiva.
    Estaban claras las instancias de notebooks, la inferencia, la API REST para servir, algo de EFS y que el centro del servicio era S3.
    El precio también era acotado, así que no había sorpresas.
    En general se sentía como DigitalOcean, y un científico de datos con conocimientos básicos de infraestructura y curiosidad podía armar una configuración barata, predecible y simple.
    Ahora existen Wrangler, Feature Store y RStudio; la experiencia de usuario de la consola de notebooks es terrible, y por dentro varios servicios mueven datos entre sí y te cobran por eso.

• Por circunstancias tuve que enviar solicitudes HTTP crudas en lugar del SDK inflado de AWS, y fallaban con el encabezado content-type: application/json, pero funcionaban con content-type: application/x-amz-json-1.0.
  Ojalá dejaran de una vez este nonsense.

  • Sentí algo parecido en casi todas las partes de AWS que he tocado durante mi carrera.
    Demasiado inflado, demasiado complejo o lleno de implementaciones propias raras sin un beneficio claro.
  • Sinceramente, es una filtración de detalles internos.
    Internamente, la mayoría de las apps usa el viejo framework Coral, y por eso usan este formato JSON con formas bien definidas de entrada, salida y errores.

• Todas las guías oficiales de AWS están diseñadas para hacerte usar la mayor cantidad posible de servicios de AWS, y eso aumenta en la misma medida el riesgo de gasto.
  Hay que mirar con extremo espíritu crítico lo que AWS recomienda: valores predeterminados de la GUI, herramientas CLI, guías, arquitecturas recomendadas, etc.
  Hay una razón por la que en las empresas existe un puesto muy bien pagado para orientar a los colegas sobre cómo usar AWS de forma rentable y con bajo riesgo.

  • Exacto.
    En despliegues pequeños o pruebas, la parte más cara casi siempre son cosas accesorias o los servicios más nuevos recomendados en lugar de alternativas más simples.

• Si estás usando OpenSearch por consultas de caja delimitadora con geo_point, ¿qué tal PostgreSQL + PostGIS?
  https://postgis.net/docs/using_postgis_query.html

• Creo que esta configuración sin fricción, la baja intuitividad de la experiencia e interfaz de usuario, la poca cautela ante registrar una tarjeta de crédito y la facturación empaquetada entre servicios como AWS Batch + Lambda + EC2 forman parte del modelo de negocio.
  No sé bien cómo expresarlo, pero se parece a un parque de diversiones moderno donde pagas entrada y luego tienes que pagar aparte por cada atracción e incluso por usar el baño.

  • Yo también lo siento así.
    El modelo de facturación de la nube traslada la responsabilidad al usuario bajo el nombre de “flexibilidad” y “personalización”.
    Imagínate una rentadora de autos que cobra por milisegundo cada componente, como las vueltas del árbol de levas del motor, las vueltas de las llantas, el funcionamiento de los limpiaparabrisas o el tiempo de calefacción del asiento, y luego dice que el cliente “controla” su uso y su presupuesto porque puede configurar alertas para cada rubro.
    Desde los valores predeterminados, es un modelo de costos hostil y peligroso para el usuario.