Cómo redujimos un 70% el costo de la cuenta en AWS de Fork
El desafío: Migrar de Sao Paulo hacia Ohio para bajar los costos
Todas las startups nacen con una necesidad común. Levantar un producto en tiempo record, iterar y construir algo que perdure en el tiempo. Debido a eso, muchas veces ocurren decisiones que aceptamos como "deuda técnica" al pasar los años.
En este caso, Fork estableció su operación en Sao Paulo hace ya más de 6 años para tener latencias bajas desde Chile. Hoy, la necesidad es otra. La latencia ha quedado en segundo plano para enfocarse en conseguir mejores precios debido a un crecimiento sostenido a través de los años.
Fork es nuestro cliente de hace años. Desde un inicio que reducimos los costos de su cuenta de AWS en un 24% con Savings Plans y Reserved Instances. En este caso, había una nueva necesidad: disminuir la factura de AWS migrando a Ohio o Virginia del Norte. Nos reunimos, nos mostraron su infraestructura y aceptamos el desafío, uno simple de decir, pero complejo de ejecutar: migrar toda la infraestructura con sus conexiones a otra región desde 0 y modernizar la arquitectura.
La diferencia de costos en Sao Paulo frente a Ohio (us-east-2) es grande, hablamos de un valor entre 30% a 60%. Según el AWS Well-Architected Framework se debe elegir una región basado en criterios de latencia y costos. Las regiones con menores costos son las que están en Estados Unidos. Si bien la latencia es menor en São Paulo, dentro de las opciones más económicas en Estados Unidos, Ohio y Virginia del Norte ofrecen la mejor latencia hacia Chile.
La diferencia de precios on-demand entre sa-east-1 y us-east-2 es significativa para los recursos típicos de una aplicación de tres capas. Tabla comparativa (precios on-demand [Agosto 2026]):
| Recurso | Ohio mensual (~730 h) | São Paulo mensual (~730 h) | Diferencia (%) |
|---|---|---|---|
| EC2 t3.medium | $30.37 | $49.06 | +61.5% |
| RDS db.t4g.medium | $47.45 | $100.01 | +110.8% |
| Application Load Balancer (ALB) | $16.43 | $24.82 | +51.1% |
| Total infraestructura base | $94.25 | $173.89 | +84.5% |
Precios on-demand, us-east-2 y sa-east-1, [Agosto 2026]. Fuentes: Amazon EC2, Amazon RDS, Elastic Load Balancing.
Los costos en las regiones de Ohio y Virginia del Norte son los mismos. Normalmente el criterio de elección se basa en costos y latencia. La latencia entre Ohio y Chile son aproximadamente 130 y 160 ms.
Qué construimos
Fase 1: El Diagnóstico (Spoiler: no es solo copiar y pegar)
Todas las empresas son distintas y enfrentan problemas de negocios diferentes. No solo eso. También existen varias formas de solucionar un mismo problema. Por lo tanto, no hay una solución mágica para migrar toda una cuenta de AWS o bajar costos directamente sin riesgos.
Migrar no es un "Ctrl+C / Ctrl+V", es una cirugía mayor. Un error clásico es intentar mover todo de golpe, en nuestro caso resolvimos el problema por etapas (En AWS se conoce como waves). Al hacer todos los cambios de una sola vez, es muy probable que aparezcan errores y nadie quiere experimentar problemas en producción... ¿Cierto?
Los recursos se deben migrar por fases debido a su interdependencia. Por ejemplo, para asignarle un dominio a un load balancer es necesario tener un certificado SSL/TLS validado, normalmente a través de Route 53. Este certificado se debe emitir en la región de destino, no basta que solo esté en la región de origen. El certificado debe ser validado también, comúnmente a través de un Record CNAME en Route 53. Una sucesión lógica es:
- Tener una Hosted Zone en Route 53
- Emitir un certificado SSL/TLS utilizando AWS ACM
- Validar un dominio asignado a un Load Balancer con certificado
Por otro lado, es imprescindible auditar el código de las aplicaciones. Si los endpoints apuntan explícitamente a recursos de la región original, las aplicaciones fallarán tras la migración. A menudo, el código está fuertemente acoplado a la infraestructura regional.
Ejemplo:
import os
import boto3
import pymysql
# ❌ HARDCODED ISSUE: Pointing explicitly to Sao Paulo ('sa-east-1')
# If RDS migrates to Ohio ('us-east-2'), this host points to the wrong/dead DB!
RDS_HOST = "example-db.sa-east-1.rds.amazonaws.com"
CURRENT_REGION = "sa-east-1" # os.getenv("AWS_REGION", "sa-east-1")
# 💥 FAILS HERE after migration: Connecting to dead sa-east-1 endpoint
pymysql.connect(host=RDS_HOST, *credentials)
La solución es desacoplar la lógica de conexión a variables de entorno o Parameter Store. El código no necesita saber dónde vive, solo necesita hacer las preguntas adecuadas:
Con variables de entorno, el código se ve así:
RDS_HOST = os.getenv("RDS_HOST")
CURRENT_REGION = os.getenv("AWS_REGION", "us-east-2")
Con parameter store, el código se ve así:
RDS_HOST = parameter_store.get("RDS_HOST")
CURRENT_REGION = parameter_store.get("AWS_REGION", "us-east-2")
El cliente también tenía otras necesidades especiales. En este caso, se nos pidió crear otra cuenta para un entorno de desarrollo, considerar una VPN Site-2-Site con GCP y permitir su conectividad con las VPCs de las nuevas cuentas.
Revisamos la topología de redes: Cómo se conectan los aplicativos entre ellos, los security groups que existen y en qué subnets se encuentran las bases de datos y workers.
A partir de este análisis, se encontraron varias oportunidades de ahorro a nivel de infraestructura: Limpieza de buckets de S3, snapshots y volúmenes EBS. Upgrade de instancias de T2 a T3. Upgrade de gp2 a gp3. Unificación de load balancers. Upgrade de instancias de RDS a graviton (instancias t4g, m7g).
Summary of Infrastructure Optimizations
| Categoría | Legacy/Anterior (costo mensual/unidad) | Optimizado/Actual (costo mensual/unidad) | Ahorro/Ventaja |
|---|---|---|---|
| EC2 Instances | t2.medium ($33.87) | t3.medium ($30.37) | 10.3% menor |
| EBS Storage | GP2 ($0.10/GB) | GP3 ($0.08/GB) | 20% ahorro |
| RDS Database | db.t3 ($59.86) | db.t4g ($47.45) | 20.7% ahorro |
Fuentes:
AWS EC2 Pricing
AWS RDS Pricing
AWS Elastic Load Balancing Pricing
AWS Well-Architected Framework - Cost Optimization
Fase 2: Migrando con Terraform. De ClickOps a IaC usando IA:
Una vez consideradas las necesidades del cliente y determinado cuál es el estado objetivo de los recursos, hay que hacer un roadmap. Si migramos únicamente la infraestructura, nos quedamos con instancias sin aplicaciones, bases de datos sin información de producción y buckets de S3 sin objetos.
Por esto, primero debe crearse la infraestructura en la cuenta destino. El orden de creación de la infraestructura debe ser algo como:
- Route 53
- ACM
- VPC
- Subnets
- Security Groups
- EC2
ACM necesita validación de Route 53. Las subnets necesitan existir en una VPC. Los security groups están dentro de una VPC, etc. Con esto tenemos la capa de infraestructura lista.
Una vez creadas las instancias u otro recurso que contiene lógicas de negocio (EC2, ECS, Lambda), desplegamos el código de los procesos. Con eso ya tenemos la capa de aplicación. Por otra parte, respecto a los datos, estos se migran a RDS, DynamoDB o S3 utilizando servicios como DMS.
Para realizar esta migración, considerando que se requería crear una cuenta de desarrollo y a la vez replicar la infraestructura, se utilizó IaC con terraform. Para esto, programamos un conjunto de scripts que toma la infraestructura viva en AWS y genera código en terraform que permite replicar el estado de la nube.
Cabe destacar que la IA se equivocó numerosas veces tratando de transformar el código vivo en Terraform. Lo que hicimos fue iterar múltiples veces creando un software determinístico. Tratamos de utilizar programas como terraformer o aws2tf, pero no obtuvimos los resultados esperados, puesto que no captaban bien dependencias o el conjunto de recursos asociados en Terraform (por ejemplo, una API Gateway tiene rutas, resources, api keys, authorizers, etc).
Con esta réplica fue casi directo crear tres entornos a la vez, uno de desarrollo, staging y producción, puesto que se trató de un copy/paste con ciertos ajustes (variables de entorno, parámetros, ARNs, etc)
Con el código de Terraform listo, utilizamos agentes de IA para auditar la infraestructura activa e identificar oportunidades de ahorro. Como ya habíamos realizado una inspección manual previa, usamos este ejercicio para validar el criterio de la IA. El resultado fue muy certero en optimizaciones estándar —como el upgrade de familias de instancias o la eliminación de volúmenes EBS obsoletos—, pero mostró sus límites al pasar por alto decisiones de arquitectura más complejas, como la unificación de ALBs o la consolidación de NAT Gateways. Por otra parte, también realizamos mejoras de orden, seguridad y privacidad. Generamos un playbook de prompts para revisar con IA los security groups, la topología de redes y la conexión entre los aplicativos. En estos playbooks incluimos también optimizaciones de seguridad. Es una buena práctica reutilizar security groups de acuerdo con la documentación oficial de VPC Security Groups. Además, aprovechan el AWS Hyperplane.
La IA también nos ayudó a determinar el orden en qué realizar la migración, las dependencias que deben usarse y a renombrar masivamente strings como ARNs (sa-east-1 a us-east-2, por ejemplo). Si una aplicación llama a SQS, una lambda o usa una base de datos en particular, este caso debe listarse y hay que preparar tanto el código fuente como las dependencias para la migración.
Una vez creada la infraestructura masivamente con terragrunt, tocó la puesta en marcha de migración de datos y aplicaciones. Los datos pudieron migrarse con servicios como DMS (Database Migration Service) con un downtime prácticamente nulo. Los aplicativos se desplegaron desde 0 a través de la ejecución de pipelines CI/CD modificadas para funcionar en las nuevas regiones y en las distintas cuentas nuevas de AWS utilizando OIDC.
Resultados
Logramos un ahorro del 70% a partir de dos componentes:
- Migración de la infraestructura
- Optimización de recursos de infraestructura
El resultado no fue solo un ahorro del 70%. Entregamos un sistema que ahora es:
- Auditable: Todo está en código. Si quieres saber qué cambió hace 3 meses, se puede ver en Git.
- Optimizado: Eliminamos recursos sin uso y modernizamos los motores de bases de datos.
- Seguro: Modernizamos el software y aseguramos que la topología de redes fuera lo más cerrada posible sin afectar el funcionamiento normal de las aplicaciones.
El cliente mantiene el dominio de todo el código y la propiedad intelectual. Sus aplicaciones están funcionando correctamente e indica estar satisfecho con los resultados. Además, le hacemos seguimiento a diario en caso de encontrar errores, incluyendo soporte.
Fork sigue siendo cliente de Frust y sigue contratando el producto de Savings Plans manejados automáticamente. Debido a la migración y a la baja de costos, los Savings Plans anteriores fueron ajustados para evitar sobreprovisionamiento. No hubo ninguna especie de lock-in por parte de los Savings Plans.
Si quieres saber más de lo que hacemos en Frust, visitia nuestra página en Frust. Reducimos tus costos de manera rápida y segura sin compromisos y sin lock-in a través del manejo inteligente de Savings Plans.
