> labs.luisguisado.cloud
Avanzado~120 min·por Luis Guisado·actualizado 16 de mayo de 2026

Llevar el sistema a AWS: Bedrock + AgentCore Runtime

Despliega el crew a AWS con Bedrock como backend de modelos y AgentCore Runtime como entorno de ejecución serverless. Cierras la serie pasando de demo local a sistema operable en cloud, con IAM, logs en CloudWatch y endpoint propio.

BedrockBedrock AgentCoreIAMCloudWatch LogsECR

Costo estimado: ~$0.50 USD si destruyes los recursos al terminar

Aparece en: Agentic AI desde cero para Backend y Cloud Developers

Por qué este lab existe

En el Lab 5 dejaste el crew corriendo contra cualquier proveedor, incluido Bedrock, pero siempre desde tu laptop:

crew = Crew(agents=[...], tasks=[...], process=Process.sequential)
resultado = crew.kickoff(inputs={"topic": "AWS EventBridge"})
print(resultado.raw)

Local funciona para validar el flujo. Pero cuando otro sistema necesite consumir el crew (un frontend, un workflow automatizado, un webhook), la laptop deja de alcanzar: necesitas un endpoint HTTP, autenticación, logs persistidos y que el proceso siga vivo aunque cierres el portátil.

Hay varias rutas para llegar allá: meter el crew en una Lambda con API Gateway, empaquetarlo en un container sobre Fargate, levantar un ECS. Funcionan, pero te toca armar toda la infra alrededor (HTTP server, auth, observability) a mano.

Amazon Bedrock AgentCore Runtime es el entorno serverless oficial de AWS pensado específicamente para correr agentes (los hechos a mano, los de CrewAI, LangChain o LangGraph). Tú subes el código del crew y AgentCore se encarga de: ejecutar la app, exponer un endpoint, persistir logs en CloudWatch, autenticar con IAM y escalar bajo demanda. En este lab vas a llevar el crew del Lab 5 a AgentCore Runtime y probarlo end-to-end.

Duración: ~120 min · Nivel: Advanced · Costo: ~$0.50 USD si destruyes los recursos al terminar.

Lo que vas a tener al terminar

  1. Acceso a Bedrock habilitado para Claude 3.5 Haiku en tu región.
  2. Una app app.py que envuelve el crew con el entrypoint de AgentCore.
  3. Un IAM role del agente con permisos mínimos (Bedrock InvokeModel + CloudWatch Logs).
  4. El crew desplegado en AgentCore Runtime, invocable por HTTPS con autenticación IAM.
  5. Logs estructurados de cada agent step en CloudWatch.
  6. Un comando de teardown que destruye todos los recursos para que el costo no siga corriendo.

Qué vas a aprender

  • Empaquetar una app Python (con CrewAI dentro) en el formato esperado por AgentCore Runtime.
  • Diseñar el IAM role del agente aplicando el principio de menor privilegio.
  • Desplegar con la CLI agentcore y entender qué crea por debajo (ECR, container image, runtime).
  • Invocar el agente por HTTPS y leer la respuesta.
  • Observar el flujo en CloudWatch Logs: cada agent step en su log group dedicado.
  • Destruir los recursos para que la corrida no genere costo después.

Conceptos clave

AgentCore Runtime como entorno serverless para agentes

Qué es: Bedrock AgentCore Runtime (en adelante AgentCore) es el servicio de AWS que ejecuta un agente como un proceso serverless de larga duración. Recibe peticiones HTTP, ejecuta tu app dentro del runtime, persiste los logs y escala automáticamente. La diferencia con una Lambda tradicional es que AgentCore está diseñado para sesiones de agente (estado conversacional, streaming, sessions con TTL), no para cómputo stateless de 15 minutos.

Mini-ejemplo: el entrypoint que AgentCore espera en tu app.

from bedrock_agentcore import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def handler(payload):
    topic = payload.get("topic", "AWS Lambda")
    # ... invocar el crew ...
    return {"result": "..."}

if __name__ == "__main__":
    app.run()

IAM role del agente y principio de menor privilegio

Qué es: AgentCore corre el container de tu app asumiendo un IAM role específico (el “execution role” del agente). Las llamadas que la app hace a otros servicios AWS (Bedrock InvokeModel, escribir logs en CloudWatch) las hace con los permisos de ese role. El principio de menor privilegio (Saltzer & Schroeder, visto en el Lab 3) dice que el role solo debe tener los permisos estrictamente necesarios para la tarea. Para este crew: invocar el modelo específico de Bedrock y escribir en el log group del agente. Nada más.

Mini-ejemplo: la política mínima para este lab.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-haiku-20241022-v1:0"
    },
    {
      "Effect": "Allow",
      "Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:us-east-1:*:log-group:/aws/bedrock-agentcore/runtimes/*"
    }
  ]
}

Para profundizar: las tres formas de invocar un modelo de Bedrock desde tu código son InvokeModel (request/response síncrono, formato propio del proveedor), Converse (API uniforme que abstrae el formato), y Streaming (response en chunks). Litellm (que CrewAI usa) elige por debajo cuál llamar según el modelo. Para el lab no necesitas decidirlo, pero conviene saber que existen porque aparecen en los logs y en las métricas. Ref: Bedrock Runtime API · InvokeModel vs Converse.

Mapa visual

   Cliente (curl, app, otro servicio)
     │
     │  POST https://bedrock-agentcore.us-east-1.amazonaws.com/...
     │  Body: { "topic": "AWS EventBridge" }
     │  Auth: SigV4 (IAM)
     │
     ▼
   ┌─────────────────────────────────────────────────┐
   │  AgentCore Runtime                              │
   │                                                 │
   │  ┌───────────────────────────────────────────┐  │
   │  │  Tu container (Python + CrewAI)           │  │
   │  │                                           │  │
   │  │  @app.entrypoint                          │  │
   │  │  def handler(payload):                    │  │
   │  │      crew.kickoff(inputs=payload)         │  │
   │  └───────────────────────────────────────────┘  │
   │                  │                              │
   │                  │  (3 llamadas: 1 por agent)   │
   │                  ▼                              │
   │           bedrock:InvokeModel                   │
   │             ▼                                   │
   │     ┌────────────────┐    ┌─────────────────┐   │
   │     │  Bedrock       │    │ CloudWatch Logs │   │
   │     │  (Claude 3.5)  │    │ /aws/bedrock-   │   │
   │     │                │    │  agentcore/...  │   │
   │     └────────────────┘    └─────────────────┘   │
   └─────────────────────────────────────────────────┘

El cliente HTTP nunca habla directo con Bedrock. Habla con el endpoint de AgentCore, que ejecuta tu app, que internamente invoca Bedrock para cada agente del crew. Los logs de los tres agentes terminan en el mismo log group del runtime.

Punto de partida

Antes de empezar, verifica:

cd agentic-ai-lab
source .venv/bin/activate
python main.py                          # el crew del Lab 5 funciona local
aws sts get-caller-identity             # tienes credenciales AWS
docker ps                               # docker está corriendo

Respuesta esperada: el crew produce un post final, AWS te identifica con un ARN y docker responde (aunque sea con la lista vacía de containers).

Si algo falla, regresa al Lab 5 y verifica el setup AWS y Docker antes de seguir.

Sobre las versiones y los servicios

Validado al updatedAt: 2026-05-16:

  • bedrock-agentcore (SDK Python): instalable con pip install bedrock-agentcore. Última en pypi.org/project/bedrock-agentcore.
  • bedrock-agentcore-starter-toolkit (CLI): instalable con pip install bedrock-agentcore-starter-toolkit. Provee el comando agentcore.
  • AWS CLI: versión 2 (aws --version debe responder aws-cli/2.x).
  • Docker Engine: cualquier versión reciente que pueda correr en tu OS.

AgentCore Runtime es un servicio relativamente reciente en la oferta de AWS. La API y la CLI han evolucionado entre revisiones. Si los nombres de subcomandos del agentcore que ves aquí no coinciden con tu instalación, revisa el User Guide oficial antes de seguir: la estructura del flujo (configurar entrypoint, launch, invoke, destroy) se mantiene aunque los flags exactos cambien.

Región: los pasos asumen us-east-1. Si usas otra región, cambia el valor en los comandos y en los ARNs.

Paso 1. Habilitar acceso al modelo en Bedrock

Bedrock requiere que solicites acceso a cada modelo antes de poder invocarlo. Para los modelos de Anthropic en Bedrock la aprobación suele ser inmediata.

  1. Entra a la consola AWS → Amazon Bedrock → Model access (en la región us-east-1).
  2. Haz click en Modify model access (o Manage model access).
  3. Selecciona Claude 3.5 Haiku y solicita acceso.
  4. Espera el estado Access granted (suele ser inmediato).

Probar desde la CLI:

aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-3-5-haiku-20241022-v1:0 \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":50,"messages":[{"role":"user","content":"hola"}]}' \
  --cli-binary-format raw-in-base64-out \
  --region us-east-1 \
  /tmp/bedrock-response.json && cat /tmp/bedrock-response.json

Respuesta esperada: un JSON con content[0].text que tenga la respuesta del modelo. Si te sale AccessDeniedException, el modelo todavía no está aprobado.

Paso 2. Empaquetar la app del crew

AgentCore espera una app Python con un entrypoint decorado. Vamos a envolver el crew del Lab 5 en ese formato.

Archivo: app.py (NUEVO)

from bedrock_agentcore import BedrockAgentCoreApp

from crewai import Crew, Process

from crew_setup import researcher, writer, reviewer
from tasks import research_task, write_task, review_task


app = BedrockAgentCoreApp()


@app.entrypoint
def handler(payload):
    """Entrypoint que AgentCore invoca por cada request HTTP."""
    topic = payload.get("topic", "AWS Lambda")

    crew = Crew(
        agents=[researcher, writer, reviewer],
        tasks=[research_task, write_task, review_task],
        process=Process.sequential,
        verbose=False,    # producción: silenciado
    )

    resultado = crew.kickoff(inputs={"topic": topic})

    return {
        "topic": topic,
        "post": resultado.raw,
        "token_usage": resultado.token_usage.model_dump()
            if hasattr(resultado.token_usage, "model_dump")
            else str(resultado.token_usage),
    }


if __name__ == "__main__":
    # Permite correr localmente sin desplegar: `python app.py`
    app.run()

Tres cosas para notar:

  1. El entrypoint recibe un payload (el body del request HTTP parseado como dict) y devuelve un dict que AgentCore serializa como JSON.
  2. verbose=False evita inundar los logs en producción. Los logs estructurados los va a poner AgentCore por su cuenta.
  3. if __name__ == "__main__": app.run() deja que pruebes la app localmente antes de desplegarla. Levanta un servidor HTTP en localhost que emula el comportamiento de AgentCore.

Archivo: .env (MODIFICADO)

Asegúrate de que LLM_PROVIDER=bedrock esté activo. Como AgentCore ya corre en AWS, no necesitas API key alguna: el container va a asumir el IAM role del agente.

LLM_PROVIDER=bedrock
AWS_REGION=us-east-1

Archivo: requirements.txt (NUEVO)

AgentCore empaqueta tu app en un container; necesita un archivo de dependencias para construir la imagen.

crewai
boto3
bedrock-agentcore
python-dotenv

Probar local:

pip install bedrock-agentcore bedrock-agentcore-starter-toolkit
python app.py

En otra terminal:

curl -X POST http://localhost:8080/invocations \
  -H "Content-Type: application/json" \
  -d '{"topic": "AWS EventBridge"}'

Respuesta esperada: el crew corre como en el Lab 5 pero ahora invocado por HTTP, y devuelve el JSON con topic, post y token_usage. Si esto funciona local, la app está lista para empaquetarse.

Paso 3. Crear el IAM role del agente

AgentCore necesita un role para asumir cuando ejecuta el container. Vamos a crearlo a mano para que veas exactamente qué permisos lleva.

Archivo: trust-policy.json (NUEVO)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Archivo: agent-policy.json (NUEVO)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeClaudeOnBedrock",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-haiku-20241022-v1:0"
    },
    {
      "Sid": "WriteLogsToCloudWatch",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:CreateLogGroup"
      ],
      "Resource": "arn:aws:logs:us-east-1:*:log-group:/aws/bedrock-agentcore/runtimes/*"
    }
  ]
}

Crear el role:

aws iam create-role \
  --role-name AgenticAILabRuntimeRole \
  --assume-role-policy-document file://trust-policy.json

aws iam put-role-policy \
  --role-name AgenticAILabRuntimeRole \
  --policy-name AgenticAILabRuntimePolicy \
  --policy-document file://agent-policy.json

aws iam get-role --role-name AgenticAILabRuntimeRole --query "Role.Arn" --output text

Respuesta esperada: la última línea imprime el ARN del role, algo como arn:aws:iam::123456789012:role/AgenticAILabRuntimeRole. Guarda ese ARN para el siguiente paso.

Por qué no usar --auto-create-role de la CLI de AgentCore: la CLI puede crear el role por ti, pero el role auto-generado suele incluir permisos amplios (bedrock:*, todos los modelos) por conveniencia. Para este lab y para producción es mejor crearlo explícito con el ARN del modelo concreto. Si el alcance crece, agregás Statements; nunca le des * por defecto.

Paso 4. Desplegar a AgentCore Runtime

El comando agentcore configure lee tu app.py, detecta el entrypoint y genera un archivo de configuración local (.bedrock_agentcore.yaml). Después agentcore launch construye la imagen Docker, la sube a un repo de ECR creado para este agente y crea el recurso de runtime en AWS.

agentcore configure \
  --entrypoint app.py \
  --execution-role <ARN_DEL_ROLE_DEL_PASO_3> \
  --region us-east-1

Respuesta esperada: se genera .bedrock_agentcore.yaml y la consola te confirma el entrypoint detectado.

agentcore launch

Respuesta esperada: la CLI muestra varios pasos:

[1/4] Building Docker image...
[2/4] Pushing image to ECR (repo: bedrock-agentcore-agentic-ai-lab)...
[3/4] Creating runtime resource...
[4/4] Waiting for runtime to be READY...

✓ Runtime ARN: arn:aws:bedrock-agentcore:us-east-1:...:runtime/agentic-ai-lab-XXXXX

Si Docker falla: verifica que el daemon esté corriendo (docker ps). En macOS, abre Docker Desktop. En Linux, sudo systemctl start docker.

Si push a ECR falla: tus credenciales AWS quizá no tienen permisos para crear repos ECR. La política AmazonEC2ContainerRegistryFullAccess adjunta a tu usuario es suficiente para el lab; en producción se delega a CI/CD.

Paso 5. Invocar el endpoint y probar end-to-end

agentcore invoke '{"topic": "AWS EventBridge"}'

Respuesta esperada: la CLI hace el request firmado con SigV4, espera la respuesta y la imprime:

{
  "topic": "AWS EventBridge",
  "post": "# AWS EventBridge para backend developers\n\n...",
  "token_usage": {"total_tokens": 4421, "prompt_tokens": 3120, "completion_tokens": 1301}
}

La diferencia entre esta corrida y la del Lab 5 es solo dónde corre: aquí los 3 agentes ejecutan dentro del container que AgentCore maneja, no en tu laptop.

Invocar con curl (alternativa, requiere firmar el request a mano o usar awscurl):

pip install awscurl
RUNTIME_ARN=$(grep "runtime_arn" .bedrock_agentcore.yaml | awk '{print $2}' | tr -d '"')
awscurl --service bedrock-agentcore --region us-east-1 \
  -X POST "https://bedrock-agentcore.us-east-1.amazonaws.com/runtimes/${RUNTIME_ARN}/invocations" \
  -d '{"topic": "AWS EventBridge"}'

Mismo resultado que agentcore invoke, pero ahora ves el HTTP raw.

Paso 6. Observabilidad: leer los logs en CloudWatch

AgentCore escribe los logs de tu app en un log group dedicado:

aws logs describe-log-groups \
  --log-group-name-prefix "/aws/bedrock-agentcore/runtimes/" \
  --query "logGroups[].logGroupName" --output table

Respuesta esperada: ves un log group con el ID del runtime que acabas de crear.

Para ver los últimos logs:

LOG_GROUP="/aws/bedrock-agentcore/runtimes/<TU_RUNTIME_ID>"
aws logs tail "$LOG_GROUP" --follow

Respuesta esperada: al invocar de nuevo (agentcore invoke '\{"topic":"X"\}' en otra terminal), ves en tiempo real los prints de la app, las llamadas a Bedrock que CrewAI hace por cada agente, y el resultado.

Para vincular cada línea de log con una invocación concreta, AgentCore inyecta un requestId en el contexto. Si dentro de handler() quieres loggear con ese ID, lo lees del contexto que AgentCore expone (ver Observability docs).

Paso 7. Destruir los recursos

Mientras el runtime esté creado, AWS te cobra por el tiempo activo aunque no haya invocaciones. Al terminar el lab, elimínalo.

agentcore destroy

Respuesta esperada: la CLI elimina el runtime, opcionalmente el repo ECR y la imagen, y te pide confirmación para el role IAM.

Si la CLI no soporta el subcomando destroy en tu versión, hazlo a mano:

# 1. Eliminar el runtime
RUNTIME_ID=$(grep "runtime_id" .bedrock_agentcore.yaml | awk '{print $2}' | tr -d '"')
aws bedrock-agentcore-control delete-agent-runtime --agent-runtime-id "$RUNTIME_ID" --region us-east-1

# 2. Borrar la imagen y el repo ECR
aws ecr delete-repository --repository-name bedrock-agentcore-agentic-ai-lab --force --region us-east-1

# 3. Borrar el role IAM
aws iam delete-role-policy --role-name AgenticAILabRuntimeRole --policy-name AgenticAILabRuntimePolicy
aws iam delete-role --role-name AgenticAILabRuntimeRole

# 4. (Opcional) Borrar el log group
aws logs delete-log-group --log-group-name "/aws/bedrock-agentcore/runtimes/$RUNTIME_ID" --region us-east-1

Probar:

aws bedrock-agentcore-control list-agent-runtimes --region us-east-1 \
  --query "agentRuntimes[?agentRuntimeName=='agentic-ai-lab']"

Respuesta esperada: [] (lista vacía). Si está vacía, el runtime ya no existe y no genera cargos.

Errores comunes

Error 1. agentcore launch falla con “Docker daemon not running”

Síntoma: la CLI corta en el paso [1/4] Building Docker image....

Causa raíz: AgentCore construye una imagen Docker localmente antes de subirla a ECR. Sin Docker en marcha no puede hacerlo.

Corrección:

docker ps         # debe responder sin error
# si falla, arranca Docker Desktop (macOS/Windows) o `sudo systemctl start docker` (Linux)

Error 2. AccessDeniedException al invocar el runtime

Síntoma: agentcore invoke ... devuelve User is not authorized to perform: bedrock-agentcore:InvokeAgentRuntime.

Causa raíz: tu usuario (no el role del runtime) necesita permiso para invocar el endpoint. El role del runtime es solo para que el container llame a Bedrock; la invocación del runtime la haces tú con tu identidad.

Corrección: adjunta a tu usuario o role de CLI:

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:us-east-1:*:runtime/agentic-ai-lab-*"
}

Error 3. El container arranca pero falla con boto3 NoCredentialsError

Síntoma: los logs de CloudWatch muestran que el container arrancó pero al hacer la primera llamada a Bedrock crashea con botocore.exceptions.NoCredentialsError.

Causa raíz: litellm (vía CrewAI) intenta usar el SDK openai por defecto cuando el modelo del LLM no tiene el prefix correcto. Si dejaste LLM_PROVIDER=groq en .env pero no incluiste la GROQ_API_KEY dentro del container, falla.

Corrección: asegúrate de que .env tenga LLM_PROVIDER=bedrock antes de hacer agentcore launch. AgentCore usa el role IAM del agente para autenticar contra Bedrock; ninguna key adicional hace falta.

Error 4. El primer invoke después del deploy tarda mucho

Síntoma: agentcore invoke ... tarda 30-60 segundos en responder la primera vez, después responde rápido.

Causa raíz: AgentCore tiene cold start como cualquier serverless. El container se levanta on-demand cuando no hay tráfico.

Corrección: para casos donde el cold start sea inaceptable, AgentCore ofrece provisioned concurrency (mantener N containers calientes). Tiene costo fijo aunque no haya tráfico, así que actívalo solo cuando lo necesites. Ref: AgentCore Runtime · Scaling.

Buenas prácticas

  • Principio de menor privilegio en el role del agente. En vez de bedrock:* y logs:*, listá el ARN específico del modelo y el patrón del log group. Cuando el role queda comprometido (credenciales filtradas desde el container), el blast radius es exactamente la lista de Resources que escribiste. Ref: Saltzer & Schroeder, The Protection of Information in Computer Systems (1975); también AWS Well-Architected · Security Pillar, sección Identity and access management.
  • Probar local antes de desplegar. python app.py levanta el servidor HTTP que emula AgentCore. Detectar errores ahí cuesta segundos; detectarlos después de agentcore launch cuesta los minutos del build + push + deploy. Ref: principio de Fail Fast (Hunt & Thomas, The Pragmatic Programmer).
  • Destruir lo que no usas. El runtime activo genera costos aunque no haya tráfico (mantiene el container ready). Si el lab queda olvidado, el costo se acumula. Cierra siempre el ciclo con agentcore destroy o el teardown manual. Ref: AWS Well-Architected · Cost Optimization Pillar, sección Resource provisioning.

Estado del proyecto al finalizar

agentic-ai-lab/
├── .venv/
├── .env                       ← MODIFICADO (LLM_PROVIDER=bedrock)
├── .gitignore                 ← MODIFICADO (agregar .bedrock_agentcore.yaml)
├── call_llm.py                ← sin cambios
├── tools.py                   ← sin cambios
├── agent.py                   ← sin cambios
├── llm_factory.py             ← sin cambios
├── crew_setup.py              ← sin cambios
├── tasks.py                   ← sin cambios
├── main.py                    ← sin cambios
├── app.py                     ← NUEVO (entrypoint AgentCore)
├── requirements.txt           ← NUEVO (deps para el container)
├── trust-policy.json          ← NUEVO
├── agent-policy.json          ← NUEVO
└── .bedrock_agentcore.yaml    ← generado por `agentcore configure` (no versionar)

Checklist:

  • python app.py corre la app local y responde a curl localhost:8080/invocations.
  • El IAM role del agente tiene permisos solo sobre el ARN del modelo específico y los log groups del runtime, nada más.
  • agentcore invoke '\{"topic": "X"\}' devuelve un JSON con el post final.
  • Ves los logs de las invocaciones en CloudWatch.
  • Corriste agentcore destroy (o el teardown manual) al terminar; list-agent-runtimes devuelve vacío.

¿Qué sigue después de esta serie?

Cerraste la ruta desde “una llamada HTTP a un LLM” hasta “un sistema multi-agente desplegado en AWS con IAM y observability”. Los próximos caminos naturales:

  • Observability avanzada de agentes: traces distribuidos por agent step, evaluación automática de outputs, detección de hallucinations. Herramientas como Langfuse o LangSmith se integran con CrewAI y AgentCore.
  • Comparar frameworks: el mismo caso de uso sobre LangGraph (más explícito, basado en grafos de estado) o LlamaIndex Agents (más orientado a RAG). El crew de este lab se traduce con cambios menores y los trade-offs se ven mejor en código que en tablas.
  • CI/CD del agente: mover el agentcore launch a un pipeline (GitHub Actions, CodePipeline). Versionado de runtime, rollback, blue/green entre dos endpoints.
  • Un caso de negocio real: llevar el crew a un pipeline de contenido para tu propio sitio, a un asistente interno de tu equipo, o a una integración con Slack/Teams.

Referencias

Documentación oficial

Libros canónicos

  • Saltzer, J. & Schroeder, M. The Protection of Information in Computer Systems (1975): origen del principio de menor privilegio aplicado al role del agente.
  • Hunt, A. & Thomas, D. The Pragmatic Programmer: principio de Fail Fast aplicado a probar la app local antes de desplegar.

AWS Well-Architected

Repositorios y librerías