Migra desde Amazon SES a deliverability gestionada sin perder la disciplina de costos que te llevó a AWS en primer lugar

Sí, SES es más barato en cada tramo de volumen sobre la base de bytes. A 100K mensajes mensuales, SES base son $10 frente a nuestros €399; a 1M ronda los $107 frente a €859; a 10M con IPs gestionadas y VDM cae en el rango $400-800 frente a nuestro piso de €2.799. No estamos a 2-3x de SES en costo bruto en ningún tramo por debajo del muy alto volumen, y nunca lo estaremos — la infraestructura pay-as-you-go a escala hyperscaler gana ese argumento.

Lo que cambia el panorama es qué incluye el bundle. SES no incluye warmup gestionado, triage de tasa de quejas, remediación de blocklists, revisión del operador del Compliance Status en Postmaster Tools ni reporte semanal de deliverability. Para tener todo eso al mismo nivel sobre SES, o lo construyes interno (un ingeniero senior de deliverability a €70-110K más herramientas y tiempo) o emparejas SES con una consultoría de deliverability (retainers típicos €1.500-4.000/mes). Una vez sumas eso a la línea SES, la comparativa se ajusta bastante, y en volúmenes sub-10M habitualmente se voltea. Trabajamos el cálculo con prospectos abiertamente — hay formas reales de programa de email donde SES gana en costo total, y lo decimos en las llamadas.

El European Sovereign Cloud entró en GA el 15 de enero de 2026 en Brandeburgo con alrededor de 70-90 servicios incluidos. SES no estaba en esa lista. AWS puede añadirlo al roadmap del ESC en algún momento — no han anunciado fecha — pero a mayo de 2026 todo email de SES sigue ruteando por las regiones AWS estándar, lo que significa que el CLOUD Act aplica a los datos de tus clientes independientemente de si tienes la cuenta en eu-west-1 (Irlanda) o eu-central-1 (Fráncfort). Para la mayoría de equipos esto no es ruptura. Para equipos en sectores regulados (servicios financieros, salud, sector público) o cuyo DPO ya marcó el tema post-Schrems II, lo está siendo.

El problema subyacente es estructural, no técnico. Múltiples análisis independientes durante 2025-2026 han argumentado que incluso el ESC mismo permanece expuesto a compelación CLOUD Act porque la propiedad controladora sigue siendo estadounidense — la filial francesa de Microsoft admitió exactamente eso bajo juramento en el Senado francés en junio de 2025. Para equipos cuyo relato de soberanía debe sobrevivir a una auditoría de procurement (la AEPD ha endurecido criterio sobre cláusulas tipo durante 2024-2025, y reguladores LATAM como la ANPD brasileña y el INAI mexicano siguen línea similar), somos respuesta limpia porque estamos incorporados en UE (Suecia) sin matriz estadounidense.

La reputación de dominio se transfiere. La reputación de IP no. Tu reputación de remitente en Gmail, Yahoo y Microsoft está atada a la combinación de IP de envío y dominio From: — cuando tu tráfico empieza a fluir por nuestras IPs pero con el mismo dominio From:, los receivers ven "este dominio tiene historial de engagement, pero la IP es nueva". Esa es exactamente la señal de warmup que Postmaster Tools v2 espera, y la curva de 14 días que corremos está calibrada para eso.

Lo que no se transfiere es la reputación que hayas construido en IPs dedicadas de SES. Si estabas en IPs dedicadas de SES y decides traerlas vía BYOIP a nuestra infraestructura, es técnicamente posible pero rara vez la respuesta correcta (el mínimo de 256 IPs de BYOIP hace la cuenta difícil, y la reputación de IP dedicada no se mueve limpia entre proveedores de todos modos). La mayoría de equipos acepta el warmup de 14 días y termina con mejor colocación que la que tenían en SES dedicado, mayormente porque las IPs nuevas se calientan contra tráfico engaged-first en vez de historial mixto de pool.

Los clientes SES típicamente usan topics SNS para hacer fan-out de eventos de rebote, queja y entrega a funciones Lambda, colas SQS o aplicaciones downstream. Nuestro modelo de webhook reemplaza SNS con POSTs HTTPS directos al endpoint que elijas, con retry y backoff exponencial gestionados de nuestro lado. El formato de payload es cercano pero no idéntico a la estructura SNS de SES — publicamos el mapeo de esquema durante la semana 1 de migración para que tus funciones Lambda se actualicen junto a la fase de ejecución paralela.

Para equipos que quieren mantener el flujo de eventos basado en SNS incluso post-migración (algunos tienen consumidores downstream acoplados a ese patrón), el workaround es apuntar nuestros webhooks a un endpoint de API Gateway que hace fan-out a SNS internamente. Funciona pero añade latencia y una línea extra de costo. La mayoría de equipos usa la migración como oportunidad para simplificar yendo directo a webhook.

Mail Manager es uno de los features de SES que es genuinamente fuerte, y no vamos a fingir que nuestro parsing de entrada lo iguala. Ingress endpoints, motor de reglas, archive add-ons y escaneo antivirus vía Trend Micro son un stack más profundo del que enviamos nosotros. Si inbound es core a tu aplicación, tres caminos funcionan: dejar SES solo para inbound (no tiene mínimo mensual, así que el coste residual queda pequeño), emparejarnos con un servicio dedicado de inbound (CloudMailin y Postmark Inbound funcionan limpios junto a nuestro outbound), o construir directo sobre Postfix en la capa de aplicación.

Típicamente recomendamos la opción uno los primeros 6-12 meses post-migración. El tráfico de salida se mueve a nosotros, el de entrada sigue corriendo en SES mientras el equipo observa el desempeño outbound. Tras estado estable, el equipo decide si mantener el split o consolidar. No hay razón operativa para forzar la migración de inbound en el mismo cronograma del outbound.

No, si el pegamento específico de SES se desmonta con cuidado. La mayoría de equipos que corrió SES también corre S3, Lambda, RDS u otros servicios AWS desde políticas IAM que pueden o no incluir permisos a SES. Hemos visto migraciones donde un ingeniero junior "limpió la política IAM de SES" borrando de más y rompió un servicio sin relación por dos días. Nuestra fase 5-8 de limpieza es específicamente para evitar ese patrón.

La migración misma solo toca la integración de email a nivel de aplicación, los registros DNS y los configuration sets de SES en AWS. Nada en S3, EC2, RDS, Lambda o VPC cambia. La cuenta AWS sigue abierta, el servicio SES sigue habilitado (no cuesta nada dejarlo habilitado con tráfico cero) y la migración es plenamente reversible hasta el punto en que borras configuration sets y revocas API keys. La mayoría de equipos toma 60-90 días tras el corte completo antes de hacer la limpieza, lo cual es conservador a propósito.

Mes a mes en planes estándar con preaviso de 30 días para cancelar. Los contratos anuales reciben descuento del 10-15% para equipos que quieren certeza de precio, pero el anual es siempre opcional y nunca lo lideramos. La elasticidad sin contrato pay-as-you-go de SES es algo que no podemos replicar del todo — tenemos un tramo mensual — pero la diferencia práctica es pequeña para cualquier equipo con volumen estable.

Durante el proyecto mismo de migración, los primeros 60 días están estructurados para que puedas regresar a SES en cualquier momento. No bloqueamos a nadie durante el periodo de validación. Si la nueva infraestructura no cumple tus estándares, el feature flag a nivel de aplicación te devuelve a SES en minutos y solo nos debes el costo mes a mes pro-rateado.