AWS descontinuará WorkMail y pondrá App Runner en modo mantenimiento: ¿qué hacer?

Introducción

En abril de 2026, AWS anunció un conjunto de cambios en su portafolio de servicios que impactan directamente a equipos de infraestructura, DevOps y desarrolladores. Dos decisiones resaltan por su alcance: la discontinuación de Amazon WorkMail —el servicio de correo empresarial alojado— y la transición de AWS App Runner a modo mantenimiento, prohibiendo la incorporación de nuevos clientes. Estas movidas no son aisladas: junto a ellas, RDS Custom para Oracle, WorkSpaces Thin Client y múltiples funcionalidades en Comprehend, Rekognition y Application Recovery Controller pasan a mantenimiento o fase de sunset.

El anuncio, publicado en el blog oficial de AWS, detalla que App Runner entrará en mantenimiento el 30 de abril de 2026, mientras que WorkMail será discontinuado en marzo de 2027. La fecha de corte para WorkMail incluye un período de gracia de 11 meses, tiempo suficiente para planificar migraciones pero insuficiente para dejarlo para último momento. Lo llamativo es la cantidad de servicios afectados en un solo comunicado: 14 servicios y funcionalidades pasarán a mantenimiento o serán descontinuados, según lo señalado por Corey Quinn, chief cloud economist en The Duckbill Group.

Qué ocurrió

El anuncio oficial de AWS, publicado el 26 de abril de 2026, incluye los siguientes cambios clave:

1. Servicios en mantenimiento (no aceptan nuevos clientes, pero siguen operativos para clientes existentes):

– AWS Audit Manager: herramienta de auditoría automatizada.

– CloudTrail Lake: almacenamiento de logs centralizado.

– AWS IoT FleetWise: gestión de flotas IoT.

– Glue Ray Jobs: integración de Apache Spark en AWS Glue.

– Amazon Comprehend: funcionalidades específicas en detección de entidades y análisis de texto.

– Amazon Rekognition: módulos de moderación de contenido y análisis de imágenes.

– Amazon SNS: ciertas APIs para envío de notificaciones.

– Application Recovery Controller: gestión de recuperación de aplicaciones.

1. Servicios en fase de sunset (descontinuación definitiva):

– RDS Custom para Oracle: versión personalizada de RDS para Oracle Database.

– WorkSpaces Thin Client: dispositivo físico para escritorios virtuales, lanzado en 2023 y discontinuado tras menos de tres años.

– Service Management Connector: integración con herramientas de ITSM.

El comunicado oficial no especifica razones técnicas profundas, pero el contexto sugiere un ajuste en el lifecycle management de AWS, priorizando servicios con mayor adopción y rentabilidad. Sin embargo, la decisión ha generado debate en la comunidad, especialmente por dos factores:

• La filtración previa del fin de App Runner en enero de 2026, que AWS revirtió temporalmente, generando confusión.
• La reactivación de CodeCommit en 2025, tras su anuncio de discontinuación en 2022, lo que alimentó dudas sobre la consistencia en la estrategia de AWS.

Impacto para DevOps, Infraestructura, Cloud y Seguridad

Para equipos de DevOps y desarrollo

• AWS ECS Express Mode: la recomendación oficial de AWS, aunque con mayor complejidad operativa.
• AWS Lambda con contenedores: si la aplicación es compatible con runtimes basados en contenedores.
• Google Cloud Run: opción preferida por usuarios en foros como Reddit, por su simplicidad y escalabilidad instantánea. Un usuario reportó que migrar un servicio desde App Runner a Cloud Run requirió solo ajustes en políticas IAM y variables de entorno, con un tiempo total de 4 horas.

• Evaluar alternativas SaaS: Microsoft 365, Google Workspace, Zoho Mail.
• Migrar datos: AWS ofrece herramientas como AWS SES para el envío de correos y S3 + Lambda para almacenar mensajes históricos.
• Reconfigurar autenticación: integrar proveedores de identidad externos (Okta, Auth0) con los nuevos servicios de correo.

Para equipos de infraestructura y cloud

La discontinuación de RDS Custom para Oracle impacta a usuarios que requieren configuraciones personalizadas en instancias de Oracle Database. Este servicio permitía modificar parámetros del motor de base de datos, algo no posible en RDS estándar. La migración implica:

• Evaluar opciones:

– Auto-scaling con EC2: para entornos que requieren ajustes manuales.

– Soluciones híbridas: Oracle Database en EC2 + RDS para otros motores.

• Planificar downtime: la migración de datos puede tardar horas o días, dependiendo del volumen.

• Reemplazarlo por soluciones software: Amazon WorkSpaces en modo cloud.
• Gestionar devoluciones: AWS ofrece reembolsos por dispositivos no usados, según lo informado por Corey Quinn.

Para equipos de seguridad

• Falta de nuevas capacidades: AWS no agregará features como integración con IA para detección de anomalías.
• Riesgo de obsolescencia: en 2 a 3 años, podrían ser discontinuados sin aviso previo.

• Evaluar alternativas open source: como Hugging Face para NLP o OpenCV para visión por computadora.
• Migrar a servicios gestionados: Azure Cognitive Services o Google Vertex AI, según el caso de uso.

Detalles técnicos

Cronograma y dependencias

1. AWS App Runner → Alternativas

App Runner era un servicio serverless que compilaba imágenes de Docker y las desplegaba automáticamente. Las alternativas recomendadas por AWS son:

• ECS Express Mode: usa Fargate con escalado automático, pero requiere definir tareas en formato task definition.
• Lambda con contenedores: ideal para APIs REST con bajo consumo de CPU/memoria.
• Google Cloud Run: opción preferida por la comunidad por su simplicidad. Ejemplo de migración:

# cloudbuild.yaml para Cloud Run (alternativa a App Runner)
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA']
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    args: ['gcloud', 'run', 'deploy', 'my-app',
           '--image', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA',
           '--platform', 'managed',
           '--region', 'us-central1']

2. Amazon WorkMail → Alternativas

WorkMail usaba protocolos como IMAP/SMTP y se integraba con AWS Organizations. La migración a Microsoft 365 requiere:

• Migración de buzones: usando herramientas como Microsoft Migration Manager (para hasta 10,000 buzones) o AWS SES + S3 para archivos históricos.
• Reconfiguración de DNS: actualizar registros MX y SPF para evitar bloqueos de correo.
• Autenticación: integrar Azure AD con Microsoft 365 usando AWS IAM Identity Center.

3. RDS Custom para Oracle → Alternativas

Este servicio permitía modificar parámetros del motor de Oracle Database (como pga_aggregate_target). Las opciones son:

• Oracle RDS estándar: si no se necesitan personalizaciones.
• Oracle en EC2 con ASM: para entornos que requieren ajustes manuales. Ejemplo de despliegue:

# Despliegue de Oracle en EC2 con Ansible
- name: Configurar Oracle en EC2
  hosts: oracle_servers
  tasks:
    - name: Instalar dependencias
      yum:
        name: ['oracle-database-xe-19c', 'unzip']
        state: present
    - name: Configurar parámetros personalizados
      lineinfile:
        path: /etc/sysctl.conf
        regexp: '^#?kernel.shmall'
        line: 'kernel.shmall = 2097152'

Qué deberían hacer los administradores y equipos técnicos

Pasos inmediatos (antes del 30/04/2026)

1. Identificar dependencias:

     aws resource-explorer-2 search \
       --query-string "type:workmail" \
       --max-results 100
     

– Para App Runner, usar:

     aws apprunner list-services
     

1. Evaluar alternativas:

– Para WorkMail: configurar un entorno piloto con Microsoft 365 o Google Workspace.

1. Planificar migración:

– Backups de datos (para WorkMail: exportar buzones a formato .pst).

– Pruebas de integración con APIs externas (ej: Slack, Jira).

– Plan de rollback en caso de fallos.

Pasos para migrar App Runner a ECS Express Mode

1. Crear un clúster ECS:

   aws ecs create-cluster \
     --cluster-name my-app-cluster \
     --capacity-providers FARGATE \
     --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1
   

1. Definir una tarea en formato task definition:

   # task-definition.json
   {
     "family": "my-app-task",
     "networkMode": "awsvpc",
     "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
     "containerDefinitions": [{
       "name": "my-app",
       "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest",
       "portMappings": [{"containerPort": 8080, "hostPort": 8080}],
       "essential": true
     }],
     "requiresCompatibilities": ["FARGATE"],
     "cpu": "256",
     "memory": "512"
   }
   

1. Desplegar el servicio:

   aws ecs create-service \
     --cluster my-app-cluster \
     --service-name my-app-service \
     --task-definition my-app-task:1 \
     --desired-count 1 \
     --launch-type FARGATE \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-123],securityGroups=[sg-123]}"
   

Pasos para migrar WorkMail a Microsoft 365

1. Exportar buzones a formato .pst:

   # Usar New-MailboxExportRequest en Exchange Online
   New-MailboxExportRequest -Mailbox [email protected] -FilePath "\\server\carpeta\usuario.pst"
   

1. Configurar DNS:

– Configurar SPF: v=spf1 include:spf.protection.outlook.com ~all.

1. Migrar contactos y calendarios:

Conclusión

Los anuncios de AWS sobre WorkMail y App Runner reflejan un cambio estratégico hacia servicios más escalables y rentables, pero obligan a equipos técnicos a actuar con urgencia. La clave está en:

1. Priorizar servicios críticos: WorkMail y App Runner son los de mayor impacto; RDS Custom para Oracle requiere planificación a mediano plazo.
2. Evaluar alternativas con pruebas de concepto: Cloud Run y ECS Express Mode son las opciones más viables para App Runner; Microsoft 365 y Google Workspace para WorkMail.
3. Automatizar migraciones: usar herramientas como AWS CLI, Terraform o Ansible para reducir errores humanos.
4. Monitorear cambios futuros: AWS ha revivido servicios como CodeCommit, pero no hay garantías. Mantener un inventario actualizado de dependencias es esencial.

Estos cambios subrayan la necesidad de flexibilidad en cloud: ningún proveedor garantiza la permanencia de sus servicios. Equipos de DevOps deben diseñar arquitecturas agnósticas de proveedor y documentar runbooks de migración antes de que los servicios sean discontinuados. La resiliencia no es solo técnica, sino también operativa.