La arquitectura correcta no empieza en AWS
Casi todas las conversaciones sobre arquitectura cloud empiezan mal. Empiezan por el catálogo: Lambda o ECS, RDS o DynamoDB, esta o aquella cola. Es la parte divertida, y por eso la hacemos primero. Pero elegir servicios antes de entender el problema es como escoger materiales antes de saber qué se va a construir.
Una arquitectura cloud AWS para empresas no es una app puesta en la nube. Es un sistema que sostiene operaciones críticas —facturación, inventario, decisiones— con gente real dependiendo de él todos los días. Y lo que decide si ese sistema sirve no es la lista de servicios: es si cada decisión técnica responde a una restricción real del negocio.
Este artículo recorre cómo diseño esas plataformas. No es teoría reempaquetada de la documentación oficial; es cómo pienso el problema, con las decisiones que tomé, lo que descarté, y lo que costó. Al final hay un caso concreto y las tres ramas donde profundizo: arquitectura AWS, IA aplicada e integraciones empresariales.
Qué significa una plataforma empresarial (y qué no)
Una plataforma empresarial es un sistema cloud-native diseñado para operar con múltiples usuarios, procesos interdependientes y datos que otros sistemas consumen, bajo requisitos explícitos de disponibilidad, costo y control. No es un sitio web con backend; es infraestructura de negocio.
La diferencia práctica está en tres exigencias que una app normal no tiene: tiene que escalar sin reescribirse, tiene que integrarse con lo que la empresa ya usa (ERP, sistemas legacy, hojas de cálculo que llevan diez años funcionando), y tiene que degradarse con gracia cuando algo falla, porque siempre algo falla. Diseñar para eso desde el día uno es lo que separa una plataforma de un prototipo con suerte.
Los seis pilares, aterrizados en decisiones
AWS resume las buenas prácticas en el Well-Architected Framework: excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costos y sostenibilidad. Es una referencia sólida. El problema es que casi siempre se cita como una lista y se olvida.
Un pilar solo vale cuando se convierte en una decisión con consecuencia. Así se ve la diferencia:
| Pilar | Decisión concreta | Consecuencia |
|---|---|---|
| Seguridad | Recursos críticos en subredes privadas, acceso solo por rol | Superficie de ataque mínima; ningún dato sensible expuesto a internet |
| Optimización de costos | Serverless donde la carga es intermitente | Se paga por uso real, no por servidores encendidos de noche |
| Fiabilidad | Distribución en varias zonas de disponibilidad | Un fallo de zona no tumba la operación |
| Eficiencia | Colas entre servicios para absorber picos | El sistema no se cae en el cierre de mes; encola y procesa |
La regla que sigo: si no puedo nombrar la consecuencia de una decisión, todavía no entendí la decisión. Ese rigor de convertir una regla en algo verificable es el mismo que aplico a la arquitectura de software con fitness functions ejecutables, pruebas que impiden que el diseño se erosione con cada cambio.
Cómputo: cuándo elijo Lambda, ECS o EC2
La pregunta no es “cuál es mejor”, es “qué exige esta carga”. El criterio se reduce a tres factores: patrón de tráfico, control que necesito sobre el entorno, y costo del arranque en frío.
- Lambda cuando la carga es intermitente o dispar. Procesos que corren por eventos —un archivo que llega, un mensaje en cola, una petición esporádica— donde pagar por servidores encendidos permanentemente sería absurdo. Es también donde más rápido llego de idea a producción.
- ECS / contenedores cuando el proceso es constante, necesita control fino del runtime, o el arranque en frío de Lambda molesta. Trabajos largos, servicios con estado de conexión, dependencias pesadas.
- EC2 cuando hay una razón concreta —licenciamiento, software que exige la máquina, cargas muy específicas— para gestionar el servidor yo mismo. Cada vez menos, pero existe.
Un ejemplo real de este criterio llevado al extremo: construí un lakehouse analítico serverless sobre Lambda y DuckDB, donde la carga analítica intermitente hacía que pagar por un clúster encendido no tuviera sentido. La decisión de cómputo salió de la forma del problema, no de una preferencia.
Datos e integración: conectar lo que ya existe
Aquí es donde la mayoría de proyectos empresariales se complican, porque ninguna empresa parte de cero. Hay un ERP, hay SAP, hay sistemas legacy que nadie quiere tocar y que aún así tienen que hablar con lo nuevo.
El patrón que uso es event-driven con una capa anti-corrupción: los sistemas de origen emiten eventos, una capa intermedia los traduce al lenguaje del nuevo sistema, y nada del legacy contamina el diseño moderno. AWS ofrece varias vías —AppFlow, Glue con OData, conectores nativos ABAP, o Bedrock cuando entra IA— pero la elección concreta importa menos que el principio: desacoplar para que un cambio de un lado no obligue a reescribir el otro.
Integrar bien no es glamoroso, pero es donde se gana o se pierde el proyecto. En una integración de SAP, RPA y APIs sobre un portal corporativo, la eficiencia recuperada rondó los USD 90.000, no por una tecnología brillante, sino por eliminar el trabajo manual de mover datos entre sistemas que antes no se hablaban.
IA aplicada: dónde suma y dónde es ruido
La parte incómoda de una guía honesta sobre IA es admitir cuándo no usarla. La automatización tradicional —reglas fijas, predecibles— sigue siendo la respuesta correcta para la mayoría de los procesos estables. La IA gana cuando hay que interpretar, clasificar con ambigüedad, o decidir sobre múltiples variables que una regla estática no captura.
El criterio que aplico antes de meter un modelo:
- ¿El proceso tiene excepciones que las reglas no cubren? Si no, automatización clásica y listo.
- ¿Hay datos suficientes y confiables? Sin esto, cualquier modelo es teatro. La credibilidad del dato es condición previa, no un detalle; escribí sobre cómo se construye esa confianza en los datos porque es el punto donde más proyectos de IA fracasan.
- ¿El error del modelo es tolerable o la persona sigue en el bucle para la parte crítica? El patrón seguro es que la IA prepare, proponga o alerte, y una persona decida.
Cuando esas condiciones se cumplen, el impacto es real. En un proceso de recursos humanos, aplicar IA para eliminar tareas repetitivas de análisis y clasificación produjo cerca de USD 120.000 de ahorro operativo. Y en analítica, reemplazar tableros tradicionales por consulta conversacional —preguntarle a los datos en lenguaje natural en vez de navegar dashboards— cambió quién puede obtener una respuesta y cuándo. Ese mismo enfoque de predicción aplicada aparece en cómo abordé la predicción de margen con SageMaker Autopilot: IA donde el problema la justifica, no donde queda bien en la presentación.
Un caso real: una plataforma que usan 250 personas
La teoría se sostiene o se cae con un sistema en producción. Diseñé una plataforma corporativa que hoy usan alrededor de 250 personas en cinco países. Vale la pena recorrerla no por las cifras, sino por las decisiones detrás.
El problema original no era técnico: procesos dispersos en herramientas que no se hablaban, con costo de licencias creciendo y datos que nadie confiaba. La restricción dura era doble —bajar el costo operativo y unificar sin frenar a nadie durante la transición.
Las decisiones que definieron la arquitectura:
- Multi-tenant desde el diseño, para que cinco países operaran sobre la misma plataforma sin duplicar infraestructura ni fugarse datos entre ellos.
- Serverless en las cargas intermitentes, para pagar por uso real y no por capacidad ociosa.
- Integración event-driven con los sistemas existentes, para migrar por partes en vez de un corte de riesgo total.
El resultado medible: ahorro en licencias, un costo operativo que bajó de forma sostenida, y —lo más difícil— adopción real. Porque una plataforma que nadie usa es un gasto, no un activo.
Por qué una buena arquitectura fracasa sin adopción
Esta es la lección que la documentación técnica nunca menciona: la mejor arquitectura del mundo fracasa si la organización no la adopta. Lo he visto y lo he escrito. Un sistema técnicamente impecable que la gente evita, porque nadie los convenció, porque el dato no les generaba confianza, o porque la nueva forma les pareció una imposición, es un fracaso de arquitectura tanto como un fallo de diseño.
Por eso trato la adopción como parte del diseño, no como un problema de “gestión del cambio” que viene después. Cómo se construye esa confianza —y por qué la desviación organizacional a veces es útil en lugar de un defecto a corregir— es un tema que me importa tanto como la arquitectura misma, porque es donde los proyectos técnicos realmente se ganan o se pierden.
Cómo evalúo un proyecto de modernización
Cuando alguien me plantea modernizar en AWS, no empiezo por la solución. Empiezo por estas preguntas:
- ¿Cuál es la restricción de negocio real —costo, velocidad, control, riesgo— que justifica el proyecto?
- ¿Qué sistemas tiene que seguir funcionando durante la transición?
- ¿Los datos son confiables hoy, o eso es lo primero que hay que resolver?
- ¿Dónde la IA aporta valor medible y dónde sería solo ruido caro?
- ¿Quién va a usar esto y qué haría falta para que lo adopte de verdad?
Si esas respuestas están claras, la arquitectura casi se dibuja sola. Si no lo están, ninguna elección de servicios lo va a arreglar.
Si estás evaluando una plataforma cloud, una integración con SAP o un caso de IA aplicada y quieres una lectura honesta —incluido cuándo no hacerlo—, puedes escribirme por LinkedIn. Diagnóstico primero; la tecnología después.