DEV Community: olcortesb

⚙️ Control PID con AWS Lambda Durable Functions: Simulando un PID y un reactor ⚗️ con estado persistente ☁️

olcortesb — Tue, 10 Feb 2026 09:04:24 +0000

Introducción

Recordando conceptos básicos de mis años de Ing. Electrónica y cómo ha evolucionado, pensaba en cómo sería la implementación de un controlador PID completamente cloud, al menos a modo práctico, en la operativa posiblemente no sea aplicable a todos los sistemas de control. Los controladores PID (Proporcional-Integral-Derivativo) tradicionalmente requieren ejecución continua, estado persistente y ciclos de control precisos. ¿Cómo implementar esto en un entorno serverless donde las funciones son efímeras por naturaleza?

En este artículo presento una prueba de concepto que combina control PID con AWS Lambda Durable Functions, demostrando cómo crear sistemas de control de larga duración sin "pagar" por tiempo de espera entre iteraciones. La implementación simula un reactor con control de temperatura, utilizando las nuevas capacidades de Lambda para workflows con estado persistente.

🎯 ¿Qué es un Controlador PID?

Un controlador PID es un mecanismo de control por retroalimentación ampliamente utilizado en sistemas industriales. Calcula una señal de control basándose en tres elementos:

Proporcional (P): Responde proporcionalmente al error actual entre el setpoint (SP) y el valor del proceso (PV). Cuanto mayor es el error, mayor es la acción correctiva
Integral (I): Corrige el error acumulado en el tiempo, eliminando el error residual en estado estacionario
Derivativo (D): Anticipa cambios futuros basándose en la tasa de cambio del error, proporcionando amortiguación al sistema

La fórmula básica del PID es:

CV(t) = Kp·e(t) + Ki·∫e(t)dt + Kd·de(t)/dt

Donde:

CV: Control Variable o salida del controlador normalmente en porcentaje (0-100%)
e(t): Error = SP - PV (Setpoint - Process Variable)
SP: Setpoint o valor deseado
PV: Process Variable o valor actual medido
Kp, Ki, Kd: Constantes de ajuste o ganancias del controlador

Tipos de respuesta:

La relación entre las constantes y su aplicación sobre distintos sistemas puede producir tres tipos de respuestas conocidas:

Subamortiguada (underdamped): Oscila antes de estabilizarse (overshoot + oscilaciones)
Críticamente amortiguada (critically damped): Converge lo más rápido posible sin overshoot
Sobreamortiguada (overdamped): Converge lentamente sin overshoot

🚀 ¿Qué son AWS Lambda Durable Functions?

AWS Lambda Durable Functions es una característica nativa que permite crear workflows de larga duración con estado persistente. A diferencia de las funciones Lambda tradicionales, las Durable Functions pueden:

Suspenderse sin costo: context.wait() pausa la ejecución sin cargos de cómputo
Mantener estado: Checkpointing automático en cada step
Recuperarse de fallos: Reinicia desde el último checkpoint exitoso
Ejecutar por horas/días: Sin mantener la Lambda activa continuamente

Referencia oficial: AWS Lambda Durable Functions

Primitivas Core del SDK

from aws_durable_execution_sdk_python import (
    DurableContext,
    durable_execution,
    durable_step,
)
from aws_durable_execution_sdk_python.config import Duration

@durable_step
def my_step(step_context, arg):
    # Lógica con checkpointing automático
    return result

@durable_execution
def lambda_handler(event, context: DurableContext):
    result = context.step(my_step(arg))
    context.wait(Duration.from_seconds(60))  # SIN COSTO
    return result

🏗️ Arquitectura de la POC

Bueno, si has llegado leyendo hasta aquí ya es hora de jugarnos, construir e ir a la sustancia. Vamos a implementar una POC que nos permita simular en Lambda Durable Functions tanto un PID como un reactor, persistiendo sus estados internamente y gestionando el flujo con las primitivas del SDK.

El sistema sería el que se muestra en la imagen a continuación.

Bien, ahora, si tuviéramos que simular esto con la versión tradicional de Lambda, necesitaríamos un par de SQS al menos para gestionar el estado y la invocación de las lambdas. La implementación que proponemos sigue este flujo:

Componentes principales:

API Gateway: Recibe el setpoint deseado
PID Controller Lambda: Ejecuta el loop de control con estado persistente
Reactor Simulator Lambda: Simula el comportamiento físico del reactor
CloudWatch Metrics: Almacena métricas para visualización

🛠️ Implementación

Lambda PID Controller

El controlador implementa el algoritmo PID completo usando Durable Functions. El código completo está disponible en el repositorio:

📁 Código fuente: terraform/src/pid_controller/app.py

Componentes principales:

@durable_step calculate_pid(): Implementa el algoritmo PID en forma paralela discreta
@durable_step invoke_reactor(): Invoca la Lambda del reactor para obtener la nueva temperatura
@durable_step publish_metrics(): Publica métricas a CloudWatch (SetpointTemperature, ActualTemperature, TemperatureError)
@durable_execution lambda_handler(): Orquesta el loop de control con context.step() y context.wait()

Ecuación PID implementada:

error = setpoint - current_temp
integral += error * SAMPLE_TIME
derivative = (error - last_error) / SAMPLE_TIME
cv = KP * error + KI * integral + KD * derivative
cv = max(0, min(100, cv))  # Limitar entre 0-100

Lambda Reactor Simulator

El simulador implementa un modelo físico simplificado del reactor. El código completo está disponible en el repositorio:

📁 Código fuente: terraform/src/reactor_simulator/app.py

Componentes principales:

@durable_step simulate_reactor_step(): Simula el comportamiento térmico del reactor
@durable_execution lambda_handler(): Recibe el control value y retorna la nueva temperatura

Física del reactor implementada:

# Enfriamiento natural (Ley de enfriamiento de Newton)
cooling = (current_temp - AMBIENT_TEMP) * COOLING_RATE

# Calentamiento por control value (0-100)
heating = control_value * HEATING_EFFICIENCY

# Cambio de temperatura con inercia térmica
temp_change = heating - cooling
new_temp = current_temp + temp_change * (1 - THERMAL_INERTIA)

🚀 Despliegue con Terraform

Inicialmente el despliegue lo realizaría con AWS SAM, sin embargo encontré algunos issues con la integración del SDK con AWS SAM. La alternativa era agregarle una lambda layer, pero no quería probar Lambda Durable fuera de la configuración más básica, por lo tanto me mudé a Terraform para el despliegue.

Configuración de Lambda Durable

En Terraform, las funciones durable requieren configuración específica:

resource "aws_lambda_function" "pid_controller" {
  filename         = data.archive_file.pid_controller.output_path
  function_name    = "${var.project_name}-pid-controller"
  role             = aws_iam_role.pid_controller.arn
  handler          = "app.lambda_handler"
  runtime          = "python3.13"
  timeout          = 900
  memory_size      = 128
  publish          = true

  durable_config {
    execution_timeout = 3600  # 1 hora
    retention_period  = 7     # 7 días
  }

  logging_config {
    log_format = "JSON"
    log_group  = aws_cloudwatch_log_group.pid_controller.name
  }

  environment {
    variables = {
      REACTOR_FUNCTION_NAME = "${aws_lambda_function.reactor_simulator.function_name}:prod"
      KP                    = "0.50"
      KI                    = "0.0004"
      KD                    = "0.20"
      SAMPLE_TIME           = "60"
      MAX_ITERATIONS        = "40"
    }
  }
}

IAM Policy para Durable Functions

resource "aws_iam_role_policy_attachment" "pid_controller_durable" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicDurableExecutionRolePolicy"
  role       = aws_iam_role.pid_controller.name
}

🧪 Pruebas y Simulación

Cómo lo probamos: dejamos un valor esperado para que el PID use como referencia realizando un CURL al API Gateway y empezamos a ver cómo se comporta el sistema.

Iniciar Control PID

curl -X POST https://xxxxx.execute-api.us-east-1.amazonaws.com/prod/setpoint \
  -H "Content-Type: application/json" \
  -d '{"setpoint": 75.0}'

Respuesta:

{
  "message": "PID control completed - 40 iterations",
  "final_temperature": 74.82,
  "setpoint": 75.0,
  "iterations": 40
}

¿Cómo se ven los Steps?

Una nueva pestaña (1) nos mostrará cómo se ven las ejecuciones de toda la Lambda Durable Function, indicando qué versión (2) está corriendo, indicando un ID (3) y el estado de la ejecución (4).

La relación de las máquinas de estado de las dos lambdas

Una de las features más interesantes es que podemos aprovechar la persistencia del estado evitando colocar SQS, DynamoDB, S3 dependiendo del caso, y ahora podemos llamar a otra función directamente gracias a la gestión de la máquina de estado.

En la imagen arriba, 1 y 2 muestran las interacciones entre los steps y los waits, que indicamos antes en el presente artículo. Lo interesante es que se ve claramente el invoke_reactor que para nuestra simulación es invocar a otra Lambda Durable Function que permitirá simular el estado del reactor, guardando la temperatura y la inercia térmica del mismo.

Ya dentro de la Lambda del reactor podemos ver cómo se ejecutan los pasos que recalculan el comportamiento del reactor respecto a la temperatura, simulando el comportamiento real de un reactor.

La respuesta final:

Para visualizar de manera aproximada cómo se estudian las gráficas de los sistemas PID, creé un dashboard que pueden consultar en el código fuente:

Código en Terraform del dashboard

Los valores configurados son para obtener una respuesta críticamente amortiguada que sería el objetivo a perseguir para un sistema de control tipo PID. Los valores los encontré realizando una simulación en Python que muestro a continuación.

Simulación Local

Sí, esto podría ser otro post, pero he disfrutado tanto haciendo este artículo que lo dejo por aquí. Como quería refrescar cómo funcionaba el PID, me creé un proyecto que es básicamente un simulador Python para probar diferentes configuraciones de PID. En base a esta simulación encontré los valores que colocamos al sistema simulado en la POC.

cd simulation

# Configurar parámetros en .env
cat > .env << EOF
KP=0.50
KI=0.0004
KD=0.20
SETPOINT=75.0
SAMPLE_TIME=30
MAX_ITERATIONS=40
THERMAL_INERTIA=0.18
EOF

# Ejecutar simulación
python simulate_pid.py

Resultados de Simulación

El simulador genera gráficas mostrando el comportamiento del sistema con diferentes configuraciones de PID. Todas las simulaciones utilizan:

Setpoint: 75°C
Temperatura inicial: 20°C
Sample time: 30 segundos
Iteraciones: 40
Inercia térmica: 0.18

Configuración 1: Kp=0.20, Ki=0.0001, Kd=0.30 (Sobreamortiguada)

Características observadas:

Convergencia lenta y suave sin overshoot
Tiempo de estabilización: ~20 minutos
Temperatura final: ~74.5°C
Error final: ~0.5°C
Control Value máximo: ~15%
Comportamiento: Sistema muy conservador, ideal cuando no se permiten sobrepasadas

Configuración 2: Kp=0.50, Ki=0.0004, Kd=0.20 (Críticamente amortiguada)

Características observadas:

Convergencia rápida sin overshoot significativo
Tiempo de estabilización: ~15 minutos
Temperatura final: ~74.8°C
Error final: ~0.2°C
Control Value máximo: ~30%
Comportamiento: Balance óptimo entre velocidad y estabilidad

Configuración 3: Kp=1.2, Ki=0.002, Kd=0.1 (Subamortiguada)

Características observadas:

Convergencia muy rápida con overshoot
Overshoot máximo: ~2°C (alcanza ~77°C)
Oscilaciones visibles antes de estabilizar
Tiempo de estabilización: ~12 minutos
Temperatura final: ~75.0°C
Error final: ~0.05°C
Control Value máximo: ~70%
Comportamiento: Sistema agresivo, respuesta rápida pero con oscilaciones

📊 Verificación de Resultados

CloudWatch Logs

Los logs muestran cada iteración del control:

{
  "timestamp": "2026-01-15T10:30:45.123Z",
  "level": "INFO",
  "message": "Iteration 15: Setpoint=75.00, Temp=72.34, CV=45.67"
}

CloudWatch Metrics

Las métricas publicadas permiten visualizar:

SetpointTemperature: Temperatura deseada (constante)
ActualTemperature: Temperatura real del reactor
TemperatureError: Error absoluto

Para visualizar en CloudWatch:

Ir a CloudWatch Console → Metrics
Buscar namespace "PIDControl-v2"
Crear dashboard con las tres métricas

Logs del Reactor

{
  "timestamp": "2026-01-15T10:30:45.456Z",
  "level": "INFO",
  "message": "Reactor: CV=45.67, Temp=72.34, Ambient=20.0"
}

💡 Ventajas de Lambda Durable Functions

✅ Sin Costo Durante Esperas

El uso de context.wait() es una de las características más poderosas de Lambda Durable Functions. Según la documentación oficial de AWS, cuando una función durable está en estado de espera usando context.wait(), no se cobra por tiempo de cómputo.

# Antes: Lambda ejecutándose = $$$
time.sleep(60)  # Pagas por 60 segundos de ejecución

# Ahora: Lambda suspendida = $0
context.wait(Duration.from_seconds(60))  # Sin cargo durante la espera

Ejemplo de ahorro de costos para el caso de nuestro control PID con SAMPLE_TIME de 60 segundos y 40 iteraciones:

Sin Durable: 40 minutos de ejecución continua = 2,400 segundos facturables
Con Durable: ~5 segundos de ejecución real (solo cómputo activo) = 5 segundos facturables
Ahorro: ~99.8% en costos de cómputo

Referencia: How Lambda Durable Functions work - AWS Documentation

Checkpointing Automático

Cada context.step() guarda el estado:

# Si falla aquí, reinicia desde el último step exitoso
pid_result = context.step(calculate_pid(...))  # ✓ Checkpoint
reactor_data = context.step(invoke_reactor(...))  # ✓ Checkpoint
context.step(publish_metrics(...))  # ✓ Checkpoint

Sin Infraestructura Extra

Comparación con arquitecturas tradicionales:

Sin Durable Functions:

DynamoDB para estado
SQS para coordinación
EventBridge para scheduling
Step Functions para workflow

Con Durable Functions:

Solo Lambda (estado incluido)

Código Más Simple

El código es más legible y mantenible:

# Loop natural con estado persistente
for iteration in range(MAX_ITERATIONS):
    pid_result = context.step(calculate_pid(...))
    reactor_data = context.step(invoke_reactor(...))
    context.step(publish_metrics(...))
    context.wait(Duration.from_seconds(SAMPLE_TIME))

📋 Casos de Uso Prácticos

Según el blog oficial de AWS y la documentación técnica, Lambda Durable Functions es especialmente útil para escenarios donde se requieren workflows de larga duración con estado persistente. Los casos de uso documentados incluyen: workflows de aprobación humana donde los procesos esperan aprobaciones sin mantener recursos activos; procesamiento de datos por lotes como ETL jobs que esperan entre etapas; orquestación de microservicios para coordinar múltiples servicios con estado; monitoreo y polling para sistemas que verifican condiciones periódicamente; y workflows de IA y ML para pipelines de entrenamiento y procesamiento de modelos. Estos patrones aprovechan la capacidad de context.wait() para suspender la ejecución sin cargos de cómputo, haciendo viable económicamente mantener workflows activos durante períodos prolongados.

Referencias: AWS Blog - Lambda Durable Functions | Use Cases Documentation

⚠️ Consideraciones Importantes

Límites del Servicio

Según la documentación oficial de AWS Lambda Durable Functions:

Execution timeout: Sin límite de tiempo total de ejecución (la función puede ejecutarse indefinidamente usando context.wait())
Individual function timeout: Máximo 15 minutos por invocación individual de función
Retention period: Máximo 1 año (365 días) para estado persistente
Payload size: Máximo 256 KB por step
Maximum concurrent executions: Sujeto a las cuotas de concurrencia de Lambda de la cuenta

Nota importante: Aunque no hay límite en el tiempo total de ejecución durable, cada invocación individual de la función Lambda está limitada a 15 minutos. El estado se persiste automáticamente entre invocaciones.

Mejores Prácticas

Usar steps granulares: Cada step debe ser una unidad lógica de trabajo
Limitar payload: Pasar solo datos necesarios entre steps
Implementar timeouts: Configurar timeouts apropiados para cada función
Monitorear métricas: Usar CloudWatch para detectar problemas
Manejar errores: Implementar retry logic en steps críticos

Cuándo NO usar Durable Functions

Latencia ultra-baja: Si necesitas respuesta en milisegundos
Alto throughput: Para miles de ejecuciones concurrentes
Workflows complejos: Step Functions puede ser mejor opción
Estado muy grande: Si el estado excede 256 KB

📊 Conclusiones (Para nuestro caso de prueba PID)

Esta POC intente validar que es posible implementar un sistema de control PID en arquitecturas serverless usando AWS Lambda Durable Functions. y lo que podemos identificar como concluciones, comparado con el uso de AWS lambda tradicional sin 'Durable Function' seria:

Economía: context.wait() elimina costos de tiempo de espera entre iteraciones
Simplicidad: Código más limpio sin necesidad de DynamoDB, SQS o Step Functions
Resiliencia: Checkpointing automático permite recuperación ante fallos
Flexibilidad: Fácil ajuste de parámetros PID y configuración del reactor
Escalabilidad: Cada control PID es independiente y puede escalar horizontalmente

Limitaciones identificadas:

Latencia: No apto para control en tiempo real (< 1 segundo)
Cold starts: Primera invocación puede tardar 2-3 segundos
Debugging: Más complejo que funciones Lambda tradicionales

Finalmente el código completo está disponible en GitHub

🔗 Referencias y Enlaces Útiles

Gracias por leer.

¡Saludos!

Oscar Cortés

Agregando reactividad ⚡ a nuestras arquitecturas con AWS CloudWatch Subscription Filter

olcortesb — Wed, 21 Jan 2026 09:04:40 +0000

Introducción

Uno de los principales desafíos al implementar sistemas basados en eventos es lograr la reactividad necesaria para que respondan automáticamente ante eventos específicos. Cuando integramos sistemas tradicionales de request-response con arquitecturas gestionadas por eventos, siempre surge la necesidad de agregar esta capacidad reactiva.

En esta búsqueda constante de soluciones robustas para agregar reactividad a los sistemas, hoy presento una prueba de concepto utilizando una de esas features que están "escondidas" dentro de los servicios de AWS. Exploraremos AWS CloudWatch Subscription Filter como una herramienta poderosa para agregar reactividad automática a nuestros sistemas.

La intención de esta POC (Proof of Concept) es utilizar AWS CloudWatch Subscription Filter para procesar logs automáticamente y ejecutar acciones basadas en el contenido de los mismos. Crearemos una arquitectura serverless que captura logs específicos y los procesa en tiempo real.

🚀 ¿Qué es AWS CloudWatch Subscription Filter?

AWS CloudWatch Subscription Filter es una feature que permite filtrar y procesar logs en "tiempo real" desde CloudWatch Logs. Cuando los logs coinciden con un patrón específico, el filtro puede enviar automáticamente esos datos a destinos como Lambda, Kinesis Data Streams, o Amazon Data Firehose. En este post vamos a explorar la integración con AWS Lambda específicamente.

AWS CloudWatch Logs Subscription Filters

🏗️ Arquitectura de la POC

Nuestra implementación sigue este flujo:

API Gateway → Recibe POST requests
Lambda Controller → Procesa el POST y loggea siempre
CloudWatch Subscription Filter → Captura logs con enable=true automáticamente
Lambda Processor → Procesa logs capturados y guarda en DynamoDB

🛠️ Implementación

Lambda Controller

La Lambda Controller recibe los POST requests y genera logs específicos que serán capturados por el subscription filter. Aquí es importante anotar que esta lambda podría ser cualquier log de nuestro sistema tradicional o reactivo que tenga la capacidad de escribir logs en CloudWatch.

import json
from datetime import datetime

def handler(event, context):
    try:
        body = json.loads(event['body'])

        # Log específico para el subscription filter
        if body.get('enable', False):
            print(f"✅ ORIGINAL_POST: {json.dumps(body)}")
            response_message = "POST logged - subscription filter will process it"
        else:
            print(f"❌ POST received but enable=false: {json.dumps(body)}")
            response_message = "POST received but enable=false, not processed"

        return {
            'statusCode': 200,
            'body': json.dumps({
                'message': response_message,
                'received_data': body,
                'timestamp': datetime.utcnow().isoformat()
            })
        }
    except Exception as e:
        print(f"Error processing request: {str(e)}")
        return {'statusCode': 500, 'body': json.dumps({'error': str(e)})}

⚙️ CloudWatch Subscription Filter

El filtro se configura para capturar únicamente logs que contengan el patrón ✅ ORIGINAL_POST. Es importante destacar que este patrón lo agrego en la lambda cuando el post cumple las condiciones de enable:true. Destaco la manera cómo se configura el filtro; aunque hay límites en el número de filtros que se pueden configurar por log group (Ref), la forma de agregar filtros es muy simple.

# Ejemplo en Terraform de cómo configurar un subscription filter
resource "aws_cloudwatch_log_subscription_filter" "posts_filter" {
  name            = "${var.project_name}-posts-filter"
  log_group_name  = aws_cloudwatch_log_group.controller_lambda_logs.name
  filter_pattern  = "✅ ORIGINAL_POST"
  destination_arn = aws_lambda_function.processor_lambda.arn
}

Lambda Processor

La Lambda Processor recibe los logs filtrados, los descomprime y procesa el contenido. En este caso, a diferencia de la lambda controller, sí necesitamos esta lambda para que procese el log y se active ante el evento del subscription filter.

import json
import boto3
import gzip
import base64
import uuid
from datetime import datetime

def handler(event, context):
    try:
        table = boto3.resource('dynamodb').Table(os.environ['DYNAMODB_TABLE'])

        # Descomprimir datos de CloudWatch Logs
        # Este punto es importante: CloudWatch envía los datos codificados 
        # en base64, hay que decodificarlos primero antes de trabajarlos
        compressed_payload = base64.b64decode(event['awslogs']['data'])
        uncompressed_payload = gzip.decompress(compressed_payload)
        log_data = json.loads(uncompressed_payload)

        # Procesar cada evento de log
        for log_event in log_data['logEvents']:
            message = log_event['message']

            if '✅ ORIGINAL_POST:' in message:
                # Extraer JSON del POST original
                json_start = message.find('{')
                if json_start != -1:
                    original_post = json.loads(message[json_start:])

                    # Guardar en DynamoDB
                    item = {
                        'id': str(uuid.uuid4()),
                        'original_post': original_post,
                        'timestamp': datetime.utcnow().isoformat(),
                        'processed_at': datetime.utcnow().isoformat()
                    }

                    table.put_item(Item=item)
                    print(f"Saved to DynamoDB: {item['id']}")

        return {'statusCode': 200, 'body': 'Successfully processed logs'}
    except Exception as e:
        print(f"Error processing logs: {str(e)}")
        return {'statusCode': 500, 'body': f'Error: {str(e)}'}

🚀 Despliegue con Terraform

Estructura del proyecto

aws-cloudwatch-subscription-filter/
├── src/
│   ├── controller_lambda.py
│   └── processor_lambda.py
├──  main.tf
├──  api_gateway.tf
├──  lambda_functions.tf
├──  cloudwatch_subscription_filter.tf
├──  dynamodb_table.tf
├──  iam_roles.tf
├──  build_lambdas.sh
└──  README.md

Comandos de despliegue

# 1. Construir las Lambdas (zip y dependencias)
./build_lambdas.sh

# 2. Inicializar Terraform (credenciales previamente configuradas)
terraform init

# 3. Planificar el despliegue
terraform plan

# 4. Aplicar la infraestructura
terraform apply

# 5. Luego de las pruebas
terraform destroy

🧪 Pruebas y Validación

POST que NO será procesado

Es importante tomar los outputs del Terraform y reemplazarlos en {your-api-gateway-url}

curl -X POST https://your-api-gateway-url/posts \
  -H "Content-Type: application/json" \
  -d '{
    "enable": false,
    "message": "Este mensaje no será procesado",
    "data": "algunos datos"
  }'

POST que SÍ será procesado

curl -X POST https://your-api-gateway-url/posts \
  -H "Content-Type: application/json" \
  -d '{
    "enable": true,
    "message": "Este mensaje será procesado y guardado en DynamoDB",
    "data": "algunos datos importantes"
  }'

📊 Verificación de Resultados

1. CloudWatch Logs

Revisar los logs de la Lambda Controller para confirmar que se generan correctamente:


❌ POST received but enable=false: {"enable": false, "message": "Este mensaje no ser\u00e1 procesado", "data": "algunos datos"}
END RequestId: 
REPORT RequestId: 
Duration: 1.81 ms Billed Duration: 87 ms Memory Size: 128 MB Max Memory Used: 32 MB Init Duration: 84.44 ms

START RequestId:  Version: $LATEST
✅ ORIGINAL_POST: {"enable": true, "message": "Este mensaje ser\u00e1 procesado y guardado en DynamoDB", "data": "algunos datos importantes"}
END RequestId: 
REPORT RequestId:  
Duration: 1.46 ms Billed Duration: 2 ms 
Memory Size: 128 MB Max Memory Used: 32 MB

2. DynamoDB

Verificar que los datos se guardaron en la tabla:

aws dynamodb scan --table-name cloudwatch-subscription-filter-posts --limit 1 --region us-east-1

// Response
{
    "Items": [
        {
            "original_post": {
                "M": {
                    "message": {
                        "S": "Este mensaje será procesado y guardado en DynamoDB"
                    },
                    "data": {
                        "S": "algunos datos importantes"
                    },
                    "enable": {
                        "BOOL": true
                    }
                }
            },
            "log_timestamp": {
                "N": "1768222052525"
            },
            "id": {
                "S": "51991cf6-23a5-463b-a8d1-dc2f047ab13c"
            },
            "processed_at": {
                "S": "2026-01-12T12:47:42.465810"
            },
            "timestamp": {
                "S": "2026-01-12T12:47:42.465790"
            }
        }
    ],
    "Count": 1,
    "ScannedCount": 1,
    "LastEvaluatedKey": {
        "id": {
            "S": "51991cf6-23a5-463b-a8d1-dc2f047ab13c"
        }
    }
}

3. CloudWatch Subscription Filter

Confirmar que el filtro se creó y está activo en la consola de AWS.

🔧 Características Técnicas

Filtro de Patrones

Patrón: ✅ ORIGINAL_POST (He probado íconos porque me parece un punto crítico)
Sensible a mayúsculas: Sí
Procesamiento: máximo 30 segundos hasta que se persiste el registro en DynamoDB.

Compresión de Datos

CloudWatch Logs envía los datos comprimidos con gzip y codificados en base64:

# Proceso de descompresión
compressed_payload = base64.b64decode(event['awslogs']['data'])
uncompressed_payload = gzip.decompress(compressed_payload)
log_data = json.loads(uncompressed_payload)

Estructura de Datos

Los logs procesados incluyen:

ID único generado con UUID
POST original completo
Timestamps de creación y procesamiento
Metadatos del log event

💡 Casos de Uso Prácticos (Siempre como referencia, pero hay muchos más...)

1. Monitoreo de Errores

# En la Lambda Controller
if error_occurred:
    print(f"🚨 ERROR_ALERT: {json.dumps(error_details)}")

2. Auditoría de Transacciones

# Para transacciones críticas
if transaction_type == "payment":
    print(f"💰 PAYMENT_LOG: {json.dumps(transaction_data)}")

3. Análisis de Comportamiento

# Para eventos de usuario
if user_action in ["login", "purchase", "signup"]:
    print(f"👤 USER_EVENT: {json.dumps(user_data)}")

📋 Conclusiones

Aproveché esta POC para validar el funcionamiento de AWS CloudWatch Subscription Filter identificando:

Automatización del procesamiento de logs basado en patrones
Integración despierta la lambda processor con una latencia razonable
Arquitectura serverless escalable y costo-eficiente. Importante anotar que no se cobra por detectar los eventos sino por los datos enviados a la lambda o el Kinesis.
Filtrado inteligente que procesa solo logs relevantes y se puede tener un control atómico de los eventos que se necesitan.

Esta implementación sirve como base para casos de uso más complejos como monitoreo de errores, auditoría de transacciones, análisis de comportamiento de usuarios, y alertas en tiempo real.

El código completo está disponible en GitHub y listo para desplegar con Terraform, proporcionando una base sólida para proyectos que requieran procesamiento automático de logs en AWS.

⚠️ Consideraciones Importantes

Límites del Servicio

Máximo 2 subscription filters por log group
Filtros de hasta 1024 caracteres
Rate limiting en destinos Lambda

Mejores Prácticas

Usar patrones específicos para evitar ruido
Implementar retry logic en el processor
Monitorear métricas de CloudWatch
Configurar alertas para errores

🔗 Referencias y Enlaces Útiles

Gracias por leer.

¡Saludos!

Oscar Cortés

AWS DocumentDB Streams: Configuración y caso de uso

olcortesb — Wed, 07 Jan 2026 15:29:39 +0000

Entre finales del 2025 y principios del presente año, con el equipo de trabajo de ACKStorm nos enfrentamos a un desafío interesante. Necesitábamos diseñar una arquitectura serverless para una aplicación que necesitaba un manejo de un alto volumen de datos. En el proceso de diseño se identifico que el uso de una DynamoDB no era una buena opción. Con este escenario analizamos el costo de las distintas bases de datos que tenemos en AWS donde DocumentDB se presentó como la mejor opción.

Una de las mejores características, al menos desde mi parecer, que tiene DynamoDB es el DynamoDB Streams, feature que permite disparar eventos en base a las modificaciones que se realicen sobre la base e integrarlas con el ecosistema de eventos de AWS(lambda, eventbridge, etc). Bien, DocumentDB tiene streams heredados de MongoDB pero no es directamente integrable con el ecosistema. En este post pretendo mostrar cómo configurar DocumentDB streams e integrarlo al flujo de trabajo de AWS.

¿Qué es AWS DocumentDB Stream?

AWS DocumentDB Streams es una funcionalidad que permite capturar y procesar cambios en los datos de una base de datos DocumentDB en tiempo real. Esta característica es especialmente útil para aplicaciones que requieren sincronización de datos, auditoría o integración con otros servicios.

Referencia oficial: AWS DocumentDB Change Streams

Características principales:

Captura de cambios en tiempo real: Detecta inserciones, actualizaciones y eliminaciones
Compatibilidad con MongoDB: Utiliza la API de Change Streams de MongoDB 3.6+
Integración nativa: Se puede conectar directamente con servicios AWS como Lambda, Kinesis y EventBridge
Filtrado granular: Permite filtrar eventos por colección, operación o campos específicos
Durabilidad: Los eventos se almacenan de forma persistente durante un período configurable

Documentación técnica: Working with Change Streams

POC: Arquitectura propuesta

Como muestra la figura, la arquitectura propuesta se basa en una lambda que permite escribir los documentos tomando lo que el API Gateway reciba como un POST desde el exterior, luego eso se envía al DocumentDB y del otro lado del dominio de la aplicación está el Event Bridge que está evaluando cada tiempo (1m para esta POC) si se insertó un nuevo documento.

EL codigo:

Todo el codigo utilizada para esta POC esta ene este repositorio Link

Configuración de DocumentDB Streams

A diferencia de DynamoDB Streams, en DocumentDB es necesario configurarla. Para configurarla se puede hacer a nivel global de la base de datos o a nivel de colecciones; vamos a configurar a nivel de colecciones. También se puede configurar por la línea de comandos o a través de SDK, este segundo será nuestra opción.

def lambda_handler(event, context):
    docdb_uri = os.environ['DOCDB_URI']
    client = None

    try:
        print(f"Connecting to DocumentDB...")

        # Conectar a DocumentDB con timeouts agresivos
        client = pymongo.MongoClient(
            docdb_uri,
            ssl=True,
            tlsCAFile='global-bundle.pem',
            retryWrites=False,
            connectTimeoutMS=5000,  # 5 segundos
            serverSelectionTimeoutMS=5000,  # 5 segundos
            socketTimeoutMS=10000,  # 10 segundos
            maxPoolSize=1,  # Conexión única
            waitQueueTimeoutMS=2000  # 2 segundos
        )

        # Verificar conexión rápidamente
        client.admin.command('ping')
        print("Connected successfully")

        db = client['demo_db']
        collection = db['users']

        # Habilitar change streams si no están habilitados
        try:
            client.admin.command("modifyChangeStreams", database="demo_db", collection="users", enable=True)
            print("Change streams enabled for collection")
        except Exception as e:
            print(f"Change streams already enabled or error: {e}")
        ....

Prueba de funcionamiento

Una vez configurado el DocumentDB Stream, nos queda realizar pruebas.

Primero realizamos un POST al API Gateway para agregar un nuevo documento a la DocumentDB.

~/workspace/aws-documentdb-streams/lambda/writer (main)$ curl -X POST https://umncz7md48.execute-api.us-east-1.amazonaws.com/dev/write   -H "Content-Type: application/json"   -d '{
    "user_id": "user_008",
    "name": "Elena Morales", 
    "email": "elena@example.com"
  }'
# {"message": "Document inserted successfully", "document_id": "695e6e66a68ca00398aeb3ca"}

Verificamos el log del lambda-writer:

Registro del Log completo:

~/workspace/aws-documentdb-streams/lambda/writer (main)$ aws logs tail /aws/lambda/docdb-streams-demo-writer --since 1m --region us-east-1
## 2026/01/07/[$LATEST] INIT_START Runtime Version: python:3.11.v109      Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:49f733259c7ce7e0deee75ff91c6afe35c7d58b04ed300f32701216263b4590c
## 2026/01/07/[$LATEST] START RequestId: 717faf29-0efd-470e-925f-12434921dc45 Version: $LATEST
## 2026/01/07/[$LATEST] Connecting to DocumentDB...
## 2026/01/07/[$LATEST] /var/task/lambda_function.py:14: UserWarning: You appear to be connected to a DocumentDB cluster. For more information regarding feature compatibility and support please visit https://www.mongodb.com/supportability/documentdb
## 2026/01/07/[$LATEST] client = pymongo.MongoClient(
## 2026/01/07/[$LATEST] Connected successfully
## 2026/01/07/[$LATEST] Change streams enabled for collection
## 026/01/07/[$LATEST] Inserting document: {'user_id': 'user_008', 'name': 'Elena Morales', 'email': 'elena@example.com', 'timestamp': datetime.datetime(2026, 1, 7, 14, 32, 6, 64071), 'action': 'user_created'}
## 2026/01/07/[$LATEST] Document inserted with ID: 695e6e66a68ca00398aeb3ca
## 2026/01/07/[$LATEST] END RequestId: 717faf29-0efd-470e-925f-12434921dc45
## 2026/01/07/[$LATEST] REPORT RequestId: 717faf29-0efd-470e-925f-12434921dc45    Duration: 1026.52 ms    Billed Duration: 1470 msMemory Size: 128 MB     Max Memory Used: 58 MB  Init Duration: 443.42 ms

Registro específico del momento en que el documento se inserta:

Inserting document: {'user_id': 'user_008', 'name': 'Elena Morales', 'email': 'elena@example.com', 'timestamp': datetime.datetime(2026, 1, 7, 14, 32, 6, 64071), 'action': 'user_created'}

Luego verificamos el log del lambda-processor:

Registro del log completo:

~/workspace/aws-documentdb-streams/lambda/processor (main)$ aws logs tail /aws/lambda/docdb-streams-demo-stream-processor --since 1m --region us-east-1
## 2026/01/07/[$LATEST] INIT_START Runtime Version: python:3.11.v109 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:49f733259c7ce7e0deee75ff91c6afe35c7d58b04ed300f32701216263b4590c
## 2026/01/07/[$LATEST] START RequestId: ba850df0-2e96-4c01-81cd-9e2109db3587 Version: $LATEST
## 2026/01/07/[$LATEST] /var/task/lambda_function.py:17: UserWarning: You appear to be connected to a DocumentDB cluster. For more information regarding feature compatibility and support please visit https://www.mongodb.com/supportability/documentdb
## 2026/01/07/[$LATEST] client = pymongo.MongoClient(docdb_uri,
## 2026/01/07/[$LATEST] Starting change stream listener...
## 2026/01/07/[$LATEST] Change detected: insert on document 695e6e66a68ca00398aeb3ca
## 2026/01/07/[$LATEST] New document: {"_id": "695e6e66a68ca00398aeb3ca", "user_id": "user_008", "name": "Elena Morales", "email": "elena@example.com", "timestamp": "2026-01-07 14:32:06.064071", "action": "user_created"}
## 2026/01/07/[$LATEST] Change detected: insert on document 695e6e66a68ca00398aeb3ca
## 2026/01/07/[$LATEST] New document: {"_id": "695e6e66a68ca00398aeb3ca", "user_id": "user_008", "name": "Elena Morales", "email": "elena@example.com", "timestamp": "2026-01-07 14:32:06.064071", "action": "user_created"}

Registro específico del momento en que el stream detecta el nuevo documento:

Change detected: insert on document 695e6e66a68ca00398aeb3ca
New document: {"_id": "695e6e66a68ca00398aeb3ca", "user_id": "user_008", "name": "Elena Morales", "email": "elena@example.com", "timestamp": "2026-01-07 14:32:06.064071", "action": "user_created"}

Conclusiones

La implementación de AWS DocumentDB Streams es una solución viable para capturar y procesar cambios en tiempo real en aplicaciones serverless de alto volumen cuando DynamoDB no es una opción. Sin embargo, hay que tener en cuenta:

Ventajas identificadas:

✅ Integración nativa con el ecosistema AWS: Aunque requiere configuración adicional comparado con DynamoDB Streams, la integración con Lambda y EventBridge funciona de manera fluida. La desventaja en este punto es que el sistema en general no es reactivo por naturaleza; necesitamos EventBridge para poder detectar el evento. Sin embargo, una vez detectado, lo podemos integrar con el resto del ecosistema.

✅ Flexibilidad de configuración: La posibilidad de habilitar streams a nivel de colección específica permite un control granular sobre qué cambios capturar.

✅ Compatibilidad con MongoDB: Al utilizar la API estándar de Change Streams de MongoDB, facilita la migración de aplicaciones existentes.

Consideraciones importantes:

⚠️ Configuración manual requerida: A diferencia de DynamoDB, DocumentDB Streams requiere habilitación explícita por colección.

⚠️ Gestión de conexiones: Es crucial implementar timeouts y pooling de conexiones adecuados para evitar problemas de rendimiento.

⚠️ Monitoreo: Se recomienda implementar alertas para detectar fallos en el procesamiento de streams.

Casos de uso recomendados (en el papel, pueden ser muchos más):

Sincronización de datos entre microservicios
Auditoría en tiempo real de cambios en documentos críticos
Triggers de notificaciones basados en cambios de estado
Replicación selectiva de datos a sistemas analíticos

Importante antes de implementar esta solución en un ambiente productivo:

Implementar manejo de errores robusto con DLQ (Dead Letter Queues)
Configurar métricas personalizadas en CloudWatch
Evaluar el uso de Kinesis Data Streams para mayor throughput
Implementar filtros más específicos para optimizar el procesamiento

En resumen, DocumentDB Streams ofrece una alternativa sólida a DynamoDB Streams cuando se requiere flexibilidad de esquemas, volumen alto de datos y compatibilidad con MongoDB, aunque con un overhead de configuración adicional que debe considerarse en el diseño de la arquitectura.

Gracias por leer.

¡Saludos!

Oscar Cortés

AWS Landing Zone: Conceptos y contexto

olcortesb — Fri, 14 Nov 2025 10:57:54 +0000

Buenas ... Normalmente escribo sobre serverless en mis posts/artículos técnicos, sin embargo, hoy inauguro una nueva línea que tiene que ver con la "gobernanza en el cloud". El crecimiento del uso del cloud, la adopción de buenas prácticas y la evolución de las organizaciones nos llevan a que la gestión de recursos a gran escala sea parte de nuestro trabajo diario con el cloud.

Después de varios años trabajando con AWS(Amazon Web Services), he visto cómo los clientes que empiezan con una sola cuenta terminan con un "caos organizado" cuando crecen. AWS Landing Zone es la solución que ofrece AWS para gestionar este caos organizado.

🎯 ¿Qué es AWS Landing Zone y por qué me parece fundamental?

En términos simples, AWS Landing Zone es como tener un "plano maestro" para organizar tu infraestructura en AWS. Imagínate que vas a construir un barrio completo: necesitas planificar las calles, los servicios básicos, las zonas residenciales y comerciales antes de empezar a construir casas.

Eso es exactamente lo que hace Landing Zone: nos da una estructura multi-cuenta bien organizada, con seguridad integrada desde el día uno y todas las estructuras(logging, monitoreo, compliance) ya conectadas. Es la diferencia entre crecer de forma ordenada o terminar con un laberinto imposible de mantener, al menos en mi experiencia.

📅 Evolución Histórica

Como siempre que inicio un nuevo tema o nueva línea de trabajo me parece buen ejercicio rastrear los orígenes, he intentado revisar post, artículos varios y esta sería una línea de tiempo no oficial de cómo AWS Landing Zone llegó a nosotros.

AWS Landing Zone (Solución original) Antes de 2019

No he encontrado referencias oficiales directas de lo que era AWS Landing Zone previo a 2019, pero en todos lados tenemos referencia a migrar landing zone (Solución Original) a control tower por ejemplo el link a continuación:

https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-control-tower/introduction.html

Por lo tanto es correcto asumir que teníamos una versión 1, y control tower se presenta como la versión 2.0.

AWS Control Tower ¿cómo llegamos hasta aquí?

24 de junio de 2019: Disponibilidad general (GA) versión 2.1 (AWS News Blog)
Agosto 2019: Controles detectivos adicionales (Release Notes)
Septiembre 2019: Controles electivos adicionales
Noviembre 2019: Versión 2.2 con controles preventivos contra drift

Años con Release Notes y Versiones Disponibles:

2019 (v2.1 - v2.2): https://docs.aws.amazon.com/controltower/latest/userguide/2019-all.html
2020 (v2.3 - v2.6): https://docs.aws.amazon.com/controltower/latest/userguide/2020-all.html
2021 (v2.7 - v2.9): https://docs.aws.amazon.com/controltower/latest/userguide/2021-all.html
2022 (v3.0 - v3.1): https://docs.aws.amazon.com/controltower/latest/userguide/2022-all.html
2023 (v3.2 - v3.3): https://docs.aws.amazon.com/controltower/latest/userguide/2023-all.html
2024 (v3.3): https://docs.aws.amazon.com/controltower/latest/userguide/2024-all.html
2025 (v3.3): https://docs.aws.amazon.com/controltower/latest/userguide/2025-all.html

🍜 Los "ingredientes" de la landing zone a grandes rasgos:

Control Tower es el elemento principal pero una landing zone realmente es un conjunto de recursos.

AWS Control Tower: El "cerebro/control" que orquesta todo. Una vez configurado, prácticamente se maneja solo
AWS Organizations: El "árbol genealógico" de cuentas. Aquí defines quién puede hacer qué y dónde
AWS SSO (Identity Center): Único Login Centralizado para todas las cuentas un SSO de libro...
AWS Config: El "detective" que te avisa cuando algo no está como debería estar configurado
AWS Service Catalog: El "catálogo de productos" donde defines plantillas pre-aprobadas que los equipos pueden usar sin romper nada (en principio)
AWS CloudTrail: El "diario" que registra absolutamente todo lo que pasa en tus cuentas

... y muchos más!

Aquí los elementos mínimos que propone AWS para implementar una AWS Landing Zone

https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html

🏗️ ¿Y cómo orquestamos / construimos todos estos recursos?

Aquí hay un punto importante, AWS ofrece una guía prescriptiva de cómo implementar un landing zone con CloudFormation:

https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/architecture-overview.html

Sin embargo he hecho pruebas y creo que me inclinaría más por Terraform o Pulumi, este es el inicio de esta serie así que ya contaré sobre este tema más adelante.

¿A partir de cuántas cuentas tendría que montarme una landing zone?

No hay una recomendación oficial sobre a partir de cuántas cuentas está bien crear una landing zone, creo que esta discusión escapa un poco de este artículo en particular pero es un tema interesante a tratar:

Sin embargo, aquí algunas referencias que se pueden encontrar sobre las recomendaciones oficiales de la documentación de AWS:

"Más de una cuenta"
• Fuente: https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html
• Texto exacto: "Although there is no standard number of AWS accounts you should have, we recommend that you create more than one AWS account."
"Más de un puñado de cuentas"
• Fuente: https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
• Texto exacto: "If you are hosting more than a handful of accounts, it's beneficial to have an orchestration layer that facilitates account deployment and account
governance."

Sobre las cuentas y OU (Unidades Organizacionales)

Bueno, supongamos que ya tenemos claro que tenemos muchas cuentas, ahora, ¿cómo las organizamos? Sobre este aspecto hay mucho escrito, a continuación un ejemplo clásico de cómo se organizan las cuentas.

Ejemplo clásico

Root Organization
├── Security OU (Organizational Unit)
│   ├── Log Archive Account
│   ├── Audit Account
│   └── Security Tooling Account
├── Sandbox OU
│   └── Developer Sandbox Accounts
├── Production OU
│   ├── Production Account 1
│   └── Production Account 2
└── Non-Production OU
    ├── Development Account
    ├── Testing Account
    └── Staging Account

Aunque este es un ejemplo clásico el tema es complejo y tiene análisis de estudio grande como se puede ver en los estudios en los White Papers que dejo en este link:

https://docs.aws.amazon.com/pdfs/whitepapers/latest/aws-overview/aws-overview.pdf

🔗 Recursos y Referencias Oficiales

A continuación, y a modo de referencia, dejo mis links, no los he leído todos al completo pero los he revisado al menos una vez...

Documentación Principal de AWS

Whitepapers y Guías Estratégicas

AWS Prescriptive Guidance

Servicios Complementarios

Herramientas de Implementación que vamos a usar en estos post!

AWS CLI: Automatización de tareas
Terraform: Infrastructure as Code (IaC)
AWS CDK: Desarrollo programático (IaC)
Pulumi: Infrastructura as Code (IaC)
CloudFormations: Infrastructure as Code (IaC)

Comunidad y Soporte

💡 Conclusiones

Este post solo pretende ser un punto de partida para compartir todas las experiencias que me he encontrado desplegando AWS Landing Zone,

gracias por leer, nos vemos

Saludos

🏗️ 4 Estrategias para Procesar Mensajes SQS en Batch con AWS Lambda

olcortesb — Fri, 10 Oct 2025 08:01:04 +0000

Durante una charla de sincronización con un compañero de trabajo, sobre un cliente que necesita una estrategia para gestionar una cola de eventos a través de procesamiento por lotes, surgió la duda de cuál es la estrategia que más le convenía, y cuál era el estado del arte de las colas SQS en estos momentos.

Basado en lo que sacamos de esa charla, en este post exploraremos 4 estrategias diferentes para procesar mensajes de Amazon SQS en lotes usando AWS Lambda (como único consumidor, esto es importante para el análisis). Cada estrategia tiene sus propios casos de uso, ventajas y consideraciones de rendimiento que analizaremos con ejemplos prácticos.

🚀 ¿Por qué procesar mensajes SQS en lotes?

Amazon SQS permite procesar hasta 10 mensajes por llamada usando receive_message() (Python), lo que es más eficiente que procesar mensajes uno por uno. Sin embargo, no todos los mensajes pueden procesarse exitosamente en el primer intento, por lo que necesitamos diferentes estrategias para manejar los fallos.

⚠️ Validación del Límite de 10 Mensajes

AWS SQS estrictamente limita el parámetro MaxNumberOfMessages entre 1 y 10. Si intentas usar un valor mayor, obtienes este error:

{
  "error": "An error occurred (InvalidParameterValue) when calling the ReceiveMessage operation: Value 20 for parameter MaxNumberOfMessages is invalid. Reason: Must be between 1 and 10, if provided."
}

Este límite aplica tanto para colas Standard como FIFO, confirmando que el procesamiento en lotes está limitado a máximo 10 mensajes por operación receive_message().

Colas estándar vs Colas FIFO: Ref

🏗️ Arquitectura del Proyecto

⚠️ Importante: Este análisis y casos de uso están basados en un consumidor único por cola. Con múltiples consumidores concurrentes, el comportamiento y las consideraciones de cada estrategia pueden ser significativamente más complejas, especialmente en términos de duplicados, orden de procesamiento y gestión de fallos.

El proyecto implementa 4 funciones Lambda diferentes, cada una con una estrategia distinta para manejar mensajes que no cumplen ciertos criterios (en nuestro caso, números menores a 50). Partiendo de un script que genera 100 mensajes aleatorios con números entre 1 y 100 (el script pueden encontrarlo en el GitHub):

https://github.com/olcortesb/aws-examples

A continuación, las dos colas que utilizaremos en las pruebas:

Resources:
  MessagesQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeoutSeconds: 30
      MessageRetentionPeriod: 1209600

  DeadLetterQueue:
    Type: AWS::SQS::Queue
    Properties:
      MessageRetentionPeriod: 1209600

📋 Las 4 Estrategias Implementadas

1. Estrategia Simple: Eliminar Todos los Mensajes

Función: GetMessagesFunction

def lambda_handler(event, context):
    response = sqs.receive_message(
        QueueUrl=queue_url,
        MaxNumberOfMessages=10,  # Máximo permitido por AWS
        WaitTimeSeconds=5
    )

    messages = response.get('Messages', [])

    for msg in messages:
        # Procesar mensaje
        processed_messages.append({
            "messageId": msg['MessageId'],
            "body": msg['Body']
        })

        # Eliminar siempre
        sqs.delete_message(
            QueueUrl=queue_url,
            ReceiptHandle=msg['ReceiptHandle']
        )

Características:

✅ Simplicidad: Lógica directa y fácil de entender
✅ Rendimiento: No hay operaciones adicionales
❌ Pérdida de datos: Los mensajes fallidos se pierden permanentemente

Caso de uso: Procesamiento donde la pérdida ocasional de mensajes es aceptable.

2. Estrategia de Reenvío: Devolver Mensajes a la Cola

Función: ProcessMessagesFunction

def lambda_handler(event, context):
    for msg in messages:
        message_number = int(msg['Body'])

        if message_number < threshold:
            # Reenviar a la misma cola
            sqs.send_message(
                QueueUrl=queue_url,
                MessageBody=msg['Body']
            )

        # Eliminar mensaje original
        sqs.delete_message(
            QueueUrl=queue_url,
            ReceiptHandle=msg['ReceiptHandle']
        )

Características:

✅ Sin pérdida: Los mensajes fallidos se reenvían
✅ Flexibilidad: Permite modificar el mensaje antes del reenvío (creo que es lo único positivo que tiene este caso de uso, pero lo dejo porque alguna vez lo he tenido que usar 😂)
❌ Duplicación: Puede crear mensajes duplicados
❌ Overhead: Operaciones adicionales de escritura

Caso de uso: Cuando necesitas modificar (por ejemplo, sumar un número en nuestro caso de prueba) mensajes antes de reintentar un nuevo procesamiento.

3. Estrategia de Visibility Timeout: Dejar Reaparecer

Función: ProcessWithVisibilityFunction

def lambda_handler(event, context):
    for msg in messages:
        message_number = int(msg['Body'])

        if message_number >= threshold:
            # Solo eliminar si cumple criterios
            sqs.delete_message(
                QueueUrl=queue_url,
                ReceiptHandle=msg['ReceiptHandle']
            )
        # Los mensajes no eliminados reaparecen automáticamente

Características:

✅ Eficiencia: Menos operaciones de escritura
✅ Automático: SQS maneja la reaparición
✅ Sin duplicados: No crea mensajes adicionales
❌ Tiempo fijo: Depende del visibility timeout configurado
- Visibility Timeout grande: Puede darce el caso que el procesamiento de mensajes puede ser distinto por ejemplo un minuto para un mensaje y 30 minutos para otro, por lo tanto, es necesario entender si podemos esperar ese tiempo o colocar un visibility mas bajo.
- Visibility Timeout pequeño: Si el timeout es muy pequeño y el procesamiento de los mensajes es mayor al timeout, se pueden generar duplicados.

Caso de uso: Ideal para reintentos automáticos sin lógica compleja.

4. Estrategia Dead Letter Queue: Segregar Mensajes Fallidos

Función: ProcessWithDlqFunction

def lambda_handler(event, context):
    for msg in messages:
        message_number = int(msg['Body'])

        if message_number >= threshold:
            processed_messages.append(msg)
        else:
            # Enviar a Dead Letter Queue
            sqs.send_message(
                QueueUrl=dlq_url,
                MessageBody=msg['Body']
            )

        # Eliminar de cola original
        sqs.delete_message(
            QueueUrl=queue_url,
            ReceiptHandle=msg['ReceiptHandle']
        )

Características:

✅ Segregación: Mensajes fallidos en cola separada
✅ Análisis: Permite investigar patrones de fallo
✅ Reprocesamiento: Posibilidad de procesar DLQ posteriormente
❌ Complejidad: Requiere gestión de múltiples colas

Caso de uso: Sistemas críticos que requieren análisis de fallos y reprocesamiento.

🚀 Despliegue y Pruebas

1. Desplegar la Aplicación

sam build
sam deploy --guided --profile your-aws-profile

2. Enviar Mensajes de Prueba

cd scripts
python3 send_messages.py

El script envía 100 mensajes numerados del 1 al 100 para probar las diferentes estrategias (los que no tomamos como válidos son los menores a 50).

3. Probar Cada Estrategia

# Estrategia 1: Eliminar todos
aws lambda invoke --function-name bach-messages-GetMessagesFunction-XXXXX response1.json

# Estrategia 2: Reenvío
aws lambda invoke --function-name bach-messages-ProcessMessagesFunction-XXXXX response2.json

# Estrategia 3: Visibility Timeout
aws lambda invoke --function-name bach-messages-ProcessWithVisibilityFunction-XXXXX response3.json

# Estrategia 4: Dead Letter Queue
aws lambda invoke --function-name bach-messages-ProcessWithDlqFunction-XXXXX response4.json

📊 Comparación de Estrategias

Estrategia	Pérdida de Datos	Duplicados	Operaciones Extra	Complejidad	Análisis de Fallos
Simple	❌ Sí	✅ No	✅ Ninguna	✅ Baja	❌ No
Reenvío	✅ No	❌ Posible	❌ Send	🟡 Media	❌ No
Visibility	✅ No	✅ No	✅ Ninguna	✅ Baja	❌ Limitado
DLQ	✅ No	✅ No	❌ Send	❌ Alta	✅ Completo

🎯 Recomendaciones por Caso de Uso

Usar Estrategia Simple cuando:

Los mensajes no son críticos
El rendimiento es prioritario
La pérdida ocasional es aceptable

Usar Estrategia de Reenvío cuando:

Necesitas modificar mensajes antes del reintento
Tienes lógica compleja de reintento
Puedes manejar duplicados

Usar Visibility Timeout cuando:

Quieres reintentos automáticos simples
El rendimiento es importante
Los fallos son temporales

Usar Dead Letter Queue cuando:

Los mensajes son críticos
Necesitas análisis de fallos
Requieres reprocesamiento manual
Tienes sistemas de monitoreo avanzados

🔧 Configuraciones Importantes

Visibility Timeout

MessagesQueue:
  Properties:
    VisibilityTimeoutSeconds: 30  # Tiempo antes de reaparecer

Message Retention

DeadLetterQueue:
  Properties:
    MessageRetentionPeriod: 1209600  # 14 días

Lambda Timeout

Globals:
  Function:
    Timeout: 3  # Debe ser menor que visibility timeout

📈 Métricas y Monitoreo

Para cada estrategia, monitorea:

Throughput: Mensajes procesados por segundo
Error Rate: Porcentaje de mensajes fallidos
Latency: Tiempo de procesamiento por lote
Queue Depth: Mensajes pendientes en cola
DLQ Messages: Mensajes en Dead Letter Queue (estrategia 4)

Y luego identifica cuál es mejor para tu caso de uso.

🏁 Conclusiones

Cada estrategia tiene su lugar en diferentes arquitecturas:

Simple: Para casos no críticos con alta performance
Reenvío: Para lógica compleja de reintento
Visibility Timeout: Para reintentos automáticos eficientes
Dead Letter Queue: Para sistemas críticos con análisis de fallos

La elección depende de tus requisitos específicos de confiabilidad, rendimiento y observabilidad.

Recuerda: Estas recomendaciones aplican principalmente para consumidores únicos. En escenarios con múltiples consumidores, considera factores adicionales como concurrencia, orden de mensajes y coordinación entre procesos.

El código completo está disponible en el repositorio aws-examples con todas las implementaciones y documentación detallada.

Gracias por leer, ¡Saludos!

Kiro: Primeras impresiones y configuración de MCPs

olcortesb — Tue, 23 Sep 2025 07:48:02 +0000

No soy un usuario avanzado de herramientas de IA, sin embargo en el último AWS Meetup Madrid, nos acompañó Alejandro Veliz Fernandes como uno de los ponentes. Durante su charla en demos interactivas nos mostró una visión general de cómo funciona KIRO, entrando en detalles en la parte que más me interesa de la IA, los límites de la herramienta (Guard rail) y la seguridad de nuestra información. Después de escuchar y tener una charla interesante con Alejandro y coincidiendo que me llegó el código de acceso a probar KIRO, aprovecharemos este post para explorar KIRO, un asistente de IA especializado en desarrollo de software, revisaremos cómo configurar el Model Context Protocol (MCP) para extender sus capacidades (intentando usarlo para algo mas que un chatbot) y revisaremos su configuración básica.

🚀 En primer lugar ¿Qué es Kiro?

Mi opinión: Kiro es un IDE que en su esencia es un fork de VSCode (es igual...) soportado en su desarrollo por AWS, que permite el acceso a él sin tener una cuenta de AWS y orientado a un desarrollo basado en especificaciones. Kiro tiene una versión free y varias alternativas de pago que exploraremos más adelante en futuros posts.

Según la documentación oficial de AWS: Kiro es una herramienta que permite construir exactamente lo que quieres y está listo para compartir con tu equipo. Los agentes de Kiro te ayudan a resolver problemas desafiantes y automatizar tareas como generar documentación y pruebas unitarias.

Documentación oficial AWS - Kiro

Características principales:

Desarrollo spec-driven: Convierte prompts en especificaciones detalladas y código funcional
Agentes inteligentes: Automatización de tareas complejas como documentación y testing
Autonomía configurable: Modo Autopilot para cambios automáticos o modo Supervisado para revisión
Contexto inteligente: Acceso a archivos (#File), carpetas (#Folder), problemas (#Problems), terminal (#Terminal) y diferencias de Git (#Git Diff)
Integración completa: Puede leer, escribir, modificar archivos y ejecutar comandos del sistema 🚥 + ⚠️.
Extensibilidad: Soporte para MCP (Model Context Protocol) para conectar herramientas externas

¿ Como instalarlo?

Al momento de escribir este post el acceso es a través de un waitlist y está en "Preview", pero se está liberando rápido: https://kiro.dev/waitlist/

¿Qué tiene de novedoso? para mí...

Al abrir el panel de Kiro se despliega una barra lateral por defecto que tiene 4 elementos: Specs, Agent Hooks, Agent Steering, MCP Servers, en principio tengo pensado escribir un post de cada uno (este será sobre MCP), pero vamos a describirlos:

Specs (Especificaciones)

Las Specs son una forma estructurada de construir y documentar funcionalidades que quieres desarrollar con Kiro. Es básicamente una formalización del proceso de diseño e implementación que te permite:

Iterar con el agente sobre requerimientos, diseño y tareas de implementación
Desarrollo incremental de funcionalidades complejas con control y retroalimentación
Documentar el proceso desde la concepción hasta la implementación
Incluir referencias a archivos usando la sintaxis #[[file:]] para incorporar specs de OpenAPI, GraphQL, etc.

Steering (Dirección/Guía)

Steering te permite incluir contexto adicional e instrucciones que se aplican a todas o algunas de tus interacciones con Kiro. Se almacenan en .kiro/steering/*.md y pueden ser:

Tipos de inclusión:

Siempre incluidos (comportamiento por defecto)
Condicionales cuando se lee un archivo específico (usando front-matter con inclusion: fileMatch y fileMatchPattern: 'README*')
Manuales cuando los proporcionas vía contexto con '#' en el chat (configurado con inclusion: manual)

Agent Hooks (Automatización a la mano...)

Los Agent Hooks son la capacidad de Kiro para crear ejecuciones automáticas del agente que se activan cuando ocurre un evento específico (o cuando el usuario hace clic en un botón) en el IDE.

Ejemplos de hooks:

Al guardar código: Cuando guardas un archivo de código, se activa automáticamente una ejecución para actualizar y ejecutar tests
Al actualizar traducciones: Cuando modificas strings de traducción, se asegura de que otros idiomas también se actualicen
Hook manual de spell-check: Cuando haces clic en un botón de 'revisión ortográfica', revisa y corrige errores gramaticales en tu archivo README

🔧 ¿Qué es el Model Context Protocol (MCP) - El 4 de las lista?

El Model Context Protocol (MCP) es un estándar que permite a aplicaciones de IA conectarse con herramientas y servicios externos, extendiendo significativamente sus capacidades más allá del desarrollo básico. En nuestro caso la aplicación de IA que queremos extender es Kiro.

Beneficios del MCP:

Extensibilidad: Conecta con APIs, bases de datos, servicios cloud
Automatización: Integra workflows complejos en tu flujo de desarrollo
Personalización: Adapta Kiro a las necesidades específicas de tu proyecto

Documentación oficial MCP

📋 Configuración Inicial de MCP

Paso 1: Estructura de configuración

Kiro utiliza archivos de configuración JSON para gestionar las conexiones MCP, tenemos dos opciones , configuración a nivel global y configuración a nivel de workspaces:

# Configuración a nivel de workspace
.kiro/settings/mcp.json

# Configuración global del usuario
~/.kiro/settings/mcp.json

Paso 2: Instalación de dependencias

Para la mayoría de servidores MCP necesitarás uv y uvx:

# Instalación usando pip
pip install uv

# O usando homebrew (macOS)
brew install uv

# Verificar instalación
uvx --version

🛠️ Configuración de Servidores MCP

Ejemplo 1: Servidor de Documentación AWS

Configuramos un servidor MCP para acceder a la documentación de AWS:

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": [],
      "disabledTools": []
    }
  }
}

Y podemos ver en el panel lateral específico de Kiro en la sección de MCP los que tenemos configurados y activos o desactivados, como muestra la imagen:

Ejemplo 2: Servidor de Sistema de Archivos

Para operaciones avanzadas con archivos y directorios:

{
  "mcpServers": {
    "filesystem": {
      "command": "uvx",
      "args": ["mcp-server-filesystem@latest"],
      "env": {
        "ALLOWED_DIRECTORIES": "/home/user/projects,/tmp"
      },
      "disabled": false,
      "autoApprove": ["list_directory", "read_file"],
      "disabledTools": ["delete_file"]
    }
  }
}

🧪 Casos de Uso Prácticos

Caso 1: Consulta de Documentación AWS

Con el servidor AWS configurado, puedes preguntar directamente:

"¿Cómo configuro un bucket S3 con cifrado?"

Kiro accederá automáticamente a la documentación oficial de AWS y te proporcionará información actualizada y precisa.

Caso 2: Análisis de Logs del Sistema

"Analiza los logs de error de la última hora en /var/log/application.log"

Con el servidor de filesystem, Kiro puede leer y analizar archivos de log directamente.

Caso 3: Integración con APIs Externas

{
  "mcpServers": {
    "github-api": {
      "command": "uvx",
      "args": ["mcp-server-github@latest"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      },
      "disabled": false,
      "autoApprove": ["get_repository", "list_issues"],
      "disabledTools": ["delete_repository"]
    }
  }
}

⚙️ Configuración Avanzada para el MCP

Gestión de Permisos ( Fundamental )

autoApprove: Lista de herramientas que se ejecutan automáticamente sin confirmación

"autoApprove": ["read_file", "list_directory", "get_documentation"]

disabledTools: Herramientas específicas que quieres deshabilitar

"disabledTools": ["delete_file", "format_disk", "shutdown_system"]

Variables de Entorno (Usar en local, nunca subir al repositorio)

Permite usar variables de entorno para configuraciones sensibles, usar responsablemente ⚠️: Sigo sin tener claro que podamos pasar a cualquier herramienta información sensible de cliente pero evaluaré qué ofrece Kiro en este aspecto a futuro.

Recomendado a nivel de Workspace: .kiro/settings/mcp.json

{
  "env": {
    "API_KEY": "${MY_API_KEY}",
    "DATABASE_URL": "${DB_CONNECTION_STRING}"
  }
}

🔗 Referencias y Enlaces Útiles

📈 Conclusiones

✅ Kiro Es un fork de VSCode, esto maximiza la compatibilidad.
✅ Kiro + MCP Me pareció ágil de configurar.
✅ Configuración flexible me parece interesante que tenga configuración para cada contexto y se puedan tener MCP en cada proyecto de manera independiente.
✅ Extensibilidad ilimitada No soy experto en MCP, pero aparentemente si lo puedes configurar puedes usarlo.
✅ Integración nativa Es compatible con lo que la mayoría usamos todos los días VSCode.
✅ Es una alternativa interesante a cursor
⚠️ Sigo sin usarlo para que me genere código de aplicaciones de manera directa para cliente final.

Próximos pasos:

Explorar los SPECS y tratar de saltarlos/romperlos para ver cómo funcionan.
Configurar hooks automáticos para tareas repetitivas, con esto puede estar interesante el proceso de mejorar nuestro desarrollo.
Implementar steering rules para estándares de equipo
Crear servidores MCP personalizados para APIs internas a largo plazo claro ☺️.

Gracias por leer, Saludos…

mimic 👓 (Api gateway + Lambda + Dynamo) en golang

olcortesb — Tue, 12 Aug 2025 09:17:45 +0000

Continuando con la serie de mimic, después de explorar la implementación básica en JavaScript y la relación con las distintas herramientas de IaC, vamos a probar esta implementación con Go y Terraform. En este artículo te muestro cómo crear una API completa de almacenamiento JSON usando Lambda en Go, API Gateway y DynamoDB.

¿Qué es mimic?

Como vimos en el artículo anterior, mimic es un stack serverless simple, que permite:

POST /mimic - Almacenar cualquier JSON y obtener un ID único

GET /mimic/{id} - Recuperar el JSON almacenado por su ID

Es como una base de datos en memoria que acepta cualquier estructura JSON, perfecta para testing, mocking de servicios y entornos efímeros.

¿Por qué Go + Terraform?

En el artículo sobre Lambda en Go con Terraform, exploramos las ventajas del runtime provided.al2023. Para mimic, estas ventajas se multiplican:

Rendimiento superior: Go compila a binarios nativos, ideal para APIs de alta frecuencia
Costo optimizado: ARM64 (Graviton2) reduce costos hasta 50%
Escalabilidad: Cada operación (POST/GET) tiene su propia Lambda
Infraestructura como código: Terraform nos da control total y reproducibilidad

Estructura del proyecto

Aquí Link dejaré el repositorio con el código completo.

01_GST_mimic/
├── src/
│   ├── request/
│   │   ├── go.mod          # Módulo Go para POST
│   │   ├── main.go         # Handler POST
│   │   └── bootstrap       # Binario compilado
│   └── response/
│       ├── go.mod          # Módulo Go para GET
│       ├── main.go         # Handler GET
│       └── bootstrap       # Binario compilado
├── apigateway.tf           # API Gateway + API Key
├── dynamo.tf               # Tabla DynamoDB
├── lambdarequest.tf        # Lambda POST + IAM
├── lambdaresponse.tf       # Lambda GET
├── random.tf               # Sufijos aleatorios
├── variables.tf            # Variables configurables
├── outputs.tf              # Outputs del módulo
└── README.md               # Documentación

Implementación en Go

Lambda POST (Request)

La lambda de almacenamiento acepta cualquier JSON válido(Esto está así a propósito):

package main

import (
    "context"
    "encoding/json"
    "log"
    "os"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/dynamodb"
    "github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute"
    "github.com/google/uuid"
)

type MimicItem struct {
    ID   string                 `json:"id"`
    Body map[string]interface{} `json:"body"`
}

var dynamoClient *dynamodb.DynamoDB
var tableName string

func init() {
    sess := session.Must(session.NewSession())
    dynamoClient = dynamodb.New(sess)
    tableName = os.Getenv("MIMIC_TABLE")
    if tableName == "" {
        tableName = "mimic-table"
    }
}

func createBodyResponse(body map[string]interface{}) (string, error) {
    id := uuid.New().String()
    mimicItem := MimicItem{
        ID:   id,
        Body: body,
    }

    av, err := dynamodbattribute.MarshalMap(mimicItem)
    if err != nil {
        return "", err
    }

    _, err = dynamoClient.PutItem(&dynamodb.PutItemInput{
        TableName: aws.String(tableName),
        Item:      av,
    })

    return id, err
}

func handler(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    log.Printf("Creating new mimic item")

    var body map[string]interface{}
    err := json.Unmarshal([]byte(request.Body), &body)
    if err != nil {
        log.Printf("Error parsing JSON: %v", err)
        return events.APIGatewayProxyResponse{
            StatusCode: 400,
            Body:       "Invalid JSON",
        }, nil
    }

    id, err := createBodyResponse(body)
    if err != nil {
        log.Printf("Error creating item: %v", err)
        return events.APIGatewayProxyResponse{
            StatusCode: 500,
            Body:       "Internal server error",
        }, nil
    }

    log.Printf("Created item with ID: %s", id)
    return events.APIGatewayProxyResponse{
        StatusCode: 200,
        Body:       id,
    }, nil
}

func main() {
    lambda.Start(handler)
}

Clave: Usamos map[string]interface{} para aceptar cualquier estructura JSON sin validaciones específicas.

Lambda GET (Response)

La lambda de recuperación devuelve el JSON original:

// get.go
package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"
    "os"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/dynamodb"
    "github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute"
)

type MimicItem struct {
    ID   string                 `json:"id"`
    Body map[string]interface{} `json:"body"`
}

var dynamoClient *dynamodb.DynamoDB
var tableName string

func init() {
    sess := session.Must(session.NewSession())
    dynamoClient = dynamodb.New(sess)
    tableName = os.Getenv("MIMIC_TABLE")
    if tableName == "" {
        tableName = "mimic-table"
    }
}

func getBodyResponse(id string) (*MimicItem, error) {
    result, err := dynamoClient.GetItem(&dynamodb.GetItemInput{
        TableName: aws.String(tableName),
        Key: map[string]*dynamodb.AttributeValue{
            "id": {
                S: aws.String(id),
            },
        },
    })

    if err != nil {
        return nil, err
    }

    if result.Item == nil {
        return nil, fmt.Errorf("item not found")
    }

    var item MimicItem
    err = dynamodbattribute.UnmarshalMap(result.Item, &item)
    if err != nil {
        return nil, err
    }

    return &item, nil
}

func handler(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    id, exists := request.PathParameters["id"]
    if !exists {
        return events.APIGatewayProxyResponse{
            StatusCode: 400,
            Body:       "Missing id parameter",
        }, nil
    }

    log.Printf("Getting mimic item with ID: %s", id)

    item, err := getBodyResponse(id)
    if err != nil {
        log.Printf("Error getting item: %v", err)
        return events.APIGatewayProxyResponse{
            StatusCode: 404,
            Body:       "Item not found",
        }, nil
    }

    responseBody, err := json.Marshal(item)
    if err != nil {
        log.Printf("Error marshaling response: %v", err)
        return events.APIGatewayProxyResponse{
            StatusCode: 500,
            Body:       "Internal server error",
        }, nil
    }

    return events.APIGatewayProxyResponse{
        StatusCode: 200,
        Body:       string(responseBody),
        Headers: map[string]string{
            "Content-Type": "application/json",
        },
    }, nil
}

func main() {
    lambda.Start(handler)
}

Infraestructura Terraform

DynamoDB en terraform.

resource "aws_dynamodb_table" "mimic_table" {
  name           = "${var.table_name}-${random_id.suffix.hex}"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "id"

  attribute {
    name = "id"
    type = "S"
  }

  point_in_time_recovery {
    enabled = true
  }

  tags = {
    Name = "MimicTable"
  }
}

API Gateway con API Key y Cuotas en terraform

# API Gateway con autenticación
resource "aws_api_gateway_rest_api" "mimic_api" {
  name        = "${var.api_name}-${random_id.suffix.hex}"
  description = "Mimic API for storing and retrieving JSON data"
}

# API Key para autenticación
resource "aws_api_gateway_api_key" "mimic_api_key" {
  name = "${var.api_name}-key-${random_id.suffix.hex}"
  description = "API Key for Mimic API"
}

# Usage Plan con cuotas mensuales
resource "aws_api_gateway_usage_plan" "mimic_usage_plan" {
  name = "${var.api_name}-usage-plan-${random_id.suffix.hex}"

  quota_settings {
    limit  = var.api_quota_limit  # 1000 requests/month
    period = "MONTH"
  }

  throttle_settings {
    rate_limit  = var.api_rate_limit   # 10 req/sec
    burst_limit = var.api_burst_limit  # 20 burst
  }
}

Compilación automática separada (No implementar external en PROD ⚠️)

Esto es para el despliegue desde el local, lo recomendable es hacer el build en los pipelines y no usar external.

# Build REQUEST Lambda
data "external" "build_create_lambda" {
  program = ["bash", "-c", "cd src/request && go mod tidy && env GOOS=linux GOARCH=arm64 go build -o bootstrap main.go && echo '{\"filename\":\"bootstrap\"}'"]
}

# Build RESPONSE Lambda
data "external" "build_get_lambda" {
  program = ["bash", "-c", "cd src/response && go mod tidy && env GOOS=linux GOARCH=arm64 go build -o bootstrap main.go && echo '{\"filename\":\"bootstrap\"}'"]
}

Importante: Cada lambda tiene su propio módulo Go y se compila independientemente.

Despliegue

# Clonar e inicializar
git clone https://github.com/tu-usuario/golang-serverless-terraform.git
cd golang-serverless-terraform/01_GST_mimic

# Configurar credenciales AWS 
# Ref: https://gist.github.com/olcortesb/a471797eb1d45c54ad51d920b78aa664

# Desplegar
terraform init
terraform plan
terraform apply

Probando la API

# Obtener valores de salida
API_URL=$(terraform output -raw api_gateway_url)
API_KEY=$(terraform output -raw api_key_value)

# Almacenar JSON de usuario
curl -X POST "${API_URL}/mimic" \
  -H "x-api-key: ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Alice",
    "email": "alice@example.com",
    "preferences": {
      "theme": "dark",
      "notifications": true
    }
  }'

# Respuesta: "550e8400-e29b-41d4-a716-446655440000"

# Recuperar JSON
curl -X GET "${API_URL}/mimic/550e8400-e29b-41d4-a716-446655440000" \
  -H "x-api-key: ${API_KEY}"

Comparativa Js vs Go

Aspecto	JavaScript	Go
Cold Start	~200ms	~50ms
Memoria	128 MB mínimo	128 MB eficiente
Costo	x86_64 estándar	ARM64 (-50%) Aproximado
Tipado	Dinámico	Estático
Compilación	Runtime	Build time

Monitoreo y observabilidad

Terraform automáticamente configura:

CloudWatch Logs: Para debugging de las lambdas
API Gateway Metrics: Latencia, errores, throttling
DynamoDB Metrics: Read/Write capacity, throttling
Usage Plan Monitoring: Cuotas y límites de rate

Limpieza

terraform destroy

Conclusiones

La implementación de mimic en Go + Terraform nos ofrece:

Rendimiento superior: Cold starts más rápidos y mejor throughput
Costo optimizado: ARM64 reduce significativamente los costos
Infraestructura reproducible: Terraform garantiza consistencia
POC: Utilizaré este código como una POC para ir mejorando, actualizando y realizando pruebas sobre Golang + AWS Lambda

Este stack es perfecto para:

Entornos de desarrollo y testing
Mocking de servicios externos
Prototipado rápido de APIs
Cache temporal de datos
🙋 Laboratorios de infraestructura (Fundamentalmente para lo que lo uso …)

En el próximo artículo exploraremos cómo integrar mimic con otros servicios AWS como S3 Events y SQS para crear arquitecturas event-driven más complejas.

¡Gracias por leer, saludos!

Referencias

Probando AWS CodeCatalyst🚀 desde el AWS Builder ID 👷

olcortesb — Wed, 06 Aug 2025 11:43:20 +0000

Source: https://olcortesb.hashnode.dev/probando-aws-codecatalyst-desde-el-aws-builder-id

En este post mostraré cómo conectarse a AWS CodeCatalyst desde el ID de Builder, aprovechando la capa gratuita. Realizaremos algunas pruebas de las funcionalidades básicas y, en futuros posts, profundizaremos en las características avanzadas del servicio.

🚀 En primer lugar ¿Qué es AWS CodeCatalyst?

AWS CodeCatalyst es un servicio gestionado por AWS que unifica en una sola plataforma todas las etapas del desarrollo de software: planificación, codificación, pruebas, integración continua (CI), entrega continua (CD) y despliegue.

https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html

👷 y ¿Qué es el AWS Builder ID?

AWS BuilderID es tu identidad personal unificada dentro del ecosistema de AWS. A diferencia de una cuenta de AWS, que está diseñada para acceder a servicios desde la consola o AWS cli, el BuilderID te permite iniciar sesión en herramientas de aprendizaje, desarrollo o colaboración como Amazon Q Developer, CodeCatalyst, entre otros.

https://docs.aws.amazon.com/signin/latest/userguide/sign-in-aws_builder_id.html

https://docs.aws.amazon.com/signin/latest/userguide/differences-aws_builder_id.html

Conectándonos a CodeCatalyst

Accediendo a la URL de CodeCatalyst nos da las opciones de conectarnos por Builder ID (1) o SSO (2), ya podemos observar que es un servicio con inicio de sesión y acceso fuera de la consola tradicional de AWS.

Luego de seleccionar el ID, si es la primera vez que entramos nos solicitará un nombre de espacio de trabajo, región y la cuenta a la que queremos asociar los recursos y servicios que vamos a desplegar, así como el costo.

Configurados estos elementos pasamos a la pantalla principal de administración del servicio, donde podemos gestionar las cuentas sobre las que actuaremos (1) y los miembros de este espacio de trabajo (2) entre otras configuraciones.

Creación de un nuevo proyecto

Bien, ahora vamos a crear un proyecto desde un Blueprint y a desplegar la aplicación. Tenemos tres opciones para crear un proyecto, vamos a utilizar la opción desde Blueprint (1) para este post.

Al seleccionar Blueprint se despliegan una serie de Blueprints configurados que al elegir alguno (1) nos dará detalles de los servicios que usa, arquitectura y permisos necesarios (2).

En el siguiente paso podemos seleccionar el nombre del proyecto (1), dónde vamos a almacenar el código (2) que me parece una funcionalidad interesante para equipos que no quieren gestionar su código desde CodeCatalyst, y la cuenta donde vamos a desplegar el servicio (3).

Importante para poder acceder a la cuenta realizar una aprobación en la cuenta destino.

Y también nos pedirá agregar un rol desde la cuenta:

💡
Importante es necesario agregar una cuenta donde facturar aunque estemos usando el free tier

Y finalmente creamos el proyecto, elegimos Python, pero podemos elegir la herramienta de IaC (Infrastructure as Code) que en este caso es CDK

Con un "Run" en la sección CI/CD ejecutamos el pipeline que tiene el Blueprint

Y probando la API validamos que funciona correctamente:

Y en la DynamoDB …

Conclusiones y comentarios

Historia

Diciembre de 2022: AWS presentó CodeCatalyst en versión preview durante el congreso re:Invent 2022, anunciándose como una herramienta todo en uno para flujo DevOps en AWS
announcing-amazon-codecatalyst-preview-a-unified-software-development-service
20 de abril de 2023: CodeCatalyst alcanzó la disponibilidad general (GA). Desde entonces, soporta workflows con AWS Graviton, integración de repositorios GitHub o GitLab, gestión de issues vinculadas a pull requests y mucho más

general-availability-amazon-codecatalyst

Actualidad

En julio de 2025, se lanzó la imagen universal Universal image 5.0.

https://docs.aws.amazon.com/codecatalyst/latest/userguide/doc-history.html
También se añadieron mejoras en temas de privacidad de datos, roles, y eliminación de Blueprints obsoletos.

Documentación de AWS

Conclusiones

Hemos conectado AWS CodeCatalyst a través del Builder ID, conectando una cuenta de destino y desplegando un Blueprint correctamente.
Es un servicio integral que permite centralizar todos los servicios que un equipo de desarrollo necesita para gestionar el ciclo de vida de las aplicaciones en AWS.
Hay mucho camino para probar y desarrollar utilizando las features que CodeCatalyst tiene para ofrecer.

Gracias por leer, Saludos…

🚀 Golang + ⚡ Lambda + 🏗️Terraform

olcortesb — Wed, 16 Jul 2025 12:39:04 +0000

Source: https://olcortesb.hashnode.dev/golang-lambda-terraform

Como siempre por estos caminos estoy hablando de Serverless y sus derivados, en esta ocasión contaré un poco sobre como es desplegar funciones AWS Lambda en Go con Terraform no es complejo, pero tenemos que tener consideraciones.

En este artículo te muestro cómo crear una función Lambda básica en Golang usando el runtime provided.al2023 y por qué es la mejor opción actualmente.

Estructura del proyecto

Aquí Link dejaré el repositorio con el código completo.

00_GST_lambda/
├── src/
│   ├── go.mod          # Módulo Go
│   ├── main.go         # Código fuente
│   └── bootstrap       # Binario compilado (generado)
├── main.tf             # Recursos Terraform
├── variables.tf        # Variables configurables
├── outputs.tf          # Outputs del módulo
├── providers.tf        # Configuración de providers
├── backend.tf          # Backend de Terraform
└── README.md           # Documentación

El código Go

Primero creamos una función Lambda básica en Go. Lo importante aquí es usar la librería oficial aws-lambda-go:

// main.go
package main

import (
    "github.com/aws/aws-lambda-go/lambda"
)

func hello() (string, error) {
    return "Hello λ!", nil
}

func main() {
    // Make the handler available for Remote Procedure Call by AWS Lambda
    lambda.Start(hello)
}

Y nuestro go.mod debe tener un nombre diferente al de la dependencia:

module lambda-function

go 1.23

require github.com/aws/aws-lambda-go v1.49.0

Importante: El nombre del módulo no puede ser github.com/aws/aws-lambda-go porque entraría en conflicto con la dependencia.

La infraestructura Terraform

Compilación automática

El truco está en usar un data source external que compile automáticamente nuestro código Go:

# Crear archivo ZIP con el código compilado
data "external" "build_lambda" {
  program = ["bash", "-c", "cd src && env GOOS=linux GOARCH=arm64 go build -o bootstrap main.go && echo '{\"filename\":\"bootstrap\"}'"]
}

data "archive_file" "lambda_zip" {
  type        = "zip"
  source_file = "${path.module}/src/bootstrap"
  output_path = "${path.module}/lambda_function.zip"
  depends_on  = [data.external.build_lambda]
}

Clave: El ejecutable debe llamarse bootstrap, no main. El runtime provided.al2023 busca específicamente este nombre.

Rol IAM y función Lambda

# Rol IAM para Lambda
resource "aws_iam_role" "lambda_role" {
  name = var.role_name

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

# Función Lambda
resource "aws_lambda_function" "go_lambda" {
  filename         = data.archive_file.lambda_zip.output_path
  function_name    = "go-hello-serverless-lambda"
  role             = aws_iam_role.lambda_role.arn
  handler          = "main"
  runtime          = "provided.al2023"
  architectures    = ["arm64"]
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256

  depends_on = [
    aws_iam_role_policy_attachment.lambda_basic,
    data.archive_file.lambda_zip
  ]
}

🤔 ¿ Por qué usar `provided.al2023` en lugar de `go1.x`?

Si has trabajado con Lambda en Go anteriormente, probablemente usaste el runtime go1.x. Sin embargo, AWS deprecó todos los runtimes nativos de Go en diciembre de 2023.

The Go 1.x managed runtime for Lambda is deprecated If you have functions that use the Go 1.x runtime, you must migrate your functions to provided.al 2023 or provided.al 2. The provided.al 2023 and provided.al 2 runtimes offer several advantages over go1.x, including support for the arm64 architecture (AWS Graviton2 processors), smaller binaries, and slightly faster invoke times.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-golang.html?utm_source=chatgpt.com

Como se ve la recomendación oficial es usar provided.al2023 por estas razones:

Soporte ARM64: Arquitectura Graviton2 que es 50% más barata que x86_64
Control total: Siempre usas la última versión de Go que necesites
Mejor rendimiento: Binario nativo sin overhead del runtime
Sin deprecación: AWS no puede deprecar tu versión de Go

Despliegue

# Inicializar Terraform
terraform init

# Ver plan de despliegue
terraform plan

# Aplicar cambios
terraform apply

Verificamos el despliegue

En nuestra consola de AWS verificamos que la función se desplegó correctamente:

Podemos ver que:

Runtime: provided.al2023
Arquitectura: arm64
Handler: bootstrap

Probando nuestra función Lambda

Para probar la función podemos usar la consola de AWS o el CLI:

aws lambda invoke --function-name go-hello-serverless-lambda response.json
cat response.json

El resultado debería ser:

more response.json
# "Hello λ!"

Errores conocidos:

Si ves este error … :

{
  "errorType": "Runtime.InvalidEntrypoint",
  "errorMessage": "Couldn't find valid bootstrap(s): [/var/task/bootstrap /opt/bootstrap]"
}

Es porque el ejecutable no se llama bootstrap. Asegúrate de compilar con:

env GOOS=linux GOARCH=arm64 go build -o bootstrap main.go

Conclusiones

Usar provided.al2023 para funciones Lambda en Go nos da:
El proceso de despliegue con Terraform es directo una vez que entiendes los detalles del runtime y la compilación automática.

¡Gracias por leer, saludos!

Referencias

▶️ Habilitar MFA (Multi-Factor Authentication)🔐 en AWS Cognito usando Terraform

olcortesb — Tue, 01 Jul 2025 13:10:10 +0000

Source: https://olcortesb.hashnode.dev/habilitar-mfa-multi-factor-authentication-en-aws-cognito-usando-terraform

En un post anterior, comentaba como desplegar AWS Cognito y una aplicación cliente utilizando Terraform. Este artículo es parte de la serie que comente realizaría sobre Cognito + Terraform. En el post de hoy nos centraremos en ver como habilitar el Multi Factor de Autenticación en Cognito con Terraform y realizaremos algunas pruebas.

Estructura del repositorio:

Similar al repositorio anterior, pero ahora en una nueva rama “add-mfa-configuration” tenemos el código de Terraform para desplegar nuestra infraestructura.

https://github.com/olcortesb/cognito-terraform/tree/feat/add-mfa-configuration

cognito.tf – Main Cognito resources configuration
config.tf – Terraform backend configuration
variables.tf – Input variable definition
maint.tf – AWS provider configuration
sns_sms.tf Role and policy for SMS
terraform.tfvars – Variable values for deployment

Habilitando el MFA:

Para habilitar el MFA es necesario agregar dentro de la definición del Cognito, además de activar el mfa_configuration es necesario activar el software_token_mfa_configuration, acorde a las definiciones y documentación de Terraform:

  // cognito.tf
resource "aws_cognito_user_pool" "this" {
  ...
  mfa_configuration          = "ON"
  sms_authentication_message = "Your code is {####}"

  sms_configuration {
    external_id    = "cognito-external-id"
    sns_caller_arn = aws_iam_role.cognito_sms_role.arn
    sns_region     = var.region
  }

  software_token_mfa_configuration {
    enabled = true
  }
  ...
}

Creando Roles y Policy

El archivo sns_sms.tf tiene los roles y Policy necesarios para el Cognito.

# IAM Role for Cognito to send SMS via SNS
resource "aws_iam_role" "cognito_sms_role" {
  name = "cognito-sms-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = {
          Service = "cognito-idp.amazonaws.com"
        },
        Action = "sts:AssumeRole",
        Condition = {
          StringEquals = {
            "sts:ExternalId" = "cognito-external-id"
          }
        }
      }
    ]
  })
}

# IAM Policy for Cognito SMS Role
resource "aws_iam_role_policy" "cognito_sms_policy" {
  name = "cognito-sms-policy"
  role = aws_iam_role.cognito_sms_role.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "sns:Publish"
        ],
        Resource = "*" // Remplazar por el resources para ambientes productivos
      }
    ]
  })
}

Configurando el Sandbox para el envío de mensajes:

Es necesario para las pruebas habilitar los números de teléfono en un ambiente de sandbox controlado los teléfonos a los que permitiremos el envío de mensaje, es recomendado probar primero en sandbox antes de pasa a un esquema productivo

Es necesario dar de alta los teléfonos que vamos a utilizar en las pruebas.

Damos de alta un usuario:

En esta configuración no habilitamos la autoverificación del teléfono para asegurarnos que el usuario cargue un teléfono válido

Prueba de Login:

A continuación un video de ejemplo de como funciona el doble factor de autenticación en Cognito:

Conclusiones

Hemos habilitado el MFA con Terraform agregando una configuración al Cognito y un par de Policy y roles.
Hemos habilitado el Sandbox, con números de teléfono específicos para las pruebas del Cognito.
⚠️ Importante para remover el MFA por seguridad es necesario dar de baja el Cognito, tener en cuenta para ambientes productivos.

Referencias

🚀 Desplegar AWS Cognito 🔑 y una Aplicación Cliente Con Terraform.

olcortesb — Tue, 17 Jun 2025 20:26:46 +0000

Fuente: Post

En una entrada anterior contaba un poco sobre que es AWS Cognito Link, he estado realizando muchas pruebas con nuevas funcionalidades e identificando las posibilidades que tenemos para integrarla con nuestras aplicaciones.

He decidido armar una serie de artículos con distintas configuraciones e integraciones para entender en profundidad este servicio de AWS, y como siempre es mejor empezar por el principio.

Vamos a Desplegar AWS Cognito + una aplicación Cliente utilizando Terraform, Aquí Link dejaré el repositorio con el código, recuerda cambiar el nombre de los buckets y las aplicaciones.

Estructura del repositorio:

https://github.com/olcortesb/cognito-terraform

cognito.tf – Main Cognito resources configuration
config.tf – Terraform backend configuration
variables.tf – Input variables definition
maint.tf – AWS provider configuration
terraform.tfvars – Variable values for deployment

El “User pool”

Para definir el user pool utilizamos el recurso "aws_cognito_user_pool" de Terraform, importante definir los atributos del usuario (recordar que Cognito tiene unos atributos predefinidos) y los atributos custom que se configura con un esquema más, tenemos hasta 50 atributos custom para agregar. Ref

# 1. User Pool
resource "aws_cognito_user_pool" "this" {
  name                     = "olcb-community-user-pool"
  username_attributes      = ["email"]
  auto_verified_attributes = ["email"]

  admin_create_user_config {
    allow_admin_create_user_only = false
  }
  # Configuraciones del password
  password_policy {
    minimum_length    = 8
    require_lowercase = true
    require_uppercase = true
    require_numbers   = true
    require_symbols   = false
  }
  # habilitar attributo predefinido  
  schema {
    name                = "email"
    attribute_data_type = "String"
    required            = true
    mutable             = true
  }
  # Atrributo custom
  schema {
    name                = "custom_attr"
    attribute_data_type = "Number"
    required            = false
    mutable             = true
    number_attribute_constraints {
      min_value = 1
      max_value = 100
    }
  }
}

Esta parte del código crea nuestro User Pool

Una vez configurado el User Pool necesitamos crear una aplicación Cliente que Sirva de integración con las aplicaciones externas que se conectaran a través de Cognito.

La “App Cliente”

La aplicación cliente la desplegamos utilizando el recurso "aws_cognito_user_pool_client", los parámetros más importantes son la referencia al User Pool que creamos en el paso anterior, user_pool_id, los flujos que aceptaremos allowed_auth_flows y el proveedor de los que tengamos en Cognito que soportará esta aplicación supported_identity_providers

# 2. App Client
resource "aws_cognito_user_pool_client" "this" {
  name                                 = "olcb-app-client"
  user_pool_id                         = aws_cognito_user_pool.this.id
  generate_secret                      = false
  allowed_oauth_flows_user_pool_client = true
  allowed_oauth_flows                  = ["code", "implicit"]
  allowed_oauth_scopes                 = ["email", "openid", "profile"]
  explicit_auth_flows                  = ["ADMIN_NO_SRP_AUTH", "USER_PASSWORD_AUTH"]
  callback_urls                        = ["https://example.com/callback"]
  logout_urls                          = ["https://example.com/logout"]

  supported_identity_providers = ["COGNITO"]
  refresh_token_validity       = 30
}

Este recurso generará la aplicación dentro de nuestro Cognito user pool

El “User Pool Domain”

Finalmente, asignamos un dominio para que nuestras URLs de login y alta de usuarios y LogOut:

# 3. User Pool Domain
resource "aws_cognito_user_pool_domain" "this" {
  domain       = "olcb-app-domain"
  user_pool_id = aws_cognito_user_pool.this.id
}

En el apartado domain de nuestro Cognito User Pool tendremos la URI que hemos definido en el Terraform.

Pantalla de Login

Finalmente, tendremos operativo nuestro Cognito con un login “UI Clásico”, y el dominio que hemos configurado.

En siguientes entrada mostraré como es el circuito de alta de usuario, conexión desde una app en Python y varias características más,

gracias por leer, Saludos

Referencias

📝 Como listar la concurrencia reservada y aprovisionada de nuestras Lambdas ⚡.

olcortesb — Wed, 28 May 2025 09:05:24 +0000

Source: https://olcortesb.hashnode.dev/como-listar-la-concurrencia-reservada-y-aprovisionada-de-nuestras-lambdas

La concurrencia en funciones lambdas se refiere al número de solicitudes que una función puede manejar simultáneamente. Existen dos tipos principales de control de concurrencia:

Concurrencia reservada: Establece un límite máximo de instancias simultáneas para una función específica, garantizando que otras funciones no utilicen esa capacidad. No tiene costos y no mejora el Cold start. El límite por cuenta de la concurrencia reservada es de 1000, se puede aumentar a nivel de cuenta.
Concurrencia aprovisionada: Mantiene un número fijo de entornos de ejecución pre inicializados para una función, asegurando que estén listos para manejar solicitudes sin demora. Tiene un costo 💵adicional y ayuda a mejorar el Cold Start ❄️. Son Lambdas que están siempre encendidas ⚠️.

Bien, con esto en mente supongamos un escenario donde tenemos una región con más de 70 lambdas desplegadas y por alguna razón, no tenemos control sobre como está distribuida la concurrencia entre estas lambdas.

Con este escenario podemos intentar ir a AWS cli, o crear un Script de Python (u otro lenguaje) para consultar a través del SDK (Boto3), y en ese momento nos daremos cuenta de que posiblemente nos retorne cero cuando el panel de Amazon y el costo nos está indicando que tenemos concurrencia reservada:

💡 Bien, lo que sucede es que no podemos realizar la consulta si el rol o el usuario que estamos usando para consultar no tiene permisos(🔏)para acceder a esta información de las lambdas.

Solución Alternativa y Reutilizable

Como no podría ser de otra manera para quien me ha leído antes, la solución propuesta es una Lambda 😀que haga este trabajo, desplegado con AWS Sam, y que podemos desplegar y destruir de manera rápida y en distintas regiones.

Código Fuente

https://github.com/olcortesb/list-lambda-provisioned-reserved

Repositorio con todo el codigo que se presenta en este post

Los permisos:

El primer punto es definir la infraestructura y definir los permisos correspondientes.

# https://github.com/olcortesb/list-lambda-provisioned-reserved/blob/main/template.yaml 
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: List Lambda provisioned reserved

Resources:                
  ListFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: lambda.lambda_handler
      Runtime: python3.10
      Architectures: [arm64]
      Timeout: 900
      Policies:
        - Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - lambda:GetFunctionConcurrency
                - lambda:ListFunctions
                - lambda:ListProvisionedConcurrencyConfigs
              Resource: "*"

Los permisos relacionados con Provicioned y concurrency son los que permiten acceder a los atributos.

El código:

El código está basado en Boto3 y lo que hacemos es consultar por todas las lambdas y revisar cuáles tienen configuraciones de concurrencia.

# https://github.com/olcortesb/list-lambda-provisioned-reserved/tree/main/src
# Base on https://repost.aws/knowledge-center/lambda-provisioned-reserved-concurrency
import os
import boto3

def lambda_handler(event, context):
        ...
            try:
                response = lambda_client.get_function_concurrency(
                    FunctionName=function_name
                )
                if 'ReservedConcurrentExecutions' in response:
                    count += 1
                    reserved_concurrency = response['ReservedConcurrentExecutions']
                    print(f"{count}. Function Name: {function_name}, Reserved Concurrency: {reserved_concurrency}")  
            except lambda_client.exceptions.ResourceNotFoundException:
                pass
            except Exception as e:
                print(f"Error retrieving concurrency for {function_name}: {e}")
            try:
                response = lambda_client.list_provisioned_concurrency_configs(
                    FunctionName=function_name
                )
                if 'ProvisionedConcurrencyConfigs' in response and response['ProvisionedConcurrencyConfigs']:
                    provisioned_concurrency = response['ProvisionedConcurrencyConfigs'][0]['RequestedProvisionedConcurrentExecutions']
                    count += 1
                    print(f"{count}. Function Name: {function_name}, Provisioned Concurrency: {provisioned_concurrency}")
            except lambda_client.exceptions.ResourceNotFoundException:
                pass
            except Exception as e:
                print(f"Error retrieving provisioned concurrency for {function_name}: {e}")

Resultados

Ale ejecutar la función recorrerá todas las lambdas que tenemos en la región donde la hemos desplegado y validara si tienen configurada concurrencia reservada o provisionada respectivamente, dándonos un listado de las funciones y la cantidad de concurrencia. Para este ejemplo lo sacamos en un log, pero se puede obtener vía API o enviarlo a algún lugar que concentre los reportes de nuestra infraestructura

Function Logs:
START RequestId: 253fe873-d35c-44e2-8593-f6a43b9cecc3 Version: $LATEST
Total functions 75
1. Function Name: fibonacci-x86-n4, Reserved Concurrency: 5
2. Function Name: fibonacci-x86-n4, Provisioned Concurrency: 1
END RequestId: 253fe873-d35c-44e2-8593-f6a43b9cecc3
REPORT RequestId: 253fe873-d35c-44e2-8593-f6a43b9cecc3  Duration: 8857.61 ms ...

Conclusión

Probamos como poder obtener los datos de nuestra concurrencia en una región específica.
Identificamos los permisos necesarios para que la lambda pueda consultar por estos permisos
Sacamos en un log los resultados como prueba básica, pudiendo enviarlos a distintos destinos o devolviendo mediante una API de ser necesario