DEV Community: Laura Bolaños

Camino a AWS Certified Developer — Associate (DVA-C03): qué cambia y por qué

Laura Bolaños — Mon, 07 Sep 2026 22:57:21 +0000

El 1 de septiembre de 2026, AWS anunció oficialmente cambios de versión en varios de sus exámenes. Entre ellos, AWS Certified Developer — Associate. En este artículo te comparto mi experiencia con la versión actual que rendí y los cambios de lo que se viene.

🎯 Hasta el 30 de noviembre de 2026 se puede rendir la versión actual DVA-C02. El registro para DVA-C03 abre el 27 de octubre de 2026, con disponibilidad general (GA) a partir del 1 de diciembre de 2026.*

Hace unos meses escribí sobre mi experiencia rindiendo el examen DVA-C02, con los temas clave que profundicé y algunos tips de estudio. AWS acaba de anunciar la actualización a DVA-C03, y me pareció importante escribir esta continuación: no para reemplazar ese artículo, sino para sumarle lo nuevo. Si estás por empezar a estudiar hoy, mi recomendación es leer ambos: la base técnica de servicios (Lambda, DynamoDB, API Gateway, Cognito, etc.) sigue totalmente vigente, y acá vas a encontrar el "qué se agrega" y el "por qué" de esta actualización.

El calendario a tener en cuenta según el anuncio:

Por qué actualizan el examen

El blog oficial de AWS Training and Certification plantea que el rol de developer ya no es solamente escribir código de aplicación. Hoy un developer usa herramientas de AI-assisted development para generar, revisar y optimizar código; integra servicios de AI administrados dentro de sus aplicaciones; y tiene que asegurar las interacciones de agentes de AI. Es decir, AI-assisted development pasa a ser una competencia central del rol, no un "extra".

Esto no significa que el examen se convierta en una certificación de AI. De hecho, el anuncio oficial aclara qué queda fuera de alcance: prompt engineering, diseño de RAG, selección de modelos de AI, Amazon SageMaker AI y diseño de frameworks de gobernanza de AI. Es decir, no van a pedirte que diseñes soluciones de AI desde cero, sino que sepas cómo un developer integra y asegura estas capacidades dentro del ciclo de vida de una aplicación en AWS.

Datos generales de la nueva versión de examen

Según el anuncio, son los mismos parámetros generales que ya conocemos de DVA-C02:

Duración: 130 minutos
Preguntas: 65 (50 puntuadas, 15 no puntuadas)
Puntaje de aprobación: 720 sobre 1000
Precio: 150 USD
Idiomas: todos los actualmente soportados, disponibles desde el lanzamiento
Modalidad: Pearson VUE (centro de examen u online proctoring)

Lo estructural: los 4 dominios se mantienen

Buena noticia para quien ya venía estudiando: los dominios y sus porcentajes no cambian:

Development with AWS Services — 30%
Security — 26%
Testing and Deployment — 22%
Troubleshooting and Optimization — 22%

Lo que cambia es el contenido dentro de cada dominio: se consolidan skills que estaban demasiado fragmentadas, y se agregan skills nuevas relacionadas a AI y a Containers.

⭐ Tip: si ya armaste tu planilla de "brechas de conocimiento" como sugería en mi artículo anterior, no la tires. Vas a poder reusar casi todo el contenido de Lambda, DynamoDB, API Gateway, Cognito, SQS/SNS, EventBridge, Step Functions, CI/CD, CloudFormation/CDK, seguridad de datos y STS. Lo que necesitás es agregar una columna nueva para lo que sigue.

Incorporación 1: una Task completa de seguridad de AI (Task 2.3)

Esta es, para mí, la adición más relevante de todo el cambio. Dentro del dominio de Security se agrega la Task 2.3 — AI security, con 5 skills nuevas:

Gestión de accesos para servicios de AI. Aplica el mismo principio de mínimo privilegio que ya se usa para Lambda o DynamoDB, pero ahora sobre quién puede invocar un modelo, un agente o una Knowledge Base. Por ejemplo, se puede restringir con una política de recursos qué rol de IAM puede ejecutar bedrock:InvokeModel sobre un modelo específico.
Controles de privacidad de datos, principalmente vía VPC endpoints (AWS PrivateLink) y la garantía de que los inputs/outputs no se usen para entrenar modelos. Este punto no es solo teórico: el servicio nunca comparte tus datos con los proveedores de modelos ni los usa para entrenar foundation models, y todas las invocaciones se mantienen dentro de la red de AWS. Para reforzar el aislamiento de red, la guía de VPC interface endpoints de Bedrock explica que se puede crear un endpoint de interfaz (AWS PrivateLink) usando nombres de servicio como com.amazonaws.region.bedrock-runtime o com.amazonaws.region.bedrock-agent-runtime, evitando así exponer el tráfico a internet.
Content filtering y protección contra prompt injection. Acá entra Amazon Bedrock Guardrails como mecanismo central. Los content filters detectan categorías de contenido dañino (odio, insultos, contenido inapropiado, violencia, mala conducta) y, dentro de esa misma categoría, un filtro específico de prompt attacks detecta jailbreaks, prompt injections y prompt leakages. Hay que entender la diferencia entre prompt injection directo (el usuario intenta manipular el prompt) e indirecto (la instrucción maliciosa viene escondida en un dato externo, como un documento o una página web, que el agente procesa sin que el usuario lo note).
Seguridad en interacciones de agentes de AI: autorización de uso de tools, aislamiento de sesión (session isolation) y flujos de aprobación humana (human-in-the-loop). Esto conecta directo con Amazon Bedrock AgentCore Identity: este servicio provee autenticación, autorización y gestión de credenciales diseñada específicamente para agentes de AI y workloads automatizados, con identidades de workload que tienen atributos especializados para habilitar capacidades específicas de agentes, manteniendo compatibilidad con patrones estándar de identidad de workload de la industria.
Protección de contenido sensible en logs de monitoreo. Amazon Bedrock permite habilitar model invocation logging hacia CloudWatch Logs o S3, pero por defecto esos logs pueden incluir el input/output completo de cada invocación. El mecanismo para proteger datos sensibles ahí es Amazon Bedrock Guardrails (vía la API ApplyGuardrail), que permite enmascarar esa información antes de que quede registrada — mismo espíritu que ya aplicabas con StreamViewType: KEYS_ONLY en DynamoDB Streams para no exponer información sensible.

⭐ Tip de estudio: si en DVA-C02 profundizaste STS, IAM trust relationships y KMS, ya tenés el 70% del razonamiento necesario para esta Task nueva. Lo que hay que sumar es el vocabulario y los mecanismos específicos de AI (Guardrails, AgentCore Identity, PrivateLink hacia Bedrock).

Incorporación 2: AI-assisted development transversal a los 4 dominios

Esto se distribuye en los cuatro dominios:

Domain 1 (Development): generación de código y revisión automatizada.
Domain 3 (Testing and Deployment): automatización de pruebas y pruebas de regresión, y soporte para workflows de CI/CD incluyendo aprobaciones automatizadas de despliegue.
Domain 4 (Troubleshooting and Optimization): análisis de errores, sugerencias de troubleshooting y recomendaciones de optimización de performance.

Un dato importante para no confundirse en el estudio: según la documentación oficial sobre el fin de soporte de los plugins IDE de Amazon Q Developer, AWS discontinuará el soporte de estos plugins el 30 de abril de 2027, y como alternativa para capacidades similares (coding agéntico, chat, soporte MCP) recomienda explorar Kiro.
Kiro es el IDE agéntico que propone spec-driven development: convierte un prompt en requerimientos, diseño de sistema y lista de tareas antes de generar código, en lugar de saltar directo a la implementación. Como developer, puede que el examen busca que entiendas el concepto de spec-driven development como enfoque de AI-assisted development.

⭐ Tip: una lectura valida es entender en qué punto del ciclo de vida de desarrollo entra cada práctica de AI-assisted development, que es como está formulada la skill en cada dominio.

Incorporación 3: Gestión de contenedores

Construcción y gestión de imágenes de contenedor con Amazon ECR.
Despliegue de aplicaciones containerizadas con Amazon ECS, Amazon EKS y AWS Fargate.

En mi artículo anterior ya mencionaba ECS/EKS dentro de "Contenedores ECS, EKS" enfocado en monitoreo y observabilidad (CloudWatch, X-Ray) ya que no se me presentaron otro tipo de preguntas. Pero la diferencia es que en la nueva versión del examen amplía el foco: no solo observar un contenedor en ejecución, sino todo el ciclo — construir la imagen, subirla a ECR, y decidir entre ECS, EKS o Fargate según el caso de uso (gestión de clúster propia vs. serverless de contenedores).

⭐ Tip de laboratorio: armá una imagen simple, subila a ECR, y desplegarla primero en ECS con Fargate y después evaluá qué cambiaría si migraras esa misma imagen a EKS. La diferencia conceptual entre "quién administra el plano de control y los nodos" es justamente lo que suelen evaluar en preguntas de este estilo.

Incorporación 4: Nuevos servicios que entran en el alcance del examen

Amazon Bedrock → el servicio administrado para trabajar con modelos fundacionales.
Amazon Bedrock AgentCore → la plataforma para construir, desplegar y operar agentes de AI de forma segura y a escala, sin gestionar infraestructura. Se compone de Runtime (entorno serverless para correr agentes), Memory (memoria de corto y largo plazo), Gateway, Identity, herramientas built-in (ejecución de código en sandbox, browser tool) y Observability (monitoreo vía CloudWatch). Para un developer, dos piezas son especialmente relevantes:
- Gateway, porque permite convertir APIs existentes (OpenAPI, Smithy) y funciones AWS Lambda en tools compatibles con el protocolo MCP (Model Context Protocol), sin tener que gestionar esa infraestructura — reutiliza directo el conocimiento de Lambda/API Gateway que ya tenés de DVA-C02.
- Identity, porque conecta directo con la Task 2.3 de seguridad que nombré más arriba.
Amazon Q → el asistente conversacional generativo para entender, construir, extender y operar aplicaciones y recursos de AWS.
Kiro → como comenté arriba, el IDE agéntico de spec-driven development.
Amazon Data Firehose → para entrega de streams de datos a destinos como S3, Redshift o servicios de terceros; relevante si tu arquitectura de eventos (la que ya veías con EventBridge y Kinesis Data Streams) necesita alimentar pipelines de AI o analítica.
AWS PrivateLink → ya mencionado en la Task de AI security, pero también entra como servicio in-scope de forma general, para conexiones privadas VPC-a-servicio sin pasar por internet.

Lo que se consolida (menos memorizar features aislados, más criterio)

Se aclara que varias skills fragmentadas se agrupan en unidades más grandes:

Área	Antes (DVA-C02)	Ahora (DVA-C03)
DynamoDB	4 skills separadas	1 skill integral
Seguridad (cifrado y datos sensibles)	13 skills en 2 tasks	7 skills en 1 task
Testing	11 skills en 2 tasks	5 skills en 1 task
Observability	8 skills	5 skills
Optimization	9 skills	6 skills

En la práctica, significa que el examen deja de preguntar detalles muy puntuales y aislados, y empieza a evaluar más el razonamiento integrado sobre un tema (por ejemplo, DynamoDB completo como una sola competencia, en vez de partir claves, índices, capacidad y TTL en preguntas separadas). Si con la guía actual DVA-C02 ya estudiaste estos temas a fondo como yo, no vas a tener que aprender contenido nuevo acá. El cambio es más de "cómo te lo preguntan".

Cómo armaría el plan de estudio hoy hasta esperar el detalle de la nueva guía de examen

Base técnica: seguí usando mi artículo de DVA-C02 como guía de los servicios core (Lambda, DynamoDB, API Gateway, Cognito, SQS/SNS, EventBridge, Step Functions, S3, CI/CD, CDK/CloudFormation, CloudWatch/X-Ray, seguridad de datos y STS). Ahí no cambió la profundidad requerida.
Sumá una capa de AI aplicada al developer: entendé conceptualmente Amazon Bedrock, AgentCore (sobre todo Gateway e Identity), Amazon Q Developer y Kiro — no como usuario experto, sino como developer que decide cuándo y cómo integrarlos, y qué controles de seguridad aplicar (Guardrails, PrivateLink, aislamiento de sesión, human-in-the-loop).
Profundizá contenedores end-to-end: ECR para las imágenes, y el criterio de decisión entre ECS, EKS y Fargate.
Repasá la guía de examen oficial completa apenas se publique (disponible cuando abra el registro, el 27 de octubre de 2026), porque ahí van a estar los task statements detallados de cada skill.
Mantené la costumbre que ya recomendaba antes: hacé laboratorios chicos de todo lo anterior y practicar muchas preguntas de examen, más que memorizar teoría aislada.

⭐ Y el mismo disclaimer que hice en el artículo anterior sigue más vigente que nunca: cuidado con usar AI para el estudio profundo de servicios sin chequear contra documentación oficial — pueden aparecer alucinaciones si se utiliza el conocimiento del modelo que uses. Contrastá contra la documentación oficial via los MCP oficiales de AWS:
"awslabs.aws-documentation-mcp-server" y "aws-knowledge-mcp-server"

Conclusión: Si estás arrancando de cero con esta certificación, te recomiendo leer primero mi artículo sobre DVA-C02 para la base de servicios, y usar este como complemento de lo nuevo que trae DVA-C03.

Fuentes

A2A en Strands: agentes remotos con routing determinístico y discovery dinámico

Laura Bolaños — Tue, 01 Sep 2026 16:20:05 +0000

Culminando la serie de artículos que trata la orquestación de multiagentes en Strands Agents, voy a explicar cómo implementar agentes remotos con A2A y algunas de sus variantes, utilizando routing determinístico y discovery dinámico de agentes. Lo ejemplifiqué con la construcción de dos casos de uso: privacy-aware-routing y multi-agent-trip-planner. Para probarlos utilicé Gemma4 + Ollama (local) y la API de Gemini, capa gratuita.

Introducción

La idea principal es experimentar con ejemplos sencillos algunas casuísticas del protocolo de comunicación A2A en tu notebook, sin necesidad de una cuenta de AWS ni de servicios como Bedrock. Strands hace de wrapper sobre el protocolo, permitiendo una comunicación fluida con agentes de IA remotos, más allá del framework o lenguaje con el que estén implementados.

🗒 Los casos de usos que elegí

Privacy aware routing: Un asistente financiero-bancario de atención al cliente (orquestador, Gemini vía API key) necesita resolver consultas que a veces incluyen datos sensibles (ej. número de cuenta, DNI, monto de la cuenta). En lugar de resolver el agente general, el orquestador detecta cuándo la consulta toca datos sensibles y delega esa parte a un agente A2A local (servidor separado, Gemma vía Ollama, corriendo en localhost).
Multi agent trip planner: Un asistente de viajes de atención al cliente donde el orquestador (Gemini vía API key) no conoce de antemano a qué agente delegar cada parte de la consulta. En su lugar, descubre en runtime tres agentes especialistas: vuelos, hoteles e itinerario. Cada uno expuesto como servidor A2A local (Gemma vía Ollama), y decide dinámicamente a cuál invocar según lo que necesita resolver.

En las secciones siguientes cubro los conceptos clave del protocolo A2A en Strands y el diseño e implementación de los casos de uso.

Conceptos Clave

➡ Protocolo A2A en Strands

A2A (Agent-to-Agent) es un protocolo abierto —no una invención de Strands ni de AWS— que define cómo agentes que corren en procesos, máquinas o incluso organizaciones distintas se descubren y comunican entre sí por HTTP/JSON-RPC.

Strands no reinventa el protocolo: lo envuelve (wraps) con una interfaz familiar, como si invocáramos a un agente normal de Strands. El desarrollador no ve protocolo: visualiza un agente. Un ejemplo sencillo:

from strands.agent.a2a_agent import A2AAgent

# Create an A2AAgent pointing to a remote A2A server
privacy_agent = A2AAgent(endpoint="http://localhost:9000")

# Invoked exactly like a local Agent — Strands' wrapper keeps
# the A2A protocol completely hidden from the caller
result = privacy_agent("I need the balance for account 1234-5678-9")

print(result.message)
# {'role': 'assistant', 'content': [{'text': 'The balance for account 1234-5678-9 is $85,400'}]}

El constructor de A2AAgent acepta varios parámetros:

Parameter	Type	Default	Description
`endpoint`	`str`	Required	Base URL of the remote A2A agent
`name`	`str`	None	Agent name (auto-populated from agent card if not provided)
`description`	`str`	None	Agent description (auto-populated from agent card if not provided)
`timeout`	`int`	300	Timeout for HTTP operations in seconds
a2a_client_factory	ClientFactory	None	Optional pre-configured A2A client factory

Dos piezas hacen posible el wrap en Strands:

A2AServer: expone cualquier Agent de Strands como servicio A2A, publicando automáticamente un agent card en /.well-known/agent-card.json → es la carta de presentación del agente (nombre, descripción, skills que ofrece).
A2AAgent: el lado cliente. Envuelve el endpoint de un agente remoto y lo invocás con la misma interfaz que un agente local.

Al igual que un Agent local, A2AAgent soporta invocación asíncrona (invoke_async) y streaming de respuestas (stream_async). En los ejemplos de este artículo, el orquestador transmite su respuesta en streaming, mientras que cada llamada A2A a un agente remoto es sincrónica (espera la respuesta completa del especialista antes de seguir).

La metadata del agente remoto es la agent card y se puede consultar explícitamente con get_agent_card():

card = await privacy_agent.get_agent_card()

print(f"Agent: {card.name}")
print(f"Description: {card.description}")
print(f"Skills: {card.skills}")

Cada skill dentro del agent card describe una capacidad puntual del agente: un identificador, una descripción en lenguaje natural, y opcionalmente ejemplos de uso. Es lo que le permite al orquestador razonar "este agente sabe buscar vuelos" sin necesidad de que el desarrollador lo codifique explícitamente. La decisión de a quién delegar se basa en hacer match entre la consulta del usuario y las skills descubiertas.

El método anterior el que después va a cobrar protagonismo real en el ejemplo multi-agent-trip-planner: ahí el orquestador no invoca un endpoint conocido de antemano, sino que consulta las agent cards de varios agentes remotos para decidir dinámicamente a cuál delegar cada tarea.

➡ A2AAgent dentro de otros patrones de orquestación en Strands

A2AAgent se puede combinar dentro de otros patrones de orquestación multiagente en Strands.

Como tool de un agente orquestador: es exactamente el enfoque que desarrollamos en la POC privacy-aware-routing — el A2AAgent se envuelve en un @tool y el agente padre lo invoca como una función más, como si fuera un subagente.
Como nodo dentro de un Graph: un A2AAgent puede integrarse como nodo remoto en un flujo de Graph, mezclando agentes locales y remotos dentro del mismo grafo de dependencias.
En Swarm: al día de hoy NO está soportado, ya que ese patrón depende de handoffs basados en tools que el protocolo A2A todavía no contempla.

Habiendo visto el lado CLIENTE, veamos ahora cómo se expone un agente para que otros puedan consumirlo vía A2A.

➡ Creando un A2A Server

Del lado servidor, exponer un agente de Strands como servicio A2A es tan simple como envolverlo con A2AServer:

from strands import Agent
from strands.multiagent.a2a import A2AServer

def create_agent(context_id: str) -> Agent:
    return Agent(
        name="Privacy Agent",
        description="Resolves queries containing sensitive customer data",
    )

a2a_server = A2AServer(agent_factory=create_agent)
a2a_server.serve()

El servidor publica automáticamente el agent card en /.well-known/agent-card.json y queda escuchando requests A2A en el puerto configurado (por default, 9000).

Un detalle de diseño importante: se recomienda pasar un agent_factory (una función que crea un agente nuevo) en lugar de una instancia única de Agent. La razón es el aislamiento por conversación: A2A identifica cada conversación con un context_id, y el servidor crea y reutiliza un agente dedicado por cada context_id, para que distintas conversaciones nunca mezclen su historial entre sí. Pasar un único Agent compartido está deprecado!

Para los casos de uso de este artículo, ese aislamiento no es el foco central: cada servidor atiende un tipo de tarea puntual, sin mantener contexto conversacional extenso.
Pero es un concepto clave a tener presente si tu agente remoto necesita recordar el hilo de una conversación a lo largo de varios turnos.

➡ Strands A2A Tool: descubrimiento dinámico

Cuando hay varios agentes remotos disponibles y no querés hardcodear el mapeo "qué tarea va a qué agente", Strands ofrece A2AClientToolProvider (parte del paquete strands-agents-tools). Le da al agente orquestador un conjunto de tools para descubrir agentes A2A y comunicarse con ellos usando lenguaje natural:

from strands import Agent
from strands_tools.a2a_client import A2AClientToolProvider

# known_agent_urls es opcional: podés pasar endpoints conocidos
# o dejar que el provider los descubra en runtime
provider = A2AClientToolProvider(
    known_agent_urls=[
        "http://localhost:9001",  # Flights Agent
        "http://localhost:9002",  # Hotels Agent
        "http://localhost:9003",  # Itinerary Agent
    ]
)

orchestrator = Agent(tools=provider.tools)
response = orchestrator("Quiero ir a Barcelona en marzo, 5 días")

El provider expone tres capacidades:

Agent Discovery: descubre automáticamente los agentes A2A disponibles y sus capacidades (leyendo sus agent cards).
Protocol Communication: envía mensajes usando el protocolo A2A estandarizado.
Natural Language Interface: el orquestador interactúa con los agentes remotos en lenguaje natural, sin que el desarrollador tenga que codear explícitamente "si la consulta es sobre vuelos, llamá a este endpoint".

Esta es la pieza central de la POC de este articulo multi-agent-trip-planner: acá el agent card deja de ser un detalle de implementación y pasa a ser el mecanismo que le permite al orquestador razonar sobre a quién delegar cada subtarea, sin que ese mapeo esté escrito en el código.

➡ Evaluaciones (Evals)

Strands cuenta con un marco oficial para realizar evaluaciones, desde resultados simples hasta el análisis de interacciones multiagente complejas.

Para evaluar los workflows usé strands-agents-evals con el mismo provider configurado en .env (Gemini) como juez via LiteLLM para mantener el proyecto sobre una sola credencial y sin cuenta de AWS. En producción la práctica estándar es usar un modelo más capaz e independiente como judge.

En ambos proyectos combiné dos tipos de evaluación, para mostrar las dos familias que ofrece el SDK:

Determinística (código puro, sin LLM): rápida y barata, ideal para CI (Continuous Integration). Verifica la decisión del orquestador inspeccionando qué herramientas invocó (su trayectoria). Es el corazón de cada patrón A2A.
LLM-as-a-judge: un modelo puntúa, con una rúbrica, cualidades más subjetivas de la respuesta final: Correctness (¿el dato coincide con la referencia?) y Faithfulness (¿se apoya en los datos de las tools y no inventa ni evade?).

La diferencia está en qué mide la capa determinística en cada patrón, porque cada uno decide algo distinto:

	privacy-aware-routing	multi-agent-trip-planner
Qué decide el orquestador	Si delega o responde directo	A quién descubre y a quién delega
Eval determinística	La tool `handle_sensitive_query` se llama solo ante datos sensibles, y NO ante consultas genéricas	El orquestador primero descubre (`a2a_list_discovered_agents`) y luego delega (`a2a_send_message`)
Evaluadores usados	`ToolCalled` + `ToolNotCalled` (custom)	`ToolCalled` (discovery y delegación)
Eval LLM-judge	Correctness + Faithfulness sobre la respuesta del agente local	Correctness + Faithfulness sobre la propuesta de viaje integrada
Problema que detecta	El modelo local inventa un saldo en lugar de usar la tool	Un especialista inventa vuelos/hoteles/atracciones en lugar de usar su tool

Descripción de la solución

📦 Un único repositorio de GitHub con los dos proyectos: github.com/reinalau/strands-a2a-patterns

El repositorio reúne dos proyectos independientes, cada uno es un caso de uso de A2A:

privacy-aware-routing - ruteo determinístico hacia un único agente remoto: el orquestador decide, según el contenido de la consulta, si responde él mismo o delega la parte sensible a un agente que corre 100% local.
multi-agent-trip-planner - descubrimiento dinámico de agentes: el orquestador no conoce de antemano a los especialistas, sino que los descubre en runtime leyendo sus agent cards y delega cada subtarea al que corresponda. A su vez cada agente tiene tools disponibles.

Ambos comparten la misma base técnica (Strands, con Gemini como orquestador y Gemma local como agente remoto) y la misma forma de ejecutarse. El siguiente setup aplica a los dos por igual. Se usan los dos modelos, Ollama local y Gemini via Apikey:

a. Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco más de 4gb) ejecutando en Docker. Para esto necesitás tener Docker Desktop instalado y corriendo; una vez levantado, los comandos de abajo crean el contenedor de Ollama y descargan el modelo.
En el caso de multi-agent-trip-planner hay tres agentes remotos que pueden recibir requests casi al mismo tiempo; si querés que esas llamadas se ejecuten en paralelo, hay que indicárselo a Ollama, cuyo comportamiento por default procesa una inferencia por vez:

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Start the Ollama server with real parallelism (3 simultaneous requests)
# docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama -e OLLAMA_NUM_PARALLEL=3  ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
# If the container has already been created and 
# is currently stopped, simply use: docker start ollama
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. API de Gemini. La API key se puede generar de manera gratuita desde aquí y utilizar al menos estos modelos (experimentá con los que te permita tu cuenta):

gemini-3.6-flash
gemini-3.5-flash-lite

El código de los 2 proyectos está en Python y la estructura se diseñó de manera que su lógica sea más explicativa; todo el detalle lo encontrás en el README.md de cada proyecto:

strands-a2a-patterns/
├── README.md                          # Overview of both use cases
│
├── privacy-aware-routing/             # Case 1: deterministic routing, single remote agent
│   ├── README.md
│   ├── requirements.txt
│   ├── .env.example
│   ├── common/                        # shared: prompts, config, logging
│   ├── remote_agent/
│   │   ├── server.py                  # A2AServer — Gemma via Ollama
│   │   └── bank_tools.py              # mock bank tools with fixed data
│   ├── orchestrator/
│   │   └── main.py                    # Gemini — A2AAgent as tool
│   ├── tests/
│   │   ├── test_routing_logic.py      # does the orchestrator delegate when it should?
│   │   └── test_a2a_integration.py    # real integration test against the running local server
│   ├── evals/
│   │   ├── eval_routing.py            # deterministic: routing decision
│   │   └── eval_response_quality.py   # LLM-judge: correctness + faithfulness
│   └── logs/
│       └── .gitkeep                    # run logs land here (gitignored)
│
└── multi-agent-trip-planner/          # Case 2: dynamic discovery, 3 remote agents
    ├── README.md
    ├── requirements.txt
    ├── .env.example
    ├── common/                        # shared: prompts, config, logging
    ├── remote_agents/
    │   ├── travel_tools.py            # mock travel tools with fixed data
    │   ├── flights_server.py          # A2AServer — Gemma via Ollama (port 9001)
    │   ├── hotels_server.py           # A2AServer — Gemma via Ollama (port 9002)
    │   └── itinerary_server.py        # A2AServer — Gemma via Ollama (port 9003)
    ├── orchestrator/
    │   └── main.py                    # Gemini — A2AClientToolProvider
    ├── tests/
    │   ├── test_discovery.py          # does the orchestrator discover before delegating?
    │   └── test_a2a_integration.py    # real integration test against the 3 running servers
    ├── evals/
    │   ├── eval_discovery.py          # deterministic: discovery + delegation decision
    │   └── eval_response_quality.py   # LLM-judge: correctness + faithfulness
    └── logs/
        └── .gitkeep                    # run logs land here (gitignored)

Ejecución Local

Una vez que tenemos el repositorio clonado y el Docker de Ollama con el modelo gemma 4 (o la API key de Gemini generada), pasamos a armar el ambiente. Los pasos son los mismos en ambos proyectos; cada uno tiene su propio requirements.txt y su .env, así que hay que pararse dentro de la carpeta del proyecto que quieras correr.

En requirements.txt (con comentarios que explican para qué se necesita cada dependencia) encontramos:

strands-agents[a2a,ollama,litellm]>=1.0.0
strands-agents-tools>=0.1.0
python-dotenv>=1.0.0
pytest>=8.0.0
pytest-asyncio>=0.23.0
strands-agents-evals>=1.2.0

Conviene instalar las dependencias en un entorno virtual, para aislarlas del resto del sistema:

python -m venv .venv
# Activar: source .venv/bin/activate (Linux/macOS)
pip install -r requirements.txt

En .env se configuran, entre otros, la API key y el modelo del orquestador (Gemini), el modelo local (Gemma vía Ollama) y el nivel de log. Alcanza con copiar el ejemplo y completar la key:

cp .env.example .env

En common/config.py está la carga y validación de esas variables (falla temprano con un mensaje si falta la API key), y en common/prompts.py los system prompts del orquestador y de cada agente remoto.

📝 Sobre cambiar de modelo: el orquestador usa LiteLLMModel, así que no está atado a Gemini: LiteLLM soporta muchos proveedores (Anthropic, OpenAI, Bedrock, etc.). Alcanza con cambiar ORCHESTRATOR_MODEL_ID en el .env por el identificador del proveedor que quieras (con su prefijo, p. ej. anthropic/…, openai/…) y setear su API key. La lista completa está en la documentación de model providers de Strands. Del mismo modo, el agente remoto no tiene por qué correr en Ollama: podés reemplazar OllamaModel por otro provider en el código del servidor (server.py / los *_server.py).

Las pruebas están en tests/ y se pueden correr una a una (recomendado! ya que puede ser algo lento localmente) o todas juntas: unitarias rápidas (deciden si el orquestador delega/descubre cuando corresponde) e integración real contra los servidores A2A (arrancan solos como subprocesos; requieren Ollama corriendo).

python -m pytest

Procedemos a ejecutar el caso real. Acá está la diferencia práctica entre los dos proyectos: cada uno corre como varios procesos independientes, uno por terminal. Primero se levantan los agentes remotos (cada A2AServer queda escuchando en su puerto) y, con todos activos, se lanza el orquestador que los descubre y les habla por la red. El orden de arranque de los servidores no importa, pero deben estar todos activos antes de correr el orquestador.

privacy-aware-routing — 2 procesos (2 terminales):

Terminal - Comando	Rol
Terminal 1: `python -m remote_agent.server`	Agente remoto local (Gemma), expone su agent card en el puerto 9000. Cuenta con tools para responder sobre datos sensibles
Terminal 2: `python -m orchestrator.main "Quiero consultar el saldo de mi cuenta 1234-5678-9"`	Orquestador (Gemini): decide si delega y arma la respuesta

multi-agent-trip-planner — 4 procesos (4 terminales):

Terminal - Comando	Rol
Terminal 1: `python -m remote_agents.flights_server`	Especialista de vuelos (Gemma), puerto 9001
Terminal 2: `python -m remote_agents.hotels_server`	Especialista de hoteles (Gemma), puerto 9002
Terminal 3: `python -m remote_agents.itinerary_server`	Especialista de itinerario (Gemma), puerto 9003
Terminal 4: `python -m orchestrator.main "Quiero ir a Barcelona en marzo, 5 dias"`	Orquestador (Gemini): descubre los 3 agentes, delega y arma la propuesta

El orquestador acepta la consulta como argumento o, si se lo llama sin argumentos, abre un chat interactivo.
Para salir de los servidores remotos: Ctrl+C en su terminal; para salir del chat interactivo: escribí exit.

Los logs de las llamadas están en logs/, separado por proceso. Contiene la data cruda que permite seguir el intercambio A2A: qué descubrió y delegó el orquestador, y qué tool ejecutó cada agente remoto (líneas TOOL CALL: ...). Permite verificar que la respuesta salió de los datos y no de una alucinación del modelo.

El resultado final se visualiza en pantalla, en streaming (token a token).

Por último, hacemos una evaluación sobre el sistema multiagente real con el concepto de "Evals". Cada proyecto trae dos scripts: uno determinístico (verifica la decisión del orquestador) y uno LLM-as-judge (puntúa la calidad de la respuesta final). Ejecutan el flujo real contra el modelo configurado, muestran los resultados en consola y guardan el reporte completo en evals/outputs/<nombre>_<timestamp>.json. (Leer más detalle arriba en Conceptos Clave)

# privacy-aware-routing
python -m evals.eval_routing
python -m evals.eval_response_quality

# multi-agent-trip-planner
python -m evals.eval_discovery
python -m evals.eval_response_quality

Conclusiones

Los dos proyectos implementan casos de uso distintos que se apoyan en la misma base exponer agentes con A2AServer, pero difieren en cómo el orquestador consume esos agentes remotos: uno con ruteo determinístico hacia un agente conocido (A2AAgent, endpoint fijo); y el otro, mediante un descubrimiento dinámico de varios especialistas (A2AClientToolProvider, que lee los agent cards en runtime).

⭐ En ambos casos de uso, la abstracción de Strands esconde la mecánica del protocolo (resolución del agent card, HTTP, JSON-RPC). Del lado del orquestador, delegar a un proceso remoto se ve casi igual que llamar a una función local.

Algunas lecciones que dejaron las ejecuciones:

El agent card es el contrato. En el caso de discovery, la calidad de las skills publicadas (nombre y descripción) es lo que le permite al orquestador rutear bien sin mapeos hardcodeados. Un agent card incompleta degrada la decisión.
Los modelos locales chicos usan tools de forma intermitente. Con gemma4:e2b-it-qat, a veces el agente responde sin llamar la tool y ahí puede inventar datos. Por eso importa (a) instruirlo en el prompt a usar siempre la tool, y (b) verificarlo: los logs TOOL CALL: ... distinguen un dato real de una alucinación.
Evaluar los agentes exige leer el campo "reasons", no solo el score. Un 0.0 puede venir de la infraestructura (un 503 del juez, un modelo dado de baja), no de una mala respuesta.
Latencia y concurrencia son decisiones de arquitectura. La inferencia local es lenta; con tres especialistas compartiendo un Ollama secuencial, las tareas se encolan. Habilitar paralelismo (OLLAMA_NUM_PARALLEL) y ajustar los timeouts del cliente A2A cambia notablemente la experiencia.

Los dos casos ejemplificados son solo algunas variantes de A2A. Strands habilita capacidades que dejo anotadas para futuras pruebas:

Agentes remotos dentro de patrones multiagente: un A2AAgent puede ser un nodo más en un Graph workflow, mezclando agentes locales y remotos en un mismo pipeline.
Interrupciones (input_required): Similar a "human-in-the-loop", un agente remoto puede pausar una tarea y esperar una aprobación antes de continuar (por ejemplo, confirmar una reserva), y reanudar exactamente donde quedó.
Persistencia de conversaciones: con un SessionManager por context_id, cada conversación puede sobrevivir al reinicio del proceso en lugar de vivir solo en memoria.
Notificaciones push y despliegue distribuido: para tareas largas y para exponer cada agente productivamente (por ejemplo, detrás de balanceadores, en AWS Fargate o vía AgentCore), escalando el sistema más allá de una notebook.
Utilizar MCP de manera complementaria: Cada especialista puede usar MCP para sus tools y A2A para colaborar con otros.

⭐ Por último, aquí construyo los agentes en Python con Strands, pero como A2A es un estándar abierto (hoy bajo la Linux Foundation) y viaja sobre HTTP/JSON-RPC, la interoperabilidad ocurre a nivel del protocolo, no del framework. Un agente Strands puede comunicarse con agentes construidos en otros frameworks y lenguajes que también implementen A2A. El protocolo tiene SDKs oficiales en Python, JavaScript, Java, C#/.NET, Go y Rust, sin que ninguno conozca la lógica interna del otro.

Recursos

Curso Fundamentos Strands
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Evals
Agent-to-Agent (A2A) Protocol
Protocolo A2A (Agent2Agent)
Sitio oficial del protocolo A2A

Workflow en Strands: un DAG de tareas ejecutado como herramienta única

Laura Bolaños — Wed, 19 Aug 2026 21:31:31 +0000

En estas notas te explico cómo orquestar agentes con la arquitectura Workflow de Strands Agents utilizando paralelismo y join points, ejemplificado con la construcción de un entregable para preparar y gestionar reuniones como Solutions Architect. Testado de dos maneras: con Gemma4 + Ollama (local) y con la API de Gemini.

Introducción

La idea principal es experimentar con el patrón de orquestación workflow sin gastar en suscripciones pagas de tokens, dejando el deploy en AWS para otra instancia. Durante el desarrollo y testing me encontré con algunos inconvenientes de features no implementadas y descubrí proveedores de modelos soportados al día de hoy.

🗒 El caso de uso que elegí para representar el patrón de orquestación Workflow es un copiloto para Solutions Architects que prepara y cierra discovery meetings con clientes: investiga la empresa, mapea a los stakeholders, genera preguntas de discovery fundamentadas en ese contexto, resume la reunión una vez ocurrida, y sintetiza todo en un entregable de seguimiento (email + próximos pasos + gaps a resolver).

La idea del diseño se sacó del playground de PartyRock de Jeff Escott

En las secciones siguientes cubro los conceptos claves del patrón, el diseño e implementación del caso de uso, los hallazgos reales de ejecución con ambos modelos, y las evaluaciones con strands-agents-evals.

Conceptos Claves

➡ Workflow de Agentes es un patrón de orquestación coordinado en una secuencia definida.

Cada Agente realiza una serie de tareas definidas. El desarrollador puede descomponer tareas complejas en componentes manejables y distribuirlos entre agentes especializados. Cada workflow tiene un control explícito del orden de ejecución de las tareas, las dependencias y el flujo de información entre tareas.

Workflow es apropiado:

Cuando se tiene un proceso complejo pero repetible que se desea encapsular en una herramienta única, confiable y reutilizable, un Workflowes un grafo de tareas definido por el desarrollador que un agente puede ejecutar como una acción única y potente.
Si tenemos complejidad en los procesos con múltiples pasos, resolución de tareas con distintas etapas secuenciales.
Procesos que requieren subagentes especializados en cada etapa o un seguimiento detallado en cada paso
Ejecutar tareas independientes en paralelo, mientras hay gestión de independencias. De esta manera optimizamos recursos.
Si tenemos que reintentar pasos por error tareas especificas sin reiniciar todo el flujo.

Para clarificar las diferencias entre patrones de orquestación, te muestro una comparativa entre workflow, graph y swarm. La mayor diferencia a considerar es cómo se determina la ruta de ejecución :

	Workflow	Graph	Swarm
Concepto fundamental	Un grafo de tareas predefinido (DAG) ejecutado como una herramienta única y no conversacional.	Un flowchart estructurado y definido por el desarrollador, donde un agente decide qué camino tomar.	Un equipo dinámico y colaborativo de agentes que se pasan las tareas de forma autónoma.
Estructura	Un desarrollador define todas las tareas y sus dependencias en el código.	Un desarrollador define todos los nodos (agentes) y aristas (transiciones) con antelación.	Un desarrollador proporciona un pool de agentes. Los propios agentes deciden el camino.
Flujo de ejecución	Determinista y paralelo. El flujo está determinado por el grafo de dependencias. Las tareas independientes se ejecutan en paralelo.	Controlado pero dinámico. El flujo sigue los bordes del grafo, pero la decisión de un LLM en cada nodo determina el camino (path).	Secuencial y autónomo. Un agente ejecuta una tarea y luego cede el control a otro agente adecuado en el enjambre.
¿Permite ciclo?	NO.	SÍ.	SÍ.
Mecanismos de compartir estados	La herramienta captura automáticamente los outputs de las tareas y los pasa como inputs a las tareas dependientes.	Se pasa un objeto de estado compartido a todos los agentes, quienes pueden leerlo y modificarlo libremente.	Todos los agentes disponen de un contexto compartido o memoria de trabajo, que contiene la solicitud original, el historial de tareas y el conocimiento de los agentes anteriores.
Historial de conversaciones	Contexto específico de la tarea. Una tarea recibe un resumen curado de los resultados relevantes de sus dependencias, no el historial completo.	Transcripción completa. Todo el historial de diálogo forma parte del estado compartido, lo que proporciona a cada agente un contexto completo y abierto.	Transcripción compartida. El contexto compartido proporciona un historial completo de los handoffs de agentes y el conocimiento aportado por agentes anteriores, disponible para el agente actual.
Control del comportamiento	La solicitud del usuario puede activar un workflow predefinido, pero no puede alterar su estructura interna.	La información que introduce el usuario en cada paso puede influir directamente en la ruta que seguirá el grafo a continuación.	La indicación inicial del usuario define el objetivo, pero a partir de ahí el Swarm corre de forma autónoma.
Escalabilidad	Escala bien en operaciones repetibles y complejas.	Escala bien en procesos complejos(muchas ramificaciones, condiciones).	Escala en función del número de agentes especializados en el equipo y de la complejidad de la tarea colaborativa.
Manejo de errores	Sistémico. Un fallo en una tarea detendrá todas las tareas dependientes posteriores. Es probable que todo el workflow entre en estado `failed`.	Controlable. Un desarrollador puede definir aristas de "error" explícitas para dirigir el flow a un nodo de error-handling si falla un paso.	Agent-driven. Un agente puede decidir transferir la tarea a un especialista en manejo de errores. El sistema se basa en tiempos de espera y límites de transferencia para evitar bucles infinitos.

➡ Conceptos genéricos de Workflow agénticos

Para la implementación del caso de uso, solo usé la workflow tool, una de las ~45 tools nativas disponibles en strands-agents-tools.

Componentes claves en la arquitectura:

⭐Definición y distribución de tareas. Cada tarea necesita una descripción especifica de qué debe lograr el agente, una asignación que haga matching con el agente adecuado según sus capacidades, y un nivel de prioridad que determine qué se ejecuta primero cuando hay margen de elección.

⭐Gestión de dependencias. Algunas tareas deben ejecutarse en un orden específico (dependencias secuenciales), mientras que las tareas independientes pueden correr en simultáneo (ejecución paralela). En la ejecución paralela tener en cuenta que el modelo de IA que se utilice debe permitirlo.
Los join points son los puntos donde varios caminos paralelos convergen antes de continuar. En el caso de uso elegido, los dos join points son discovery_questions (espera a company_research + stakeholder_mapping) y follow_up_actions (espera a discovery_questions + meeting_summary).

⭐Flujo de información. El mapeo de input/output conecta la salida de un agente con la entrada de otro, la preservación de contexto mantiene la información relevante a lo largo de todo el workflow, y la gestión de estado permite trackear el progreso general del workflow.

Parámetros básicos del workflow:

action → create, start, status (indica si hubo error o no), list, delete.

workflow_id → identificador único del workflow.

tasks → lista de tareas con sus correspondientes propiedades

Algunas propiedades dentro de cada task:
task_id : Obligatorio. Identificador o nombre de la tarea.

description: Obligatorio. se completa con un resumen de lo que hace la tarea, es un pequeño prompt.

dependencies: Opcional. Encadenas una tarea con la otra para que no se ejecute si las dependencias aún no culminaron.

system_prompt: Obligatorio.

priority: Propiedad numérica que indica prioridad en la ejecución por el modelo.

tools: Opcional. Pero si no lo especificás puede que en la inferencia el modelo decida usar cualquier tool nativa y entre en un loop infinito.
Si no querés que la tarea ejecute ninguna tool se puede especificar cómo "tools": NO_TOOLS, esto no es un valor oficial del SDK, es un workaround verificado empíricamente: se pasa un nombre de tool que no existe en el registry, forzando al sub-agente a correr sin tools. Pasar "tools": [] no funciona porque es falsy en Python y el workflow lo ignora heredando todo el toolset del agente padre.

➡ Topologías de Secuencias y Workflow

En Strands Agents, "Workflow" puede referirse a dos cosas distintas: una arquitectura secuencial que se implementa manualmente encadenando agentes en código Python, o la Workflow Tool (strands-agents-tools), que gestiona dependencias, paralelismo y pasaje de contexto automáticamente.

Workflow Secuencial

En la topología secuencial, cada agente es un objeto Python independiente y el desarrollador conecta las salidas manualmente. Es la forma más simple de encadenar agentes, pero no hay gestión automática de dependencias ni paralelismo.

from strands import Agent
# Create specialized agents
agent1 = Agent(system_prompt="You are Agent 1. Perform the first step.", callback_handler=None)
agent2 = Agent(system_prompt="You are Agent 2. Perform the second step.", callback_handler=None)
agent3 = Agent(system_prompt="You are Agent 3. Perform the final step.")

# Sequential workflow processing
def process_workflow(input_data):
    step1_result = agent1(f"Process: {input_data}")
    step2_result = agent2(f"Process: {step1_result}")
    final_result = agent3(f"Process: {step2_result}")
    return final_result

Workflow Tool

La Workflow Tool gestiona dependencias, paralelismo y pasaje de contexto automáticamente. El desarrollador define la estructura (tasks + dependencies) y la tool se encarga del resto: qué corre en paralelo, qué espera, y qué contexto inyecta a cada tarea dependiente.

from strands import Agent
from strands_tools import workflow

# Create an agent with workflow capability
agent = Agent(tools=[workflow])

# Create a multi-agent workflow
agent.tool.workflow(
    action="create",
    workflow_id="generic_workflow",
    tasks=[
        {
            "task_id": "task1",
            "description": "Description of the first task",
            "system_prompt": "You perform the first task.",
            "priority": 5
        },
        {
            "task_id": "task2",
            "description": "Description of the second task",
            "dependencies": ["task1"],
            "system_prompt": "You perform the second task.",
            "priority": 3
        },
        {
            "task_id": "task3",
            "description": "Description of the third task",
            "dependencies": ["task2"],
            "system_prompt": "You perform the third task.",
            "priority": 2
        }
    ]
)

# Execute workflow (parallel processing where possible)
agent.tool.workflow(action="start", workflow_id="generic_workflow")
# Check results
status = agent.tool.workflow(action="status", workflow_id="generic_workflow")

➡ Evaluaciones (Evals)

Strands cuenta con una marco oficial para realizar evaluaciones de resultados simples hasta el análisis de interacciones de multiagentes complejos.

Para evaluar el workflow usé strands-agents-evals con el mismo provider configurado en .env (Gemini u Ollama) como juez. En producción la práctica estándar es usar un modelo más capaz como judge (ej. el workflow corre con gemini-2.0-flash y el judge usa gemini-2.5-pro), pero para este proyecto educativo se unifica por simplicidad.

Combiné dos tipos de evaluación:

LLM-as-a-judge — el modelo evalúa la calidad del output final:

Evaluador	¿Qué evalúa?	Escala
`OutputEvaluator`	Verifica que `follow_up_actions` tenga las 3 secciones obligatorias (email, next steps, gaps) y que el contenido esté fundamentado en los datos reales de la reunión.	0 / 0.5 / 1
`HelpfulnessEvaluator`(1)	Evalúa si el entregable final es útil para un Solutions Architect — no solo si tiene el formato correcto. (Es una instancia de OutputEvaluator con rubric propio, no una clase separada del SDK!)	0 / 0.5 / 1

(1)HelpfulnessEvaluator del SDK requiere trazas OpenTelemetry que la Workflow Tool no provee. Se reemplazó por un segundo OutputEvaluator con rubric de helpfulness.
Cuando usé HelpfulnessEvaluator del SDK, el score devolvió 0.0 con el error: "Trace parsing requires actual_trajectory to be a Session object, got NoneType". El evaluador espera un objeto Session de Strands (que debe contener trazas OpenTelemetry de la ejecución del agente), no solo el texto del output.

Métricas deterministas — evalúan propiedades estructurales del patrón, sin llamadas a LLM:

Métrica	¿Qué mide?
`task_completion_rate`	Fracción de tasks que completaron con `status="completed"` en el JSON persistido.
`join_point_coverage`	Verifica que ambos join points produjeron output no vacío, confirma que la inyección de contexto funcionó.
`required_sections`	Check determinista de las 3 secciones del entregable (email, next steps, gaps).
`stakeholder_coverage`	Verifica que cada stakeholder del input aparece en `discovery_questions`, confirma que el contexto de `stakeholder_mapping` llegó al join point #1.
`keyword_presence`	Presencia de keywords de dominio (con soporte de sinónimos via `\

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-workflow

Para la prueba de concepto utilicé dos opciones locales de ejecución que permitió analizar sus resultados, pero se puede utilizar solo una:
a. Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker.
En caso que quieras ejecutar realmente las task que son independientes en paralelo, hay que indicarselo a ollama (sino el comportamiento por default es secuencial) :
{% raw %}

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Start the Ollama server en parallel
# docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama -e OLLAMA_NUM_PARALLEL=3  ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
# If the container has already been created and 
# is currently stopped, simply use: docker start ollama
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. Api de gemini. La api key se puede generar de manera gratuita desde aquí y utilizar algunos de estos modelos (experimentar con los que te permita):

gemini-2.5-flash-lite
gemini-2.5-flash
gemini-3.5-flash
gemini-3.5-flash-lite

El código está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica, todo el detalle lo encontrás en el Readme.md del proyecto:

strands-workflow/
├── README.md
├── requirements.txt                  # strands-agents[litellm,ollama], strands-agents-tools, pydantic, pytest
├── .env.example                      # MODEL_PROVIDER, GEMINI_API_KEY, OLLAMA_MODEL_ID
├── .gitignore
├── pytest.ini                        # pythonpath=. so tests/ and evals/ resolve src./config imports
│
├── src/
│   ├── __init__.py
│   ├── config.py                     # get_model_config(): single global provider (Gemini or Ollama) via MODEL_PROVIDER env var
│   ├── main.py                       # Entry point: builds tasks, creates+starts the workflow, assembles the final .md
│   │
│   ├── agents/
│   │   ├── __init__.py
│   │   └── prompts.py                # System prompts per task_id (company_research, stakeholder_mapping, etc.)
│   │
│   ├── workflow/
│   │   ├── __init__.py
│   │   ├── builder.py                # build_tasks(): builds the task list — task_id, dependencies, priority
│   │   ├── deliverable.py            # Reads the persisted workflow JSON and assembles the final .md
│   │   └── instrumentation.py        # Timing hook: logs START/END + duration per task
│   │
│   ├── models/
│   │   └── schemas.py                # Pydantic: DiscoveryMeetingInput
│   │
│   └── utils/
│       ├── logging_config.py         # Tees stdout+stderr to logs/, optional DEBUG level
│       └── report_export.py          # Writes the final .md to outputs/
│
├── tests/
│   ├── __init__.py
│   ├── test_config.py                # get_model_config(): provider resolution + error if API key is missing
│   ├── test_workflow_structure.py    # Validates the workflow is well-formed: no cycles, existing dependencies, correct join points
│   ├── test_schemas.py               # Pydantic validation of DiscoveryMeetingInput
│   ├── test_report_export.py         # Generates the .md from a mocked workflow JSON
│   └── test_instrumentation.py       # Verifies install_task_timing_hooks() logs START/END with duration, without calling a real LLM
│
├── examples/
│   └── sample_input.json             # Sample input to run the workflow quickly
│
├── evals/
│   ├── __init__.py
│   ├── evaluate_workflow.py          # strands-evals runner: OutputEvaluator + HelpfulnessEvaluator + deterministic metrics
│   ├── metrics.py                    # Domain metrics: task completion rate, join point coverage, required sections, stakeholder coverage, keyword presence
│   └── test_cases/
│       └── workflow_eval_cases.json  # Input + expected properties per eval case
│
├── logs/
│   └── .gitkeep                      # logs/run_<timestamp>.log, gitignored otherwise
│
└── outputs/
    └── .gitkeep                      # .md generated per run, gitignored otherwise

Ejecución Local

Una vez que tengas el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 o la api key de gemini generada, pasamos armar el ambiente.

Los requerimientos que vas a encontrar en requirements.txt :

strands-agents[litellm,ollama]==1.52.0
strands-agents-tools==0.8.6
ollama==0.5.1
pydantic==2.13.4
pytest==8.3.4
strands-agents-evals>=1.0.0
python-dotenv==1.0.1

pip install -r requirements.txt

En .env se necesitan estos valores. Notar que depende el modelo que elegimos podemos intercambiar el MODEL_PROVIDER:

# Select ONE provider: "ollama" or "gemini"
MODEL_PROVIDER=ollama

# --- Gemini (only required if MODEL_PROVIDER=gemini) ---
# Free tier key: https://aistudio.google.com/apikey
GEMINI_API_KEY=YourApiKey
GEMINI_MODEL_ID=gemini-3.5-flash-lite

# --- Ollama (only used if MODEL_PROVIDER=ollama) ---
# Must have the Ollama daemon running locally: https://ollama.com
# Pull the model first: ollama pull gemma4:e2b-it-qat
OLLAMA_MODEL_ID=gemma4:e2b-it-qat
OLLAMA_HOST=http://localhost:11434

# --- Workflow persistence ---
# Redirects strands_tools' internal workflow state JSON into logs/ instead of
# the default ~/.strands/workflows/ — keeps everything from one run together.
STRANDS_WORKFLOW_DIR=logs/workflows

cp .env.example .env

En src/config.py está la configuración de ejecución, en este caso de uso utilicé parámetros como la temperature y max_tokens (limita los tokens que pueden gastar los agentes).
→ Si optas por ejecutar con el provider ollama hay que tener en cuenta el valor de la ventana de contexto: num_ctx.
→ Si optas por ejecutar con la apikey de Gemini, en el SDK de Strands, el dispatcher create_model que usa workflowinternamente soporta estos modelos solo vía litellm ("model_provider": "litellm")

Las pruebas están organizadas en tests/ en un solo nivel: ejecución rápida y determinista. Validan la estructura del workflow (sin ciclos, dependencias existentes, join points correctos), el schema del input con Pydantic, la exportación del .md desde un JSON mockeado, y los hooks de timing (sin llamadas al LLM).

python -m pytest

Ejecución del Workflow principal. En examples/sample_input.txtestá el input de ejemplo en un formato json:

{
"company_name": "...",
"known_challenges": "...",
"stakeholders": "...",
"raw_meeting_notes": "..."
}

Se puede ejecutar contra el modelo ollama local o vía api de gemini comentado más arriba.

python -m src.main

🎯 Un bug real: durante las pruebas descubrí que usando Gemini con paralelismo real puede hacer crashear el proceso de forma intermitente (y no es un problema de Windows, ocurre también en Linux). La causa es un bug conocido y abierto en LiteLLM: el cliente HTTP que usa para el streaming de Gemini es un singleton global que no distingue entre los distintos event loops que crea cada tarea del workflow al correr en paralelo.
Solución aplicada: limitar la ejecución a un hilo por vez cuando el proveedor es Gemini, vía la env var STRANDS_WORKFLOW_MAX_THREADS=1 de Strands.

El log de las llamadas del workflow está en logs/. Contiene la data cruda que permite verificar si hubo paralelismo, cuanto tiempo tarda cada task, etc.

El resultado final
Es un documento markdown con diferentes secciones como:
Company Research - Stakeholder Mapping - Meeting Summary - Discovery Questions - Follow-up Deliverable and Gap
Se guarda en outputs/discovery_meeting_yyyymmdd_hhmmss.md.

Por último, hice una evaluación de pruebas sobre el workflow multiagente real con el concepto de "Evals". Ejecuta el workflow completo contra el modelo configurado, corre los evaluadores LLM-as-judge y las métricas deterministas, muestra los resultados en consola y guarda el reporte completo en outputs/eval_report_<timestamp>.json.

python  -m  evals.evaluate_workflow

📝 Nota: La explicación del código fuente y paso a paso de la ejecución se encuentra detallado en el README.md en github .

Conclusiones y lecciones aprendidas

El patrón Workflow en Strands resuelve en lineas generales lo que indica su documentación. Dependency resolution, paralelismo real y context passing automático entre join points funcionaron correctamente y sin código extra de orquestación. El DAG se ejecuta en el orden correcto y los join points reciben el contexto inyectado de sus dependencias sin intervención manual.
La Workflow Tool de Strands está en maduración activa. pause/resume están documentados como Advanced Features pero no implementados — al ejecutarlos devuelven "🚧 Action '...' is not yet implemented", verificado contra el código fuente instalado. El workflow puede quedar colgado indefinidamente si una task termina en error (el loop interno gira para siempre esperando dependientes que nunca se vuelven "ready"). El resultado de cada task no se expone via API... hay que leer el JSON persistido directamente.
Algunos comportamientos requieren workarounds no oficiales. La herencia de tools en sub-agentes no está documentada. Por defecto cada sub-agente hereda todo el toolset del padre, incluida la workflow tool, lo que con modelos agénticos lleva a llamadas recursivas reales. "tools": [] (lista vacía) no funciona como restricción porque es falsy en Python — la solución es NO_TOOLS (["__no_tools__"]), un placeholder que fuerza filtered_tools a quedar vacío. No encontré hooks públicos para observar timing por task, se requiere monkeypatch sobre WorkflowManager.execute_task.
Los hooks de Strands tienen un mecanismo LimitToolCounts (via BeforeToolCallEvent) que permite cancelar una tool cuando se invoca más veces de lo permitido, útil como guardrail contra loops. Sin embargo, no aplica al bug de herencia de la Workflow Tool, ese mecanismo actúa sobre el agente padre, pero los sub-agentes creados internamente por el framework son instancias separadas sobre las que no hay control para registrar hooks desde afuera. Por eso "tools": NO_TOOLS sigue siendo la solución correcta.
Concurrencia del workflow tool con Gemini. Cuando hay tasks en paralelo + LiteLLM/aiohttp, se produce un RuntimeError: Task <...> got Future <...> attached to a different loop intermitente. Cada task corre en su propio thread con su propio asyncio.run(), y el cierre del connector de aiohttp cae en el loop equivocado. Se solucionó colocando una variables de entorno de Strands STRANDS_WORKFLOW_MAX_THREADS=1, limitando la concurrencia. (esto no sucede con Ollama-Gemma4 via Docker).

Recursos

Curso Fundamentos (hacelos!)
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Agent Workflows
Evals
Otros
5 Multi-Agent Patterns in Strands

Graph en Strands: Parallel + Aggregation y Feedback Loop para construir Knowledge Graphs

Laura Bolaños — Wed, 12 Aug 2026 15:19:12 +0000

Siguiendo con la serie de artículos sobre la orquestación de multiagentes en Strands, le toca el turno a Graph Multi-Agent Pattern, ejemplificado con la construcción de un knowledge graph en base a un input de texto (abstract), donde los nodos de un grafo determinista tienen las responsabilidades divididas para lograrlo. Se probó de dos maneras: con Gemma4 + Ollama y con la API de Gemini en su capa gratuita.

Introducción

La información del presente artículo la podés seguir teniendo alguna noción sobre agentes y grafos. Pero te propongo hacer un curso de fundamentos del framework Strands Agents, para que en futuros proyectos puedas dar mayor complejidad a tus agentes. La idea principal es experimentar con el patrón sin gastar en suscripciones pagas de tokens, dejando la implementación en AWS para otra instancia.

✳ El caso de uso que elegí para representar el patrón Graph es la Extracción de entidades/relaciones para formar un Knowledge Graph con validación. Se me ocurrió hacer algo útil para la comunidad académica, un mecanismo de extracción de conocimiento que sea capaz de tomar parte de un artículo científico e ingestar lo más importante en un documento json, que pueda ser legible por humanos y sistemas. La solución es un pipeline de construcción de knowledge graph a partir de un texto (ej. un abstract), usando la topología Parallel Processing→ with Aggregation→ Feedback Loop.
El diseño es una versión reducida de arquitecturas multi-agente real para enriquecimiento de knowledge graph descritos en:

Revolutionizing Knowledge Graphs with Multi-Agent Systems: AI-Powered Construction, Enrichment, and Applications

Conceptos Claves

➡ Graph es un patrón de orquestación de agentes determinista
El desarrollador define explícitamente la topología de ejecución: qué nodos existen, en qué orden corren, y bajo qué condiciones se transita de uno a otro. Cada nodo es un agente y a diferencia de otros patrones como Swarm, donde el flujo surge de la negociación entre agentes, en Graph el flujo está fijado de antemano como un grafo dirigido (DAG o con ciclos controlados).

Graph es apropiado cuando:

La estructura de dependencias es conocida de antemano: sabés qué pasos necesitan el resultado de otros antes de poder ejecutarse.
Hay paralelismo real que después converge: varios agentes pueden trabajar al mismo tiempo sobre partes independientes del problema, y sus resultados se consolidan en un punto de agregación explícito.
Se necesita revisión con ciclos controlados: un resultado puede requerir corrección y volver a un paso anterior (feedback loop), con límites de seguridad (set_max_node_executions) que garantizan que el proceso termine.
La trazabilidad y el control son prioritarios: como cada nodo y cada transición son explícitos, es más fácil auditar, debuggear y predecir el comportamiento, es bueno en contextos con validación humana o compliance.

➡ Conceptos genéricos de Grafos Agenticos

El framework propone una interfaz sencilla para la construcción de grafos, con 3 componentes base: GraphNode, GraphEdge, GraphBuilder

1.Los nodos representan agentes, nodos personalizados o sistemas multiagente. Ej:

from strands import Agent
from strands.multiagent import GraphBuilder

# Build the graph
builder = GraphBuilder()

# Add nodes
builder.add_node(agent_1, "[node_id_1]")
builder.add_node(agent_2, "[node_id_2]")

2.Las aristas definen las dependencias y el flujo de información entre los nodos. Además se puede agregar lógica condicional (no lo utilicé en el caso de uso analizado):

# Add edges (dependencies)
builder.add_edge("[node_id_1]", "[node_id_2]")

3.La ejecución sigue la estructura del grafo, respeta dependencias, la salida de un nodo se convierte en la entrada de su dependiente. Y en el caso de que varios nodos tienen aristas hacia un nodo de destino, el comportamiento predeterminado para la ejecución del destino puede variar según el SDK (Python utiliza semánticas OR: el nodo destino se dispara en cuanto cualquiera de sus dependencias completa).
4.Compatibilidad con patrones anidados, un grafo como nodo dentro de otro grafo.
5.Remote Agents vía A2A: Graph soporta agentes remotos como nodos a través de A2AAgent, para arquitecturas distribuidas donde la orquestación corre localmente pero tareas especializadas se ejecutan en servicios remotos.
6.Cyclic graph permite que un nodo sea revisitado dentro del mismo flujo, con límites de ejecución y gestión de estado.
7.Custom Node Types: Graph permite extender MultiAgentBase para crear nodos que ejecutan funciones Python deterministas en lugar de llamar a un LLM, útil para lógica de negocio, validaciones y pipelines de procesamiento de datos dentro del mismo grafo.
8.Graphs as a Tool: mediante el paquete strands_tools, un agente puede recibir el graph como tool y construir/ejecutar su propia topología de nodos en tiempo real, dejando que el LLM decida dinámicamente la orquestación en lugar de definirla de antemano con GraphBuilder.

➡ Topologías comunes
Strands documenta 4 topologías base que cubren la mayoría de casos de uso, y se pueden combinar según la complejidad del problema. Sequential Pipeline sirve cuando cada paso depende estrictamente del anterior. Parallel + Aggregation es ideal cuando hay trabajo independiente que puede correr simultáneamente y luego converger en un solo resultado. Branching Logic permite que el flujo tome caminos distintos según el contenido generado en un paso previo. Y Feedback Loop habilita ciclos de revisión con vuelta atrás, para casos donde un resultado necesita validación antes de darse por definitivo.

➡ Evaluaciones (Evals) Strands cuenta con una marco oficial para realizar evaluaciones de resultados simples hasta el análisis de interacciones de multiagentes complejos.
En el caso de uso para la creación de Knowledge Graph se realizaron 6 evaluaciones (3 sin utilizar el framework).

Evaluación / Métrica	Tipo / Origen	¿Qué evalúa?	Escala
OutputEvaluator	LLM-as-a-Judge (`strands-agents-evals`)	Verifica que la salida del nodo Publisher sea un JSON válido (`entities` y `relations`) y que las relaciones estén fundamentadas fácticamente en el texto original.	0 / 0.5 / 1
SemanticCorrectnessEvaluator	LLM-as-a-Judge (`strands-agents-evals`)	Compara semánticamente el knowledge graph generado contra las relaciones esperadas (ground truth), dando crédito parcial a triples con distinto wording pero igual significado. Implementado como un segundo `OutputEvaluator` con rúbrica de referencia, ya que el `CorrectnessEvaluator` oficial requiere un objeto `Session` de Strands (incompatible con grafos multi-agente).	0 / 0.5 / 1
Exact-Match (P / R / F1)	Métrica Determinista (`metrics.py`)	Mide la coincidencia exacta (normalizada a minúsculas/espacios) entre las triples extraídas y las triples de referencia del caso de prueba.	0.0 – 1.0
Loop Iterations Count	Métrica de Topología (`metrics.py`)	Cuenta cuántas iteraciones de revisión ocurrieron en el feedback loop entre el Validator y el Aggregator antes de la aprobación final.	entero ≥ 0
Bias-Flag Rate	Métrica Determinista (`metrics.py`)	Detecta si la respuesta del nodo Validator levantó alguna objeción o alerta de sesgo/desbalance en las relaciones o entidades analizadas.	`true` / `false`
Compound Entity Check	Métrica Determinista (`metrics.py`)	Chequeo de regresión: detecta entidades compuestas (ej. "entities and relations") que deberían haberse dividido en dos nodos separados, según la regla en `extractor_agent.py`/`aggregator_agent.py`.	lista de entidades detectadas

Para clarificar: una triple es la unidad básica de información que compone un Knowledge Graph. Representa una afirmación o hecho estructurado combinando tres elementos:

$$\text{(Sujeto)} \xrightarrow{\quad\text{Relación / Predicado}\quad} \text{(Objeto)}$$

Sujeto (source): La entidad de origen (ej. "Laura Bolaños").
Relación (relation): El tipo de vínculo o conector (ej. "born_in").
Objeto (target): La entidad de destino (ej. "Argentina").

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-graph

⭐ El caso de uso combina dos topologías: paralelismo con agregación, seguido de un ciclo de feedback antes de publicar el resultado final. Notar en la representación que Extractor es un agente que se instancia 3 veces, una única definición de agente, instanciada 3 veces (una por chunk_number) dentro del loop en builder.py.

Para la prueba de concepto utilicé dos opciones locales de ejecución que me permitió analizar sus resultados, pero podes utilizar solo una:
a. Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker:

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
# If the container has already been created and 
# is currently stopped, simply use: docker start ollama
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. Api de gemini. La api key se puede generar de manera gratuita desde aquí y utilizar al menos estos modelos (experimentar con los que te permita):

gemini-2.5-flash-lite
gemini-2.5-flash
gemini-3.5-flash
gemini-3.5-flash-lite

El código del multiagente Graph está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica:

strands-graph/
├── README.md                        # Project overview, setup, and usage instructions
├── requirements.txt                  # Python dependencies (strands-agents[gemini,ollama], strands-agents-evals, pydantic, etc.)
├── .env.example                      # Template for API keys (GEMINI_API_KEY) and Ollama config
├── .gitignore
│
├── src/
│   ├── __init__.py
│   ├── config.py                     # Model configs: role -> provider mapping (Gemini/Ollama), get_model()
│   ├── main.py                       # Entry point: builds graph, runs on input, prints/exports result, saves run log
│   │
│   ├── agents/
│   │   ├── __init__.py               # Re-exports all create_*_agent() factories
│   │   ├── coordinator_agent.py      # Entry point: splits input text into chunks for parallel extraction
│   │   ├── extractor_agent.py        # Shared extractor logic, instantiated 3x (one per chunk); no compound entities
│   │   ├── aggregator_agent.py       # Conflict resolution: merges, deduplicates, splits any compound entities
│   │   ├── validator_agent.py        # structured_output_model: checks format, consistency, completeness, bias
│   │   └── publisher_agent.py        # Formats and exports the final validated KG
│   │
│   ├── graph/
│   │   ├── __init__.py
│   │   ├── builder.py                # GraphBuilder setup: 7 nodes, edges (incl. aggregator->publisher), entry point
│   │   └── conditions.py             # Edge conditions: needs_revision, is_approved, all_dependencies_complete
│   │
│   ├── models/
│   │   └── schemas.py                # Pydantic schemas: Relation, KnowledgeGraph, ValidatorOutput
│   │
│   └── utils/
│       ├── logging_config.py         # Debug logging + tee_console_to_file (saves full run output to logs/)
│       └── kg_export.py              # Parses and exports final KG to JSON
│
├── tests/
│   ├── __init__.py
│   ├── test_conditions.py            # Unit tests for all_dependencies_complete, needs_revision, is_approved
│   ├── test_kg_export.py             # Unit tests for parse_publisher_output (valid/invalid JSON, schema mismatch)
│   ├── test_metrics.py               # Unit tests for evals/metrics.py, incl. find_compound_entities regression check
│   ├── test_schemas.py               # Unit tests for Relation/KnowledgeGraph/ValidatorOutput validation
│   └── test_settings.py              # Unit tests for get_model role/provider resolution and missing API key error
│
├── examples/
│   └── sample_input.txt              # Short input text used as the default demo run
│
├── evals/
│   ├── __init__.py
│   ├── test_cases/
│   │   └── kg_extraction_cases.json  # Input texts + expected relations for evaluation
│   ├── evaluators.py                 # Custom Strands Evals SDK evaluators (precision/recall, feedback loop)
│   ├── evaluate_graph.py             # Strands Evals SDK runner: Case/Experiment against test cases
│   └── metrics.py                    # Domain metrics: precision/recall, loop iterations, bias-flag rate, compound entities
│
├── logs/
│   └── .gitkeep                      # Full console output per run (logs/run_<timestamp>.log), gitignored otherwise
│
└── outputs/
    └── .gitkeep                      # Generated KG JSON + eval reports land here, gitignored otherwise

Ejecución Local

Una vez que tenemos el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 o la api key de gemini generada, pasamos armar el ambiente.

Los requerimientos que vamos a encontrar en requirements.txt:
strands-agents[gemini,ollama]>=1.0.0
strands-agents-tools>=0.1.0
strands-agents-evals
python-dotenv>=1.0.0
pydantic>=2.0.0
pytest

pip install -r requirements.txt

En .env se necesitan estos valores. Notar que depende el modelo que elegimos podemos intercambiar:

#Gemini (required if any role uses provider="gemini") ---
GEMINI_API_KEY=your_gemini_api_key_here
GEMINI_MODEL_ID=gemini-2.5-flash
#Ollama (required if any role uses provider="ollama") ---
OLLAMA_HOST=http://localhost:11434
OLLAMA_MODEL_ID=gemma4:e2b-it-qat
#Per-role provider overrides (optional) ---
#Values: "gemini" or "ollama". Defaults are set in src/config.py.
MODEL_PROVIDER_COORDINATOR=ollama
MODEL_PROVIDER_EXTRACTOR=ollama
MODEL_PROVIDER_AGGREGATOR=ollama
MODEL_PROVIDER_VALIDATOR=ollama
MODEL_PROVIDER_PUBLISHER=ollama

cp .env.example .env

En src/config.py está la configuración de despliegue, en este caso de ejecución local se encuentran parámetros como la temperature, top_p, max_output_tokens (muy importante porque limita los tokens que pueden gastar los agentes).

Las constantes estructurales del grafo a nivel módulo, se encuentran en src/graph/builder.py :

NUM_EXTRACTORS → cantidad de nodos extractores paralelos (y de chunks que pide el Coordinator). Cambiarlo requiere que coincida con el num_chunks pasado a create_coordinator_agent().
MAX_NODE_EXECUTIONS → límite global de ejecuciones de nodos en todo el grafo, la salvaguarda contra el feedback loop infinito Validator↔Aggregator.
EXECUTION_TIMEOUT_SECONDS → timeout global del grafo completo.

NUM_EXTRACTORS = 3
MAX_NODE_EXECUTIONS = 15
EXECUTION_TIMEOUT_SECONDS = 1200 # (For local execution, it's advisable to have a high value)

Las pruebas están organizadas en tests/ en un solo nivel: ejecución rápida y determinista. Validan la lógica de las funciones de condición de Graph (needs_revision, is_approved, all_dependencies_complete), el parsing/validación de schemas (Relation, KnowledgeGraph, ValidatorOutput).
Se testea, además de los posibles errores del runtime, la resolución de provider/modelo por rol de src/config.py:

_resolve_provider() — que cada rol (coordinator, extractor, aggregator, validator, publisher) resuelva al provider correcto: el default (ROLE_PROVIDER_DEFAULTS) cuando no hay override, y la variable de entorno (MODEL_PROVIDER_VALIDATOR=ollama, etc.) cuando sí la hay.
get_model() — que devuelva una instancia de OllamaModel cuando el provider es "ollama", y GeminiModel cuando es "gemini".

python -m pytest

Procedemos a ejecutar el Graph principal. En examples/sample_input.txtestá el input de ejemplo.
Se puede ejecutar contra el modelo ollama local o vía api de gemini comentado más arriba.

python -m src.main

El log de las llamadas entre el pipeline de agentes se visualiza en la carpeta logs/. Contiene la data cruda que permite comparar comportamiento del modelo (cuántos turnos internos hace cada uno, cuánto tarda, si usa tool calls, etc.).

El resultado final
Es un Knowledge graph y se guarda en un .json enoutputs/.
Se visualiza la representación estructurada del texto de entrada, describiendo: qué conceptos existen (entities) y cómo se relacionan entre sí (relations), en formato sujeto-predicado-objeto.

Por último, hacemos una evaluación de pruebas sobre el grafo multiagente real con el concepto de "Evals". Esto es importante para todos los agentes futuros que construyas, tomar la documentación de Strands y descubrir cómo y para qué tenemos que evaluar nuestros agentes. El resultado se guarda en outputs/eval_report.json (el detalle de las evaluaciones están en "Conceptos Claves"):

python  -m  evals.evaluate_graph

📝 Nota: La explicación del código fuente y paso a paso de la ejecución se encuentra detallado en el README.md en el repositorio de github .

Conclusiones y lecciones aprendidas

Construir este pipeline con Graph me dejó varias lecciones que van más allá de la forma de crearlo según su documentación:

Las constantes estructurales del grafo no son de uso de común para todos los modelos. NUM_EXTRACTORS, MAX_NODE_EXECUTIONS y EXECUTION_TIMEOUT_SECONDS en builder.py parecen valores de infraestructura, pero en la práctica están acoplados al comportamiento del modelo elegido. Con Gemma4 local, el cuello de botella fue el tiempo (EXECUTION_TIMEOUT_SECONDS tuvo que subir a 1800s). Con Gemini, el cuello de botella fue la convergencia del feedback loop: con temperature=0.3 y top_p=0.9 el Aggregator regeneraba las triples con variación de wording en cada ronda, y el Validator nunca encontraba dos corridas iguales para aprobar, agotando MAX_NODE_EXECUTIONS sin converger. Solución: bajar a temperature=0 y top_p=0.5 .
Análisis del input propagation de Graph Un nodo sólo recibe el resultado de sus dependencias directas + el input original con el que comienza el grafo. El Publisher, dependiendo solo del Validator, se quedó sin las triples reales porque el Validator fue instruido a responder con una confirmación corta, no a repetir los datos. La solución fue agregar aggregator → publisher como dependencia adicional. Hay que diseñar edges, pensando qué datos necesita cada nodo, no solo qué controla el flujo.
Las semánticas OR de Python son una fuente de bugs silenciosos. Sin all_dependencies_complete(), el Aggregator se hubiera ejecutado 3 veces (una por extractor) en lugar de una vez con los 3 resultados completos. Cualquier nodo con múltiples edges de entrada en Python necesita esta verificación explícita si queremos esperar a todas las dependencias.
La granularidad de extracción es responsabilidad del prompt, no del framework. Ver entidades compuestas como "entities and relations" en lugar de dos nodos separados es variabilidad normal de un LLM con temperatura > 0. Hay que reforzar reglas en el prompt del Extractor y del Aggregator.
structured_output_model requiere que el modelo soporte tool calling (este parámetro se pasa en la creación del Agent. Hay que verificarlo (ollama show <model> → Capabilities: tools) antes de asumir que cualquier modelo local lo soporta.
Exact-match y LLM-as-judge miden cosas distintas. En una corrida, el mismo caso obtuvo F1 exact-match = 0.0 pero SemanticCorrectnessEvaluator = 1.0, el pipeline había extraído el 100% del conocimiento correcto, solo con sinónimos distintos ("Aggregator node" vs "Aggregator"). Confiar solo en exact-match hubiera hecho pensar que el pipeline falló por completo.

Recursos

Curso Fundamentos
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Graph
Evals
Otros
Multi-Agent Systems with Graph Pattern
Inyección de prompts en agentes de IA
5 Multi-Agent Patterns in Strands

Swarm en Strands: orquestación autónoma mediante handoffs emergentes

Laura Bolaños — Mon, 03 Aug 2026 14:55:38 +0000

Siguiendo con la serie de artículos sobre la orquestación de multiagentes en Strands, en estas notas le toca turno a Swarm o Enjambre explicado con un ejemplo gamificado de cinco agentes especializados, donde cada uno es responsable de diseñar una dimensión distinta de un videojuego. Testeado de dos maneras con Gemma4 + Ollama y con la api de Gemini.

Introducción

Para desarrollar y comprender agentes con el framework Strands Agents te propongo hacer un curso de fundamentos o leer su documentación (que es extensa). Los fundamentos son importantes! Es primordial conocer cómo dar complejidad a nuestros agentes, no esperar delegar toda la responsabilidad del diseño a la IA (recursos al pie de estas notas).
Para la prueba de concepto utilicé dos opciones locales de ejecución que me permitió analizar sus resultados:

Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker.
Con la Api de gemini. La api key se puede generar de manera gratuita y utilizar el modelo "Gemini 2.5 Flash"

🎮 El caso de uso que tomé para desarrollar el patrón Swarm es la creación de un Game Design Document (GDD) a partir de una premisa: "roguelike de cocina en un castillo maldito..."
Participan cinco agentes especializados, cada uno responsable de una dimensión diferente del diseño del videojuego: mecánicas, narrativa, niveles, lore (historias, mitos, reglas, datos del pasado) y experiencia de juego. Todos colaboran para transformar una premisa simple en un Game Design Document (GDD) coherente.

A diferencia de un pipeline lineal, los agentes pueden detectar fricciones entre sus decisiones (una mecánica que contradice la narrativa, una regla de lore que rompe el balance) y reabrir la conversación con el agente correspondiente hasta llegar a un resultado consensuado.

Conceptos Claves

➡ Swarm es un patrón de orquestación de agentes colaborativo, donde múltiples agentes trabajan juntos como un equipo para resolver tareas complejas. A diferencia de los sistemas multiagente tradicionales, ya sean secuenciales o jerárquicos, un enjambre permite la coordinación autónoma entre agentes con contexto y memoria de trabajo compartidos.

Swarm es apropiado cuando:

La secuencia de pasos no se puede predefinir: de antemano no sabés qué agente necesitará intervenir, porque depende del contenido que se vaya generando.
Puede haber correcciones o retrocesos: el problema requiere ciclos de ida y vuelta entre especialistas (ejemplo: una decisión de un agente invalida el trabajo de otro).
Hay múltiples dimensiones de expertise en tensión: cada agente defiende una perspectiva distinta y el valor está justamente en que negocien entre sí, no en que trabajen aislados uno de otro.
Se necesita razonamiento colectivo emergente: la solución final surge de la interacción entre agentes, no de que un solo agente (o un humano) coordine todo desde arriba.

❗ No es el patrón ideal cuando el flujo de trabajo es fijo y predecible.

➡ Memoria / Contexto
Poseen memoria de trabajo compartida y contexto completo. Cuando el enjambre se ejecuta, el historial completo de mensajes (propuestas, objeciones y razonamientos de de los agentes anteriores) se transmite al nuevo agente que toma el control (handoff).
Payload del Handoff: además del historial acumulado, cuando un agente ejecuta la herramienta de handoff, puede adjuntar un mensaje o nota explícita (message / context) explicando por qué le transfiere la tarea y qué espera que haga.

➡ Nodos vs. Agentes
En Swarm, cada agente se registra como un "nodo" (SwarmNode) que envuelve al Agent. Esta distinción importa porque el swarm no razona en términos de "quién es quién" sino de "qué nodo ejecuta a continuación". El resultado final expone esto como node_history, una lista de nodos ejecutados, no una conversación: es lo que permite reconstruir después la topología real que se ejecutó, sin haberla tenido que diseñar de antemano.

➡ El mecanismo de Handoff es tool-calling, no un cambio de contexto mágico
Vale la pena aclarar explícitamente que handoff_to_agentno es una función especial del framework fuera del paradigma de LLMs: es una tool más, inyectada automáticamente por Strands en cada agente del swarm, con el mismo mecanismo de function-calling que cualquier otra tool. La consecuente es la fiabilidad del patrón Swarm depende enteramente de qué tan bien el modelo subyacente hace tool-calling. No es una limitación de Strands, es una dependencia estructural del patrón. Por eso, acompañando este artículo el caso de uso se testeo de dos maneras: con el pequeño modelo Gemma4 y con el modelo Gemini 2.5 Flash.

➡ Topología emergente vs. predefinida (el argumento central de "por qué Swarm")
En Swarm, la topología es un resultado, no una entrada. Se descubre recién en la ejecución, y puede variar entre corridas con la misma premisa (ejemplo: tengo 5 agentes y sólo intervienen 4). Esto es una ventaja de adaptabilidad y un riesgo no-determinista al mismo tiempo.
Se necesita indicar donde comienza el enjambre y cada punto de decisión lo toma el propio agente en base al contexto acumulado. Aquí un topología de ejemplo del caso de uso:

mechanic_designer
      ↓
level_architect ←──────────┐
      ↓                    │
playtest_simulator ─────────┤ (iteration 1: objection → adjustment)
      ↓                    │
level_architect ──────────→┘
      ↓
playtest_simulator ─────────┐ (iteration 2: objection → adjustment)
      ↓                    │
level_architect ←───────────┘
      ↓
narrative_weaver
      ↓
lore_keeper
      ↓
playtest_simulator ─────────┐ (iteration 1: objection → adjustment)
      ↓                    │
level_architect ←───────────┘
      ↓
playtest_simulator
      ↓
[VERDICT: NO FRICTION DETECTED] → END

➡ Guardrails como parte del diseño
max_handoffs: Máximo de transferencias entre agentes permitidos en todo el swarm antes de forzar el corte. Es el límite global de "pasos" de la ejecución completa.
max_iterations: Máximo de iteraciones del swarm (ejecuciones de nodo) permitidas. En la práctica actúa junto con max_handoffs como segunda red de seguridad contra ejecuciones descontroladas.
execution_timeout: Tiempo total en segundos que puede durar la ejecución completa del swarm, sumando todos los agentes y handoffs. Si se supera, el swarm corta con Status.FAILED aunque esté en medio de un turno.
node_timeout: Tiempo máximo (en segundos) que un agente individual puede tardar en un solo turno (una llamada al modelo + su respuesta). Protege contra que un nodo puntual se cuelgue sin afectar el límite global.
repetitive_handoff_detection_window: Tamaño de la "ventana" (cantidad de handoffs recientes) que Strands analiza para detectar patrones repetitivos. Con 6, mira los últimos 6 handoffs para decidir si hay un loop.
min_unique_agents: Dentro de esa ventana, cantidad mínima de agentes distintos que deben haber participado para considerar el flujo "sano". Si en los últimos 6 handoffs participaron menos de 3 agentes únicos (ej. solo 2 rebotando entre sí), Strands lo detecta como ping-pong y corta el swarm.
Todos los guardrails anteriores no son opcionales para un swarm en producción, son necesarios para limitar la autonomía de los agentes y que el costo de tokens, tiempo o dinero en APIs pagas no se descontrole.

➡ La importancia del diseño de prompts
Strands provee el mecanismo de handoff (la tool, el hook, los guardrails), pero no decide cuándo usarlo, eso está en el system prompt de cada agente. En este caso de uso, cada uno de los 5 prompts define explícitamente tres cosas: el rol y criterios de evaluación del agente, a quién y bajo qué condición debe transferir el control, y reglas de convergencia para evitar que vuelva a objetar lo mismo una vez resuelto ("Convergence rule").

Esta última fue necesaria escribirla ya que en las primeras ejecuciones algunos agentes re-abrían el mismo desacuerdo varias veces con distintas palabras, generando ciclos improductivos que ni los guardrails ni el hook podían distinguir de una negociación legítima. La solución fue de prompt, instruir explícitamente a cada agente a aceptar una corrección después de la primera vuelta, salvo que aparezca un motivo nuevo. Los guardrails protegen contra loops estructurales; esto resuelve los loops semánticos.

➡ Hooks como punto de extensión para mitigar limitaciones del modelo elegido
Strands permite engancharse al ciclo de ejecución del agente mediante hooks, interceptando eventos como una llamada a herramienta exitosa. En el caso de uso se implementó StopAfterHandoffHook, que fuerza al agente a detener su turno inmediatamente después de un handoff exitoso.

Este mecanismos sirve para cuando el prompt no alcanza para garantizar un comportamiento, evita que el modelo llame a la herramienta de handoff más de una vez por turno. Es una intervención determinista a nivel de código, sin depender del prompt engineering.

➡ Evaluaciones (Evals)
Existe el package strands-agents-evals que provee evaluadores reutilizables (por salida, por trayectoria de tool-calls, por trazas de ejecución, etc). En este caso de uso se implementaron dos evaluadores:
- Evaluación por Trayectoria (Trajectory Evaluation). En vez de exigir una secuencia exacta de handoffs, valida propiedades estructurales de la ejecución.

que el punto de entrada haya sido el correcto.
que haya participado una cantidad mínima de agentes únicos, y que los agentes indispensables (como mechanic_designer) hayan intervenido.

- Evaluación por Salida (Output Evaluation). Verifica que el GDD final contenga las palabras clave esperadas del dominio del juego (ej. "curse", "ingredient", "castle"), como chequeo básico de que el contenido generado es relevante a la premisa de origen.

⭐ Este enfoque refleja una diferencia clave frente a patrones más deterministas como agents-as-tools donde se puede evaluar contra un resultado esperado preciso (si se delegó al agente correcto); en cambio en Swarm hay que evaluar la forma del comportamiento, no una secuencia fija.

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-swarm

Como comenté más arriba, utilicé 2 opciones de modelos para la ejecución y analizar el comportamiento, pero podes usar solo una de ellas:

a. Docker Desktop, luego descargué la imagen de Ollama e instalé gemma4:e2b-it-qat (que pesa poco mas de 4GB). Todos los modelos gemma los podés encontrar aquí

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. Generé una api key de gemini de capa gratuita, desde aquí. Te permite usar el modelo Gemini 2.5 Flash.

El código del multiagente está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica:

strands-swarm/
├── README.md
├── requirements.txt
├── .env.example
├── .gitignore
│
├── src/
│   ├── __init__.py
│   ├── main.py                  # entry point, builds and runs the swarm
│   ├── config.py                # model provider config, timeouts, swarm limits
│   │
│   ├── agents/
│   │   ├── __init__.py
│   │   ├── _common.py           # shared model factory + prompt loader
│   │   ├── _hooks.py            # StopAfterHandoffHook
│   │   ├── mechanic_designer.py
│   │   ├── narrative_weaver.py
│   │   ├── level_architect.py
│   │   ├── lore_keeper.py
│   │   └── playtest_simulator.py
│   │
│   ├── prompts/
│   │   ├── mechanic_designer.md
│   │   ├── narrative_weaver.md
│   │   ├── level_architect.md
│   │   ├── lore_keeper.md
│   │   └── playtest_simulator.md
│   │
│   ├── swarm/
│   │   ├── __init__.py
│   │   └── build_swarm.py       # instantiates agents + configures Swarm (max_handoffs, etc.)
│   │
│   └── output/
│       ├── __init__.py
│       └── gdd_builder.py       # consolidates node_history/results into the final GDD
│
├── evals/
│   ├── __init__.py
│   ├── eval_cases.py            # EvalCase definitions (premise, expected agents, keywords)
│   └── run_evals.py             # trajectory + output evaluators over the swarm
│
├── examples/
│   └── example_premise.txt      # "cooking roguelike in a cursed castle"
│
├── outputs/
│   └── .gitkeep                 # generated GDDs land here after each run
│
├── logs/
│   └── .gitkeep                 # execution logs / handoff events
│
└── tests/
    ├── __init__.py
    └── test_swarm_flow.py

Ejecución Local

Una vez que tenemos el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 o la api key de gemini generada, pasamos armar el ambiente.
Los requerimientos que vamos a encontrar en requirements.txt:
strands-agents[ollama]
strands-agents[gemini]
strands-agents-evals
python-dotenv
pytest

pip install -r requirements.txt

En .env necesitamos:
OLLAMA_HOST=http://localhost:11434
MODEL_NAME=gemma4:e2b-it-qat
MODEL_PROVIDER=gemini # ollama
GEMINI_API_KEY=tuapikeyOpcional
GEMINI_MODEL_NAME=gemini-2.5-flash
LOG_LEVEL=INFO
MODEL_TEMPERATURE=0.5
MODEL_MAX_TOKENS=3500
MODEL_NUM_CTX=4096
MAX_HANDOFFS=12
MAX_ITERATIONS=12
EXECUTION_TIMEOUT=5000
NODE_TIMEOUT=1500
REPETITIVE_HANDOFF_DETECTION_WINDOW=6
REPETITIVE_HANDOFF_MIN_UNIQUE_AGENTS=3
ENTRY_POINT_AGENT=mechanic_designer
LOG_DIR=logs
OUTPUT_DIR=outputs

   cp .env.example .env

Las pruebas están organizadas en un enfoque de 2 niveles (tests/):
Nivel 1 (Rápidas y deterministas): Valida la estructura del swarm, la configuración de nodos/límites, la extracción de texto y la consolidación del GDD sin realizar llamadas reales al modelo. Usa cadenas simuladas como "Cooking roguelike in a cursed castle." o "Test Premise".

   python -m pytest

Nivel 2 (Test de integración end-to-end): Ejecuta el swarm completo contra el modelo real (Gemma4 en Ollama o Gemini). Está deshabilitado por default, pytest lo salta automáticamente, y se activa así en esta ejecución:

   RUN_INTEGRATION_TESTS=1 python -m pytest -m integration

📝 Nota: el comportamiento de activación/desactivación explícita para tests que dependen de un LLM real es una práctica común cuando se integran estos flujos a pipelines de CI/CD, donde ejecutar llamadas reales a un modelo en cada commit sería muy lento.

Procedemos a ejecutar el Swarm principal. Se puede ejecutar contra el modelo ollama local o vía api de gemini. Se configura en .env , tener en cuenta de cambiar MODEL_PROVIDER a "gemini" u "ollama". También recomiendo revisar valores default de src/config.py.

python -m src.main

El log de las llamadas entre agentes se visualiza en la carpeta logs/.
El resultado final del intercambio de mensajes entre los agentes del enjambre es el Game Design Document y se guarda en un documento markdown en la carpeta outputs/.

⭐ Te invito analizar la topología de handoffs después de las ejecuciones para entender si los agentes necesitan ajustes ya sea de prompts, hooks o parámetros de configuración.

Por último, hacemos una evaluación de pruebas sobre el agente real con el concepto de "Evals". Esto es importante para todos los agentes futuros que construyas, tomar la documentación de Strands y descubrir cómo y para qué tenemos que evaluar nuestros agentes.
Se desactiva el recolector de telemetría OpenTelemetry: OTEL_SDK_DISABLED=true para evitar cuelgues en un entorno local con el modelo en ollama (si internamente no alcanza un endpoint se cuelga indefinidamente).

export OTEL_SDK_DISABLED="true"
python -m evals.run_evals

📝 Nota-2: La explicación del código y paso a paso de la ejecución se encuentra detallado en el README.md en el repositorio de github.

Conclusiones

El patrón *Swarm * cede el control del flujo al propio modelo. Una corrida puede resolverse en 4 pasos o en 11, en un minuto o en dos horas, según decisiones que toman los agentes que intervienen.
Con un modelo chico experimenté loops de handoff, ping-pong entre agentes, transferencias narradas en texto en lugar de ejecutadas y para resolverlo tuve que agregar controles explícitos: límites de iteración, detección de repetición y un hook que corta el turno apenas el handoff se confirma.
La autonomía de un swarm no reemplaza los guardarraíles de ingeniería, los vuelve indispensables.

⭐ Y como trabajo futuro hay que pensar cómo implementar un proyecto multiagente Swarm productivo. El presente proyecto es educativo y sirve para entender el funcionamiento del patrón, pero es insuficiente para producción. AWS ya tiene un camino natural para eso: Amazon Bedrock AgentCore, un runtime serverless que ejecuta agentes Strands con aislamiento por sesión, observabilidad, memoria administrada y escalado automático. Queda para un próximo artículo explorar esa migración.

Recursos

Curso Fundamentos
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Swarm
Evals
Otros
Blog Writer Agent using Swarm Pattern
Building AI Agent Harnesses – Video Course
Detener alucinaciones de agentes de IA

Agents as Tools en Strands: orquestación jerárquica en local con Gemma 4 y Ollama

Laura Bolaños — Mon, 27 Jul 2026 16:33:25 +0000

Hace tiempo vengo consumiendo cursos de orquestación de agentes de distintos frameworks y me propuse navegar por los diferentes patrones de Strands Agents de complejidad media, ejecutados localmente (con la idea de encarar más adelante el deploy en AWS). Este artículo está dedicado a Agents-as-Tools, corriendo con Ollama en una laptop con solo 16GB de RAM 💻.

Introducción

Para que la prueba de concepto se pueda ejecutar localmente, utilicé Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker.

El caso de uso que tomé para desarrollar el patrón es la automatización del soporte básico de TI:
🛠 Se recibe un ticket de soporte y se determina si es un ticket de facturación, técnico o seguridad. Luego se envía al agente especializado para que lo resuelva.

Conceptos claves

➡ Agents As Tools es un patrón de orquestación multiagente que como se describe en la documentación es jerárquico (hub and spooke), donde un orquestador delega tareas a agentes especializados que tienen diferentes tools para resolver. El orquestador y cada agente poseen contexto aislado, no se contaminan entre sí.

Para clarificar el funcionamiento: al delegar, hay dos agents loops anidados, no uno compartido: el orquestador no "pausa" su razonamiento en espera del especialista, simplemente visualiza una tool call que devuelve texto, por detrás, esa tool call disparó un loop completo e independiente que ya terminó antes de volver.

Orchestrator loop
   └─ calls billing_agent(query) → triggers a new, isolated loop
         └─ Billing loop: check_invoice_status → process_refund → final response
   ← receives only the final string (doesn't see the internal tool calls)
   └─ continues its own loop: delegates to another specialist or replies to the user

➡ @tool no distingue entre operación simple o integración vía APis y agente completo , el patrón Agents-as-Tools explota que un agente cumpla la misma interfaz que una tool (recibe input, devuelve output), para que se pueda componer recursivamente. Es lo que permite anidar agentes dentro de agentes sin que el nivel superior necesite saber la complejidad interna del nivel inferior.

⭐ La descripción (docstring) de cada función @tool no es un comentario decorativo: es el input que el LLM orquestador lee en tiempo de ejecución para decidir a qué especialista delegar. Distinto del parámetro description= del propio Agent, que es metadata informativa y no interviene en el routing.

➡ Memoria del orquestador (ConversationManager). Utilicé el concepto de compresión al hacer que el agente recuerde los últimos 10 mensajes o tickets de la sesión para mantener contexto entre interacciones consecutivas con SlidingWindowConversationManager(window_size=10)
Mantiene los mensajes en una lista dentro del objeto Python en RAM durante la ejecución del proceso.

➡ Hook de dominio (SteeringHandler). Implementa el "HookProvider" de Strands, en este caso de uso fuerza el orden de pasos del protocolo de respuesta ante incidentes de Seguridad. Si el LLM intenta llamar por ejemplo a revoke_access_token sin haber auditado primero la IP, el hook lo bloquea con event.cancel_tool antes de que la función se ejecute. El framework impone la lógica de negocio determinista, sin depender del criterio del modelo. Describe con precisión los tres eventos BeforeInvocationEvent, AfterToolCallEvent, BeforeToolCallEvent

Los hooks sirven en general para:

Prevenir loops infinitos o excesivos de tool calls (control de costos/tokens)
Guardrails de seguridad/negocio (ej. no permitir más de n transacciones, n consultas a una API con rate limit, etc.)
Es el mecanismo estándar de Strands para inyectar lógica de control sin modificar el core del agent loop.

➡ Evaluaciones (Evals): evaluación de comportamiento del agente (con Contains, no asserts tradicionales).

Algunas consideraciones que tomé para poder ejecutar los evals sin que se cuelguen en un entorno local con el modelo en ollama: Desactivé OTLP de Opentelemetry, este si internamente no alcanza un endpoint (localhost:4318) se cuelga indefinidamente.

En el caso de uso del repositorio se hacen evaluaciones deterministas ya que se utiliza solo un LLM, no se abarcan todas las evaluaciones pero sí dos importantes descritas debajo.

Output Evaluation. Evalúa el resultado final (el texto que recibe el usuario), sin importar el camino interno que tomó el agente para llegar ahí. Es un chequeo determinista de keyword matching: la respuesta debe contener ciertas palabras clave esperadas (INV-1002, USR-884, etc.).

Trajectory Evaluation. No evalúa qué respondió el agente, sino cómo llegó ahí, qué tools/sub-agentes invocó durante su razonamiento. En el código, extract_called_tools() inspecciona agent.messages buscando bloques toolUse, y evaluate_trajectory() verifica que el sub-agente esperado (ej. BillingAgent) haya sido efectivamente el delegado. Para la ejecución en entorno local con Ollama, la función extract_called_tools extrae directamente los nombres de las herramientas en agent.messages y comprueba en milisegundos si se invocó a case.expected_agent, sin necesidad de instanciar un modelo juez adicional ni hacer peticiones extra a Bedrock/Ollama (sin cuelgues asíncronos).

⭐ PASS / FAIL a nivel dimensión, en el output: cada EvalCase se marca como aprobado (case_passed) solo si ambas dimensiones pasan (traj_eval.test_pass and out_eval.test_pass). Un agente puede delegar al especialista correcto (trayectoria OK) pero responder sin las keywords esperadas (output FAIL), y el caso se marca como fallido igual. Una sola dimensión de evaluación no alcanza: el agente puede "hacer lo correcto" pero "comunicarlo mal", o viceversa.

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-agents-as-tools

Para alojar el LLM utilicé Docker Desktop, luego descargué la imagen de Ollama e instalé gemma4:e2b-it-qat (que pesa poco mas de 4GB). Todos los modelos gemma los podés encontrar aquí pero este en particular funciona OK en una laptop con 16GB de RAM.

Como condición necesaria asegurate de dar memoria suficiente a Docker.

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama
# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat
# Test that the model responds
docker exec -it ollama ollama run gemma4:e2b-it-qat
# Verify that the model is running
docker exec -it ollama ollama ps

Importante! Testear el modelo gemma 4 en la terminal haciendo alguna pregunta para corroborar que responda.

El código del multiagente está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica:

strands-agents-as-tools
├── README.md
├── requirements.txt
├── .env.example
├── .gitignore
│
├── src/
│   ├── __init__.py
│   ├── main.py
│   ├── config.py
│   │
│   ├── agents/
│   │   ├── __init__.py
│   │   ├── orchestrator.py
│   │   ├── billing_agent.py
│   │   ├── technical_agent.py
│   │   └── security_agent.py
│   │
│   ├── tools/
│   │   ├── __init__.py
│   │   ├── billing_tools.py
│   │   ├── technical_tools.py
│   │   └── security_tools.py
│   │
│   └── hooks/
│       ├── __init__.py
│       └── security_verification_hook.py   # Domain SteeringHandler
│
├── examples/
│   └── sample_tickets.py
│
├── evals/
│   ├── __init__.py
│   ├── eval_cases.py                 # Cases with inputs, expected agent and keywords
│   └── run_evals.py                  # Dual evaluator: Trajectory (Tool Call) + Output (Keywords)
│
└── tests/
    └── test_agents.py                # Unit tests for tools (no LLM)

Ejecución local

Una vez que tenemos el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 ejecutando, pasamos armar el ambiente.

Los requerimientos que vamos a encontrar en requirements.txt:
strands-agents
strands-agents-evals
ollama
python-dotenv
pytest

pip install -r requirements.txt

En el .env vamos a necesitar:
OLLAMA_HOST=http://localhost:11434
MODEL_NAME=gemma4:e2b-it-qat
LOG_LEVEL=INFO

cp .env.example .env

Los test son pruebas unitarias deterministas (tests/). Permite validar rápidamente y de forma aislada la lógica de código puro de las herramientas (tools) de negocio (facturación, soporte técnico y seguridad), sin requerir inferencia de LLM. Garantizan que las funciones auxiliares retornen los estados y formatos esperados antes de ser expuestas como capacidades @tool al sistema multiagente.

python -m pytest tests/

Procedemos a ejecutar el flujo principal demostrativo donde se ve al orquestador delegar tickets a los especialistas procesados por Ollama. Puede ser algo lento debido al modelo de ollama elegido pero finalmente termina el flujo con los ejemplos de tickets. Se utilizan ejemplos de soportes dentro de main con from examples.sample_tickets import SAMPLE_TICKETS ...te invito a cambiarlos!

python -m src.main

Por último, hacemos una evaluación de pruebas de calidad y precisión ejecutadas sobre el agente real con el concepto de "Evals". Esto es importante para todos los agentes futuros que construyas: hay que tomar la documentación de Strands y descubrir cómo y para qué tenemos que evaluar nuestros agentes.

También recomiendo establecer OTEL_SDK_DISABLED=true para desactivar el recolector de telemetría OpenTelemetry (explicado en Conceptos Claves)

export OTEL_SDK_DISABLED="true"
python -m evals.run_evals

Este último script ejecuta dos metodologías de evaluación según las especificaciones de Strands Agents: Output / Keyword Evaluation y Tool-Call Trajectory Evaluation (explicado en Conceptos Claves)

📝 Nota: Todo la explicación del código del repositorio y paso a paso de la ejecución se encuentra en el README.md

Conclusiones

Implementar Agents-as-Tools con un modelo local vía Ollama fue una buena forma de entender el patrón de orquestación sin gastar, pero también descubrí que modelos chicos como gemma4:e2b-it-qat pueden ser inconsistentes en su razonamiento (llamadas duplicadas a una misma tool, dudas antes de delegar) a diferencia de un modelo más grande (Bedrock/Claude/GPT-4) que probablemente sea más preciso. Esto no invalida el patrón, todo lo contrario: reafirma por qué los guardrails deterministas (el hook de seguridad) y las evaluaciones automáticas es la forma de detectar el comportamiento errático antes de que llegue a producción.

Limitaciones del ejemplo

Este repositorio es educativo, y tiene varias simplificaciones:

Tools hardcodeadas con datos mock: check_invoice_status, check_system_status, audit_ip_address, etc. devuelven datos fijos en el código, no consultan ningún sistema real.
Un solo LLM local: no se probó el comportamiento con otros modelos para comparar consistencia de routing/tool-calling entre modelos de distinto tamaño.
Evaluación: solo se cubrieron Output y Trajectory de forma determinista; no se probó chaos testing, LLM-as-judge, ni simulación multi-turno (mirar la documentación oficial).

Pensando en este mismo Multiagente productivo 🤯

Conectar tools a APIs/sistemas reales: reemplazar los mocks por llamadas a una API de facturación real, un endpoint de status de infraestructura (ej. AWS CloudWatch, Datadog), y un servicio real de gestión de identidad (ej. IAM, Okta) para revocación de tokens. Varios de estos ya existen como servidores MCP mantenidos por la comunidad/AWS (conectarlos vía MCPClient sería más rápido que escribir cada tool a mano).
Persistencia real de sesión: en este ejemplo cada ticket es stateless entre ejecuciones de main.py; sumar un SessionManager(FileSessionManagero DynamoDBSessionManager) para simular conversaciones multi-turno reales de un mismo usuario.
Comparar modelos: correr el mismo test suite contra un modelo de Bedrock o la API de Anthropic, y comparar tasa de errores de routing/tool-calling contra el modelo local, cuantificar el trade-off costo/latencia vs. confiabilidad.
Chaos testing: simular caídas de las APIs reales (una vez conectadas) con ChaosPlugin, para validar que el agente degrada con gracia en vez de alucinar una respuesta.

⭐ Migrar a Bedrock AgentCore: envolver el orquestador con BedrockAgentCoreApppara exponerlo vía el runtime administrado de AWS, adicionando AgentCoreMemorySessionManagerpara memoria semántica de usuario (facts/preferences) en vez de solo SlidingWindowConversationManager

Recursos

Cursos Fundamentos
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Agents as Tools
Trajectory Evaluator
Artículos de Builders y AWS Developer Advocate
AWS Strands Agents: simplifica la creación de agentes de IA
Detener alucinaciones de agentes de IA

Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 2

Laura Bolaños — Thu, 04 Jun 2026 13:41:05 +0000

Segunda parte de las notas de examen. La idea es que identifiques los principales temas para el examen de certificación y conocer algunos tips de estudio para alcanzar con éxito tu meta 🎓

⬅ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Temas que son claves conocer para el examen - Segunda Parte

AWS Config

Es prioritario revisar todas sus casos de uso y su integración con acciones de remediación con SSM y sus runbook. La remediación puede ser manual o automática.

La integración importante es con EventBridge para realizar una acción. Algo a saber es que los avisos a un equipo de soporte se hacen a través de SNS.
Data Aggregation for AWS Config (Multi-Account - Multi-Region) ➡ recopila datos de configuración y cumplimiento de varias cuentas y varias regiones de AWS. Una organización en AWS Organizations y todas las cuentas de esa organización que tengan AWS Config habilitado.
Reglas de configuración comunes en AWS Config:

Rule	Qué chequea
`cloudtrail-enabled`	CloudTrail habilitado en la cuenta
`mfa-enabled-for-iam-console-access`	Los usuarios de IAM con acceso a la consola tienen MFA habilitado
`s3-bucket-public-read-prohibited`	Los buckets de S3 no permiten acceso de lectura pública
`encrypted-volumes`	Los volúmenes de EBS están encriptados
`rds-storage-encrypted`	Las instancias RDS tienen encriptación del storage habilitada
`iam-password-policy`	La política de contraseñas cumple con los requisitos especificados
`restricted-ssh`	Los Security Groups no permiten acceso SSH sin restricciones (puerto 22)
`root-account-mfa-enabled`	La cuenta root tiene MFA habilitado
`vpc-flow-logs-enabled`	VPC Flow Logs está activado
`cloud-trail-encryption-enabled`	Los logs de CloudTrail están encriptados con KMS
`s3-bucket-ssl-requests-only`	S3 solo acepta requests HTTPS
`ec2-instances-in-vpc`	Las instancias EC2 están dentro de una VPC
`access-keys-rotated`	Las access keys de IAM se rotan dentro de N días

Control Tower

Relacionado con casos de uso de Organization ➡ Proporciona una landing zone para múltiples cuentas. Automatiza la configuración de AWS Organizations, la venta de cuentas, las medidas de seguridad (controles preventivos y de detección) y un registro de auditoría centralizado.

Security Hub - WAF - Detective - Inspector - GuardDuty

Es útil realizar cuadro comparativo con los servicios Detective, Inspector y GuardDuty para visualizar sus diferencias y en qué casos de uso son más adecuados. La mayoría se utilizan para controles de detección.

Security Hub: gestiona la postura o posición de seguridad de una Organización. Automatiza las comprobaciones de mejores prácticas y agrega alertas de Seguridad.
WAF: los casos de uso referidos son sencillos de identificar, detección de ataques sql injection - bloqueo de ip de países-rate limiting por IP, etc. Se gestiona mediante Web ACLs con reglas propias o AWS Managed Rules (reglas preconfiguradas por AWS)
Inspector: Evalúa automáticamente vulnerabilidades en EC2, ECR y funciones Lambda ➡ prevención y detección proactiva.
Detective: simplifica el proceso de analizar, investigar e identificar la causa raíz de los hallazgos de seguridad o actividades sospechosas en las cuentas de AWS. Recopila registros de CloudTrail (frase clave es log de APIs), VPC Flows, GuardDuty, entre otros ➡ Actúa en el post-incidente.
GuardDuty: Detección de amenazas continua mediante análisis de CloudTrail, VPC Flow Logs y DNS logs. Usa ML para identificar comportamiento anómalo (ej: instancia EC2 haciendo crypto mining, credenciales filtradas usadas desde IP sospechosa). Es el detector en tiempo real, genera findings que pueden disparar acciones en EventBridge → Lambda/SNS.

Conceptos básicos de Networking

NACL: Actúan a nivel de subnet y no tienen estado. Hay que agregar reglas de entrada y de salida. Las reglas se evalúan de manera ascendente. Es el primer mecanismo de defensa a nivel subred, útil para bloquear IPs específicas. Ejemplo de resolución de problema: una instancia EC2 (en una private subnet) no tiene salida a internet? ➡ Las reglas de entrada y salida deben permitir el tráfico (incluidos los puertos de retorno efímeros 1024–65535).
Security groups: Actúan a nivel de instancia o servicio. Tienen estado, todo lo que se permite entrar- se permite salir (salvo que indiques lo contrario en las reglas de salida).
- Resolución de conexiones vía SSH o RDP a instancias EC2. Qué revisar? En principio las reglas de entrada del Security Group a los puertos correspondientes.
Nat Gateway: es escalable mejor que Instance Nat Gateway. Asociada a una subnet pública. Solo para IPV4. Asegurar que la Private subnet route table debe tener
Egress-Only Internet Gateway (EIGW): permite que los recursos en una subred privada se comuniquen con el exterior a través de IPv6

VPC FlowLogs

VPC > Your VPCs > Flow logs > Create Flow Logs (se necesita un rol para escribir en CloudWatch). Monitorea todo el trafico de la VPC determinada aparece en CloudWatch > Logs > Log Management .
Otros destinos de logs son S3 y Kinesis Data Firehose. Se puede realizar consultas sql mediante Athena tomando como fuente S3.
Conocer el formato de los registros Default VPC Flow Logs y Custom VPC Flow Log Format. Cómo configurar y qué soportes permite resolver.

Ejemplo cuando falta una regla en Nacl o Security Group para permitir una conexión:

2 123456789012 eni-abc123 10.0.1.4 10.0.2.5 43234 443 6 12 1400 1624387215 1624387275 ACCEPT OK

2 123456789012 eni-abc123 172.31.16.139 172.31.16.21 80 42333 6 24 2456 1624387215 1624387275 REJECT OK

Route 53

Hosted zone ➡ pública y privada. Comprender el concepto de casos de uso: El cliente externo consulta la zona pública de Route 53 y llega a la versión pública de la app y el cliente interno dentro de la VPC consulta la zona privada de Route 53 y llega a la versión interna de la app ➡ ambos pueden tener el mismo nombre laub.com pero devuelven destinos diferentes de acuerdo de donde se lo consulte.
Es primordial conocer los tipos de registros y casos de usos:

Tipo	Qué contiene	Uso
`A`	IPv4	www.laub.com → 52.10.1.100
`AAAA`	IPv6	www.laub.com → 2001:db8::1
`CNAME`	Otro hostname	www → otro.dominio.com
`Alias`	Recurso AWS	laub.com → mi-alb.us-east-1.elb.amazonaws.com
`NS`	Name servers de la zona	Delegación de subdominios
`SOA`	Metadatos de la zona	Se crea automático
`MX`	Servidor de correo	laub.com → mail.empresa.com
`TXT`	Texto libre	Verificación de dominio, SPF
`SRV`	Servicio + puerto	Usado por algunos protocolos
`PTR`	DNS inverso	IP → hostname

Route 53 Resolver: define cómo y hacia dónde se hacen las consultas DNS.
- En esta feature se da la relación de entornos híbridos, DNS de on-premises resuelto por Route 53 (Outbound endpoint) o un DNS en AWS (en VPC) que lo resuelve on-premises (Inbound endpoint).
Route 53 routing policies, hay preguntas de examen sobre estas features relacionados con estrategias de deployment o failover:

Política	Descripción	Health Checks	Caso de Uso
Simple	Un único servidor. Sin lógica ni failover.	No soporta	Un solo recurso sin redundancia
Weighted	Distribución de tráfico por pesos.	Soportado — si falla un destino su peso es ignorado	Deployment canary, A/B testing
Latency	Dirige el tráfico al recurso con menor latencia.	Soportado	Usuarios globales que necesitan baja latencia
Geolocation	Enruta según la ubicación geográfica del origen de la consulta DNS (continente, país o estado).	Soportado	Contenido regionalizado, cumplimiento normativo
Geoproximity	Enruta según ubicación geográfica de los recursos con valor de sesgo opcional. Requiere Route 53 Traffic Flow.	Soportado	Balanceo geográfico con control fino de fronteras
Failover	Enruta a recurso principal; si falla va al secundario. Recursos en VPC privada requieren CloudWatch Alarm como intermediario.	Requerido	Alta disponibilidad activo-pasivo
IP-Based	Enruta según la IP del remitente de la consulta DNS.	Soportado	Segmentación por ISP o rango de IPs corporativas
Multivalue Answer	Devuelve hasta 8 registros saludables al azar.	Soportado	Distribución simple sin necesidad de ELB
Cross Account	La zona padre delega un subdominio creando registros NS que apuntan a la zona hija en otra cuenta.	—	Gestión de DNS entre múltiples cuentas AWS

Query Logging: Registra todas las consultas DNS está disponible para zonas públicas., con esto podemos resolver problemas. Auditar consultas DNS de una zona privada ➡ no es Route 53 query logging, es Route 53 Resolver Query Logs (servicio diferente).
Tipos de Health checks: Es un concepto básico a retener ➡Endpoint health check, Calculated health check y CloudWatch alarm health check.

Cálculo de CIDR para un Subnet

En una VPC no se puede superponer el bloque de direcciones cidr de sus subnet ➡ ejemplo encontrar el tamaño mínimo de la subred que tenga 30 direcciones IP disponibles.

Total de direcciones IP disponibles = 2^(32-X) – 5 (Reservadas por AWS)

Donde X es la notación CIDR.

Para el bloque CIDR 192.168.1.0/26.

Total de direcciones IP disponibles = 2^(32-26) – 5 = 59 direcciones IP.

AWS Global Accelerator

Si enfrentas alguna pregunta que necesitas tiempos de milisegundos con direcciones IP anycast estáticas ➡ la respuesta seguramente es Global Accelerator.

Frases claves para este servicio: aceleración del tráfico TCP/UDP.

VPC Peering - Transit Gateway

VPC peering: Conocer las limitaciones de ➡ hasta 10 interconexiones de VPC es potable. No hay transitividad en las conexiones. Es conveniente realizar laboratorio para entender cómo se configuran las Route Tables. Tener presente que se puede realizar conexiones entre diferentes regiones y cuentas.
- Solucionar conexion de VPC Peering entre dos instancias de EC2 en dos VPC diferentes. Se configuró correctamente el VPC peering entre ambas. Una instancia A puede hacer ping a instancia B. Pero la instancia B no puede hacer ping a la instancia A ➡ Posiblemente para solucionar este problema es necesario actualizar el grupo de seguridad de la instancia A para permitir el tráfico ICMP entrante.
Transit Gateway: actúa como una hub de redes eliminando la necesidad de complejas redes de interconexión. A diferencia de VPC peering tiene ruteo transitivo. Importante! conocer el concepto de adjuntar una VPC (Attach a VPC).
- Soporta multicast.
- Se puede usar con VPN y Direct Connect como hub central, simplificando arquitecturas híbridas.
- TGW Route Tables permiten segmentar el tráfico entre VPCs conectadas.Ejemplo ➡ aislar producción de desarrollo.

Cloudfront

Comprender cómo configurar los diferentes orígenes. El más sencillo y natural que conocemos, si has rendido alguna certificación, es S3. Pero vas a tener que preparar ELB y el caso especial de EC2:

Origin Type	Description	Clave para el examen
Amazon S3	Contenido estático	OAC reemplaza OAI (legacy). Sin OAC, el bucket puede quedar público
Application Load Balancer	Contenido dinámico	El ELB debe ser público. CloudFront no puede llegar a un ALB interno. Usá security group del ALB restringido a los IPs de CloudFront para que el tráfico solo entre por CloudFront
EC2 instance	Servidores web custom	La instancia debe ser pública y con security group que permita IPs de CloudFront
API Gateway	REST o HTTP APIs	Podés deshabilitar el endpoint público de APIGW y forzar acceso solo vía CloudFront
Custom HTTP origin	Servidores on-premise u otros	Requiere HTTPS con certificado válido si usás HTTPS entre CloudFront y el origen

Qué pasa cuando hay pocos cache hit (Cache Hit bajo)?
- Revisar el TTL , si es muy bajo, los objetos expiran rápido y van al origen frecuentemente.
- Revisar la Cache Key , si incluye headers, cookies o query strings innecesarios, fragmenta el caché y baja el hit rate. La solución es usar Cache Policies para controlar qué forma parte de la cache key.
Qué hacer cuando lo cacheado quedó antiguo, cómo resolver inmediatamente sin esperar que expire el TTL?
- Invalidación de caché (CreateInvalidation) hace que CloudFront descarte el objeto antes del TTL.
- Alternativa más eficiente para el examen: versionado de archivos en el nombre (app.v2.js), evita invalidaciones y es la práctica recomendada por AWS.
Behavior (comportamiento): analizar las variantes. Es útil realizar laboratorios.
- Permiten definir reglas distintas por path pattern (/api/*, /images/*, /static/*).
- Cada behavior puede tener su propio origen, TTL, política de caché y restricciones de acceso.
- Caso de uso común: /api/* apunta a ALB (dinámico, sin caché) y /* apunta a S3 (estático, con caché larga).

VPC Endpoints

Es clave conocer los tipos de punto final para aplicar seguridad a la conexión de servicios aws (sin pasar por internet).

Gateway Endpoint : Es sin costo, solo para conectar con S3, DynamoDB. Importante para sortear preguntas, solo tiene utilidad dentro de una VPC, no tiene la capacidad de acceso externo. También admite políticas de punto final para controlar el acceso.
Interface Endpoint (PrivateLink): Tiene costo. Crea una ENI con IP privada en tu VPC para conectarse a servicios de AWS (y servicios de terceros). Permite el acceso desde on-premise si existe conectividad previa (VPN/Direct Connect). Admite políticas de punto final para controlar qué entidades principales pueden usarlo.
- Al crearlo AWS genera DNS privados para el servicio, si Enable Private DNS está activado, las llamadas al endpoint público se resuelven automáticamente a la ENI privada. Resolución de problemas: si el tráfico sigue saliendo a internet a pesar de tener un Interface Endpoint → verificar que Enable Private DNS esté activado.

⬅ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Laura Bolaños — Thu, 04 Jun 2026 03:00:00 +0000

Primera parte de los apuntes del examen. La idea es que identifiques los principales temas para el examen de certificación y conocer algunos tips de estudio para alcanzar con éxito tu meta 🎓

Características generales

La complejidad es de nivel medio. A mi criterio lo más complejo son las diferentes formas de soporte vía SSM.

Consta de 5 dominios y toda la información detallada la podemos encontrar aquí.

Solo se puede rendir en inglés, con lo cual es prioritario estudiar con apuntes, entrenamiento de preguntas y laboratorios en este idioma. Se aprueba con 720 puntos.

Es una certificación que te invita a conocer en profundidad las arquitecturas mas tradicionales de AWS , la resolución de problemas en producción y el mantenimiento evolutivo al momento de actualizar infraestructura para la continuidad del negocio.

⭐ Se superponen varios temas con Solutions Architect Associate y Developer Associate. Si ya rendiste alguna, te va a resultar familiar un % del contenido.

Método de estudio

Estudiar para una certificación no tiene fórmulas mágicas, se necesita apartar tiempo de nuestro dia y constancia. Tener en claro que nos permite profundizar en conceptos o prácticas que tal vez no vemos en el trabajo diario...esa será nuestras motivación.

Tu punto de partida debe ser la guia de examen siempre.
Conviene hacer la preparación de examen de SkillBuilder, te da un paneo general de temas y asi podes identificar las brechas de conocimientos en las que debes profundizar.
Mi forma favorita de estudiar es hacer una especie de RAG con NotebookLM con la documentación oficial de AWS pertinente (aws permite bajar los pdf).
La novedad es que hay mcp de AWS disponibles referidos a la documentación. Por ejemplo, utilizando los temas de la guia de examen como contexto, se puede generar apuntes. Utilice este mcp , pero tambien hay uno que no he probado que es mucho más amplio y contiene temas de arquitectura aquí

⭐ Resumen de los Dominios de examen generado por kiro con el mcp de la documentación de AWS.

⭐ Utilicé Tutorials Dojo como banco de preguntas para practicar, pero mi percepción es que las preguntas en el examen eran más difíciles.

Arquitecturas importantes

Te invito a pensar en sus variantes para lograr alta disponibilidad, escalabilidad y resiliencia. Los temas de networking son importantes en el examen: configuración de VPC, subnet, tablas de ruteo, Security Groups entre otros, especialmente troubleshooting de conectividad.

High Available (Route53)

High Available and Scalable Web App (Cloudfront - ALB)

Worker Fleet - SQS

VPC Peering

Transit Gateway

Cloudfront - OAC

Config

Temas que son claves conocer para el examen

Las preguntas de examen se centran en la resolución de problemas con menos carga operativa y la elección de arquitecturas más lógica.

CloudWatch

Familiarizarse con las features de la consola de CloudWatch porque vas a enfrentarte a varias preguntas sobre la administración de logs.

Cómo visualizó los logs comunes? **CloudWatch > Logs > Log Management. Aquí se encuentran todos los "Logs Groups" como aws/lambda/..., aws/apigateway/...,ecs/..., ec2..
Cómo creo un Log Group? Desde la CLI de AWS. Cómo inserto Log en CloudWatch? Desde la Api con Create
CloudWatch metrics, tener en claro las diferentes tipos y circunstancias a utilizar. Cada métrica tiene un nombre, namespace y dimensiones (opcional).
- Basic Monitoring (5 min, default).
- Detailed Monitoring (1 min, se habilita manualmente)
- High Resolution para métricas custom (hasta 1 segundo).
Metric Filters ➡ Definís un patrón de búsqueda sobre un Log Group y CloudWatch genera una métrica custom a partir de las coincidencias.
- El caso de uso típico a resolver: detectar cantidad de errores 500 en logs de una aplicación. Metric Filter sobre el Log Group (métrica custom) → alarma de CloudWatch sobre esa métrica y acción de remediación automática.
CloudWatch Agent ➡ es uno de las features más importantes que nos va a permitir enviar Logs a CloudWatch desde las instancias de EC2, server onprem, EKS cluster (recopilar métricas y registros a nivel de nodo de los contenedores).
- Comprender cómo se configura y se modifica el archivo de configuración del agente (sin reiniciar las instancias de EC2): amazon-cloudwatch-agent-ctl command with the fetch-config
CloudWatch Logs Insights: sintaxis y comandos para el análisis de logs ➡ fields , display , filter , stats , sort , limit ...

Escalabilidad y Elasticidad

Administración de Fleet de EC2: Estrategias para continuar procesamiento de trabajos minimizando las interrupciones de form costo-efectiva ➡ capacity-optimized para minimizar interrupciones o price-capacity-optimized para balance entre costo y disponibilidad. (Combinando instancias Spot y On-Demand con el parámetro OnDemandBaseCapacity se especifica cuántas instancias base On-Demand y el resto se cubre con Spot).
EC2 Auto Scaling Group: puede aparecer pregunta puntual sobre administrar ASG, pero por lo general no aparece como concepto aislado sino asociado a un balanceador de carga (ALB/NLB) y en arquitecturas multi-región con Route 53.
- Capacidad mínima, máxima y deseada.
- Definición de Launch template, cómo aplicar una nueva configuración a todas las instancias del ASG sin downtime? ➡ Cuando se actualiza un Launch Template, las instancias existentes no se reemplazan automáticamente, siguen ejecutando la versión anterior. Las nuevas instancias que escalen usarán la versión nueva. Para forzar el reemplazo se usa Instance Refresh.
- Distribución en AZ.
- Health Checks de EC2 o si health checks desde un ELB determina que las instancias que no están en buen estado se reemplazan automáticamente. Profundizar en este punto
- Es clave entender las siguientes políticas de escalamiento para responder sobre mejora de performance.

Tipo de Política	Cómo Funciona	Caso de Uso
Target Tracking	Mantiene una métrica en un valor objetivo (ej: CPU al 50%). AWS gestiona las alarmas de CloudWatch automáticamente.	Aplicaciones web generales donde querés simplicidad sin configuración compleja.
Step Scaling	Ajusta la capacidad en pasos según cuánto se desvía una métrica del umbral. Permite diferentes tamaños de paso según la magnitud.	Workloads con picos abruptos donde necesitás agregar más instancias cuanto mayor es el desvío.
Simple Scaling	Agrega o quita una cantidad fija de instancias cuando se dispara una alarma. Incluye período de cooldown antes de la siguiente acción.	Legacy, no recomendada. Target Tracking la reemplaza en casi todos los casos.
Scheduled Scaling	Escala la capacidad en un horario específico usando expresiones cron.	Cargas predecibles: horario comercial, cierre de mes, campañas programadas.
Predictive Scaling	Usa ML para predecir la carga futura y ajusta la capacidad de forma proactiva.	E-commerce con patrones cíclicos (ej: picos semanales o estacionales recurrentes).

LifeCycle Hooks: En Auto Scaling Group para analizar errores de las instancias antes de que se finalicen para ser reemplazadas se puede pausar la finalización de la instancia. También, este mecanismo, al inicio permite acciones como instalación de software. La instancia permanece en estado Pendiente
Conocer el término Warmup, define un tiempo de calentamiento de la instancia. Es el período posterior al lanzamiento de una nueva instancia antes de que sus métricas contribuyan a la métrica de escalado. Evita el escalado por falsas métricas hasta que la instancia se estabilice.
Application AutoScaling (no confundir con ASG):
- ECS, cantidad de task.
- Lambda. Entender la diferencia entre Provisioned Concurrency y Reserved Concurrency. La primera es la que permite "autoescalar" ➡ muy probable que te planteen una situación con Lambda para resolver temas de concurrencia.
- Aurora réplicas. Permite liberar la instancia del cluster, teniendo réplicas de lectura (no de escrituras).
- DynamoDB, puede crear una política de AutoScaling. Luego DynamoDB pública métricas de capacidad consumida CloudWatch ➡ La alarma de CloudWatch invoca a AutoScaling de aplicaciones para evaluar la política de escalado, emite una solicitud UpdateTable para ajustar el rendimiento aprovisionado de la tabla.

ELB - High availability

Con el siguiente cuadro podés responder varios casos de uso:

Load Balancer	Capa	Protocolos	Características Clave
Application Load Balancer (ALB)	Layer 7 (HTTP/HTTPS)	HTTP, HTTPS, gRPC, WebSocket	Enrutamiento basado en contenido (path, host, headers, query strings), targets Lambda, integración con WAF, sticky sessions.
Network Load Balancer (NLB)	Layer 4 (TCP/UDP)	TCP, UDP, TLS	Ultra-baja latencia, IP estática por AZ, soporte Elastic IP, preserva la IP de origen, maneja millones de requests/segundo.
Gateway Load Balancer (GWLB)	Layer 3 (IP)	IP	Despliega, escala y gestiona appliances virtuales de terceros (firewalls, IDS/IPS). Usa protocolo GENEVE.
Classic Load Balancer (CLB)	Layer 4 y 7	HTTP, HTTPS, TCP, SSL	Legacy; no recomendado para nuevos despliegues.

Dónde encontrar información detallada como la dirección IP del cliente, latencias, rutas de solicitud y respuestas del servidor? ➡ La respuesta es habilitar los ELB Access Logs y almacenarlos en un bucket de S3.
Problemas de conectividad. Una web inalcanzable con grupos de seguridad correctos ➡ La solución es permitir puertos efímeros (1024-65535) en la Network ACL (NACL), porque ELB utiliza este rango para comunicarse con los clientes.
Sticky Sessions: Caso de uso donde una sola instancia EC2 tiene un uso de CPU del 95% mientras las otras están al 10% ➡ ajustar la expiración de las cookies de la aplicación para rebalancear la carga.
Conocer Cross-Zone Load Balancing para asegurar una distribución uniforme del tráfico en todas las zonas de disponibilidad habilitadas.
Integración de ALB con WAF pero no así con NLB.

Placement Group

Cluster: Agrupa las instancias muy cerca unas de otras en una única zona de disponibilidad. Proporciona una red de baja latencia y alto ancho de banda (hasta 100 Gbps con EFA). Casos de uso ➡ HPC, Machine Learning,

Partition: Divide las instancias en particiones lógicas, cada una en racks separados con alimentación y red independientes. Hasta 7 particiones por zona de disponibilidad. Caso de uso ➡ base de datos Distribuidas: Cassandra,HDFS, Kafka

Spread: Cada instancia se ubica en un hardware distinto (racks separados). Máximo 7 instancias por zona de disponibilidad por grupo. Caso de Uso ➡ grupos de instancias que deben aislarse entre sí en hardware separado.

Estrategias de Disaster Recovery

Conceptos principales RTO (Recovery Time Objective), RPO (Recovery Point Objective) ➡ mientras mas pequeños mas costosos. Este enlace tiene información detallada que vale la pena revisar de las siguientes estrategias:

Estrategia	RTO	RPO	Costo	Caso de Uso
Backup and Restore	Horas	Horas	$	Dev/test, no-crítico
Pilot Light	Varios minutos	Minutos	$$	Apps internas, criticidad moderada
Warm Standby	Minutos	Segundos–minutos	$$$	Apps de negocio críticas
Multi-Site Active/Active	Segundos	Segundos	$$$$	Crítico, zero-downtime

Clases de S3 - Versiones - Eventos

Hacer un pequeño cuadro comparativo de versiones de S3 y que casos de uso se utiliza para cada uno. Ejemplo ➡ cuando los patrones de acceso son impredecibles o cambiantes y no querés gestionar manualmente las políticas de ciclo de vida: S3 Intelligent-Tiering
S3 Object Lock ➡ cuando se usa Governance mode o Compliance mode.
Activación de versionado. Relación con CRR (Cross Region Replication) y SRR (replicación en misma región pero diferentes cuentas).
- Resolución de problemas de latencia o errores cuando el S3 es origen de CloudFront: Si hay millones de versiones y las operaciones de listado o ciclo de vida se vuelven pesadas ➡ Configurar S3 Lifecycle Policies para expirar versiones antiguas automáticamente, usando NoncurrentVersionExpiration para eliminar versiones no actuales después de cierta cantidad de días.
Event notifications para creación, eliminación, update de objetos. Integración con Lambda, SNS y Eventbridge. EventBridge permite filtrar eventos por prefijo, sufijo, tamaño, etc. y enrutarlos a más de 20 destinos distintos.
Conocer las políticas de bucket para responder preguntas sobre que habilita o deniega una policy. Su alcance. Entender que un Deny explícito siempre gana, incluso si hay un Allow en otra política.

ElastiCache

Conocer las llamadas básicas de la API es básico ➡ saber como crear un cluster CreateCacheCluster, parámetros importantes como CacheNodeType

ElastiCache - Memcached: caso de uso que recibe alertas relacionadas con un alto uso de CPU en un clúster de Amazon ElastiCache Memcached, cómo solucionarlo? ➡ Agregar nodos adicionales proporcionará mayor capacidad al clúster o bien según la versión de Memcached se puede escalar verticalmente cambiando el tipo de nodo sin necesidad de crear un nuevo cluster. No tiene replicación, ni persistencia.
ElastiCache - Redis: El concepto más importante de esta opción es permitir Alta Disponibilidad a través de sus réplicas: Multi-AZ con failover automático. División en sharding. Compatible con PUB/SUB. Adecuado para conservar sesiones. El soporte más común a resolver por performance es cambiar el tipo de nodo.

SSM (Simple Service Manager)

Si no trabajas todos los días con este servicio, es necesario que no solo estudies teoría en cuanto a sus features, sino que también hagas laboratorios.

Las preguntas que aparecen en el examen son muy variadas en cuanto a la administración de EC2, aplicación de parches, auto aprobaciones de releases y algunas que involucran webhooks con github.

Recomiendo mirar la sintaxis de los documentos en JSON o Yaml que definen acciones y flujos de trabajo automatizados ➡ hay preguntas sencillas sobre este punto en el examen.

Enumero algunas situaciones o casos de uso:

Un concepto sencillo útil: todas las ejecuciones se puede trackear su estatus y log de salidas desde la consola de System Manager.
Se quiere automatizar la creación de Amazon Machine Images (AMIs) personalizadas. Se detecta errores timeout sobre el pipeline de EC2 Image Builder ➡ El agente de AWS Systems Manager (agente SSM) en la instancia de compilación no se está ejecutando o no está accesible.
¿Cómo dividimos los parches entre servidores de diferentes cuentas/entornos y SO? ➡ La solución combina Patch Baselines (definen qué parches aplicar, con aprobaciones automáticas y listas de rechazo, por SO) + Patch Groups (agrupan nodos mediante tags y los asocian a una Baseline específica).

Runbook: Tipo específico de documento de Systems Manager (SSM) que define las acciones exactas que realiza el servicio Automation. Define yaml o json para orquestar un workflow de ejecución.

Por lo general, se usa para la remediación asociado con AWS Config.
Usando AWS Organizations se necesita automatizar el proceso de stopping de instancias EC2 no productivas fuera del horario de negocio de todos las cuentas miembro ➡ Crear roles de IAM en cada cuenta con los permisos adecuados, utilizar Systems Manager Automation con una cuenta de administrador delegado para ejecutar un runbook que dirija los recursos de toda la organización según los tags.
Patch Policies: se utiliza para Organizations. Tener en claro que centraliza el control para definir patching schedules y baselines para múltiples cuentas y regiones
Revisar los documentos de ejecuciones más importantes en SSM.
Integraciones por eventos externos, tener claro cómo trabaja en los diferentes casos webhooks (con avisos de software de terceros). Que flujos podemos tener:
- Webhook → API GW → Lambda → SSM
- GitHub Actions → SSM (puedes filtrar exactamente por eventos RELEASED o PRERELEASED).
- Amazon EventBridge Partner Events → GitHub como fuente nativa de eventos → SSM Automation o Lambda como destino.
- EventBridge Scheduler → Lambda consulta GitHub API → escribe versión en SSM Parameter Store (como fuente de verdad para actualizaciones)
AWS RunRemoteScript: Documento SSM que permite ejecutar scripts alojados en S3 o GitHub directamente en los nodos, sin necesidad de copiarlos previamente.

Servicios y estrategias de Deployment

Casos de uso de AWS Code Pipeline, y los otros servicios que involucra ➡ Code Commit o GitHUb, Code Build, Code Deploy o CloudFormation. Entender donde se integran los test y tener en cuenta que se puede agregar una aprobación vía sns antes de realizar deploy.
CodePipeline puede implementar CloudFormation StackSets, lo que permite implementaciones en múltiples cuentas y regiones como parte de una canalización de CI/CD.
Estrategias de deployment:
- In-place (All-at-once): Implementa en todas las instancias simultáneamente. Downtime Posible. Es Lento (redeploy versión antigua). Se usa en entornos de desarrollo, cuando el downtime es aceptable
- Rolling: Reemplazar instancias en lotes. Downtime Mínimo. Se usa cuando querés ahorrar costos sin aprovisionar nueva infraestructura.
- Rolling with additional batch: Agrega nuevas instancias antes de eliminar las antiguas. Downtime mejor que el anterior. Se usa cuando necesitas mantener capacidad completa durante el deploy
- Immutable: Inicia instancias completamente nuevas; intercambia cuando estén en buen estado. Se usa en producción donde el rollback rápido es crítico.
- Blue/Green: Ejecuta dos entornos idénticos; cambia el tráfico. Downtime mínimo. Se usa cuando necesitás rollback instantáneo y podés asumir el costo de doble infraestructura.
- Canary: Desvía primero un pequeño % del tráfico; lo va ampliando si todo está OK. Es rápido. Se usa para validar un release con un subconjunto de usuarios antes de rollout completo.

Cloudformation

Es un servicio fundamental en el examen. Conocer las secciones principales de la plantilla (JSON o YAmL) : Metadata, Parameters, Mappings (caso de uso de parametrización de Amazon Machine Images (AMIs) ), Conditions, Transform (SAM), Resources.

Una buena práctica para familiarizarse con la sintaxis de los templates es construir arquitecturas clásicas que utilicen EC2, ASG, ALB, RDS con Secret Manager, entre otras.
Comandos CLI importantes:
- aws cloudformation create-stack ➡ crea un stack nuevo
- aws cloudformation deploy ➡ crea o actualiza un stack usando un template empaquetado (más usado en CI/CD)
- aws cloudformation detect-drift ➡ inicia la detección de drift en un stack
- aws cloudformation describe-stack-drift-detection-status ➡ consulta el resultado de la detección
- aws cloudformation cancel-update-stack ➡ cancela una actualización en curso
StackSet ➡ caso de uso importante de cuentas asociadas en Organizations. Gestiona de manera centralizada para implementar cambios en las stack en varias cuentas. Se puede usar StackSets para crear, actualizar o eliminar stacks en varias cuentas y regiones de AWS con una sola operación.
Intrinsic functions: comandos que se utilizan dentro de las plantillas para asignar valores a propiedades que no están disponibles hasta el momento de la implementación (en tiempo de ejecución) ➡ revisar implementaciones de las mas importantes: Ref , Fn::GetAtt, Fn::ImportValue, Fn::FindInMap, Fn::ForEach, Fn::Transform ...
NestedStack: AWS::CloudFormation::Stack ➡ mecanismo para crear infraestructura modular, reutilizable y gestionable mediante la integración de una pila dentro de otra. En lugar de crear una plantilla única y masiva que resulta difícil de mantener, se puede dividir la arquitectura en componentes lógicos (por ejemplo, VPC, base de datos, capa de aplicación) y referenciarlos como pilas separadas dentro de una plantilla "raíz" o "padre".
Mecanismos de protección en CloudFormation:
- Stack Policy: documento JSON que restringe qué recursos pueden ser actualizados. Ideal para proteger RDS de producción de cambios accidentales.
- Termination Protection: protección a nivel stack contra eliminación accidental. Se hereda a los nested stacks.
- DeletionPolicy: Retain conserva el recurso, Snapshot genera snapshot antes de eliminar (soportado en RDS, EBS). La situación típica que se plantea, como conservar una RDS si se elimina el stack de cloudformation?
- UpdateReplacePolicy: igual que DeletionPolicy pero aplica cuando un update requiere reemplazar el recurso físico.
- Drift Detection: detecta recursos cuya configuración real difiere del template, útil para identificar cambios manuales que bypasearon el pipeline.
Profundizar en los Script Auxiliares más importantes, mecanismos para sincronizar la creación o actualización de recursos, para que el stack espere hasta que la configuración esté lista antes de continuar.
- cfn-init → lee y ejecuta la sección AWS::CloudFormation::Init del template (instala paquetes, archivos, servicios). Se ejecuta durante el User Data.
- cfn-signal ➡ Generalmente se implementa al final de un script de User Data. Un patrón común es ejecutarlo después de cfn-init
- Tener en cuenta los atributos que requieren señales como CreationPolicy (puede estar asociados con AWS::EC2::Instance o AWS::AutoScaling::AutoScalingGroup ) y los tipos de UpdatePolicy (con WaitOnResourceSignals).
CloudFormation Traffic Shifting ➡ se implementa definiendo DeploymentPreference en el template. CodeDeploy ejecuta el shifting según la estrategia elegida (Canary, Linear, AllAtOnce).

Storage

Evaluar y seleccionar que tipo de Storage es adecuado a un caso de uso. Si estudiaste para la certificación de SAA son preguntas similares.

Storage en entornos híbridos ➡ Storage Gateway y todas sus variantes
- S3 File Gateway: Acceso NFS/SMB a objetos en S3. Los archivos se almacenan como objetos nativos. Caso de uso: migración de archivos on-premise a S3.
- Volume Gateway:
- Cached mode: datos principales en S3, caché local de los más accedidos.
- Stored mode: datos principales on-premise, backup asíncrono a S3 como EBS snapshots.
- Tape Gateway: Reemplaza cintas físicas. Importante es que se expande automáticamente, esta última característica puede ser un caso de uso que aparezca en el examen.
- FSx File Gateway: Caché local de FSx for Windows File Server para acceso de baja latencia desde on-premise.
FSx for Windows FileServer y su otras variantes, cuando usarlo?
- Es MultiAZ, es una feature importante.
- Shadow Copies: los usuarios finales puedan ver y restaurar por sí mismos versiones anteriores de archivos o carpetas individuales sin depender de otro mecanismo.
- Usado con Windows SMB, Active Directory.
FSx for Lustre ➡ HPC, ML, high throughput
EFS (Elastic File System) comprender el caso de uso que puede compartir storage entre varias EC2, Linux NFS.
- Multi-AZ
- Performance modes: general Purpose y MaxIO
- Throughput Modes: Elastic (recomendado), Provisioned, Bursting.
- Conocer qué EFS tiene Storage Class y Lifecycle Policies ➡ aunque suele no aparecer en el examen.
EBS ➡ siempre en el contexto de EC2 y la elección del disco para optimizar las cargas de trabajo: gp3 sobre gp2 sin incrementar los costos, gp3 permite configurar IOPS y throughput independientemente del tamaño del volumen. Para transacciones, persistencia y durabilidad es io2
- Amazon Data Lifecycle Manager (DLM): Automatiza la creación, retención y eliminación de instantáneas de EBS y AMI respaldadas por EBS mediante políticas de ciclo de vida.
- EBS Snapshot: Una copia de seguridad puntual de un volumen EBS almacenado en S3 (gestionado por AWS). Los snapshot son incrementales.

RDS y Aurora

Los accesos se deben guardar en Secrets Manager y luego las aplicaciones acceden a eso. Característica importante Cross-Region backup replication. Tanto RDS como Aurora tienen PITR (Point-in-Time Restore).

RDS Multi-AZ ➡ standby síncrono en otra AZ, failover automático pero más lento que Aurora.
Se puede asociar con el servicio RDS Proxy para el manejo de conexiones.
Aurora ➡ Almacenamiento distribuido que se replica automáticamente en 3 AZs, hasta 15 réplicas de lectura, failover automático en segundos.
Aurora Serverless v2 ➡ la característica importante es que escala a "cero" y no genera costo.

DynamoDB

Las preguntas se centran en resolver problemas de performance; cómo volver a un recovery point. Ejemplo: La tabla experimenta picos de tráfico incrementales durante el horario laboral, con patrones predecibles, cuando se producen millones de lecturas y escrituras. Hay que configurar una solución para aumentar la capacidad de procesamiento ➡ Habilitar el escalado automático en la tabla de DynamoDB. Configurar una política de escalado automático para ajustar el tamaño en función de las unidades de capacidad de lectura y escritura.

Point-in-Time Recovery (PITR) ➡ backup continuo, permite restaurar a cualquier segundo de los últimos 35 días.
Para esto debemos conocer los tipos de Lectura Eventually Consistent Read (por defecto) y Strongly Consistent Read
Los diferentes modos de capacidad On-Demand y Provisioned (profundizar en estos dos conceptos).
DynamoDB Global Tables ➡ replicación multirregional y multiactiva. Cada región puede aceptar lecturas y escrituras, y los cambios se replican de forma asíncrona. Esto permite la escalabilidad global y la recuperación ante desastres.

Encriptación en reposo, tránsito y uso de KMS

Encriptación con S3 de KMS: SSE-S3 (clave gestionada por AWS), SSE-KMS (usás una KMS key propia, permite auditoría via CloudTrail y control de acceso granular) y SSE-C (el cliente provee la clave, AWS no la almacena). Si la pregunta menciona auditoría de uso de claves o control granular ➡ SSE-KMS.
Clave simetrica y asimetrica son básicos. Aunque en el examen no hay preguntas profundas sobre este punto.
Key Policies: Cada clave KMS tiene una política de claves. Una política basada en recursos que controla quién puede usar y administrar la clave. A diferencia de las políticas de IAM, la política de claves es el principal mecanismo de control de acceso para las claves KMS.
Rotación de Key, hay 3 variantes:
- automática, para customer managed keys puede habilitar la rotación automática
- manual u On-demand por medio de trigger.
Importación de material de clave de un cliente en KMS, pero no rota automáticamente.
Replicación AWS KMS Multi-Region Keys: Una clave KMS que existe en una región diferente, pero comparte el mismo ID de clave y material de clave que su clave principal.

AWS Certificate Manager (ACM)

Las preguntas son sencillas, si se habla que servicio proporciona certificados SSL/TLS la respuesta es ACM.

Revisar los casos de uso de como integrar ACM con ELB, CloudFront, ApiGateway, Elastic Beanstalk, Cognito.
Tipos de certificados ➡ públicos, privados e importación de terceros. Identificar los casos de uso para poder resolver situaciones.
Mecanismo de renovación e importación de certificados de terceros.

Seguridad IAM

Pensar que todo servicio para ejecutar algo debe tener un rol de IAM asociado. En ciertas ocasiones para permitir que usuarios utilicen servicios o listen ciertas features de manera temporal podemos agregar inline policies y luego eliminarlas.
Casos de uso de iam:PassRole. Entender por qué es una capa de seguridad importante para proteger el entorno de AWS de actividades no deseadas y de la escalada de privilegios.
Caso de uso de credenciales temporalesiam:AssumeRole. Ejemplo ➡ la entidad en la Cuenta A utiliza para ejecutar servicios en la Cuenta B como si fuera un usuario local en esa cuenta.
Federación de Identidades: Permite a los usuarios autenticados por un proveedor de identidad externo (IdP) acceder a AWS sin crear usuarios de IAM individuales. Conocer los casos de uso:
- SAML 2.0: se integra con Microsoft Active Directory Federation Services (ADFS) u Okta. Los usuarios se autentican con sus credenciales corporativas y reciben credenciales temporales de AWS.

OpenID Connect (OIDC):

para aplicaciones web y móviles. Admite proveedores de identidad como Google, Facebook o cualquier proveedor compatible con OIDC. Solución de error "Not authorized to perform sts:AssumeRoleWithWebIdentity" ➡ agregar el ARN del proveedor de identidad en el elemento principal de la política de confianza (trust policy).

AWS Organizations

OU (Organizational Units): las cuentas se agrupan en OUs y los SCPs se aplican a nivel OU o cuenta individual, heredando hacia abajo en la jerarquía.
Delegated Administrator: permite que una cuenta miembro (no la cuenta de administración) gestione servicios específicos como Security Hub, GuardDuty o Config para toda la organización.
Relaciona el concepto de administrar muchas cuentas con Service control policies (SCPs). Recordar que afectan únicamente a los usuarios y roles de IAM gestionados por las cuentas que forman parte de la organización. SCPs no afectan directamente a las políticas basadas en recursos.
Políticas de tagging. Se puede asegurar que los usuarios no puedan crear recursos sin una etiqueta específica.
Integración con CloudFormation StackSet. Definir un StackSet que implementa una plantilla base (almacenada en S3) en toda una Unidad Organizativa (OU) en varias regiones utilizando Service-Managed permission model.
Consolidated Billing: todas las cuentas miembro consolidan el pago en la cuenta de administración, permite aprovechar descuentos por volumen y Reserved Instances compartidas entre cuentas.

AWS Artifact

Su caso de uso es acceder a informes de auditoría. Se puede descargar bajo demanda certificaciones de cumplimiento normativo (como SOC 1/2/3, ISO/IEC, y PCI DSS).

Este apunte continua en ➡ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 2

Patrones de acceso seguro a S3 🌐

Laura Bolaños — Mon, 27 Apr 2026 14:09:23 +0000

Este análisis se propone clarificar algunos casos de uso donde se requiere servir contenido de S3 de manera segura, identificando las brechas de seguridad a las que debemos enfrentarnos y explorar posibles mejoras. El desafío real no está en analizar cada servicio por separado, sino en combinarlos correctamente.

1. CloudFront + OAC con presigned url

Caso de uso frecuente: Un sitio web que muestra imágenes/vídeos de una temática determinada. Una parte de los objetos multimedia puede restringirse a que solo lo vean usuarios que iniciaron sesión vía Cognito. Aquí la solución más sencilla:

Upload de Multimedia (escritura)
El frontend solicita una Presigned URL a un endpoint protegido por Cognito (una api). La api se integra con una función Lambda que genera una URL temporal (válida por x minutos) firmada con permisos de "s3:PutObject" para el bucket privado de imágenes.

Visualización de Multimedia (lectura)
El bucket de S3 tiene el bloqueo de acceso público activado.
Los elementos multimedia se sirven a través de CloudFront, utilizando OAC (Origin Access Control) para firmar internamente la petición (usando el protocolo SigV4) y solicitar el objeto a S3 de forma segura.
La política (Bucket Policy) del bucket S3 solo permite la acción "s3:GetObject" si la petición proviene específicamente del ARN de la distribución de CloudFront ("Condition: AWS:SourceArn").

Conceptualmente una Presigned URL se puede utilizar tanto para cargar como para leer objetos, en el ejemplo anterior notar que solo se usa para cargar los objetos a S3*.* Una presigned URL es simplemente una URL con la firma embebida ➡ cualquiera que la tenga puede usarla hasta que expire, sin autenticación. Por eso debemos aplicar diferentes técnicas de seguridad.

La url puede tener una duración desde 1 minuto hasta 12 horas, si alguien no autorizado consigue la url y ya caduco ➡ NO la puede utilizar.
Con el uso de Cognito, el token JWT tiene una duración y se puede aplicar este control con Cognito JWT Authorizer (nativo de API Gateway). La otra posibilidad es tener Lambda Authorizer en API Gateway. Esta última tiene lógica de autorización custom.
Cuando generamos una presigned url para upload, se puede controlar que tipos de objetos cargar y su peso máximo. Algunos ejemplos:

# Generate presigned URL for PUT
# ContentType specifies the types of objects and controls their size on the frontend
upload_url = s3_client.generate_presigned_url(
            "put_object",
            Params={
                "Bucket":      IMAGES_BUCKET,
                "Key":         imagen_key,
                "ContentType": expected_content_type,
            },
            ExpiresIn=PRESIGNED_URL_TTL,
)

# the frontend makes a multipart POST request
response = s3_client.generate_presigned_post(
    Bucket=IMAGES_BUCKET,
    Key=imagen_key,
    Fields={
        "Content-Type": expected_content_type,
    },
    Conditions=[
        {"Content-Type": expected_content_type},
        ["content-length-range", 1, 5242880],  # máx 5MB
    ],
    ExpiresIn=PRESIGNED_URL_TTL,
)

1.2 Caso de uso complementario - Validación de acceso en el edge (Lambda@Edge)

Podemos enfrentarnos a dos requerimientos no funcionales: minimizar la latencia y asegurar quién puede hacer request a Cloudfront.
El caso anterior asegura que solo CloudFront puede acceder a S3, pero no controla quién puede hacer requests a CloudFront. Con Lambda@Edge es posible agregar lógica de autorización en los nodos de la CDN, antes de que el request llegue al origen. La secuencia es la siguiente:

Cuando un usuario solicita un objeto de un bucket, CloudFront invoca una función Lambda@Edge en el nodo más cercano geográficamente.
La función valida el JWT de Cognito (o cualquier token de sesión) sin necesidad de redirigir el request al backend.
Si el token es válido, el request continúa hacia S3 a través de OAC normalmente.
Si no es válido, Lambda@Edge retorna un 401 o redirige al login desde el edge.

⭐ La ventaja es la baja latencia, la validación ocurre en el edge node más cercano al usuario, sin necesidad de viajar hasta la región de AWS donde vive el backend. Cada request de contenido protegido se resuelve en milisegundos en lugar de sumar el tiempo de ida y vuelta a tu servidor.

2. Descarga temporal de un archivo privado - S3 Presigned URLs

Para esta opción el casos de uso típico: Un usuario necesita descargar un reporte generado, una factura o un documento legal guardado en bucket S3. No se utiliza Cloudfront porque no necesitamos cachear contenido de la petición.

Se produce la petición del usuario, el backend valida que ese usuario tiene permiso sobre ese archivo específico.
Lambda genera una presigned URL con GetObject que expire entre 5-15 min. La lógica de validación de lambda es idéntica del caso de uso 1 de Upload.
El browser descarga directamente desde S3 usando esa URL.

🔐 Brechas de seguridad detectadas

Riesgos de seguridad	Mitigación posible
El usuario la copia y la comparte intencionalmente o no.	TTL muy corto (1-2 minutos si es descarga inmediata)
Queda en logs del browser, proxies o herramientas de red	Generar la URL y redirigir directamente (`302`) en lugar de devolverla al frontend (nunca queda expuesta en el browser)
Se filtra por un `Referer` header en un redirect	Incluir el `userId` en la key del objeto (`uploads/{userId}/{filename}`) para que aunque alguien obtenga la URL, solo pueda acceder al archivo de ese usuario específico.

3. Distribución segura con cookies por sesión - CloudFront Signed Cookies

Caso de uso típico: Una plataforma web con contenido que se accede por suscripción, los usuarios se loguean pero cada sesión debe tener acceso acotado en el tiempo. En lugar de firmar URL por URL, el backend emite una Signed Cookie de CloudFront al momento del login, que el browser envía automáticamente en cada request de objetos multimedia.

El backend verifica la sesión y envía tres headers Set-Cookie al browser (CloudFront requiere exactamente tres pares clave-valor para una Signed Cookie). Estos headers deben enviarse antes de que el usuario solicite el contenido privado.
Si se configura un tiempo de expiración corto, el backend puede reenviar tres nuevos headers Set-Cookie en requests posteriores para mantener el acceso activo.
CloudFront valida las cookies en cada request antes de servir los objetos multimedia. La distribución debe tener al menos dos comportamientos de cache: uno público y uno que requiere autenticación. La sección privada redirige al login si no hay cookie válida.
Al cerrar sesión o expirar las cookies, el acceso se revoca sin cambiar las URLs.

⭐ Esta opción es Ideal cuando un usuario accede a múltiples objetos multimedia de una misma sección sin generar una firma por cada archivo.
⭐ Si CloudFront se configura para cachear basándose en cookies, NO generará entradas de caché separadas por los atributos de las Signed Cookies. Es decir, todos los usuarios autorizados compartirán la misma entrada de caché para un objeto determinado— CloudFront valida la cookie para permitir o denegar el acceso, pero la ignora al construir la cache key.

Aspectos generales a tener en cuenta

➡ Diseño
Considerar Patrón BFF (Backend for Frontend). Para el caso de descarga privada, se puede interponer una capa BFF entre el frontend y API Gateway. Esta capa maneja la sesión del usuario y puede ejecutar un redirect 302 directo hacia S3, evitando que la presigned URL quede expuesta en el browser.

➡ Performance/Costo
Invalidaciones de CloudFront (incurre costo después de 1000/mes). Además del costo analizar tiempo de cacheo de datos.

S3 request rates (3500 PUT/5500 GET por segundo por prefix, si el volumen es alto distribuir con prefijos).

Costo de Lambda por invocación para generar presigned URLs a escala.

➡ Seguridad
Rotación de claves KMS si el bucket usa SSE-KMS.

Versionado de objetos en S3 para evitar sobreescritura accidental.

➡ Operacional
TTL de presigned URLs vs tiempo de expiración del JWT — si el JWT expira antes que la URL, tenemos un problema!

Estrategia de nombres de objetos (userId/filename) para evitar colisiones y facilitar políticas IAM por prefijo.

Pensar en Serverless para crear bellos sueños 🦋

Laura Bolaños — Fri, 10 Apr 2026 12:56:18 +0000

En estas líneas te explico una sencilla arquitectura para desplegar un sitio web íntegramente utilizando servicios Serverless que podría servir, como en mi caso, para mostrarle al mundo mi interés por la ecología (con repositorio github incluido)

En un mundo digital donde se crean productos financieros, web que muestran dashboard de eficiencias, p&L y todo tipo de temáticas asociada al dinero ...y que está muy bien! olvidamos que nuestro hábitat natural necesita ayuda.
Hace unos años me percate de esto y comencé a leer/hablar de árboles, arbustos y plantas mal llamadas malezas - nativas de mi región que son fuente de alimento de mariposas e insectos que son fundamentales para la biodiversidad - que están desapareciendo con el avance de las especies exóticas, los agroquímicos y la destrucción de humedales.
La mayoría de las personas cuando comentas la problemática te dice "OK estoy de acuerdo contigo" pero no activan en tener un pequeño jardín de nativas o a la hora de elegir un árbol para su vereda priorizan especies exóticas solo por estetica, sin saber que muchas nativas son igual de hermosas y además sostienen la fauna local (hablo especialmente de la Provincia de Buenos Aires, Argentina).

....Y qué pasaría si cambio mi discurso en mi afán de convencer y digo: "si no ayudamos plantando nativas en nuestros hogares las mariposas pueden desaparecer" ¿Suena drástico? pero en gran parte es cierto. Estudios afirman que la población ha disminuido muy rápido, especialmente la mariposa Bandera Argentina debido a que no encuentra su planta nutricia (Coronillo) donde desovar sus huevos 💔 Cabe aclarar que la disminución de mariposas afecta directamente a la polinización y con esto atenta contra la seguridad alimentaria.
Por todo lo anterior y para bajar un poco el dramatismo decidí hacer algo: crear un proyecto web que muestre mariposas e indique la planta nativa nutricia que alimenta sus orugas! Y que los usuarios registrados puedan cargar avistamientos de mariposas en la región. Para acompañar esta idea pensé en una arquitectura Serverless, que reduce la huella de carbono y acompaña mi pensamiento ecológico 🌱.

Comencemos analizando la arquitectura

Como podés observar el laboratorio es de un nivel entre 100 y 200 (si necesitas ayuda me comentas).
Implementa una arquitectura Serverless de 3 capas:

Web Tier:
S3-Sitio Web + CloudFront ➡ contiene todo el sitio web creado con react. El código está preparado para integrar con los servicios Apigateway y Cognito. Cloudfront servicio para servir el sitio web de S3. Este s3 no es público, solo se accede a través de Cloudfront.

App Tier:
Cognito + API Gateway + Lambda ➡ Cognito realiza la autenticación del usuario que se inicia sesión. Se aclara que los usuarios se deben crear manualmente por la Consola de AWS o por cli (explicado en el Readme de repositorio). Las Lambdas de crear imagen, get imagen, presigned_URL y delete imagen(funcionalidad no desarrollada aún desde el frontend) se invocan via Apigateway. Solo los usuarios autorizados por Cognito pueden acceder a estas funcionalidades.
Las lambdas están codificadas en Python.

Data Tier:
DynamoDB + S3 - imágenes ➡ Toda la información de la fichas de las imágenes de mariposas se guarda en DynamoDB incluyendo la presigned-URL de S3-imagenes. En este último bucket se guardarán las imágenes de mariposas subidas por el usuario.
Aunque Route53 aparece en el diagrama, en el repo no lo vas a ver codificado en la IaC. Por qué? porque para el entorno educativo del laboratorio no es necesario, con la url de cloudfront el sitio web queda totalmente funcional.

⭐ El objetivo es construir una aplicación real con autenticación, subida de archivos y CRUD completo utilizando solo servicios serverless de AWS, con la opción de deployar en CloudFormation o Terraform. Porque también es muy importante aprender las diferentes formas de desplegar sin tocar el Console Home.

Como utilizar el repositorio de código

✅ Ten en cuenta que como requisito para comenzar con este ejercicio necesitas instalado Python, Terraform, AWS Cli (todo explicadisimo en el repo 🤓)

El código se encuentra en una url de un repositorio padre labs-aws-llb donde hay otros laboratorios, pero el que nos interesa es: webAppServerles.

Comenzar leyendo Arquitectura.md que explica un poco la secuencia de las acciones en los componentes y las decisiones de Arquitectura, como por ejemplo por qué no pasar las imagenes por el payload de Lambda.
Leer el Readme.md principal: contiene el paso a paso que debes hacer y si decides hacer el deploy con terraform o cloudformation te indicará ir a su correspondiente directorio. Cada directorio también contiene su Readme.md.
Leer Integration.md : te vas a encontrar que una vez deployada la IaC en AWS, solo necesitarás tomar los outputs de terraform o el descripción del stack de cloudformation y configurar el archivo aws-config.ts . Luego volverás al Readme principal para seguir el paso a paso ➡ volver a subir la web buildeada a S3 y crear una invalidación de CloudFront para actualizar la web integrada con el backend.
El laboratorio tiene un costo mínimo (si estás en la capa gratuita cero) Como siempre recomiendo limpiar todo lo desplegado. Si estas pensando en crear una web funcional estable ten en cuenta los costos. Información detallada en Readme principal.

Funcionalidades

Una vez deployado el sitio web siguiendo las indicaciones, tenemos las siguientes funcionalidades.

Feature	Usuario anónimo	Usuario logueado
Ver catálogo de mariposas precargadas	🦋	🦋
Ver galería de avistamientos de usuarios	❌	🦋
Subir foto + metadata de avistamiento	❌	🦋
Filtrar por ecorregión	🦋	🦋
Ver ficha detallada de mariposa	🦋	🦋

Después de todo el trabajo... con la url de Cloudfront descubrirás esta hermosa web funcional de mariposas bonaerenses 💗 sustentada íntegramente con servicios serverless.

En el título hablo de sueños porque realmente lo es, sueño que mis vecinos tengan aunque sea solo un ejemplar nativo. No hay estadística clara sobre la vegetación nativa, pero sabemos que las especies van retrocediendo y con esto también las mariposas.
La foto principal es una Monarca del Sur recién nacida en mi jardín, ya que generé las condiciones para que eso pasara.
Este laboratorio sirve para mostrar que casi sin costo podemos difundir información sobre temas que nos favorecen a todos y a todas. Y en tu región, ¿qué mariposas habitan?

Claves para lograr la certificación AWS Data Engineer Associate

Laura Bolaños — Fri, 20 Mar 2026 03:33:59 +0000

En este artículo encontrarás una guía para descubrir qué conocimientos necesitás antes de rendir el examen, identificar tus brechas y entender en qué temas profundizar. 🤓

Información general del examen

La certificación esta orientada los Ingenieros de datos pero también a todos aquellos que están construyendo su perfil de Arquitecto Cloud.
Aquí podes encontrar datos generales del examen, intuyo que ya conoces esta información.
La guia de examen consta de 4 dominios, es super necesario leer y revisar continuamente mientras estudias para la certificación: link
El dato importante: el examen no esta disponible en español. Para todos los que tenemos dificultad con el idioma puede parecer un impedimento pero no te preocupes! estudiando y armando apuntes en ingles lo puedes lograr 🏆 Las preguntas se pueden comprender perfectamente porque se alcanza un nivel de familiaridad con frases claves del examen.
⭐ Tip: lengua no nativa ingles ➡ pedir los 30 minutos adicionales (Exam acommodations) en la plataforma Training And Certificacion antes de agendar el examen.

Complejidad

Si no trabajas como Data Engineer pero contas con un background en bases de datos, consultas sql complejas y performance tuning los contenidos te van a resultar familiares y sencillos de incorporar. Además, si contás con la certificación Solutions Architect Associate una parte del contenido ya lo habrás estudiado.

⭐ Es una certificación importante y muy amena para estudiar, de complejidad media.

Cursos de preparación y laboratorios básicos

➡ Curso en Skillbuilder de Data Engineer Foundations . Es gratis y básico para esta certificación.
➡ Curso en SkillBuilder de preparación del examen. Es esencial ya que explica en que consiste el examen y lo que debemos estudiar. Si no contas con la suscripción haz todo el contenido libre, basicamente es la explicación de los 4 dominios.
➡ Es necesario hacer laboratorios de diferentes casos de uso, tanto de Data Lakes como de DataWarehouse. Los laboratorios los encontras en SkillBuilder (ejemplo CloudQuest Data Analytics) o invertir unos dolares en la consola. Comparto laboratorio básico de mi github

Método de estudio sugerido

Armar un NotebookLM con tus apuntes y links a pdf de la documentación oficial de AWS. Particularmente recomiendo Developer Guide y/o User Guide de servicios como Glue, Redshift, Kinesis, Athena, QuickSigth, OpenSearch, Amazon MSK, LakeFormation, DataSync y todas las url que consideres. De esta manera construyes una especie de RAG para tener precisión a la hora de preguntar dudas conceptuales o de casos de uso.
En el momento de practicar preguntas no te fies ciegamente de las respuestas de las IA, el último tiempo noté que algunos modelos tienen dificultades con temas de elección de arquitecturas. Verificar siempre con la documentación oficial, por eso es importante el punto anterior.
Buscar un banco de preguntas para entrenar y conocer el estilo de examen. En mi caso utilicé Tutoriales Dojo
Recursos útiles (lo utilicé en la preparación) :

video banco de preguntas

video casos de uso

github llb

Conocimientos fundamentales para presentar el examen

Durante el examen prestar atención a palabras claves, pensar cual solución es mas lógica, más costo- efectiva, con menor esfuerzo operacional y con performance aceptable.
El listado a continuación no cubre todo el temario, pero dominar estos temas es fundamental para aprobar:

Generales

Datalake ➡ S3: raw, curation, consumption.
DataWarehouse : Redshift. Siempre relacionado con queries complejas.
Data Lakehouse.
Patrones de ingesta de datos: Streaming y Batch.
Atención en las preguntas donde se haga alusión a data lake o datawarehouse porque puede ser la clave para elegir el almacenamiento.
Formatos de archivos para alimentar un Data Lake en S3: Json, Parquet, Avro, ORC, Csv. Sus casos de uso. Comprender mecanismo de construcción de su metadata. Formatos de Compresión gzip (ratio), snappy (rápidez), zlib.
Elección de servicio para migrar archivos/datos desde el onprem. Probablemente la elección es DataSync.
Data Skew: referido a una distribución desigual de los datos entre las diferentes unidades de procesamiento provocando un desequilibrio de carga.
Métodos principales de orquestación de pipeline de datos: Step Functions, Glue Workflows (nativo para job de glue) y MWAA (dependencias complejas, portabilidad). Se pueden crear flujos y orquestarlos con Event Bridge.
DynamoDb Stream. DynamoDB TTL.
Conexion a RDS, Aurora, Redshift via api desde Lambda. Revisar ejemplos.
Comprender el concepto DAGs (Directed Acyclic Graphs) y con qué servicios esta relacionado. Amazon MWAA
Visualizacion-Dashboard ➡ QuickSigth . QuickSigth SPICE (relacion con Athena). Analizar diferentes casos de uso.
QuickSigth librerias built-in functions and operators: utilidad en casos de uso que necesitamos Rolling Averages, Pivoting and Grouping y Machine Learning (ML) Insights.
Opensearch: Creación de indices, monitorización de logs en tiempo real. UltraWarm en OpenSearch ➡ Conocer su caso de uso.
Secrets Manager es nuestro servicio estrella para guardar accesos a base de dados de manera segura.
Casos de uso de MSK (Kafka). Se asocia con Glue para transformar.

Amazon S3

S3 Storage Lens: Si tengo que hacer una auditoría de bucket, identificar versiones antiguas de objetos, partes incompletas, etc ➡ cuento con un dashboard para clarificar estas falencias.
Tener claro todos los tipos o layers de S3, su tiempo de recuperación de datos y costos: S3 Standar, IA, Glacier Flexible, Glacier Deep Archive, Intelligent tearing y los otros que no son de alta disponibilidad. Ciclo de vida. Versionamiento. Dependiendo el caso de uso hay que optar.
Cómo aplico encriptación en reposo en S3, DynamoDB. Siempre pensar en KMS pero NO con una clave proporcionada por el cliente porque es MÁS carga operacional (es lo que debemos evitar): en S3 ➡ SSE-KMS (claves gestionadas por AWS KMS con auditoría)
Cifrado doble en S3 ➡ SE-KMS (cifrado de doble capa del lado del servidor con AWS KMS).
VPC Endpoint GATEWAY . No tiene costo en S3 y otorga seguridad sin pasar por internet. Desde Glue se puede crear una conexión de red, especificar vpc/subnet. Mismo caso para conectar una lambda de manera segura a S3.
Si tengo varias aplicaciones que consumen diferentes prefix de S3 cual es la mejor manera de brindar seguridad para que una aplicación no pueda ver los datos de otra? Probablemente la solución sea S3 Access Point
Casos de uso de EDA (Event-Driven Architecture). Especialmente de S3, reconocer cuando conviene registrar un EventBridge y cuando reaccionar a una lambda (sin intermediarios).
Modificación de objetos (datos) en S3 al momento de la recuperación, ejemplo: un caso de uso que deba enmascarar información ➡ Por medio de S3 Object Lambda.
Técnicas de Performance en datos almacenados en S3: Bucketing y Partition (ver cardinalidades). Entender las diferencias y cuando se usa según el caso para poder responder con seguridad.
Amazon Macie: tener claro que hace escaneo, descubrimiento y clasificacion de información sensible cuando los datos ya están alojados en S3. Puede integrarse con EventBridge para realizar acciones sobre los hallazgos.
SQL S3 ➡ solo puede consultar un unico archivo. Util para consultas adhoc de un dato en particular.

Amazon Glue

Glue Engine: Spark, Ray (computación paralela/intensiva) y Python Shell (ejecuciones sencillas).
Glue ETLs. Glue Crawler (identificación de metadata en varios origenes). Programación de cron. DynamicFrames.
Glue Dynamic Schema (Schema Evolution). Relacion con AVRO.
Glue Data Catalog (recordar que no solo se usa en el scope de Glue sino que también se integra con EMR). Schema version history.
Glue DataBrew - relacionado con Data Quality pero es herramienta visual no-code. Conocer la sintaxis de rules. Conviene hacer laboratorios o al menos revisar la consola de AWS. En qué casos de uso podemos arreglar los datos. Recordar que está vinculado con SageMaker AI en la preparación de datos para entrenar modelos.
Permite hacer Custom rules.
AWS Glue Data Quality. Es una capacidad diferentes al punto anterior. Utiliza DQDL para definir reglas de validación.
Glue Workflows (usar cuando orquestamos solo job de Glue, si vemos que tenemos que orquestar Lambdas la opción correcta probablemente sea Step Functions).
Glue Bookmark. Si lo tengo activado y el job vuelve a procesar los datos nuevamente...que puede estar pasando? falta job.commit().
Desde un bucket policy se puede denegar ejecuciones de glue que no esten desde un rango horario determinado, ejemplo: "StringNotEquals":{},"NumericGreaterThan":{"aws:CurrentTime":"11:00:00Z"},"NumericLessThan":{"aws:CurrentTime":"09:00:00Z"}} . Ver casos de policy en S3, es la parte de seguridad mas importante del examen.
Comprender permisos de ejecucion en Glue mediante roles y politica de confianza (Trust Policy): AWSServiceRole (tiene las politicas básicas).
Si tengo que monitorear job de Glue, a donde voy? lo hago en Glue Studio ➡Job monitoring dashboard (no desde Cloudwatch). Hacer laboratorio con Glue y revisar las métricas, ejecuciones anteriores. Este analisis sirve para ajustar dpu o workers.
Glue transformación de datos JSON a Tabular : Relationalize Transform.
Feature Transformación Detect PII (o Detect Sensitive Data): Accion de enmascarar, redactar o eliminar.
Glue Interactive Sessions.
Glue Flex. Usa capacidad de computación ociosa por lo tanto es menos costoso.

Amazon Redshift

Redshift sintaxis sql: practicar select, agrupaciones, rank() y funciones más comunes. Sintaxis UDF (se invocan en la proyeccción). Entender que las búsquedas con expresiones regulares son más lentas.
Redshift comandos: COPY (se usa para traer rápidamente datos desde S3) ➡Option: PARALLEL y COMPUPDATE. Unload (se usa para descargar datos a S3, generalmente históricos).
Redshift leader nodes y compute nodes. Entender cómo trabaja para tener la capacidad de responder preguntas de performance.
Redshift Spectrum, está pensando para consultar S3 Y Redshift. No confundir con consultas federadas. Por lo general se usa Spectrum cuando redshift descarga registros antiguos en s3 para abaratar costos y se requiere algún informe que cruce con datos históricos.
Redshift consultas federadas vs Athena federated queries. Se puede presentar una pregunta con estas dos opciones. Leer el caso de uso y tener en claro que soporta cada una. Ejemplo, Redshift queries federadas no soportas consultas en TimeStream.
Redshift Distribution Style : entender que es Auto Distribution, ALL, Even, Key. Esto se aplica para hacer performantes las querys. Relacionar con Star Schemas.
Redshift: Ingesta de datos en formato JSON, cómo se almacena/consulta de forma performante? Con el tipo de dato SUPER, se crea una tabla con una única columna y se puede realizar consultas anidadas (se usa PARTITION BY y funciones como like json_extract_path_text).
Data Sharing: Redshift comparte información entre cluster. Ver casos de uso.
Vistas materializadas. Como las construye. En qué casos de uso se utilizan. Cómo se refrescan.
Redshift troubleshooting: Tabla de sistema STL_ALERT_EVENT_LOG. Maximum Transmission Unit (MTU). VACCUM, VACCUM FULL, VACCUM DELETE ONLY y VACCUM REINDEX.
Redshift Workload Management. Determina como se ejecutan las consultas en el cluster (query queues and route queries).
MPP (Massively Parallel Processing) y Windows Functions.
Dynamic Data Masking - DDM (CREATE MASKING POLICY) ➡ Permite ocultar, ofuscar o seudonimizar datos. Se pueden restringir a usuarios o a roles específicos.

Kinesis Data Stream - Kinesis Firehose - Amazon Managed Service for Apache Flink (Ex Kinesis Data Analytics)

Tener claro conceptualmente los 3 servicios del título. Real time y Near real time.
Amazon Managed Service for Apache Flink: Detectar anomalias o casos de uso de Fraude. Windows Operations (defining time-based or row-based windows to manage data streams)
Mirar todos los casos de ingesta Kinesis Data Stream (pensar que siempre es real time). Puede ingestar a Redshift directamente con Redshift Streaming (es zero etl).
Analizar Casos de Uso de streaming de IoT. Velocidad de Transmisión de datos- Registros por segundo.
Performance en streaming de datos: Kinesis Producer Library (KPL) y Kinesis Client Library (KCL). Shared Fan-out
Partition key de alta cardinalidad para distribuir la carga de forma equitativa en los diferentes shard.
Resolución de problemas en Kinesis Data Stream ➡ si la velocidad de los datos supera la capacidad de los fragmentos actuales: ProvisionedThroughput - Exceeded Exception.
Caso de uso Kinesis Firehose + Lambda para transformación de datos.
Integración Kinesis Firehose con CloudTrail.

Lake Formation

Lake Formation, si hay preguntas sobre permisos granulares considerar que la respuesta es esta. Tener en cuenta todo lo que puede gobernar Lake Formation (qué fuentes de datos).
Fine-Grained Access Control (FGAC). Tag-Based Access Control (LF-TBAC). Credential Vending.
Blueprints and Workflows: Templates que ayudan a ingestar datos desde varias fuentes para crear automaticamente AWS Glue crawlers, jobs, and triggers.
Auditoría via CloudTrail.
CloudTrail Lake: observalidad de como interactúa el ecosistema de AWS. Centralidad de logs. SQL Engine. Seguridad Granular.

EMR

Comprender los casos de uso EMR. Es la opcion de procesamiento de datos mas costosa para mantener (para que viva la metadata hay que tener prendido el cluster). Puede ser la elección adecuado si se requiere control profundo sobre la infraestructura, configuraciones personalizadas (flexibilidad) o el uso del ecosistema completo de Hadoop para migraciones de datos.
Relación con BigData. Procesamiento Distribuido.
EMR puede usar Glue Catalog.
Mirar la combinación de cómputo recomendada para brindar alta disponibilidad y cost effective. Instancias Spot y Procesadores Graviton.
EMR: feature security configuration para setear encriptación tanto en reposo como en tránsito.
EMR Serverless. Casos de uso. Entender en cual caso conviene utilizar en lugar de EMR Standard.

Amazon Athena

"Analizar datos con sql" la respuesta es Athena.
Tablas en Athena que se pueden modificar : Apache Iceberg.
Athena predicate pushdown*.*
Athena Parallel Execution.
Consultas anidadas en Athena (nested), como hacer performante y fácil. View por cada consulta.
Athena federated Query.
Athena ➡ queries lentas, están mal las particiones que estoy tomando para filtrar. Uso Partition Projection en base a los accesos.
Glue Notebooks y Athena Notebooks: cuando se usa cada uno?
CTAS (Create Table as Select)
Athena Federated Query por medio de Lambda.
Athena Workgroups

DMS - STC -CDC

Migrar a una base de datos en la nube o desde onprem, la mejor elección es DMS. Si no hay homogeneidad en la base de datos origen con la de destino se debe usar STC (AWS Schema Conversion tool). Para replicar datos evitando downtime en la base de datos se replica con CDC (change data capture). Este último se realiza con los logs full de transacciones activado en la base de datos origen.
En los casos de uso de migración de bases de datos homogéneas solo se usa DMS + DMS Schema Conversion y cdc (change data capture) para los cambios.
Cuando tengo dos regiones y se quiere migrar una base de datos en la región A con destino en la región B, DMS debe ubicarse idealmente en la región donde está la base de datos de destino o en una región cercana para minimizar la latencia de escritura.

Cloudwatch - CloudTrail

Comprender cuándo utilizar CloudWatch, ejemplo ➡ si necesito analizar/buscar con lenguaje sql uso Amazon CloudWatch Logs Insights. Metrics Filters y Subscription Filter.
Creación de Train en CloudTrail. Mecanismo de envío de datos (a S3) y consultas.
En CloudTrail puedo direccionar el logueo de la actividad de cuentas y/o servicios a un S3 y analizar los datos mediante Athena.
CloudTrail caso de uso testigo: a. CloudTrail capta eventos de Redshift, b. por medio de Reglas de EventBridge guarda esos logs en DynamoDB. También EventBridge Pipes puede filtrar contenido de eventos.

Camino a lograr AWS Certified Developer - Associate (DVA-C02)

Laura Bolaños — Tue, 17 Mar 2026 14:23:20 +0000

Estas notas no intentan ser una guía detallada, sino un recorrido por temas importantes y tips que debemos tener en cuenta si nos aventuramos a estudiar esta certificación. También es importante aclarar que se trata de una visión subjetiva acerca de la complejidad del examen, basada en mi experiencia después de haber obtenido 3 certificaciones previas de AWS.

Información general del examen

No me voy a detener en esta descripción porque está claramente escrito en este enlace que debes leer.

⭐ Tip: si tu lengua no es ingles nativa, pedir 30 minutos adicionales (Exam acommodations) en la plataforma Training And Certificacion antes de agendar el examen, sin importar si se rinde en ingles o español.
Esta selección se realiza en la opción de menú marcada y queda seleccionada por default para todas las futuras certificaciones de AWS.

Complejidad

AWS Developer Associate < AWS Solutions Architect Associate
AWS Developer Associate > AWS Cloud Practtioner
AWS Developer Associate < AWS AI Practitioner

Relación con certificaciones anteriores

Cuál es tu punto de partida?

Leer la guía de examen para tener una visión general del contenido que debemos abordar de los 4 dominios, cada dominio tiene un % diferente de cobertura en la certificación. No te desanimes si a priori pensas que tu perfil no es el del candidato que se describe en la guía, yo tampoco lo soy 100%, pero con ganas y entusiasmo para aprender → llegarás a la meta!!.
guía del examen
Learning plan de preparación de AWS SkillBuilder. No importa si no contas con la suscripción, haz lo que este sin costo. Es una forma de nivelar tus conocimientos.
Lo bueno de la suscripción es que accedes a varios laboratorios útiles pero no es un impedimento. Si haces practicas de laboratorios por cuenta propia necesitarás una inversión mínima en la consola de AWS de 1 a 3 usd.
Exam Prep Plan: AWS Certified Developer — Associate

⭐ Cuando comiences el punto 2, recomiendo armar planilla de calculo de “brechas de conocimiento” e indicar como vas a cubrir ese gap (con laboratorios, documentación de AWS o practicando preguntas de examen).

Claves fundamentales para presentar el examen

En esta sección se listan los conocimientos clave que debemos profundizar para alcanzar la certificación. Como siempre, es fundamental tener una perspectiva de seguridad para los diferentes servicios de AWS: quién puede invocar cada servicio y qué acciones puede realizar una vez invocado → aplicando el Principio del Mínimo Privilegio.

☁ Desarrollo con Lambda: si crees que por lanzar una lambda via consola o cloudformation ya tenes todo el conocimiento…pues no es así. Hay que profundizar y tener practica de laboratorios pasando por la mayoría de sus features:

Versiones Lambda — Alias Lambda-Integraciones (como se usan?). Pruebas de dev y prod con alias. Alias ponderados (como usar?).
Tiempo de Espera Lambda.
Variables de Entorno (se cifran? ).
Concurrencia Aprovisionada y Concurrencia Reservada. (diferencia y sus casos de uso).
DLQ (cuando se usa).
Triggers. Lambda Source Events (EventSourceMaping).
Logueo en CloudWatch
Limites y quotas Lambda
Lambda layers (para que se usan).
Lambda VPC (cuando y como se usa).
Eficiencia Lambda (memoria? codigo?)
Almacenamiento interno /tmp (limites y en que casos es util).
Manejo de errores. Retroceso exponencial.
Payload de entrada y de salida.

⭐ Tip: para cubrir la mayoría de teoría de lambda con demostraciones, ver video Joan Amengual.
⭐ No dejes de hacer laboratorios o pequeñas pruebas tomando un lenguaje de programación soportado, en mi caso elegí Python.

☁ DynamoDB: Conocimiento profundo del servicio.

Clave sencilla (único atributo) y compuesta (2 atributos).
Importancia de cardinalidad en claves de partición. Índices de ordenación.
Índices LSI y GSI. Qué índice se puede crear en una tabla ya activa y con datos. Limites de índices. *Recuperar items y en qué casos de uso se utilizan: GetItem, Scan (no performante), Query y BatchGetItem. Consultas condicionales.
Lecturas eventualmente consistentes y fuertemente consistentes. Transacciones en DynamoDB. Consumo de RCU y WCU de cada una. Tra
Conocimiento para calcular RCU-WCU en un caso de uso de lecturas/escrituras por segundo de acuerdo al tipo de requerimiento de consistencia.
Capacidad aprovisionada o a demanda. En qué casos de uso conviene utilizar cada una.
TTL. Configuración para eliminación de ítem por medio de atributo marca de tiempo.

⭐Tip: Hacer laboratorios de Lambda invocando programáticamente a DynamoDB, con diferentes funcionalidades de recupero de ítems utilizando el SDK de AWS.

☁ DynamoDB Stream: Cómo integramos los avisos de cambios de DynamoDB (insert, modify, delete ) con los diferentes servicios .

FilterCriteria. Revisar ejemplos.
Cómo evito publicar información sensible por medio de StreamViewType (KEYS_ONLY).

⭐Tip: Recomiendo revisar diferentes casos de uso Lambda, Amazon Kinesis Data Stream, Step Functions.

☁ Desarrollo Api Gateway: Contar con conocimiento profundo del servicio.

Tipos de APIs. Correspondencia con casos de uso.
Integración con lambda, alias-versiones.
Stages. Ambientes dev-prod. Variables de stage.
Integraciones simuladas. Mocks.
Validación de headers, request y body. Por ejemplo, podemos validar antes de llamar a un backend Lambda.
Autenticación y Autorización. Roles de IAM. Api key. Cognito (app web y mobile). Lambda Authotizer.

⭐ Este servicio es de los mas importantes junto con Lambda. Es necesario hacer diferentes laboratorios por medio de la Consola de AWS y también por SAM (Serverless Application Model).

☁ Autenticación y Autorización Cognito:

User Pools e Identity Pools. Comprender el flujo básico de autenticación.
Casos en que solo con User Pools podemos tener autenticación. Adicionando Identity Pool para implemetar Roles de IAM acceder a servicios aws (credenciales temporales).
Acceso a usuarios autenticados y no autenticados. Casos de uso y diferencias.
IAM roles y Trust relationships. Su relación con la configuración en Cognito.
Grupos de usuarios de Cognito (dentro de User Pools). Asignación de Roles de IAM.
Federación de identidades (Facebook, google, etc). Identity Provider. Protocolos SAML o OpenID Connect (OIDC).
Flujos de autenticación personalizados con Lambda (Custom authentication challenge Lambda trigger). *Amazon Cognito Sync para sincronización de perfiles en todos los dispositos mobile y web.

⭐ Es importante repasar ejemplos y si es posible hacer pequeños laboratorios de: app web con ALB-Cognito, flujos de autorizaciones personalizadas Lambda, Autenticación Cognito en Apigateway.
⭐Ayuda revisar las diferentes configuraciones en la consola de AWS.

☁ ALB-ASG-EC2: Conocer los casos de uso típicos de aplicaciones web con esta arquitectura de alta disponibilidad y cómo aplicar seguridad y certificados (ACM).

Perfiles de instancia de EC2 y asunción de roles. Casos de uso que necesito acceder a una RDS a escribir.
Cómo aplico Seguridad por VPC, Security groups, ACL.

☁ Contenedores ECS, EKS: Componentes fundamentales, como aplicar monitoreo y observabilidad en los dos casos para solucionar problemas (Cloudwtach y X-Ray).

☁ Cloudfront: Además de conocer frente a que servicios puede estar (ALB, S3, lambdaEdge..) centrarse en la seguridad. Ver casos de uso para aplicar seguridad entre el lector-cloudfront y cloudfront-origen.

☁ SAM (Serveless Application Model): Conocer los comandos básicos de la Cli de SAM. Hacer pequeños laboratorios con Lambda-ApiGateway- DynamoDB (caso de uso CRUD), comandos para testear localmente e implementar.

☁ CI/CD: Conocer comandos básicos y cómo se integran CodeBuild, CodeDeploy, CodePipeline.

Archivos necesarios en la raiz local de cada proyecto: buildspec.yml y appspec.yml (gestiona los hooks necesarios para la implementación).
Verificación con Hooks de CodeDeploy: PreTraffic y PostTraffic.
En cual podemos agregar pruebas automatizadas. En dónde podemos agregar aprobación manual.
Cómo lo integro con SAM? Para separar ambientes de dev-staging-prod que opciones tengo para guardar esa parametría (configuración local, ParameterStore).
Importancia de las implementaciones Canary y el desvío de tráfico por porcentaje entre producción actual y la nueva implementación .

☁ EventBridge: Revisar casos de uso de Arquitecturas orientadas a eventos donde intervenga este servicio.

Comprender la diferencia de utilizar Amazon Eventbridge o SNS. Revisar diferentes casos de uso.
Capacidad de transformación de el payload para cada destino.
Filtrado de eventos. Reglas complejas basadas en el payload del evento.
Casos de uso de avisos relacionados a cumplimiento, seguridad o controles generales. Relación con Security Hub, avisos de Vencimientos de certificados (ACM).

⭐ Recomiendo hacer laboratorio de un ejemplo similar a: venta/pedidos de producto, donde tengo un bus de eventos y diferentes reglas que ejecutan Lambdas: “registrar pedido”, “preparar pedido” y “entregar pedido”. Cada lambda con un evento posterior avisa para el siguiente paso al bus de eventos.

☁ SQS: Elemental entender sus casos de uso con Lambda, SNS y EventBridge.

Tipos Standard y FIFO. Performance de cada uno.
DLQ (dead letter queue).
Visibilidad de mensajes. Máximos.
Retardos de entrega de mensajes: Delay. No confundir con visbilidad de mensajes.
Reintentos de entrega de mensajes. Permanencia de mensajes.
Borrado automático de mensajes cuando se realiza sondeo o pooling y cuando es necesario eliminar programáticamente.

☁ SNS: Comprender sus casos de uso con Lambda, SQS y EventBridge.

Filtrado de eventos para diferentes consumidores. Uso de atributos para el filtrado.
Diferencias con SQS. SNS tiene la capacidad de entregar el mismo mensaje a diferentes consumidores.
Reintentos de entrega de mensaje. Protocolos y Políticas de entrega.

☁ S3: Conocimiento general de todos los tipos y el tiempo de recuperación de información.

Casos de uso comunes de carga de objetos y que eventos puede disparar, ya sea en una SQS, SNS o simplemente la ejecución de una Lambda.
Conocimientos de manejo de políticas de bucket (políticas basadas en recursos) no solo para permitir qué hacer a nivel bucket sino también a nivel objeto.
Políticas de recursos para forzar conexiones cifradas (https), forzar realizar put ítem donde elemento ya venga encriptado. Cómo hacer para que un usuario determinado solo vea sus objetos en un bucket general.
URL pre-firmadas. Duración máxima y seteo de expiración time.
Sitios web estaticos. Como hacer para que sólo se puede invocar desde Cloudfront (OAC-Origin Access Control).

⭐ Es muy útil la practica de comandos/acciones sobre S3 con AWS CLI.

☁ ElasticBeanstalk: que tipos de casos de uso puedo desarrollar. Comandos ClI EB. Por qué se Beanstalk (ventajas) ? En qué casos nos ayuda?

Tipos de deployment, (hacer cuadro comparativo de All at once, Rolling, Immutable, Traffic splitting, Blue/green).
Componentes centrales Enviroments y Applications-Application versions.

☁ StepFunctions: Conocer los estados y condiciones.

Cómo hace los reintentos. Revisar ejemplos del tipo sistema de pagos.
Comprender que no siempre utilizar SF es la solución mas sencilla.
Relación con Lambda, SQS y Eventbridge.

☁ CDK: No confundir con SDK.

Uso de AWS CDK Construct Library y AWS CDK Tookit.
El modelo de Programación de Constructs. Clase CDK Aspects.
Aserciones de CDK . Pruebas unitarias.
Traducción a plantillas Cloudformation.

☁ CloudFormation: Estructura básica. Parametría. Rollback. Diferencias entre Ref o GetAtt. Pilas anidadas. La importancia de los Outputs. Fn::ImportValue.

☁ CloudWatch:

Métricas personalizas. Grupos de logs. Logueo personalizado.
Query en los logs.
Uso Formato de Métrica Integrada (EMF, Embedded Metric Format).
Agente cloudwatch. Su relacion con ECS, EKS y servidores on-prem. Qué recopila.
Filtros Cloudwatch. Contadores. Avisos. Desde qué momento tiene vigencia.

☁ CloudTrail — XRay Diferencias conceptuales entre ambos. Particularmente para el caso de AWS Developer tiene mas utilidad X-Ray, entender el por qué.

Consultas en CloudTrail, relación con Amazon Athena.
Auditoria de KMS en CloudTrail.
Analisis/Solución cuellos de botella. Latencia.
Cómo integrar X-Ray en ECS o EKS. Sidecar X-Ray.

☁ Seguridad de datos y secretos:

Claves simétricas y asimétricas. Cifrado en transito y reposo.
Cómo puedo usar KMS (claves administrados, material de clave importados, etc).
Casos de uso en los que un desarrollador necesita rotar secretos de password de base de datos usando Secret Manager.
Casos de uso que podemos utilizar Parameter Store - Secure String. Cifrado en transito y reposo.

☁ STS: Comprender los mecanismos de obtención de credenciales: AssumeRole, AssumeRoleWebIndentity, AssumeRoleWithSAML, GetFederationToken, GetSessionToken..

Cómo hacer para probar asumir un rol desde AWS CLI y solucionar un problema.
STS en Cognito. Relaciones de Confianza.
Invocaciones AssumeRoleWithWebIdentity por qué no requieren el uso de credenciales de seguridad de AWS.
Etiquetas de Sesión (Tags).
Endpoint STS Global y Regional. Su relación con la latencia.

Alguna manera útil de estudiar teoría y buscar apoyo de colegas?

⭐ En casos de uso de servicios que mas dudas tengas, lo recomendable siempre es hacer pequeños laboratorios..seguro ya lo dije pero es muy importante!!

⭐ Cuidado con las IA y la explicación profunda de los servicios o casos de uso, tienen alucinaciones!
Recomiendo estudiar de las documentación oficial de Aws. En mi caso usé: Developer Guide y API Reference en pdf/html de los servicios para CHATEAR con ellas por medio de un cuaderno de Google NotebookLM (te permite agregar hasta 50 fuentes con usuario sin suscripción, adición de notas y +…es espectacular!).

⭐ Practicar muchas preguntas de examen es lo que te asegura el éxito.
En AWS SkillBuilder hay un set gratuito y uno con suscripción.
Exam Topics (10 gratuitas).
Tutoriales Dojo (gratuitas).
Revisar algún set de Practica de Udemy. En mi caso utilice set de un instructor muy poco conocido.

⭐ Todo proceso de certificación conviene transitarlo con apoyo de las comunidades con intereses parecidos a los nuestros. Te invito a unirte:
📚 AWS Women In Cloud Buenos Aires → donde ayudamos a cerrar la brecha de género en aws.
📚 La comunidad de MaxCloud — El Capitan
📚 AWS Women Colombia