Tabla de Contenidos
- Introducción
- El Ecosistema de Herramientas del Arquitecto
- Las Leyes de Contención en AWS
- Arquitectura Monocapa: El Prototipo
- El Motor de Alta Disponibilidad
- Arquitectura de Tres Capas: El Estándar Empresarial
- Anatomía de un Flujo Serverless
- Matriz de Arquitecturas: Eligiendo el Modelo Correcto
- La Mente del Arquitecto: El Flujo Completo
- El Toque Final: Documentación Integrada
- Conclusión
Introducción
Si alguna vez te sentaste frente a draw.io o Lucidchart a "dibujar tu arquitectura" y terminaste con un plato de espaguetis de flechas sin sentido... este artículo es para ti.
Diagramar en AWS no es solo arrastrar íconos al lienzo. Es un ejercicio de pensamiento arquitectónico donde cada caja, cada flecha y cada borde cuenta una historia sobre cómo fluyen los datos, cómo se aíslan los componentes y cómo sobrevive tu sistema cuando algo falla.
En esta guía vamos a recorrer desde las herramientas que necesitas hasta los patrones arquitectónicos más comunes, pasando por las reglas de contención que todo diagrama profesional debe respetar.
El Ecosistema de Herramientas del Arquitecto
Antes de dibujar la primera línea, necesitas dos cosas: los activos correctos y el lienzo adecuado.
Los Activos
Para mantener un estándar profesional, evita íconos genéricos. AWS publica un paquete oficial de íconos de arquitectura que puedes descargar buscando "AWS architecture icons". Este paquete incluye kits para PowerPoint (PPTX) y archivos SVG que puedes usar directamente en tus herramientas de diagramación.
El Lienzo
Las dos plataformas certificadas más populares son:
- draw.io — Gratuita y open source. Asegúrate de habilitar el paquete "AWS 2026" en la sección "Más formas" (More shapes) para acceder a las versiones más recientes de los íconos.
- Lucidchart — Opción premium con colaboración en tiempo real y bibliotecas de AWS integradas.
Las Leyes de Contención en AWS
Antes de colocar un solo servidor, debes trazar los cimientos. Toda infraestructura AWS sigue una jerarquía estricta de aislamiento y red que debe reflejarse en los grupos y marcos de tu diagrama.
Este es el Modelo de Contención, de afuera hacia adentro:
Cuenta AWS
└── Región
└── VPC (Virtual Private Cloud)
└── Zonas de Disponibilidad (AZs)
├── Subred Pública
├── Subred Privada
└── Subred Privada
Cada nivel de esta jerarquía representa un límite de aislamiento. Tu diagrama debe mostrar claramente estos límites usando marcos anidados, porque si alguien no puede distinguir qué está en una subred pública vs. privada con solo mirar el diagrama, entonces el diagrama no está cumpliendo su función.
Arquitectura Monocapa: El Prototipo
Esta es la arquitectura más simple posible. Ideal para pruebas o aplicaciones muy simples.
Todo el sistema — interfaz, lógica y base de datos — reside en una sola instancia EC2 dentro de una subred pública, accesible a través de un Internet Gateway.
Flujo del diagrama
Usuario → Internet Gateway → EC2 (Frontend + Lógica + Base de Datos)
Componentes
| Componente | Ubicación |
|---|---|
| Frontend | EC2 (subred pública) |
| Lógica de negocio | EC2 (subred pública) |
| Base de datos | EC2 (subred pública) |
Contenedores del diagrama
- VPC → marco exterior (línea continua verde)
- AZ → marco intermedio (línea punteada azul)
- Subred Pública → marco interior (línea continua naranja)
⚠️ Advertencia: Esta arquitectura tiene alta vulnerabilidad. Si la Zona de Disponibilidad falla, la aplicación entera se cae. No tiene redundancia ni escalabilidad. Úsala solo para prototipos rápidos.
El Motor de Alta Disponibilidad
Para sobrevivir a caídas de infraestructura, la arquitectura debe evolucionar. Se introducen dos componentes clave:
- Application Load Balancer (ALB): Distribuye el tráfico entre múltiples Zonas de Disponibilidad.
- Auto Scaling Group (ASG): Crea nuevas instancias automáticamente ante picos de demanda.
Falla Única vs. Alta Disponibilidad
Sin HA: Un usuario llega al Internet Gateway → una sola EC2 en una sola AZ. Si esa AZ cae, todo cae.
Con HA: El usuario llega al ALB → este distribuye tráfico a instancias EC2 en la Zona A y la Zona B. El Auto Scaling Group gestiona la cantidad de instancias según la demanda.
Cómo diagramarlo
La clave visual es mostrar dos Zonas de Disponibilidad lado a lado, cada una con sus propias instancias EC2, y el ALB como punto de entrada centralizado. El Auto Scaling Group se representa como un marco que envuelve las instancias EC2 que administra.
Arquitectura de Tres Capas: El Estándar Empresarial
Aquí se separan los componentes para maximizar la seguridad. Solo los servidores web residen en la subred pública. La lógica de negocio y la base de datos se ocultan en subredes privadas, protegidas del acceso directo a internet.
Las tres capas
| Capa | Componente | Subred | Acceso |
|---|---|---|---|
| Web | EC2 Web Server | Pública | Expuesta vía ALB |
| Aplicación | EC2 Application Server | Privada 1 | Solo accesible desde la capa web |
| Base de Datos | Amazon RDS | Privada 2 | Solo accesible desde la capa de aplicación |
Flujo del diagrama
Usuario → Internet Gateway → ALB → EC2 Web Server (Subred Pública)
↓
EC2 App Server (Subred Privada 1)
↓
Amazon RDS (Subred Privada 2)
Alta disponibilidad incluida
Cada capa se replica en dos AZs. La base de datos usa replicación sincrónica entre la instancia primaria (Database) y la instancia de respaldo (Standby) en la segunda AZ.
💡 Tip para el diagrama: Usa columnas para representar las AZs y filas para las capas. Esto crea una grilla visual intuitiva donde es fácil identificar tanto la redundancia horizontal como la separación de capas vertical.
Anatomía de un Flujo Serverless
Desaparecen los servidores físicos y las subredes complejas. El arquitecto ahora orquesta servicios administrados. El usuario carga la web estática desde S3 vía CloudFront, y las interacciones se procesan mediante APIs que disparan funciones Lambda conectadas a DynamoDB.
El flujo paso a paso
| Paso | Origen | Destino | Descripción |
|---|---|---|---|
| 1 | Usuario | Amazon Route 53 | Resolución DNS |
| 2 | CloudFront | Amazon S3 | Sirve el frontend estático (HTML/Assets) |
| 3 | Frontend | Amazon API Gateway | Llamadas al backend |
| 4 | API Gateway | AWS Lambda | Ejecución de código (Node.js/Python) |
| 5 | Lambda | Amazon DynamoDB | Operación de base de datos vía IAM Role |
Cómo diagramarlo
A diferencia de las arquitecturas con EC2, aquí no dibujas VPCs ni subredes (a menos que Lambda esté configurada dentro de una VPC). El flujo es lineal de izquierda a derecha, numerando cada paso para guiar al lector.
💡 Tip: Los diagramas serverless se leen como una línea de tiempo. Numera cada conexión para que la secuencia sea obvia.
Matriz de Arquitecturas: Eligiendo el Modelo Correcto
Un buen diagrama comienza con la elección correcta del patrón. Evalúa los requisitos de disponibilidad, el presupuesto de mantenimiento y la necesidad de escalabilidad antes de arrastrar el primer ícono al lienzo.
| Criterio | Monocapa | Tres Capas | Serverless |
|---|---|---|---|
| Complejidad de configuración | Baja | Alta | Media |
| Esfuerzo de mantenimiento | Alto | Alto | Bajo |
| Escalabilidad | Manual / Limitada | Automática (Auto Scaling) | Infinita y Nativa |
| Servicios clave | EC2 | EC2, RDS, ALB | Lambda, API Gateway, DynamoDB |
| Caso de uso ideal | Prototipos rápidos | Aplicaciones empresariales tradicionales | Microservicios modernos |
La tabla anterior no es solo una referencia técnica — es la primera decisión que defines antes de abrir tu herramienta de diagramación.
La Mente del Arquitecto: El Flujo Completo
Dibujar no es el primer paso. El diseño efectivo de arquitecturas AWS requiere un enfoque sistemático donde la lógica empresarial dicta la ubicación espacial de cada componente en el lienzo.
Los 6 pasos del flujo
- Definir Requisitos — ¿Alta disponibilidad? ¿Serverless? ¿Cuál es el presupuesto?
- Configurar Herramientas — Seleccionar draw.io o Lucidchart y cargar los íconos oficiales 2025.
- Trazar Cimientos — Dibujar los límites de VPC, Región y AZs.
- Ubicar Cómputo y Datos — Posicionar EC2, Lambda, RDS en sus subredes correspondientes.
- Mapear el Flujo — Conectar con flechas desde el usuario hasta la base de datos.
- Anotar y Documentar — Añadir numeración, etiquetas y descripciones.
La clave es que los pasos 1 y 2 ocurren antes de tocar el lienzo. Si te saltas la fase de requisitos, terminarás redibujando todo.
El Toque Final: Documentación Integrada
Un diagrama profesional debe explicarse por sí mismo. No te limites a conectar líneas. Agrega:
- Etiquetas claras en cada componente
- Roles de seguridad (IAM) cuando sean relevantes
- Secuencias numeradas para indicar el orden del flujo de datos
Por ejemplo, en un flujo serverless, una anotación como "La función Lambda (Python) asume un rol de IAM para consultar datos en DynamoDB" transforma una simple flecha entre dos íconos en una historia comprensible para cualquier persona del equipo.
🎯 El objetivo final no es solo dibujar infraestructura, sino contar la historia de cómo fluyen los datos.
Conclusión
Diagramar arquitecturas AWS es una habilidad que combina pensamiento técnico con comunicación visual. Recuerda estas reglas fundamentales:
- Usa siempre los íconos oficiales — la profesionalidad empieza por los activos.
- Respeta la jerarquía de contención — Cuenta → Región → VPC → AZ → Subred.
- Elige el patrón antes de dibujar — Monocapa, Tres Capas o Serverless.
- Sigue el flujo sistemático — Requisitos → Herramientas → Cimientos → Cómputo → Flujo → Documentación.
- Documenta dentro del diagrama — Etiquetas, roles IAM y secuencias numeradas.
Un buen diagrama no solo describe tu infraestructura: la defiende, la comunica y la documenta para todo tu equipo.
¿Te resultó útil esta guía? Déjame un 🦄 o un 💬 con tu experiencia diagramando en AWS.
Si quieres profundizar en algún patrón específico o ver un caso práctico con draw.io, házmelo saber en los comentarios.
Sígueme para más contenido sobre AWS y arquitectura cloud. ☁️
Top comments (0)