DEV Community: Pablo Gonzalez Robles

AWS PrivateLink - VPC Endpoints: Gateway vs Interface para acceso a Amazon S3 (en español sencillo) - Parte 2

Pablo Gonzalez Robles — Sun, 29 Mar 2026 21:25:40 +0000

Hola comunidad,

En mi post anterior, exploramos cómo conectarnos a instancias EC2 completamente privadas utilizando AWS Systems Manager (SSM) y VPC Endpoints, logrando eliminar la necesidad de exponer puertos a internet o lidiar con Bastion Hosts y Key Pairs. Si no lo has leído, te invito a revisarlo primero: https://dev.to/pangoro24/aws-privatelink-acceso-a-instancias-ec2-privadas-con-y-ssm-en-espanol-sencillo-2kg3

Hoy continuamos con la segunda parte de esta serie. Aprovechando la infraestructura que ya construimos, vamos a abordar una duda de diseño muy común: ¿Cuál es la diferencia entre los VPC Endpoints de tipo Gateway y de tipo Interface?, y en qué casos usar cada uno.

Para hacerlo fácil de entender, usaremos como ejemplo el acceso a uno de los servicios más populares: Amazon S3. Además, he actualizado el repositorio del demo para que veamos la teoría aplicada a la práctica.

VPC Endpoints: Gateway vs Interface (El caso de S3)
Cuando tienes una instancia privada (sin salida a internet vía Internet Gateway o NAT Gateway) y necesitas leer o escribir archivos en un bucket de S3 de forma segura a través de la red interna, necesitas un VPC Endpoint para acceder al servicio. Actualmente tienes dos opciones principales y aquí te resumo de manera sencilla sus diferencias fundamentales:

Gateway VPC Endpoint:

Cómo funciona: No crea una interfaz de red física virtual (ENI) ni consume direcciones IP de tu subred. En su lugar, agrega automáticamente una ruta (mediante un Prefix List) en la Tabla de Rutas (Route Table) de tu VPC. Todo el tráfico dirigido hacia S3 es enrutado internamente por ahí.

Costo: ¡Es totalmente gratuito! No hay cargo por hora de uso ni por procesamiento de datos.

Limitación principal: El acceso está estrictamente limitado a los recursos que viven dentro de esa VPC. No puedes usar un Gateway Endpoint para acceder a S3 directamente desde tu red on-premises (vía VPN o Direct Connect) ni desde otras VPCs conectadas.

Imagen de referencia de: https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html

Interface VPC Endpoint (AWS PrivateLink):

Cómo funciona: Este fue el tipo de endpoint que usamos en el primer post para SSM. Crea una Interfaz de Red Elástica (ENI) dentro de la subred que elijas, asignándole una dirección IP privada. El tráfico se dirige hacia esa IP de manera local.

Costo: Tiene un costo asociado por hora por Zona de Disponibilidad, más un cargo por cada GB de datos procesado.

Ventaja principal: Al estar representado por una IP privada dentro de tu red, permite el acceso a S3 desde redes on-premises (mediante AWS Direct Connect o Site-to-Site VPN) o desde entornos multi-cuenta centralizados.

La Regla de Oro para S3:

Si el tráfico hacia tus buckets nace exclusivamente desde instancias EC2 u otros recursos alojados dentro de esa misma VPC, opta siempre por el Gateway Endpoint para ahorrar costos y simplificar el enrutamiento. Si requieres acceso desde on-premises o arquitecturas hub-and-spoke complejas, el Interface Endpoint es el camino a seguir.

La Solución: Acceso a S3 en nuestro Demo

Para no quedarnos solo en la teoría, he aplicado estos conceptos en la misma arquitectura base que desplegamos anteriormente.

En esta actualización, he modificado las plantillas de infraestructura en el repositorio para incluir el aprovisionamiento de un VPC Endpoint para S3, dejándote el código listo para que despliegues el de tipo Gateway o el de tipo Interface, para que puedas usar el que mejor se adapte a tu caso de uso. Si optas por desplegar el Gateway, CloudFormation se encarga de inyectar las reglas necesarias en la tabla de rutas de nuestra subred privada; si optas por el Interface, se aprovisionará una interfaz de red local. De cualquier manera, la instancia a la que accedemos vía Fleet Manager ahora tiene el camino despejado para interactuar con Amazon S3 sin tocar en ningún momento el internet público, manteniendo el esquema de "Zero Trust" a nivel de red externa.

¿Dónde puedo ver un ejemplo de implementación?
He subido los cambios a las plantillas de CloudFormation en el mismo repositorio público. Allí encontrarás el código necesario en la carpeta de vpce para ver cómo se declara un Gateway Endpoint y se asocia a las tablas de enrutamiento.

Repositorio:
https://github.com/pangoro24/aws-privatelink-private-instance-ssm

Si sigues la guía de despliegue actualizada en el Readme:

Desplegarás la VPC privada.

Desplegarás los Endpoints de interfaz (para SSM) y el nuevo Endpoint para S3.

Desplegarás la instancia EC2.

Al conectarte a tu instancia mediante Systems Manager Fleet Manager (sin internet), podrás abrir la consola y ejecutar comandos contra el CLI de AWS S3 (por ejemplo, listar buckets o descargar archivos) y verás que la comunicación es completamente exitosa.

Bonus: te dejo también la plantilla de un bucket de s3 mantener todo por infraestructura como código :)

Nota: Como siempre, no olvides eliminar el stack de CloudFormation cuando termines el laboratorio para evitar cobros de los Endpoints de Interfaz y la instancia EC2 si no los vas a necesitar.

Conclusión

Entender la diferencia entre un Gateway y un Interface Endpoint es clave para diseñar arquitecturas en la nube que sean seguras, escalables y costo-efectivas. Mientras que la flexibilidad de las IPs de un Interface Endpoint (PrivateLink) nos salva la vida en arquitecturas híbridas, los Gateways siguen siendo los reyes indiscutibles para el acceso interno hacia Amazon S3 y DynamoDB con un costo de $0.00.

En la próxima entrega, presentaré un caso de uso muy interesante y común sobre los VPC Endpoints de tipo Interface; algo que todo ingeniero de nube debería conocer, ya que puede que te toque implementarlo.

Gracias por leer.

AWS PrivateLink - Acceso a Instancias EC2 Privadas a través de VPC endpoints y Systems Manager (en español sencillo)

Pablo Gonzalez Robles — Sun, 22 Mar 2026 15:35:51 +0000

Hola comunidad,

Seguramente te has encontrado en la necesidad de acceder a una instancia EC2 que se encuentra en una subred privada. Tradicionalmente, la solución implicaba configurar un Bastion Host (o Jumpbox), o peor aún, asignarle una IP pública y abrir puertos en los Security Groups. Además, la administración requería lidiar con la gestión de llaves SSH o pares de claves (Key Pairs) de Windows, lo que añade una capa extra de complejidad operativa y riesgos de seguridad.

Si te interesa simplificar esto y garantizar un acceso 100% privado y seguro, sin depender de reglas de entrada o salida a internet en tus instancias ni gestión de contenedores de llaves, este artículo es para ti. En este post estaré revisando:

Qué es AWS PrivateLink y qué son los VPC Endpoints
Cómo conectarnos a EC2 sin necesidad de Access Keys o Key Pairs
Cómo mantener la comunicación privada sin acceso a internet
Un ejemplo de la arquitectura y despliegue

¿Qué es AWS PrivateLink y qué son los VPC Endpoints?

Para entender la solución, primero debemos hablar de dos conceptos fundamentales, que juntos forman la base de la comunicación interna segura en AWS:

AWS PrivateLink

Es una tecnología altamente disponible y escalable que proporciona conectividad privada entre Virtual Private Clouds (VPC), servicios compatibles de AWS y tus redes on-premises. La magia de PrivateLink radica en que el tráfico de red no atraviesa la Internet pública, reduciendo significativamente la exposición a amenazas de ciberseguridad. En lugar de salir a internet, todo viaja directamente a través de la red troncal (backbone) privada de Amazon.

VPC Endpoints

Para poder utilizar PrivateLink, necesitas un punto de entrada en tu red. Existen dos tipos principales de endpoints de VPC, pero para este caso nos enfocaremos en los Interface VPC Endpoints. Estos actúan como interfaces de red elásticas (ENI) virtuales con direcciones IP privadas dentro de tus propias subredes. Su propósito es servir como la puerta de enlace que enruta de manera local el tráfico dirigido hacia un servicio de AWS.

La Solución: Acceso a la instancia sin bastions o key Pairs usando vpc endpoints y ssm

El enfoque moderno y recomendado por AWS para administrar instancias es utilizar AWS Systems Manager (SSM) Session Manager, y para entornos gráficos como Windows de manera unificada desde la consola, su función de Fleet Manager.

La arquitectura segura para lograrlo funciona de la siguiente manera:

Instancia Completamente Privada: Desplegamos nuestra instancia EC2 en una subred privada, sin asignarle una IP Pública y en una VPC que no necesita tener configurado ni un Internet Gateway (IGW) ni un NAT Gateway.
Cero Key Pairs: No asociamos ningún Key Pair al momento de crear la instancia para conectarnos. En su lugar, le adjuntamos a la instancia un IAM Role (Instance Profile) que le otorga los permisos necesarios al agente (SSM Agent) para comunicarse de forma segura con AWS Systems Manager.
VPC Endpoints para SSM: Para que el SSM Agent instalado en nuestra instancia EC2 pueda hablar con el servicio de Systems Manager (cuyos servidores están fuera de nuestra VPC) sin usar internet, aprovisionamos VPC Endpoints de interfaz principales como ssm, ssmmessages y ec2messages.
Security Groups Restrictivos: Todo ocurre localmente. Como la comunicación es mediante los Endpoints dentro de la misma red local (VPC), no dependes de reglas de entrada o salida hacia/desde el exterior (0.0.0.0/0). La EC2 no necesita abrir un puerto 22 (SSH) o 3389 (RDP) para tu IP. Solo necesitas que el Security Group permita el tráfico interno en tu subred hacia el puerto HTTPS (443) de los Endpoints.
Acceso Dinámico y Justo a Tiempo (JIT) vía SSM: Aquí es donde la solución destaca. Como no utilizamos Key Pairs iniciales, cuando necesitas entrar a la instancia puedes enviar un comando remoto con SSM (Run Command) de forma segura para preconfigurar al usuario e inyectar su respectiva contraseña. Luego, una vez terminada la sesión o tu tarea, podrías enviar otro comando para eliminar o deshabilitar ese usuario nuevamente. Esto te faculta para crear accesos al momento en que se necesitan y removerlos posterior al uso, evitando la perdurabilidad de contraseñas.

Al final de esta arquitectura, logramos nuestra misión:
✅ Cero exposición a internet: Al no requerir IGW ni NAT, la máquina es invisible desde el exterior.
✅ Cero administración de llaves estáticas: El acceso es auditado y autenticado mediante políticas de IAM, y permitimos accesos dinámicos configurables al vuelo con SSM, fácilmente revocables.
✅ Comunicación 100% privada: Todo el tráfico entre tu EC2 y la consola de Systems Manager está asegurado por la red troncal de AWS.

¿Dónde puedo ver un ejemplo de implementación?

He subido un demo completo a mi repositorio público. Allí encontrarás las plantillas de CloudFormation (en las carpetas de vpc, vpce e instance) y todo el laboratorio necesario para poner esto a prueba en tu propia cuenta.

Repositorio:
https://github.com/pangoro24/aws-privatelink-private-instance-ssm

Si te diriges a la guía de despliegue dentro del repositorio, podrás ver un paso a paso para:

Desplegar una VPC y subredes verdaderamente privadas.
Desplegar los Endpoints de VPC con sus reglas de red para permitir PrivateLink. Sin estos vpc endpoints, recibirás error al intentar conectarse a la instancia.

Desplegar un Windows Server configurado con el Instance Profile de IAM.
Establecer una nueva clave interactiva al sistema sin usar RDP externo y acceder usando Fleet Manager de Systems Manager directamente desde tu navegador.

Si el despliegue de los recursos se realiza exitosamente, al intentar conectarte a la instancia de ec2 podrás ver un status para Session Manager connection de "Connected". De lo contrario, verás un mensaje de "No connected"

Al conectarse a fleet manager, podremos ver la pantalla de windows pero sin acceso a internet porque obviamente, la instancia vive en la red privada.

Conclusión

Utilizar AWS PrivateLink y VPC Endpoints en conjunto con Systems Manager elimina una enorme carga operativa asociada a la rotación de llaves, el mantenimiento de Bastion Hosts y los costos de gateways. A la vez, mejora radicalmente la postura de seguridad de nuestras aplicaciones al eliminar el uso de puertos de administración expuestos a la internet.

¿Ya utilizas SSM y Endpoints de VPC en tu organización para administrar tu infraestructura de manera unificada, o sigues utilizando VPNs tradicionales o Jumpboxes? Cuéntamelo en los comentarios.

En el próximo post, veremos otro uso de los vpc endpoints y reutilizaremos los componentes que hemos desplegado en este post. Importante recordar que los vpc endpoints y las instancias tienen un costo por hora por lo que si ya no los requieres, debes eliminar los recursos.

Gracias por leer.

Referencias:

Control centralizado de S3 Block Public Access a nivel organizacional (en español sencillo)

Pablo Gonzalez Robles — Sun, 21 Dec 2025 18:00:52 +0000

¡Hola comunidad! 👋
Quiero compartirles una nueva funcionalidad de seguridad en AWS que me parece interesante pero he visto que se ha mencionado muy poco en las redes: El bloqueo público de los buckets de S3 desde AWS Organizations. Si quieres leer el anuncio oficial de esta funcionalidad, puedes verla aquí: https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-block-public-access-organization-level-enforcement/

¿Por qué me llamó la atención esto?

La razón principal es simple: control centralizado desde la cuenta administradora de la organización.

La vieja solución

Antes (todavía el presente para muchos) teníamos básicamente dos opciones para asegurar que los objetos de los buckets no se expusieran públicamente:
Opción 1: Bloqueo a nivel de cuenta
Tenías que ir cuenta por cuenta dentro de tu organización, activando manualmente (o con scripts) el Block Public Access en cada una. Esto significa:

Configuración repetitiva en múltiples cuentas
Mayor probabilidad de error humano
Necesidad de monitorear cada cuenta individualmente
Complejidad al escalar

Opción 2: Bloqueo a nivel de bucket
Aún peor. Esto implicaba configurar cada bucket individual con Block Public Access activado:

Trabajo manual exhaustivo
Imposible de escalar en organizaciones grandes
Fácil olvidar un bucket nuevo
Pesadilla operativa para auditorías

Ambas opciones requerían vigilancia constante y eran propensas a errores.

La nueva solución

Política a nivel organizacional.
¿Qué significa esto en la práctica?
Con un control preventivo habilitado en la cuenta de gestión de tu organización, obtienes:
✅ Control centralizado: Todo se gestiona desde un solo lugar
✅ Aplicación automática: Se aplica a todas las cuentas de la organización
✅ Menos vigilancia: Ya no necesitas monitorear cada cuenta o cada bucket

Es elegante, es simple, es efectivo.

Cómo se implementa

Primero, necesitas activar las S3 policies, para ello debes ejecutar el comando:

aws organizations enable-policy-type --root-id r-1234 --policy-type S3_POLICY

Referencia: https://docs.aws.amazon.com/cli/latest/reference/organizations/enable-policy-type.html

Luego de activarla, podrás ver algo como lo de abajo en la consola:

{
"PolicyTypes": [
            {
                "Type": "S3_POLICY",
                "Status": "ENABLED"
            }
]
}

En la consola, podrás ver lo siguiente:

Esto significa que ya puedes crear la política pero no significa que ya queda el bloqueo habilitado.

Para probar esto, creé un sitio web que es alojado en s3. Quité el bloqueo público a nivel de bucket, a nivel de cuenta y configuré una política de recurso muy permisiva en el bucket para así poder ver el sitio web desde el internet.

Luego que ya tenemos cómo validar si la política está funcionado, ahora la desplegamos usando infraestructura como código (incluso para las políticas), y quedaría así:

Ya luego de tener la política activada para toda la organización, recibo el siguiente error en el sitio web lo que confirma que el bloqueo público ya quedó habilitado.

Demo

Acabo de publicar la plantilla de despliegue de la política de S3 usando cloudoformation en mi GitHub: https://github.com/pangoro24/aws-cloudformation-bpa-org

Para cerrar

Esta implementación es perfecta si:

Gestionas múltiples cuentas de AWS en una organización
Quieres reforzar la seguridad sin aumentar la carga operativa
Buscas cumplir con políticas de seguridad de manera escalable
Prefieres la prevención sobre la detección

Sugerencia adicional: Si ya habías activado el bloqueo público a nivel de cuenta, manténla y así tendrás una capa adicional de seguridad (defense in depth)

¿Preguntas? ¿Sugerencias? ¡Los leo en los comentarios! 💬

Tags: #aws #cloudformation #security #devops #s3 #organizations

☁️ Acerca del autor

Pablo González Robles
Especialista en seguridad en la nube con más de 5 años de experiencia y 4 certificaciones de AWS. Escribo sobre AWS, Ciberseguridad y Automatización. Compartiendo estrategias para la gestión y remediación de vulnerabilidades en AWS.
Podemos conectar a través de: LinkedIn

CloudFormation Hooks: Lambda hooks con anotaciones granulares (en español sencillo)

Pablo Gonzalez Robles — Mon, 17 Nov 2025 16:25:08 +0000

CloudFormation Hooks recibe una gran mejora: anotaciones granulares e información más rica por validación

Hace unos meses publiqué un artículo introductorio sobre CloudFormation Hooks y cómo utilizarlos para habilitar validación proactiva en nuestras plantillas. Si no lo has leído, puedes encontrarlo aquí:

Introducción a CloudFormation Hooks: Validación proactiva para una nube segura
https://dev.to/pangoro24/introduccion-a-cloudformation-hooks-validacion-proactiva-para-una-nube-segura-340f

Hoy quiero compartir una actualización importante: AWS ha lanzado una mejora significativa relacionada a cómo los hooks pueden entregar información de validación, permitiéndonos crear anotaciones más claras, más completas y mucho más útiles para el usuario final.

AWS explica la novedad aquí:
https://aws.amazon.com/es/about-aws/whats-new/2025/11/aws-cloudformation-hooks-granular-invocation-details/

Y ya actualicé el demo en este nuevo repositorio:
https://github.com/pangoro24/aws-cloudformation-hooks (para poder dejar el de la sesión del community day tal como se explicó en su día)

Qué problema resuelve esta actualización

Antes de esta mejora, los hooks solo permitían un campo único llamado message para comunicar hallazgos. Esto generaba varios problemas en escenarios reales:

• Si el hook evaluaba múltiples reglas, todo debía colocarse en un solo texto.
• Para mantener claridad, la mayoría terminábamos usando paréntesis, listas improvisadas o pseudo-JSON, que funcionaban… pero no eran agradables ni consistentes.
• Desde la consola, el usuario veía un bloque de texto poco formateado, a veces difícil de leer.

Esto no solo afectaba la experiencia del desarrollador, sino también la claridad operativa y la capacidad de remediación.

Qué cambia con las nuevas anotaciones granulares

Ahora CloudFormation Hooks permite incluir anotaciones específicas por cada validación, con campos separados y claramente presentados en la consola, incluyendo:

• severity – nivel de criticidad
• status – resultado de la evaluación de la lógica
• status message – explicación más detallada que deseamos agregar
• remediation message – qué debe hacer el usuario
• remediation link – enlace directo a documentación o guías internas
• Y la posibilidad de ver todo esto desde el Invocation history (si no sabías que existe el invocation history, el detalle acá: https://aws.amazon.com/about-aws/whats-new/2025/09/cloudformation-hooks-managed-controls-summary/

Un ejemplo práctico

Imagina que definiste un hook para validar un recurso AWS::S3::Bucket con 3 reglas:

Que tenga Block Public Access habilitado
Que tenga versionamiento
Que tenga un ciclo de vida para los objetos

Con este nuevo modelo puedes elegir:

• Generar una anotación por cada validación, claramente independiente
• Generar anotaciones solo para las validaciones que fallaron

El usuario final verá cada anotación como un elemento independiente dentro del Invocation history. Nada de paredes de texto, nada de interpretar formatos improvisados.

Es una mejora real en cuanto a experiencia, claridad y gobernanza.

Cómo lo vemos desde la consola

Acá te muestro el antes y después de los mensajes de los hooks:
Antes: sin anotaciones

Ahora: con anotaciones

Conclusión

Esta mejora convierte a CloudFormation Hooks en una herramienta más madura para validación proactiva, gobernanza, seguridad y experiencia de desarrollador.
Ahora no solo podemos detectar malas configuraciones, sino también comunicar de manera clara qué se debe corregir y por qué.

☁️ Acerca del autor

Servicios de AWS que un Cloud Security Engineer debe dominar, aunque NO sean "servicios de seguridad" per se

Pablo Gonzalez Robles — Tue, 11 Nov 2025 23:14:01 +0000

Cuando pensamos en seguridad en AWS, el brainstorming siempre cae en el "típico combo": IAM, AWS WAF, KMS, quizá Security Hub. Sus íconos en color rojo ya los definen como servicios de seguridad per se.

Pero si llevas un tiempo como Cloud Security Engineer en AWS, sabes que la seguridad real involucra varios servicios aparte de los mencionados.

Aquí les dejo mi top 6 de servicios "no-seguridad" que considero importante conocer más para mejorar la postura de seguridad:

1️⃣ Amazon VPC: Donde Empieza el Juego de la Defensa
La seguridad empieza por casa, y en la nube, tu casa es la VPC. Si las redes no están bien diseñadas desde el inicio, puede ser un reto garantizar su seguridad. Dedica tiempo a entender cómo se estructuran las VPCs en cada cuenta. Servicios como Transit Gateway, túneles VPN y Security Groups forman parte de la base para una red segura y funcional.

2️⃣ AWS Config: El Detective de la Gobernanza
La gobernanza y el cumplimiento (compliance) son la forma de dormir tranquilo. Config avisa qué recursos están fuera de la línea y no cumplen con nuestras políticas establecidas (ej. ese bucket de S3 abierto al mundo). Lo bueno es integrarlo con otros servicios para no solo detectar, sino también automatizar acciones correctivas. ¡Menos trabajo manual!

3️⃣ AWS Systems Manager (SSM): El Navaja Suiza para el Ops Seguro
Tiene varias funcionalidades pero las que más me interesan a nivel des seguridad son:
SSM Documents: Usa las automatizaciones de SSM para implementar controles correctivos, normalmente sobre recursos en incumplimiento detectadas por las reglas de Config. ¿Detectaste algo mal? Un runbook de SSM se ejecuta y listo, recurso corregido.
Patch Manager: ¡Adiós a los dolores de cabeza con los parches! Te ayuda a gestionar las actualizaciones de forma eficiente y a escala.

4️⃣ AWS Organizations: Pon Orden en el Caos de Cuentas
Un entorno bien organizado es un entorno más seguro (y menos complejo). Una buena estructura de cuentas con Organizational Units (OUs) es la clave para la gobernanza centralizada.
Así puedes aplicar controles preventivos como: SCPs (Service Control Policies), Backup Policies, o las nuevas Resource Control Policies (RCPs) y declarative policies.

5️⃣ AWS Control Tower: El Acelerador de Seguridad Out-of-the-Box
Para los que montan entornos desde cero y no quieren reinventar la rueda de seguridad, Control Tower es el camino. Te monta una línea base de seguridad sólida, activa controles automáticos sobre las OUs y te da ese punto de cumplimiento inmediato. Te ahorras un montón de tiempo en validaciones manuales y tienes una gran cantidad de controles que son mantenidos por AWS directamente y solo tenemos que activarlos en las OUs de interés.

6️⃣ AWS CloudFormation: El Código que es Nuestro Control
La Infraestructura como Código (IaC) es ley. No solo te da consistencia en los despliegues, sino que es el punto clave para realizar validaciones a través de controles proactivos. Con los CloudFormation Hooks, podemos introducir validaciones específicas antes de que el recurso se cree. Es la forma controlada de gestionar excepciones y asegurar que solo se despliegue lo que es seguro por diseño.

🌟 Si alguien considera otro servicio que no es de seguridad y que les aporta mucho, me escriben en los comentarios porque tal vez me lo estoy perdiendo 😅

☁️ Acerca del autor

Defensa por Capas: Seguridad INTEGRAL en la nube de AWS 🔐

Pablo Gonzalez Robles — Sat, 11 Oct 2025 16:30:35 +0000

La Defensa por Capas (Defense in Depth, en inglés) es una estrategia que organiza la seguridad en múltiples niveles, protegiendo los activos desde el núcleo hasta el perímetro.

Cada capa cumple un rol esencial, pero —desde mi experiencia— la última tiene el mayor impacto 😎.

Durante este año he dedicado bastante tiempo a revisar el Cloud Adoption Framework (CAF) y quiero compartir un resumen práctico de cada capa junto con algunos servicios clave de AWS que pueden ayudarte a fortalecer tu postura de seguridad.

1️⃣ Protección de Datos

Protege tu activo más valioso: los datos.

Servicios recomendados:

Amazon Macie: Detecta y protege información confidencial.
AWS KMS: Garantiza la integridad y el cifrado de datos.
AWS Backup: Asegura la disponibilidad mediante copias automáticas y centralizadas.

2️⃣ Protección de Aplicaciones

Asegura tus aplicaciones frente a ataques web.

Servicios recomendados:

AWS WAF: Protege contra exploits comunes y vulnerabilidades OWASP.
AWS Shield: Defiende de ataques DDoS tanto a nivel estándar como avanzado.

3️⃣ Protección de Infraestructura

Fortalece servidores, configuraciones y sistemas.

Servicios recomendados:

AWS Config: Supervisa y evalúa la conformidad de tus configuraciones.
AWS Systems Manager: Automatiza el parchado y la aplicación de políticas de configuración.

4️⃣ Detección de Amenazas y Respuesta a Incidentes

Detecta, analiza y responde ante posibles amenazas.

Servicios recomendados:

Amazon GuardDuty: Identifica comportamientos maliciosos y actividades inusuales.
AWS CloudTrail: Registra y audita las acciones realizadas en tu entorno AWS.

5️⃣ Gestión de Identidad y Acceso

Controla quién accede y qué puede hacer dentro de tu entorno.

Servicios recomendados:

AWS IAM: Administra permisos y políticas a nivel de cuenta.
AWS IAM Identity Center (antes SSO): Centraliza la gestión de identidades y accesos a nivel organizacional.

6️⃣ Protección de Red y Perímetro

Asegura tanto el tráfico interno como el acceso externo.

Servicios recomendados:

Amazon VPC: Define redes seguras y segmentadas.
Amazon Route 53: Gestiona la resolución de nombres de dominio internos y públicos.

7️⃣ Políticas, Procedimientos y Concienciación

La capa más importante: las personas.

Sin un equipo consciente y capacitado, la tecnología por sí sola no basta.

Fomenta la cultura de seguridad, la formación continua y la responsabilidad compartida.

💡 Conclusión

Una estrategia de defensa por capas efectiva no se trata solo de herramientas, sino de equilibrar tecnología, procesos y personas.

Combinar una infraestructura sólida con un equipo preparado es lo que realmente construye una seguridad integral en la nube.

👉 Si estás aprendiendo sobre seguridad en AWS, te animo a seguir explorando, practicando y certificándote. Cada paso te acerca más a dominar la nube con confianza 💪☁️

☁️ Acerca del autor

Lecciones aprendidas de la certificación AWS Security Specialty 🥇

Pablo Gonzalez Robles — Sun, 05 Oct 2025 17:48:15 +0000

Hola comunidad,

Hace un tiempo logré la certificación de especialidad en seguridad de AWS y quiero compartir algunas lecciones que, espero, les sean útiles a quienes estén pensando en presentar este examen.

1. No necesitas ser un experto absoluto. Este examen busca validar tu capacidad para usar los servicios, pero no exige que seas especialista en todos ellos. Es cierto que trabajar con los servicios en el día a día o hacer demos ayuda mucho, pero incluso quienes usamos AWS de manera constante rara vez conocemos todas las funcionalidades de un servicio o lo aplicamos en todos los escenarios posibles. Igual tendrás que seguir practicando y estudiando. Si sabes qué hace cada servicio y cómo configurarlo en los casos de uso más comunes, ya tienes una buena base para aprobar.

2. Comprende las integraciones. Un servicio de seguridad que simplemente está habilitado aporta poco o nada de valor por sí solo. Los hallazgos deben recopilarse, filtrarse, procesarse y llegar a quienes puedan actuar sobre ellos, ya sea para estar informados o como parte de otro proceso. La guía oficial lo dice claramente: las integraciones con servicios nativos de AWS (y también de terceros) son clave. Si entiendes cómo integrarlos, estás en el camino correcto.

3. Toma notas mientras te preparas. Más allá de aprobar o no, lo más valioso de cualquier certificación es el proceso de aprendizaje. Tomar notas te servirá para reforzar conocimientos si necesitas volver a intentarlo y, lo más importante, te quedarán como referencia práctica cuando debas implementar esos servicios en tu organización.

4. Practica con exámenes de prueba, pero no te obsesiones. Muchos recomiendan alcanzar cierto porcentaje en los simulacros antes de presentar el examen oficial. En mi caso, nunca terminé uno completo. Lo que hacía era comenzar un examen de práctica y, después de 10 o 20 preguntas, me detenía a analizar tanto las respuestas correctas como las incorrectas. Ese ejercicio me permitió identificar los temas en los que necesitaba profundizar y también entender por qué algunas opciones nunca serían viables, más allá de que la “correcta” fuera otra.

Al final, muchas personas postergan el examen porque sienten que no están listas (a mí también me pasó). Pero el momento ideal es cuando te das cuenta de que, si alguien te pide ayuda con un servicio de seguridad en AWS, puedes responder:
"Sí, lo conozco, sé cómo usarlo, entiendo por qué es la mejor opción en este escenario y, revisando mis notas y la documentación, puedo ayudarte a configurarlo correctamente y resolver tu problema."

Ojalá este post les ayude a animarse a dar ese paso. Confíen en su preparación y dense la oportunidad: el examen puede parecer desafiante, pero con constancia y práctica, es totalmente alcanzable.

☁️ Acerca del autor

Parametrizaciones inteligentes y auditables usando Cloudformation Custom Resources (en español sencillo)

Pablo Gonzalez Robles — Sat, 30 Aug 2025 01:12:40 +0000

Hola comunidad,

¿Alguna vez te has encontrado con la necesidad de automatizar configuraciones de AWS que CloudFormation no maneja nativamente? Por ejemplo, necesitaba habilitar S3 Block Public Access a nivel de cuenta usando CloudFormation, pero resulta que no existe un tipo de recurso nativo para esto.

¿Entonces qué nos queda por hacer? Ahí es donde entran las Custom Resources de CloudFormation.

En este post les voy a compartir cómo se estructuran los custom resources en cloudformation, y adicional, cómo Kiro me ayudó a estructurar todo el proyecto usando spec-driven development.

En este post estaré cubriendo:

Qué son los Custom Resources y cuándo usarlos
Desarrollo del componente usando spec-driven development
Implementación práctica del custom resource para S3 BPA
Código real y capturas del funcionamiento

¿Qué son las Custom Resources en CloudFormation?

Las Custom Resources son básicamente una forma de extender CloudFormation cuando necesitas hacer algo que los tipos de recursos nativos no pueden manejar, como lógica o parametrizaciones en los servicios, que no es realmente el despliegue de un recurso. Funcionan mediante una función Lambda que CloudFormation invoca durante las operaciones de CREATE, UPDATE y DELETE del stack (si así lo deseamos aunque puedes elegir solo una o dos acciones). Acá puedes leer la documentación oficial de AWS: https://docs.aws.amazon.com/es_es/AWSCloudFormation/latest/TemplateReference/aws-resource-cloudformation-customresource.html

En mi caso específico, necesitaba:

Consultar y habilitar el Bloqueo de Acceso Público (Block Public Access - BPA) a nivel de cuenta en el servicio de S3
Enviar una notificación del cambio ejecutado

Desarrollo guiado a través de especificaciones (Spec-driven development)

Aquí es donde Kiro (https://kiro.dev/) realmente brilló. En lugar de pedirme un prompt para ponerse directamente a escribir el código de python y la plantilla de cloudformation, me guió a través de un proceso estructurado que nunca había usado antes con los agentes de inteligencia aritificial. Antes, yo ño más que hacía era crearme un archivo .txt o .md donde listaba los requisitos y le decía al agente que se guiara de ese documento para desarrollar el proyecto pero en la mayoría de los casos, tocaba hacer mucho refinamiento lo cual consume tiempo y especialmente, requests/tokens que pueden llegar a costar dinero.

Nota: Te dejo por acá el post donde compartí mi primera experiencia usando Kiro: https://dev.to/pangoro24/mi-experiencia-con-kiro-59k7.

Para este caso específico y siguiendo el spec-driven development, el proyecto se trabaja de la siguiente manera:

Paso 1: Definición de requerimientos

Kiro me ayudó a estructurar los requerimientos de manera clara:

Habilitar S3 Block Public Access a nivel de cuenta
Manejar operaciones CREATE, UPDATE y DELETE
Enviar notificaciones opcionales via SNS
Implementar manejo de errores robusto

Paso 2: Diseño de la implementación

Luego trabajamos en el diseño técnico:

Custom Resource que invoca una función Lambda
Función Lambda con lógica para consultar y aplicar configuraciones
Plantilla CloudFormation con todos los recursos necesarios
Pruebas unitarias para validar la lógica

Paso 3: Ejecución de las tareas

Finalmente, Kiro me ayudó a implementar cada componente paso a paso, siempre validando que el código funcionara antes de continuar.

¿Cómo funciona el Custom Resource?

El flujo es bastante directo:

Despliegue: CloudFormation crea el stack e invoca la función Lambda con el evento CREATE
Evaluación: La Lambda consulta la configuración actual de S3 BPA usando boto3
Aplicación: Si BPA no está habilitado, la función lo configura automáticamente
Notificación: Desde la lambda se envía un mensaje SNS con el resultado de la ejecución
Respuesta: La Lambda responde a CloudFormation con SUCCESS o FAILED

Implementación práctica

Es cierto que, con un solo prompt bien definido, la mayoría de los modelos de inteligencia artificial habrían generado la plantilla y el código necesarios, por lo que usar aquí la metodología de desarrollo dirigido por especificaciones podría parecer "over-engineering". Sin embargo, al ser mi primer proyecto desde cero con Kiro, quise probarlo primero en un demo sencillo antes de avanzar hacia algo más complejo.

¿Dónde puedo ver el código completo?

He subido la implementación completa a GitHub, incluyendo:

Plantilla de CloudFormation completa
Código de la función Lambda con tests
Resumen del proyecto
Documentos refinados para el desarrollo guiado por especificaciones para este proyecto (requirements.md, design.md, tasks.md)

Repositorio: https://github.com/pangoro24/aws-cloudformation-custom-resource-bpa-account/

Conclusión

Los Custom Resources son una herramienta poderosa cuando necesitas extender CloudFormation más allá de sus capacidades nativas y cuando los cambios en la cuenta deben realizarse por infraestructura como código.
Por otro lado, usar spec-driven development con Kiro realmente cambió mi forma de abordar proyectos y voy a probar en un proyecto más complejo la próxima vez.

¿Has usado Custom Resources en tus proyectos? ¿Te gustaría que profundice en algún aspecto específico o que cubra otros casos de uso? Déjamelo saber en los comentarios.

Gracias por leer.

☁️ Acerca del autor

Mi experiencia con Kiro (en español sencillo)

Pablo Gonzalez Robles — Tue, 26 Aug 2025 04:42:21 +0000

Hola comunidad,

Hace unas semanas recibí la licencia para poder usar Kiro y como siempre ando buscando herramientas que me ayuden a ser más productivo (y que no me cuesten una fortuna), pensé que valía la pena darle una oportunidad ya que viniendo de AWS pensaría que sería un buen editor para alguien que trabaja a full en proyectos en la nube de AWS.

Después de usarlo por un par de días trabajando en 2 proyectos, quería compartir mi experiencia REAL con ustedes.

En este post les voy a contar:

Qué es Kiro y cómo puedes acceder a este editor
Lo bueno, lo malo y lo que está en el medio
Consejos si deciden probarlo

¿Qué es Kiro?

Kiro es básicamente un editor como visual studio code con asistente de IA integrado que te ayuda con tareas de codificación y que fue desarrollado por el equipo de AWS. A la fecha, para acceder debes anotarte en una lista de espera. Acá el link al proyecto: https://kiro.dev/

Lo que me gustó

Tiene capa gratuita

El tier gratuito viene con una cantidad decente de requests. No es ilimitado, pero para proyectos personales y pruebas está bastante bien. Obviamente hay que ser estratégico con cómo lo usas, pero no me sentí limitado al principio. En el free tier, obtienes un bonus de 100 requests tipo vibe y 100 requests tipo spec y luego recibes 50 vibe requests mensualmente. El detalle del tipo de sesiones y requests está acá: https://kiro.dev/docs/chat/vibe/

Claude 4.0 como motor en el free tier

Esto fue un game changer para mí. Las respuestas son coherentes y el código que genera generalmente funciona.

Asistencia para arrancar el proyecto usando Spec driven development

En el mundo empresarial real, así es que se desarrollan los proyectos. No arrancas a escribir código sin tener claro los requisitos y este IDE ya viene con un modo nativo en el cual te ayuda a estructurar tu proyecto de esta manera.

Lo que no me gustó tanto

Hay que ser muy específico con los requests

Aquí aprendí por las malas. Si no eres súper específico con lo que quieres, Kiro tiende a generar más código y archivos complementarios del necesario. Y como cada request cuenta para tu límite, esto se vuelve un problema si el objetivo es crear un proyecto grande y complejo.

Por ejemplo, si le pides "ayúdame con esta función que haga tal cosa" y no le dices que sea minimalista, se pone a crear un archivo de clases, otro archivo de utils, y luego pruebas para todo eso, cuando yo sé que la funcionalidad era tan sencilla que no requiere tanta ingeniería. Claro, él está asumiendo que esto es un mega proyecto empresarial y que vas a crear docenas de funciones lambda que deben reutilizar código y debe estandarizar pero si no lo necesitas, pues debes avisarle antes de que empiece a crear cosas.

Se pasa de la raya con los requerimientos

Parecido al punto anterior, empezó a buscarle la quinta pata al gato y terminó armando una larga lista de requerimientos (historias de usuario). Para simplificar el proyecto decidí eliminar varios de ellos y tuve que aclararle que no los volviera a incluir, porque cada vez que añadía un requerimiento nuevo, reaparecían varios de los que ya había quitado. Al final, uno de los requerimientos terminó siendo justamente que no me agregara esos "otros requerimientos" que realmente no necesito.

Requiere ajustes manuales

Rara vez el código funciona al 100% en el primer intento o que siga una estructura agradable al ojo humano que es muy necesario para el futuro mantenimiento del proyecto. Desde la perspectiva de la IA, eso puede verse como algo negativo; pero desde el lado humano y profesional es positivo, porque demuestra que sin conocimientos técnicos, la IA por sí sola no es suficiente. Al menos por ahora, nuestro trabajo sigue siendo necesario.

Consume muchos requests

Este fue mi mayor dolor de cabeza. Si no tienes cuidado, puedes quemar tu cuota mensual en unos pocos días. Cada consulta cuenta, y cuando estás en modo "debugging intensivo", los requests se van volando. Recomiendo hacer una prueba con un proyecto super simple para entender cómo funcionan las sesiones, ir revisando el consumo de requests y trabajar bajo el marco del spec-driven development antes de iniciar con un proyecto más grande que luego tengas que pagar de manera prematura el modo pro.

Velocidad

El agente no es el más rápido del mundo pero no es lento al punto de ser frustrante. Obvimente escribe código más rápido que yo y me permite enfocarme en orquestar los requerimientos del proyecto y resolver los problemas técnicos o de forma donde se estanca la IA.

Consejos en base a mi experiencia como usuario

Sean específicos: Mientras más detallado sea su request, mejor será el resultado, menos iteraciones necesitarán, más rápido terminará las tareas y menos requests de refinamiento necesitarán.
Usen el contexto: Kiro puede leer archivos de su proyecto. Aprovéchenlo para que entienda mejor lo que están solicitando. Pueden referenciar a otros archivos de sus proyectos previos para seguir un estándar en específico que ustedes desean que se aplique en el nuevo proyecto.
Revisen todo: Nunca asuman que el código generado está perfecto. Siempre hay algo que ajustar y probar antes de decir: terminé.
Gestionen sus requests: Mantengan un ojo en cuántos requests les quedan. Lo pueden ver desde el ícono de su perfil (esquina inferior izquierda).
Úsenlo para aprender: Una de las mejores cosas es aprender esta nueva metodología de usar estos agentes de IA. Yo antes solo generaba un archivo markdown con las funcionalidades y algunos requesitos no funcionales pero la forma en la que lo sugiere Kiro, me pareció algo más estructurado.

Lo que falta

La documentación podría ser mejor. Tuve que descubrir varias cosas por ensayo y error porque tampoco es que hay muchos posts, tutoriales o vídeos (y en español mucho más escaso).

Sería genial ver más ejemplos de uso real y recomendaciones de otros usuarios.

Conclusión

Kiro es una herramienta útil si sabes cómo usarla y entiendes sus limitaciones.

¿Lo recomiendo? Sí, especialmente si pueden aprovecharlo ahora que el tier gratuito es muy generoso. Solo no esperen magia - sigue siendo una herramienta que requiere un desarrollador que sepa qué está haciendo y necesitando.

¿Han probado Kiro y tiene alguna experiencia o consejo que compartir? Me encantaría escuchar sus historias en los comentarios, especialmente si han encontrado formas creativas de maximizar el tier gratuito.

Gracias por leer.

☁️ Acerca del autor

Remediación Automática con AWS Config y Systems Manager: Seguridad Proactiva en la Nube (en español sencillo)

Pablo Gonzalez Robles — Tue, 19 Aug 2025 15:44:12 +0000

Hola comunidad,

¿Alguna vez te has despertado un día con un email o reporte del securityHub diciendo que hay x cantidad de buckets de S3 mal configurados que necesitan atención inmediata? En caso de que te permitan realizar remediaciones automáticas, este post es para ti. En este post les compartiré un sistema de remediación automática que combina AWS Config con Systems Manager (SSM) Automation.

En este post estaré cubriendo:

Qué es la remediación automática y por qué es importante
Componentes principales y arquictura de la solución
Demo con capturas reales del funcionamiento (y link al repo)
Próximos pasos y conclusiones

¿Qué es la remediación automática?

La remediación automática es un proceso que detecta configuraciones que no cumplen con los lineamientos establecidos y corrige automáticamente, sin intervención manual.

En lugar de solo alertar sobre problemas de configuración, el sistema los identifica y aplica las correcciones necesarias de forma inmediata. Esto representa un cambio de enfoque: de reactivo (detectar y alertar) a proactivo (detectar y corregir).

Arquitectura de la solución

La solución implementa tres componentes principales de AWS que trabajan en conjunto:

AWS Config - el detective

Monitorea continuamente la configuración de los recursos y ejecuta evaluaciones de cumplimiento. Utiliza una regla administrada por AWS o personalizada respaldada por Lambda.

AWS Lambda - el analista

Ejecuta la lógica de evaluación personalizada. La función analiza los recursos de interés, verifica su configuración de seguridad, y reporta el estado de cumplimiento (COMPLIANT/NON_COMPLIANT) a AWS Config.

AWS Systems Manager Automation - el reparador

Ejecuta las acciones de remediación cuando Config identifica recursos no conformes. Utiliza documentos de automatización que contienen los pasos específicos, como playbooks, para aplicar las configuraciones de seguridad requeridas.

¿Cómo funciona el flujo completo?

El proceso de remediación automática con una regla de Config períodica para evaluar y remediar buckets que no tiene configurado el bloqueo de acceso público sigue estos pasos:

Detección: AWS Config ejecuta la regla personalizada cada cierta cantidad de cantidad horas, dependiendo la parametrización que definamos.
Evaluación: La función Lambda recibe la lista de buckets y evalúa cada uno, verificando si tiene configurado el bloqueo de acceso público.
Reporte: Lambda reporta el estado de cumplimiento de cada recurso a AWS Config, marcándolos como COMPLIANT o NON_COMPLIANT.
Activación: Config identifica los recursos no conformes y activa el proceso de remediación automática. Esto puede tomar un par de segundos.
Remediación: Systems Manager Automation ejecuta el documento que aplica las configuraciones de bloqueo de acceso público al bucket.
Verificación: Config vuelve a evaluar el recurso, acorde a su periodicidad definida, para confirmar que ahora cumple con la política establecida y marcarlo como OMPLIANT.

Capturas del Demo

Nada mejor que ver el sistema en acción. Te voy a mostrar exactamente lo que pasa cuando alguien (digamos, un desarrollador con prisa y en ese momento no había un control prevenentivo) crea un bucket sin las configuraciones de seguridad:

Escenario: Creamos un bucket S3 sin configuración de bloqueo de acceso público.

Estado Inicial - Bucket No Conforme

AWS Config detecta esta configuración insegura de bucket y marca el recurso como NON_COMPLIANT.

Estado Intermedio - Bucket Corregido

AWS Config activa automáticamente la remediación configurada. En la consola se puede observar el progreso de la ejecución del documento de Systems Manager en tiempo real.
Después de la remediación automática, el bucket tiene correctamente configurado el bloqueo de acceso público. El recurso cambió de NON_COMPLIANT a COMPLIANT sin intervención manual.

Estado Final - Bucket marcado como Conforme

En la próxima evaluación de la regla, el recurso que ya cumple con el lineamiento, es marcado como en cumplimiento. Este estado debe preservarse de allí en adelante siempre y cuando tengamos un control preventivo que evite que este tipo de configuraciones vuelvan a aplicarse o que alguien lo ajuste por consola.

Nota importante - Gastos relacionados:

Para la implementación de esta solución, AWS Config debe estar habilitado en su cuenta. Para optimizar los costos, puede utilizar reglas periódicas que se activan cada cierto número de horas. De esta manera, no es necesario mantener el AWS Config Recorder activado continuamente, lo que puede generar gastos significativos.

Si la necesidad es mantener un cumplimiento continuo, se requiere que el Recorder esté encendido. Este grabará cada cambio en los recursos, permitiendo configurar reglas de Config para que evalúen cada recurso que reciba modificaciones.

Una estrategia para la optimización de costos es ajustar el alcance del Recorder, excluyendo tipos de recursos que no son críticos. Otra opción es modificar la periodicidad del Recorder a una evaluación diaria, lo cual captura una "instantánea" de la configuración. Sin embargo, esta opción no es aplicable a todos los tipos de recursos.

A continuación, se detallan los costos asociados en los que podría incurrir al mantener el Recorder activado.

¿Dónde puedo ver el código completo?

He subido la implementación completa a GitHub, incluyendo:

Plantilla de CloudFormation con toda la infraestructura

Repositorio: https://github.com/pangoro24/aws-public-buckets-auto-remediation

Próximos pasos

Esta implementación es solo el comienzo. Puedes extender el concepto para:

Otros recursos de AWS (EC2, RDS, ELB, etc.)
Múltiples políticas de seguridad
Integración con herramientas de notificación (sns,ses)
Métricas y dashboards personalizados

Conclusiones

La implementación de remediación automática representa un cambio significativo en la gestión de seguridad en la nube, pasando de un enfoque reactivo a uno proactivo.

La combinación de AWS Config, Lambda y Systems Manager crea un sistema robusto que no solo detecta configuraciones inseguras, sino que las corrige automáticamente, reduciendo el tiempo de exposición a riesgos y liberando recursos del equipo para tareas más estratégicas.

Si estás cansado de pasar tus días arreglando configuraciones de seguridad, dale una oportunidad a esta solución.

¿Ya tienes algo similar implementado? ¿Te gustaría que hable de otros casos de uso o que profundice en algún aspecto específico? Déjamelo saber en los comentarios - siempre me gusta escuchar experiencias de otros desarrolladores que han pasado por lo mismo.

Gracias por leer.

Referencias:

https://aws.amazon.com/es/blogs/mt/remediate-noncompliant-aws-config-rules-with-aws-systems-manager-automation-runbooks/

☁️ Acerca del autor

Introducción a CloudFormation Hooks: Validación Proactiva para una Nube Segura (en español sencillo)

Pablo Gonzalez Robles — Sun, 20 Jul 2025 18:27:08 +0000

Hola comunidad,

Hace unos días tuve la oportunidad de participar como speaker en el AWS Community Day Panamá 2025, donde presenté sobre CloudFormation Hooks. Luego de salir del evento, me puse a pensar que el contenido preparador sería bueno compartirlo al resto de la comunidad AWS de habla en español.

Si trabajas con infraestructura como código y te interesa asegurar que tus despliegues cumplan con políticas personalizadas antes de crear recursos, este artículo es para ti. En este post estaré revisando:

Qué son los CloudFormation Hooks
Diferencias entre Lambda Hooks y Guard Hooks
Cómo implementarlos
Y un demo con capturas (al final del post)

¿Qué son los CloudFormation Hooks?

Los CloudFormation Hooks permite validar las propiedades de los recursos antes de que sean creados o modificados. Esto te da la oportunidad de aprobar o rechazar de manera automatizada dichos cambios según tus propios lineamientos de seguridad.

Imagina que alguien del equipo intenta desplegar un bucket de S3 sin cifrado o sin bloquear el acceso público... Con un hook, puedes evitar que eso pase antes de que se cree el recurso.

Los hooks son un mecanismo de control preventivo, lo que significa que nos permiten aplicar seguridad desde etapas tempranas del ciclo de vida de la infraestructura —es decir, "mover la seguridad a la izquierda". Esto trae beneficios significativos para la organización, ya que al evitar que se desplieguen recursos que luego tengamos que remediar, con lo cual evitamos retrabajos y evitamos costos innecesarios.

Tipos de Hooks (2025): Lambda vs. Guard

AWS ofrece dos tipos de hooks para CloudFormation:

Lambda Hook

Este tipo de hook usa una función Lambda como backend de validación. Al ser lambda que es un tipo de recurso conocido por casi todos los que trabajamos en la nube, sabemos cómo configurarla y si necesitas realizar algún cambio, puedes ajustar fácilmente. Además puedes usar el lenguaje de programación de preferencia, puedes realizar multiples validaciones lo cual se entenderá fácilmente en tu script. Por último pero no menos importante, te puedes integrar fácilmente con otros servicios de AWS y poder extraer datos necesarios para realizar validaciones complejas. Sin embargo, debes considerar que a medida que creces con los hooks, puede que tengas que mantener docenas de lambdas y sus respectivos roles.

Guard Hook

Este tipo de hook usa el lenguaje declarativo CloudFormation Guard, pensado para escribir reglas más fácilmente y de forma más declarativa. Es ideal para validaciones sencillas como validación de nombramientos, estado de propiedades (enabled / disabled), etc

Desde mi experiencia, recomiendo comenzar directamente con los Lambda Hooks, ya que con el tiempo los lineamientos de seguridad tienden a volverse más numerosos y complejos. En esos casos, usar lenguajes como Python o JavaScript facilita mucho entender y mantener cada validación que se desea aplicar. Además, al tratarse de funciones Lambda, es posible crear pruebas unitarias de forma sencilla para validar la lógica de negocio antes de desplegar una nueva versión del hook, lo que mejora la calidad y confiabilidad del proceso.

¿Cómo funcionan los hooks?

Directamente del blog post de AWS que fue publicado no hace mucho (abril 2025)donde se valida el runtime de una función lambda, te lo explico en palabras sencillas:

Un desarrollador intenta desplegar una plantilla de CloudFormation que incluye una o varias funciones Lambda.
CloudFormation activa un Lambda Hook, que está configurado para revisar cada uno de los recurso de tipo Lambda::Function.
La lógica de evaluación corre dentro de la lambda y se realiza los llamados a otros recursos de AWS en caso de ser necesario
La función retorna el resultado de la evaluación en el campo "hookStatus". SUCCESS si el recurso cumple o FAILED si el recurso está en incumplimiento.
Si el hook responde con FAILED, se detiene el despliegue del stack. Por el contrario, CloudFormation continúa con la creación o actualización de dicho recurso.

¿Dónde puedo ver un ejemplo real?

He subido un demo completo a GitHub, con ejemplos de:

Lambda Hook que impide crear buckets de S3 sin bloqueo de acceso público
Guard Hook que impide crear buckets de S3 sin bloqueo de acceso público (a modo demostrativo ya que no es mi favorito)

Repositorio:

https://github.com/pangoro24/awsdaypa2025-sec

Capturas del Demo

Abajo te dejo algunas capturas donde podrás ver los hooks en acción.

Escenario: El bucket a desplegar no tiene la propiedad "PublicAccessBlockConfiguration" debidamente configurada, y por ende, el resultado de la evaluación es que el recurso no cumple y por ende, el stack falla su tarea de despliegue.

Por el otro lado, si el bucket tiene la propiedad "PublicAccessBlockConfiguration" debidamente configurada, el resultado de la lambda es SUCCESS y por ende, se le permite a cloudformation desplegar el recurso.

Conclusión

CloudFormation Hooks son una herramienta increíble si estás buscando aplicar control proactivo sobre tus despliegues. Dale una mirada al repositorio y empieza a experimentar.

¿Ya usaste CloudFormation Hooks en tu organización? ¿Te gustaría que hablemos más de los hooks en otro post u otro tema de seguridad en la nube de la AWS?, cuéntamelo en los comentarios.

Gracias por leer.

Referencias:

https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/lambda-hooks-create-lambda-function.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-cloudformation-lambdahook.html
https://aws.amazon.com/es/blogs/devops/validate-your-lambda-runtime-with-cloudformation-lambda-hooks/