AWS a 4 años: costos, dependencia y límites

Cuatro años en AWS suenan a una historia de éxito hasta que empiezas a sumar la factura, revisar el tiempo que tu equipo invierte en operar la plataforma y medir cuánto control real tienes sobre tu infraestructura. Ahí es donde la conversación cambia. Ya no se trata de si la nube funciona, porque sí funciona. Se trata de cuánto cuesta sostenerla, qué dependencias estás creando y qué trade-offs aceptas para moverte rápido.

Este análisis de cuatro años usando AWS deja una lección bastante clara para founders y líderes técnicos en LatAm: la nube te compra velocidad y elasticidad, pero no te regala simplicidad ni ahorro automático. Si no diseñas con intención, terminas pagando por conveniencia más de lo que imaginabas, y además con una arquitectura que luego cuesta mover. Eso importa todavía más en mercados donde cada dólar cuenta y donde el equipo suele ser pequeño.

Lo que AWS sí resuelve y por qué tantos equipos se quedan

AWS sigue siendo una opción muy sólida cuando necesitas lanzar rápido, escalar con demanda variable y evitar montar infraestructura física. Si estás construyendo un producto con tráfico incierto, te permite pasar de cero a producción sin comprar servidores, sin negociar colocation y sin esperar semanas por hardware. Para una startup en Ciudad de México, Bogotá, Lima o Quito, eso puede ser la diferencia entre validar una idea en 30 días o perder tres meses en operaciones.

La primera ventaja real no es técnica, es de foco. Tu equipo puede concentrarse en producto, datos y clientes, en lugar de administrar racks, reemplazar discos o pelear con proveedores locales de conectividad. Servicios como S3, RDS, ECS, Lambda o CloudFront te ahorran una cantidad enorme de trabajo inicial. La documentación oficial de AWS para Amazon S3 y Amazon RDS muestra bien el tipo de responsabilidades que delegas al proveedor.

Pero esa comodidad tiene un precio. No solo pagas por recursos; pagas por diseño, por operación y por decisiones que luego condicionan el futuro. Si eliges servicios administrados muy específicos, tu sistema gana velocidad hoy, pero pierde portabilidad mañana. Y si tu equipo no tiene hábitos de observabilidad y control de costos, la factura crece en silencio.

La nube no elimina la operación, la cambia de forma

Antes, operar significaba mantener servidores. Ahora significa administrar permisos, redes, políticas de seguridad, límites de servicio, alertas y costos. No desaparece el trabajo, solo cambia de capa. En AWS, una mala configuración de IAM puede ser tan peligrosa como un servidor mal parchado, y una regla de autoscaling mal pensada puede disparar gastos en horas.

Eso obliga a pensar distinto. Ya no basta con “tener infraestructura”. Necesitas saber quién puede crear recursos, cómo se etiquetan, qué se borra automáticamente y qué queda prendido por accidente. Si no haces ese control desde el inicio, la nube se vuelve un cajón donde todo se acumula.

Costos reales: dónde se va el dinero

La parte más incómoda de AWS es que el costo rara vez aparece en una sola línea. Se reparte entre cómputo, almacenamiento, salida de datos, balanceadores, logs, snapshots, NAT gateways, tráfico entre zonas y servicios administrados. El problema no es que cada componente sea caro por sí solo. El problema es que la suma de pequeñas decisiones termina siendo grande.

En equipos pequeños, el gasto suele empezar con algo razonable y luego crecer por inercia. Un entorno de staging que nadie apaga. Logs que se retienen 90 días cuando nadie los revisa. Backups duplicados. Instancias sobredimensionadas. Bases de datos con más capacidad de la necesaria. Todo eso es bastante común, y no hace falta un incidente para que pase.

Un ejemplo de desglose mensual

La siguiente tabla no representa una cuenta real de un caso específico; es un ejemplo práctico de cómo se distribuyen gastos típicos en un stack pequeño o mediano en AWS.

Lo útil de este desglose es que te muestra dónde mirar primero. Mucha gente revisa solo EC2 o solo la base de datos, pero el gasto real puede estar escondido en red o en observabilidad. Si tienes un entorno con mucho tráfico saliente, la factura sube aunque el cómputo no cambie tanto.

Tres palancas que sí mueven la factura

1. Right-sizing: ajustar tamaños de instancias y bases de datos al uso real. Si tu CPU promedio está en 10% durante semanas, probablemente estás pagando de más.
2. Apagar lo que no produce valor: staging, pruebas y ambientes temporales deberían tener horarios o automatización de apagado.
3. Reducir transferencia de datos: mover cargas al borde, usar caché y evitar saltos innecesarios entre zonas o regiones.

AWS tiene herramientas oficiales para esto, como AWS Cost Explorer y AWS Budgets. No resuelven el problema por sí solas, pero te dan visibilidad para actuar antes de que la factura te sorprenda.

Dependencia del proveedor: el costo que no sale en la factura

El vendor lock-in no siempre se siente como una trampa al inicio. A veces se ve como eficiencia. Usas DynamoDB porque escala sin que te preocupes por particiones. Usas Lambda porque te evita administrar servidores. Usas SQS, SNS, EventBridge y otros servicios nativos porque encajan bien entre sí. Todo eso acelera.

El problema aparece cuando quieres salir. Migrar no solo significa copiar datos. Significa reconstruir comportamientos, permisos, automatizaciones, observabilidad y, en algunos casos, reglas de negocio que quedaron embebidas en servicios específicos. Mientras más profundo entras en la capa administrada, más difícil es cambiar de proveedor sin costo operativo.

Cuándo el lock-in sí vale la pena

No todo lock-in es malo. Si tu negocio gana mucho con un servicio administrado muy específico, puede ser una decisión racional. Por ejemplo, si tu equipo es pequeño y no quieres mantener colas, orquestadores o clusters complejos, usar servicios nativos puede ser mejor que inventar una plataforma interna mediocre.

La pregunta correcta no es “¿cómo evito depender de AWS?”. La pregunta útil es “¿qué parte de mi sistema quiero poder mover en 12 o 24 meses?”. Si respondes eso por adelantado, puedes decidir dónde usar estándares abiertos y dónde aceptar dependencia por velocidad.

Cómo reducir dependencia sin frenar el producto

Hay varias prácticas que ayudan bastante:

• Mantén la lógica de negocio fuera de servicios muy acoplados al proveedor cuando sea posible.
• Usa contenedores y despliegues reproducibles para que el runtime no dependa de una consola específica.
• Define interfaces claras para almacenamiento, colas y mensajería.
• Evita mezclar demasiados servicios AWS en una sola funcionalidad si una alternativa más simple cumple igual.
• Documenta qué sería difícil de migrar y por qué.

No necesitas diseñar para una migración hipotética desde el día uno. Sí necesitas evitar que cada decisión te ate sin darte cuenta. En LatAm, donde el acceso a talento cloud senior puede ser más limitado y caro, el lock-in técnico se vuelve también lock-in de equipo: si solo una o dos personas entienden cómo funciona todo, el riesgo sube.

Operación diaria: lo que cambia después del primer año

El primer año en AWS suele sentirse ordenado. Todo está nuevo, hay poco tráfico, los entornos están relativamente limpios y las alertas todavía no han explotado. El segundo y tercer año son otra historia. Empiezan a aparecer recursos olvidados, cambios urgentes, deuda técnica y configuraciones que nadie recuerda por qué existen.

Ahí se nota si tu operación está madura o no. Un stack en AWS puede ser muy estable, pero no se administra solo. Necesitas disciplina en despliegues, seguridad, observabilidad y limpieza de recursos. Si no, la nube acumula basura tan rápido como cualquier servidor físico, solo que más fácil de crear.

Señales de que ya tienes problema operativo

Busca estas señales en tu cuenta:

• Más de un ambiente con recursos que nadie puede explicar.
• Alertas que suenan y nadie puede correlacionar con una causa.
• Costos mensuales que suben aunque el tráfico no cambie.
• Permisos IAM demasiado amplios porque “así funciona más rápido”.
• Snapshots y buckets viejos que nadie revisa.

Si reconoces dos o más de esas señales, no tienes un problema de nube. Tienes un problema de proceso. AWS solo lo hace visible.

H3: Seguridad y permisos no son un detalle

AWS te permite hacer cosas muy potentes, y eso implica que una mala política puede abrir demasiado. El principio de menor privilegio no es teoría de auditoría; es una forma de evitar incidentes. Si tu equipo crea roles amplios para salir del paso, luego nadie sabe quién puede borrar qué, leer qué o desplegar dónde.

La documentación oficial de AWS IAM es clara sobre este punto: los permisos deben darse por necesidad, no por comodidad. En la práctica, eso significa revisar políticas, rotarlas, eliminar accesos viejos y separar cuentas o roles por ambiente.

Qué haría distinto si empezara hoy

Después de cuatro años, la lección principal no es “AWS es caro” ni “AWS es malo”. La lección es más útil: la nube amplifica tus decisiones. Si tu arquitectura es simple, tus procesos son claros y tu equipo mide costos desde el inicio, AWS te ayuda bastante. Si improvisas, la nube también amplifica el desorden.

Si hoy estuvieras arrancando un proyecto en LatAm, yo priorizaría estas decisiones:

1. Define el objetivo de negocio antes de elegir servicios. No empieces por la tecnología. Empieza por la frecuencia de tráfico, el tiempo de salida al mercado y el presupuesto mensual máximo.
2. Usa la menor cantidad posible de servicios al principio. Cada servicio extra agrega complejidad operativa.
3. Mide costos desde el día uno. No esperes a tener una factura grande para revisar gastos.
4. Automatiza apagado y limpieza. Los entornos temporales deben morir solos.
5. Diseña una salida razonable. No una migración completa, sino una forma de no quedar atrapado en un solo patrón.

También vale la pena pensar en región y latencia. Para muchas empresas de LatAm, el servicio más cercano no siempre es el más barato, pero sí puede ser el que mejor balance da entre experiencia de usuario y operación. Si tu producto tiene usuarios en varios países, conviene probar cuánto impacta la latencia antes de mover todo a una arquitectura más compleja.

Tabla resumen

AWS no es una mala decisión por defecto. Tampoco es una decisión gratis. A cuatro años, lo que queda claro es que su valor depende menos de la marca y más de cómo diseñas, operas y controlas tu plataforma. Si tú o tu equipo toman decisiones con intención, la nube puede ser una ventaja real. Si no, termina siendo una factura mensual con demasiadas piezas invisibles.