speakerdeck.com
Optimización de Costos para Transacciones de Alto Volumen en AWS
Cuando se habla de optimización de costos en AWS, la conversación suele ir a los mismos lugares de siempre: Reserved Instances, Savings Plans, apagar recursos que no usas. Todo eso está bien y deberías hacerlo, pero hay un nivel más profundo que la mayoría de los equipos no toca — las decisiones de arquitectura y tecnología que generan costos innecesarios a escala sin que nadie se dé cuenta. Este post va sobre eso.
La economía oculta de las API calls
En arquitecturas serverless, cada llamada API tiene un costo. Eso parece obvio, pero las implicaciones no siempre son visibles cuando estás diseñando el sistema.
El patrón más común que genera costo silencioso es el polling. Imagina una aplicación que consulta un endpoint REST cada 5 segundos para verificar si hay nuevas órdenes en DynamoDB. A volumen bajo nadie lo nota. A volumen alto, estás pagando por miles de requests a API Gateway y Lambda que en su mayoría regresan vacío. La corrección es dejar de preguntar y empezar a escuchar: DynamoDB Streams detecta los cambios en la tabla y los envía a EventBridge, que filtra y transforma el evento antes de disparar el downstream — SNS, Step Functions, WebSockets. Cero polling, costo proporcional al trabajo real.
Otro patrón costoso es usar Lambda para cada operación que pasa por API Gateway. Si tienes un frontend enviando datos JSON que necesitan ser validados y escritos en DynamoDB, el reflejo natural es meter una Lambda en el medio. El problema es que cada invocación tiene costo. API Gateway tiene Mapping Templates que pueden hacer validaciones y transformaciones de request sin necesidad de invocar ninguna función. Para operaciones simples y de alto volumen, eliminar esa Lambda puede significar cientos de miles de invocaciones menos por mes.
El tercer caso tiene que ver con los límites internos de AWS. Cuando una aplicación escribe a DynamoDB a alta velocidad y alcanza el límite de Write Capacity Units, AWS aplica backoff exponencial y genera reintentos automáticos — que también cuestan. Meter SQS como buffer entre la aplicación y DynamoDB nivela el throughput y elimina esos reintentos, convirtiendo un patrón de escritura caótico en uno predecible y controlable.
Data transfer: el costo que nadie presupuesta
La transferencia de datos en AWS tiene una particularidad: es casi invisible en el diseño inicial y muy visible en la factura a fin de mes.
El ejemplo más costoso y fácil de corregir es usar NAT Gateway para que instancias en subnets privadas accedan a S3. NAT Gateway cobra por procesamiento de datos — a $0.045 por GB, 5TB al mes son $225 adicionales que no agregan ningún valor técnico. La solución es un VPC Endpoint para S3: el tráfico fluye directamente dentro de la red de AWS sin pasar por NAT, sin costo por transferencia. Es una de las optimizaciones con mejor ratio esfuerzo/impacto que existen.
Para APIs con alto tráfico de lectura, CloudFront delante de API Gateway puede eliminar la gran mayoría de invocaciones a Lambda. Si configuras CloudFront para cachear respuestas comunes por 5 minutos, todo ese tráfico repetido deja de llegar al backend. Para catálogos de productos, configuraciones, datos de referencia — el impacto puede ser dramático.
El caso de GenAI agrega una dimensión nueva. Si tienes un chatbot en AWS que manda cada query a un modelo externo como OpenAI, estás pagando transferencia de datos de salida en cada request. Mover el modelo a Amazon Bedrock o SageMaker dentro de AWS no solo elimina esa transferencia — también te da más control sobre latencia, disponibilidad y costos por token.
La economía del almacenamiento
El formato de compresión que usas para tus datos puede parecer un detalle técnico menor. En cargas de análisis a escala, no lo es. GZIP es el default en muchos pipelines de Redshift, EMR y Glue, pero tiene latencia de descompresión alta y peor ratio de compresión comparado con alternativas más modernas. Zstandard en nivel 3 ofrece mayor eficiencia tanto de almacenamiento como de procesamiento, con reducciones de más de un 30% en tamaño. Para 50TB de logs de transacciones, ese 30% es dinero real.
El zero-copy data sharing es otro concepto que vale la pena entender. El patrón ineficiente es copiar datos entre cuentas de AWS para que cada equipo tenga su propia copia en S3. Cada copia es storage adicional, cada sincronización es transferencia. Con AWS Lake Formation y Glue Catalog Cross-Account, puedes dar acceso a las mismas tablas registradas a múltiples cuentas sin mover un solo byte. Los datos viven en un lugar, el acceso se gestiona con permisos.
Computación selectiva: elegir bien el tipo de recurso
Aquí hay una distinción que muchos equipos no hacen: no todos los workloads tienen el mismo cuello de botella. Algunos son CPU-intensivos, otros son memory-bound, otros son IO-bound. Elegir la familia de instancia equivocada significa pagar por recursos que no estás usando.
Un ejemplo concreto: una base de datos MySQL en RDS con instancias t3.medium que tiene la RAM llena y hace swapping a disco. El problema no es CPU — es memoria. La solución no es subir a una instancia con más CPU, es cambiar a una familia memory-optimized. Las instancias R6g con Graviton2 ofrecen 50% más memoria por dólar que T3. Para Elasticsearch con alto uso de IOPS donde EBS gp3 ya es el cuello de botella, instancias I4i con almacenamiento NVMe local reducen la latencia de consultas en un 60%.
En Lambda, la relación memoria-CPU tiene una implicación de costos contraintuitiva. Con 128MB de RAM, una función de procesamiento de imágenes puede tardar 6 segundos. Con 1024MB tiene acceso a una vCPU completa y la misma operación tarda 0.8 segundos — 7 veces más rápida. Lambda Power Tuning existe para encontrar el punto óptimo entre costo por ejecución y tiempo de ejecución, y el resultado frecuentemente sorprende: más memoria puede ser más barato.
En Kubernetes, el costo escala con el número de nodos, y el número de nodos escala con el número de pods. Si cada microservicio tiene su propio pod con límites de CPU y memoria dedicados, terminas con mucha capacidad reservada que en promedio está subutilizada. Consolidar servicios relacionados en pods multi-tenant reduce el número total de nodos necesarios y mejora la utilización del clúster.
Estrategias de bases de datos
Aurora tiene una característica que justifica su adopción para cargas intensivas en I/O: Aurora I/O-Optimized elimina el cobro por operaciones de lectura y escritura, cambiando el modelo de precio a uno más predecible basado en capacidad. Si tienes un workload con miles de IOPS, la diferencia puede ser sustancial. Combinado con auto-tiering para mover datos históricos a almacenamiento más barato y Aurora Backtrack para reducir snapshots innecesarios, el costo total de una instancia de 5TB puede bajar considerablemente.
Para logs de transacciones en PostgreSQL que crecen a millones de registros con el tiempo, la solución no es escalar la instancia — es particionar los datos por tiempo. En lugar de una tabla gigante donde las consultas escanean todo el historial, particiones mensuales o diarias limitan el scope de cada query al período relevante. Amazon Timestream también es una alternativa cuando el patrón de acceso es fundamentalmente time-series.
Con DynamoDB a escala, TTL es una herramienta de costo que se subestima. Los ítems expirados se eliminan automáticamente sin consumir Write Capacity Units, lo que mantiene la tabla limpia sin operaciones de borrado explícitas. DAX como capa de caché elimina lecturas repetidas a la tabla principal y DynamoDB Streams permite reaccionar a cambios sin polling — ambos ya cubiertos en la sección de API calls.
Los anti-patterns que hay que evitar
Tan importante como saber qué optimizar es saber qué no hacer. Over-engineering en arquitecturas event-centric es frecuente: agregar capas de EventBridge, SNS y SQS a flujos que podrían ser síncronos simples, creando complejidad operacional por ahorros marginales que nunca se materializan.
El mito de que serverless siempre es más económico que servidores es exactamente eso: un mito. Para cargas con throughput constante y predecible, un servicio administrado de contenedores o incluso instancias reservadas pueden salir más baratos que pagar por invocación a escala. El modelo correcto depende del patrón de tráfico.
Los logs sin filtrar son otro agujero silencioso. Loggear todo en CloudWatch Logs a nivel DEBUG en producción, sin retention policies, sin filtros, genera costos de ingesta y almacenamiento que crecen con el tráfico. Filtrar a nivel del source, definir retention apropiado y usar Log Insights solo cuando se necesita mantiene eso bajo control.
La conclusión más importante es también la más sencilla: la optimización no es un proyecto con fecha de inicio y fin, es una práctica continua. Las estrategias no convencionales que van más allá de Reserved Instances y right-sizing pueden aportar entre un 15-30% adicional de ahorro. Pero solo si el equipo tiene cultura de cost awareness integrada desde el diseño, no como una corrección posterior.
Top comments (0)