Para diseñar una arquitectura en AWS, empieza por lo que el sistema debe hacer y las condiciones con las que debe cumplir. A partir de ahí, compara opciones de cómputo, datos, integración y recuperación. No hay un patrón que sea el mejor para todas las cargas: el AWS Well-Architected Framework ayuda a sopesar las decisiones. Sus seis pilares son excelencia operativa, seguridad, confiabilidad, eficiencia del rendimiento, optimización de costos y sostenibilidad.
Para conocer esos pilares en formato de charla, puedes seguir La Amenaza del Nivel 100: AWS Well-Architected Framework, del canal AWS Women Colombia.
Define los requisitos antes de elegir servicios
Escribe qué resultado espera el usuario y cómo sabrás que funciona. Esa breve lista evita empezar por el servicio de moda y te ayuda a explicar por qué una opción encaja mejor que otra.
| Pregunta | Qué cambia en el diseño |
|---|---|
| ¿Qué parte debe responder en el momento y qué puede procesarse después? | Separa el camino que espera el usuario de los trabajos que pueden ejecutarse en segundo plano. |
| ¿Cuánto tiempo puede estar fuera el sistema y cuántos datos se podrían perder? | Define el tiempo máximo para restaurar el servicio (RTO) y cuánto tiempo de datos desde el último punto de recuperación se puede perder (RPO), antes de decidir redundancia, copias y recuperación ante desastres. La guía de confiabilidad de AWS explica estos objetivos. |
| ¿Cuándo y desde dónde llega la carga? | Un flujo irregular o con picos puede justificar colas y escalado automático; usuarios lejanos pueden cambiar la ubicación de cómputo o contenido. |
| ¿Qué datos maneja y dónde pueden almacenarse? | La residencia, sensibilidad, consistencia y retención de los datos limitan las regiones y los servicios posibles. |
| ¿Quién operará la solución y qué sabe mantener el equipo? | Compara el tiempo de operación que requiere cada alternativa con la experiencia y guardias disponibles. |
| ¿Qué límites de seguridad, cumplimiento y presupuesto hay? | Incluye identidad, permisos, cifrado, auditoría y seguimiento de consumo desde el diseño. |
El contexto importa: AWS describe el Well-Architected Framework como una forma de entender ventajas y desventajas de las decisiones, no como una receta única. Sus pilares permiten hacer explícitos los compromisos, por ejemplo, cuánto esfuerzo operativo o gasto adicional se acepta para cumplir un objetivo de recuperación.
Diseña la red con el contexto de uso
La latencia hacia usuarios, los enlaces con centros de datos y la segmentación del tráfico ayudan a decidir subredes, rutas y conexiones. La región más cercana no siempre es una elección válida si los datos deben permanecer en otra ubicación; evalúa ambas condiciones. Para seguir una charla de diseño de redes, mira AWS Networking - Diseña tu red en la nube de forma eficiente, del canal AWS User Group Guatemala. El AWS User Group Networking Colombia comparte encuentros técnicos sobre conectividad híbrida, redes entre cuentas y diseño de redes AWS. Para aprender los fundamentos de VPC, AWS Student Builder Group at Universidad Distrital tendrá una sesión virtual el 21 de octubre, de 18:00 a 20:00 en horario de Colombia.
Elige el modelo de cómputo según la carga
Una vez claros los requisitos, compara primero el modelo de ejecución. AWS mantiene una guía para elegir cómputo, una guía de servicios para contenedores y otras guías para evaluar servicios serverless; úsalas para contrastar tus requisitos y validar los límites actuales de cada servicio.
- Lambda: evalúala para funciones activadas por eventos o solicitudes, especialmente cuando el trabajo puede ejecutarse en unidades acotadas y el volumen varía. Reduce tareas de gestión de servidores, pero tienes que diseñar los reintentos, límites de concurrencia, observabilidad y efectos duplicados.
- Contenedores con ECS y Fargate: pueden encajar cuando necesitas empaquetar una aplicación con sus dependencias, ejecutar un servicio de larga duración o conservar un entorno de ejecución propio sin administrar servidores EC2. Aun así, el equipo prepara imágenes, tareas, despliegues y monitoreo. Para practicar una estrategia de despliegue gradual, el repositorio ECS Canary in Action tiene un recorrido local con Docker Compose y una ruta separada que crea recursos en AWS con Terraform. En Córdoba, el encuentro AWS Gaming Lab: ECS, CI/CD y la magia de Terraform será presencial en UTN Facultad Regional Córdoba el 10 de octubre, de 12:00 a 14:00.
- Contenedores con EKS: considera Kubernetes cuando sus APIs, herramientas o prácticas ya son una necesidad concreta del equipo. El plano de control administrado no elimina las decisiones sobre clústeres, red, seguridad y operación.
- EC2: conserva el control del sistema operativo y de la instancia. Puede ser adecuado para software heredado, agentes o configuraciones de host que no encajan en una opción más administrada; ese control también implica mantener y actualizar más componentes.
No es obligatorio que toda una aplicación use el mismo modelo. Por ejemplo, una API podría tener un servicio de larga duración y enviar a Lambda las tareas de procesamiento que se activan por eventos. Combinar modelos puede ser más claro que forzar una única tecnología, siempre que cada frontera tenga una razón y alguien pueda operarla.
Para comparar dos modelos de cómputo con otros participantes, el 16 de octubre habrá una sesión en línea «EC2 vs Lambda» de AWS User Group Tlaxcala FireflyCloud, de 16:00 a 17:00 en horario de Ciudad de México.
Ejemplo: procesar imágenes sin bloquear la solicitud
Imagina una aplicación que recibe imágenes y crea versiones reducidas. Si la persona que sube el archivo no necesita esperar el resultado, puedes separar la carga de archivos del procesamiento:
S3 de entrada
↓
SQS → Lambda → S3 de salida
↘ DynamoDB
(estado opcional)La aplicación deja el archivo en S3 y confirma que recibió la solicitud. Una notificación de S3 puede enviar el evento a SQS; un mapeo de origen de eventos permite que Lambda consuma mensajes de esa cola, genere las imágenes y guarde el resultado. La interfaz puede mostrar que el trabajo está pendiente y consultar su estado.
Esta elección tiene condiciones concretas:
- Usa el procesamiento directo si la respuesta necesita incluir el resultado y el tiempo de trabajo cabe en el camino síncrono. Usa una cola cuando el usuario pueda recibir una confirmación antes de terminar el trabajo.
- Los mensajes de una cola estándar pueden procesarse más de una vez. La guía de AWS para entrega al menos una vez en SQS recomienda consumidores idempotentes para que un mensaje repetido no cause cambios o notificaciones duplicados.
- Define qué hacer con fallos repetidos: reintentos y, si configuras la cola para ello, una cola de mensajes fallidos (DLQ) que permita al equipo investigar trabajos atascados.
- Separa los archivos originales de los resultados —por ejemplo, con buckets o prefijos distintos— para evitar que una función vuelva a activar el evento que ella misma genera; S3 documenta este riesgo de ciclos de notificación.
Si varias aplicaciones deben recibir y filtrar eventos, compara también EventBridge. La guía de AWS para arquitecturas orientadas a eventos explica el papel de colas, temas y buses de eventos. La forma apropiada depende de si necesitas retener trabajo, enviar un evento a varios consumidores o dirigirlo según reglas. Para profundizar en patrones EDA, sigue arquitecturas dirigidas por eventos en AWS y la grabación Introducción a arquitecturas orientadas a eventos y Amazon EventBridge, de Marcia en Desplegando Cloud. El AWS User Group Serverless Colombia también reúne encuentros sobre este espacio técnico. Allí habrá una sesión en línea sobre SQS y Lambda el 20 de octubre, de 19:00 a 21:00 en horario de Colombia.
Ajusta la resiliencia a la recuperación requerida
Decide primero qué interrupciones estás dispuesto a aceptar y cuánto tiempo puede tomar recuperar el servicio. Para una carga de producción, la guía de confiabilidad de AWS recomienda distribuir recursos entre al menos dos zonas de disponibilidad. Revisa también cómo replica o recupera datos el servicio elegido: tener cómputo en más de una zona no basta si el estado que necesita la aplicación depende de una sola.
Una segunda región es útil cuando el objetivo de negocio exige recuperar la carga ante una interrupción regional y las reglas de residencia de datos lo permiten. También requiere duplicar y operar recursos, configurar replicación y ensayar la conmutación. Si varias zonas de una región cumplen los objetivos acordados, una arquitectura multi-región puede añadir complejidad y costo sin resolver una necesidad real. AWS recomienda decidir entre multi-AZ y multi-región a partir de requisitos de resiliencia y recuperación. Para ampliar la comparación, continúa con arquitecturas de alta disponibilidad en AWS y arquitecturas multi-región en AWS.
La replicación ayuda a mantener datos disponibles en otra ubicación; no sustituye las copias de seguridad. AWS recomienda respaldar incluso los datos replicados y probar una restauración para cubrir borrados, cambios incorrectos u otros incidentes que también podrían propagarse a una réplica. Para contrastar el diseño con la comunidad, puedes ver Diseñando arquitecturas resilientes en AWS, del canal AWS UG Ecuador.
Si trabajas desde Argentina, el AWS User Group Córdoba presenta un espacio local para compartir experiencias sobre AWS y computación en la nube.
Tendencias que conviene evaluar con criterio
- Servicios administrados y serverless: delegan parte de la gestión de servidores y capacidad. Aportan valor cuando el equipo prioriza operar menos infraestructura y el modelo de ejecución cubre la carga. Evalúa también límites, reintentos, dependencia del proveedor y monitoreo.
- Procesamiento dirigido por eventos: permite que productores y consumidores avancen a ritmos distintos. Funciona bien cuando los pasos son asíncronos o independientes; exige manejar retrasos, duplicados, orden y diagnóstico distribuido.
- Contenedores y Kubernetes: estandarizan el empaquetado de aplicaciones. Kubernetes sirve cuando el equipo necesita ese ecosistema; adoptarlo por popularidad suma una plataforma que también hay que mantener.
- Infraestructura definida como código: ayuda a revisar y repetir cambios de infraestructura. En CloudFormation, por ejemplo, un conjunto de cambios (change set) muestra recursos que podrían agregarse, modificarse o reemplazarse antes de ejecutarlo; no garantiza que la actualización vaya a completarse. Si también necesitas evaluar la configuración y el cumplimiento, continúa con automatización de cumplimiento con AWS Config. Para encontrar una conversación práctica de gobierno en AWS, consulta la ficha de Compliance as Code en AWS: de la política a la acción automática y confirma allí la fecha y modalidad actuales.
- Diseños híbridos, de borde o multi-región: resuelven necesidades de latencia, residencia de datos o recuperación geográfica. Incorpóralos cuando los requisitos indiquen dónde debe procesarse o recuperarse la carga.
Estas opciones no son objetivos por sí mismos. Para compararlas, registra el requisito que resuelven, la operación que agregan y cómo vas a comprobar el resultado.
Valida la decisión antes de ampliarla
- Escribe los requisitos que no se pueden negociar y los que sí admiten un compromiso.
- Dibuja el flujo de solicitudes y datos, incluyendo fallos, reintentos, permisos y puntos de recuperación.
- Compara dos diseños viables y anota por qué elegiste uno, qué asumiste y qué costo operativo aceptas.
- Implementa una parte acotada en un entorno de prueba. Mide latencia y consumo con la carga esperada, y verifica qué pasa cuando una dependencia falla.
- Ensaya restauración o conmutación según los objetivos de recuperación; compara el resultado medido con el RTO y RPO definidos.
- Automatiza los cambios de infraestructura y revisa qué recursos se crearían, modificarían o eliminarían antes de aplicarlos.
Vuelve a revisar la arquitectura cuando cambien el volumen, los datos, las reglas de residencia o el equipo que la opera. Un diagrama es útil si ayuda a comprobar esos supuestos; no reemplaza las pruebas del sistema en ejecución.
Practica la arquitectura en comunidad
Para poner a prueba el diseño con un reto compartido, el 26 de octubre de 2026 habrá una AWSpectrum Architecture Arena presencial en FARO Cosmos, Ciudad de México, de 16:00 a 18:30. Consulta la página del evento para ver inscripción y disponibilidad.
