Tienes una API REST con Spring Boot que funciona en tu máquina y quieres subirla a AWS. Hay muchas formas de hacerlo, y la factura cambia bastante según cuál elijas: desde un par de dólares al mes hasta más de 60 USD para la misma API.
En esta guía comparo las cuatro opciones más comunes para una API Java (EC2, Elastic Beanstalk, ECS con Fargate y Lambda). Para cada una verás qué cobra AWS, un cálculo de ejemplo y cuándo conviene.
Antes de empezar: los precios de AWS cambian y dependen de la región. Las cifras son aproximadas para us-east-1 (Norte de Virginia) al momento de escribir, con 730 horas por mes. Antes de decidir, comprueba tu caso en la AWS Pricing Calculator. Si preparas el AWS Cloud Practitioner, este cálculo es buen ejercicio para la parte de facturación: lo explico en la guía para aprobarlo.
El escenario de ejemplo
Para que la comparación sea justa, todas las opciones despliegan la misma API:
- Spring Boot 3 con Java 21, empaquetada como un
.jar. - Tráfico bajo o moderado: hasta 1 millón de peticiones al mes, con una respuesta media de 200 ms.
- Un solo entorno (producción), sin contar la base de datos. La base de datos va aparte, más abajo.
Spring Boot necesita memoria: una API típica usa entre 300 y 600 MB de RAM. Por eso no conviene una instancia con 512 MB: con 1 GB funciona justa, y lo cómodo es 2 GB.
Opción 1: EC2
Una máquina virtual donde instalas Java y ejecutas el .jar (con systemd o en un contenedor Docker).
| Concepto | Precio | Al mes |
|---|---|---|
Instancia t4g.small (2 vCPU ARM, 2 GB) | ~0,0168 USD/hora | ~12,30 USD |
| Disco EBS gp3 de 20 GB | ~0,08 USD por GB | ~1,60 USD |
| IPv4 pública | ~0,005 USD/hora | ~3,65 USD |
| Total | ~17,50 USD |
Las instancias t4g usan procesadores Graviton (ARM) y cuestan alrededor de un 20 % menos que sus equivalentes x86 (t3). Java corre igual en ARM: solo necesitas un JDK para ARM, como las imágenes de Eclipse Temurin, que son multiarquitectura.
A favor: es lo más barato con una máquina siempre encendida, y tienes control total. En contra: tú actualizas el sistema operativo, configuras HTTPS, reinicias si se cae y escalas a mano.
Opción 2: Elastic Beanstalk
Subes el .jar y Beanstalk crea la infraestructura: instancias EC2, el entorno de Java, los logs y, si lo pides, el balanceador y el escalado automático. Beanstalk no cobra nada por sí mismo: pagas los recursos que crea.
| Tipo de entorno | Qué crea | Al mes |
|---|---|---|
| Instancia única | 1 EC2 t4g.small + disco + IP pública | ~17,50 USD |
| Con balanceador | 2 EC2 + Application Load Balancer + IPs públicas | ~55–60 USD |
El balanceador de aplicaciones (ALB) cuesta unos 16,50 USD al mes solo por existir, más su uso (LCU) y sus IPs públicas. Es el salto de precio más grande de esta comparación.
A favor: despliegas con eb deploy o desde el pipeline, sin pensar en la infraestructura. Las actualizaciones de la plataforma son administradas.
En contra: personalizar fuera de lo previsto (redes, proxies, agentes) se vuelve incómodo.
Opción 3: ECS con Fargate
Empaquetas la API en una imagen de Docker y ECS la ejecuta en Fargate, sin servidores que administrar. Pagas por la CPU y la memoria que reservas mientras el contenedor está encendido.
Una imagen mínima para Spring Boot:
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY target/api.jar api.jar
# La JVM usa como máximo el 75 % de la memoria del contenedor
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75"
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "api.jar"]
| Concepto | Precio (ARM) | Al mes |
|---|---|---|
| Tarea con 0,5 vCPU y 1 GB | ~0,0198 USD/hora | ~14,40 USD |
| Application Load Balancer (más uso y sus IPs) | ~25 USD | |
| IPv4 pública de la tarea | ~3,65 USD | |
| Total con 1 tarea | ~40–45 USD | |
| Total con 2 tareas (alta disponibilidad) | ~55–65 USD |
En x86 la tarea cuesta unos 18 USD al mes, un 20 % más. Sin balanceador, con una IP pública en la tarea, el total baja a unos 18 USD. Esa variante sirve para pruebas, pero la IP cambia en cada despliegue.
A favor: despliegues reproducibles con imágenes, escalado automático y nada de sistemas operativos que parchear. Es el estándar para microservicios. En contra: hay más piezas que entender (clúster, servicio, tarea, ECR) y el balanceador encarece los proyectos pequeños.
Opción 4: Lambda con API Gateway
La API se ejecuta solo cuando llega una petición. Con Spring Boot se usa la librería aws-serverless-java-container, que adapta las peticiones de API Gateway a tus controladores sin reescribirlos.
| Concepto | Precio | Al mes (1 millón de peticiones) |
|---|---|---|
| Peticiones de Lambda | 0,20 USD por millón | 0,20 USD |
| Cómputo (1 GB × 200 ms) | ~0,0000167 USD por GB-segundo | ~3,33 USD |
| API Gateway (HTTP API) | ~1 USD por millón | ~1 USD |
| Total | ~4,50 USD |
La capa gratuita permanente de Lambda incluye 1 millón de peticiones y 400 000 GB-segundos al mes. En este escenario, eso deja el total en alrededor de 1 USD, lo que cobra API Gateway.
El problema clásico de Java en Lambda es el arranque en frío: levantar Spring tarda varios segundos. Hay dos formas de mitigarlo:
- Lambda SnapStart: guarda una instantánea de la función ya inicializada y la restaura en milisegundos. Para Java no tiene costo adicional.
- Compilar a imagen nativa con GraalVM (Spring Boot 3 lo soporta): arranca mucho más rápido y usa menos memoria, a cambio de una compilación más lenta.
A favor: costo casi cero con poco tráfico y escala sola. En contra: el arranque en frío, el límite de 15 minutos por ejecución y que no encaja con conexiones largas (WebSockets) ni con pools de conexiones grandes a la base de datos.
La comparación
| Opción | Al mes (aprox.) | Administración | Escala sola | Ideal para |
|---|---|---|---|---|
EC2 t4g.small | ~17,50 USD | Alta | No | Aprender, proyectos personales, control total |
| Beanstalk, instancia única | ~17,50 USD | Baja | No | MVP sin tiempo para infraestructura |
| Beanstalk con balanceador | ~55–60 USD | Baja | Sí | Apps tradicionales en producción |
| Fargate + balanceador | ~40–65 USD | Media | Sí | Microservicios y equipos que ya usan Docker |
| Lambda + API Gateway | ~1–5 USD | Muy baja | Sí | Tráfico bajo o con picos, APIs pequeñas |
Calcula tu caso
Pon tu tráfico, el tamaño de la instancia o de la tarea y si usas balanceador o NAT Gateway: la calculadora compara las cuatro opciones con tus números. También está como página aparte en la calculadora de costos de AWS.
Más barata con estos supuestos: Lambda + API Gateway
Precios aproximados de us-east-1 (Norte de Virginia), consultados en octubre de 2026, sin impuestos ni descuentos. Pueden cambiar: confirma tu caso en la AWS Pricing Calculator.
Los costos que nadie mira hasta que llega la factura
- IPs públicas IPv4. Desde 2024 AWS cobra cada IPv4 pública, unos 3,65 USD al mes por IP. Se cobran también las del balanceador y las de las tareas.
- NAT Gateway. Si pones las instancias o tareas en subredes privadas, necesitan un NAT Gateway para salir a internet. Cuesta unos 33 USD al mes más el tráfico. Es la sorpresa más común en proyectos pequeños. Alternativas: subredes públicas con grupos de seguridad estrictos o VPC endpoints para los servicios de AWS.
- CloudWatch Logs. Unos 0,50 USD por GB ingerido. Un log en nivel
DEBUGen producción lo multiplica. - Transferencia de datos. Los primeros 100 GB de salida a internet al mes son gratis; después, unos 0,09 USD por GB.
- La base de datos. Suele costar más que la propia API (ver la siguiente sección).
Y la base de datos
Casi toda API Spring Boot necesita una. Las opciones más comunes:
| Opción | Al mes (aprox.) | Notas |
|---|---|---|
RDS PostgreSQL db.t4g.micro + 20 GB | ~14 USD | Copias de seguridad y parches administrados |
| PostgreSQL en la misma EC2 | 0 USD extra | Barato, pero tú haces las copias de seguridad y lo mantienes |
| DynamoDB bajo demanda | Céntimos con poco tráfico | Exige modelar los datos de otra forma (NoSQL) |
| MongoDB Atlas (nivel gratuito) | 0 USD | Útil para probar; el nivel de producción se paga aparte |
Para producción, una base de datos administrada (RDS) vale lo que cuesta: las copias de seguridad automáticas y la restauración a un punto en el tiempo te salvan el día que algo sale mal.
Cuál elegir
- Estás aprendiendo o es un proyecto personal: EC2
t4g.small, o Lambda si el tráfico es esporádico. Aprenderás más con EC2. - Es un MVP y quieres desplegar ya: Elastic Beanstalk con instancia única. Cuando crezca, cambias a un entorno con balanceador sin tocar el código.
- Son varios microservicios o tu equipo ya usa Docker: ECS con Fargate. Un solo balanceador puede repartir el tráfico entre varios servicios por ruta, así que su costo se reparte.
- Tráfico bajo, irregular o con picos: Lambda con SnapStart.
Cómo no llevarte sorpresas
- Crea una alerta en AWS Budgets el primer día, por ejemplo a los 10 USD. Es gratis y te avisa por correo.
- Estima antes de desplegar con la AWS Pricing Calculator, con tus números de tráfico.
- Etiqueta los recursos (
proyecto=mi-api) para ver en Cost Explorer cuánto cuesta cada proyecto. - Apaga lo que no uses: un entorno de pruebas encendido todo el mes cuesta lo mismo que el de producción.
Preguntas frecuentes
¿Puedo tener todo esto gratis con la capa gratuita?
En parte. La capa gratuita permanente cubre Lambda en el escenario de ejemplo. Para EC2, RDS y otros servicios, las condiciones dependen de cuándo creaste la cuenta: las cuentas nuevas reciben créditos durante los primeros meses en lugar de horas gratuitas. Revisa las condiciones vigentes en la página de la capa gratuita de AWS.
¿Me sale más barato un VPS fuera de AWS?
Para una sola API pequeña, muchas veces sí: un VPS de otro proveedor puede costar menos que una EC2 con su IP. AWS compensa cuando necesitas sus servicios administrados (bases de datos, colas, autenticación), escalado automático o cumplir requisitos de tu empresa.
¿Y App Runner o EKS?
EKS (Kubernetes) cobra unos 73 USD al mes solo por el plano de control, antes de cualquier nodo. No tiene sentido para una API sola. App Runner simplifica el despliegue de contenedores, pero revisa su disponibilidad y precio actuales antes de elegirlo para un proyecto nuevo.
¿Graviton es compatible con mi API?
Casi siempre. Java es multiplataforma: el mismo .jar corre en ARM. Solo revisa las dependencias con código nativo (algunos drivers o librerías de compresión) y usa una imagen base de Docker que tenga versión para ARM.