Arquitectura AWS, modelada en UML

El familiar es un lienzo de iconos de servicios con líneas entre ellos. Es genuinamente bueno en una cosa - mostrar qué productos están en juego a alguien que ya sabe qué hacen esos productos - y por eso toda presentación de AWS contiene uno.

Lo que no lleva es dirección, protocolo, puerto, ni si una línea significa "llama por la red" o "lo configura". Esos cuatro son todo el contenido de una revisión de seguridad, y son lo que alguien mirando una alerta a las tres de la mañana intenta reconstruir. Un diagrama de despliegue los lleva, a costa de parecerse menos a un folleto.

Tres cosas de la figura de cabecera merecen copiarse a la tuya, y ninguna va de AWS.

1. La región es una caja, no una etiqueta. El anidamiento es la relación de contención, así que la pregunta de frontera - qué está dentro de eu-central-1 y qué no - la responde la geometría en vez de una leyenda. Que el navegador esté fuera es el hecho más importante del diagrama.
2. Cada ruta lleva un protocolo y un puerto."HTTPS", "TCP 5432". Una línea sin etiquetar entre un balanceador y un servicio es una línea que nunca se ha contrastado con un grupo de seguridad.
3. El artefacto va dentro del nodo que lo ejecuta. api.jar dentro del servicio Fargate, y no al lado con una flecha. Qué está desplegado dónde es la pregunta para la que existe esta clase de diagrama.

Lo que falta a propósito: IAM, CloudWatch, Secrets Manager, la pasarela NAT. Todos son reales y ninguno es participante de una ruta de petición: son configuración, y ponerlos en el diagrama duplica su tamaño sin responder a ninguna pregunta que alguien haya hecho.

Este es el diagrama que hace la arquitectura en la nube revisable en vez de solo documentada. La Order API depende de IOrderStore e IFileStore; los adaptadores nombran los productos. Todo lo que está por encima de los adaptadores es portable por construcción, y todo lo que no lo es cabe en dos cajas que puedes contar.

Es además la mitad que no cambia cuando cambia la infraestructura. Pasa de ECS a EKS, o de eu-central-1 a dos regiones, y la figura de cabecera se redibuja mientras esta queda intacta, que es la razón práctica para tenerlas separadas en vez de fundirlas en una sola imagen impresionante.

El mismo tratamiento aplicado a una tienda está en la arquitectura de comercio electrónico, modelada, y la cuestión de las fronteras de servicio se lleva más lejos en el ejemplo de microservicios.