ConTodo
Consultor Senior — Consolidación DevOps & AWS (Entregable Final)

ConTodo ERP — Arquitectura AWS Cloud-Native: Infraestructura, HA/DR, CI/CD, IaC y Modelo de Costos Consolidado

ConTodo ERP — Plataforma Cloud-Native en AWS (Entregable Consolidado)

Propósito del entregable. Definir la arquitectura de infraestructura definitiva y reconciliada de ConTodo, un ERP SaaS multi-tenant (Rails + PostgreSQL + Redis/Sidekiq + React) sobre AWS. Consolida el documento del agente DevOps & AWS (10), lo alinea con el contrato del Solution Architect (07) y resuelve las contradicciones y subestimaciones identificadas en la crítica técnica Big Four (debate 02). Cubre: diagrama de infraestructura, red y seguridad, HA/DR, CI/CD, IaC (Terraform) y un modelo de costos consolidado —que ahora sí incluye IA y BI— para MVP, 100, 500, 1.000 y 5.000 clientes.

Anti-overclaiming. Las cifras de costo son supuestos de planeación sobre precios públicos de AWS (~junio 2026), no una factura. Se presentan en dos vistas: infra base (el modelo original de DevOps) y TCO realista (infra + IA + BI, según el ajuste del partner de tecnología). Deben revalidarse trimestralmente con FinOps y contra factura real. Ninguna decisión es gratis: cada una se justifica y se contrastan alternativas.

0. Decisiones reconciliadas (resumen del ADR maestro aplicado)

La crítica técnica (debate 02) identificó 8 contradicciones entre los siete documentos escritos en paralelo. Este entregable las cierra con decisiones vinculantes. Se documentan aquí para que la infraestructura no se construya sobre supuestos divergentes.

#Tema en disputaDecisión consolidada en este entregableImpacto en infra
C1Región AWS primaria (us-east-1 vs sa-east-1)us-east-1 primaria por costo; sa-east-1 (São Paulo) como región de residencia para tenants Enterprise que lo exijan (SKU Soberanía). DR en us-west-2.Modelo de costos en us-east-1; multiplicador +25–40% si un tenant exige sa-east-1.
C2Nombre de columna tenanttenant_id canónico (no company_id).Policies RLS, índices y particionado usan tenant_id.
C3Tipo de tenant_idBIGINT interno (PK, sharding, RLS) + UUID público expuesto.current_setting('app.current_tenant')::bigint en RLS.
C4/C6Bus de eventos / stack BIUn solo pipeline en MVP: Outbox transaccional → EventBridge. CDC (Debezium/Kafka/MSK) diferido a Fase 3. BI en MVP = batch nocturno dbt + DuckDB/S3.Elimina MSK/Redshift/Cube del MVP; se costean como Fase 2–3.
C5API REST vs GraphQL / SSRREST + OpenAPI. SPA pura, sin SSR. Se corrige la terminología "render server-side" del doc DevOps.ALB enruta /api/* a Rails API; estáticos desde S3/CloudFront.
C7Silo EnterpriseSilo = RDS dedicada (vía Rails connects_to) compartiendo el cluster ECS por defecto; ECS dedicado solo en SKU Soberanía.SKU Enterprise con RDS aparte; ECS común salvo soberanía.
C8Costo de IABedrock managed (Claude/Haiku) en MVP; Llama self-host en GPU solo en SKU Soberanía. Se añade línea de IA al modelo de costos.Nueva línea de costo IA en la vista TCO.
RT1Aislamiento pooler + RLSMandato: toda query en transacción con SET LOCAL app.current_tenant; test de aislamiento a través de RDS Proxy.Riesgo de seguridad nº 1; condiciona el uso de RDS Proxy.

Conclusión de gobierno. La infraestructura descrita a continuación asume estas decisiones. El binomio RDS Proxy + RLS (RT1) es el riesgo más alto del proyecto y se trata en §3.4 con detalle operativo.

1. Principios de diseño y supuestos de capacidad

1.1 Principios rectores

  1. Multi-tenant por esquema compartido (Shared Schema + RLS), no por infra física. Todos los tenants comparten clúster Rails y RDS; aislamiento por tenant_id + Row-Level Security en PostgreSQL. Maximiza densidad y margen. Enterprise con aislamiento estricto → silo dedicado (RDS propia vía connects_to) como SKU premium.
  2. Stateless compute, stateful gestionado. Contenedores Rails/Sidekiq efímeros (Fargate); todo el estado en servicios gestionados (RDS, ElastiCache, S3). Escala horizontal sin sesiones pegajosas (sesiones en Redis/JWT).
  3. IaC como única fuente de verdad. Cero cambios manuales en consola fuera de incidentes. Terraform versionado con plan revisado en cada PR.
  4. Seguridad por defecto. Cifrado en reposo (KMS) y tránsito (TLS 1.2+), secretos en Secrets Manager, WAF al borde, mínimo privilegio IAM.
  5. Costo consciente del SaaS (FinOps). Fargate Spot para workers async, Savings Plans para baseline, Graviton (r6g/r7g), S3 Intelligent-Tiering, autoscaling agresivo. El modelo de costos es un único artefacto que incluye IA y BI.
  6. Superficie operativa mínima en MVP. Equipo de 4–6 ingenieros. Se difieren MSK, Redshift, Cube y Llama-VPC. La complejidad operativa es una restricción de primer orden.

1.2 Supuestos de capacidad

SupuestoValorJustificación
Tenant = persona jurídica (RUC)1 RUC = 1 tenantN sucursales, N almacenes, N usuarios por tenant
Usuarios activos por cliente (promedio)8PYME textil/comercial típica (5–50 usuarios)
Distribución de cargaPower-law: 5% de tenants = ~50% cargaMedianas/distribuidoras con alto volumen de CPE
Ratio usuarios concurrentes25%Pico horario laboral Perú (GMT-5)
RPS por usuario concurrente0,3ERP transaccional, no streaming
Tamaño DB por cliente (año 1)0,8–1,5 GBDocumentos, kardex, asientos; adjuntos en S3
Jobs Sidekiq por cliente/día200–600CPE, PLE/SIRE, BI, correos
Región primariaus-east-1Menor precio; latencia Perú ~90 ms aceptable
Región residencia Enterprisesa-east-1 (São Paulo)SKU Soberanía; +25–40% costo
Región DRus-west-2Replicación cross-region para RPO/RTO
SLA objetivo99,9% MVP → 99,95% madurez≈8,76 h/año downtime en MVP
RPO / RTORPO ≤ 5 min (PITR) / RTO ≤ 1 h EnterpriseDatos contables/tributarios irrecuperables
Equipo inicial4–6 ingenieros + SRE antes de 500 tenantsComplejidad operativa = restricción dura

Soberanía de datos. Perú no exige residencia local para ERP comercial, pero Ley 29733 y SUNAT obligan a confidencialidad y trazabilidad. Se mantiene us-east-1 por costo; sa-east-1 o AWS Local Zone Lima disponibles para Enterprise que lo exija contractualmente.

2. Diagrama de arquitectura AWS

2.1 Componentes y su rol

ComponenteServicio AWSFunción en ConTodo
DNSRoute53app.contodo.pe, api.contodo.pe, failover DR
CDN/EdgeCloudFront + ACM + ShieldCache SPA React, TLS, compresión, geo, DDoS
Firewall L7AWS WAFOWASP Top 10, rate limiting por tenant, geo-block, bot control
BalanceoALBDistribución a tasks ECS, health checks
Compute webECS Fargate (Rails/Puma)API REST (OpenAPI), auth, RLS por tenant
Compute asyncECS Fargate (Sidekiq)CPE, PLE/SIRE, correos, BI batch, IA
Pooling DBRDS ProxyMultiplexa conexiones; clave para SET LOCAL de tenant (ver §3.4)
Base de datosRDS PostgreSQL 16 Multi-AZOLTP multi-tenant, RLS por tenant_id, particionado
Réplica lecturaRDS Read ReplicaReportes BI y Estados Financieros pesados
Silo EnterpriseRDS dedicadaTenants con aislamiento físico (SKU premium)
Cache/ColaElastiCache RedisCache, sesiones, broker Sidekiq, rate limit
ObjetosS3SPA estática, CPE/XML/CDR SUNAT, backups lógicos
Bus de eventosEventBridgeOutbox relay (integraciones, webhooks)
SecretosSecrets ManagerCredenciales DB, certificados SUNAT, tokens OSE, rotación
ObservabilidadCloudWatch + X-RayLogs, métricas, trazas, alarmas, dashboards, costo/tenant
Backup/DRAWS BackupSnapshots cifrados, copia cross-region
CifradoKMSCMK por dominio (DB, S3, Redis); BYOK en SKU Soberanía

3. Red y seguridad

3.1 Topología VPC

  • VPC 10.0.0.0/16 en us-east-1, en 2 AZ (us-east-1a/b); se amplía a 3 AZ desde 1.000 clientes.
  • Subnets públicas (/24): ALB y NAT Gateway. Sin instancias con IP pública.
  • Subnets privadas app (/22): tasks Fargate (web + worker) + RDS Proxy. Salida a internet solo vía NAT.
  • Subnets privadas datos (/24): RDS, RDS Silo y ElastiCache, sin ruta a internet.
  • VPC Endpoints (Gateway/Interface) para S3, ECR, Secrets Manager, CloudWatch Logs y Bedrock: evita tráfico por NAT y reduce egreso.

3.2 Controles de seguridad (defensa en profundidad)

CapaControl
BordeWAF managed rules (Core, SQLi, Linux), rate limit 2.000 req/5min/IP + rate-limit por tenant, geo-allow LATAM+EEUU, Shield
TransporteTLS 1.2+ en CloudFront/ALB/RDS, HSTS, certificados ACM auto-renovados
IdentidadCognito o JWT propio + refresh corto; MFA para admins de tenant; RBAC+ABAC multirol; IAM roles por servicio (sin llaves estáticas)
DatosKMS CMK, RLS PostgreSQL por tenant_id, cifrado de columnas sensibles (DNI, cuentas), certificados SUNAT en Secrets Manager
SecretosSecrets Manager con rotación automática de credenciales RDS cada 30 días
RedSecurity Groups mínimos (ALB→web:3000, web/worker→RDS Proxy:5432, web→Redis:6379); SSM en vez de SSH
AuditoríaCloudTrail org-wide, GuardDuty, Security Hub, Config rules; tabla audit_logs append-only con hash chain + WORM
ComplianceLey 29733; readiness SOC 2 / ISO 27001 (logging, control de acceso, cifrado por diseño)

3.3 Aislamiento multi-tenant (capas)

3.4 RT1 — El binomio RDS Proxy + RLS (riesgo nº 1)

Hallazgo crítico de la crítica técnica. PgBouncer/RDS Proxy en modo transaction multiplexa conexiones físicas entre requests. Una variable de sesión mal scopeada (SET en vez de SET LOCAL) puede filtrar el contexto de un tenant a otro — un evento de extinción de marca para un ERP contable. Este riesgo no estaba resuelto en los documentos originales.

Mandato operativo (vinculante):

  1. SET LOCAL, nunca SET. El contexto de tenant se fija con SET LOCAL app.current_tenant = $1 dentro de una transacción explícita. SET LOCAL muere al cerrar la transacción, por lo que nunca persiste en la conexión reutilizada por el pooler.
  2. Toda query en transacción. Rails no envuelve lecturas en transacción por defecto. Se fuerza vía middleware/around_action que abre una transacción por request y fija el contexto. Sin transacción, no hay tenant → la policy RLS deniega por defecto (fail-closed).
  3. Default deny en RLS. La policy se escribe de modo que si current_setting('app.current_tenant', true) es NULL, la fila no es visible. Nunca "abierto por defecto".
  4. Test de aislamiento a través del pooler. El CI corre tests de aislamiento cross-tenant contra RDS Proxy, no solo contra Postgres directo, para reproducir la multiplexación real. Cobertura reportada como métrica de compliance.
  5. RDS Proxy en pinning-aware. Monitorear DatabaseConnectionsCurrentlySessionPinned; documentar qué statements causan pinning para evitar degradación silenciosa.

4. Estrategia CI/CD

4.1 Pipeline

  1. PR a main dispara: linters (RuboCop, ESLint), tests (RSpec, Jest, cobertura ≥80%), tests de aislamiento cross-tenant a través de RDS Proxy (RT1), SAST (Brakeman), escaneo de imagen (Trivy), npm/bundle audit, policy-as-code (checkov).
  2. Build de imagen Docker multi-stage (Ruby 3.3-slim sobre Graviton/arm64, assets React precompilados), tag SHA + semver, push a ECR con escaneo on-push.
  3. Migraciones como ECS one-off task antes del despliegue, con advisory lock anti-doble-ejecución. Expand/contract estricto + pg-osc para tablas grandes (ver §7.4): a 5.000 tenants un backfill afecta a todos a la vez, por lo que las migraciones online son obligatorias desde la primera tabla.
  4. Staging: despliegue automático tras merge + smoke tests.
  5. Producción: despliegue gated (aprobación manual). Blue-green con CodeDeploy. Canary 10% → validación de métricas (5xx, p95) → 100% con auto-rollback ante alarma CloudWatch.
  6. Infra: cada PR a Terraform corre plan comentado; apply solo tras aprobación en main vía OIDC (sin credenciales largas en GitHub).

5. Infraestructura como Código (Terraform)

Estructura modular, backend remoto S3 + bloqueo DynamoDB, ambientes separados por carpeta (dev, staging, prod).

# environments/prod/main.tf — extracto representativo
terraform {
  required_version = ">= 1.7"
  backend "s3" {
    bucket         = "contodo-tfstate-prod"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "contodo-tflock"
    encrypt        = true
  }
}

module "network" {
  source             = "../../modules/network"
  cidr               = "10.0.0.0/16"
  azs                = ["us-east-1a", "us-east-1b"] # +1c desde 1.000 tenants
  enable_nat_gateway = true
  vpc_endpoints      = ["s3", "ecr.api", "ecr.dkr", "secretsmanager", "logs", "bedrock-runtime"]
}

module "rds" {
  source                = "../../modules/rds"
  engine_version        = "16.3"
  instance_class        = "db.r6g.large"   # escala segun cohorte (Graviton)
  allocated_storage     = 200
  max_allocated_storage = 2000             # autoscaling de disco
  multi_az              = true
  read_replica_count    = 1
  backup_retention_days = 14
  kms_key_arn           = module.kms.rds_key_arn
  deletion_protection   = true
  performance_insights  = true
  enable_rds_proxy      = true             # RT1: pooling + SET LOCAL
}

module "ecs_web" {
  source            = "../../modules/ecs-service"
  cluster_arn       = module.ecs.cluster_arn
  family            = "contodo-web"
  cpu               = 1024          # 1 vCPU
  memory            = 2048          # 2 GB
  desired_count     = 4
  autoscaling_min   = 4
  autoscaling_max   = 40
  target_cpu_pct    = 60
  image             = "${module.ecr.repo_url}:${var.app_version}"
  capacity_provider = "FARGATE"     # web On-Demand/Savings Plan
}

module "ecs_worker_critical" {
  source            = "../../modules/ecs-service"
  family            = "contodo-sidekiq-critical"
  capacity_provider = "FARGATE"     # RT6: cola fiscal SIEMPRE On-Demand
  queues            = ["critical", "cpe", "sire"]
}

module "ecs_worker_async" {
  source            = "../../modules/ecs-service"
  family            = "contodo-sidekiq-async"
  capacity_provider = "FARGATE_SPOT" # reports/ai/email toleran interrupcion
  queues            = ["reports", "ai", "default", "low"]
  autoscaling_max   = 30
  scale_metric      = "sidekiq_queue_latency"
}

module "redis" {
  source          = "../../modules/elasticache"
  node_type       = "cache.r7g.large"
  num_node_groups = 1
  replicas_per_ng = 1
  multi_az        = true
  transit_enabled = true
  at_rest_enabled = true
}

Buenas prácticas IaC. Variables por ambiente en tfvars cifrados (SOPS/KMS), terraform fmt/validate/tflint en CI, módulos versionados, prevent_destroy en RDS/S3 de estado, checkov para policy-as-code. Cambio clave vs doc original: la cola critical se separa en su propio service On-Demand (RT6) para que una interrupción Spot no deje un CPE o asiento a medias.

6. Alta disponibilidad y Disaster Recovery

6.1 Objetivos

MétricaMVP/PymeEnterprise
RPO (pérdida máx. de datos)1 hora5 minutos
RTO (tiempo máx. de recuperación)4 horas1 hora
SLA disponibilidad99,9%99,95%

6.2 HA por componente

ComponenteHA
RDSMulti-AZ (failover ~60–120 s) + PITR (RPO ≤ 5 min) + snapshots diarios
ECSTasks en ≥2 AZ tras ALB, health checks, blue-green sin downtime
RedisElastiCache Multi-AZ con réplica + auto-failover
S3Durabilidad 11 nueves + versioning + CRR
ALB / NATMulti-AZ por diseño

6.3 Estrategia de respaldo

  • RDS: snapshots automáticos + PITR retención 14 días; logs de transacción → RPO de minutos. Copia a us-west-2 vía AWS Backup (cross-region, KMS multi-región).
  • S3: versioning + CRR a us-west-2; lifecycle → Glacier para XML/CDR > 1 año (SUNAT exige conservar CPE 5 años; nunca borrado físico).
  • Redis: snapshots diarios (cache reconstruible, no crítico para RPO).
  • Backup por tenant: export lógico filtrado por tenant_id programado (Sidekiq) → S3, para soportar export/eliminar datos (Ley 29733, derecho al olvido). Pendiente de diseño detallado — deuda técnica reconocida.
  • IaC: estado + módulos reconstruyen la infra completa en región DR en < 1 h.

6.4 Patrón DR

  • Warm Standby (Enterprise): RDS read replica cross-region promovible + ECS service mínimo (1 task) en us-west-2, Route53 failover health-check.
  • Pilot Light (Pyme): solo datos replicados; compute on-demand vía Terraform ante desastre (RTO ~2–4 h).
  • Game days trimestrales: simulacro de promoción de réplica y failover Route53, con runbook.

7. Escalado

7.1 Horizontal (preferente)

  • ECS web: Target Tracking sobre CPU 60% y RequestCountPerTarget del ALB. Min 4, max 40 tasks (cubre MVP → 5.000 clientes).
  • ECS Sidekiq: escalado por latencia de cola (métrica custom). Cola critical (fiscal) en On-Demand; reports/ai en Spot (RT6).
  • RDS Read Replicas: 1 → 3+ réplicas para BI/EEFF.

7.2 Vertical (cuando aplica)

  • RDS: db.r6g.large → r6g.xlarge → r6g.2xlarge → r6g.4xlarge. RDS Proxy obligatorio desde 100 clientes (Rails abre muchas conexiones).
  • Redis: r7g.large → r7g.xlarge; cluster mode (sharding) desde ~1.000 clientes.

7.3 Particionado y sharding

  • Particionado por tenant_id (LIST/HASH) en tablas calientes (comprobantes, kardex_movimientos, asientos_contables) desde MVP. Limitación reconocida: la distribución power-law crea particiones desbalanceadas; no resuelve el noisy-neighbor del tenant gigante — la mitigación real es promoverlo a Silo.
  • Sharding por cohorte y/o Aurora PostgreSQL Serverless v2 a 5.000+. ADR de sharding con métrica gatillo (ej. CPU RDS >70% sostenido en instancia máxima) y dueño RACI requerido antes de 500–1.000 tenants — no "a futuro".

7.4 Migraciones a escala (deuda técnica priorizada)

A 5.000 tenants una migración corre sobre tablas compartidas de cientos de millones de filas y afecta a todos a la vez. Mandato: expand/contract + pg-osc (online schema change para Postgres) desde la primera tabla + runbook de ventana de mantenimiento.

8. Observabilidad y FinOps

  • CloudWatch Logs centralizados (Fargate awslogs), retención 30 días + export a S3/Athena.
  • Métricas custom: latencia colas Sidekiq, tiempo de CPE por tenant, errores SUNAT, p95 por endpoint, costo de IA (tokens) y de infra por tenant.
  • Trazas: AWS X-Ray cross-service.
  • Alarmas: 5xx > 1%, p95 > 800 ms, CPU RDS > 80%, cola Sidekiq > 5 min, free storage RDS < 15%, RDS Proxy session pinning, AWS Budgets de costo. → SNS → Slack/PagerDuty.
  • Dashboards: App, DB, Colas, Costos/Margen por tenant (identifica candidatos a silo/upsell). SLO 99,9%.

9. Modelo de costos consolidado (USD/mes)

Precios públicos AWS us-east-1, ~junio 2026. Incluye Savings Plans para baseline de cómputo. Excluye soporte AWS, IGV 18% (factura Perú) y descuentos plurianuales. Rango ±20%. Dos vistas: (A) infra base; (B) TCO realista con IA + BI, según el ajuste de la crítica técnica.

9.1 Vista A — Infraestructura base

ServicioMVP (~5)1005001.0005.000
ECS Fargate web601805209503.800
ECS Fargate Sidekiq (Spot+On-Demand)30802404501.800
RDS PostgreSQL Multi-AZ1302906201.1504.200
RDS Read Replica(s)0702204802.100
RDS Proxy0153045120
ElastiCache Redis50902304301.500
S3 (storage + req)52590180750
CloudFront (transfer)10351302501.100
ALB2025354590
NAT Gateway35457095220
Route53 + ACM345610
WAF + Shield12183045120
Secrets Manager48152560
EventBridge (outbox)152040180
CloudWatch + X-Ray1540110200700
AWS Backup + CRR103090170650
KMS346820
Data transfer out830110210900
Subtotal infra base3969942.5714.77918.320
Buffer/contingencia 15%591493867172.748
TOTAL infra base~455~1.143~2.957~5.496~21.068

9.2 Vista B — TCO realista (infra + IA + BI)

Corrección clave de la crítica técnica (debate 02 §2.3). El modelo original omitía IA y BI —los diferenciadores que el negocio va a vender— y subestimaba RDS a 5.000 tenants ~2–3x. Esta vista los incorpora. En MVP, IA y BI son mínimos (Bedrock managed + batch dbt/DuckDB); MSK/Redshift/Cube/Llama-VPC se difieren y aparecen solo desde escala media.

ConceptoMVP (~5)1005001.0005.000
Infra base (Vista A, sin buffer)3969942.5714.77918.320
Ajuste RDS realista a escala (sharding/Aurora)00+300+1.500+5.500
IA — Bedrock (Claude/Haiku, tokens)301507001.8006.000
IA — Llama VPC GPU (solo SKU Soberanía)0006002.000
BI — batch dbt + DuckDB/S3 (MVP→media)540200400900
BI — Kafka/MSK (CDC, Fase 3)0001.2002.200
BI — Redshift/DW (Fase 3)0001.5003.500
BI — Cube (capa semántica)000300700
Subtotal TCO4661.2243.97114.37939.120
Buffer/contingencia 15%701845962.1575.868
TOTAL TCO realista~536~1.408~4.567~16.536~44.988

9.3 Costo por cliente y margen

MétricaMVP1005001.0005.000
Costo/cliente — infra base~91~11,4~5,9~5,5~4,2
Costo/cliente — TCO realista~107~14,1~9,1~16,5*~9,0
Margen infra (pricing $25–40/cliente)bajo (MVP)~70%~75%~60%*65–75%

* El salto a 1.000 refleja la activación de MSK + Redshift + GPU (Fase 3). Si el batch satisface latencia BI < 5 min, no introducir Kafka/Redshift y el TCO a 1.000 cae a ~$6.500/mes (margen >75%).

9.4 Lectura del modelo

  • Economías de escala reales pero más modestas que el modelo original: el costo/cliente cae a ~$9 (no $4) a 5.000 cuando se cuentan IA y BI. Margen realista 65–75%, no >80%. Sigue siendo sano para SaaS B2B con pricing $25–40.
  • RDS es el mayor centro de costo (~25–30%). Optimizaciones: Aurora Serverless v2, Graviton (~20% más barato), Reserved Instances (hasta 40% off, 1 año).
  • IA es la línea más volátil: depende de adopción y de tokens. Medidor de costo por tenant (CloudWatch) imprescindible para no erosionar margen.
  • Diferir MSK/Redshift/Cube/Llama-VPC mantiene el MVP y la escala media operables por un equipo de 4–6 y ahorra $1.500–6.000/mes hasta que el batch deje de ser suficiente.

9.5 Configuración de cómputo por cohorte (referencia)

CohorteRDSRead ReplicasRedisECS webECS SidekiqIABI
MVPdb.t4g.medium (Multi-AZ prod)0t4g.small21Bedrock Haikudbt+DuckDB nocturno
100db.r6g.large + Proxy1r7g.large42Bedrock Claude/Haikudbt+DuckDB
500db.r6g.xlarge + Proxy1r7g.large85Bedrockdbt+DuckDB/S3
1.000db.r6g.2xlarge (eval Aurora)2r7g.xlarge149Bedrock + GPU (soberanía)eval CDC/Cube
5.000r6g.4xlarge + sharding / Aurora3+r7g.xlarge cluster3628Bedrock + Llama-VPCMSK+Redshift+Cube

10. Riesgos, alternativas y recomendaciones

10.1 Riesgos

RiesgoSeveridadMitigación
Fuga cross-tenant vía RDS Proxy + RLS (RT1)CríticaSET LOCAL en transacción, default-deny RLS, tests de aislamiento a través del pooler, monitoreo de pinning
Costo real 2–3x por IA+BI ausentesAltaModelo TCO consolidado (§9.2), gate FinOps antes de activar BI/IA en prod
Spot interrumpe jobs fiscalesMedia-AltaCola critical/cpe/sire SIEMPRE On-Demand (RT6)
Sharding sin disparador ni dueñoAltaADR de sharding con métrica gatillo + RACI antes de 500–1.000 tenants
Migración a escala bloquea a 5.000 tenantsAltapg-osc + expand/contract + runbook desde día 1
Doble pipeline de eventos (outbox + CDC)AltaUn solo pipeline en MVP (outbox→EventBridge); CDC solo si BI exige < 5 min
Equipo de 4–6 opera 15+ serviciosAltaReducir superficie MVP; contratar SRE antes de 500 tenants
RDS dispara margen a escalaMediaReserved Instances, Graviton, Aurora Serverless v2, sharding
Conexiones DB saturadas (Rails)AltaRDS Proxy obligatorio desde 100 clientes
Compliance SOC2/ISO con 1 Security EngMedia-AltavCISO + Vanta/Drata, presupuestado en P&L
Latencia Perú (~90 ms)Bajo-MedioCloudFront edge Lima; Local Zone si Enterprise lo exige
Pérdida de CPE (SUNAT 5 años)CríticaS3 versioning + CRR + lifecycle Glacier; nunca borrado físico
Caída SUNAT/OSEMedioReintentos con backoff, colas de reproceso, alertas

10.2 Alternativas evaluadas

  • ECS Fargate vs EKS: Fargate por menor overhead operativo (equipo de 6). EKS se reconsidera a > 2.000 clientes.
  • RDS vs Aurora: inicio con RDS PostgreSQL (más barato/simple); Aurora Serverless v2 a evaluar a escala — debe pre-modelarse porque cambia el modelo de costos completo.
  • Outbox→EventBridge vs CDC/Kafka: Outbox en MVP (ya captura cambios; alimenta BI batch sin Kafka). CDC/Kafka solo en Fase 3 si la latencia BI < 5 min lo exige.
  • AWS Copilot/App Runner: descartados frente a Terraform (control multi-ambiente + policy-as-code).
  • Multi-cloud: no en Fase 1. Portabilidad como seguro, no objetivo.

10.3 Recomendaciones priorizadas

  1. Semana 0–2 (bloqueante): ADR maestro (región, tenant_id BIGINT, bus de eventos único, fasing BI/IA), validar RT1 (pooler + RLS), modelo de costos TCO consolidado entregado a Finanzas.
  2. Día 1: VPC multi-AZ, RDS Multi-AZ + RDS Proxy, IaC Terraform, CI/CD con OIDC + tests de aislamiento, WAF, Secrets Manager, cola critical On-Demand. No diferir seguridad.
  3. Desde 100 clientes: read replica, Savings Plans, AWS Budgets, SLO formal, medidor de costo por tenant.
  4. Desde 500: cross-region DR (warm standby), FinOps mensual, Reserved Instances, SRE dedicado, vCISO + Vanta/Drata, ADR de sharding.
  5. Desde 1.000: evaluar Aurora, 3 AZ, decidir CDC sí/no según latencia BI real, diseño de promoción shared→silo.

11. Conclusión

La arquitectura de ConTodo es cloud-native, multi-AZ, segura por defecto y económicamente escalable, y ahora —tras la reconciliación de los siete documentos técnicos— internamente coherente: una sola región primaria (us-east-1), un tenant_id canónico (BIGINT), un único pipeline de eventos en MVP (outbox→EventBridge) y un modelo de costos consolidado que sí cuenta IA y BI.

Parte de ~$455/mes de infra base en MVP ($536 con IA/BI mínimos) y soporta 5.000 clientes por ~$21.000/mes de infra base o ~$45.000/mes en TCO realista con BI + IA completos ($9/cliente). El margen de infraestructura realista es 65–75% —no el >80% optimista del modelo original—, aún sano para un SaaS B2B con pricing de $25–40/cliente.

El riesgo número uno no es técnico de capacidad sino de aislamiento: el binomio RDS Proxy + RLS debe validarse con SET LOCAL transaccional y tests a través del pooler antes de escribir la primera tabla — de materializarse una fuga cross-tenant en un ERP contable, sería un evento de extinción de marca. Con ese control validado, la disciplina de IaC, CI/CD gated, DR warm-standby y observabilidad con SLO 99,9% sostiene operación confiable a escala LATAM. Las cifras son supuestos de planeación y deben revalidarse cada trimestre contra factura real con prácticas FinOps.

ConTodo ERP — Arquitectura de Software: Bounded Contexts (DDD), Event-Driven, API-First y PatronesConTodo ERP — Colección Consolidada de Diagramas de Arquitectura (Mermaid)