Arquitectura AWS para startups: guía de costes y escalabilidad

AWS factura 142.000 millones de dólares anuales y controla el 30% del mercado de infraestructura cloud. Es la plataforma donde nacen la mayoría de startups tecnológicas. Pero elegir AWS es solo el primer paso. La diferencia entre una startup que escala y una que quiebra por costes de infraestructura está en la arquitectura.

Según un estudio de Flexera, las empresas desperdician un 32% de su gasto en cloud. En startups con presupuesto limitado, ese desperdicio puede significar meses de runway perdido.

Este artículo explica las arquitecturas que funcionan en cada etapa de crecimiento, los costes reales que puedes esperar y los errores que convierten AWS en un pozo de dinero.

AWS para startups: el punto de partida

AWS Activate: créditos gratuitos

AWS ofrece el programa Activate para startups, con hasta 100.000 dólares en créditos para empresas respaldadas por aceleradoras o inversores. Incluso sin respaldo, el programa básico ofrece 1.000 dólares en créditos y soporte técnico.

El Free Tier incluye servicios gratuitos durante 12 meses:

• EC2: 750 horas/mes de instancia t2.micro o t3.micro
• RDS: 750 horas/mes de instancia db.t2.micro
• S3: 5 GB de almacenamiento estándar
• Lambda: 1 millón de invocaciones/mes (siempre gratis)
• DynamoDB: 25 GB de almacenamiento + 25 unidades de lectura/escritura (siempre gratis)
• API Gateway: 1 millón de llamadas API/mes durante 12 meses

Trampa habitual: El Free Tier tiene límites. Una instancia t3.micro ejecutándose 24/7 consume exactamente 744 horas/mes: dentro del límite. Pero si lanzas dos instancias por error, pagas la segunda completa. Configura alertas de facturación desde el día 1.

Well-Architected Framework: los 6 pilares

AWS define 6 pilares para arquitecturas bien diseñadas. Para startups, tres son críticos:

1. Eficiencia de costes: Pagar solo por lo que usas. No sobredimensionar.
2. Eficiencia de rendimiento: Elegir el servicio correcto para cada caso de uso.
3. Excelencia operativa: Automatizar todo lo que puedas para reducir carga operativa.

Los otros tres pilares (seguridad, fiabilidad, sostenibilidad) importan, pero en fase early-stage, los costes y la velocidad de iteración determinan la supervivencia.

Arquitecturas por etapa de crecimiento

Etapa 1: Pre-product market fit (0-1.000 usuarios)

Objetivo: Validar la hipótesis de negocio gastando lo mínimo posible.

Arquitectura recomendada: Serverless pura.

API Gateway → Lambda → DynamoDB
     ↓
CloudFront → S3 (frontend estático)

Servicios clave:

Por qué serverless en esta etapa:

• Sin coste fijo: pagas solo por uso real
• Escala automática: de 0 a miles de requests sin configuración
• Sin mantenimiento de servidores: el equipo se enfoca en producto
• Deploy instantáneo: iteración rápida

Coste real: Con menos de 1.000 usuarios activos, una arquitectura serverless bien diseñada cuesta entre 0 y 25 dólares al mes. Muchas startups operan dentro del Free Tier durante meses.

Etapa 2: Crecimiento temprano (1.000-10.000 usuarios)

Objetivo: Escalar sin reescribir la arquitectura.

Arquitectura recomendada: Serverless con servicios gestionados.

CloudFront → S3 (SPA)
     ↓
API Gateway → Lambda → Aurora Serverless v2
     ↓                       ↓
SQS → Lambda (async)   ElastiCache (Redis)

Cambios clave:

• Aurora Serverless v2 reemplaza a DynamoDB si necesitas consultas relacionales complejas. Escala automáticamente de 0,5 a 128 ACUs.
• ElastiCache para cachear consultas frecuentes y reducir latencia.
• SQS + Lambda para procesos asíncronos (emails, notificaciones, procesamiento de datos).

Punto de decisión: Si tu aplicación necesita conexiones WebSocket persistentes, ejecución de procesos largos (más de 15 minutos) o configuración específica del sistema operativo, es momento de evaluar contenedores.

Etapa 3: Escala (10.000-100.000 usuarios)

Objetivo: Rendimiento predecible y costes controlados.

Arquitectura recomendada: Contenedores con servicios gestionados.

CloudFront → ALB → ECS Fargate (microservicios)
                        ↓
              Aurora PostgreSQL + ElastiCache
                        ↓
         SQS → ECS Fargate (workers)
                        ↓
              S3 + EventBridge (eventos)

Por qué contenedores en esta etapa:

• Costes predecibles: A escala, Lambda puede ser más caro que contenedores para cargas constantes. Una Lambda ejecutándose millones de veces al día puede costar más que un contenedor Fargate ejecutándose 24/7.
• Control: Configuración específica de runtime, librerías, y dependencias del sistema.
• Procesos largos: ECS no tiene el límite de 15 minutos de Lambda.

Etapa 4: Escala seria (más de 100.000 usuarios)

Objetivo: Optimizar costes a escala y preparar para alta disponibilidad.

A esta escala, la arquitectura necesita:

• Multi-AZ: Redundancia en múltiples zonas de disponibilidad.
• Reserved Instances o Savings Plans: Ahorro del 30-72% frente a on-demand.
• Auto Scaling Groups: Escala horizontal basada en métricas.
• Kubernetes (EKS): Si necesitas orquestación compleja de microservicios.

El coste típico oscila entre 3.000 y 15.000 dólares al mes, pero con Reserved Instances y optimización activa, muchas startups reducen entre un 40-60% respecto al precio on-demand.

Serverless vs contenedores: cuándo elegir cada uno

Elige serverless cuando…

• Tu tráfico es impredecible o tiene picos pronunciados
• Quieres minimizar el coste operativo (sin servidores que mantener)
• Tus funciones duran menos de 15 minutos
• Estás en fase de validación y necesitas iterar rápido
• Tu equipo es pequeño y no puede dedicar tiempo a infraestructura

Elige contenedores cuando…

• Tu tráfico es constante y predecible
• Necesitas procesos largos o conexiones persistentes
• Necesitas control sobre el runtime y las dependencias
• Tu aplicación tiene requisitos específicos de CPU/memoria
• A escala, el coste de Lambda supera al de contenedores

El punto de cruce

El punto donde contenedores resultan más baratos que Lambda depende del patrón de uso. Como regla general:

• Menos de 1 millón de invocaciones/mes con ejecución corta: Lambda es más barato
• Carga constante 24/7 con millones de invocaciones: Contenedores son más baratos
• Cargas mixtas: Usa ambos. Lambda para APIs con tráfico variable, contenedores para workers constantes

La decisión no es binaria. La mayoría de startups en crecimiento usan una combinación de ambos.

Los 7 errores que disparan los costes en AWS

Error 1: No configurar alertas de facturación

AWS puede generar facturas inesperadas en horas. Un error de configuración en producción puede costarte miles de euros en un fin de semana. Configura AWS Budgets con alertas al 50%, 80% y 100% del presupuesto mensual desde el primer día.

Error 2: Sobredimensionar instancias

El error más común. Un t3.xlarge (4 vCPU, 16 GB RAM) cuesta 4 veces más que un t3.medium (2 vCPU, 4 GB RAM). La mayoría de aplicaciones en fase temprana funcionan perfectamente con t3.small o t3.medium.

Solución: Empieza pequeño. Monitoriza con CloudWatch. Escala solo cuando los datos lo justifiquen.

Error 3: NAT Gateway sin control

Un NAT Gateway cuesta 0,045 $/hora (32 $/mes) más 0,045 $ por GB de datos procesados. Si tu arquitectura enruta mucho tráfico a través del NAT Gateway (especialmente entre servicios AWS), la factura se dispara.

Solución: Usa VPC Endpoints para servicios AWS (S3, DynamoDB, SQS). Son gratuitos o mucho más baratos que el NAT Gateway.

Error 4: Data transfer entre regiones y AZs

AWS cobra por transferencia de datos entre zonas de disponibilidad (0,01 $/GB) y entre regiones (0,02-0,09 $/GB). En arquitecturas distribuidas, estos costes se acumulan rápidamente.

Solución: Mantén los servicios que se comunican frecuentemente en la misma AZ cuando sea posible. Usa CloudFront para reducir transferencia de datos desde el origen.

Error 5: Almacenamiento S3 sin lifecycle policies

Los datos se acumulan. Sin políticas de ciclo de vida, pagas el precio más alto (S3 Standard) por datos que nadie accede. La diferencia entre S3 Standard (0,023 $/GB) y S3 Glacier Deep Archive (0,00099 $/GB) es de 23 veces.

Solución: Configura lifecycle policies. Mueve datos no accedidos a S3 Infrequent Access (30 días) y a Glacier (90 días).

Error 6: Ignorar Reserved Instances y Savings Plans

Si sabes que vas a usar cierta capacidad durante 1-3 años, los Savings Plans ofrecen descuentos del 30-72%. Muchas startups pagan on-demand durante años por inercia.

Solución: Analiza tu uso estable. Para cargas predecibles, compra Savings Plans de 1 año con pago parcial anticipado (mejor relación ahorro/flexibilidad).

Error 7: No usar Spot Instances para cargas tolerantes

Las Spot Instances cuestan hasta un 90% menos que on-demand. Son perfectas para procesamiento batch, CI/CD, entrenamiento de modelos y tareas que pueden interrumpirse.

Solución: Usa Spot Instances para todo lo que no sea producción crítica. Combina con on-demand para mantener una base estable.

Patrones de escalabilidad en AWS

Auto Scaling basado en métricas

Configura Auto Scaling Groups para escalar horizontalmente basándote en:

• CPU: Escala cuando la utilización supera el 70%.
• Requests por target: Escala cuando cada instancia recibe más de N requests.
• Custom metrics: Escala basándote en métricas de negocio (cola de mensajes, latencia).

Caching agresivo

ElastiCache (Redis) reduce entre un 60-80% la carga en la base de datos. CloudFront cachea contenido estático en edge locations globales. Implementa caching en múltiples capas:

1. CDN (CloudFront): Assets estáticos, imágenes, CSS/JS.
2. Application cache (ElastiCache): Consultas frecuentes, sesiones.
3. Database cache (Aurora read replicas): Consultas complejas distribuidas.

Event-driven architecture

Desacopla componentes usando eventos:

• SQS: Colas de mensajes para procesamiento asíncrono.
• EventBridge: Bus de eventos para integración entre servicios.
• SNS: Notificaciones push para comunicación fan-out.

Este patrón permite que cada componente escale independientemente y reduce el acoplamiento entre servicios.

Checklist: tu arquitectura AWS paso a paso

1. Configura alertas de facturación (AWS Budgets, 5 minutos)
2. Solicita créditos AWS Activate si aplicas
3. Empieza con serverless para validar producto
4. Añade base de datos gestionada cuando necesites consultas complejas
5. Implementa caching antes de escalar compute
6. Monitoriza con CloudWatch y Right Sizing Recommendations
7. Evalúa contenedores cuando el tráfico sea constante y predecible
8. Compra Savings Plans cuando tu uso sea estable
9. Usa Spot Instances para cargas no críticas
10. Audita costes mensualmente con Cost Explorer

Conclusión

La arquitectura correcta en AWS no es la más sofisticada. Es la que se adapta a tu etapa de crecimiento y cambia con ella. Serverless para validar, servicios gestionados para crecer, contenedores para escalar.

El error más caro no es elegir mal un servicio. Es sobredimensionar la arquitectura para una escala que aún no tienes. Construye para hoy, con la capacidad de evolucionar mañana.

En NERVICO ayudamos a startups a diseñar arquitecturas AWS que escalan sin arruinarse: evaluamos tu infraestructura actual, diseñamos la arquitectura óptima para tu etapa y acompañamos la migración con métricas de coste desde el primer día.

Fuentes:

1. AWS Well-Architected Framework - Amazon Web Services
2. AWS Activate para startups - Amazon Web Services
3. AWS Q4 2025: $35.6B revenue, 24% YoY growth - TechCrunch, febrero 2026
4. State of the Cloud Report: 32% cloud spend wasted - Flexera, 2025
5. AWS Pricing Calculator - Amazon Web Services
6. Cloud market share Q4 2025 - Synergy Research Group