Java sobre AWS: qué servicio elegir y cuándo compensa
ECS, EKS o Lambda; RDS o DynamoDB; SQS o MSK. Las decisiones de servicio determinan el coste operativo de los próximos años más que el propio código.
ECS, EKS o Lambda
La elección depende de cuánta plataforma se quiera operar y de qué perfil de tráfico tenga el servicio.
Para la mayoría de plataformas Java empresariales, ECS con Fargate es el punto de equilibrio: contenedores sin gestionar servidores ni un plano de control de Kubernetes, con integración directa en el balanceador, los roles de IAM y CloudWatch.
EKS compensa cuando ya existe experiencia en Kubernetes, cuando hay cargas que exigen sus primitivas o cuando la portabilidad entre proveedores es un requisito explícito. Lambda encaja en cargas event-driven, esporádicas o con picos muy marcados, siempre que el arranque en frío sea aceptable o se mitigue con compilación nativa.
Relacional por defecto, DynamoDB por excepción
Para la inmensa mayoría de aplicaciones Java empresariales, Amazon RDS o Aurora con PostgreSQL es la opción correcta: modelo relacional, transacciones, consultas flexibles y compatibilidad con JPA sin adaptaciones.
DynamoDB solo compensa cuando los patrones de acceso son conocidos, estables y muy acotados, y se necesita latencia constante a gran escala. Su modelo de datos obliga a diseñar las tablas a partir de las consultas, y cualquier consulta no prevista requiere un índice adicional o una reestructuración.
El error caro es elegir DynamoDB por su escalabilidad en un sistema con consultas variadas y relaciones entre entidades. Se termina replicando datos en varios índices y manteniendo consistencia a mano, es decir, reimplementando lo que una base de datos relacional ya ofrece.
Cada servicio resuelve un problema distinto
La elección debe partir de la semántica que necesita el sistema, no de cuál es más potente.
SQS
Colas de trabajo con un consumidor por mensaje. Es la opción por defecto para desacoplar procesamiento y absorber picos.
SNS
Publicación y suscripción para notificar a varios destinatarios a la vez, habitualmente combinado con SQS mediante el patrón fan-out.
MSK
Kafka gestionado. Log de eventos persistente y reproducible, con orden por partición: necesario cuando hace falta releer el histórico.
EventBridge
Enrutado de eventos entre servicios de AWS y aplicaciones, con filtrado por contenido del propio evento.
MSK aporta capacidades que SQS no tiene, pero también un coste operativo mucho mayor: particiones, grupos de consumidores, retención y rebalanceos. Si el sistema no necesita reproducir eventos ni garantizar orden, SQS resuelve el caso con una fracción del esfuerzo.
Dónde se va el presupuesto en una plataforma Java
Ninguna de estas partidas es grande por separado. Sumadas suelen representar una parte considerable de la factura mensual.
El coste se controla dimensionando según medición real en lugar de por estimación, y revisando las partidas que crecen de forma silenciosa.
- Contenedores sobredimensionados porque la JVM se configuró con un heap fijo generoso «por si acaso».
- Retención de logs indefinida en CloudWatch cuando el valor de un log operativo se agota en días.
- Tráfico entre zonas de disponibilidad por servicios que se llaman entre sí sin afinidad de zona.
- Entornos de desarrollo y preproducción funcionando fuera del horario laboral.
- NAT Gateways por los que pasa todo el tráfico de salida sin necesidad, cuando un VPC Endpoint sería suficiente.
Instrumentar con estándares abiertos, exportar al proveedor
Conviene instrumentar con OpenTelemetry y exportar hacia los servicios de AWS, en lugar de instrumentar directamente con los SDK propietarios. Así la instrumentación del código permanece igual aunque cambie el destino de las señales.
El montaje habitual usa el AWS Distro for OpenTelemetry como recolector, X-Ray para las trazas, CloudWatch para métricas y logs, y Micrometer para las métricas de aplicación. Todo ello sin ninguna dependencia de AWS en el código de negocio.
El criterio que aplico en todos los proyectos: la instrumentación se hace con estándares abiertos y el acoplamiento al proveedor queda en la configuración. Migrar de X-Ray a otra herramienta debe ser cambiar el destino del exportador, no reinstrumentar la aplicación. Los detalles están en la guía de observabilidad.
Preguntas frecuentes
Dudas habituales sobre aws java en proyectos empresariales.
¿Cómo se despliega una aplicación Java en AWS?
Se despliega empaquetándola como imagen de contenedor y ejecutándola en ECS con Fargate, en EKS o como función Lambda. Para la mayoría de plataformas Java empresariales, ECS con Fargate es el punto de equilibrio porque ofrece contenedores sin gestionar servidores ni plano de control de Kubernetes. EKS compensa si ya hay experiencia en Kubernetes o si la portabilidad es un requisito, y Lambda encaja en cargas event-driven o con picos muy marcados.
¿Qué base de datos elegir en AWS para una aplicación Java?
Para la mayoría de aplicaciones Java empresariales, Amazon RDS o Aurora con PostgreSQL es la opción correcta: modelo relacional, transacciones, consultas flexibles y compatibilidad directa con JPA. DynamoDB solo compensa cuando los patrones de acceso son conocidos, estables y acotados y se necesita latencia constante a gran escala, ya que obliga a diseñar las tablas a partir de las consultas.
¿Cuándo usar SQS, SNS o MSK en AWS?
SQS es la opción por defecto para colas de trabajo con un consumidor por mensaje. SNS resuelve la publicación y suscripción hacia varios destinatarios, habitualmente combinado con SQS. MSK, que es Kafka gestionado, se necesita cuando hace falta un log de eventos persistente y reproducible con orden por partición. Si el sistema no necesita releer eventos ni garantizar orden, SQS resuelve el caso con mucho menos coste operativo.
¿Cómo se controla el coste de una plataforma Java en AWS?
Dimensionando según medición real y revisando las partidas que crecen en silencio. En plataformas Java las fuentes habituales de sobrecoste son contenedores sobredimensionados por un heap fijo generoso, retención indefinida de logs en CloudWatch, tráfico entre zonas de disponibilidad, entornos de desarrollo encendidos fuera de horario y NAT Gateways evitables mediante VPC Endpoints.
¿Qué observabilidad conviene usar en AWS con Java?
Conviene instrumentar con OpenTelemetry y exportar hacia los servicios de AWS en lugar de usar directamente los SDK propietarios, de modo que la instrumentación del código no cambie aunque cambie el destino. El montaje habitual combina AWS Distro for OpenTelemetry como recolector, X-Ray para trazas, CloudWatch para métricas y logs, y Micrometer para métricas de aplicación.
Recursos relacionados
Páginas pilar, guías y casos reales que amplían lo tratado aquí.
- Java Cloud Principios cloud-native independientes de proveedor.
- Cloud & DevOps Terraform, CI/CD y automatización sobre AWS.
- Java Microservicios Los servicios que se despliegan en esta plataforma.
- Guía de observabilidad OpenTelemetry, X-Ray y CloudWatch en detalle.
- Caso Iberia Plataforma Java sobre Kubernetes y AWS.
- Caso PRADIB Migración de un monolito a microservicios en AWS.
¿Necesitas diseñar o revisar tu arquitectura Java en AWS?
Evalúo la elección de servicios, el coste asociado y la estrategia de despliegue antes de que las decisiones se vuelvan caras de revertir.