Arquitectura AWS, modelada en UML
El diagrama de AWS habitual es un muro de iconos de servicios que dice qué productos has comprado. Este es el otro tipo: dos diagramas que dicen qué puede alcanzar qué, por qué puerto, y qué partes son tuyas y reemplazables.
8 min de lecturaUML 2.5.123 de 23
01Two kinds of AWS diagram
The familiar one is a canvas of service icons with lines between them. It is genuinely good at one job - showing which products are in play to somebody who already knows what those products do - and it is why every AWS deck contains one.
What it does not carry is direction, protocol, port, or whether a line means "calls over the network" or "is configured by". Those four are the entire content of a security review, and they are what somebody staring at an alert at 3am is trying to reconstruct. A deployment diagram carries them, at the cost of looking less like a brochure.
02Reading the topology
Three things on the hero figure are worth copying into your own, and none of them is about AWS.
- The region is a box, not a label. Nesting is the containment relationship, so the boundary question - what is inside eu-central-1 and what is not - is answered by geometry rather than by a legend. The browser being outside it is the most important fact on the diagram.
- Every path carries a protocol and a port."HTTPS", "TCP 5432". An unlabelled line between a load balancer and a service is a line that has never been checked against a security group.
- The artifact sits inside the node that runs it.
api.jarinside the Fargate service, rather than beside it with an arrow. What is deployed where is the question this diagram kind exists for.
What is deliberately absent: IAM, CloudWatch, Secrets Manager, the NAT gateway. Every one is real and none of them is a participant in a request path - they are configuration, and putting them on the diagram doubles its size while answering no question anybody asked.
03The same system without the vendors
This is the diagram that makes cloud architecture reviewable rather than merely documented. The Order API depends on IOrderStore and IFileStore; the adapters name the products. Everything above the adapters is portable by construction, and everything that is not portable is in two boxes you can count.
It is also the half that does not change when the infrastructure does. Move from ECS to EKS, or from eu-central-1 to two regions, and the hero figure is redrawn while this one is untouched - which is the practical reason to keep them apart rather than merging them into one impressive picture.
In one line each
- 01Icon diagrams name products; deployment diagrams name paths, protocols and ports.
- 02Draw the region as a containing node - nesting is the boundary, no arrow needed.
- 03Label every communication path with its protocol and port, or it has not been checked.
- 04Put artifacts inside the node that executes them.
- 05Leave IAM, logging and secrets off: they are configuration, not participants.
- 06Keep the component view separate - it survives the re-platforming that invalidates the topology.
The same treatment applied to a shop is in e-commerce architecture, modelled, and the service-boundary question is taken further in the microservices example.
04Preguntas frecuentes
¿Un diagrama de arquitectura AWS debe ir en UML o con iconos de AWS?
Ambos, para lectores distintos. El diagrama de iconos es mejor para vender y para incorporar a alguien, porque todo el mundo reconoce los productos; un diagrama de despliegue UML es mejor documento de trabajo, porque nombra protocolos, puertos y direcciones, que es lo que preguntan una revisión de seguridad y una incidencia a las tres de la mañana.
¿Cómo se dibuja una VPC o una región en UML?
Como un nodo que contiene a los demás, dibujado anidándolos dentro. La relación es la contención misma, así que no hace falta flecha, y la pregunta de la frontera - qué queda dentro de la región y qué fuera - se ve en la imagen en vez de en una leyenda.
¿Hay que dibujar todos los servicios de AWS que usamos?
No, y dibujarlos todos es lo que vuelve inservibles estos diagramas. Incluye un servicio si un camino de petición lo atraviesa o si guarda estado que tendrías que migrar; deja fuera lo que es configuración y no participante, como IAM, CloudWatch o Secrets Manager.
¿Cómo evitar que un diagrama cloud quede obsoleto tras una migración?
Pártelo en dos. La vista de componentes nombra contratos de los que depende tu código y sobrevive intacta a un cambio de plataforma; solo la vista de despliegue tiene que cambiar, con lo que un redibujado completo se convierte en editar un diagrama.
Lecturas relacionadas