DEV Community: Carlos Garcés

Deja de usar requests en tus Lambdas: a tu CTO le encantará

Carlos Garcés — Sun, 25 Oct 2026 20:49:46 +0000

Introducción: Dos librerías, distinto funcionamiento en AWS Lambda

En el ecosistema de Python, requests es la opción por defecto para muchos cuando interactúan con HTTP. Bajo el lema «HTTP for Humans» («HTTP para humanos»), requests ofrece una API intuitiva y de alto nivel que abstrae los mecanismos de cabeceras, parámetros de consulta, cookies y serialización JSON.

Cualquier desarrollador de Python usa por defecto requests. Es elegante, intuitiva y prácticamente un sinónimo de HTTP en Python. Por eso, al crear una función en Python que llama a un webhook externo o a un microservicio interno, la reacción inmediata es:

pip install requests

Sin embargo, bajo esa superficie tan amigable para el desarrollador, requests en realidad no gestiona las comunicaciones de red de bajo nivel por sí misma. En su lugar, se apoya en urllib3 como motor de transporte subyacente.

Qué hace realmente cada librería

Para entender por qué deberías prescindir de requests en Lambda, primero es necesario comprender la relación entre ambos paquetes:

urllib3 es un cliente de transporte HTTP de bajo nivel. Gestiona directamente las conexiones de sockets, el pooling de conexiones, la resolución DNS y los handshakes SSL/TLS.
requests es una capa envolvente de alto nivel, construida sobre urllib3.

requests no reinventa la rueda; delega el trabajo pesado en urllib3. Lo que requests aporta es mejoras de sintaxis: codificación automática de diccionarios, gestión de cookies, serialización JSON integrada y objetos de respuesta de alto nivel.

Ambas librerías realizan un trabajo similar pero los entornos de ejecución (runtimes) de AWS Lambda ya incluyen preinstalados boto3 y botocore, los cuales dependen directamente de urllib3. Como resultado, urllib3 ya está disponible de forma nativa en cualquier entorno Python de AWS Lambda sin añadir un solo kilobyte al tamaño de tu paquete de despliegue.

Actualizaciones del entorno de ejecución: ¿acaso no puede hacerlo otro?

Una de las mayores ventajas operativas de AWS Lambda es el ciclo de vida gestionado de su entorno de ejecución (Managed Runtime Lifecycle); como nos enseñó el episodio Trash of the Titans, siempre es mejor cuando alguien más lo hace por ti.

Cómo gestiona AWS urllib3

Los runtimes de Python en AWS Lambda vienen con el SDK de AWS (boto3 / botocore) preinstalado. Dado que botocore depende de urllib3, urllib3 ya está presente dentro de tu entorno Lambda sin necesidad de empaquetarlo.

Además, AWS aplica automáticamente parches de seguridad, correcciones de errores menores y actualizaciones de mantenimiento en los runtimes gestionados mediante despliegues de runtime en dos fases. Cuando se corrige una vulnerabilidad en urllib3, AWS actualiza el entorno subyacente en toda tu flota por ti, sin necesidad de un nuevo despliegue ni de ejecutar tus pipelines de CI/CD.

Qué ocurre cuando empaquetas `requests`

requests no forma parte del runtime nativo de Lambda. Cuando la incluyes en tu archivo zip o en una Lambda Layer, se instalan todas sus dependencias:

requests==2.34.2
┣━━ ✓ certifi required: >=2023.5.7 installed: 2026.6.17
┣━━ ✓ charset-normalizer required: >=2,<4 installed: 3.4.7
┣━━ ✓ idna required: >=2.5,<4 installed: 3.18
┗━━ ✓ urllib3 required: >=1.26,<3 installed: 2.6.3

Este subárbol de dependencias no está gestionado por AWS, y tú eres el responsable de mantenerlo al día, con las siguientes consecuencias:

Tú eres dueño del ciclo de mantenimiento: AWS nunca actualizará ni parchará requests por ti. Si se descubre una vulnerabilidad, todas y cada una de las funciones Lambda que incluyan requests seguirán expuestas hasta que alguien actualice el archivo requirements.txt, recompile el artefacto y lo vuelva a desplegar.
Exposición a vulnerabilidades de seguridad: Los escáneres de seguridad detectan dependencias desactualizadas en CI/CD. Por ejemplo, vulnerabilidades recientes como CVE-2026-25645 (extracción en rutas temporales predecibles). Sé que sabes que esto probablemente no afecte a un entorno aislado como Lambda, pero las herramientas de seguridad estática (como Amazon Inspector) generarán una alerta automáticamente. Buena suerte explicando a tu equipo de seguridad que un CVE específico es un «falso positivo».
Aumento de dependencias: Empaquetar requests, certifi, idna y charset-normalizer engorda los paquetes de despliegue, incrementando los tiempos de subida y prolongando ligeramente la descompresión del código en los inicios en frío (cold starts). Además, estas dependencias adicionales pueden introducir problemas de seguridad imprevistos, como los incidentes recientes con los paquetes de certifi y los certificados de eMudhra.

Al cambiar a la versión nativa de urllib3 del runtime, eliminas todo un subárbol de dependencias externas y delegas la aplicación de parches de seguridad en AWS.

Entendiendo la fase INIT de Lambda

En AWS Lambda, la ejecución se divide en dos fases bien diferenciadas del ciclo de vida:

La fase de inicialización (INIT): Ejecuta todo el código a nivel de módulo que está fuera de lambda_handler. Esto ocurre una sola vez cuando se arranca un entorno de ejecución.
La fase de invocación (Invocation): Ejecuta lambda_handler(event, context) en cada petición recibida.

Un antipatrón clásico con requests es invocar requests.get() directamente dentro del handler:

def lambda_handler(event, context):
  # ¡Crea una conexión completamente nueva en cada invocación!
  response = requests.get("https://api.example.com/data")
  return response.json()

Dado que requests.get() no mantiene estado, cada invocación realiza una nueva resolución DNS, handshake TCP y negociación TLS desde cero. Bajo un alto volumen de tráfico, esto añade algun milisegundo de latencia a cada llamada.

La solución: urllib3.PoolManager global

urllib3 se articula en torno a PoolManager, que es seguro para hilos (thread-safe) y mantiene los sockets abiertos entre invocaciones cuando se declara en el ámbito estático de INIT:

import urllib3

# Inicializado UNA SOLA VEZ durante la fase INIT de Lambda
http = urllib3.PoolManager(maxsize=10)

def lambda_handler(event, context):
  # Reutiliza la conexión TCP/TLS existente en invocaciones "warm"
  response = http.request("GET", "https://api.example.com/data")
  ...

Como el entorno de ejecución se mantiene activo (warm) entre invocaciones, la sesión TLS permanece establecida, reduciendo la sobrecarga de red a prácticamente cero en las llamadas subsiguientes.

Se puede obtener un resultado similar creando un objeto de sesión con la librería requests:

import requests

# Inicializado UNA SOLA VEZ durante la fase INIT de Lambda
session = requests.Session()

def lambda_handler(event, context):
  # Reutiliza la conexión TCP/TLS existente en invocaciones "warm"
  response = session.get("https://api.example.com/data")
  ...

Benchmarks de rendimiento y Cold-Start

Para comprobar el impacto en el rendimiento, se probaron 2 funciones Lambda diferentes utilizando aws lambda power tuning con los mismos parámetros:

{
    "lambdaARN": "lambda_arn",
    "powerValues": [128],
    "num": 100,
    "payload": {}
}

Métrica	`requests` (Handler)	`urllib3.PoolManager` (INIT)
Tamaño del paquete	653 KB	582 bytes
Inicio en frío (Cold Start)	840 ms	915 ms
Invocación promedio	340 ms	72 ms
Consumo de memoria	63 MB	56 MB

Guía de migración: de requests a urllib3

La migración es muy sencilla; cualquier LLM moderno puede hacerla por ti, solo debes indicarle que utilice PoolManager.

Aquí tienes los reemplazos directos para los patrones más comunes:

Patrón 1: Petición GET simple con parámetros de consulta

Antes (requests):

import requests

params = {"status": "active", "limit": 20}
resp = requests.get("https://api.example.com/items", params=params, timeout=5)
data = resp.json()

Después (urllib3):


  import json
  import urllib3

  http = urllib3.PoolManager()

  params = {"status": "active", "limit": 20}
  resp = http.request(
      "GET", "https://api.example.com/items", fields=params, timeout=5.0
  )
  data = json.loads(resp.data.decode("utf-8"))

Patrón 2: POST con carga útil (payload) JSON y cabeceras personalizadas

Antes (requests):

import requests

headers = {"Authorization": "Bearer secret-token"}
payload = {"name": "Widget", "price": 49.99}

resp = requests.post(
    "https://api.example.com/products", json=payload, headers=headers
)

Después (urllib3):


  import json
  import urllib3

  http = urllib3.PoolManager()

  headers = {
      "Authorization": "Bearer secret-token",
      "Content-Type": "application/json",
  }
  payload = {"name": "Widget", "price": 49.99}

  resp = http.request(
      "POST",
      "https://api.example.com/products",
      body=json.dumps(payload).encode("utf-8"),
      headers=headers,
  )

Patrón 3: Configurar reintentos automáticos con backoff exponencial

En requests, configurar reintentos requiere importar HTTPAdapter y Retry y montarlos en una sesión personalizada. En urllib3, los reintentos son una funcionalidad nativa de primer nivel:

import urllib3
from urllib3.util import Retry

# Configurar la estrategia de backoff
retries = Retry(
    total=3,
    backoff_factor=0.5,
    status_forcelist=[429, 500, 502, 503, 504],
    raise_on_status=False,
)

# Asociar los reintentos globalmente al pool manager
http = urllib3.PoolManager(retries=retries)


def lambda_handler(event, context):
  response = http.request("GET", "https://api.example.com/reliable-endpoint")
  return {"status": response.status}

Resumen: Por qué deberías dejar de usar requests en tus Lambdas

Pasar de requests a urllib3 en tus Lambdas le aporta beneficios inmediatos a tu equipo de ingeniería:

Cero dependencias de terceros que empaquetar, comprimir en zip o compilar en capas (layers).
Parches automáticos de vulnerabilidades mantenidos directamente por AWS.
Invocaciones promedio más rápidas y ejecuciones «warm» ultrarrápidas gracias a pools de conexiones persistentes.
Informes de auditoría limpios sin avisos de CVE transitivos.

Tu código se mantiene limpio, tus Lambdas se ejecutan más rápido y tu CTO no tendrá que preocuparse por el próximo zero-day en una dependencia.

Nuevas instancias T8i, ¿hora de jubilar tus T3i?

Carlos Garcés — Sat, 19 Sep 2026 19:39:17 +0000

Introducción: ¿Qué ofrece la familia T8i?

Las instancias Amazon EC2 T8i son la versión más reciente de instancias burstable de bajo costo en AWS. Están impulsadas por el AWS Nitro System y procesadores personalizados Intel Xeon Scalable de 6.ª generación (Granite Rapids). Diseñadas para cargas de trabajo con uso de CPU de bajo a moderado (como microservicios, entornos de desarrollo/pruebas, sitios web de bajo tráfico y procesamiento por lotes).

¿Y cual es la diferencia con mis venerables T3?

Arquitectura de procesador antigua: Las instancias T3 se lanzaron en 2018, en informática 8 años de diferencia son como los años de un perro

Rendimiento de cómputo inferior: Las nuevas instancias T8i ofrecen hasta un 70% más de rendimiento de cómputo, 1.25 veces más ancho de banda de red y 2.4 veces más ancho de banda para EBS en comparación con las T3.

Genial las T8i son mas rápidas, ¿migro ya?

No tan rápido, debido a las mejoras tanto en CPU como en memoria AWS asegura ofrecer hasta un 30% mejor relación precio-rendimiento en comparación con T3. Sin embargo en la nota de prensa no hablan de que son un 20% mas caras.

Además hay que tener en cuenta que las T8i no están cubiertas aún por los saving plans y que pueden no estar disponibles en tu región.

Alternativas a T3 basadas en costo y rendimiento

Al evaluar una estrategia de migración desde T3, existen diferentes casuísticas según el patrón de uso y el tamaño requerido:

Reemplazo directo a T8i: T8i solo ofrece los tamaños nano, micro, small y medium. El reemplazo directo no tiene riesgo desde el punto de vista del rendimiento ya que se mantiene la cantidad de CPU y memoria.
Instancias de rendimiento dedicado sin créditos (c6a, m6a, c7i-flex): Diseñadas para aplicaciones con un uso de CPU continuo o sostenido donde los límites de créditos de la serie T generan sobrecostes o cuellos de botella.
Instancias optimizadas en memoria (r6a, r8i-flex): Recomendadas para cargas que superan los tamaños de T8i o que requieren mantener el tamaño de la memoria.
Migración a soluciones gestionadas por AWS: Es un caso de uso poco habitual, pero en determinadas situaciones una migración de la máquina EC2 a la solución gestionada por AWS puede ahorrar costes.

Escenarios de Migración y Comparativas

Escenario 1: `t3` vs `t8i` para tamaños menores a `large` (`nano`, `micro`, `small`, `medium`)

Para tamaños pequeños, la migración a T8i proporciona un incremento de hasta el 70% en el rendimiento de cálculo y mayor capacidad de red/EBS, logrando una mejora general de precio-rendimiento de hasta el 30%.

Si en la T3 actual la CPU es cuello de botella, la migración a T8i puede eliminar el cuello de botella.

Además si la instancia T3 está consumiendo créditos en modo ilimitado, la mejora de CPU causará un menor consumo de créditos, que puede compensar el 20% de incremento de coste.

Métrica / Característica	Familia T3 (`< large`)	Familia T8i (`< large`)
Procesador	Intel Xeon Platinum (hasta 3.1 GHz)	Intel Xeon Scalable n (hasta 3.8 GHz)
Rendimiento CPU	Base previa	Hasta +70% rendimiento de cómputo
Ancho de banda Red	Hasta 5 Gbps (`t3.medium`)	Hasta 6.25 Gbps (`t8i.medium`, 1.25x mayor)
Ancho de banda EBS	Hasta 2,085 - 2,780 Mbps	Hasta 2.4x mayor ancho de banda EBS
Ejemplo de Costo On-Demand	`t3.medium`: $0.046 / hora	`t8i.medium`: $0.055 / hora

Escenario 2: `t3` vs `m6a`, `c6a` y `c7i-flex` para aplicaciones de alto uso de CPU y poca memoria

En aplicaciones con uso de CPU bajo pero constante, las instancias T3 pueden convertirse en una trampa de costos debido a su arquitectura basada en créditos de CPU:

El riesgo de los créditos en T3: En modo Standard, si se agotan los créditos acumulados, el rendimiento de la CPU se restringe drásticamente a la línea base (por ejemplo, 30% por vCPU en t3.large). En modo Unlimited (activado por defecto), si el uso promediado en 24 horas supera la línea base, AWS cobra $0.05 adicionales por vCPU-hora. Si una instancia t3.large (2 vCPUs) se ejecuta al 100% de CPU de manera continua, el recargo suma $0.10/hora, elevando el costo total real de ~$0.0835/hora a ~$0.1835/hora.
La ventaja de m6a, c6a y c7i-flex: Estas familias ofrecen vCPUs dedicadas al 100% de rendimiento constante, eliminando la volatilidad de créditos y garantizando una capacidad fija.

Migrar a familias de tipo c permite cambiar el ratio de CPU y memoria (2 GB de RAM por cada vCPU), esta opción es solo válida si se está usando menos del 50% de memoria en la instancia T3 actual.

Si por el contrario se quiere mantener el ratio de CPU y memoria se debe optar por una m6a, esta opción es solo válida si la instancia T3 está consumiendo créditos en modo unlimited, causando costos adicionales.

Instancia	vCPUs	Memoria (GiB)	Arquitectura CPU	Precio On-Demand (por hora)
`t3.large`	2	8	Intel Xeon 1.ª/2.ª Gen (30% línea base / requiere créditos)	$0.091 (+$0.10/h si consume créditos)
`c6a.large`	2	4	100% Dedicado (AMD EPYC)	$0.082
`m6a.large`	2	8	100% Dedicado (AMD EPYC 7R13 @ 3.6 GHz)	$0.096
`c7i-flex.large`	2	4	100% Dedicado (Sapphire Rapids @ 3.2 GHz)	$0.091

Escenario 3: `t3.xlarge` vs `r8i-flex.large` para aplicaciones de bajo uso de CPU y mucha memoria

Dado que T8i no ofrece un tamaño large, AWS recomienda migrar los tamaños superiores a instancias Flex.

Si la aplicación no hace un uso intensivo de la CPU y se quiere mantener la cantidad de memoria, es posible reemplazar las instancias t3.xlarge por r8i-flex.large. El procesador de la familia R8i es un 70% mas potente que las CPUs de la familia T3, es posible que aun reduciendo el número de vCPUs a la mitad, la mejora del 70% compense el rendimiento.

Después de hacer este cambio es necesario monitorizar la CPU del equipo, para confirmar que el rendimiento es aceptable.

Instancia	vCPUs	Memoria (GiB)	Arquitectura CPU	Precio On-Demand (por hora)
`t3.large`	4	16	Intel Xeon 1.ª/2.ª Gen (30% línea base)	$0.182
`r8i-flex.large`	2	16	Intel Xeon Scalable Granite Rapids @ 3.9 GHz	$0.148

Escenario 4: Migración a soluciones gestionadas por AWS

Reconozco que es un caso atípico pero he tenido clientes en esta situación.

Algunas veces tendemos a usar instancias EC2 en vez de las soluciones gestionadas por AWS intentando ahorrar algo de dinero en la factura mensual. Pero a veces estas soluciones se quedan obsoletas debido a cambios de precios en AWS.

Caso real en uno de mis clientes.

Maquina t3.micro usada como servidor Redis $0.011 hora. La instancia tenía asociada una IP pública que añadida $0.005 al coste por hora.

El servidor se levantó hace años, desde entonces muchas cosas han pasado:

2021 Amazon ofrece servidores redis con t4g
2024 AWS empieza a cobrar las IPs públicas
2025 AWS lanza Valkey con un precio por debajo del coste de Redis.

La T3 que montaste pensando en ahorrar dinero, resulta que es mas cara que su equivalente administrado.

Instancia	Costo On-Demand	Costo IP	Total
t3.micro	$0.0110 / hora	$0.005 / hora	$0.0160 / hora
t4g.micro	$0.0136 / hora		$0.0136 / hora

(*) En la tabla se han omitido los costes del disco EBS.

Normalmente migrar una máquina x86 a Arm64 puede conllevar bastante trabajo, pero al delegar en un servicio administrado AWS se encarga de la optimización del sistema para Arm64. Este caso de uso solo tiene sentido en máquinas pequeñas en las que el precio de la IP pública puede tener mas impacto.

Conclusión

La familia T3 no ha quedado desactualizada sigue siendo una opción barata para entornos con poco uso de CPU. Para entornos con tamaños iguales o menores a medium, la adopción de T8i ofrece ganancias inmediatas de hasta un 70% en rendimiento de procesamiento con un ahorro de precio-rendimiento de hasta el 30%. Para instancias large o superiores, la migración natural debe dirigirse hacia las instancias Flex (familias 7i u 8i) o hacia alternativas AMD (c6a / m6a) para eliminar definitivamente la sobrecarga por gestión de créditos de CPU.