Johan Romero Aguirre

Ingeniero DevOps y Cloud · Azure · AWS · GCP

Johan Romero Aguirre

Infraestructura AWS que sigue en pie cuando cae una región.

Unos diez años construyendo plataformas para banca, seguros y energía. Diseño infraestructura en Terraform con alta disponibilidad, seguridad desde el diseño y costes bajo control, y documento por qué tomo cada decisión.

Ver el código en GitHub Recorrer los proyectos

Prueba el failover

Topología de dos regiones Los usuarios en Latinoamérica llegan a la región activa a través de Route 53. Aurora replica los datos de forma continua desde la región activa a la región en espera. Usuarios LATAM Route 53 us-east-1 Virginia En espera, 1 instancia sa-east-1 São Paulo Activa, 2–6 instancias Aurora
Región activa
sa-east-1
Datos perdidos
—
Interrupción
—

    Simulación ilustrativa de los pasos del runbook de failover. Los tiempos son objetivos de diseño (RPO menor a 1 minuto, RTO menor a 15 minutos), no una medición.

    Cinco proyectos, una plataforma

    Cada proyecto es Terraform que se puede desplegar, con su README de decisiones, tests que corren sin credenciales de AWS y un análisis de seguridad en cada pull request.

    • Multi-región con alta disponibilidadprojects/01-multi-region-ha-dr

      Aplicación en dos regiones con Aurora Global Database y conmutación por DNS. La región de espera funciona con capacidad mínima y escala durante el failover.

      Incluye runbook de failover y failback, un game day para medir RPO y RTO reales, y una contraseña de base de datos que nunca se escribe en el estado de Terraform.

      • Aurora Global
      • Route 53
      • ALB
      • ASG
      • WAF
      • KMS

      Abrir el proyecto

    • Pipeline serverless de pedidosprojects/02-serverless-order-pipeline

      Una Lambda en Python valida pedidos que llegan a S3, los registra en DynamoDB y los reparte a envíos, inventario y analítica mediante SNS y colas SQS.

      Idempotente ante duplicados, reintenta solo los mensajes con fallos transitorios y recupera eventos que no llegaron a publicarse. 22 tests con AWS simulado.

      • Lambda Python
      • EventBridge
      • SQS
      • SNS
      • DynamoDB

      Abrir el proyecto

    • Baseline de seguridad y gobiernoprojects/03-security-baseline

      Lo que se aplica a una cuenta antes de desplegar nada: auditoría que no se puede alterar, detección de amenazas, reglas de cumplimiento y alertas sobre cambios sensibles.

      17 reglas de AWS Config, 14 alertas del benchmark CIS, Security Hub, un permissions boundary para que los equipos creen sus roles sin escalar privilegios y SCPs de ejemplo.

      • CloudTrail
      • Config
      • GuardDuty
      • Security Hub
      • IAM

      Abrir el proyecto

    • FinOps automatizadoprojects/04-finops-automation

      Presupuestos con aviso por pronóstico, detección de anomalías de gasto y un informe semanal de volúmenes, IPs, snapshots e instancias que cuestan dinero sin aportar valor.

      El escáner nunca borra nada: informa del ahorro estimado y marca los recursos para que su dueño decida. Su rol solo puede escribir una etiqueta concreta.

      • Budgets
      • Cost Anomaly Detection
      • Lambda Python
      • Scheduler

      Abrir el proyecto

    • Observabilidad basada en SLOsprojects/05-observability

      Alertas que se disparan según lo rápido que se gasta el presupuesto de error, no por umbrales fijos. Dashboard por servicio, consultas de Logs Insights para incidentes y envío opcional de logs a OpenSearch.

      Cada alerta que despierta a alguien enlaza a un runbook, y los umbrales se verifican con tests.

      • CloudWatch
      • OpenSearch
      • Data Firehose

      Abrir el proyecto

    Cómo tomo decisiones

    La parte difícil de la infraestructura no es escribirla, es elegir qué no hacer. Estas son algunas de las decisiones registradas en el repositorio.

    Warm standby antes que activo-activo

    Con un RTO de 15 minutos, dos regiones aceptando escrituras duplican el coste y añaden conflictos que el negocio no necesita. Ver ADR

    Migrar desde CloudFormation sin recrear nada

    Los stacks estables se quedan como están. Lo que se migra entra con bloques import revisados en un pull request. Ver ADR

    Ninguna access key en la CI

    GitHub Actions obtiene credenciales temporales por OIDC: un rol de solo lectura para el plan y otro, tras aprobación manual, para el apply. Ver ADR

    Alertar sobre el impacto, no sobre el ruido

    Diez errores pueden ser nada o pueden ser todo, según el tráfico. Por eso las alertas miden el consumo del presupuesto de error. Ver ADR

    Qué buscar en el código

    Si estás evaluando un perfil de ingeniería cloud en AWS, aquí está dónde comprobar cada competencia.

    CompetenciaDónde verla
    Alta disponibilidad y recuperación multi-regiónProyecto 01, runbooks y game day
    Terraform modular, trazable y probadoMódulos vpc y app-stack, terraform test, plan comentado en cada PR
    Redes: VPC, subredes, NAT, endpointsMódulo vpc, con tres capas y una NAT por zona
    Seguridad: IAM, KMS, cifrado y auditoríaProyecto 03 y la política de mínimo privilegio de cada rol
    Lambda en PythonProyectos 02 y 04, con tests en pytest y moto
    Costes y eficiencia operativaProyecto 04 y etiquetas de coste en todos los recursos
    Monitoreo y logs con CloudWatch y ELKProyecto 05
    CI/CDWorkflows de GitHub Actions con Checkov, TFLint y OIDC

    Experiencia

    Plataformas cloud y DevSecOps para banca, seguros y energía, desde consultoras internacionales y equipos de producto. Además dirijo nimbodev, una consultora de cinco ingenieros senior.

    Dónde he trabajado

    • NTT Data
    • Indra, Centro de Excelencia DevSecOps
    • Smartjob
    • Slashmobility
    • Zoluxiones
    • Gloval Building

    Certificaciones

    • AWS Certified Cloud Practitioner
    • Azure Solutions Architect Expert (AZ-305)
    • Azure Network Engineer Associate (AZ-700)
    • Azure Administrator Associate (AZ-104)
    • Azure Virtual Desktop Specialty (AZ-140)
    • Azure Fundamentals (AZ-900)
    • LPIC-1