Los pilares de buena arquitectura que comparten los tres proveedores
AWS, Google Cloud y Azure publican cada uno su marco de buena arquitectura y dicen casi lo mismo. Sirven menos como checklist y más como una forma de discutir decisiones: cada pilar es una pregunta que obliga a explicitar qué se está resignando.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
Los tres proveedores publican un marco de buena arquitectura, con sus pilares, sus preguntas y su herramienta para hacer revisiones. Es fácil leerlo como una lista para tildar antes de una auditoría.
Sirve para otra cosa. Los pilares se contradicen entre sí a propósito: más disponibilidad cuesta más plata, más seguridad agrega fricción, más rendimiento suele agregar complejidad operativa. El marco no dice qué hacer: obliga a decir qué se resignó y por qué.
Los pilares, y qué pregunta hace cada uno
| Pilar | La pregunta | Qué se resigna al maximizarlo |
|---|---|---|
| Excelencia operativa | ¿Podemos desplegar, observar y recuperar sin heroísmo? | Velocidad inicial: automatizar cuesta antes de rendir |
| Seguridad | ¿Quién puede hacer qué, y cómo nos enteramos? | Fricción para el equipo que desarrolla |
| Confiabilidad | ¿Qué pasa cuando esto falla, y cuánto tardamos en volver? | Costo: la redundancia se paga esté o no en uso |
| Eficiencia de rendimiento | ¿Estamos usando el servicio adecuado para esta carga? | Simplicidad: lo más eficiente suele ser lo más específico |
| Optimización de costos | ¿Estamos pagando por lo que usamos? | Margen ante picos y esfuerzo de ajuste continuo |
| Sustentabilidad | ¿Cuánto recurso desperdiciamos? | Poco: casi siempre va junto con el costo |
Las tensiones, con números
El pilar más caro de sostener es el de confiabilidad, y vale la pena verlo como lo que es: una compra. Se compran nueves y se pagan en infraestructura ociosa.
99.9600 %
17 min por mes de caída esperada
A esta altura la fórmula deja de describir el sistema real: lo que manda ya no es la probabilidad de cada pieza sino lo que falla junto, como un despliegue o un cambio de configuración.
Antes de seguir, predecí
Cómo se hace una revisión que sirva
El formato que funciona
- Un sistema por vez, no toda la plataforma: las preguntas sólo tienen respuesta concreta sobre algo concreto.
- Con las personas que lo operan, no sólo con quien lo diseñó. La distancia entre el diagrama y la realidad aparece ahí.
- Anotar riesgos, no tareas: “una caída de zona nos deja afuera cuatro horas” es un riesgo con dueño; “configurar multi-zona” es una tarea sin contexto.
- Clasificar en alto y medio, y aceptar explícitamente los que no se van a resolver. Un riesgo aceptado por escrito es una decisión; uno no anotado es una sorpresa futura.
- Repetir cuando cambia algo grande, no cada trimestre por calendario.
Las herramientas nativas —AWS Well-Architected Tool, las recomendaciones de Advisor en Azure y las de Active Assist en Google Cloud— sirven para la parte mecánica: detectan lo que se puede detectar mirando la configuración. Lo que no detectan es lo único que importa de verdad: si el negocio tolera o no lo que esa arquitectura implica.
Más a fondo · nivel seniorCuando el marco se usa mal
Dos formas conocidas de arruinarlo:
- Como auditoría de cumplimiento. Si la revisión se percibe como una evaluación del equipo, las respuestas se maquillan y el ejercicio deja de tener valor. La revisión es para encontrar riesgos, no para calificar a nadie.
- Como excusa para sobre-diseñar. Los pilares empujan siempre hacia arriba: más redundancia, más controles, más automatización. Aplicados sin la pregunta del costo del fallo, producen sistemas multi-región para aplicaciones que atienden a veinte personas. El marco tiene un pilar de costos precisamente para frenar eso, y es el que más se ignora.
El uso maduro es al revés: usar los pilares para encontrar dónde se está gastando de más en confiabilidad que nadie pidió, y mover ese presupuesto a donde el fallo sí duele.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica