DEV Community: Oscar Gaviria

🔥AWS Network Firewall vs Gateway Load Balancer: la decisión que nadie explica bien.

Oscar Gaviria — Mon, 17 Aug 2026 15:30:15 +0000

🧠 Introducción

En un reciente Architecture Review con un cliente de servicios financieros en LATAM, llegamos al slide de seguridad de red y pasó algo que ya he visto varias veces.

El equipo tenía desplegado AWS Network Firewall en un hub de inspección centralizado. Arquitectura hub-spoke con TGW. Todo correctamente diseñado en papel.

El problema: el cliente tenía requerimientos de compliance que exigían las firmas de amenazas propietarias de su vendor de seguridad — Palo Alto Networks, con el que ya operaban on-premises con Panorama como single pane of glass.

Network Firewall no podía satisfacer ese requerimiento. Habían construido la arquitectura entera sobre el servicio equivocado.

La pregunta que nadie había respondido al inicio del proyecto fue la más simple:

"¿Necesitamos el firewall de AWS o necesitamos nuestro firewall en AWS?"

Esa diferencia lo cambia todo.

🚀 Preámbulo: dos servicios que resuelven problemas distintos

Antes de comparar, es necesario entender que Network Firewall y GWLB no son alternativas equivalentes. Son herramientas que operan en capas diferentes del problema de inspección de tráfico.

AWS Network Firewall es un firewall gestionado nativo. AWS opera el motor de inspección; nosotros operamos las reglas. Stateful, stateless, Suricata-compatible, con IPS/IDS integrado.

AWS Gateway Load Balancer es infraestructura de distribución de tráfico. No inspecciona nada por sí solo. Su trabajo es dirigir tráfico hacia appliances de terceros (Palo Alto VM-Series, Fortinet FortiGate, Check Point CloudGuard) de forma transparente, escalable y con preservación de sesión.

Un dato técnico que pocos conocen: AWS Network Firewall ya usa internamente Gateway Load Balancer para proveer escalabilidad elástica en su propio endpoint. Esto significa que cuando elegimos Network Firewall, estamos usando GWLB — pero con el motor de inspección de AWS incluido y abstraído.

La pregunta real entonces no es "¿cuál es mejor?" sino:

¿Quién opera el motor de inspección y quién controla las firmas de amenazas?

⚙️ Cómo intercepta el tráfico cada uno — la diferencia arquitectónica real

Antes de la decisión, necesitamos entender el mecanismo de intercepción. Son fundamentalmente distintos.

AWS Network Firewall — flujo de tráfico:

VPC spoke
  └── TGW (attachment)
        └── Inspection VPC
              └── Firewall Subnet
                    └── Network Firewall Endpoint (ENI tipo gateway_load_balancer_endpoint)
                          └── Motor Suricata (gestionado por AWS)
                                └── Retorna tráfico inspeccionado

El endpoint de Network Firewall actúa como bump-in-the-wire: el tráfico entra, se inspecciona contra las reglas Suricata/stateful configuradas, y sale hacia su destino. Vemos las reglas y los logs. AWS opera el motor.

GWLB + Appliance de tercero — flujo de tráfico:

VPC spoke
  └── TGW (attachment)
        └── Security VPC
              └── GWLB Endpoint (GWLBE, vía PrivateLink)
                    └── GWLB (encapsulación GENEVE port 6081)
                          └── Target Group → Appliance EC2 (Palo Alto / Fortinet / etc.)
                                └── Inspección + retorno al GWLB
                                      └── GWLB reenvía tráfico a destino

El punto técnico crítico: GWLB usa encapsulación GENEVE para enviar el paquete original intacto al appliance, preservando la 5-tupla original. El appliance inspecciona, toma decisión, y devuelve el paquete al GWLB que lo reenvía al destino. El tráfico es transparente para origen y destino — ninguno sabe que fue inspeccionado.

Esto tiene una implicación operativa importante: el appliance debe soportar GENEVE (port 6081) para integrarse con GWLB. Palo Alto VM-Series, Fortinet FortiGate y Check Point CloudGuard lo soportan. Si el vendor de seguridad de la organización no lo soporta, GWLB no es viable sin cambios en el appliance.

📊 La tabla de decisión — criterios objetivos

Esta es la tabla que debería existir en todo Architecture Review que involucre inspección de tráfico en AWS:

Criterio	AWS Network Firewall	GWLB + Appliance tercero
Operación del motor	AWS (managed)	Nosotros (EC2 + licencia vendor)
Firmas de amenazas	AWS Managed Rules + Suricata community	Propietarias del vendor (Palo Alto, Fortinet)
Single pane of glass con on-prem	❌ No	✅ Sí (Panorama, FortiManager)
TLS inspection	✅ Sí (Advanced Inspection, sin cargo extra de data processing desde feb 2026, en 13 regiones)	✅ Sí (depende del appliance)
Escalabilidad	Automática (managed)	Auto Scaling Group manual
Costo base (us-east-1, por AZ)	$0.395/hora endpoint + $0.065/GB	$0.014/hora GWLB + $0.004/GLCU-hora + licencia EC2 + vendor
Overhead operativo	Bajo	Alto (parches, licencias, HA del appliance)
Tiempo hasta producción	Horas	Días/semanas
Compliance con requerimientos vendor-specific	❌ Limitado	✅ Total
Multi-VPC con un solo firewall	✅ Hasta 50 VPCs por AZ (secondary endpoints)	✅ Con GWLBE por VPC

💸 Trade-off de costos — los números que importan

Escenario típico: hub de inspección centralizado, 3 AZs, 10 TB/mes de tráfico inspeccionado

AWS Network Firewall:

Endpoints: 3 AZs × $0.395/hora × 730 horas = $865/mes
Tráfico:   10,000 GB × $0.065/GB            = $650/mes
──────────────────────────────────────────────────────
Total mensual aproximado:                   ~$1,515/mes

GWLB + Palo Alto VM-Series (estimado):

GWLB:       3 AZs × $0.014/hora × 730h    =   $31/mes
GLCUs:      variable según tráfico         ~   $50/mes
EC2 (PA):   3× m5.2xlarge (~$0.384/h)     ~  $842/mes
Licencia:   Palo Alto BYOL o marketplace   ~  $500–1,500/mes
──────────────────────────────────────────────────────
Total mensual aproximado:                  ~$1,400–2,400/mes

Conclusión del análisis de costos: Network Firewall es más predecible y generalmente más barato en arquitecturas medianas. GWLB se justifica cuando el costo de la licencia del vendor ya está amortizado (BYOL desde on-premises) o cuando las capacidades del vendor son un requerimiento no negociable.

Un dato relevante publicado en febrero de 2026: AWS Network Firewall eliminó los cargos adicionales de data processing para Advanced Inspection TLS (vigente en 13 regiones, incluyendo São Paulo) y extendió los descuentos de NAT Gateway encadenado a los secondary endpoints, esta última mejora sin restricción regional. Eso mejora significativamente el TCO de Network Firewall en arquitecturas multi-VPC con inspección TLS activa.

🔧 Patrón 1 — Network Firewall en hub-spoke con TGW

Este es el patrón de referencia para organizaciones AWS-native sin dependencia de vendor externo.

VPC Spoke A ──┐
VPC Spoke B ──┤── TGW ──── Inspection VPC
VPC Spoke C ──┘              └── Firewall Subnet (1 por AZ)
                                    └── Network Firewall Endpoint
                                          └── Suricata Rules + Stateful

Nota de costos: en este patrón el tráfico inter-spoke atraviesa
el TGW dos veces — una hacia la Inspection VPC y otra hacia el spoke
destino. Consideremos ese doble cargo de $0.02/GB en el modelo de costos
para tráfico Este-Oeste de alto volumen.

Cuándo es el patrón correcto:

Organización AWS-first sin equipos de seguridad que operen vendors externos
Necesitamos inspección rápida sin overhead operativo de licencias y parches
Requerimiento de TLS inspection: sin cargo extra de data processing desde feb 2026, en 13 regiones.
Dev/test environments donde el costo de un appliance no se justifica
Startups y scale-ups que no tienen on-premises con firewall vendor establecido

Lo que necesitamos configurar en el TGW:

Route tables separadas: pre-inspection (tráfico entra al firewall) y post-inspection (tráfico sale al destino)
Appliance mode en el TGW attachment para preservar simetría de flujo
Network Firewall policy con al menos: stateless rules para tráfico conocido + stateful rules para inspección profunda

Desde noviembre de 2025, Network Firewall soporta flexible cost allocation vía TGW native attachments, permitiendo distribuir los costos de inspección a las cuentas de las aplicaciones según uso real. Para un ambiente multi-cuenta enterprise, esto resuelve el problema de chargeback interno sin soluciones custom.

Esto requiere migrar a TGW native attachment, que reemplaza la Inspection VPC dedicada por una conexión directa del firewall al TGW. Esto no es una capacidad adicional sobre el diseño de arriba, es un patrón de despliegue distinto.

🔧 Patrón 2 — GWLB con appliance de tercero en hub centralizado

Este es el patrón para organizaciones con dependencia de vendor o requerimientos de compliance que Network Firewall no cubre.

VPC Spoke A ──┐
VPC Spoke B ──┤── TGW ──── Security VPC
VPC Spoke C ──┘              └── GWLBE (centralizado por AZ, vía PrivateLink)
                                    └── GWLB (encapsulación GENEVE port 6081)
                                          └── Auto Scaling Group
                                                └── Palo Alto VM-Series
                                                      └── Panorama (gestión centralizada)

Cuándo es el patrón correcto:

Organización con Palo Alto/Fortinet/CheckPoint on-premises y Panorama/FortiManager como consola unificada
Requerimientos de compliance que exigen firmas propietarias de vendor certificado (PCI-DSS nivel 1, HIPAA con auditorías de vendor específico)
Necesitamos capacidades que Network Firewall no tiene: sandbox de malware, DLP a nivel de appliance, URL categorization propietaria
Migración desde on-premises donde el vendor ya tiene contexto de políticas históricas

Consideración operativa crítica: con GWLB somos responsables de la HA del appliance. Necesitamos:

Auto Scaling Group con health checks configurados para el appliance
Appliance mode en TGW para simetría de flujo (sin esto, flows bidireccionales pueden ir a instancias distintas y romper inspección stateful)
Proceso de parches del OS del appliance sin interrumpir tráfico
Gestión de licencias y renovaciones del vendor

🧠 El árbol de decisión — nivel arquitecto

¿Necesitamos firmas propietarias de un vendor específico?
  │
  ├── SÍ → ¿Ese vendor tiene appliance compatible con GENEVE/GWLB?
  │           ├── SÍ → GWLB + Appliance (Palo Alto, Fortinet, CheckPoint)
  │           └── NO → Evaluamos Palo Alto Cloud NGFW (marketplace)
  │                     o rediscutimos el requerimiento con el equipo de seguridad
  │
  └── NO → ¿Tenemos equipo para operar, parchear y licenciar appliances?
              │
              ├── SÍ → Evaluamos ambas opciones según TCO
              │
              └── NO → AWS Network Firewall
                          │
                          └── ¿Necesitamos TLS inspection?
                                ├── SÍ → Network Firewall + Advanced Inspection
                                │         (sin cargo extra desde feb 2026, vigente en 13 regiones, incluyendo São Paulo)
                                └── NO → Network Firewall standard

⚠️ Antipatrones consolidados

❌ "Necesitamos firewall" sin definir qué tipo: la decisión de vendor vs. managed se toma en la semana 1, no en la semana 8 cuando ya está construida la arquitectura.

❌ Network Firewall para reemplazar un vendor con el que ya tenemos contrato y Panorama: vamos a operar dos consolas de seguridad distintas sin ganancia técnica real.

❌ GWLB sin appliance mode en TGW: flows bidireccionales pueden llegar a instancias distintas del appliance. Inspección stateful rota silenciosamente.

❌ Un solo endpoint de Network Firewall para múltiples AZs: si el endpoint falla, el tráfico de esas AZs pierde inspección. Siempre desplegamos un endpoint por AZ en producción.

❌ GWLB en dev/test con appliance de producción: el costo del appliance (EC2 + licencia) en entornos non-prod es difícil de justificar. Network Firewall en dev/test + GWLB en producción es el patrón híbrido más común y más económico.

🔧 Conclusión

La pregunta correcta en un Architecture Review no es:

"¿Usamos Network Firewall o GWLB?"

Es:

"¿Quién controla el motor de inspección y quién gestiona las firmas de amenazas — AWS o nuestro vendor de seguridad?"

Si la respuesta es AWS: Network Firewall es el camino más directo, más predecible en costos y con menor overhead operativo.

Si la respuesta es el vendor de seguridad existente de la organización: GWLB es la infraestructura que permite llevar ese vendor a AWS sin cambiar el modelo operativo de seguridad.

Ambos son correctos. El error es elegir uno sin haber respondido esa pregunta primero.

Happy learning on AWS 🚀

De una idea en 2020 a la Golden Jacket: mi camino recorrido con AWS

Oscar Gaviria — Sun, 26 Jul 2026 21:40:56 +0000

En en año 2020 no tenía certificaciones. Tenía una pregunta.

Trabajaba en una empresa donde "la nube" era un terreno desconocido, y yo intuía que ahí estaba la solución a un problema que nadie sabía cómo resolver. No sabía de AWS, pero sabía que quería entenderla lo suficiente como para proponer algo que valiera la pena. Ese fue el verdadero punto de partida: no una meta, sino una curiosidad.

El método: paciencia y disciplina

Antes de pensar en exámenes, entendí que me faltaban dos cosas: inglés y fundamentos.

Y aquí hay algo que quiero decir con honestidad: cuando empecé, este camino era mucho más solitario. No existía la cantidad de contenido en español que hay hoy, ni la comunidad de especialistas, ni los posts, guías y documentación que ahora encuentras a un clic. Tocaba abrirse paso a punta de inglés y prueba y error. Por eso valoro tanto la democratización del conocimiento que vivimos hoy: quien empieza ahora tiene un ecosistema que a mí me habría ahorrado muchas noches.

Así que ataqué inglés y fundamentos en paralelo. Empecé a comprar cursos de AWS en Udemy. No los veía como un gasto, sino como una inversión en mí. Me puse una regla simple, casi una cultura personal: comprar uno, máximo dos cursos, y terminarlos antes de que acabara el mes. Sin acumular. Sin dejar cursos a medias. Un paso a la vez, pero sin parar.

Las Associate: los cimientos que abrieron puertas

El camino formal arrancó con las certificaciones Associate: Solutions Architect, SysOps Administrator y Developer.

Estas tres no solo me dieron la base técnica: me abrieron nuevas oportunidades laborales que me permitieron avanzar y crecer profesionalmente. Fue la primera vez que sentí, de forma tangible, que la inversión estaba dando frutos.

Networking Specialty: mi terreno… y mi única caída

Después fui por la Advanced Networking – Specialty, porque era mi área de especialidad.

Y aquí les confieso algo: fue la única certificación que reprobé en toda mi carrera con AWS. Irónico, ¿no? Justo en mi terreno. ¿La razón? Confianza de más. Entré confiado, subestimé el examen, y AWS me recordó que la experiencia no reemplaza la preparación. La volví a presentar, la aprobé, y me quedó una de las lecciones más valiosas de todo el camino: nunca des un examen por ganado.

Las Professional: y una broma que se volvió meta

Luego llegaron las Professional: Solutions Architect y DevOps Engineer.

Y con ellas, mi primer re:Invent, en 2024. Ahí, entre pasillos y sesiones, mis jefes soltaron una broma: "¿Y la Golden Jacket para cuándo?". Yo me reí, pero por dentro pensé: es una locura, no tengo tanto tiempo, mis hijos ocupan cada espacio libre que tengo.

La broma terminó, pero la espina quedó clavada.

La decisión: ir por todas

Volví de re:Invent con una idea que no me soltaba. Me puse la meta: obtener todas las certificaciones que me faltaban.

El problema es que muchas salían de mi zona de conocimiento. Así que hice lo que haría cualquier arquitecto: analicé el mejor path. Empecé por las Practitioner (Cloud y AI Practitioner) para abrir la puerta al mundo de la IA y los datos.

De ahí seguí el recorrido:

Data Engineer – Associate, mi entrada formal al mundo de los datos.
Machine Learning Engineer – Associate, uno de los grandes retos: involucraba servicios y contenido que no había visto a fondo antes.
El cambio de SysOps a CloudOps, que honestamente no representó mayor problema porque el salto entre una y otra fue mínimo.
Machine Learning – Specialty, la más dura a nivel teórico. Mucha documentación, mucha información que no estaba en ningún otro path… pero increíblemente nutritiva. Fue la que de verdad me hizo entender, a fondo, cómo funciona este mundo de la IA.

El malabar invisible: familia, trabajo y otras nubes
**
Nada de esto pasó en un laboratorio aislado. Este camino tuve que **equilibrarlo con mi familia, mi trabajo, proyectos reales y certificaciones en otras nubes (Azure, GCP y OCI).

Ese multi-cloud no fue una distracción: fue un multiplicador. Me permitió crecer, sí, pero sobre todo comparar. Ver cómo cada proveedor entiende una misma solución, dónde está fuerte cada uno, qué filosofía hay detrás de sus servicios. Certificarme en AWS me hizo mejor arquitecto; certificarme en varias nubes me hizo mejor decisor.

El sprint final

Para re:Invent 2025 solo me faltaba Security. Pero AWS lanzó una nueva certificación: AI Developer – Professional, que quedaría disponible justo después del evento. Decidí postergar Security para afrontar esta primero, y la aprobé en febrero de 2025, post re:Invent.

Y dejé para el final la Security – Specialty. Al revisarla, vi que buena parte de su contenido ya estaba cubierto por certificaciones anteriores. Así que elegí una fecha con intención: la presenté el 6 de mayo, el día de mi cumpleaños. Si aprobaba, celebraría por partida doble.

Y así fue.

Lo que me llevo

La Golden Jacket es dorada y brilla, pero no es lo que más valoro de este camino.

Lo que me llevo es la prueba de que una curiosidad de 2020 —un tipo sin certificaciones, sin comunidad en español, tratando de entender la nube— podía convertirse en esto. Un curso a la vez. Un mes a la vez. Robándole horas al cansancio y nunca al tiempo con mis hijos.

🚀Y ahora te toca a ti

Si estás empezando y sientes que la meta está demasiado lejos: lo estaba para mí también. Pero hoy tienes algo que yo no tuve: una comunidad enorme, contenido en español y especialistas dispuestos a ayudarte. Aprovéchalo.

👉 Si este camino te resuena, cuéntame en los comentarios: ¿cuál es la próxima certificación que vas a conquistar? Y si estás en el proceso, escríbeme — con gusto te comparto el path que a mí me funcionó.

Comparte este post con alguien que necesite recordar que el secreto no es el talento, es no soltar la espina. ☁️

De 2020 a hoy. Y apenas empieza.

Happy learning on AWS 🚀

🌐AWS en la era de la IA: cómo integrar Bedrock en arquitecturas enterprise sin romper lo que ya existe.

Oscar Gaviria — Mon, 29 Jun 2026 14:25:02 +0000

🧠 Introducción

En un engagement reciente con un cliente financiero en LATAM.

Datos en RDS Oracle. Lógica de negocio en microservicios sobre ECS. Integraciones legacy por MQ. Todo on-premise hasta hace dos años, hoy parcialmente migrado a AWS.

La pregunta del CTO fue directa:

"¿Podemos agregar IA generativa sin rehacer todo?"

Mi respuesta también fue directa:

"Depende de dónde están tus datos y qué nivel de control necesitas sobre ellos."

Esa conversación me hizo ordenar los patrones que he visto funcionar — y los que he visto explotar — al integrar Bedrock en arquitecturas enterprise existentes.

🚀 Preámbulo: el nuevo driver que nadie modeló en el Well-Architected

Cuando diseñamos arquitecturas enterprise en AWS, los cinco pilares del WAF cubren casi todo.

Pero hay un driver que emergió con la IA generativa que no estaba en el modelo original:

La proximidad del modelo al dato.

En arquitecturas tradicionales, mover datos era costoso pero tolerable. En inferencia con LLMs, el problema se invierte: no se pueden mover todos los datos al modelo en cada request. Se necesita que el modelo opere cerca de los datos — o que los datos lleguen al modelo de forma controlada, privada y auditable.

Eso tiene implicancias arquitectónicas concretas que se desarrollan a continuación.

Pero antes de hablar de Amazon Bedrock, vale la pena visualizar una arquitectura de referencia. La idea no es reemplazar los microservicios existentes, sino incorporar capacidades de IA como un servicio adicional dentro de una arquitectura desacoplada basada en eventos.

Los usuarios consumen la aplicación mediante API Gateway.
Los microservicios continúan siendo responsables de la lógica de negocio.
EventBridge desacopla la comunicación con los componentes de IA.
Amazon Bedrock procesa prompts y utiliza modelos fundacionales.
Knowledge Base aporta contexto empresarial mediante embeddings.
Amazon S3 almacena documentos, imágenes y otros datos utilizados por la IA.

⚙️ El mapa de servicios Bedrock que importa en enterprise

Antes de los patrones, es necesario tener claro qué hace cada pieza:

Servicio	Rol en la arquitectura
Bedrock Runtime	Invocación de modelos fundacionales (inference endpoint)
Bedrock Knowledge Bases	RAG gestionado — conecta nuestros datos a los modelos
Bedrock Agents	Orquestación de tareas multi-step con herramientas externas
Bedrock Guardrails	Control de contenido, PII redaction, topic filtering
Bedrock Flows	Pipelines visuales de orquestación (serverless)

El error más común que veo: tratar Bedrock como una API de chat. No lo es. Es una plataforma de inferencia enterprise con controles de red, identidad y gobierno propios.

🔒 Patrón 1 — Acceso privado: Bedrock sin tocar internet

Este es el patrón que más preguntas genera en clientes enterprise, especialmente en banca y salud.

El problema: por defecto, cuando una Lambda o un ECS task llama a Bedrock, el tráfico sale por internet (o por NAT Gateway si estamos en la VPC). Eso es inaceptable para workloads con datos sensibles.

La solución: VPC Interface Endpoints vía AWS PrivateLink.

VPC (subnet privada)
  └── ENI (Interface Endpoint)
        └── com.amazonaws.<region>.bedrock-runtime
              └── Bedrock Runtime API [sin salida a internet]

Con esto:

El tráfico nunca sale de la red de AWS.
No hay NAT Gateway charges por inferencia.
Se puede aplicar VPC Endpoint Policies para restringir qué IAM principals puedan invocar qué modelos.

💸 Trade-off de costo (no es gratis): se elimina el data processing del NAT Gateway, pero el Interface Endpoint tiene su propio cargo por hora por AZ + data processing por GB. Con un volumen alto de inferencia sale a favor; a un volumen bajo y con pocos endpoints, se debe sacar cuentas antes de asumir que PrivateLink siempre es más barato.

Punto técnico importante: Bedrock tiene dos endpoints separados que necesitamos configurar:

bedrock → para operaciones del control plane (listar modelos, configurar Knowledge Bases).
bedrock-runtime → para inferencia.

Y desde febrero de 2026, también está disponible PrivateLink para el endpoint bedrock-mantle (el nuevo motor de inferencia distribuida de AWS, compatible con OpenAI API spec). Esto es relevante si estamos migrando workloads que usan el SDK de OpenAI.

VPC Endpoint Policy mínima recomendada:

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:role/bedrock-inference-role"
    },
    "Action": "bedrock:InvokeModel",
    "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*"
  }]
}

👉 Con esta política, solo el rol específico puede invocar modelos Claude. Cualquier otro principal — incluso con permisos IAM — es rechazado a nivel de endpoint.

⚠️ Caveat que rompe en producción: esta policy cubre invocación directa al foundation-model. Pero en producción casi todo invoca vía cross-region inference profiles (us.anthropic.claude-*, eu.anthropic.claude-*) para throughput y resiliencia. El profile necesita permiso sobre dos tipos de recurso: el ARN del profile y el del foundation model en la región de origen y en cada región destino del profile. Si solo permitimos foundation-model/*, la llamada vía profile nos devuelve un AccessDenied.

{
  "Effect": "Allow",
  "Action": "bedrock:InvokeModel",
  "Resource": [
    "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-*",
    "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*",
    "arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-*",
    "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-*"
  ]
}

Son 4 ARNs = 1 inference profile + 3 foundation-models, uno por cada región a la que rutea el profile us (N. Virginia, Ohio, Oregon). Para global CRIS, además se suma el FM sin región: arn:aws:bedrock:::foundation-model/....

🧩 Patrón 2 — RAG privado: Knowledge Bases sin exponer nuestro datos

El patrón RAG (Retrieval-Augmented Generation) es el más usado para integrar IA con datos enterprise existentes. La pregunta arquitectónica clave es:

¿Dónde viven los embeddings y quién controla el acceso?

Con Bedrock Knowledge Bases:

S3 (datos source) 
  → Bedrock Knowledge Bases (embedding + vector store)
    → OpenSearch Serverless (índice vectorial, en tu cuenta)
      → Bedrock Runtime (retrieval + inferencia)
        → Tu aplicación

Lo que importa para enterprise:

Los datos nunca salen de la cuenta AWS.
El modelo fundacional no se re-entrena con los datos propios (Bedrock lo garantiza contractualmente).
El vector store (OpenSearch Serverless) es accesible de forma privada vía VPC endpoint, con acceso controlado por data access policies + IAM.
Se puede aplicar metadata filtering para segmentar qué datos ve cada usuario o rol.

Antipatrón frecuente: indexar todo el lake en el vector store sin segmentación.
Resultado: el modelo responde con información de un tenant usando contexto de otro. Necesitamos filtros por tenant_id, classification_level o lo que corresponda a nuestro modelo de datos.

🛡️ Patrón 3 — Guardrails como capa de control transversal

Bedrock Guardrails no es solo un filtro de contenido. En enterprise, es el mecanismo de gobierno de IA.

Lo que hace:

Content filtering: bloquea hasta el 88% de contenido dañino según AWS.
PII redaction: enmascara datos sensibles en prompts y respuestas.
Topic denial: define temas que el modelo no puede responder (ej: asesoría legal o médica).
Prompt attack detection: protección contra jailbreaks e inyecciones.
Grounding checks: detecta alucinaciones comparando contra contexto conocido.

Lo que cambió en 2025 y es crítico para enterprise:

Desde marzo de 2025, Guardrails soporta IAM policy-based enforcement. Esto significa que se puede configurar una condición IAM (bedrock:GuardrailIdentifier) que rechaza cualquier llamada a InvokeModel que no incluya un guardrail. Ojo con el matiz: IAM solo bloquea la ausencia del guardrail — la app igual tiene que pasarlo en cada llamada; lo que se gana es que ningún equipo pueda invocar el modelo "pelado".

{
  "Condition": {
    "StringEquals": {
      "bedrock:GuardrailIdentifier": "arn:aws:bedrock:us-east-1:123456789012:guardrail/abc123"
    }
  }
}

En la práctica, se puede forzar a nivel IAM que toda invocación pase por un guardrail vía SCP + condición. Para un ambiente multi-cuenta (que es el estándar enterprise), esto es el equivalente al aws:PrincipalOrgID condition pero para gobierno de IA.

🔄 Actualización (abril 2026): enforcement nativo cross-account

El enfoque anterior funciona, pero tiene un techo: depende de que la app pase el guardrail en cada llamada. Desde abril de 2026, con la disponibilidad general de los cross-account safeguards, se puede especificar un guardrail en una nueva Amazon Bedrock policy dentro de la cuenta de management de la organización, que enforcea automáticamente los safeguards configurados en todas las entidades miembro para cada invocación de modelo en Bedrock.

La diferencia arquitectónica es la clave: cualquier llamada de inferencia en esas cuentas pasa por los filtros centralizados sin tocar la configuración de cada cuenta, y sin que la app pase nada — las cuentas miembro no pueden sobreescribirlo. El guardrail deja de ser una responsabilidad de la aplicación y pasa a ser un baseline de seguridad inmutable, como un SCP (técnicamente es un tipo de política declarativa nuevo en Organizations, no un SCP, pero hereda igual).

{
  "bedrock": {
    "guardrail_inference": {
      "us-east-1": {
        "config_1": {
          "identifier": {
            "@@assign": "arn:aws:bedrock:us-east-1:111122223333:guardrail/abc123:1"
          },
          "selective_content_guarding": {
            "messages": { "@@assign": "comprehensive" }
          },
          "model_enforcement": {
            "included_models": { "@@assign": ["ALL"] },
            "excluded_models": { "@@assign": ["amazon.titan-embed-text-v2:0"] }
          }
        }
      }
    }
  }
}

Dos cosas que no podemos ignorar antes de llevarlo a producción:

ARN inválido = outage. Un ARN incorrecto o inválido en la policy no falla de forma elegante: causa violaciones de política y bloquea el uso de los modelos para inferencia en las cuentas afectadas. Tratamos el ARN del guardrail como infra config: versionado, peer-reviewed, probado en una OU de no-prod antes de tocar producción.

comprehensive es el único default sensato en regulado. El modo comprehensive evalúa todo el contenido sin importar cómo lo taggee la app; selective confía en el tagging del caller. En banca o salud, selective es una optimización de performance, no un punto de partida.

💸 Patrón 4 — Control de costos de inferencia

Este es el antipatrón que más explota en producción y menos se habla en los blogs de arquitectura.

El costo de Bedrock es por token (input + output). En arquitecturas enterprise sin control, el consumo puede crecer exponencialmente por tres razones:

Contextos sin límite: prompts que incluyen todo el historial de conversación sin truncar.
RAG sin relevance threshold: recuperar chunks irrelevantes que agrandan el prompt sin aportar calidad.
Modelos sobredimensionados: usar Claude Opus para tasks que Claude Haiku resuelve igual.

Decisión de modelo por tipo de tarea:

Task	Modelo recomendado	Justificación
Clasificación, routing, extracción simple	Claude Haiku / Nova Micro	Latencia baja, costo mínimo
RAG, Q&A sobre documentos	Claude Sonnet / Nova Lite	Balance calidad/costo
Razonamiento complejo, análisis legal/financiero	Claude Opus / Nova Pro	Justifica el costo por la complejidad

Modelos vigentes a junio 2026.

Control arquitectónico: no debemos exponer el modelo directamente a la aplicación. Se debe interponer una capa de abstracción (un servicio interno o una Step Function) que:

Seleccione el modelo según el tipo de request.
Aplique límites de tokens por usuario/tenant.
Registre consumo en CloudWatch para chargebacks internos.

🔁 Patrón 5 — Desacoplamiento: la AI Layer como servicio interno

El error de acoplamiento es el más difícil de corregir después.

El AI Gateway centraliza las responsabilidades transversales. La línea punteada roja muestra el antipatrón: aplicación llamando Bedrock directamente, sin gobernanza.

❌ Antipatrón:
App → Bedrock (directo, hardcodeado)

✅ Patrón correcto:
App → AI Gateway (interno) → Bedrock
                ↑
         [routing, auth, logging, cost control, fallback]

El AI Gateway interno puede ser tan simple como una Lambda con API Gateway, o tan complejo como un servicio ECS dedicado. Lo importante es que centraliza:

Autenticación: quién puede invocar IA y con qué modelo.
Logging: cada request/response auditado en S3 (requerimiento regulatorio en banca).
Fallback: si Bedrock throttlea, ¿qué pasa? ¿error 500 o respuesta degradada?
Observabilidad: latencia de inferencia, tokens consumidos, tasa de rechazo por guardrails.

AI Gateway sigue aportando valor aunque contemos con este enforcement nativo — el gateway nos da routing, cost control, fallback y logging que el org policy no cubre.

Sin esta capa, cuando el CTO pregunte "¿cuánto nos costó la IA este mes por área de negocio?" — no vamos a tener respuesta.

🧠 Insight clave (nivel arquitecto)

La integración de Bedrock en enterprise no es un problema de IA. Es un problema de arquitectura de red, identidad y gobierno — los mismos que ya se resolvieron para otros servicios AWS.

La diferencia es que los errores en IA tienen dos dimensiones nuevas:

Costos que escalan con el uso (no con la infraestructura).
Riesgos de compliance si los datos sensibles tocan el modelo sin control.

Tratar Bedrock como otro servicio managed de AWS — con los mismos patrones de VPC, IAM, logging y abstracción de capas — es exactamente el enfoque correcto.

🌎 Antipatrones consolidados

❌ AI washing: integrar Bedrock sin caso de uso medible. Si no podemos definir una métrica de éxito antes de construir, no construyamos.

❌ Inferencia acoplada: llamar Bedrock directamente desde la app sin abstracción. Imposible de gobernar, imposible de migrar de modelo.

❌ RAG sin segmentación: todos los datos en el mismo índice vectorial. Riesgo de privacidad entre tenants o clasificaciones.

❌ Sin observabilidad de modelos: métricas de aplicación sin métricas de inferencia. No sabemos si el modelo está respondiendo bien, solo si el endpoint está up.

❌ Modelo único para todo: el mismo modelo para clasificación simple y análisis complejo. El costo de inferencia explota sin ganancia de calidad.

🔧 Conclusión

La pregunta que más escucho es: "¿Podemos agregar IA a nuestra arquitectura existente?"

La respuesta correcta no es técnica. Es arquitectónica:

✔️ ¿Dónde estan tus datos y quién controla el acceso?
✔️ ¿Existe una capa de abstracción que centralice gobierno y costos?
✔️ ¿La red permite inferencia privada sin exponer datos sensibles a internet?

Las empresas que integren IA correctamente no serán las que usen los modelos más potentes. Serán las que resuelvan primero el problema de datos, red y gobierno — y construyan la capa de inferencia encima de eso.

Happy learning on AWS 🚀

🌐Arquitectura de red para Multi-Región en AWS: latencia, failover y coste.

Oscar Gaviria — Mon, 08 Jun 2026 12:45:09 +0000

🧠 Introducción

La mayoría de arquitecturas multi-región en AWS fallan por tres razones:

Subestiman la latencia entre regiones.
Sobreestiman el valor del active-active.
Descubren demasiado tarde el impacto del tráfico cross-region en la factura.

Diseñar multi-región no es replicar infraestructura.
Es tomar decisiones sobre:

Consistencia.
Routing global.
Recuperación.
Coste operativo.

Y en la práctica, no es un problema de compute…
👉 es un problema de red y datos.

🧭 ¿Cuándo realmente necesitas Multi-Region?
Primero, rompamos un mito:

Multi-AZ no es Multi-Region.

Muchas aplicaciones empresariales:

Cumplen SLA con Multi-AZ
Usan backups cross-region
No necesitan más complejidad

Multi-Region tiene sentido cuando:

Necesitas RTO cercano a cero
Tienes usuarios distribuidos globalmente
Hay requisitos regulatorios/geográficos
El downtime tiene impacto crítico en el negocio

👉 Si no tienes estos requisitos, probablemente no necesitas multi-región.

🌐 El verdadero desafío: la red
Cuando pasas a multi-región, aparecen problemas reales:
🔹 Latencia

RTT entre regiones: 50–200 ms
Impacta replicación, APIs y UX

🔹 Replicación de datos

Síncrona → prácticamente inviable
Asíncrona → introduce lag

🔹 DNS y routing

Failover dependiente de TTL
Nunca es instantáneo

🔹 Coste de red

Tráfico inter-región = $$$
Principal driver oculto de coste

👉 Insight clave:

Multi-Region es más un problema de red que de infraestructura.

🏗️ Patrones de arquitectura Multi-Region

🔵 Active-Passive (recomendado en la mayoría de casos)
Incluye:

Backup & Restore
Pilot Light
Warm Standby

✅ Ventajas:

Menor coste
Menor complejidad
Más fácil de operar

❌ Desventajas:

Mayor RTO
Requiere automatización de failover

👉 Ideal cuando el negocio tolera minutos de recuperación.

🟣 Active-Active
Ambas regiones sirven tráfico simultáneamente.

✅ Ventajas:

Latencia global baja
RTO cercano a cero

❌ Desventajas:

Complejidad extrema
Consistencia distribuida
Coste elevado

👉 Realidad:

Muchas arquitecturas active-active están sobredimensionadas para el problema que resuelven.

Y más importante:

Active-Active sin estrategia de consistencia no es resiliencia, es incertidumbre distribuida.

🌍 Routing Global: dónde se gana o se pierde la arquitectura
🔹 Route 53

Failover → DR
Latency-based → apps globales
Weighted → migraciones

🔹 AWS Global Accelerator

Anycast sobre backbone AWS
Failover rápido (<30s)
Ideal para TCP/UDP críticos

🔹 CloudFront

Edge caching (600+ PoPs)
Reduce necesidad de multi-región en muchos casos

👉 Insight senior:

Muchas arquitecturas multi-región deberían empezar por CloudFront, no por replicar regiones.

💡 El "Secreto" del Failover de <30s: Anycast vs. Caché DNS

Muchos arquitectos asumen que Route 53 y AWS Global Accelerator hacen lo mismo porque ambos manejan routing basado en latencia o failover. Error grave de diseño.

El problema de Route 53: Depende de registros DNS y del TTL (Time to Live). Si cambias el registro para apuntar a la región secundaria, tienes que esperar a que los resolvers de los ISPs del cliente borren su caché. Si un ISP ignora tu TTL bajo (lo cual pasa constantemente en producción), tus usuarios seguirán intentando ir a la región caída.

La ventaja de Global Accelerator: Te da 2 IPs estáticas Anycast globales. El tráfico entra a la red troncal de AWS en el Edge Location más cercano al usuario. Si una región falla, Global Accelerator desvía el tráfico a nivel de capa de transporte (TCP/UDP proxy) dentro de la propia red de AWS, redirigiéndolo instantáneamente a los ALBs saludables de la otra región. El cliente nunca cambia de IP, por ende, el caché del DNS no importa.

💸 Coste real de Multi-Región

Aquí es donde muchas arquitecturas fallan.
Costes ocultos:

Tráfico inter-región ($0.02–0.08/GB)
Replicación de bases de datos
Infraestructura duplicada
NAT Gateway por región
Health checks + observabilidad
Entornos idle (warm standby)

👉 Ejemplo real:

En una arquitectura LATAM, el tráfico inter-región incrementó el coste total en ~34% sin mejorar la latencia percibida significativamente.

👉 Conclusión:

Estrategias Multi-región ("con > 500 GB/mes de tráfico inter-región") mal diseñadas, pueden ser 3x–4x veces más costosas.

🧠 Estrategias de datos (el verdadero problema)

El compute escala fácil.
Los datos, no.

🔹 Comparativa rápida

_"Aurora parece 'peor' por el failover manual, pero su lag <1s la hace más predecible para cargas transaccionales que DynamoDB con escrituras concurrentes en ambas regiones."
_
Problemas reales:

Conflictos de escritura
Lag de replicación
Datos inconsistentes entre regiones

Cuando duplicas tu infraestructura en otra región para failover, la red es el problema fácil; el verdadero reto son tus bases de datos. Aquí hay dos patrones claros y sus trade-offs reales en AWS:

Active-Active con DynamoDB Global Tables: Proporciona replicación totalmente administrada con latencias de replicación típicamente sub-segundo. Sin embargo, opera bajo el modelo de consistencia eventual. Si tienes escrituras concurrentes en ambas regiones sobre el mismo ítem, aplica la regla Last-Writer-Wins. Si tu aplicación no es idempotente, vas a corromper datos de negocio.
Active-Passive con Aurora Global Database: Replica los datos a nivel del storage cluster físico con un lag menor a 1 segundo sin impactar el performance de la base de datos principal. Es ideal para estrategias de Warm Standby, pero ten en cuenta el RTO: en caso de failover, tu plano de control o aplicación debe promover explícitamente el clúster secundario a modo de Lectura/Escritura, lo que requiere automatización (vía AWS SDK o EventBridge).

🚨 Errores comunes (basado en producción)

TTL DNS demasiado alto
No probar el failover
Asumir que Multi-AZ es suficiente para DR
Ignorar replication lag
Diseñar active-active “por moda”
No definir RTO/RPO con negocio

👉 El peor:

Diseñar multi-región sin entender la operación diaria.

🚫 Anti-patterns que veo frecuentemente

Active-Active con bases de datos sin estrategia de conflicto.
Failover DNS con TTL > 300s.
Replicación global “porque sí”.
NAT Gateway como bottleneck multi-región.
Endpoints Regionales Hardcodeados.
Split-Brain por Health Checks Invertidos.

"Split-Brain por Health Checks Invertidos: si configuras un health check que marca la región secundaria como unhealthy cuando la primaria está caída (por dependencia cruzada), ambas regiones se desactivan simultáneamente. He visto esto en producción con Route 53 y ALBs que hacen health check a endpoints cross-region."

📈 Evolución recomendada
La mayoría de workloads deberían avanzar así:

Multi-AZ
Backup cross-region
Warm standby
(solo si realmente aplica) Active-Active

👉 No empieces por el nivel más complejo.

🧭 Conclusión
Multi-región no es un objetivo técnico.
Es una decisión de negocio basada en:

disponibilidad
experiencia de usuario
tolerancia al riesgo
coste

Y sobre todo:

Diseñar resiliencia no es evitar fallos…
es asumir que ocurrirán y construir para recuperarse.

✅ Takeaway final:

Una arquitectura multi-región sin failover automatizado y probado no es alta disponibilidad… es alta esperanza.

Happy learning on AWS 🚀

🧠 Plano Físico vs Plano Funcional en AWS Networking: cómo los arquitectos senior resuelven lo que otros no ven.

Oscar Gaviria — Wed, 27 May 2026 23:23:46 +0000

Introducción

El túnel VPN está UP. El attachment del TGW existe. El BGP está establecido. Y el ping no llega.

Si alguna vez pasaste más de 30 minutos en ese escenario, el problema probablemente no estaba en el enlace — estaba en que estabas buscando en el plano equivocado.

Hay una confusión que aparece constantemente en diseños de conectividad cloud, en reviews de arquitectura y en conversaciones con equipos técnicos muy capaces: mezclar el plano físico con el plano funcional. No es una confusión menor. Es la raíz de decisiones de diseño equivocadas, de troubleshooting que tarda horas en lugar de minutos, y de arquitecturas que funcionan… hasta que no funcionan.

En un post anterior hablé de patrones de VPC: hub-spoke, mesh, multi-account. Hoy vamos más profundo. Vamos a separar conscientemente cómo está construida la red de qué puede hacer esa red — y por qué esa separación cambia la forma en que diseñas.

🔴 Preámbulo

El problema es que ese nivel de imprecisión, tolerable en conversaciones informales, rompe diseños en producción.

Un equipo puede pasar semanas debatiendo si una arquitectura "funciona" porque la mitad del equipo está pensando en topología física y la otra mitad en flujos funcionales. El diagrama muestra lo mismo para los dos grupos. Las conclusiones son distintas.

Ese es el momento en que la distinción entre plano físico y plano funcional deja de ser académica.

🗺️ Los dos planos: definición operativa

Antes de los diagramas, la definición que usamos en la práctica:

Plano físico (o de infraestructura): los componentes que AWS provisiona, las conexiones físicas o lógicas entre ellos, y las restricciones que vienen de la plataforma. Aquí viven: puertos, VLANs, VIFs, attachments, instancias, interfaces de red. Son hechos, no decisiones.

Este diagrama muestra algo que casi ningún curso de certificación explica con suficiente claridad: la VPC no tiene un cable conectado. Lo que tiene son route tables con rutas propagadas desde los componentes de terminación.

Eso cambia completamente cómo razonas sobre transitividad, sobre fallo de conectividad, y sobre dónde aplicar políticas de seguridad.

Plano funcional (qué puede hablar con qué): el comportamiento resultante — es una capa de abstracción superior. Describe flujos de comunicación permitidos, no endpoints físicos. Es la respuesta a "¿puede el servidor A llegar al servidor B?" — no a "¿dónde termina el túnel?".

El problema ocurre cuando tratamos hechos del plano físico como si fueran decisiones del plano funcional, o viceversa.

Y aquí está la trampa: el plano físico no garantiza el plano funcional.

Tener un VGW adjunto a una VPC no significa que el tráfico fluye. Necesitas:

Route tables con las rutas correctas propagadas
Security Groups y NACLs que permitan el tráfico
Políticas IAM si hay servicios en juego

Y si hay inspección: un diseño de routing asimétrico explícito

Este es el punto donde la mayoría de los incidentes de conectividad tienen su causa raíz: el enlace físico está activo, el VGW está adjunto, el TGW tiene el attachment — y sin embargo el tráfico no llega. Porque alguna de las capas funcionales está bloqueando.

🔌 El caso concreto: VPN y Direct Connect
Este es el ejemplo más frecuente donde la confusión aparece.
Cuando alguien provisiona una VPN Site-to-Site en AWS, la descripción natural es "conecté mi datacenter a mi VPC". Funcionalmente eso es correcto. Físicamente, no.

Lo que ocurrió realmente:

AWS creó un Virtual Private Gateway (VGW) — El VGW es un componente de borde administrado que actúa como el agregador de terminación de túneles IPsec para la VPC. No reside dentro del direccionamiento CIDR de tus subnets, sino que se inyecta como un target lógico en el sistema de enrutamiento implícito de la VPC..
El VGW se asoció a tu VPC.
Con route propagation activada, las rutas del lado on-premise aparecen en las route tables de tus subnets.
El tráfico entra al VGW y AWS lo enruta internamente hacia las instancias.

La VPC nunca "ve" la VPN. Ve rutas. Esa distinción importa.

Con Direct Connect hay una capa adicional: el DX termina físicamente en una ubicación de colocation. Desde ahí, un Virtual Interface (VIF) — que puede ser Private, Public o Transit — se asocia al VGW o al TGW. El VIF es el objeto que cruza el plano físico al plano lógico de AWS.

Segundo diagrama — el flujo real de una conexión híbrida:

🚫 Por qué VPN y Peering no son transitivos — y por qué importa entenderlo bien.

Aquí es donde la confusión de planos genera errores de diseño reales.

VPC Peering no es transitivo por diseño del data plane, no por una limitación arbitraria. Cuando una instancia en la VPC A intenta alcanzar la VPC C pasando por la VPC B, el sustrato SDN de AWS (el servicio de mapeo del hipervisor) evalúa el paquete. Como el encapsulado de un Peering es estrictamente punto a punto entre las VPCs involucradas, el data plane no permite re-encapsular o encadenar un segundo salto de peering para proteger la red de bucles (packet looping). El paquete simplemente se descarta en el origen.

Lo mismo con VPN: el VGW termina en esa VPC. No tiene visibilidad ni capacidad de reenvío hacia otra VPC pereada. El tráfico que entra por la VPN existe en el contexto de esa VPC únicamente.

Pero esta restricción vive en el plano físico (data plane de AWS), no en el plano funcional. Y ahí está la clave: si introduces un elemento que opera en capa 3 dentro de la VPC — un appliance, un NVA, una instancia con IP forwarding — ese elemento sí puede recibir el tráfico y reenviarlo activamente. No está rompiendo ninguna regla de AWS; está operando en un plano distinto.

Nota: el Source/Destination Check, si se olvida deshabilitar este atributo en la ENI del appliance, el plano funcional se rompe por completo, porque el hipervisor de AWS descarta cualquier paquete cuyo IP de origen o destino no coincida con la ENI de la instancia. Este es el ejemplo perfecto de interacción entre ambos planos.

Tercer diagrama — transitividad física vs funcional:

Un matiz técnico importante en un diseño de arquitectura.

Un matiz que merece atención especial: en una arquitectura hub-spoke, el TGW resuelve el plano físico — centraliza el routing entre VPCs y hacia on-premise. Pero el TGW no inspecciona tráfico. Para eso necesitas una Security VPC que opere en el plano funcional — con Network Firewall, appliances o Gateway Load Balancer. Son dos capas distintas resolviendo problemas distintos, y confundirlas lleva a diseños donde el tráfico fluye pero nadie lo está viendo.

Porque:

TGW sí crea una topología hub-and-spoke de routing.
Pero no necesariamente concentra servicios funcionales.

Este patrón — cómo separar el plano de conectividad del plano de seguridad en una arquitectura hub-spoke — tiene suficiente profundidad para un artículo propio. Lo cubro en el siguiente post.

🟢 Cómo aplicar esta separación en la práctica

La abstracción no es solo un ejercicio académico. Tiene consecuencias directas en cómo diseñas, debuggeas y explicas arquitecturas.

Cuando diseñas:
Define primero el plano funcional — qué necesita hablar con qué, con qué nivel de inspección, con qué latencia. Luego elige los componentes físicos que materializan esos flujos. Hacerlo al revés (elegir TGW o peering antes de saber qué flujos necesitas) es lo que genera rediseños costosos.

Cuando debuggeas conectividad:
Separa mentalmente los dos planos y recórrelos en orden.

Plano físico primero:

Si usas VGW: ¿está adjunto a la VPC correcta? ¿Hay route propagation habilitada en las route tables de las subnets relevantes?
Si usas TGW: ¿el attachment está en estado available? ¿La route table del TGW tiene la ruta hacia el destino? ¿El dominio de routing es el correcto?
Si usas DX: ¿el VIF está en estado available? ¿El BGP session está established? ¿Se están recibiendo prefijos del lado on-premise?

Plano funcional después:

¿La route table de la subnet tiene la ruta con el target correcto (VGW, TGW, o ENI del appliance)?
¿El NACL de la subnet permite el tráfico en ambas direcciones? Recuerda: es stateless — inbound y outbound deben estar explícitamente permitidos.
¿El Security Group de la instancia destino permite el puerto y protocolo desde el CIDR o SG de origen?
Si hay un appliance en el path: ¿tiene el Source/Destination Check deshabilitado en su ENI?

La herramienta nativa para recorrer estas capas es VPC Reachability Analyzer — trabaja sobre el plano funcional completo y te indica exactamente en qué capa se rompe el flujo, sin necesidad de enviar tráfico real.

Cuando explicas a un equipo:
Cuando alguien dice "la VPN no llega a la VPC", antes de responder, pregunta: ¿está hablando del enlace físico (¿está el VGW configurado?) o del flujo funcional (¿llega el paquete al destino?)? La respuesta es distinta en cada caso.

🧭 Conclusión

Separar el plano físico del plano funcional no es un ejercicio de semántica.

Es la diferencia entre diagnosticar un incidente de conectividad en 10 minutos o en 3 horas. Entre diseñar una arquitectura que aguante el crecimiento o una que requiera rediseño cuando aparece el primer requisito de inspección de tráfico. Entre tener una conversación técnica productiva con tu equipo o una donde todos hablan de cosas distintas con las mismas palabras.

El plano físico te dice dónde terminan los cables. El plano funcional te dice si el paquete llega. Necesitas ambos — y necesitas saber en cuál estás en cada momento del diseño.

El patrón para aplicar esto:
✔ Diseñar: empieza por el plano funcional (flujos requeridos) → elige los componentes físicos que los materialicen
✔ Debuggear: valida el plano físico primero → luego recorre las capas funcionales en orden
✔ Comunicar: antes de responder cualquier pregunta de conectividad, identifica en qué plano está la pregunta

Happy learning on AWS 🚀

🧭Diseñando VPCs en AWS: patrones reales (hub-spoke, mesh, multi-account).

Oscar Gaviria — Mon, 18 May 2026 23:39:23 +0000

Cuando se diseñan arquitecturas en AWS, uno de los errores más comunes es pensar en la VPC como un componente técnico aislado.

Pero en la práctica, la VPC es:

👉 La base sobre la que se construyen la seguridad, la conectividad y la escalabilidad de todo el sistema.

Y aquí es donde muchos diseños empiezan a romperse…
no el día uno, sino cuando la plataforma crece.

🧭 Antes de hablar de patrones hablemos de el error más común

La mayoría de arquitecturas empiezan así:

✔️ Una sola VPC
✔️ Subnets públicas y privadas
✔️ Un NAT Gateway
✔️ Todo funcionando… al inicio

Pero cuando aparecen múltiples equipos, múltiples entornos (dev, qa, prod), requisitos de seguridad estrictos o conectividad híbrida, esa VPC se convierte en un cuello de botella.

🧩 Entonces… ¿cómo se diseñan VPCs en el mundo real?

No hay una única forma correcta.
Pero sí hay patrones que aparecen constantemente en producción.

Aquí los más relevantes:

🔵 1. Hub-and-Spoke (el más usado en entornos enterprise)

Este patrón separa la conectividad central del resto de workloads.

Cómo funciona:
VPC central (hub): VPN / Direct Connect, NAT Gateways, firewalls e inspección de tráfico.

VPCs spoke: aplicaciones, microservicios, entornos aislados.
Conectadas mediante Transit Gateway (recomendado a escala) o VPC Peering en casos simples.

Cuándo usarlo:
Arquitecturas multi-account, control centralizado de red, requisitos fuertes de seguridad, conectividad híbrida.

Trade-offs reales:
Un Transit Gateway con 10 VPCs adjuntas en us-east-1 tiene un costo base de ~$219/mes solo en attachment fees, antes de procesar un solo byte. En arquitecturas con tráfico este-oeste intenso entre spokes, ese costo puede superar al de los propios workloads. A eso se suma la complejidad operativa de mantener route tables del TGW separadas de las route tables de VPC, y el riesgo de convertir el hub en cuello de botella si el dimensionamiento de tráfico no se hace bien desde el inicio.
Un punto que casi nunca se menciona: si añades inspección centralizada con AWS Network Firewall en el hub, las route tables se vuelven asimétricas. El tráfico entra por una ruta y sale por otra. Ese detalle rompe implementaciones en producción si no se diseña explícitamente desde el principio.
Opinión:

Funciona muy bien, siempre que el crecimiento del tráfico esté bien dimensionado y la inspección de tráfico esté considerada desde el diseño inicial, no como un añadido posterior.

🟣 2. Full Mesh (todo conectado con todo)

Cada VPC se conecta directamente con las demás mediante VPC Peering, sin punto central.

Cuándo usarlo:
Pocas VPCs, baja complejidad, latencia mínima entre servicios.

El problema real:
Escala muy mal. Con N VPCs necesitas N×(N-1)/2 peerings. Con 10 VPCs son 45 conexiones, cada una con sus propias route tables. Con 20 VPCs son 190. A eso se suma que no hay control centralizado, el troubleshooting es lento porque no hay un punto único de observabilidad, y las rutas son difíciles de auditar cuando hay múltiples equipos tocando distintos peerings.

Opinión:
Funciona en startups con 3-4 VPCs. Se rompe en enterprise antes de lo que parece.

🟢 3. Multi-Account (más que un patrón, una estrategia)

Paradójicamente, separar cuentas no ralentiza a los equipos. Les permite moverse más rápido sin interferirse.
Cómo funciona:
Separación por cuentas (producción, desarrollo, seguridad, networking) usando AWS Organizations, Transit Gateway y VPC sharing.
Cuándo usarlo:
Aislamiento real de blast radius, cumplimiento y auditorías, escalabilidad organizacional.

Trade-offs reales:
La complejidad inicial es real. El mayor dolor no es técnico sino de gobierno: ¿quién es dueño de la cuenta de networking? ¿Quién aprueba cambios en las route tables del TGW? Sin esas respuestas claras antes de desplegar, el modelo multi-account genera más fricción de la que resuelve.

Opinión:
A cierta escala no es opcional. Es inevitable.

Hub-and-Spoke y Multi-Account no son excluyentes

Este es el punto que más confusión genera en equipos que están adoptando estos patrones por primera vez.
No son patrones opuestos. Resuelven problemas distintos en capas distintas:

Multi-Account define los límites de confianza, gobierno y blast radius.
Hub-and-Spoke define cómo se conectan esas redes de forma controlada.

En entornos enterprise es muy común — y totalmente correcto — ver una arquitectura multi-account que utiliza una topología hub-and-spoke para la conectividad. Son complementarios.

🔥 Decisiones que realmente importan (y casi nadie menciona).

Más allá del patrón elegido, estas cuatro decisiones determinan si el diseño aguanta el crecimiento:

¿Dónde inspeccionas el tráfico?
Centralizado en el hub o distribuido en cada VPC. Impacta directamente en seguridad, latencia y coste. La inspección centralizada con Network Firewall es más barata operativamente pero introduce la asimetría de rutas mencionada antes.

¿Cómo sales a internet?
NAT por VPC o NAT centralizado en el hub. Aquí es donde muchas facturas explotan. Un NAT Gateway por VPC en una arquitectura con 15 spokes puede costar entre 3x y 5x más que un NAT centralizado, dependiendo del patrón de tráfico.

¿Cómo segmentas?
Por VPC, por subnet o por cuenta. El error más común: mezclar todo porque hoy funciona, sin pensar en cómo se auditará en 12 meses cuando haya un incidente de seguridad.

¿Cómo escalará esto en 6 meses?
Antes de elegir un patrón, responde estas preguntas: ¿Cuántas cuentas tendrás en 12 meses? ¿Tienes o tendrás conectividad híbrida? ¿Quién es el dueño técnico de la red? ¿Cuánto tráfico este-oeste esperas entre workloads? Las respuestas dictan el patrón, no al revés.

⚡ Ejemplo real (simplificado)

En un proyecto de pagos con 3 equipos y 8 cuentas AWS, el punto de quiebre llegó cuando un equipo de desarrollo desplegó un cambio en una route table compartida y tumbó conectividad en producción durante 40 minutos. No fue un problema técnico. Fue un problema de gobierno.

La solución no fue técnica tampoco: fue separar la cuenta de networking, transferir la propiedad de las route tables del TGW a un equipo dedicado, e implementar aprobación obligatoria para cualquier cambio de red mediante pipelines de IaC con revisión. Después de eso, cero incidentes de red por cambios no coordinados en 8 meses.

Esa evolución se ve constantemente:

Inicio: 1 VPC, todo dentro, funciona
Crecimiento: más servicios, problemas de seguridad y control
Evolución: multi-account + hub-and-spoke + networking centralizado
Resultado: mejor control, más seguridad, más complejidad — inevitable y manejable si se diseña bien

Un punto importante de aclarar es que Hub‑and‑Spoke y Multi‑Account no son patrones opuestos.

En arquitecturas reales, resuelven problemas distintos en capas distintas:

**Multi‑Account **define los límites de confianza, gobierno y blast radius.
Hub‑and‑Spoke define cómo se conectan esas redes de forma controlada.

Por eso, en entornos enterprise es muy común —y totalmente correcto— ver:

👉 Una arquitectura multi‑account que utiliza una topología Hub‑and‑Spoke para la conectividad.

🧭 Conclusión

Diseñar una VPC no es crear subnets.

Es decidir cómo se comunican los sistemas, cómo se aíslan, cómo escalan y cuánto cuesta operarlos. Y sobre todo, cómo evitar que tu arquitectura funcione hoy pero falle mañana.

El patrón correcto no existe en abstracto. Existe en función de cuántos equipos tienes, qué nivel de aislamiento necesitas y cuánto tráfico moverás. Empieza por esas preguntas, no por el diagrama.

Happy learning on AWS 🚀

AWS Interconnect: La Clave para Estrategias Multicloud y Policloud

Oscar Gaviria — Tue, 28 Apr 2026 16:09:18 +0000

☁️ Introducción

A medida que las organizaciones evolucionan en su adopción cloud, el enfoque ya no es simplemente multicloud, sino policloud: utilizar distintos proveedores Cloud de forma estratégica según las capacidades específicas de cada uno.

Pero este enfoque introduce un reto fundamental:
👉 ¿Cómo conectas entornos diseñados para ser diferentes?

Aquí es donde entra en juego AWS Interconnect, apoyado en servicios como Direct Connect y su integración con ecosistemas de conectividad, permitiendo construir una red privada entre nubes.

Preambulo

Multicloud es usar varios Clouds.
Policloud es usarlos con intención.

El problema no es elegir AWS, Azure o GCP…
El problema es cómo hacer que trabajen juntos sin fricción.

Aquí te dejo una guía clara de cómo AWS aborda este desafío.

☁️ ¿Qué es AWS Interconnect en un contexto Multicloud / Policloud?

AWS Interconnect no es un servicio individual, sino una arquitectura de conectividad avanzada que permite integrar AWS con otros proveedores Cloud mediante conexiones privadas.

Se basa en:

AWS Direct Connect
Colocation (Equinix, Digital Realty…)
Cloud Exchange Providers (Megaport, Equinix Fabric…)

Permite construir un backbone privado entre Cloud, clave en entornos donde cada proveedor cumple un rol específico (policloud).

🔶 Modelo Tradicional: Multicloud sobre Internet

Muchas organizaciones comienzan su estrategia conectando Clouds a través de internet.

🔍 ¿Cómo funciona?

Comunicación mediante IP públicas
Uso de VPNs o cifrado TLS
Tráfico sobre internet público

⭐ Ventajas

Implementación rápida
Bajo coste inicial
Alta flexibilidad

⚠️ Limitaciones

Latencia impredecible
Dependencia del internet
Costes elevados por egress
Arquitecturas poco eficientes a escala

🔧 Ideal para:

Fases iniciales o casos de bajo impacto

🔵 AWS Interconnect: Base para Policloud

Cuando pasas de multicloud a policloud, la conectividad deja de ser opcional.

🔍 ¿Cómo funciona?

AWS se conecta mediante Direct Connect a un punto de interconexión
Desde ahí, se enlaza con otros Clouds usando proveedores especializados
El tráfico fluye de forma privada entre plataformas

⭐ Ventajas

Baja latencia y alto rendimiento
Conectividad privada entre Cloud
Arquitecturas más predecibles
Optimización de costes a gran escala
Mejor alineación con estrategias policloud

🔧 Ideal para:

Workloads distribuidos entre Cloud (ej: datos en GCP, apps en AWS)
Estrategias donde cada Cloud cumple un rol específico
Grandes volúmenes de tráfico entre plataformas
Entornos Enterprise.

⚔️ Comparación: Internet vs AWS Interconnect

✔️ Latencia

Internet → Variable
Interconnect → Consistente

✔️ Seguridad

Internet → Basada en cifrado
Interconnect → Red privada, aislamiento físico/lógico y opcionalmente cifrado adicional

✔️ Costes

Internet → Bajo inicio, alto a escala.
Interconnect → no siempre es más barato en términos absolutos, pero sí más eficiente y predecible a escala.

✔️ Arquitectura

Internet → Multicloud básico
Interconnect → Multicloud avanzado / Policloud

✔️ Escalabilidad

Internet → Limitada
Interconnect → Nivel enterprise

🧭 ¿Cuándo necesitas AWS Interconnect?

✔ Cuando evolucionas de multicloud a policloud
✔ Cuando cada cloud tiene un rol definido en tu arquitectura
✔ Cuando necesitas baja latencia entre plataformas
✔ Cuando el volumen de datos entre clouds es significativo
✔ Cuando la red se vuelve un factor crítico de negocio

🏁 Conclusión

No todas las estrategias multicloud son iguales.

👉 Multicloud te da flexibilidad.
👉 Policloud te da intención.

Pero ambas fallan sin una conectividad adecuada.

AWS Interconnect es el puente que transforma múltiples Cloud en una arquitectura coherente, integrada y preparada para escalar.

La evolución natural no es usar más clouds…
👉 es usarlos mejor y conectarlos correctamente.

Happy learning on AWS & beyond! 🚀

🌐 Arquitecturas AI-Native en AWS: Cómo diseñar plataformas cloud impulsadas por IA.

Oscar Gaviria — Mon, 20 Apr 2026 12:44:49 +0000

🧠 Introducción

Durante años diseñamos arquitecturas Cloud enfocadas en:

✔️ Escalabilidad
✔️ Resiliencia
✔️ Costos

Hoy hay un nuevo pilar que redefine todo:

👉 la Inteligencia Artificial como parte central del diseño

AWS no está simplemente “añadiendo IA” a sus servicios.
Está evolucionando hacia un modelo donde la IA se convierte en una capacidad transversal dentro de la arquitectura.

Incluso el AWS Well-Architected Framework ha evolucionado: la IA ya no es una carga de trabajo aislada, sino un pilar de optimización que afecta la excelencia operativa y la eficiencia de costos.

La pregunta ya no es:

¿Cómo integro IA en mi sistema?

Sino:

👉 ¿Cómo diseño mi arquitectura para que la IA sea parte nativa desde el inicio?

🚀 Preámbulo

En AWS, la IA no vive en un único servicio.

Se distribuye a lo largo de todo el stack:

Datos
Procesamiento
Aplicaciones
Experiencia de usuario

👉 Esto permite construir arquitecturas altamente flexibles, pero también introduce nuevas decisiones arquitectónicas.

La IA cambia el eje de diseño de la arquitectura en AWS, dejamos de diseñar sistemas que procesan requests y empezamos a diseñar sistemas que toman decisiones.

⚙️ El stack de IA en AWS

🔶 1. Capa de modelos (Foundation Models)

Amazon Bedrock
Acceso a múltiples LLMs (Anthropic, Titan, etc.)

👉 Permite:
✔ IA generativa sin gestionar infraestructura
✔ Abstracción del modelo
✔ Integración rápida en aplicaciones

🔶 2. Capa de Machine Learning

Amazon SageMaker

👉 Permite:
✔ Entrenar modelos propios
✔ Deploy de endpoints
✔ MLOps completo

🔶 3. Capa de integración (AI Layer)

AWS Lambda
API Gateway
Step Functions

👉 Permite:
✔ Orquestar inferencia
✔ Integrar IA en flujos de negocio
✔ Arquitecturas event-driven
✔ AI Agents Orchestration

🔶 4. Capa de datos (Data Foundation)

Amazon S3 (Lake House)
Glue
Athena / Redshift ✔ Vector Engine

👉 La IA en AWS depende críticamente de:

✔ Calidad de datos
✔ Gobernanza
✔ Acceso eficiente

🧩 Arquitectura de referencia AI-Native en AWS

👉 Aquí la IA no es un add-on
👉 Es una capa central de decisión

🔄 Patrones arquitectónicos clave

🔹 1. AI as a Service (AIaaS)

APIs que consumen modelos
Desacoplamiento total

🔹 2. Event-Driven AI

Inferencia activada por eventos
Integración con streaming (Kinesis)

🔹 3. Retrieval-Augmented Generation (RAG)

Usuario → Query → S3 / Vector DB → LLM → Respuesta

👉 En AWS, RAG se está convirtiendo en el patrón dominante para IA generativa en entornos enterprise, ya que permite mantener control sobre datos, reducir alucinaciones y optimizar costos de inferencia.

🔹 4. Serverless AI

Lambda + Bedrock
Sin gestión de infraestructura

⚔️ Fortalezas de AWS en IA

✔ Integración con ecosistema enterprise
✔ Flexibilidad total
✔ Control sobre modelos y despliegue
✔ Capacidad multi-servicio

🛡️ Governance & Trust en arquitecturas AI‑Native

En AWS, una arquitectura AI‑Native debe incorporar:

Control de acceso a modelos (IAM + Bedrock policies)
Versionado de modelos y datasets
Trazabilidad de inferencias
✔ AI Guardrails
Protección de datos sensibles (PII, prompts, embeddings)

👉 Sin esta capa, la IA escala el riesgo tan rápido como el valor.

⚠️ Retos arquitectónicos

❗ Complejidad (muchos servicios)
❗ Gobierno de datos
❗ Costos de inferencia
❗ FinOps para Generative AI
❗ Observabilidad de modelos

🌎 Antipatrones a evitar

✔ Integrar IA sin estrategia de datos
✔ Acoplar directamente el modelo a la app
✔ No considerar latencia de inferencia
✔ No controlar costos (tokens, llamadas)
✔ No versionar modelos

📊 Impacto en la organización

Nuevas capacidades digitales
Automatización avanzada
Experiencias inteligentes
Decisiones basadas en datos

🔧 Conclusión

AWS permite construir arquitecturas AI-Native altamente flexibles, pero exige:

✔ Diseño consciente
✔ Buen gobierno de datos
✔ Automatización
✔ Observabilidad

En AWS, la IA no es un servicio que consumes.
Es una capacidad que diseñas.

💡 Mensaje clave

Las empresas que ganen no serán las que usen IA, sino las que arquitecten correctamente alrededor de ella.

Happy learning in AWS & AI 🚀

🔐 IAM en AWS vs IAM en GCP: Diferencias que pueden romper tu arquitectura.

Oscar Gaviria — Mon, 13 Apr 2026 13:26:10 +0000

☁️ Introducción

En cualquier arquitectura Cloud moderna, la seguridad no comienza en la red… comienza en la identidad.

¿Quién puede acceder?
¿Qué puede hacer?
¿Desde dónde?

Aquí es donde entra en juego IAM (Identity and Access Management), uno de los componentes más críticos y a la vez más subestimados en la nube.

Tanto AWS como GCP ofrecen modelos robustos de IAM, pero con enfoques radicalmente distintos. Y no entender estas diferencias no solo genera problemas de seguridad… puede romper completamente tu arquitectura.

📌 Preámbulo

IAM no es solo gestión de usuarios. Es el motor de control de acceso que define cómo interactúan servicios, aplicaciones y personas dentro de tu entorno Cloud.

Aunque AWS y GCP tienen el mismo objetivo, su forma de implementarlo cambia:

AWS → enfoque granular, distribuido y altamente flexible
GCP → enfoque centralizado, jerárquico y basado en identidad

El mayor error no es técnico, es cognitivo:

al diseñar IAM con el modelo mental equivocado para la nube que estás usando.

Entender esto es clave para diseñar arquitecturas seguras y escalables.

🔐 ¿Qué es IAM?

IAM (Identity and Access Management) permite definir:

Quién (usuarios, servicios, aplicaciones).
Puede hacer qué (permisos).
Sobre qué recursos.

Es, en esencia, el equivalente a los controles de acceso en un data center tradicional, pero llevado a escala Cloud.

🔶 IAM en AWS: Granularidad extrema y control total

AWS adopta un modelo muy flexible, pero también más complejo.

🔍 ¿Cómo funciona IAM en AWS?
No existe jerarquía de recursos como tal (como en GCP)
Todo gira en torno a:

Usuarios.
Roles.
Políticas (Policies).

Las políticas son documentos JSON donde defines permisos de forma explícita.

👉 Ejemplo conceptual:

“Permitir acceso S3 solo a este bucket, desde esta IP, en este horario”

⭐ Ventajas de AWS IAM

Granularidad extrema: puedes controlar permisos a nivel muy fino.
Flexibilidad total: múltiples formas de asignar permisos.
Condiciones avanzadas: IP, tags, tiempo, MFA, etc.
Madurez: uno de los sistemas más completos del mercado.

⚠️ Riesgos comunes en AWS

Complejidad alta → fácil cometer errores.
Políticas difíciles de mantener a escala.
Over-permissioning (más permisos de los necesarios).
Difícil trazabilidad en entornos grandes.

🔧 Ideal para:

Entornos altamente regulados
Casos donde necesitas control detallado
Arquitecturas complejas con múltiples excepciones

🔵 IAM en GCP: Simplicidad, jerarquía y modelo basado en identidad

Google adopta un enfoque completamente distinto: todo está organizado jerárquicamente.

🔍 ¿Cómo funciona IAM en GCP?

Estructura jerárquica:

Organización
└── Folder
└── Proyecto
└── Recursos

Los permisos se asignan mediante:

Roles (predefinidos o custom).
Bindings (quién tiene ese rol).

👉 Y lo más importante:

Los permisos se heredan automáticamente hacia abajo.

⭐ Ventajas de GCP IAM

Modelo más simple e intuitivo.
Herencia automática de permisos.
Menor esfuerzo operativo.
Integración fuerte con identidades (service accounts).

⚠️ Riesgos comunes en GCP

Exceso de permisos por herencia mal diseñada.
Menor granularidad en algunos casos.
Difícil segmentación si no se diseña bien la jerarquía.
Dependencia fuerte del diseño organizacional.

🔧 Ideal para:

Organizaciones que priorizan simplicidad.
Equipos que quieren escalar rápido.
Entornos con gobierno centralizado.

“La diferencia no está solo en cómo configuras permisos… sino en cómo piensas la arquitectura desde el inicio.”

🚨 Diferencias que rompen arquitecturas

Ejemplo real:

Una organización migra desde AWS a GCP.

En AWS:

Cada cuenta tenía roles específicos.
Permisos explícitos por aplicación.
Nada se heredaba automáticamente.

En GCP:

Se crea una Organización y un Proyecto único.
Se asigna Owner a un grupo “plataforma”.

Resultado:

Servicios internos acceden a recursos productivos sin intención.
Equipos de dev tienen permisos que nunca tuvieron en AWS.
Auditoría fallida por exceso de privilegios.

El problema no fue GCP.
Fue migrar el modelo mental de AWS sin rediseñar la jerarquía.

Aquí está lo realmente importante 👇

1. Herencia vs control explícito
En AWS: nada se hereda automáticamente.
En GCP: TODO puede heredarse.

👉 Error típico:
Migrar sin rediseñar → permisos excesivos o insuficientes

2. Roles vs Policies
AWS: defines permisos muy específicos.
GCP: trabajas más con roles predefinidos.

👉 Impacto:
Diseños pensados para AWS pueden no encajar bien en GCP

3. Service Accounts vs Roles
AWS: uso intensivo de roles (STS).
GCP: service accounts como identidad principal.

👉 Error común:
No adaptar autenticación entre servicios → fallos de integración.

4. Gobierno organizacional
AWS: más descentralizado.
GCP: depende fuertemente de la jerarquía.

👉 **Impacto:**
Un mal diseño inicial en GCP afecta TODO el sistema.

🤝 ¿En qué coinciden AWS y GCP IAM?

Ambos implementan principio de menor privilegio.
Ambos permiten identidades de servicio bien definidas.
Ambos fallan cuando: - No hay gobierno. - No hay automatización (IaC). - Se improvisa en producción.

🎯 IAM no falla solo… falla cuando la arquitectura falla.

🧭 ¿Cuál elegir?

Depende de tu enfoque como arquitecto:

✔ Si necesitas control absoluto → AWS
Ideal para entornos complejos y altamente regulados.

✔ Si buscas simplicidad y escalabilidad → GCP
Perfecto para organizaciones modernas y ágiles.

🏁 Conclusión

IAM no es solo un componente más… es la base de la seguridad en la nube.

AWS te da control total, pero exige mayor madurez operativa.
GCP simplifica la gestión, pero requiere buen diseño jerárquico.

La clave no es cuál es mejor, sino:

Cuál se alinea mejor con tu modelo operativo y tu arquitectura.

Porque en Cloud, una mala decisión en IAM no solo genera riesgos…
puede romper toda tu plataforma.

Happy learning on AWS & GCP 🔥

🧪 Well-Architected en acción: cómo pasar de la teoría a una arquitectura real y resiliente.

Oscar Gaviria — Mon, 06 Apr 2026 12:30:39 +0000

☁️ Introducción

Diseñar una arquitectura en la nube no es solo desplegar servicios: es tomar decisiones que impactan directamente en seguridad, costos, rendimiento y resiliencia. A medida que los entornos crecen, también lo hacen los riesgos de desviarse de las buenas prácticas.

Aquí es donde entra el AWS Well-Architected Framework, una guía que permite evaluar arquitecturas cloud y asegurar que estén alineadas con estándares probados.

Pero más allá de la teoría, la pregunta clave es:

👉 ¿Cómo lo llevamos a la práctica en entornos reales?

📘 Preámbulo

El Well-Architected Framework no es un checklist estático. Es una herramienta viva que te ayuda a identificar riesgos, priorizar mejoras y evolucionar tu arquitectura continuamente.

Aquí te dejo una guía clara para entenderlo, aplicarlo y obtener resultados reales desde el día uno.

☁️ ¿Qué es el AWS Well-Architected Framework?

Es un conjunto de buenas prácticas organizadas en 6 pilares fundamentales que permiten evaluar la calidad de una arquitectura cloud.

Cada pilar responde a una pregunta clave:

¿Es segura?
¿Es resiliente?
¿Es eficiente?
¿Está optimizada en costos?
¿Es sostenible?
¿Está bien operada?

🏗️ Los 6 pilares explicados de forma práctica

🔒 Seguridad

Protege datos, sistemas y activos.

✔ Buenas prácticas:

Uso de IAM con mínimo privilegio
Encriptación por defecto
Auditoría con CloudTrail

👉 Quick win:
Revisar usuarios IAM con permisos excesivos.

⚙️ Excelencia Operacional

Capacidad de operar, monitorear y mejorar continuamente.

✔ Buenas prácticas:

Infraestructura como código (IaC)
Observabilidad (logs, métricas, alertas)
Automatización de operaciones

👉 Quick win:
Automatizar despliegues con Terraform o CloudFormation.

🚀 Rendimiento (Performance Efficiency)

Uso eficiente de recursos para escalar correctamente.

✔ Buenas prácticas:

Auto Scaling
Uso de servicios serverless
Selección adecuada de tipos de instancia

👉 Quick win:
Revisar instancias sobredimensionadas.

💰 Optimización de Costos

Evitar gasto innecesario sin sacrificar rendimiento.

✔ Buenas prácticas:

Rightsizing
Savings Plans / Reserved Instances
Apagar recursos no utilizados

👉 Quick win:
Identificar recursos “idle”.

🛡️ Fiabilidad (Reliability)

Capacidad de recuperarse ante fallos.

✔ Buenas prácticas:

Multi-AZ / Multi-Region
Backups automatizados
Diseño desacoplado

👉 Quick win:
Verificar si tus workloads críticos están en una sola AZ.

🌱 Sostenibilidad

Reducir impacto ambiental mediante eficiencia.

✔ Buenas prácticas:

Uso de serverless
Optimización de consumo
Eliminación de recursos innecesarios

👉 Quick win:
Eliminar recursos no utilizados en entornos de prueba.

🛠️ ¿Cómo hacer una evaluación paso a paso?

Aquí es donde pasamos de teoría a práctica:

1️⃣ Definir el workload

Selecciona la aplicación o sistema que vas a evaluar.

2️⃣ Usar AWS Well-Architected Tool

Servicio nativo de AWS para realizar la revisión.

✔ Permite:

Responder cuestionarios por pilar
Detectar riesgos (High / Medium / Low)
Generar recomendaciones

3️⃣ Identificar riesgos (Findings)

Cada respuesta genera insights accionables.

Ejemplo:

“No hay backups configurados” → riesgo alto
“No hay monitoreo activo” → riesgo medio

4️⃣ Priorizar mejoras

No todo se corrige al mismo tiempo.

✔ Enfócate en:

Riesgos críticos (High Risk Issues)
Impacto en negocio
Esfuerzo vs beneficio

5️⃣ Implementar mejoras incrementales

El objetivo no es perfección, sino evolución continua.

Diseño de arquitectura referencial con HA y DR.

⚔️ Errores comunes al aplicar el framework

❌ Usarlo solo como auditoría (y no como mejora continua)
❌ Querer cumplir todo desde el inicio
❌ Ignorar el contexto del negocio
❌ No involucrar a equipos de operación

🧭 ¿Cuándo deberías aplicar Well-Architected?

✔ Antes de pasar a producción
✔ Después de incidentes importantes
✔ En procesos de modernización
✔ De forma periódica (ej: cada 3-6 meses)

“El verdadero valor del Well-Architected Framework no está en el diagnóstico, sino en las decisiones que tomas después de él.”

🧠 Principios de diseño que atraviesan todos los pilares

Ejemplos:

Everything fails → diseña asumiendo fallos
Loose coupling → servicios desacoplados
Automate everything → humanos = punto de falla
Measure before optimize → métricas antes de decisiones

🚨 Antipatrones frecuentes que vemos en revisiones Well-Architected

Multi-AZ “de nombre”, pero con estado compartido en una AZ
Auto Scaling sin health checks reales
Backups configurados, pero nunca probados
IAM con : “temporal” que se vuelve permanente
Monitoreo solo de infraestructura, no de negocio

🏁 Conclusión

El AWS Well-Architected Framework no es solo una guía técnica, es una herramienta estratégica para construir arquitecturas más seguras, eficientes y resilientes.

No se trata de hacerlo perfecto desde el inicio, sino de mejorar continuamente con base en datos y buenas prácticas.

En palabras mas sencillas, la arquitectura en ambientes Clous no es algo que diseñas una vez…
es algo que evoluciona constantemente.

Happy learnning on AWS!

Despliegue, Operación y Troubleshooting interactivo de Infraestructura, usando AWS KIRO.

Oscar Gaviria — Mon, 30 Mar 2026 11:55:56 +0000

🧠 Introducción

La operación de infraestructura en AWS suele involucrar múltiples fuentes de información: configuraciones distribuidas, logs, métricas, eventos de despliegue y dependencias entre servicios. Este escenario hace que la identificación de incidencias y el análisis de causa raíz (RCA) sean procesos complejos, especialmente en entornos modernos basados en microservicios, IaC y automatización continua.

AWS KIRO surge como una capa de inteligencia que procesa, correlaciona y razona sobre este ecosistema, actuando como un asistente operativo y de troubleshooting interactivo basado en IA, capaz de integrarse desde el despliegue hasta la operación diaria.

📌 Preambulo

¿Qué es KIRO desde el punto de vista de infraestructura?

KIRO puede entenderse como un asistente interactivo basado en IA, capaz de diagnosticar, correlacionar y resolver incidencias en AWS mediante análisis contextual de múltiples capas:

Configuración de recursos: IAM, VPC, compute, storage
Métricas y logs: Amazon CloudWatch, CloudTrail
Eventos de despliegue: CloudFormation, CDK, pipelines CI/CD
Topología de arquitectura: dependencias y flujos entre servicios

✔️ En este artículo analizaremos en detalle:

KIRO como asistente integral de infraestructura en AWS.
Soporte inteligente en el despliegue de infraestructura.
Operación asistida mediante observabilidad aumentada.
Troubleshooting guiado y análisis de causa raíz (RCA).
Cómo KIRO transforma el ciclo completo de infraestructura.
Beneficios para equipos de arquitectura y operación.

🌎 1. Despliegue de Infraestructura con AWS KiRO

Una de las principales en los cuales se incorpora KiRO , es por las capacidades avanzadas que apoyan de forma inteligente los despliegues de infraestructura en AWS, ya que permite integración directamente con los flujos de IaC y automatización continua. Su rol en esta etapa es clave para asegurar despliegues consistentes, predecibles y libres de errores.

1.1 Validación inteligente de IaC (Infrastructure as Code)
Kiro analiza plantillas y definiciones de infraestructura en formatos como CloudFormation, CDK y Terraform, identificando:

Relaciones mal definidas entre recursos.
Parámetros inconsistentes o faltantes.
Bucles de dependencia.
Políticas IAM que no cumplen buenas prácticas.
Definiciones que generarán fallos en tiempo de ejecución.

1.2 Análisis en tiempo real de eventos de despliegue
Durante un despliegue, KiRO consume:

Eventos de CloudFormation Stack
Logs de CodeBuild y CodePipeline
Salidas de CDK Synth y CDK Deploy
Cambios registrados en CloudTrail

Con esta información, puede:

Correlacionar errores de compilación con fallos de permisos
Detectar recursos que quedaron en estado ROLLBACK_COMPLETE
Identificar drifts entre infraestructura declarada y real
Explicar qué dependencia o recurso provocó que el despliegue falle
Puede guiar paso a paso la solución.

Esto ayuda a detectar errores antes de que lleguen al pipeline.

1.3 Prevención de drift y problemas de consistencia
KiRO monitorea continuamente:

Configuraciones de IAM
Parámetros de VPC y subredes
Cambios no declarados en recursos críticos
Desvíos entre plantilla IaC y estado real

Si detecta un cambio manual, lo señala, explica el impacto y propone las correcciones para volver al estado deseado.

1.4 Acompañamiento guiado en despliegues complejos
Para arquitecturas con múltiples componentes —como EKS, RDS, Lambdas, VPC altamente segmentadas o stacks encadenados— Kiro puede:

Proponer el orden correcto de despliegue
Verificar dependencias inter-stack
Validar prerequisitos (roles, parámetros, networking)
Identificar componentes que requieren reprovisión

Esto reduce significativamente el riesgo de fallas por dependencias rotas.

1.5 Documentación automática del despliegue
Al finalizar un despliegue (exitoso o con errores), KIRO puede generar:

Resumen técnico
Recursos afectados
Logs relevantes
Cambios aplicados
Causas raíz de fallos (si ocurren)
Pasos a seguir

Esto no solo acelera auditorías, sino que mejora la trazabilidad operativa.

🚀 2 Asistencia en la Operación de la Reacción a la Prevención

Una de las bondades principales de KIRO es que actúa como una herramienta de operación predictiva, permitiendo:

2.1 Detección temprana de anomalías
Basado en métricas históricas, distribución de eventos y patrones
operativos.

2.2 Recomendaciones de optimización
Incluyendo:

Costos y dimensionamiento.
Seguridad (IAM, Security Groups, KMS).
Mejoras de rendimiento en componentes compute y networking.
Buenas prácticas de arquitectura.

2.3 Documentación automática de incidentes
Genera un informe con:

Análisis de contexto.
Pasos realizados.
Hallazgos.
RCA.
Solución.
Recomendaciones futuras.

Esto reduce drásticamente la carga operativa y mejora la gobernanza técnica.

⚙️ 3 Troubleshooting Interactivo y Basado en Razón

Una de las capacidades más potentes de KIRO es su comportamiento como un asistente técnico conversacional, capaz de:

3.1 Diagnóstico guiado
Kiro analiza el contexto del incidente, revisa logs, revisa configuración, compara con desviaciones previas y propone hipótesis técnicas.

3.2 Correlaciones automáticas
Relaciona métricas de rendimiento con fallos de despliegue, cambios de configuración o eventos de seguridad.

Ejemplos típicos:

Un error 503 en API Gateway correlacionado con fallas en Lambda y timeouts de VPC.
Caídas en throughput en EKS correlacionadas con cambios de autoscaling o limitaciones de CPU.
Incremento en 5xx tras un despliegue específico detectado mediante CloudTrail + CodePipeline.

3.3 Guía hacia la causa raíz (RCA)
KIRO opera como un copiloto técnico:

Identifica el punto de falla.
Explica qué lo produjo.
Muestra el rastro de dependencias.
Propone acciones correctivas.

Todo con trazabilidad y evidencia técnica.

🧪 4. Caso práctico (ejemplo típico)

Escenario: aplicación en EKS con latencia elevada.

KIRO permite:

Detectar incremento en métricas de latencia (CloudWatch)

Correlacionar con:

Saturación de CPU en pods.
Throttling en base de datos.

Identificar causa raíz:

Subdimensionamiento o mala configuración de autoscaling

Sugerir acciones:

Ajuste de HPA
Optimización de Queries.
Mejora de límites de recursos.

Troubleshooting Interactivo y Basado en Razón

🧩 Aplicación en el ciclo de vida de infraestructura

📉 Despliegue

Identificación de errores en IaC (CloudFormation/CDK)
Diagnóstico de fallos en pipelines CI/CD
Validación de configuraciones antes de producción

🔄 Operación

Monitoreo continuo con correlación automática
Detección de anomalías en tiempo real
Optimización de performance y costos

🛠️ Troubleshooting

Reducción del tiempo de análisis manual
Identificación guiada de causa raíz
Generación de recomendaciones accionables

📈 Beneficios clave

Reducción del MTTR hasta un 40–70%
Menor dependencia de múltiples equipos en incidentes complejos (30–50%)
Mayor visibilidad end-to-end de la arquitectura
Documentación implícita del proceso de resolución
Disminución de errores operativos repetitivos

💬 Conclusión

KIRO permite diagnosticar y resolver problemas en AWS de forma interactiva, identificando fallos en despliegues, analizando métricas operativas, explicando causas raíz y proponiendo acciones concretas para mejorar la infraestructura, su operación y la documentación asociada a la resolución de incidentes.

Happy learnning on AWS!

Despliegue, Operación y Troubleshooting interactivo de Infraestructura, usando AWS Kiro

Oscar Gaviria — Fri, 27 Mar 2026 14:22:44 +0000

🧠 Introducción

AWS Kiro surge como una capa de inteligencia que procesa, correlaciona y razona sobre este ecosistema, actuando como un asistente operativo y de troubleshooting interactivo basado en IA, capaz de integrarse desde el despliegue hasta la operación diaria.

📌 Preambulo

¿Qué es Kiro desde el punto de vista de infraestructura?

Kiro puede entenderse como un asistente de troubleshooting interactivo basado en IA, capaz de diagnosticar, correlacionar y resolver incidencias en AWS mediante análisis contextual de múltiples capas:

🔐 Configuración de recursos: IAM, VPC, compute, storage

📊 Métricas y logs: Amazon CloudWatch, CloudTrail

🚀 Eventos de despliegue: CloudFormation, CDK, pipelines CI/CD

🕸️ Topología de arquitectura: dependencias y flujos entre servicios

✔️ En este artículo analizaremos en detalle:

Kiro como asistente integral de infraestructura en AWS.
Soporte inteligente en el despliegue de infraestructura.
Operación asistida mediante observabilidad aumentada.
Troubleshooting guiado y análisis de causa raíz (RCA).
Cómo Kiro transforma el ciclo completo de infraestructura.
Beneficios para equipos de arquitectura y operación.

🌎 1. Despliegue de Infraestructura con AWS Kiro

Una de las principales en los cuales se incorpora Kiro , es por las capacidades avanzadas que apoyan de forma inteligente los despliegues de infraestructura en AWS, ya que permite integración directamente con los flujos de IaC y automatización continua. Su rol en esta etapa es clave para asegurar despliegues consistentes, predecibles y libres de errores.

1.1 Validación inteligente de IaC (Infrastructure as Code)
Kiro analiza plantillas y definiciones de infraestructura en formatos como CloudFormation, CDK y Terraform, identificando:

Relaciones mal definidas entre recursos.
Parámetros inconsistentes o faltantes.
Bucles de dependencia.
Políticas IAM que no cumplen buenas prácticas.
Definiciones que generarán fallos en tiempo de ejecución.

1.2 Análisis en tiempo real de eventos de despliegue
Durante un despliegue, Kiro consume:

Eventos de CloudFormation Stack
Logs de CodeBuild y CodePipeline
Salidas de CDK Synth y CDK Deploy
Cambios registrados en CloudTrail

Con esta información, puede:

Correlacionar errores de compilación con fallos de permisos
Detectar recursos que quedaron en estado ROLLBACK_COMPLETE
Identificar drifts entre infraestructura declarada y real
Explicar qué dependencia o recurso provocó que el despliegue falle
Puede guiar paso a paso la solución.

Esto ayuda a detectar errores antes de que lleguen al pipeline.

1.3 Prevención de drift y problemas de consistencia
Kiro monitorea continuamente:

Configuraciones de IAM
Parámetros de VPC y subredes
Cambios no declarados en recursos críticos
Desvíos entre plantilla IaC y estado real

Si detecta un cambio manual, lo señala, explica el impacto y propone las correcciones para volver al estado deseado.

1.4 Acompañamiento guiado en despliegues complejos
Para arquitecturas con múltiples componentes —como EKS, RDS, Lambdas, VPC altamente segmentadas o stacks encadenados— Kiro puede:

Proponer el orden correcto de despliegue
Verificar dependencias inter-stack
Validar prerequisitos (roles, parámetros, networking)
Identificar componentes que requieren reprovisión

Esto reduce significativamente el riesgo de fallas por dependencias rotas.

1.5 Documentación automática del despliegue
Al finalizar un despliegue (exitoso o con errores), Kiro puede generar:

Resumen técnico
Recursos afectados
Logs relevantes
Cambios aplicados
Causas raíz de fallos (si ocurren)
Pasos a seguir

Esto no solo acelera auditorías, sino que mejora la trazabilidad operativa.

🚀 2 Asistencia en la Operación de la Reacción a la Prevención

Una de las bondades principales de Kiro, es que actúa como una herramienta de operación predictiva, permitiendo:

2.1 Detección temprana de anomalías
Basado en métricas históricas, distribución de eventos y patrones
operativos.

2.2 Recomendaciones de optimización
Incluyendo:

Costos y dimensionamiento.
Seguridad (IAM, Security Groups, KMS).
Mejoras de rendimiento en componentes compute y networking.
Buenas prácticas de arquitectura.

2.3 Documentación automática de incidentes
Genera un informe con:

Análisis de contexto.
Pasos realizados.
Hallazgos.
RCA.
Solución.
Recomendaciones futuras.

Esto reduce drásticamente la carga operativa y mejora la gobernanza técnica.

⚙️ 3 Troubleshooting Interactivo y Basado en Razón

Una de las capacidades más potentes de Kiro es su comportamiento como un asistente técnico conversacional, capaz de:

3.1 Diagnóstico guiado
Kiro analiza el contexto del incidente, revisa logs, revisa configuración, compara con desviaciones previas y propone hipótesis técnicas.

3.2 Correlaciones automáticas
Relaciona métricas de rendimiento con fallos de despliegue, cambios de configuración o eventos de seguridad.

Ejemplos típicos:

Un error 503 en API Gateway correlacionado con fallas en Lambda y timeouts de VPC.
Caídas en throughput en EKS correlacionadas con cambios de autoscaling o limitaciones de CPU.
Incremento en 5xx tras un despliegue específico detectado mediante CloudTrail + CodePipeline.

3.3 Guía hacia la causa raíz (RCA)
Kiro opera como un copiloto técnico:

Identifica el punto de falla.
Explica qué lo produjo.
Muestra el rastro de dependencias.
Propone acciones correctivas.

Todo con trazabilidad y evidencia técnica.

🧪 4. Caso práctico (ejemplo típico)

Escenario: aplicación en EKS con latencia elevada.

Kiro permite:

Detectar incremento en métricas de latencia (CloudWatch)

Correlacionar con:

Saturación de CPU en pods.
Throttling en base de datos.

Identificar causa raíz:

Subdimensionamiento o mala configuración de autoscaling

Sugerir acciones:

Ajuste de HPA
Optimización de Queries.
Mejora de límites de recursos.

Troubleshooting Interactivo y Basado en Razón

** Aplicación en el ciclo de vida de infraestructura**

👉 Despliegue

Identificación de errores en IaC (CloudFormation/CDK)
Diagnóstico de fallos en pipelines CI/CD
Validación de configuraciones antes de producción

🔄 Operación

Monitoreo continuo con correlación automática
Detección de anomalías en tiempo real
Optimización de performance y costos

🛠️ Troubleshooting

Reducción del tiempo de análisis manual
Identificación guiada de causa raíz
Generación de recomendaciones accionables

📈 Beneficios clave

⏱️ Reducción del MTTR hasta un 40–70%
👥 Menor dependencia de múltiples equipos en incidentes complejos (30–50%)
🔍 Mayor visibilidad end-to-end de la arquitectura
📚 Documentación implícita del proceso de resolución
📉 Disminución de errores operativos repetitivos

💬 Conclusión

Kiro permite diagnosticar y resolver problemas en AWS de forma interactiva, identificando fallos en despliegues, analizando métricas operativas, explicando causas raíz y proponiendo acciones concretas para mejorar la infraestructura, su operación y la documentación asociada a la resolución de incidentes.

Happy learnning on AWS!