Caso · Movilidad y transporteEn producción

Gennos

Migración y nueva infraestructura en AWS para la plataforma de movilidad y transporte de Gennos: más de 15 servicios en contenedores, con foco en seguridad y costos.

  • Terraform
  • ECS Fargate
  • WAF
  • ElastiCache
El desafío

Qué había que resolver

Gennos es una plataforma de movilidad y transporte. Detrás de sus aplicaciones corren muchas piezas: APIs, sincronizadores de datos, back-office, servicios de datos de transporte en formato GTFS (horarios y tiempo real), planificación de viajes, geocodificación y automatizaciones.

Había que mover todo eso a una infraestructura nueva en AWS, ordenada y reproducible, sin perder la base de datos existente, con los servicios internos fuera de internet y con una factura que no creciera sin control.

La solución

Qué construimos

Infraestructura nueva, toda como código

Redes, balanceadores, cómputo, caché, almacenamiento, WAF y permisos escritos en Terraform, organizados en módulos y con el estado remoto cifrado y con bloqueo.

Más de 15 servicios en contenedores

APIs, back-office, web, sincronizadores, servicios GTFS, planificador de viajes (OpenTripPlanner), geocodificación (Nominatim), feature flags y automatizaciones con n8n, cada uno como servicio de ECS Fargate.

Lo interno, privado

Un balanceador público para lo que ven los usuarios y otro interno para las APIs de back-office y tiempo real; los procesos en segundo plano corren en subnets privadas.

Migración sin perder datos

La nueva plataforma se conectó a la base de datos existente, para mover los servicios por etapas sin migrar los datos de golpe.

Seguridad en el borde

AWS WAF con las reglas administradas de AWS y límite de pedidos por IP frente al balanceador público.

Costos bajo control

Ajustes de FinOps sobre la marcha: endpoints de VPC en una sola zona, retención de logs acotada, métricas de CloudWatch solo donde aportan y tareas dimensionadas a su uso real.

Arquitectura

Cómo se arma en AWS

PiezaServicio de AWS
CómputoAmazon ECS + AWS FargateMás de 15 servicios sin servidores que administrar, cada uno con su CPU y memoria.
EntradaApplication Load Balancer (público e interno)Separa lo que se expone a internet de las APIs internas.
ProtecciónAWS WAFReglas administradas contra ataques comunes y rate limiting por IP.
Comunicación entre serviciosAWS Cloud MapDescubrimiento de servicios por DNS privado dentro de la VPC.
CachéAmazon ElastiCache (Valkey)Caché administrada con cifrado en tránsito (TLS).
Datos persistentesAmazon EFSVolúmenes compartidos con un access point por servicio (planificador, geocodificación, automatizaciones).
Configuración y secretosAWS Systems Manager Parameter StoreVariables de cada servicio fuera del código, inyectadas al desplegar.
Tráfico privado a AWSVPC endpointsECR, S3, CloudWatch Logs y SSM sin salir a internet.
ImágenesAmazon ECRRegistro privado de las imágenes propias y de terceros.
ObservabilidadAmazon CloudWatch + Grafana / PrometheusLogs centralizados y tableros de monitoreo para el equipo.
Decisiones clave

Lo que hace la diferencia

  1. 01

    Estado de Terraform remoto, cifrado y con bloqueo

    El estado vive en S3, cifrado y con lockfile: nadie pisa los cambios de otro y no hay archivos sueltos en una computadora.

  2. 02

    Dos balanceadores en lugar de uno

    Las APIs de back-office y de tiempo real se movieron a un balanceador interno: no quedan expuestas a internet.

  3. 03

    Ahorro sin resignar operación

    Cada ajuste de costos se evaluó contra lo que aporta: por ejemplo, endpoints en una zona en lugar de tres y métricas detalladas solo donde se usan.

  4. 04

    Acceso administrativo controlado

    Las herramientas de administración y monitoreo se acceden por VPN, no desde internet.