Amazon SES para tu MVP: correo barato, configuración cruda

Todo MVP que envía correo transaccional termina enfrentando la misma disyuntiva: pagar más por un proveedor pulido y listo para usar, o pagar menos y construir por su cuenta más de la fontanería. Resend vs SendGrid trata la primera elección — dos proveedores que venden comodidad sobre la entrega de correo. Amazon SES (Simple Email Service) se sitúa completamente del otro lado de esa línea. Es la infraestructura cruda de envío de correo de AWS, con un precio cercano al costo real de enviar el correo, sin el pulido de paneles ni las herramientas de plantillas integradas. Para los MVP que vigilan cada dólar de gasto en infraestructura, esa diferencia vale la pena entenderla antes de elegir un proveedor por defecto.

Qué es realmente Amazon SES

SES es parte de AWS, no una empresa de correo independiente. Te da una API (y una interfaz SMTP) para enviar correo transaccional y masivo, junto con la infraestructura de envío subyacente — gestión de reputación de IP, manejo de rebotes y quejas, y entrega a través de los servidores de correo de AWS. No viene con un editor de plantillas visual, un panel de análisis integrado comparable al de SendGrid, ni soporte de primera clase para un framework de plantillas como la integración de React Email de Resend. Lo que obtienes se parece más a una utilidad bien construida que a un producto: un punto de conexión de API, controles de configuración y métricas de CloudWatch si las conectas tú mismo.

Eso no es una crítica — es precisamente el punto. SES está construido para equipos que ya viven en AWS y quieren el correo como una primitiva de infraestructura más junto a su cómputo y almacenamiento, no como una relación con un proveedor gestionada por separado con su propio panel que revisar.

Por qué SES es más barato

La brecha de costo entre SES y proveedores como Resend o SendGrid no es un descuento ni una promoción — refleja una posición diferente en la pila. Resend y SendGrid compran infraestructura de envío (en algunos casos, de AWS o un proveedor de nube similar) y luego añaden una capa de producto encima: paneles, editores de plantillas, webhooks con cargas útiles amigables, flujos de incorporación y personal de soporte. Sus precios tienen que cubrir esa capa de producto, no solo la mecánica de enviar un correo.

SES se salta esa capa. Le pagas a AWS casi el costo bruto de mover un correo a través de su infraestructura, de la misma manera que Hetzner es más barato que una base de datos gestionada de un hyperscaler porque pagas por cómputo y almacenamiento en lugar de un servicio gestionado envuelto alrededor (ver Hosting en la nube económico para MVP: cuándo Hetzner tiene sentido para la misma lógica de nivel de costo aplicada al hosting). Los ahorros son reales, pero provienen de que AWS no gasta dinero en las partes del producto que hacen que Resend o SendGrid sean agradables de usar — y esa diferencia aparece en el momento en que empiezas a construir sobre SES.

Las compensaciones reales

Una API más cruda y menos barreras de protección

Enviar un correo a través de SES significa llamar directamente al SDK de AWS o a la API REST, manejar tu propia lógica de reintentos y construir toda la visibilidad que quieras sobre el estado de entrega — rebotes, quejas, aperturas — normalmente conectando tú mismo las notificaciones de SNS. Resend y SendGrid te entregan cargas útiles de webhook legibles y un panel listos para usar; con SES, ensamblas eso a partir de primitivas de AWS. Todo está documentado y probado, pero es notablemente más configuración que “instala el SDK, llama a send”.

Más configuración de AWS por adelantado

Antes de enviar un solo correo, necesitas verificar tu dominio de envío en SES con registros DNS (similar a la configuración de SPF/DKIM/DMARC de cualquier proveedor, pero hecha a través de la consola de AWS o la CLI en lugar de un flujo de incorporación guiado), configurar permisos de IAM para el servicio que llame a SES, y decidir si envías a través de la interfaz de API o SMTP. Nada de esto es exótico si tu equipo ya se siente cómodo con AWS — es una tarde adicional de configuración, no un proyecto de investigación. Si tu equipo nunca ha tocado AWS antes, es una primera subida más empinada que registrarse en Resend y pegar una clave de API.

El sandbox y el proceso de aprobación de límites de envío

Esta es la compensación con más probabilidad de sorprender a un equipo que avanza rápido. Las cuentas nuevas de SES comienzan en un sandbox: solo puedes enviar a direcciones de correo verificadas, y el volumen de envío diario tiene un tope bajo. Para enviar a usuarios reales no verificados en producción, tienes que presentar una solicitud a AWS que describa tu caso de uso, el volumen esperado y cómo manejas los rebotes y las quejas — y AWS la revisa antes de conceder el acceso de producción. Esto no es instantáneo, y históricamente ha sido más estricto que “regístrate y adelante”, lo cual importa si estás tratando de lanzar un correo de confirmación de registro esta semana en lugar de la próxima. Resend y SendGrid no tienen una barrera de aprobación equivalente para empezar.

Amazon SES frente a proveedores estilo Resend/SendGrid

Factor	Amazon SES	Resend / SendGrid
Costo a escala	El más bajo — precios de infraestructura cruda de AWS	Más alto — incluye la capa de producto/soporte en el precio
Esfuerzo de configuración	Mayor — configuración de consola de AWS/IAM/DNS, conexión manual de webhooks	Menor — clave de API, verificación de dominio guiada, paneles listos
Experiencia de desarrollador	API/SMTP crudas, construyes tú mismo el monitoreo y las plantillas	SDK pulidos, análisis integrados, herramientas de plantillas (p. ej. React Email en Resend)
Para empezar	Límites de sandbox + proceso de revisión de AWS para envío en producción	Sin barrera de aprobación comparable — envío rápido a direcciones reales
Ideal para	Equipos ya en AWS, envío de alto volumen, sensibles al costo a escala	Equipos que quieren configuración rápida y menos mantenimiento, volumen bajo/moderado

Cuándo valen la pena los ahorros de costo

SES suele tener sentido cuando se cumple al menos una de estas condiciones: tu equipo ya opera infraestructura significativa en AWS y añadir un servicio más tiene realmente poca fricción; tu volumen de correo esperado es lo suficientemente alto como para que la diferencia de costo por correo se sume a una línea de presupuesto real, no un redondeo; o tienes el tiempo de ingeniería para construir el monitoreo, los reintentos y el manejo de plantillas que un proveedor pulido te da gratis. En esos casos, el costo continuo más bajo se acumula cada mes que operas el producto, y el costo de configuración único deja de importar una vez que está hecho.

Cuándo un proveedor pulido ahorra más de lo que cuesta

Para la mayoría de los MVP en sus primeros meses, el cálculo funciona al revés. Si tu equipo nunca ha trabajado en AWS, el tiempo de configuración — más la espera por la aprobación del límite de envío de SES — es tiempo que no se dedica a construir el producto en sí. Si tu volumen de correo aún es bajo, los ahorros absolutos en dólares al elegir SES son pequeños en un primer año, mientras que las horas de ingeniería para construir un monitoreo y plantillas equivalentes no lo son. En esa situación, la comparación directa de Resend o SendGrid es la lectura más útil: ambos cambian un costo por correo más alto por notablemente menos configuración y mantenimiento, lo cual suele ser la compensación correcta para un equipo cuyo recurso escaso es el tiempo de ingeniería, no el presupuesto de infraestructura.

Tomar la decisión

Amazon SES no es un truco oculto ni una trampa — es la misma decisión de “infraestructura cruda versus producto gestionado” que los equipos de MVP ya toman para el hosting, aplicada al correo. La ventaja de costo es genuina y crece con el volumen, pero se paga con tiempo de configuración, una API más cruda y un proceso de aprobación que puede añadir tiempo de espera antes de que envíes correo de producción real. Si tu equipo es nativo de AWS o ya está escalando más allá del punto en que el costo por correo importa, esa compensación vale la pena. Si todavía estás validando el producto y quieres que el correo transaccional funcione esta semana sin tener que vigilar la configuración de AWS, un proveedor como Resend o SendGrid te llevará allí más rápido — y siempre puedes migrar a SES más adelante una vez que el volumen justifique el cambio, de manera muy similar a como los equipos migran cargas de trabajo específicas de un host económico a un hyperscaler una vez que el cálculo cambia.

Preguntas Frecuentes

¿Es Amazon SES más barato que Resend o SendGrid?

Con un volumen de envío significativo, sí — SES suele ser la opción más económica porque tiene el precio de infraestructura cruda de AWS en lugar de un producto pulido con soporte, paneles y plantillas incluidos en el precio. Revisa la página de precios actual de cada proveedor frente a tu volumen esperado en lugar de confiar en una cifra recordada, ya que los niveles cambian.

¿Es difícil configurar Amazon SES?

Es más laborioso que Resend o SendGrid. Configuras el envío mediante la consola de AWS o la CLI, verificas tu dominio de envío con registros DNS y — para uso en producción fuera del sandbox — solicitas un aumento del límite de envío que AWS revisa antes de aprobarlo. No es tanto difícil como manual, con menos barreras de protección que una API de correo dedicada.

¿Qué es el sandbox de SES y cómo afecta a un MVP nuevo?

Las cuentas nuevas de SES comienzan en un sandbox que restringe el envío solo a direcciones de correo verificadas, con límites de envío diarios bajos. Pasar al acceso de producción requiere enviar una solicitud a AWS describiendo tu caso de uso, que ellos revisan antes de levantar la restricción — planifica este tiempo de espera antes de esperar enviar correos a usuarios reales.

¿Debería un MVP en etapa temprana usar Amazon SES en lugar de Resend o SendGrid?

Solo si hay más tiempo de ingeniería disponible que presupuesto, o si ya estás profundamente inmerso en la infraestructura de AWS. Si quieres lanzar correo transaccional rápidamente con una configuración mínima y no te importa pagar más por correo, Resend o SendGrid te llevarán allí más rápido. Si estás optimizando para el costo más bajo posible a escala y estás dispuesto a construir más por tu cuenta, SES vale la configuración adicional.

¿Puedo cambiar de Amazon SES a Resend o SendGrid más adelante, o al revés?

Sí. Rediriges el código de envío de correo de tu aplicación hacia una nueva API y repites la autenticación de dominio (SPF, DKIM, DMARC) para el nuevo proveedor — trabajo real, pero no una reconstrucción. Muchos equipos comienzan con un proveedor pulido por velocidad y pasan a SES más adelante una vez que el volumen justifica el cambio, o hacen lo contrario si la sobrecarga de configuración de SES supera los ahorros.