Una arquitectura cloud AWS para empresas es un sistema que sostiene operaciones críticas (facturación, inventario, decisiones) con personas dependiendo de él todos los días. No es una aplicación alojada en la nube: es infraestructura de negocio, y lo que decide si sirve no es la lista de servicios elegidos, sino si cada decisión técnica responde a una restricción real del negocio. Diseño esas plataformas empezando por el diagnóstico y no por el catálogo: primero la restricción (costo, velocidad, control o riesgo), después el cómputo, luego la integración con los sistemas que la empresa ya usa y, solo donde aporta valor medible, la IA. Con ese criterio diseñé una plataforma corporativa que hoy usan alrededor de 250 personas en cinco países, una integración de SAP, RPA y APIs que recuperó cerca de USD 90.000 en eficiencia, y un caso de IA aplicada a recursos humanos con unos USD 120.000 de ahorro operativo.
¿Por qué 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.
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é es una plataforma empresarial (y qué no lo es)?
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.
¿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: carga intermitente o dirigida por eventos
Elijo 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: procesos constantes y control del runtime
Elijo 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 para gestionar el servidor
Elijo EC2 cuando hay una razón concreta para gestionar el servidor yo mismo: licenciamiento, software que exige la máquina, cargas muy específicas. 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.
¿Cómo se integra una plataforma nueva con SAP y sistemas legacy?
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: event-driven con capa anti-corrupción
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.
Ese principio aplicado a un ERP legado está en cómo extender SAP ECC sin exponerlo. Un caso concreto es exponer un SAP ECC como API sin exponer el ERP: una capa anti-corrupción que publica capacidades de negocio en lugar de funciones RFC. Su contraparte de controles (autenticación máquina a máquina, autorización por objeto y protección de la disponibilidad del ERP) está en seguridad de una API B2B sobre SAP.
Qué se gana: USD 90.000 en una integración de SAP y RPA
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.
¿Cuándo aporta valor la IA aplicada y cuándo es ruido?
La parte incómoda de una guía honesta sobre IA es admitir cuándo no usarla. La automatización tradicional, con reglas fijas y 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.
Las tres preguntas 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.
Qué se gana: USD 120.000 en un proceso de recursos humanos
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é fracasa una buena arquitectura 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 en AWS?
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.