Los inicios: LLMs sin acciones

Todo comenzó con los LLMs. Estos modelos reciben un input (prompt) del usuario y generan una respuesta. Son muy buenos para producir contenido en base a la data con la que fueron entrenados: escribir un ensayo, resumir un documento, traducir un texto.

Pero pronto nos encontramos con un límite evidente:
➡️ Los LLMs no pueden ejecutar acciones en el mundo real, solo generan texto.

Segunda etapa: Agentes con herramientas (tools)

La siguiente evolución fueron los agentes. Estos aprovechan la capacidad de los LLMs para razonar y generar instrucciones, pero ahora con acceso a tools (herramientas externas).

Con esto, los agentes pueden:

• Consultar una API (ej. tipo de cambio de la SUNAT).
• Buscar en la web (como hace Perplexity o ChatGPT).
• Crear archivos o conectarse a sistemas de terceros.

El LLM no ejecuta la acción directamente, pero decide cuándo invocar un tool, y construye la respuesta final con base en el resultado.

El problema: acoplamiento de tools y agentes

Esto fue un gran avance, pero trajo un reto:
Los agentes eran responsables de definir, mantener e integrar todos sus tools.

➡️ Cada agente terminaba acoplado a su propio set de herramientas, lo que hacía difícil la reutilización, mantenimiento y estandarización.

El salto: llega MCP

Para resolverlo, Anthropic introdujo el Model Context Protocol (MCP).

MCP define un protocolo estándar que permite exponer herramientas (capabilities) a los agentes de forma desacoplada.

• Se construye un MCP Server, que implementa las acciones (ej. crear un repo en GitHub, consultar documentación de AWS).
• Los agentes actúan como MCP Clients, conectándose a los servidores mediante: stdio (flujo estándar) o shttp (streaming HTTP)

Los servidores MCP no solo exponen herramientas, también publican información contextual como prompts disponibles o descripciones de capabilities. De esta manera, un agente puede decidir dinámicamente qué usar para responder a la petición del usuario.

Adopción en el ecosistema

En poco tiempo, MCP ha sido ampliamente adoptado. Algunos ejemplos:

• GitHub MCP Server → crear repositorios, issues, pull requests.
• AWS MCP Server → acceder a documentación, ejecutar acciones en servicios cloud.

Para empresas, MCP significa modularidad:

• Los equipos ya no tienen que acoplar sus agentes a tools específicos.
• Pueden construir MCP Servers reutilizables y usarlos en múltiples proyectos, simplificando mantenimiento y despliegue.

MCP en acción: Amazon Q CLI + GitHub

Veamos un ejemplo práctico: configurar el GitHub MCP Server dentro de Amazon Q CLI.

Requisitos previos

• Tener instalado el Amazon Q CLI.
• Contar con Docker en ejecución.
• Crear un GitHub Personal Access Token con los siguientes permisos:

Configuración del archivo mcp.json

Dependiendo del alcance que quieras:

• Global (todos los proyectos): ~/.aws/amazonq/mcp.json
• Solo en un workspace: .amazonq/mcp.json

Crea el archivo con este contenido, recuerda cambiar el github personal access token:

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<tu-access-token>"
      }
    }
  }
}

Uso

Ejecuta:

q chat

Dentro de Amazon Q puedes ver los tools configurados incluyendo el de github.

Ahora puedes, por ejemplo, crear un repositorio directamente desde tu consola.

Conclusiones

El Model Context Protocol (MCP) representa un cambio de paradigma:

• Desacopla agentes y herramientas.
• Establece un lenguaje común entre LLMs, agentes y sistemas externos.
• Permite crear ecosistemas de herramientas reutilizables y seguros.

En otras palabras, MCP nos ayuda a pasar de agentes con herramientas aisladas a un ecosistema interoperable de capacidades, mucho más preparado para escalar en entornos reales y empresariales.

De agentes aislados a ecosistemas interoperables: MCP explicado was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aquí es donde entra Amazon Bedrock AgentCore.

¿Qué es Amazon Bedrock AgentCore?

Amazon Bedrock AgentCore es un servicio que permite desplegar y operar agentes de IA altamente capaces de forma segura y escalable. Ofrece:

• Infraestructura optimizada para cargas dinámicas de agentes.
• Integración flexible con frameworks como Strands Agents, LangGraph, LlamaIndex o CrewAI.
• Compatibilidad con cualquier modelo fundacional, tanto dentro como fuera de Amazon Bedrock.
• Controles de operación y observabilidad listos para producción.

En pocas palabras, elimina el heavy lifting de crear la infraestructura de agentes desde cero, para que los equipos puedan enfocarse en la lógica de negocio y acelerar el paso a producción.

Actualmente, AgentCore se encuentra en preview, por lo que no lo recomendaría aún para despliegues críticos en producción, pero sí es un momento ideal para explorar sus capacidades y prepararse.

Ajustando nuestro agente para AgentCore Runtime

En un post anterior construimos un agente utilizando Strands Agents. Ahora, vamos a integrarlo con AgentCore Runtime para desplegarlo.

Primero, instalamos las librerías necesarias:

pip install bedrock-agentcore strands-agents strands-agents-tools

Haremos tres modificaciones clave en nuestro agente existente:

Importar el runtime de Bedrock:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

Inicializar la aplicación de AgentCore:

app = BedrockAgentCoreApp()

Definir un entrypoint para procesar las solicitudes:

@app.entrypoint
def invoke(payload: dict):
    """Process user input and return a response"""
    user_message = payload.get("prompt")
    result = agent(user_message)
    return {"result": result.message}


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

Con esto, nuestro agente queda listo para ejecutarse dentro de AgentCore. Este es el código completo de nuestro agente:

from strands import Agent, tool
from strands_tools import calculator, current_time
import requests
from datetime import datetime
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()


@tool
def tipo_cambio_sunat() -> dict:
    """
    Obtiene el tipo de cambio del día de hoy desde SUNAT.

    Returns:
        dict: Diccionario con fecha, tipo de cambio compra y venta
              Ejemplo: {"fecha": "29/09/2025", "compra": 3.494, "venta": 3.502}
    """
    try:
        # Hacer request a la URL de SUNAT
        url = "https://www.sunat.gob.pe/a/txt/tipoCambio.txt"
        response = requests.get(url, timeout=10)
        response.raise_for_status()

        # Parsear la respuesta
        # Formato esperado: 29/09/2025|3.494|3.502|
        data = response.text.strip()
        parts = data.split('|')

        if len(parts) < 3:
            raise ValueError("Formato de respuesta inesperado de SUNAT")

        fecha = parts[0]
        compra = float(parts[1])
        venta = float(parts[2])

        return {
            "fecha": fecha,
            "compra": compra,
            "venta": venta,
            "moneda": "USD/PEN"
        }

    except requests.RequestException as e:
        return {"error": f"Error al conectar con SUNAT: {str(e)}"}
    except (ValueError, IndexError) as e:
        return {"error": f"Error al procesar datos de SUNAT: {str(e)}"}
    except Exception as e:
        return {"error": f"Error inesperado: {str(e)}"}


# Crea un agente con nuestra tool y tools de la comunidad
agent = Agent(tools=[calculator, current_time, tipo_cambio_sunat])


@app.entrypoint
def invoke(payload: dict):
    """Process user input and return a response"""
    user_message = payload.get("prompt")
    result = agent(user_message)
    return {"result": result.message}


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

Probando localmente

Antes de desplegar en la nube, podemos verificarlo de forma local:

python mi_agente.py

El servicio se expondrá en el puerto 8080. Podemos enviarle un prompt de prueba con curl:

curl:
curl -X POST http://localhost:8080/invocations \
-H "Content-Type: application/json" \
-d '{"prompt": "¿Cuál es el tipo de cambio de hoy según SUNAT? Y si tengo 100 dólares, ¿cuántos soles serían al tipo de cambio de venta?"}'

La respuesta confirmará que el agente sigue funcionando correctamente bajo AgentCore.

{"result": {"role": "assistant", "content": [{"text": "Según SUNAT, el tipo de cambio de hoy **29/09/2025** es:\n- **Compra**: S/ 3.494 por dólar\n- **Venta**: S/ 3.502 por dólar\n\nSi tienes **100 dólares** y los cambias al tipo de cambio de venta, obtendrías:\n**S/ 350.20 soles**\n\nEl tipo de cambio de venta es el que se usa cuando cambias dólares por soles, ya que es el precio al cual las casas de cambio te \"venden\" los soles a cambio de tus dólares."}]}}

Realizando el despliegue

Vamos a realizar el despliegue utilizando el starter toolkit de Amazon Bedrock AgentCore. Lo instalamos con pip:

pip install bedrock-agentcore-starter-toolkit

Necesitamos crear un archivo llamado requirements.txt con nuestras dependencias:

strands-agents
bedrock-agentcore
strands-agents-tools

Luego, realizamos la configuración de nuestro agente con el siguiente comando.

agentcore configure -e mi_agente.py

Puedes darle enter en todas las preguntas para usar la configuración por defecto.

Ahora procedemos a desplegar el agente con el siguiente comando:

agentcore launch

Una vez desplegado podemos probarlo con el siguiente comando:

agentcore invoke '{"prompt": "¿Cuál es el tipo de cambio de hoy según SUNAT? Y si tengo 100 dólares, ¿cuántos soles serían al tipo de cambio de venta?"}'

Visualizando el agente en la consola

Podemos ingresar al servicio Amazon Bedrock AgentCore, seleccionar la opción Agent Runtime y hacer clic en nuestro agente.

En la página de detalle veremos un ejemplo de cómo invocarlo, y ahí mismo se muestra el ARN del runtime que necesitamos copiar para usar en nuestro código.

Interactuando con el agente

Para probar nuestro agente de forma rápida, vamos a crear una pequeña aplicación con Streamlit que nos dé una interfaz de chat.

Primero instalamos Streamlit:

pip install streamlit

Luego creamos un archivo llamado basic-chat-streamlit.py con el siguiente contenido:

import json
import time
import uuid

import boto3
import streamlit as st

# Cliente de Bedrock AgentCore
agent_core = boto3.client("bedrock-agentcore", region_name="us-east-1")

# Generar un session_id válido (≥ 33 caracteres)
session_id = str(int(time.time())) + "_" + uuid.uuid4().hex

st.title("Chat básico con Bedrock AgentCore")
st.write("Ejemplo: Streamlit + AgentCore Runtime + Strands Agents")

# ARN del runtime desplegado en AgentCore
RUNTIME_ARN = "arn:aws:bedrock-agentcore:us-east-1:123456789012:runtime/mi_agente-xxxxxxxxxx"

# Caja de input estilo chat
if prompt := st.chat_input("Escribe tu mensaje..."):
    st.chat_message("user").write(prompt)

    with st.spinner("Consultando al agente..."):
        # Invocamos el runtime
        response = agent_core.invoke_agent_runtime(
            agentRuntimeArn=RUNTIME_ARN,
            runtimeSessionId=session_id,
            payload=json.dumps({"prompt": prompt}),
            qualifier="DEFAULT",
        )

        # Parsear respuesta
        result = json.loads(response["response"].read())

        # Mostrar respuesta del agente
        st.chat_message("assistant").write(result["result"]["content"][0]["text"])

👉 Importante: recuerda actualizar la región y el RUNTIME_ARN con los valores de tu propio agente.

Para ejecutar la aplicación:

streamlit run basic-streamlit.py

Esto abrirá una interfaz web sencilla donde podrás escribir mensajes y ver las respuestas de tu agente como un chat:

Componentes Clave de Amazon Bedrock AgentCore

Además del runtime que ya usamos en el ejemplo, Amazon Bedrock AgentCore trae varios componentes adicionales que facilitan la vida cuando queremos construir y operar agentes en un entorno empresarial. Aquí un repaso rápido:

AgentCore Runtime
La capa base que da un entorno de ejecución seguro y serverless para correr el código del agente o de sus herramientas. Soporta tanto interacciones en tiempo real con baja latencia como cargas asíncronas que pueden correr hasta 8 horas. Cada sesión está completamente aislada para evitar fugas de datos, y funciona con frameworks open source, modelos y cargas multimodales.

AgentCore Memory
Permite manejar memoria de corto y largo plazo para que los agentes sean context aware. El desarrollador decide qué recordar sin tener que construir toda la infraestructura de memoria. Así, los agentes pueden aprender de interacciones pasadas y traer el contexto adecuado a la conversación.

AgentCore Identity
Un sistema de identidad y acceso diseñado para agentes. Les permite autenticarse de forma segura y acceder a recursos o herramientas. Se integra con proveedores de identidad como Amazon Cognito, Microsoft Entra ID o Okta, y habilita acceso a recursos de AWS o servicios externos bajo consentimiento del usuario o políticas pre-aprobadas.

AgentCore Gateway
Es el puente para que los agentes descubran y usen herramientas. Convierte fácilmente APIs existentes, Lambdas o servicios en tools compatibles con agentes. Esto les abre la puerta a ejecutar tareas reales en entornos complejos sin fricción.

AgentCore Code Interpreter
Un entorno aislado y seguro para ejecutar código. Soporta varios lenguajes (Python, JavaScript, TypeScript) y permite que el agente haga análisis de datos o automatización de flujos sin comprometer la seguridad, gracias al aislamiento a nivel de VM.

AgentCore Browser Tool
Un navegador en la nube que los agentes pueden usar para interactuar con páginas web: desde navegar y llenar formularios hasta ejecutar flujos más complejos. Es model-agnostic y está pensado para escalar.

AgentCore Observability
Toda la visibilidad necesaria para producción: logs, métricas y trazas. Se apoya en Amazon CloudWatch con dashboards listos y compatibilidad con OpenTelemetry para integrarlo a tus tableros existentes.

Conclusión

Amazon Bedrock AgentCore es una pieza clave para pasar de un agente experimental a uno preparado para producción. Aunque todavía está en preview, ofrece una arquitectura pensada para la operación real de agentes: runtime administrado, observabilidad integrada y compatibilidad con cualquier framework o modelo.

Si ya estás experimentando con frameworks como Strands Agents, este es el momento perfecto para probar AgentCore Runtime y empezar a preparar tu stack de agentes para la nube.

Del prototipo a producción: Desplegando agentes de IA con Amazon Bedrock AgentCore was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

La construcción de agentes de IA tradicionalmente ha requerido definir flujos de trabajo detallados y rígidos, lo que limita su escalabilidad y capacidad de adaptación. Sin embargo, con la evolución de los modelos de lenguaje, hoy es posible dejar que el propio modelo guíe gran parte del proceso, reduciendo la complejidad para los desarrolladores y habilitando comportamientos mucho más flexibles y autónomos.

Aquí es donde entra Strands Agents, el SDK open source lanzado por AWS. Diseñado para aprovechar las capacidades de los modelos más avanzados, Strands permite a los desarrolladores crear agentes de manera simple: basta con definir un prompt y una lista de herramientas en código. A partir de ahí, el agent loop — un ciclo de razonamiento, uso de herramientas y generación de respuestas — se encarga de orquestar el comportamiento inteligente del agente, que puede probarse localmente y desplegarse en la nube.

Instalación inicial

Para empezar, instalamos las librerías necesarias:

pip install strands-agents strands-agents-tools

Strands Agents usa por defecto Amazon Bedrock como proveedor de modelos, específicamente Claude Sonnet 4. Por lo tanto, necesitamos credenciales de AWS válidas con permisos para invocar modelos en Bedrock.

Primer agente básico

El siguiente ejemplo crea un agente que responde usando solo el modelo LLM:

from strands import Agent

# Crear agente
agent = Agent()

# Preguntar algo al agente
message = """
¿Qué hora es en Lima, Perú?
"""
agent(message)

El resultado será la respuesta generada directamente por el modelo, sin acceso a herramientas externas.

No tengo acceso a información en tiempo real, por lo que no puedo decirte la hora exacta actual en Lima, Perú.

Sin embargo, puedo darte información útil:

- **Zona horaria**: Lima está en UTC-5 (Hora Estándar de Perú)
- **Diferencias horarias comunes**:
  - 2 horas menos que Argentina/Chile
  - Misma hora que Colombia/Ecuador
  - 1 hora más que México (centro)
  - 5 horas menos que España

Para conocer la hora exacta actual en Lima, te recomiendo:
- Buscar "hora en Lima" en Google
- Usar aplicaciones de reloj mundial
- Consultar sitios web como timeanddate.com

¿Te gustaría que te ayude a calcular la diferencia horaria con algún otro lugar específico?

Agregando herramientas

Para hacerlo más interesante, podemos darle acceso a la herramienta current_time, incluida en el paquete strands-tools.

from strands import Agent
from strands_tools import current_time

# Crear agente con acceso a herramientas
agent = Agent(tools=[current_time])

# Pregunta al agente
message = """
¿Qué hora es en Lima, Perú?
"""

agent(message)

Ahora el agente no solo depende del modelo: usa la herramienta para consultar la hora actual en Lima y responde con precisión.

Tool #1: current_time
La hora actual en Lima, Perú es **10:03:24 AM** (29 de septiembre de 2025).

Lima se encuentra en la zona horaria UTC-5 (también conocida como America/Lima), y actualmente no observa el horario de verano, por lo que mantiene la misma diferencia horaria durante todo el año.

Creando nuestra propia herramienta

La verdadera potencia de Strands Agents está en definir nuestras propias tools. Supongamos que queremos consultar el tipo de cambio oficial publicado por SUNAT.

Si no agregamos una herramienta, el modelo responderá con datos aproximados o dirá que no tiene acceso a esa información.

No tengo acceso a herramientas que me permitan consultar el tipo de cambio actual de SUNAT en tiempo real. Las funciones disponibles son para cálculos matemáticos y obtener la hora actual, pero no para consultar APIs de tipo de cambio.

Para solucionarlo, definimos una función en Python con el decorador @tool:

from strands import Agent, tool
from strands_tools import calculator, current_time
import requests
from datetime import datetime

@tool
def tipo_cambio_sunat() -> dict:
    """
    Obtiene el tipo de cambio del día de hoy desde SUNAT.
    
    Returns:
        dict: Diccionario con fecha, tipo de cambio compra y venta
              Ejemplo: {"fecha": "29/09/2025", "compra": 3.494, "venta": 3.502}
    """
    try:
        # Hacer request a la URL de SUNAT
        url = "https://www.sunat.gob.pe/a/txt/tipoCambio.txt"
        response = requests.get(url, timeout=10)
        response.raise_for_status()
        
        # Parsear la respuesta
        # Formato esperado: 29/09/2025|3.494|3.502|
        data = response.text.strip()
        parts = data.split('|')
        
        if len(parts) < 3:
            raise ValueError("Formato de respuesta inesperado de SUNAT")
        
        fecha = parts[0]
        compra = float(parts[1])
        venta = float(parts[2])
        
        return {
            "fecha": fecha,
            "compra": compra,
            "venta": venta,
            "moneda": "USD/PEN"
        }
        
    except requests.RequestException as e:
        return {"error": f"Error al conectar con SUNAT: {str(e)}"}
    except (ValueError, IndexError) as e:
        return {"error": f"Error al procesar datos de SUNAT: {str(e)}"}
    except Exception as e:
        return {"error": f"Error inesperado: {str(e)}"}

# Crea un agente con nuestra tool y tools de la comunidad
agent = Agent(tools=[calculator, current_time, tipo_cambio_sunat])

# Realiza una pregunta al agente con las herramientas disponibles
message = """
¿Cuál es el tipo de cambio de hoy según SUNAT? Y si tengo 100 dólares, ¿cuántos soles serían al tipo de cambio de venta?
"""
agent(message)

Con esto, el agente invoca la API de SUNAT, obtiene el tipo de cambio y lo combina con la calculadora para responder correctamente.

Te ayudo a consultar el tipo de cambio de hoy según SUNAT y hacer el cálculo de conversión.
Tool #1: tipo_cambio_sunat
Ahora calculemos cuántos soles serían 100 dólares al tipo de cambio de venta:
Tool #2: calculator
## Tipo de cambio SUNAT - 29/09/2025

**Tipo de cambio del día:**
- **Compra**: S/ 3.494 por dólar
- **Venta**: S/ 3.502 por dólar

**Conversión de tus 100 dólares:**
- Al tipo de cambio de venta: **100 USD = S/ 350.20**

Esto significa que si vendes 100 dólares americanos hoy, recibirías 350.20 soles peruanos según el tipo de cambio oficial de SUNAT.

Conclusión

Strands Agents facilita la construcción de agentes de IA sobre AWS al abstraer la complejidad del agent loop y permitir que los desarrolladores se enfoquen en lo importante: crear herramientas que conecten al LLM con datos y servicios reales.

• Con unas pocas líneas de código podemos pasar de un agente que responde con conocimiento general a uno que accede a información actualizada y confiable.
• Gracias a la integración nativa con Amazon Bedrock, es posible crear agentes productivos sin preocuparse por la infraestructura del modelo.
• Y lo más poderoso: podemos extender las capacidades del agente creando tools que respondan a las necesidades de cada negocio.

Este es solo el inicio. El siguiente paso es explorar cómo orquestar múltiples agentes, desplegarlos en arquitecturas serverless (como AWS Lambda o Step Functions) y habilitar escenarios más avanzados de automatización con IA generativa.

Creando Agentes de IA con Strands Agents was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ejemplo Práctico: Creando un feature flag

1. Ve a AWS AppConfig (dentro de AWS Systems Manager), entra a Applications → Create application, ingresa un nombre para la aplicación y haz clic en Create application.

2. Dentro de la aplicación, ve a Environments → Create environment, ingresa un nombre (p. ej., prod) y haz clic en Create environment.

3. Ve a Configuration profiles → Create configuration profile, coloca un nombre (p. ej., FraudFlags), selecciona Configuration type = Feature flags y haz clic en Next.

4. A continuación ingresa un Flag key (p. ej., enable-new-fraud-model), deja State = Disabled, haz clic en Next y luego en Save and continue to deploy.

5. Elige el Environment (p. ej., prod), selecciona la Deployment strategy (AllAtOnce esta bien para pruebas) y haz clic en Start deployment

6. Crea una función Lambda (Python 3.12) con las siguientes características:

• Variables de entorno:
• APPCFG_APPLICATION=BankingPlatform
• APPCFG_ENVIRONMENT=prod
• APPCFG_PROFILE=FraudFlags
• Layers → Add layer → AWS layers: agrega AWS AppConfig Lambda Extension.
• Role (IAM) con: appconfig:StartConfigurationSession, appconfig:GetLatestConfiguration, appconfig:GetConfiguration

Este es el código de la prueba para la Lambda:

import json
import logging
import os
import sys
import urllib.request

# Logger básico
logger = logging.getLogger()
logger.setLevel(logging.INFO)
if not logger.handlers:
    h = logging.StreamHandler(sys.stdout)
    h.setFormatter(logging.Formatter("%(asctime)s [%(levelname)s] %(message)s"))
    logger.addHandler(h)

# Vars de entorno (defínelas en la consola)
APP     = os.environ["APPCFG_APPLICATION"]    # AppEjemplo
ENV     = os.environ["APPCFG_ENVIRONMENT"]    # prod
PROFILE = os.environ["APPCFG_PROFILE"]        # FraudFlags

# Endpoint del AppConfig Agent (Lambda Extension)
APPCFG_URL = f"http://localhost:2772/applications/{APP}/environments/{ENV}/configurations/{PROFILE}"

def lambda_handler(event, context):
    # 1) Leer feature flags nativos desde el Agent
    with urllib.request.urlopen(APPCFG_URL, timeout=1.5) as resp:
        cfg = json.loads(resp.read().decode("utf-8"))

    # 2) Tomar el estado del release flag
    enabled = cfg["enable-new-fraud-model"]["enabled"]

    # 3) SOLO logs (sin implementar nada de fraude)
    if enabled:
        logger.info("Nuevo modelo de fraude: **ACTIVADO** (release flag encendido)")
    else:
        logger.info("Nuevo modelo de fraude: **DESACTIVADO** (release flag apagado)")

    # 4) Respuesta mínima
    return {
        "statusCode": 200,
        "body": json.dumps({
            "flag": "enable-new-fraud-model",
            "enabled": enabled
        })
    }

7. Ejecuta la función Lambda; en CloudWatch Logs deberías ver un mensaje indicando que se está usando la versión antigua (flag desactivado).

8. En AppConfig, abre el flag enable-new-fraud-model, cambia el estado a Enabled (On) y haz clic en Save version.

9. En el Configuration profile, selecciona Start deployment, elige el Environment (p. ej., prod), define la Deployment strategy (para pruebas, AllAtOnce) y pulsa Start.

10. Vuelve a invocar la función Lambda; ahora los logs deberían indicar que se está usando la nueva versión (flag activado).

Buenas Practicas

Al implementar feature flags en nuestros sistemas, es importante seguir ciertas buenas prácticas para obtener el máximo beneficio y evitar posibles antipatrones. A continuación, presentamos algunas recomendaciones clave, junto con formas en que AWS AppConfig soporta o automatiza cada una:

• Desplegar funcionalidades de forma gradual: No actives un feature flag al 100% de tus usuarios de golpe. Es más seguro hacer rollout progresivo, observando métricas y feedback en cada incremento. AWS AppConfig facilita esto mediante Deployment Strategies configurables: puedes definir estrategias lineales (por ejemplo, aumentar 10% cada 5 minutos), exponenciales u otras, incluyendo un periodo de bake time para monitorear antes de continuar. En la consola de AppConfig, al iniciar un despliegue de configuración puedes escoger una estrategia predefinida (como AppConfig.Linear) o personalizar una estrategia a tu medida. De esta forma limitas el radio de impacto de cualquier problema potencial, tal como recomienda AWS Well-Architected.
• Habilitar la reversión automática (auto-rollback): Configura sistemas de monitoreo y alarmas que desencadenen la desactivación de un flag o la reversión de la configuración si algo anda mal. AWS AppConfig se integra con Amazon CloudWatch Alarms para este propósito. Puedes asociar una alarma (por ejemplo, por tasa de errores, latencia, etc.) a la implementación de un flag: si la alarma se dispara durante el rollout, AppConfig automáticamente revierte la configuración al estado anterior sin intervención humana. Esto es invaluable, pues la velocidad de reacción automática suele ser más rápida que la de un operador humano que tendría que notar el problema y apagar el flag manualmente.
• Validar el input de la configuración: Nunca asumas que quien cambia un valor en producción no puede cometer un error de tipeo o formato. Implementa validaciones sintácticas y semánticas para cada flag o parámetro. AWS AppConfig te permite adjuntar Validators a tus perfiles de configuración. Estos validadores pueden ser esquemas JSON (JSON Schema) que definen la estructura esperada y rangos válidos, o incluso funciones Lambda personalizadas para chequeos más complejos. Por ejemplo, puedes definir que un valor de porcentaje de descuento debe ser un número entre 0 y 100, o que un flag de nivel de log solo acepte “DEBUG”, “INFO”, “WARN”, “ERROR”. Si alguien introduce un valor fuera de esas reglas, AppConfig bloqueará la implementación antes de afectar a los clientes. Esto previene despliegues de configuraciones corruptas que podrían causar fallos o comportamientos inesperados en la app.
• Usar una capa de caché para la configuración en la aplicación: Aunque podríamos consultar el servicio de configuración en cada llamada, es más eficiente y resistente mantener una caché local de los flags en la aplicación. AWS proporciona el AppConfig Agent (y extensiones para Lambda, etc.), que actúa como intermediario entre tu aplicación y el servicio AppConfig. Este agente se encarga de obtener las configuraciones y feature flags de forma eficiente, manteniéndolas en memoria y actualizándolas en segundo plano, reduciendo la latencia y carga en tu aplicación. En producción, es considerado una mejor práctica usar el AppConfig Agent para consumir las configuraciones, ya que además maneja reconexiones y fallback si AppConfig (o la red) presenta problemas. En resumen, una caché/agent añade un buffer entre tu sistema y la fuente de verdad, mejorando el performance y evitando dependencia directa constante de la red para cada verificación de flag.
• Limpiar los feature flags obsoletos: Incorpora en tu proceso de desarrollo la eliminación de flags que ya no se necesitan. Los feature flags deberían tener un ciclo de vida: aquellos de uso temporal (como los release flags) deben ser marcados para su futura eliminación una vez que cumplen su propósito. AWS AppConfig ayuda en la gobernanza de esto: puedes etiquetar un flag como Short-term (corto plazo) y asignarle una fecha objetivo de deprecación. La consola de AppConfig incluso mostrará qué flags han sobrepasado su fecha marcándolos como “Overdue” (atrasados), facilitando al equipo identificar y eliminar esas referencias pendientes. Estas herramientas fomentan una buena higiene, evitando el temido flag rot donde decenas de toggles viejos complican el código. Adicionalmente, mantener documentado qué flags existen y quién es el responsable de quitarlos es una buena práctica organizativa.

Los feature flags, usados con disciplina, permiten separar el despliegue de código de la liberación de funcionalidades, reduciendo riesgos y mejorando la fiabilidad. Con AWS AppConfig es posible gestionarlos de manera centralizada, validando configuraciones, habilitando rollbacks automáticos y facilitando despliegues graduales. En conjunto, estas prácticas convierten el cambio en un proceso controlado y predecible, clave para la resiliencia de cualquier sistema en producción.

Feature Flags con AWS AppConfig: cambios seguros y confiables was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

He estado probando Kiro durante un par de semanas. Se trata del nuevo IDE potenciado con IA de Amazon Web Services (AWS) que trabaja mediante agentes inteligentes. Kiro es mucho más que una simple herramienta de autocompletado de código: su objetivo es aportar estructura al desarrollo asistido por IA mediante una filosofía llamada Spec-Driven Development (desarrollo dirigido por especificaciones). En otras palabras, Kiro integra de forma nativa prácticas recomendadas de ingeniería de software en el flujo de trabajo con IA, ayudándote a ir “del vibe coding al código viable” con buenas prácticas incorporadas. Este IDE agéntico (orientado a agentes) ofrece funciones fundamentales como especificaciones estructuradas (Specs), archivos de direccionamiento (Steering files) para contexto persistente, hooks inteligentes y un chat avanzado con IA, entre otras. A continuación describo mis primeras impresiones y aprendizajes al usar Kiro, desde entender el Spec-Driven Development hasta desarrollar un proyecto prototipo con su ayuda.

Desarrollo dirigido por especificaciones (Spec-Driven Development)

Spec-Driven Development (SDD) es la piedra angular de Kiro. En este enfoque, antes de escribir una sola línea de código, colaboramos con un agente de IA para redactar las especificaciones funcionales de lo que vamos a construir. Es decir, detallamos qué debe hacer el software y cómo debería hacerlo, y lo hacemos junto con la IA en el IDE. Kiro asiste en la generación de estos artefactos de planificación: desde los requerimientos iniciales hasta el diseño técnico y la lista de tareas a ejecutar, todo queda documentado de antemano. Este proceso nos fuerza (en el buen sentido) a pensar primero en la solución de forma estructurada, antes de sumergirnos en el código.

En concreto, Kiro convierte una idea de funcionalidad en un documento de especificación que pasa por tres fases:

1. Requisitos — Historias de usuario con criterios de aceptación (usando notación EARS) que describen el comportamiento esperado.

1. Diseño — Una descripción de la arquitectura y las decisiones técnicas: qué componentes, APIs o módulos se necesitan y cómo interactúan.

1. Tareas — Una lista de pasos o tickets de implementación discretos, rastreables y ordenados, que cubrirán todos los elementos para cumplir con los requisitos.

Al completar estas fases, obtenemos una guía paso a paso antes de comenzar a programar. Una vez acordada la especificación, los agentes de Kiro pueden proceder a implementar cada tarea, manteniéndonos siempre en control del proceso. Un aspecto poderoso es que Kiro incluso valida o complementa las tareas con pruebas automatizadas y otros artefactos de calidad. Por ejemplo, la herramienta genera casos de prueba unitarios y documentación conforme se van definiendo las tareas, asegurando que el código resultante esté respaldado por tests robustos desde el inicio. En resumen, el SDD en Kiro combina la velocidad de la IA con la rigurosidad de las buenas prácticas de ingeniería, antes incluso de escribir código fuente.

Primeros pasos con Kiro y archivos Steering

Para empezar con Kiro, lo primero es crear los Steering Files, que son archivos Markdown donde se guarda el contexto de tu proyecto. Gracias a ellos, la IA entiende desde el inicio de qué trata tu producto, qué tecnologías usas y cómo está organizado tu código, sin necesidad de repetirlo en cada conversación.

Con un par de clics, Kiro genera tres archivos base en la carpeta .kiro/steering:

• product.md: explica el propósito del producto y a quién va dirigido.

• tech.md: lista las tecnologías, frameworks y librerías que usas.

• structure.md: describe cómo está organizado el proyecto y sus convenciones.

Estos documentos funcionan como una “memoria” que guía a la IA y aseguran que el código sugerido se adapte a tu stack y estilo. Además, puedes añadir archivos personalizados según las necesidades de tu equipo. Lo bueno es que esto también se puede aplicar a proyectos que ya existen, no solo a los nuevos.

Con los steering en su lugar, el siguiente paso es crear tu primera especificación junto con el agente y empezar a transformar esas tareas en código real.

MCP en Kiro

Otro aspecto importante de Kiro son los MCP (Model Context Protocols), que funcionan como conectores para dar a la IA acceso seguro y actualizado a herramientas externas. En lugar de trabajar solo con el contexto local, los MCP permiten que Kiro consulte directamente servicios como repositorios, bases de datos o aplicaciones de productividad.

Un ejemplo práctico: probé el MCP de Vibe Design de Monday. Gracias a este conector, Kiro podía acceder a la información más reciente de la herramienta sin que yo tuviera que copiarla manualmente. Esto redujo alucinaciones y evitó depender de información desfasada del modelo, ya que la IA siempre trabajaba con datos en tiempo real.

Mi primer proyecto con Kiro

La mejor forma de entender una herramienta nueva es experimentar.

Para probar Kiro decidí implementar una pequeña aplicación web para ayudar a aprender japonés mediante repaso espaciado (spaced repetition system). Empezando desde cero, en cuestión de horas ya tenía un prototipo funcional.

La velocidad de desarrollo fue espectacular: Kiro se sintió como un co-desarrollador que ayudaba a pensar en arquitectura, a generar historias de usuario y a convertirlas en tareas concretas. Lo más sorprendente fue la calidad del código: pruebas unitarias, documentación básica y buenas prácticas incluidas desde el inicio.

Aunque era un proyecto sencillo, sirvió como prueba del poder de Kiro: pasar de idea a prototipo completo en pocos días, algo que normalmente tomaría semanas.

Conclusiones

Kiro todavía se encuentra en versión Public Preview (vista previa pública), lo que significa que la herramienta está en pleno desarrollo y evolución. En estas pocas semanas de uso he encontrado algún que otro fallo menor y ciertas limitaciones, pero es comprensible dado que el producto aún está madurando. A pesar de ello, la dirección que marca es muy prometedora. La forma en que desarrollamos software podría cambiar radicalmente en los próximos años gracias a IDEs con IA como Kiro. Personalmente, me pregunto cómo encajará Kiro (y el enfoque de Spec-Driven Development) en entornos empresariales más grandes: ¿Cómo cambiará la construcción de requerimientos junto a los Product Owners? ¿Qué impacto tendrá en las prácticas ágiles actuales? ¿Se redefinirán los roles del equipo? Por ahora solo lo he usado en proyectos pequeños y personales, pero los resultados me indican que las empresas que adopten la IA de manera robusta y organizada avanzarán más rápido que las que no lo hagan. Ya empiezan a surgir metodologías y frameworks que ponen a la IA como pieza fundamental del ciclo de desarrollo, y Kiro es un ejemplo tangible de esa tendencia.

Dicho esto, no todo son fortalezas. Una limitación actual para el público de habla hispana es que el soporte de Kiro para el desarrollo dirigido por especificaciones funciona solamente en inglés por el momento. La interfaz y los agentes están optimizados para entender y generar specs en inglés, por lo que intentar usar SDD en español no brinda todavía buenos resultados. Esperemos que con el tiempo añadan compatibilidad con otros idiomas, dado que sería un gran beneficio para la comunidad global de desarrolladores.

En conclusión, mi experiencia con Kiro ha sido muy positiva: trabajar con un IDE que actúa como un desarrollador senior acompañándote resulta tanto emocionante como productivo. Aunque Kiro apenas comienza su recorrido y quedan preguntas por responder, ya demuestra cómo la IA puede proporcionar estructura y acelerar la creación de software de calidad. Seguiré experimentando con esta herramienta y observando cómo evoluciona. Por ahora, puedo afirmar que Kiro me ha hecho replantear mi flujo de trabajo: después de probar el Spec-Driven Development, cuesta imaginar volver al vibe coding puro y desorganizado. El futuro del desarrollo de software asistido por IA luce verdaderamente interesante.

Kiro: Primeras impresiones del nuevo IDE con IA de AWS was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS Glue no trae soporte geoespacial de fábrica, pero podemos aprovechar Apache Sedona, un framework distribuido sobre Spark que entiende geometrías como puntos, líneas y polígonos.

En este artículo veremos:

• Cómo configurar y probar Apache Sedona en AWS Glue con un ejemplo mínimo.
• Un caso de uso práctico: asignar el UBIGEO a tiendas según sus coordenadas.

Configuración básica de Apache Sedona en AWS Glue

Antes de entrar al caso de uso, veamos cómo habilitar Sedona en Glue:

Sube a un bucket S3 los JARs necesarios:

• sedona-spark-shaded-3.3_2.12–1.7.1.jar
• geotools-wrapper-1.7.1–28.5.jar

Configura tu Job de Glue:

Entra a la pestaña Job Details y ve a la sección Advanced Properties. En el apartado Libraries ingresa lo siguiente en:

Dependent JARs path:

s3://<tu-bucket>/geotools-wrapper-1.7.1–28.5.jar,s3://<tu-bucket>/sedona-spark-shaded-3.3_2.12–1.7.1.jar

Additional Python modules path

apache-sedona==1.7.1

Con esto, tu Job ya puede ejecutar funciones espaciales como ST_Point, ST_GeomFromWKT, ST_Contains, entre otras.

Probar la configuración con un script mínimo

Carga el siguiente script de prueba en el Job de Glue para probar la configuración.

from pyspark.sql import SparkSession
from pyspark.sql.functions import expr

from sedona.register import SedonaRegistrator
from sedona.utils import SedonaKryoRegistrator, KryoSerializer

# ------------------------------------------------------------------------------------
# Inicializar Spark con Sedona
# ------------------------------------------------------------------------------------
spark = (
    SparkSession.builder
        .appName("SedonaDemo")
        .config("spark.serializer", KryoSerializer.getName)
        .config("spark.kryo.registrator", SedonaKryoRegistrator.getName)
        .getOrCreate()
)

SedonaRegistrator.registerAll(spark)

# ------------------------------------------------------------------------------------
# Demo: crear un DataFrame con coordenadas y un punto
# ------------------------------------------------------------------------------------
data = [(1, -77.042793, -12.046374)]  # id, longitud, latitud (ejemplo: Lima, Perú)
columns = ["id", "longitud", "latitud"]

df = spark.createDataFrame(data, columns)

df = df.withColumn(
    "geom",
    expr("ST_Point(CAST(longitud AS DECIMAL(24,20)), CAST(latitud AS DECIMAL(24,20)))")
)

print("=== Mostrar DataFrame con geometría ===")
df.show(truncate=False)


df.printSchema()

Ejecuta este script: deberías ver las columnas longitud, latitud y la geometría creada con ST_Point.

+---+----------+----------+-----------------------------+
|id |longitud  |latitud   |geom                         |
+---+----------+----------+-----------------------------+
|1  |-77.042793|-12.046374|POINT (-77.042793 -12.046374)|
+---+----------+----------+-----------------------------+

Caso de uso: asignar UBIGEO a tiendas

Imagina que tienes una cadena de tiendas en todo el país y que cada una guarda sus coordenadas (latitud/longitud).

Aunque esas coordenadas bastan para mostrarlas en un mapa, para fines de analítica de negocio y reportes regulatorios necesitas enriquecer los datos con:

• El UBIGEO oficial del distrito donde se ubica la tienda.
• El nombre del departamento, provincia y distrito.
• La posibilidad de calcular métricas agrupadas por nivel administrativo (ventas por distrito, penetración por provincia, etc.).

Esto lo podemos lograr uniendo las coordenadas de tiendas contra la cartografía distrital del INEI mediante Sedona en Glue.

Preparando los datos del INEI: de GeoPackage a WKT

El Instituto Nacional de Estadística e Informática (INEI) distribuye los límites distritales del Perú en formato GeoPackage (.gpkg). Este archivo contiene todos los polígonos de distritos junto con los códigos UBIGEO y los nombres oficiales de departamento, provincia y distrito.

El problema es que AWS Glue no lee GeoPackage directamente. Por eso, la mejor práctica es convertirlo localmente a un formato más amigable para Spark, como Parquet, y además transformar la geometría a WKT (Well-Known Text).

De esta forma, cuando carguemos el dataset en Glue, solo tenemos que aplicar ST_GeomFromWKT para reconstruir los polígonos.

a) Instalar dependencias en tu máquina

En un entorno local (puede ser un venv), instala:

python -m pip install geopandas pyarrow

Estas librerías te permiten leer archivos geoespaciales y exportarlos a formatos analíticos modernos.

b) Conversión del GPKG a WKT

Crea y ejecuta el siguiente script de python para realizar la conversión:

import geopandas as gpd

# Abre el GeoPackage y la capa correcta
gdf = gpd.read_file("peru_distritos.gpkg", layer="ig_distrito")

# Convierte la geometría a WKT
gdf["geometry_wkt"] = gdf.geometry.apply(lambda geom: geom.wkt)

# Selecciona columnas útiles
df = gdf[["UBIGEO", "NOMBDEP", "NOMBPROV", "NOMBDIST", "geometry_wkt"]]

# Exporta a Parquet (ideal para Glue/Sedona)
df.to_parquet("distritos_wkt.parquet", index=False)

print("✅ Exportación lista: distritos_wkt.parquet")

c) Subir a S3

Una vez ejecutado el script, sube el archivo a tu bucket:

aws s3 cp distritos_wkt.parquet s3://<bucket>/distritos_wkt.parquet

Ahora tienes un dataset rápido de consultar en Glue, con las columnas:
UBIGEO, NOMBDEP, NOMBPROV, NOMBDIST, geometry_wkt.

Script de Glue: join espacial tiendas vs distritos

Con los polígonos del INEI en S3, podemos hacer el join espacial en Glue.
El flujo será:

1. Crear un DataFrame de tiendas (con latitud/longitud).
2. Leer distritos desde S3 (Parquet con WKT).
3. Convertir WKT a geometría Sedona con ST_GeomFromWKT.
4. Hacer el join espacial con ST_Contains(polygon, point).

Modifica el script del Job con el siguiente contenido:

from pyspark.sql import SparkSession
from pyspark.sql.functions import expr, col
from pyspark.sql.types import StringType
from sedona.register import SedonaRegistrator
from sedona.utils import SedonaKryoRegistrator, KryoSerializer

# ------------------------------------------------------------------------------------
# Inicializar Spark + Sedona
# ------------------------------------------------------------------------------------
spark = (
    SparkSession.builder
        .appName("SedonaTiendasUbigeo")
        .config("spark.serializer", KryoSerializer.getName)
        .config("spark.kryo.registrator", SedonaKryoRegistrator.getName)
        .getOrCreate()
)
SedonaRegistrator.registerAll(spark)

# ------------------------------------------------------------------------------------
# 1) Tiendas en memoria (ejemplo simple)
# ------------------------------------------------------------------------------------
tiendas_data = [
    ("T001", -77.042793, -12.046374),   # Lima
    ("T002", -77.059714, -12.095380),   # Magdalena
    ("T003", -71.535000, -16.398890),   # Arequipa
]
df_tiendas = spark.createDataFrame(tiendas_data, ["tienda_id", "longitud", "latitud"])

# Crear POINT (X=lon, Y=lat)
df_tiendas_geo = df_tiendas.withColumn(
    "point",
    expr("ST_Point(CAST(longitud AS DECIMAL(24,20)), CAST(latitud AS DECIMAL(24,20)))")
)

print("=== Tiendas ===")
df_tiendas_geo.show(truncate=False)

# ------------------------------------------------------------------------------------
# 2) Distritos desde S3 (Parquet con geometry_wkt del INEI)
# ------------------------------------------------------------------------------------
WKT_PATH = "s3://<bucket>/distritos_wkt.parquet"

df_wkt = spark.read.parquet(WKT_PATH)

# Asegurar que las columnas administrativas sean String
df_wkt = (
    df_wkt
    .withColumn("UBIGEO", col("UBIGEO").cast(StringType()))
    .withColumn("NOMBDEP", col("NOMBDEP").cast(StringType()))
    .withColumn("NOMBPROV", col("NOMBPROV").cast(StringType()))
    .withColumn("NOMBDIST", col("NOMBDIST").cast(StringType()))
)

# Construir la geometría Sedona a partir del WKT
df_wkt_geo = df_wkt.withColumn("polygon", expr("ST_GeomFromWKT(geometry_wkt)"))

print("=== Distritos ===")
df_wkt_geo.select("UBIGEO", "NOMBDEP", "NOMBPROV", "NOMBDIST").show(5, truncate=False)

# ------------------------------------------------------------------------------------
# 3) Join espacial: ST_Contains
# ------------------------------------------------------------------------------------
resultado = (
    df_tiendas_geo.join(
        df_wkt_geo.select("UBIGEO", "NOMBDEP", "NOMBPROV", "NOMBDIST", "polygon"),
        expr("ST_Contains(polygon, point)"),
        how="left"
    )
    .withColumnRenamed("UBIGEO", "ubigeo")
    .withColumnRenamed("NOMBDEP", "departamento")
    .withColumnRenamed("NOMBPROV", "provincia")
    .withColumnRenamed("NOMBDIST", "distrito")
)

print("=== Resultado: tiendas con UBIGEO asignado ===")
resultado.select("tienda_id", "latitud", "longitud", "ubigeo", "departamento", "provincia", "distrito") \
         .show(truncate=False)Ejemplo de salida

💡 Si nunca has usado Apache Sedona antes, fíjate en estos tres pasos clave dentro del script:

1. Crear los puntos de las tiendas con ST_Point: a partir de la longitud y latitud construimos un objeto geométrico que Sedona entiende.
2. Convertir los polígonos del INEI desde WKT con ST_GeomFromWKT: así Sedona transforma las geometrías guardadas como texto en verdaderos objetos espaciales.
3. Hacer el join espacial con ST_Contains: aquí ocurre la “magia”. Por cada tienda, Sedona evalúa en qué polígono (distrito) cae su punto y le asigna el UBIGEO y los nombres correspondientes.

Ejecuta el script y deberias recibir el siguiente resultado:

+---------+----------+----------+------+------------+---------+-----------------+
|tienda_id|latitud   |longitud  |ubigeo|departamento|provincia|distrito         |
+---------+----------+----------+------+------------+---------+-----------------+
|T001     |-12.046374|-77.042793|150101|LIMA        |LIMA     |LIMA             |
|T002     |-12.09538 |-77.059714|150120|LIMA        |LIMA     |MAGDALENA DEL MAR|
|T003     |-16.39889 |-71.535   |040101|AREQUIPA    |AREQUIPA |AREQUIPA         |
+---------+----------+----------+------+------------+---------+-----------------+

El resultado muestra que cada tienda fue asignada correctamente a su distrito según sus coordenadas:

• T001 cayó en el distrito LIMA (UBIGEO 150101).
• T002 se ubicó en MAGDALENA DEL MAR (UBIGEO 150120).
• T003 corresponde a AREQUIPA (UBIGEO 040101).

👉 Así comprobamos que el join espacial con Sedona funciona, enriqueciendo las coordenadas con información oficial de UBIGEO, departamento, provincia y distrito.

Conclusiones

• Con Apache Sedona en AWS Glue puedes extender tus pipelines ETL para manejar datos geoespaciales.
• Convertir el GeoPackage del INEI a Parquet con geometrías en WKT facilita la integración. La misma técnica puede reutilizarse con otros mapas temáticos (provincias, regiones, áreas de cobertura, zonas de riesgo), no solo con distritos, ampliando los casos de uso en analítica geoespacial.
• El join espacial permite asignar automáticamente UBIGEO y nombres administrativos a cualquier dataset con coordenadas.

Procesamiento geoespacial en AWS Glue con Apache Sedona was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Es una manera sencilla y directa de compartir datos a gran escala, sin necesidad de procesos adicionales. Para escenarios más avanzados — por ejemplo, cuando se requiere control de acceso, monetización o suscripciones — también existe AWS Data Exchange, que permite distribuir datasets de forma gestionada y con modelos comerciales más flexibles.

Esta opción resulta ideal para casos como imágenes satelitales, datasets científicos o archivos multimedia, donde cada usuario paga solo por lo que consume.

Cómo habilitar Requester Pays en un bucket

1. Vía AWS Console

1. Abre la consola de Amazon S3.
2. Selecciona el bucket que quieres configurar.
3. Selecciona la pestaña Propiedades.
4. En la sección Requester Pays, activa la opción “Los solicitantes pagan”.
5. Guarda los cambios.

2. Vía AWS CLI

aws s3api put-bucket-request-payment \
  --bucket nombre-del-bucket \
  --request-payment-configuration '{"Payer":"Requester"}'

Confirmar la configuración:

aws s3api get-bucket-request-payment --bucket nombre-del-bucket

Respuesta esperada:

{
    "Payer": "Requester"
}

Accediendo a un bucket con Requester Pays

Cuando un usuario accede al bucket, debe especificar el flag --request-payer requester. Ejemplo:

aws s3 cp s3://nombre-del-bucket/archivo.tif ./ \
  --request-payer requester

Si no incluye ese parámetro, la solicitud será rechazada.

Ejemplo práctico: descargando imágenes satelitales públicas con Requester Pays

Amazon mantiene el programa AWS Open Data, donde muchas instituciones publican datasets abiertos. Uno de los más usados es el de imágenes satelitales Landsat, alojado en el bucket usgs-landsat (en la región us-west-2).

Este bucket está configurado con Requester Pays: cualquiera puede acceder a las imágenes, pero el costo de descarga lo asume el solicitante.

1. Listar objetos (con --request-payer)

aws s3 ls s3://usgs-landsat/collection02/ --region us-west-2 --request-payer requester

2. Descargar un archivo específico

Por ejemplo, un archivo GeoTIFF de la colección Landsat 8:

aws s3 cp \
  s3://usgs-landsat/collection02/level-1/standard/oli-tirs/2013/030/030/LC08_L1TP_030030_20130320_20200913_02_T1/LC08_L1TP_030030_20130320_20200913_02_T1_thumb_small.jpeg . \
  --region us-west-2 \
  --request-payer requester

• --region es obligatorio porque el bucket está en us-west-2.
• --request-payer requester debe ir en todas las operaciones, de lo contrario obtendrás AccessDenied.

Buenas prácticas y consideraciones

• No se recomienda para contenido web de acceso masivo al público general (por ejemplo, un sitio web estático), porque los visitantes no tienen manera de pasar el flag --request-payer requester.
• Úsalo cuando el acceso se dé principalmente vía CLI, SDK o aplicaciones personalizadas.
• Siempre documenta a tus usuarios cómo deben acceder al bucket, incluyendo el parámetro --request-payer requester.

Conclusión

Amazon S3 Requester Pays es una solución simple pero poderosa para compartir datasets masivos de manera equitativa. Permite que investigadores, empresas y comunidades colaborativas accedan a datos como imágenes satelitales, genomics o logs sin que el costo recaiga únicamente en el propietario del bucket.

En resumen: si compartes datos a gran escala, deja que cada consumidor pague por lo que descarga y optimiza tus costos con Requester Pays.

Amazon S3 Requester Pays: qué es, cómo configurarlo y casos de uso reales was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Uno de los retos que enfrentamos en la integración continua es cuando necesitamos que nuestros procesos de construcción y prueba accedan a recursos que están dentro de nuestra VPC (Virtual Private Cloud), como servicios internos o APIs que no son accesibles desde internet. Un ejemplo de esta situación es la integración con herramientas de análisis de código como SonarQube que están alojadas en redes privadas.

Tradicionalmente, para solucionar esto, muchas organizaciones optan por usar agentes de integración continua personalizados, como runners de GitLab alojados en instancias EC2. Si bien esta solución puede ser eficaz, también presenta varios inconvenientes operativos. Debes encargarte de gestionar las instancias EC2, monitorear su disponibilidad y rendimiento, así como encargarte de las actualizaciones de seguridad y la escalabilidad. Este proceso puede convertirse en una carga operativa significativa a largo plazo.

¡Pero no te preocupes! Ahora existe una mejor manera de hacer esto con AWS CodeBuild y su nueva funcionalidad que permite usarlo como un managed GitLab runner con acceso a los recursos de tu VPC. Veamos cómo esta nueva característica puede simplificar enormemente tu flujo de trabajo de integración continua.

Crear la conexión entre Gitlab y CodeBuild

El primer paso que tenemos que realizar es conectar la cuenta de GitLab con los servicios de Code de AWS. Para realizar eso vamos a buscar el servicio de CodeBuild en la consola.

1. En la consola de AWS CodeBuild, ve a Settings > Connections y haz clic en Create Connection.

2. Selecciona GitLab como proveedor, ingresa un nombre para la conexión, y haz clic en Connect to GitLab.

3. Autoriza la conexión en GitLab haciendo clic en el botón Authorize AWS Connector for GitLab.

4. Haz clic en el botón de Connect.

5. La conexión está lista y deberias poder visualizarla.

Crear un proyecto de CodeBuild

Sigue estos pasos para configurar un proyecto de CodeBuild que utilice GitLab como proveedor de código fuente:

1. En la barra de navegación despliega la opción Build > Build Projects y haz clic en el botón Create build project.

2. Ingresa un nombre para el proyecto. Yo estoy nombrandolo gitlab-runner.

3. En la sección Managed default source credentials selecciona GitLab como Source Provider.

4. La primera vez que creamos el proyecto debemos configurar la conexión, para heco debemos hacer clic en la opción Managed default source credentials.

5. Debemos seleccionar el CodeConnection que configuramos en la sección previa y hacer clic en Save.

6. Luego deberemos seleccionar el repositorio de GitLab con el que queramos trabajar.

7. En la sección Primary source webhook events, debemos seleccionar la opción Rebuild every time a code change is pushed to this repository. En la opción Event Type debemos elegir WORKFLOW_JOB_QUEUED.

8. Deja las configuraciones restantes como predeterminadas y haz clic en Create build project para finalizar la creación del proyecto.

Crear el Pipeline en GitLab

El siguiente paso es configurar el pipeline en GitLab para ejecutar las tareas de CI/CD utilizando AWS CodeBuild. Sigue estos pasos para crear y configurar el archivo del pipeline:

1. En la raíz de tu repositorio de GitLab, crea un archivo llamado .gitlab-ci.yml con el siguiente contenido:

workflow:
  name: HelloWorld
stages:          # List of stages for jobs, and their order of execution
  - build

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  script:
    - echo "Hello World!"
  tags:
    - codebuild-gitlab-runner-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME

En el archivo, asegúrate de reemplazar la palabra “gitlab-runner” por el nombre de tu propio proyecto de CodeBuild. El resto del tag puede quedar tal como está, ya que las variables como $CI_PROJECT_ID, $CI_PIPELINE_IID y $CI_JOB_NAME serán automáticamente asignadas por GitLab.

Ejemplo:

tags:
  - codebuild-mi-proyecto-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME

Ver el Pipeline en Acción

Una vez que hayas guardado el archivo .gitlab-ci.yml, GitLab comenzará a ejecutar el pipeline. Para verificarlo:

• En GitLab, ve a la sección Build > Job dentro de tu repositorio y selecciona el job recién creado. Podrás ver los detalles de la ejecución.

• También puedes verificar la ejecución en AWS CodeBuild revisando el proyecto que creaste previamente.

¡Eso es todo! Con esta configuración, podrás utilizar AWS CodeBuild para gestionar los trabajos de CI/CD de GitLab, aprovechando la infraestructura gestionada de AWS.

Gitlab + CodeBuild: Managed Gitlab runners was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

La función de recompensa es el corazón del aprendizaje por refuerzo en AWS DeepRacer. Define las reglas que guían al vehículo autónomo a tomar decisiones a lo largo de la pista, asignando puntos en función de qué tan bien sigue estas reglas.

¿Qué es una Función de Recompensa?

En DeepRacer, la función de recompensa es una pieza de código que calcula una puntuación cada vez que el coche completa un paso en la pista. Esto sucede de la siguiente manera:

1. Paso del coche: El coche se mueve una pequeña distancia basada en su velocidad y ángulo de dirección.
2. Evaluación: Después de cada paso, DeepRacer llama a la función de recompensa y le pasa los parámetros actuales.
3. Cálculo de la recompensa: La función de recompensa devuelve un valor que se añade a la recompensa acumulada del coche para esa carrera.

El objetivo del modelo es maximizar esta recompensa total. Por lo tanto, una función de recompensa bien diseñada incentiva al coche a comportarse de la manera deseada, como seguir la pista, mantener una velocidad constante o evitar salirse de la pista.

Anatomía Básica de una Función de Recompensa

A nivel técnico, la función de recompensa se implementa en Python. Aquí te mostramos una estructura básica:

def reward_function(params):
    '''
    Ejemplo de cómo recompensar al agente por seguir la línea central
    '''
    
    # Leer los parámetros de entrada
    track_width = params['track_width']
    distance_from_center = params['distance_from_center']
    
    # Calcular 3 marcadores que están a diferentes distancias de la línea central
    marker_1 = 0.1 * track_width
    marker_2 = 0.25 * track_width
    marker_3 = 0.5 * track_width
    
    # Dar una recompensa mayor si el coche está más cerca de la línea central y viceversa
    if distance_from_center <= marker_1:
        reward = 1.0
    elif distance_from_center <= marker_2:
        reward = 0.5
    elif distance_from_center <= marker_3:
        reward = 0.1
    else:
        reward = 1e-3  # probablemente se estrelló o está cerca de salirse de la pista
    
    return float(reward)

Desglocemos los elementos importantes:

1. params: Un diccionario que contiene todas las variables que puedes usar en tu función de recompensa. Estas variables describen el estado actual del coche en la pista, como la velocidad, la posición en la pista, el ángulo de dirección, entre otros.
2. Lógica de recompensa: Basado en las variables extraídas, puedes diseñar reglas para dar una recompensa mayor cuando el coche sigue las pautas que consideres óptimas. En este caso, hemos asignado una recompensa mayor si el coche está más cerca del centro de la pista.
3. Retorno: La función siempre debe devolver un valor numérico de tipo flotante, que será usado por el agente para aprender y ajustar su comportamiento.

Parámetros Disponibles en la Función de Recompensa

Existen diversas parámetros que AWS DeepRacer provee para ayudarte a crear una función de recompensa efectiva. En la documentación puedes ver el listado completo.

Algunas de las más comunes son:

• track_width: El ancho de la pista.
• distance_from_center: Qué tan lejos está el coche del centro de la pista.
• all_wheels_on_track: Un booleano que indica si todas las ruedas están dentro de los límites de la pista.
• speed: La velocidad actual del coche.
• steering_angle: El ángulo de dirección en grados.
• waypoints: La lista ordenada que describe el recorrido de la pista.
• closest_waypoints: Los dos puntos más cercanos en la pista al coche.

Estas variables se pueden combinar para crear reglas más complejas. Por ejemplo, podrías incrementar la recompensa si el coche mantiene una velocidad constante y está alineado con la dirección de la pista.

En la siguiente función de recompensa podemos ver como se combinan dos parámetros para crearla. La función de recompensa premia al vehículo autónomo por mantenerse en la pista (utilizando el parámetro all_wheels_on_track) y moverse a una velocidad adecuada (con el parámetro speed). Si el coche se sale de la pista, recibe una recompensa muy baja. Si está en la pista pero va demasiado lento, la recompensa es moderada. Solo recibe la máxima recompensa si permanece en la pista y mantiene una velocidad superior al umbral definido, incentivando así un comportamiento óptimo.

def reward_function(params):
    '''
    Ejemplo de uso de all_wheels_on_track y la velocidad
    '''

    # Leer las variables de entrada
    all_wheels_on_track = params['all_wheels_on_track']
    speed = params['speed']

    # Definir el umbral de velocidad basado en tu espacio de acciones
    SPEED_THRESHOLD = 1.0

    if not all_wheels_on_track:
        # Penalizar si el coche se sale de la pista
        reward = 1e-3
    elif speed < SPEED_THRESHOLD:
        # Penalizar si el coche va demasiado lento
        reward = 0.5
    else:
        # Alta recompensa si el coche se mantiene en la pista y va rápido
        reward = 1.0

    return float(reward)

¿Qué son los Waypoints y cómo usarlos en la Función de Recompensa?

Cada pista tiene una secuencia de waypoints, y cada uno está definido por un par de coordenadas (x,y). Estos puntos te permiten calcular la dirección que el coche debería seguir, así como su progreso en relación a la pista.

DeepRacer tiene muchas pistas disponibles y los waypoints son públicos dentro del repositorio aws-deepracer-community/deepracer-race-data

Puedes descargar y visualizar estos puntos dentro de un jupyter notebook: https://github.com/claudiamp/visualize-track-deepracer/blob/main/Visualize_Track.ipynb

Cómo Crear una Función de Recompensa Basada en Waypoints

En la siguiente función de recompensa podemos ver como se ajusta la recompensa del vehículo según la alineación de su dirección con la dirección de la pista. Calcula la dirección de la pista entre los dos puntos de referencia más cercanos (closest_waypoints) y compara esta dirección con la dirección actual del coche (heading). Si la diferencia entre estas direcciones es mayor que un umbral definido (DIRECTION_THRESHOLD), se penaliza la recompensa reduciéndola a la mitad. Esto incentiva al coche a mantener una dirección alineada con la pista para mejorar su rendimiento.

# Coloca la declaración de importación fuera de la función (bibliotecas soportadas: math, random, numpy, scipy y shapely)
# Ejemplos de importación de las bibliotecas disponibles
#
# import math
# import random
# import numpy
# import scipy
# import shapely
import math

def reward_function(params):
    ###############################################################################
    '''
    Ejemplo de uso de waypoints y heading para alinear el coche en la dirección correcta
    '''

    # Leer las variables de entrada
    waypoints = params['waypoints']
    closest_waypoints = params['closest_waypoints']
    heading = params['heading']

    # Inicializar la recompensa con un valor típico
    reward = 1.0

    # Calcular la dirección de la línea central basándose en los waypoints más cercanos
    next_point = waypoints[closest_waypoints[1]]
    prev_point = waypoints[closest_waypoints[0]]

    # Calcular la dirección en radianes usando arctan2(dy, dx), el resultado está en el rango (-pi, pi)
    track_direction = math.atan2(next_point[1] - prev_point[1], next_point[0] - prev_point[0])
    # Convertir a grados
    track_direction = math.degrees(track_direction)

    # Calcular la diferencia entre la dirección de la pista y la dirección actual del coche
    direction_diff = abs(track_direction - heading)
    if direction_diff > 180:
        direction_diff = 360 - direction_diff

    # Penalizar la recompensa si la diferencia es demasiado grande
    DIRECTION_THRESHOLD = 10.0
    if direction_diff > DIRECTION_THRESHOLD:
        reward *= 0.5

    return float(reward)

Conclusión

Optimizar la función de recompensa es crucial para mejorar el rendimiento de tu modelo de AWS DeepRacer. Al diseñar una función de recompensa efectiva, puedes guiar al vehículo autónomo para que tome decisiones más inteligentes y se comporte de manera óptima en la pista. Desde recompensar al coche por mantener una buena alineación con la pista hasta ajustar la recompensa según la velocidad y la proximidad al centro, cada detalle cuenta para lograr el comportamiento deseado. Aprovecha los parámetros disponibles y experimenta con diferentes estrategias para encontrar la configuración que mejor se adapte a tus objetivos. Con una función de recompensa bien afinada, estarás un paso más cerca de dominar el circuito y optimizar tu modelo de DeepRacer.

Optimizando tu Modelo de AWS DeepRacer: Una Guía para Diseñar Funciones de Recompensa was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.

En muchos proyectos de IoT, la capacidad de acceder y solucionar problemas de manera remota es fundamental. Ya sea para diagnosticar fallos o realizar ajustes rápidos, contar con un acceso remoto seguro a dispositivos como la Raspberry Pi 5 es clave para mantener la continuidad del proyecto. En este tutorial, te guiaré a través del proceso de configuración y uso de AWS IoT Device Client para acceder remotamente a tu Raspberry Pi 5, asegurando que siempre puedas estar preparado para realizar troubleshooting cuando sea necesario.

Requisitos Previos

Antes de comenzar, asegúrate de tener lo siguiente:

• Una Raspberry Pi 5 con una instalación limpia de Raspberry Pi OS.

Paso 1: Crear un “thing”

1. En la consola de AWS IoT elegimos a Manage, All devices y Create things.
2. En la pantalla Create Things hacemos clic en Next.
3. En la pantalla Specify thing properties ingresamos un nombre en Thing name para nuestro dispositivo y luego hacemos clic en Next.
4. En la pantalla Configure device certificate — optional dejamos seleccionada la opción Auto-generate a new certificate (recommended) y hacemos clic en Next.
5. En la pantalla Attach Policies to certificate — optional hacemos clic en la opción Create Policy
6. En la pantalla Create Policy ingresamos un nombre para la política en el campo Policy Name. En la sección Policy Document seleccionamos JSON y pegamos la siguiente política.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iot:Publish",
        "iot:Subscribe",
        "iot:Receive",
        "iot:Connect"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

7. Regresamos a la pantalla de creación del objeto, seleccionamos la política creada y hacemos clic en Create thing.

8. Nos aparecerá una pantalla para descargar los certificados. Necesitamos descargar el Device Certificate, Private key file y ROOT CA Certificate.

9. Debemos copiar los 3 archivos a una carpeta dentro del Raspberry Pi y darle los permisos adecuados a los certificados

chmod 700 ~/certs
chmod 600 ~/certs/pi-private.pem.key

10. También debemos anotar el endpoint que se encuentra en la pantalla de Settings de la consola de AWS IOT para la configuración que se realizará a continuación.

Paso 2: Instalar y Configurar AWS IoT Device Client en la Raspberry Pi

1. Lo primero que necesitamos hacer es asegurarnos de que la Raspberry Pi esté actualizada y tenga todas las dependencias necesarias.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install cmake libssl-dev vim

2. Clonar el repositorio de AWS IoT Device Client:

git clone https://github.com/awslabs/aws-iot-device-client
cd aws-iot-device-client

3. Compilar el cliente:

mkdir build
cd build
cmake ../
cmake - build . - target aws-iot-device-client

4. Crear un archivo de configuración en la ruta /etc/.aws-iot-device-client/aws-iot-device-client.conf con el siguiente contenido. Asegurate de cambiar los datos entre <> con la información de los certificados y rutas obtenidas en el paso 1.

{
  "endpoint": "<tuendpoint>-ats.iot.<region>.amazonaws.com",
  "cert": "<ruta al certificado del dispositivo (.pem.crt)>",
  "key": "<ruta a la llave privada (.pem.key)>",
  "root-ca": "<ruta a AmazonRootCA1.pem>",
  "thing-name": "<Nombre del thing creado en el paso 1>",
  "logging": {
    "level": "WARN",
    "type": "FILE",
    "file": "/var/log/aws-iot-device-client/aws-iot-device-client.log",
    "enable-sdk-logging": true,
    "sdk-log-level": "WARN",
    "sdk-log-file": "/var/log/aws-iot-device-client/sdk.log"
  },
  "jobs": {
    "enabled": false,
    "handler-directory": "/etc/.aws-iot-device-client/jobs"
  },
  "tunneling": {
    "enabled": true
  },
  "device-defender": {
    "enabled": false,
    "interval": 300
  },
  "fleet-provisioning": {
    "enabled": false,
    "template-name": "",
    "template-parameters": "",
    "csr-file": "",
    "device-key": ""
  },
  "samples": {
    "pub-sub": {
      "enabled": false,
      "publish-topic": "",
      "publish-file": "/etc/.aws-iot-device-client/pubsub/publish-file.txt",
      "subscribe-topic": "",
      "subscribe-file": "/etc/.aws-iot-device-client/pubsub/subscribe-file.txt"
    }
  },
  "config-shadow": {
    "enabled": false
  },
  "sample-shadow": {
    "enabled": false,
    "shadow-name": "",
    "shadow-input-file": "",
    "shadow-output-file": ""
  }
}

4. Instalaremos el cliente y lo configuremos para que funcione como servicio.

cd ../
sudo ./setup.sh

Deberás seleccionar las siguientes opciones en la configuración del setup:

Paso 3: Conectarse por el tunel

1. En la consola de AWS IoT elegimos a Manage, All devices y hacemos clic en el nombre de nuestro dispositivo.
2. En la pagina de nuestro dispositivo haremos clic en Create secure tunnel.

3. Dejaremos las opciones por defecto y haremos clic en Next.

4. En la siguiente pantalla seleccionaremos Confirm and create.

5. Nuestro tunel ya está creado, para conectarnos debemos hacer clic en Connect e ingresar el usuario y contraseña para ingresar a nustro pi.

6. Una vez ingresado nuestra contraseña, contaremos con un shell de nuestra Raspberry PI dentro de la consola de AWS.

7. En caso la conexión se pierda, se puede generar nuevos llaves de acceso haciendo clic en Generate new access tokens y volvernos a connectar haciendo clic en Connect.

Conexión remota a una Raspberry Pi 5 utilizando AWS IoT Device Client was originally published in Caleidos on Medium, where people are continuing the conversation by highlighting and responding to this story.