En 2020, migrar a la nube significaba ahorrar dinero. En 2026, los números son otros.
La adopción de cloud llegó a su punto máximo alrededor de 2021. En cada entrevista con un CTO, en cada keynote del re:Invent, el argumento era el mismo: migra, moderniza, ahorra. Y por un tiempo fue verdad. Las empresas que salían de hardware on-prem viejo recortaban costos, a veces de manera considerable.
Pero los precios no se quedaron quietos. Las tarifas de egress de AWS S3 subieron. GCP eliminó descuentos por uso sostenido. El pricing de bandwidth de Azure cambió sin hacer ruido. Nada de esto llegó a los titulares. Solo apareció en la factura cada mes, acumulándose.
Recopilamos datos de pricing de AWS, GCP y Azure, probados contra tres patrones reales de arquitectura: una plataforma SaaS, un equipo que hizo todo bien en FinOps, y una API global. El mismo problema apareció en los tres casos, solo con distintas formas.
El resumen: El precio por GB de egress apenas se movió desde 2020, pero el volumen de datos de las aplicaciones creció entre 3 y 7 veces. Una empresa SaaS de mercado medio que mueve 50 TB por mes fuera de AWS paga US$ 54,000 al año solo en bandwidth. Enrutar los workloads stateless a través de una red distribuida reduce esa factura entre 60 y 80% sin tocar la base de datos ni reconstruir la arquitectura.
Por qué los costos de egress de AWS han seguido creciendo desde 2020
AWS cobraba US$ 0.09/GB saliendo de us-east-1 en 2020. En 2026, ese número sigue siendo US$ 0.09. Ahí es donde termina el “nada cambió”.
Los volúmenes de datos crecieron. Las bases de usuarios se volvieron globales. Las aplicaciones se volvieron más real-time: más llamadas de API, más conexiones WebSocket, más entrega de contenido multimedia. El multiplicador de egress de una aplicación moderna es de 3 a 7 veces lo que los equipos proyectaron en sus planes de migración de 2020. El precio unitario se mantuvo plano mientras el volumen se multiplicaba por debajo.
Una empresa SaaS que mueve 50 terabytes fuera de AWS al mes paga cerca de US$ 4,500 al mes en egress. Son US$ 54,000 al año. De bandwidth. Solo bandwidth. Enruta ese mismo tráfico por una red distribuida con puntos de presencia globales y la factura baja entre 60 y 80%. Mismos 50 TB. Mismos usuarios. Camino diferente.
Qué arquitecturas cloud están más expuestas a las tarifas de egress
El caso SaaS es el más común. App server en una región, base de datos en la misma región, CDN encima. Multi-region fue una consideración tardía, cuando ocurrió. Era la arquitectura que tenía sentido en 2020.
El problema de latencia es estructural. Un usuario en Ciudad de México accediendo a una API en us-east-1 ya tiene entre 120 y 180ms de round-trip solo por la distancia geográfica, antes de que corra cualquier lógica de la aplicación. Para autocomplete, dashboards en tiempo real o edición colaborativa, eso rompe el producto. Mover toda la aplicación no lo resuelve; mover la capa stateless sí. El cache de API, la capa de auth y la entrega de assets estáticos pueden responder en 30ms. La base de datos se queda donde está.
El caso FinOps es más frustrante porque el equipo hizo todo bien. Right-sizing, eliminación de recursos ociosos, reserved instances: hecho de forma consistente, ese trabajo baja entre 15 y 25% de una factura bruta en la nube. Pero tiene un techo, y la mayoría de los equipos lo alcanza antes de los 18 meses. Las herramientas de FinOps pueden mostrarte de dónde viene el egress. No pueden cambiar el precio unitario; eso lo define el proveedor. Un equipo de FinOps mirando una línea de US$ 25,000 en egress puede etiquetarla, rastrearla y escalarla. Al final de ese proceso, te van a decir que la única solución real es una decisión de ingeniería. No se puede optimizar una arquitectura que enruta cada byte por el cloud origin.
El caso de la API global es el que más sorprende a los equipos. Las APIs internas, los microservicios comunicándose entre sí, los data pipelines, las integraciones con terceros: todo eso genera egress. Cada respuesta que sale de la región es bandwidth cobrado. Los equipos con microservicios subestiman los costos de tráfico cross-region en cerca de 40% en sus proyecciones iniciales. En tres años, esa diferencia se convierte en un número que el CFO va a preguntar.
Tres razones por las que la factura no se corrige
La mayoría de los engineering leaders que se encuentran en esta situación ya saben que algo está mal. Ya vieron los dashboards de CloudWatch y tuvieron la conversación con finanzas. El problema no es falta de información.
Sesgo del costo hundido. Si lideraste la migración a la nube, admitir que la ecuación económica cambió se siente como admitir que te equivocaste. Entonces los equipos esperan. Esa espera cuesta dinero real cada mes.
Ilusión de complejidad. Tocar la arquitectura suena como un proyecto de 12 meses con alta probabilidad de romper algo en producción. Generalmente no es así, pero los vendors que se benefician de tu configuración actual no tienen razón para corregir esa percepción.
Ceguera de benchmark. La mayoría de los equipos compara su factura de cloud con lo que pagaban on-prem hace cinco años. Esa baseline está obsoleta. Las alternativas de hoy no son las mismas que en 2020.
Ninguno de estos es un problema técnico.
Cómo auditar tus gastos de egress en menos de cuatro horas
La auditoría toma entre dos y cuatro horas con los dashboards que ya tienes abiertos.
¿Qué porcentaje de tu factura mensual es egress? Por encima del 15% tienes un objetivo inmediato. Por encima del 25% estás perdiendo dinero que no tendrías que perder.
¿Cuál es la latencia promedio de API para usuarios fuera de tu región principal? Si no sabes el número de memoria, esa ya es una respuesta. Sácalo de New Relic, Datadog o cualquier herramienta de observabilidad que estés usando.
¿Qué workloads son stateless versus stateful? Los workloads stateless (respuestas de API, autenticación, entrega de assets, serverless functions) son candidatos para mover. Los workloads stateful (bases de datos, colas, almacenamiento persistente) se quedan. Esa es la línea de decisión.
¿Cuál es tu costo de egress por usuario activo al mes? Tu cloud provider no va a mostrar ese número en la consola. Divide el costo total de egress entre tus usuarios activos mensuales. Si ese número crece más rápido que el ingreso por usuario, la arquitectura está trabajando en contra del negocio.
Stateless vs. stateful: dónde ocurre realmente la reducción de costos de egress
| Tipo de workload | Ejemplos | Dónde corre | Impacto en egress |
|---|---|---|---|
| Stateless | Respuestas de API, auth, entrega de assets, edge functions | Red distribuida | Bajo — el tráfico deja de llegar al cloud origin por cada request |
| Stateful | Bases de datos, colas, almacenamiento persistente | Cloud (sin cambios) | Contenido — no se necesita cambio arquitectural |
El principio es simple: los workloads stateless van en la red distribuida, los workloads stateful van en la nube. La mayoría de los equipos corre las dos capas en la nube por default, y por eso la factura de egress sigue creciendo.
La red distribuida de Azion corre Functions, WAF y controles de seguridad de aplicaciones en más de 100 ubicaciones globalmente. Un usuario en Ciudad de México accede en 15ms en lugar de 180ms. El egress baja porque el tráfego deja de enrutarse por el cloud origin en cada request. La base de datos no se mueve. El equipo no reconstruye la arquitectura desde cero.
Los equipos que hicieron esta división están viendo reducciones de egress de 60 a 80% y mejoras de latencia de 40 a 60% fuera de su región principal. El cambio no es un rip-and-replace. Es mover el 20% de workloads que generan el 80% de la factura de egress.
En 2020, la respuesta por default era: ponlo en la nube. En 2026, ese default es inercia.
La nube sigue siendo la decisión correcta para workloads stateful. Para todo lo que es stateless, egress-heavy y distribuido globalmente, las cuentas dejaron de cuadrar hace tiempo. La mayoría de los equipos simplemente no lo ha revisado.
Empieza por el egress como porcentaje de tu factura total. Saca los datos de latencia para usuarios fuera de tu región principal. Traza la línea stateless/stateful en tu arquitectura. Esos tres números te van a decir si tienes un problema estructural o un problema de right-sizing — y solo uno de ellos se resuelve con una herramienta de FinOps.
Habla con un especialista de Azion para ver cómo mover workloads stateless a una red distribuida impacta tu factura de egress.
Preguntas frecuentes
¿Qué es el costo de egress en la nube? El costo de egress es la tarifa que los proveedores de cloud cobran por transferir datos fuera de su red. AWS cobra US$ 0.09 por GB saliendo de us-east-1. Para una empresa que mueve 50 TB al mes, eso es US$ 4,500 al mes o US$ 54,000 al año solo en tarifas de bandwidth, antes de cualquier costo de compute o storage.
¿Por qué las tarifas de egress de AWS son tan altas en 2026? El precio por GB no ha cambiado significativamente desde 2020, pero el volumen de datos de las aplicaciones creció entre 3 y 7 veces respecto a lo que los equipos proyectaron en sus planes originales de migración. Las funcionalidades real-time, las bases de usuarios globales y las arquitecturas de microservicios multiplican el egress muy por encima de las proyecciones iniciales.
¿Cuál es la diferencia entre workloads stateless y stateful en la nube? Los workloads stateless — respuestas de API, autenticación, entrega de assets y serverless functions — no dependen de estado de sesión almacenado y pueden correr en cualquier lugar. Los workloads stateful — bases de datos, colas y almacenamiento persistente — necesitan mantenerse en una ubicación consistente. Esta distinción determina qué workloads pueden moverse a una red distribuida para reducir costos de egress sin afectar el resto de la arquitectura.
¿FinOps puede reducir los costos de egress en la nube? FinOps puede identificar y rastrear el gasto en egress, pero no puede cambiar el precio por GB que define el proveedor. Right-sizing y reserved instances suelen reducir las facturas de cloud entre 15 y 25%, pero la reducción de egress requiere un cambio arquitectural: mover los workloads stateless y egress-heavy a una red distribuida más cercana a los usuarios.
¿Cómo calculo el costo de egress por usuario activo? Divide tu costo total mensual de egress entre tus usuarios activos mensuales. Si ese número crece más rápido que el ingreso por usuario, tus costos de infraestructura están escalando más rápido que el negocio. Eso es un problema estructural, no de right-sizing, y no se puede resolver solo con una herramienta de FinOps.
¿Cómo se ve la división stateless/stateful en la práctica? Los caches de API, las capas de autenticación, la entrega de assets estáticos y las edge functions van a una red distribuida con puntos de presencia globales. Las bases de datos, las colas y el almacenamiento persistente se quedan en la nube sin cambios. El resultado es que los requests de los usuarios se atienden más cerca de donde están, el egress saliendo del cloud origin baja significativamente, y la infraestructura central de la aplicación no necesita reconstruirse.