DEV Community: Oscar Gaviria

🔐 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!

Modernización sin fricción: AWS Transform en acción (VMware EC2 nativo). Parte 2: Hands-on

Oscar Gaviria — Mon, 16 Mar 2026 13:25:48 +0000

🧠Introducción

En la Parte 1 expliqué por qué AWS Transform para VMware está cambiando la forma en que planificamos migraciones a escala: discovery, traducción de red y wave planning asistidos por IA.

En esta Parte 2 vamos a lo que más valor genera: la práctica.
El objetivo es construir un piloto reproducible para entender el flujo completo:

✅ Simular un entorno “on-prem”
✅ Cargar informacion en AWS Transform
✅ Obtener plan de migración + oleadas + diseño de red (VMware → VPC)
✅ Avanzar hacia ejecución integrando AWS MGN

👉 Preambulo

Para esta práctica no usamos un vCenter real ni un cluster ESXi físico. En su lugar, se construyó un entorno simulado de VMware dentro de AWS, utilizando instancias nativas (Amazon EC2) y componentes de infraestructura que emulan los elementos que normalmente encontraríamos en un datacenter on-prem.

La intención del lab es replicar, de forma controlada y reproducible, los insumos mínimos que típicamente se requieren para iniciar una migración VMware→AWS en un escenario real: inventario, topología, segmentación, comunicación entre workloads y un dataset tipo RVTools.

¿Qué significa “simular VMware con EC2” y por qué tiene sentido?

En migraciones reales, herramientas como AWS Transform consumen datasets provenientes de:

RVTools exports (inventario y configuración extraída desde vCenter),
AWS Application Discovery Service (ADS),
Datasets equivalentes exportados desde CMDB u otras fuentes.

En este lab, la “infra VMware” se representa con workloads EC2 que simulan:

Múltiples VMs con diferentes roles (web/app/db/servicios),
Patrones de comunicación east-west (dependencias),
Separación lógica por capas o dominios (segmentación/red).

Es decir: no intentaremos ejecutar VMware. Lo que haremos es construir una infraestructura “tipo on-prem” con señales equivalentes para que el pipeline de planificación (discovery → dependencias → red → waves) sea demostrable.

⚡ ¿Qué se despliega exactamente?

Para la actividad previamente, se levantara un stack automatizado (via IaC), que genera una topología reproducible.

A alto nivel, se crean:

VPC + subnets + route tables para representar la conectividad base del “datacenter simulado”.
Instancias EC2 que representan servidores/VMs de distintas capas (por ejemplo: front-end, back-end, data/services).
Security Groups como equivalente funcional de reglas de segmentación (similar a lo que serían ACLs/FW rules on-prem o reglas distribuidas).
Componentes auxiliares para pruebas de conectividad/servicios y para garantizar que exista comunicación controlada entre nodos (dependencias observables).

La idea es que, cuando generemos el dataset, tengamos un inventario “realista”: diferentes máquinas, tamaños, redes, y relaciones de consumo entre servicios.

🔧 Diagrama simple del laboratorio

¿Por qué RVTools es clave en este ejercicio?

En ambientes VMware, RVTools es uno de los mecanismos más usados para extraer inventario desde vCenter porque incluye información como:

lista de VMs, hosts, clusters,
CPU/Mem asignados,
Discos y storage,
Redes/portgroups,
Metadatos suficientes para una primera etapa de discovery y sizing.

En este lab, generamos un export tipo RVTools a partir del entorno simulado. El resultado final es un archivo .xlsx con múltiples pestañas y/o CSVs que representan el inventario y configuración de la infraestructura simulada.

Ese dataset funciona como el “equivalente” de lo que en un proyecto real entregarías al equipo de migración desde tu entorno on-prem VMware.

👉 Ejemplo RVTools

RVTools es una de las herramientas más utilizadas para exportar inventario desde vCenter, incluyendo información de VMs, redes, CPU, memoria y almacenamiento. Este dataset suele ser el punto de partida para herramientas de migración y análisis.

📌 ¿Qué logramos con esta simulación?

Con el entorno simulado + RVTools export, habilitamos un flujo muy similar al de un piloto real:

Tener un inventario estructurado (RVTools) con “señales” de infraestructura.
Alimentar AWS Transform con ese dataset para que genere:
Agrupaciones por aplicación o dependencias.
Recomendaciones de red VMware→VPC.
Wave planning.
Conectar una cuenta destino y preparar la infraestructura target.
Avanzar hacia ejecución integrando AWS MGN para el rehost a EC2 nativo.

En resumen: esta práctica no busca “migrar VMware en sí”, sino probar el proceso completo de planificación y migración usando los artefactos que se usan en la vida real, pero con un laboratorio repetible y seguro.

⭐ Habilitar AWS Transform y preparar el workspace

En la consola:

Entrar a AWS Transform

Habilitar el servicio AWS Transform en nuestra consola.

Se selecciona la plataforma que utilizaremos para poder hacer login en el servicio. (AWS Transform web application para esta actividad).

Debemos administrar los usuarios que podrán tener acceso a este servicio.

Se asignan usuarios o grupos acceso (conexión con nuestro servicio de login en este caso "Identity Center").

👉 Debe mostrar una pantalla similar.

Procedemos a iniciar sesión en el servicio de AWS Transform, copiando la URL indicada en en la imagen en nuestro en el navegador.

COn los pasos anteriores, debemos tener ya habilitado el servicio de AWS Transform en nuestra consola.

⚡ Iniciamos nuestro proceso de trabajo en AWS Transform

Creamos nuestro un Workspace

Crea un Migration Job del tipo Migration

Selecciona el tipo de Migración VMware Migration

AWS Transform prepara el entorno inicial (unos minutos) y te guía con tareas para el proceso.

Seleccionamos el tipo de job que realizaremos

Para esta actividad, sera un End-to-End Migration

Se inicia el Proceso, mostrando todos los pasos que se tomaran durante este proceso Job Plan.

Importación de Inventario (Fase 1 del Job Plan)

Se procede a cargar el RVTools y se da submit y dejamos que la IA haga su trabajo

Comienza el analisis del archivo RVTools.

Construcción Plan de Migacion (Fase 2 del Job Plan)

Muestra información recopilada del RVTools y nos pide si queremos continuar con la construcción del Plan de migración.

El proceso va guiando e indicando algunas recomendaciones y opciones para la construcción del plan de migración.

Despues de una serie de iteraciones se muestra una propuesta de plan de Migración.

En todo este proceso se combinan mejores prácticas con la información que entrega el cliente sobre sus cargas de trabajo. Esto nos permite interactuar con la herramienta y validar sus recomendaciones, ajustándolas cuando sea necesario, para construir un plan de trabajo realista y alineado con las necesidades del negocio y los requisitos técnicos.

Revisado el plan de migración propuesto y hecha su aprobación, se procede a construir dicho plan.

En la construcción del Plan se muestra, el sumario de Olas de migración (el cual se aprueba de estar de acuerdo).

Configuracion Cuenta destino de AWS (Fase 3 del Job Plan)

Conexión cuenta target (cuenta destino en AWS)

Se configura cuenta

Procedemos a aprobar la conexión a esa cuenta target en el navegador, usando el link que entrega la herramienta. (Al finalizar debemos dar submit en AWS transform)

Se muestra las primera 3 etapas listas.

Configuracion Cuenta destino de AWS (Fase 4 del Job Plan)

Preparación del entorno de red de AWS.

Se puede cargar un nuevo archivo RVTols con la información o usar opción 1, el mismo archivo usado anteriormente (nuestra opción).

SE selecciona el tipo de creación para la VPC. (para esta actividad será de tipo Isolated)

Se muestra un resumen de las configuraciones indicadas a la herramienta para su análisis.

AWS Transform te muestra 2 opciones para la realización del despliegue del networking en la cuenta target de AWS. (para esta actividad será de manera automática)

Se debe aprobar

Despues de aprobado el despliegue del networking, AWS Transform usa en Back, el servicio de CloudFormation, el cual se encargara de hacer el despliegue de lo definido en el paso anterior. }

Despues de realizada la construcción de la infraestructura de networking en la cuenta target, se nos muestra las 4 primeras actividades del Plan listas.

Ejecución del Plan de Migración (Fase 5 del Job Plan)

Se aprueba el inicio del Plan de Migración.

Se debe seleccionar las instancias EC2, que soportaran las cargas de trabajo a migrar.

Se procede con las Olas de migración definidas en el Plan de Migración.

Se debe habilitar el servicio MGN.

AWS Transform, usa el servicio AWS Application Migration Service (MGN) en Back, para realizar el proceso de migrar las cargas de trabajo, desde nuestro origen (on-premise o cuenta aws de simulación en nuestro caso), hasta la cuenta Target de AWS definida en el Plan de Migración.

Se valida que todo los pasos previos estén OK, para proceder con la migración de la primera Ola.

Muestra un resumen de lo que se realizara en el proceso de Migración de la Ola.

El servicio AWS MGN comienza el proceso de replica a la cuenta target de AWS.

Nota: Previamente MGN instalo el agente de replicación en la maquina a migrar.

Se inicia el proceso de sincronización.

Fin del proceso de migración.

Una vez finalizada la fase de replicación y sincronización de las máquinas por cada ola, se procede con el cutover, que es el momento en que las cargas de trabajo pasan oficialmente del entorno de origen al entorno en AWS.

Durante este proceso, AWS Application Migration Service (MGN) ejecuta una serie de pasos automatizados para garantizar que la transición sea segura y consistente. Primero, el servicio valida que la replicación esté completamente sincronizada y que no existan cambios pendientes entre el servidor de origen y el entorno de destino. Luego se detiene temporalmente la máquina en el entorno de origen para asegurar la consistencia de los datos y evitar divergencias en el estado del sistema.

A continuación, MGN lanza una instancia EC2 basada en la última réplica sincronizada, utilizando la configuración previamente definida en las plantillas de lanzamiento (Launch Templates), donde se especifican parámetros como tipo de instancia, subred, grupos de seguridad y almacenamiento. Esta instancia representa la versión final del servidor ya ejecutándose en AWS.

Durante el cutover también se pueden ejecutar pruebas de validación, verificar conectividad, comportamiento de la aplicación y dependencias entre sistemas. En muchos casos, este paso forma parte de una ventana de mantenimiento controlada para minimizar el impacto en los usuarios o en los servicios productivos.

Una de las ventajas clave de AWS MGN es que permite realizar test cutovers antes del cutover final. Esto significa que se pueden lanzar instancias temporales en AWS para validar el funcionamiento de la aplicación sin interrumpir el sistema original, lo que reduce significativamente el riesgo durante la migración.

Finalmente, una vez confirmado que las instancias en AWS funcionan correctamente, se completa el proceso de cutover y las cargas de trabajo quedan operando en Amazon EC2, desde donde pueden continuar su proceso de optimización o modernización dentro del ecosistema de servicios de AWS.

Se debe repetir todos estos pasos de la Fase 5, para todas de las Olas definidas en el Plan de Migración.

🔧 Lecciones aprendidas

Durante el laboratorio aparecen algunos puntos interesantes:

La calidad del inventario impacta directamente la calidad del plan.
El wave planning automático acelera significativamente la planificación.
La traducción de red VMware → VPC elimina gran parte del trabajo manual

-Los test cutovers de MGN reducen el riesgo antes de migraciones productivas.

💬 Conclusión

Este Post muestra por qué AWS Transform se siente como un “cambio de era”:

Convierte un inventario tipo RVTools en un plan accionable.
Acelera el diseño de red a VPC
Baja la fricción para pasar a ejecución con MGN

Happy learnning on AWS!

Modernización sin fricción: AWS Transform y el futuro del rehosting inteligente. (Parte 1)

Oscar Gaviria — Mon, 23 Feb 2026 11:43:11 +0000

🧠Introducción

La realidad es evidente: cada vez más organizaciones están reevaluando su dependencia del ecosistema VMware. Entre incrementos de licenciamiento, deuda técnica acumulada y la presión por habilitar casos de IA, analítica y modernización, muchas empresas están buscando caminos más eficientes para migrar sus cargas hacia la nube.

El problema siempre ha sido el mismo:

➡️ descubrimiento lento,
➡️ dependencias ocultas,
➡️ semanas de planificaciones,
➡️ redes difíciles de traducir,
➡️ oleadas que cambian constantemente.

⚡ Pero esto ya no volverá a ser lo mismo. ⚡

AWS Transform para VMware es la herramienta que vino a cambiar completamente el juego.

📌 En este artículo analizaremos en detalle:

Que es AWS Transform
Que hace diferente a AWS Transform
Beneficios Concretos
Por qué este enfoque está ganando tracción

👉 Preambulo

Durante años, migrar cargas VMware ha sido sinónimo de procesos lentos, manuales y costosos. Descubrir servidores, mapear dependencias, traducir redes y planificar oleadas consumía semanas enteras antes incluso de mover la primera máquina. Las organizaciones sabían que necesitaban modernizar, pero la complejidad del camino frenaba la decisión.
Ese modelo se acaba hoy.

La llegada de agentic AI a la migración de infraestructura marca un punto de inflexión que redefine lo que es posible. Por primera vez, el proceso de mover VMware hacia cómputo nativo en la nube se vuelve inteligente, automatizado y radicalmente más rápido.

En este nuevo escenario, AWS Transform para VMware no es “una herramienta más”: es el cambio estructural que acelera la modernización, elimina semanas de trabajo manual y abre la puerta a costos más bajos, mayor eficiencia y adopción real de IA en las empresas.

🔍 ¿Qué es AWS Transform?

AWS Transform para VMware es el primer servicio de AI agentic diseñado para automatizar el ciclo completo descubrir → analizar → planear → migrar al mover cargas VMware hacia Amazon EC2 nativo.
No hablamos de “VMware en AWS”.

Aquí el objetivo es claro:

Salir del stack VMware, reducir costos y acelerar modernización.
Transform toma datos de descubrimiento (ADS, vCenter, datasets externos) y los procesa con IA para generar planes completos, dependencias, redes traducidas y oleadas listas para ejecutar, integrando herramientas como AWS MGN para el movimiento final.

⭐ ¿Qué hace diferente a AWS Transform?

1. Descubrimiento avanzado

Consume datos desde Application Discovery Service, Export for vCenter o datasets importados.
Identifica relaciones, dependencias, topologías y patrones de comunicación.

2. Traducción automática de red VMware → VPC

La IA convierte la estructura de redes VMware a un diseño VPC seguro, escalable y estandarizado.
Hasta 80x más rápido que la traducción manual.

3. Planificación inteligente de oleadas

Agrupa servidores en aplicaciones reales (no solo máquinas sueltas).
Calcula dependencias críticas, priorización y orden de migración.
Optimiza tiempos, riesgo y ventanas de cutover.

4. Migración orquestada a EC2 nativo

Orquesta el rehosting con herramientas como AWS MGN.
Permite pruebas, rollback controlado y validaciones automáticas.

5. Modernización acelerada

Una vez en Amazon EC2, las organizaciones pueden evolucionar hacia contenedores, serverless, analítica moderna o IA generativa (Bedrock).

⚡Beneficios Concretos

✔ Reducción significativa de costos al eliminar dependencias de licenciamiento VMware.

✔ Descubrimiento y diseño automatizado con IA.

✔ Planes de oleadas completos en minutos, no semanas.

✔ Menos riesgo gracias a dependencias detectadas automáticamente.

✔ Un flujo de migración unificado, colaborativo y guiado por agentes de IA.

✔ Base sólida para modernización real, no solo lift & shift.

📈 ¿Por qué este enfoque está ganando tracción?

Las señales del mercado son consistentes:

Los costos y cambios de licenciamiento VMware están impulsando a las empresas a reconsiderar su arquitectura.
Las organizaciones buscan salir del “bloque monolítico” y moverse hacia modelos nativos.
La IA generativa aplicada a migración elimina semanas de trabajo manual.
AWS Transform acelera la salida del stack VMware hacia un cómputo más liviano, flexible y económico.

💬 Conclusión

Si tu organización está considerando:

reducir costos y licencias VMware,
preparar una modernización real,
o simplemente entender su inventario VMware y crear un plan de salida…

👉 AWS Transform merece una prueba piloto inmediata.

El valor aparece desde el día uno:

descubrimiento automático + análisis de IA + planes de migración listos para ejecutarse.

Nota:
Se viene una Parte 2, con un ejemplo de migración usando AWS Transform.

Happy learnning on AWS!

🌐 Multicloud y Polycloud: La Nueva Realidad Arquitectónica de la nube.

Oscar Gaviria — Mon, 16 Feb 2026 12:05:59 +0000

🧠Introducción

Durante años el debate fue: ¿AWS, Azure o GCP?

Hoy sabemos que la pregunta correcta es otra:

👉 ¿Cómo integramos lo mejor de cada nube para acelerar al máximo nuestro negocio?
Las organizaciones modernas ya no buscan “elegir una nube”, sino construir un ecosistema multicloud y polycloud que combine lo mejor de cada proveedor, según su fortaleza técnica.

📌 En este artículo analizaremos en detalle:

Entendimiento de Multicloud y PolyCloud
¿Por qué AWS + GCP + Azure es una combinación tan poderosa?
¿Cuándo Multicloud? ¿Cuándo Polycloud?
Antipatrones de arquitectura a evitar

🚀 Preambulo

Multicloud y Polycloud: ¿Qué diferencia hay realmente?

🔹 Multicloud
Operar en varias nubes para incrementar resiliencia, disponibilidad, cumplimiento regulatorio y continuidad de negocio.

🔹 Polycloud
Elegir intencionalmente servicios específicos de cada nube porque son los mejores para resolver una necesidad puntual.
En otras palabras:

Multicloud es dónde operamos. (el dónde)
Polycloud es cómo sacamos ventaja. (el cómo)

⚙️ ¿Por qué AWS + GCP + Azure es una combinación tan poderosa?

🔸 1. Excelencia técnica por dominio

Cada nube tiene fortalezas claras:

AWS → madurez, ecosistema empresarial, servicios serverless, IoT, automatización.
GCP → datos, BigQuery, redes globales de baja latencia, IA nativa.
Azure → integración con entornos corporativos, Active Directory, Microsoft stack, compliance.

¿Por qué limitarnos a una sola? si podemos usar:

✔️ BigQuery para analítica masiva
✔️ DynamoDB o Aurora para cargas transaccionales
✔️ Azure AD / Entra para identidad empresarial
✔️ Vertex AI o Bedrock según modelo
✔️ Kubernetes distribuido entre los tres

Eso es polycloud real.

🔸 2. Resiliencia a nivel estratégico

Multicloud no es solo tener un “backup en otra nube”.

Es diseñar operación continua, incluso ante:

✔️ Caídas regionales
✔️ Incidentes globales
✔️ Restricciones regulatorias
✔️ Bloqueos comerciales o contractuales

Una arquitectura distribuida entre AWS, Azure y GCP aumenta la verdadera resiliencia organizacional.

🔸 3. Optimización de costos inteligente

Cada nube tiene zonas donde es más eficiente:

GCP → consultas masivas por segundo
AWS → almacenamiento sobredimensionado
Azure → integraciones empresariales

El modelo polycloud permite “colocar cada workload donde este tiene mejor desempeño”.

🔸 **4. Mayor velocidad de innovación

**Los equipos dejan de depender de limitaciones de un solo proveedor.
En su lugar, usan la herramienta correcta para el problema correcto, sin fricciones.

🔸 5. Preparación para un futuro híbrido y distribuido

Adquisiciones, fusiones, nuevos mercados y nuevas regulaciones obligarán a operar en múltiple nubes.
Las organizaciones que ya han construido ecosistemas multicloud/polycloud serán las que lideren.

Cuándo Multicloud? ¿Cuándo Polycloud?

Multicloud “defensivo” (baseline)

✔️Requerimientos regulatorios y de continuidad (DR multi‑proveedor).
✔️Negociación de costos y contratos.
✔️Proximidad a usuarios/partners específicos.
✔️Riesgo: costos operativos altos si no hay estandarización mínima.

📌 Polycloud “ofensivo” (ventaja competitiva)

✔️Time‑to‑value al adoptar el servicio óptimo (ej.: data warehouse nativo de un proveedor + feature store/ML de otro).
✔️Innovación: acceso al “best‑of‑breed” sin esperar paridad entre proveedores.
✔️Acelerar go‑to‑market con capacidades diferenciadas.
✔️Riesgo: complejidad de integración, observabilidad y gobierno de datos.

🌎 Antipatrones de arquitectura a evitar

✔️“Clone‑cloud”: duplicar toda la pila en cada proveedor sin una razón de negocio clara.
✔️Sobrestándar que impide usar ventajas nativas (terminas en “mínimo común denominador”).
✔️Observabilidad fragmentada: métricas y logs por silo → ciegueira durante incidentes.
✔️Bloqueo por networking: peering/transit mal diseñados que encarecen y agregan latencia innecesaria.
✔️Sin FinOps: costes impredecibles sin budgets, tags y unit economics por producto.

🔧 Conclusión

No se trata de “AWS vs Azure vs GCP”.
Eso ya es pasado.

La verdadera ventaja competitiva está en saber:

✔️ Integrar
✔️ Orquestar
✔️ Automatizar y operar eficientemente
✔️ Soluciones distribuidas entre las tres nubes.

El futuro de la arquitectura cloud es multicloud por necesidad
y polycloud por estrategia.

Happy learnning in the Cloud!

⚙️ “El Enlace Invisible: Cómo AWS mantiene conectada toda tu arquitectura”

Oscar Gaviria — Mon, 09 Feb 2026 11:58:43 +0000

🧠 Introducción

En la mayoría de los diseños en AWS ponemos el foco en VPCs, subnets, seguridad, IAM o servicios gestionados. Sin embargo, detrás de todo eso existe un componente silencioso—casi invisible—que determina cómo se conectan los servicios, cómo viajan los paquetes y cómo realmente escala una red en la nube: el enrutamiento.

Este elemento, aunque pasa desapercibido, es el engranaje que mantiene cohesionada toda la arquitectura.

👉 Preambulo

Es fácil dar el enrutamiento por sentado, porque “simplemente funciona”. Pero comprenderlo de verdad es lo que diferencia una arquitectura básica de una arquitectura resiliente, eficiente y preparada para fallos.

Dominar cómo opera el tráfico dentro y fuera de una VPC permite diseñar soluciones más seguras, optimizadas y predecibles… y es ahí donde muchos arquitectos marcan la diferencia..

✔️ En este artículo analizaremos en detalle:

El router
Route Tables
Internet Gateway, NAT Gateway
VPC Peering
Transit Gateway
PrivateLink
Rutas
Seguridad vs Enrrutamiento

🔹 1. El router implícito de la VPC: el gran olvidado
Cada VPC en AWS incluye un router lógico que opera de manera automática.
No lo ves, no lo configuras directamente… pero todas las rutas pasan por él.

Este router (el gran orquestador) ya que:

Mantiene la conectividad entre subnets de la misma VPC
Aplica las Route Tables asociadas
Gestiona el tráfico entrante y saliente (según rutas y gateways)

La conectividad intra‑VPC no es magia; ocurre gracias al router implícito de la VPC, un componente que AWS gestiona de forma transparente. Este router proporciona conectividad Full Mesh entre todas las subnets dentro de la misma VPC.

Por eso, no se necesita VPC Peering ni ninguna configuración adicional para lograr comunicación entre subnets: mientras compartan la misma VPC y las reglas de seguridad lo permitan, el tráfico fluye automáticamente.

🔹 2. Route Tables: el GPS de cada subnet
A diferencia de otros proveedores Cloud, en AWS cada subnet debe tener una Route Table asociada (la default o una explícita).

Las Route Tables definen:

Subredes internas disponibles
Tráfico hacia Internet
Rutas hacia on-premise
Rutas hacia otras VPC por Peering o Transit Gateway

Ejemplo típico:

  - 10.0.0.0/16      local
  - 0.0.0.0/0        igw-12345
  - 172.16.0.0/16    pcx-33333

📌 Regla de oro:
La entrada “local” nunca se puede modificar ni eliminar.

🔹 3. Internet Gateway, NAT Gateway y el rol de la red 0.0.0.0/0

Para que una subnet sea “pública”, su Route Table debe teneruna ruta parecida a esta:

 - 0.0.0.0/0 → igw-xxxx

Y las instancia dentro de esta subnet publica deben tener:

 - Una IP pública o Elastic IP
 - Permisos de Security Group para salida

Para subnets privadas:

 - 0.0.0.0/0 → nat-xxxx

Es decir, la diferencia entre pública y privada no es la subnet… sino su ruta por defecto.

Subnet publicas: para su salida a internet apuntan a un Internet Gateway (IG)
Subnet privada: para su salida a internet apuntan a un NAT Gateway (NG)

🔹 4. VPC Peering: rápido, simple… pero no escalable

El VPC Peering crea conectividad directa entre dos VPC, pero con limitaciones:

No soporta tránsito (A ↔ B ↔ C no funciona) Concepto de transitividad
No escala bien cuando hay muchas VPC's
No admite superposiciones de IP (Overlaping)

EL VPC peering es ideal para soluciones puntuales, pero no para topologías complejas.

🔹 5. Transit Gateway: el backbone de redes grandes
Cuando la organización crece, el enrutamiento necesita ordenarse.
Ahí entra AWS Transit Gateway (TGW):

Soporta miles de VPC
Permite conectar on-premise vía VPN o Direct Connect
Permite políticas de enrutamiento centralizadas
Sí permite tránsito entre VPC

En esencia y como se muestra en siguiente diagrama de referencia, el TGW es en un concentrador de comunicaciones entre VPC´s de alto rendimiento.

🔹 6. PrivateLink: conectividad sin exponer redes
Una confusión frecuente: PrivateLink no es enrutamiento.
Es un servicio point-to-point para exponer servicios, no redes completas.

Sirve para:

Conectar servicios entre VPC sin abrir rutas
Consumir servicios SaaS de forma privada
Evitar VPC Peering cuando no hace falta

PrivateLink minimiza la superficie de ataque porque expone únicamente un servicio específico y no toda la VPC. La comunicación se establece a nivel de endpoint, no a nivel de red.

🔹 7. Rutas hacia on-premise: VPN y Direct Connect
Cuando conectas on-premise a AWS, las Route Tables se enriquecen con rutas propagadas desde:

VPN (Site-to-Site)
Direct Connect
Transit Gateway

El principio siempre es el mismo:

👉 La ruta con la coincidencia más específica gana.

🔹 8. Seguridad vs. enrutamiento: roles diferentes
Es importante entender y diferenciar el papel que cumplen estos 2 componentes en nuestros diseños:

El enrutamiento decide a dónde va el tráfico.
Los Security Groups y NACLs deciden si está permitido.

Ambos operan juntos, pero con funciones complementarias.

🧩 Conclusión
Entender el enrutamiento en AWS permite diseñar redes:

Más seguras
Más escalables
Más resilientes
Más predecibles ante fallos

Y lo más importante: te permite tomar decisiones de arquitectura basadas en principios, no en intuición.

Happy learnning on AWS!

🌩️ VPC en AWS y GCP: La Comparativa Esencial para Arquitectos Cloud

Oscar Gaviria — Mon, 02 Feb 2026 11:49:15 +0000

☁️ Introducción

En el corazón de toda arquitectura cloud moderna existe un componente que define cómo viaja la información, cómo se segmentan los entornos y cómo se protege cada carga de trabajo: las Virtual Private Clouds (VPC). Estas redes virtuales permiten construir una infraestructura aislada, segura y altamente configurable dentro de la nube, ofreciendo a las organizaciones el control necesario para desplegar aplicaciones a escala global. Tanto AWS como GCP han desarrollado su propio enfoque de VPC, cada uno con una filosofía distinta de diseño de red, automatización y operación. Entender estas diferencias es fundamental para elegir la estrategia adecuada y diseñar arquitecturas eficientes, seguras y preparadas para el futuro.

Preambulo

Las VPC son la base de la red en la nube. Pero aunque AWS y GCP las llamen igual, su modelo de funcionamiento y administración es muy distinto. Aquí te dejo una guía clara para entenderlas, compararlas y elegir la mejor opción según tu caso.

☁️ ¿Qué es una VPC?

Una VPC (Virtual Private Cloud) es una red virtual aislada dentro de un proveedor cloud. Es el equivalente moderno de tu red física tradicional, pero con la flexibilidad del software y sin necesidad de administrar hardware.
Cada proveedor la implementa con su propia filosofía.

🔶 VPC en AWS: Control Total y Modelo Inmutable

La Amazon VPC sigue un enfoque tradicional muy similar a cómo se diseña una red en un data center físico.

🔍 ¿Cómo funciona una VPC en AWS?

La VPC es Regional, no global.
La VPC es la unidad principal de red.

Dentro de ella se defines:

Cada VPC es completamente aislada, y el usuario controla su topología desde cero.

⭐ Ventajas de AWS VPC

Gran granularidad y control. Puedes definir todo: desde rutas hasta ACLs por subnet.
Aislamiento fuerte. Cada VPC opera como un entorno totalmente independiente.
Red extremadamente predecible. Nada cambia automáticamente; tú administras todo.
Madurez y ecosistema robusto. Es el servicio más consolidado del mercado.

🔧 Ideal para:

Arquitecturas con fuerte control de seguridad.
Empresas que migraron desde on‑premise y buscan un modelo familiar.
Entornos donde se necesita personalizar cada detalle de red.

🔵 VPC en GCP: Simplicidad, Globalidad y Modelo Distribuido
Google tomó otro camino: una VPC global para toda la organización, lo que permite una red más flexible y escalable sin necesidad de múltiples VPC regionales.

🔍 ¿Cómo funciona una VPC en GCP?

La VPC es global, no regional.
Las subnets sí son regionales, pero viven dentro de una única VPC.

No existen NACLs. El firewall de GCP opera a nivel de VPC, no de subnet.

⭐ Ventajas de GCP VPC

Menor complejidad. Topología más simple: centralizas políticas y controles.
Red global. Puedes comunicar regiones sin VPC peering.
Firewall más intuitivo. Políticas unificadas y basadas en tags.
Enrutamiento inteligente. Google gestiona gran parte del tráfico mediante SDN.

🔧 Ideal para:

Empresas que priorizan simplicidad operativa.
Workloads distribuidos globalmente.
Organizaciones que valoran la abstracción sobre el detalle.

⚔️ AWS vs GCP: Comparación Directa

✔️ Rango CIDR

AWS

Se define un CIDR por VPC (ej: 10.0.0.0/16)

GCP

También se define un CIDR por VPC, pero:

Los CIDR son globales, no por región.
Las subnets sí son regionales y cada una tiene su propio rango IP.

Ejemplo:
VPC global: sin rango fijo
Subnet (us-central1): 10.0.0.0/24
Subnet (europe-west1): 10.0.1.0/24

✔️ Subnets públicas y privadas

AWS

Subnets públicas: tienen ruta al IGW
Subnets privadas: salen a internet por NAT Gateway

GCP

No existe el concepto “público/privado” como tal.
Una Subnet solo tiene IPs internas.
El “ser público” depende de:
- Si la VM tiene IP externa
- Si la route table permite salida por el default internet gateway

✔️ Route Tables

AWS

Cada subnet se asocia a una Route Table.

GCP

Existe una sola tabla de rutas por VPC, y las rutas aplican a todas las subnets.
Se pueden agregar rutas específicas (estáticas o dinámicas con Cloud Router).

✔️ Internet Gateways y NAT Gateways

AWS

IGW = salida a internet
NAT GW = salida a internet para subnets privadas

GCP

No existe un “Internet Gateway” explícito.
El enrutador por defecto de GCP permite la salida a internet si la VM tiene una IP pública.

Equivalente a NAT Gateway:

Cloud NAT

Servicio administrado, escalable y regional.
Funciona muy parecido al NAT Gateway de AWS.

✔️ NACLs (Network ACLs)

AWS

ACLs por subnet
Regla inbound + outbound

GCP

GCP NO tiene NACLs.
Todo se maneja con Firewall Rules a nivel de VPC.

✔️ Security Groups (SG)

AWS

Firewall por instancia
Stateful

GCP

Firewall Rules globales por VPC, pero aplicadas a:

Tags de red (network tags)
Cuentas de servicio (identity-based firewall)
Son stateful igual que los SG.

✔️ Resumen

🧭 ¿Cuál elegir?

Depende del enfoque de tu arquitectura:
✔ Si buscas control absoluto → AWS
Perfecto para arquitecturas complejas, ambientes regulados o equipos expertos en redes.
✔ Si quieres simplicidad y escala global → GCP
Ideal para organizaciones ágiles que quieren centralizar políticas y moverse rápido.

🏁 Conclusión

Las VPC son el corazón de cualquier infraestructura Cloud, y entender las diferencias entre AWS y GCP te permite diseñar arquitecturas más seguras, eficientes y alineadas con tu estrategia.
AWS ofrece control granular y predictibilidad.
GCP ofrece simplicidad, escala global y un modelo moderno basado en SDN.

La elección no es cuál es mejor, sino cuál se ajusta más a tu visión como arquitecto.

Happy learnning on AWS and GCP!

“Arquitecturas Resilientes en AWS: Todo Empieza Entendiendo Su Infraestructura”

Oscar Gaviria — Mon, 26 Jan 2026 12:13:50 +0000

Uno de los aspectos más importantes al diseñar arquitecturas en AWS capaces de soportar nuestras cargas de trabajo —o las de nuestros clientes— es analizarlas desde tres grandes perspectivas:

1️⃣ Comprender el negocio y su necesidad real

Antes de elegir servicios o patrones, es fundamental entender qué necesita el negocio, qué problema se debe resolver y qué métricas definen el éxito.

2️⃣ Identificar los servicios adecuados

AWS ofrece una amplia variedad de servicios; elegir los correctos es clave para lograr eficiencia, seguridad y escalabilidad.

3️⃣ Entender cómo está construida la infraestructura de AWS (tema central de este artículo)

Conocer la estructura física y lógica sobre la que funcionan nuestros servicios es esencial para diseñar arquitecturas resilientes, disponibles y preparadas para fallos.

📌 En este artículo analizaremos en detalle:

Regiones
Zonas de Disponibilidad (AZs)
Alta Disponibilidad (HA)
Recuperación ante Desastres (DR)
RTO
RPO

Preámbulo

Cuando hablamos de arquitecturas resilientes en la nube, lo primero que debemos entender no son los servicios, sino la infraestructura física que los soporta. AWS fue diseñada desde su base para tolerar fallas, aislar riesgos y garantizar continuidad incluso ante desastres mayores.

Aquí explico un claro resumen de cómo se organiza esta infraestructura.

🌎 Regiones en AWS:

Una Región de AWS es una ubicación física geográfica, como us-east-1, eu-west-1 o sa-east-1.

Están distribuidas estratégicamente a nivel global, lo que permite:

✔️ Reducir la latencia para usuarios locales
✔️ Cumplir normativas de soberanía de datos
✔️ Aislar fallas entre países o continentes
✔️ Crear estrategias de DR multi-región

Cada región en AWS, esta compuesta por al menos 3 Zonas de Disponibilidad (AZ), lo que permite crear distintas estrategias de resiliencia.

Importante:
Las regiones en AWS, no comparten infraestructura eléctrica, de red ni datacenters entre sí. Son entornos completamente independientes.

🧩 Zonas de Disponibilidad en AWS (AZ):

Una AZ puede estar compuesta por uno o varios datacenters discretos, separados por varios kilómetros entre sí, pero conectados mediante enlaces privados, de baja latencia y alta capacidad.

Ejemplos:
us-east-1a, us-east-1b, us-east-1c.

Características clave:

Energía independiente
Sistemas de enfriamiento propios
Conectividad redundante
Aislamiento físico real
Conexión interna de baja latencia

Estas características permiten ejecutar sistemas en activo-activo dentro de la región.

En otras palabras:
Si una AZ falla, las otras continúan operando.

🟢 Alta Disponibilidad (HA) en AWS

La Alta Disponibilidad (HA) es la capacidad de un sistema para seguir funcionando incluso cuando uno o varios componentes fallan.

En AWS, la HA se construye distribuyendo recursos entre múltiples AZ dentro de la misma región.

Características claves de HA usando Multi-AZ en AWS

✔️ Redundancia geográfica intra-región
✔️ Tolerancia a fallas locales (AZ caída)
✔️ Balanceo de carga inteligente (ALB/NLB)
✔️ Replicación sincrónica donde aplica
RDS Multi-AZ
EFS Multi-AZ
✔️ Auto Scaling distribuido entre AZ

¿Por qué es importante la HA en nuestros sistemas y negocio?

Reduce la probabilidad de caída total del servicio.
Garantiza continuidad operativa.
Permite cumplir SLAs estrictos (99.9% a 99.99%).
Minimiza el impacto de mantenimientos programados.

En resumen, HA = resiliencia dentro de una región.

🔥 Disaster Recovery (DR) en AWS

La Recuperación ante Desastres (DR) es la capacidad de restaurar la operación del sistema cuando ocurre un desastre de gran escala, normalmente una falla completa de una región.

Características clave del DR

✔️ Aislamiento total entre regiones
✔️ Replicación entre regiones (generalmente asincrónica):

S3 Cross-Region Replication
Aurora Global Database
RDS Cross-Region Read Replicas

✔️ Despliegue de ambientes completos o parciales, según la estrategia:

Backup & Restore —-> más económico, mayor RTO
Pilot Light
Warm Standby
Active-Active -—-> más costoso, menor RTO

✔️ Dependencia de las métricas RTO y RPO

La elección de la estrategia depende de estos dos métricas, las cuales son muy importantes y vienen dadas por la capacidad y necesidad del negocio de mantener su continuidad operativa.

⏱️ RTO y RPO: Métricas que gobiernan HA y DR

RTO — Recovery Time Objective: Tiempo máximo que el negocio acepta que un sistema esté fuera de servicio.

Ejemplo:
Si un retail sufre la caída de la región donde opera su sistema de ventas, el RTO indica cuánto tiempo puede estar sin vender antes de que el impacto sea crítico.
Es decir, cuánto tiempo pueden estar “fuera del aire” sin que la situación se convierta en un problema serio para la organización.

RPO — Recovery Point Objective: es la cantidad máxima de datos que el negocio acepta perder.

Ejemplo:
Si la región cae, el RPO indica cuántas transacciones no registradas puede tolerar el retail sin impacto significativo.

En otras palabras, es cuántas ventas podrían no registrarse antes de que la situación se convierta en un problema serio para la organización.

*Diagrama de referencia una solucion HA (activo-activo), con un DR en el cual solamente la capa aplicativo y web, se encuentra apagado. *

RPO ~ 0 min ---> la data se replica otra región de manera Async (BBDD)
RTO <= 30 min ---> Encendido de maquinas y pruebas de funcionamiento

🧭 Conclusión:
Para comprender bien la diferencia entre HA y DR, basta recordar su alcance:

HA actúa dentro de una región, distribuyendo carga entre AZs.
DR actúa entre regiones, permitiendo recuperar operaciones ante fallas catastróficas.

Conocer esta infraestructura es clave para diseñar soluciones robustas, resilientes y alineadas al negocio.

Happy learnning on AWS!

AWS AWS Security Groups vs NACLs: (Stateful vs Stateless explicado fácil para proteger tus cargas de trabajo)

Oscar Gaviria — Wed, 21 Jan 2026 13:33:00 +0000

Cuando comienzas tu camino en el mundo Cloud, especialmente en AWS, uno de los conceptos que suele generar más confusión —sobre todo para quienes no vienen del ámbito de networking— es entender cómo funcionan los Security Groups (SG) y las Network ACLs (NACLs).

Ambos forman parte esencial de la capa de seguridad dentro de una VPC, pero cumplen roles distintos, operan en niveles diferentes y, sobre todo, no se comportan igual.

Es muy común que los principiantes los confundan o los utilicen de manera incorrecta. Esta confusión puede provocar problemas de conectividad, fallas inesperadas entre servicios o, peor aún, brechas en la seguridad del entorno. Por eso, comprender claramente su propósito, su ámbito de aplicación y la diferencia entre stateful y stateless es fundamental para diseñar arquitecturas seguras y mantener un control adecuado del tráfico en AWS.

✔️ En este artículo analizaremos en detalle:

Qué son los Security Groups y cómo operan a nivel de instancia/ENI.
Qué son las Network ACLs y cómo actúan como firewalls de subred.
Qué significa que algo sea stateful o stateless, y por qué esto cambia totalmente el comportamiento del tráfico.
Cuándo usar uno, cuándo usar el otro y cuándo usar ambos para una estrategia de defense in depth.
Ejemplos reales de configuraciones y errores comunes que suelen encontrarse en entornos productivos.

El objetivo es que, al finalizar esta lectura, tengas una visión clara y práctica para aplicar estos conceptos en tus propios proyectos en AWS sin caer en las confusiones típicas del inicio.

✔️ ¿Qué es un Security Group (SG)?

Son un conjunto de reglas, que controla que trafico de red puede entrar o salir de nuestras cargas de trabajo. Es el mecanismo de defensa mas cercano a nuestras cargas de trabajo.

✔️ Características clave

Es stateful.
Se aplica a nivel de recursos (EC2, RDS, Lambda ENI, etc.).
Reglas de inbound y outbound.
Permite reglas evaluando otros security group, IP o rangos de Ips.
Solo se puede permitir trafico.

✔️ Ejemplo de uso

Permitir solo tráfico HTTP/HTTPS a un servidor web.
Permitir acceso SSH solo desde una IP fija.

✔️ Statefull

Es un concepto fundamental para comprender el comportamiento del tráfico en los Security Groups (SG).
Cuando decimos que los SG son stateful, nos referimos a que tienen la capacidad de recordar el estado de una conexión. Esto significa que, si en una regla —ya sea inbound o outbound— se permite un tipo de tráfico, no es necesario crear una regla adicional para permitir su retorno.

En palabras más simples:

Si permito la salida desde mi máquina hacia un destino, entonces la respuesta asociada a ese tráfico queda automáticamente permitida.
Y si permito la entrada de cierto tráfico, la salida de retorno también queda permitida sin definir reglas adicionales.
Es decir, los Security Groups se encargan automáticamente del flujo bidireccional asociado a una conexión legítima, simplificando la configuración y reduciendo errores.

✔️ ¿Qué es una Network Control Access List (NACLs)?

Una NACL es una lista de control de acceso a nivel de subred (Subnet) dentro de una VPC.
Actúa como un firewall stateless que filtra el tráfico que entra y sale de cada subnet.

Piensa en la NACL como una frontera que protege la red antes de que el tráfico llegue a las instancias.

✔️ Características clave

Es stateless.
Se procesa ordenadamente por número de regla.
Requiere reglas explícitas tanto para entrada como salida.
Puede permitir o denegar tráfico.
Se aplica a subnets completas.

✔️ Ejemplo de uso

Bloquear tráfico no deseado a una subnet completa.
Limitar puertos específicos antes de que lleguen a los SG.

✔️ Stateless

A diferencia de los Security Groups, las Network ACLs (NACLs) en AWS son stateless, y este concepto es clave para entender por qué requieren una configuración más precisa —y a veces más compleja— a la hora de permitir o denegar tráfico dentro de una VPC.
Cuando decimos que las NACLs son stateless, nos referimos a que no tienen la capacidad de recordar el estado de una conexión. No rastrean ni reconocen que un paquete pertenece a una sesión ya establecida.
Esto implica algo muy importante:

Cada dirección del tráfico debe ser permitida explícitamente.

En palabras más simples:

Si permites la entrada de cierto tráfico en una NACL, esto NO implica que la salida de retorno esté permitida.
Y si permites la salida hacia un destino, la respuesta tampoco estará permitida automáticamente.
Debes crear dos reglas independientes: una para el trafico de ida y otra para el tráfico de vuelta.

Esto significa que, en una NACL, permitir tráfico implica siempre pensar en ambos sentidos, porque la NACL no hará ninguna “magia” adicional como sí ocurre con los SG.

✔️ Comparación rápida: NACL vs Security Group

✔️ Puertos Efimeros (ojo importante a esto)

Los puertos efímeros son puertos temporales que usa el sistema operativo para establecer conexiones salientes.

Cuando una instancia, contenedor o servicio envía una solicitud hacia otro destino, el tráfico de ida utiliza el puerto específico del servicio (por ejemplo, 443), pero la respuesta vuelve por un puerto efímero.

Ejemplo típico:

La EC2 inicia conexión al puerto 443 de un servidor externo.
El servidor responde, pero la respuesta llega a un puerto aleatorio, como por ejemplo TCP 49152.

Estos puertos se asignan de forma automática y varían según el sistema operativo, pero normalmente están en rangos como:

1024 – 65535 (Linux)
49152 – 65535 (rango IANA recomendado)

✔️ Cómo afectan los puertos efímeros a las NACLs y SG

SG: Como vimos, los Security Groups son stateful, lo que significa que el sistema reconoce automáticamente que una respuesta forma parte de una conexión válida ya establecida. Gracias a este comportamiento, no es necesario configurar reglas adicionales para permitir el tráfico de retorno: si la conexión fue permitida en un sentido, la respuesta quedará permitida de forma automática.

En otras palabras, los SG gestionan de forma transparente el flujo bidireccional asociado a cada conexión, simplificando la configuración y reduciendo enormemente el riesgo de errores.

NACLs: En el caso de las NACLs, como vimos, son completamente stateless, lo que significa que no recuerdan ninguna conexión. Debido a esto, debes tener especial cuidado al configurar reglas: si permites tráfico en un sentido, debes permitir explícitamente el tráfico de respuesta en el sentido contrario.

Y aquí es donde entra en juego un punto clave:
La mayoría de los servicios no responden usando el mismo puerto al que te conectaste, sino que utilizan puertos efímeros para enviar la respuesta. Si no tienes un patrón específico de puertos definidos y no habilitas el rango de puertos efímeros adecuado, la respuesta será bloqueada por la NACL, incluso si la regla de ida está correctamente configurada.
Por eso, al trabajar con NACLs, siempre debes asegurarte de permitir los puertos efímeros en la dirección contraria al tráfico iniciado. De lo contrario, la conexión fallará, aunque todo lo demás esté bien configurado.

✔️ Conclusión

Los Security Groups y las Network ACLs forman la base de la seguridad en cualquier arquitectura desplegada dentro de una VPC en AWS. Aunque a primera vista pueden parecer similares, entender sus diferencias es fundamental para diseñar entornos seguros, eficientes y libres de errores de conectividad.
Los Security Groups, al ser stateful, simplifican enormemente la administración del tráfico a nivel de instancia, permitiendo que toda conexión legítima fluya sin necesidad de reglas duplicadas. Son ideales para controlar el acceso directo a recursos específicos, aplicar principios de mínimo privilegio y asegurar servicios críticos como EC2, RDS, Load Balancers, entre otros.

Por otro lado, las NACLs, al ser stateless, proporcionan una capa adicional de seguridad a nivel de subred. Su capacidad de permitir y denegar tráfico explícitamente las convierte en un mecanismo poderoso para implementar políticas más estrictas o filtrar tráfico antes de que alcance los recursos internos. Sin embargo, su naturaleza stateless requiere mayor precisión al configurarlas, ya que cada flujo debe ser permitido en ambos sentidos.

En conjunto, SG y NACL ofrecen un enfoque de defense in depth, donde cada capa de la red contribuye a proteger los sistemas ante accesos no autorizados, errores de configuración o vulnerabilidades inesperadas. Un diseño bien equilibrado entre ambos no solo mejora la seguridad, sino también la estabilidad operativa de la plataforma.
Comprender cómo funcionan, cómo interactúan y cuándo utilizar cada uno es un paso clave para cualquier profesional que esté construyendo soluciones en AWS. Al dominar estos conceptos, podrás crear entornos más robustos, seguros y alineados con las mejores prácticas del mundo Cloud.

Happy learnning on AWS!