Escrito por Rodrigo de Miguel
Un blog no debería ser un SaaS | Parte 1/x
Por qué Astro SSG + AWS en lugar de Vercel
Pasé de una SPA en React (SEO pobre y CWV mejorables) a Astro con SSG servido en AWS (S3 + CloudFront + Route 53) para tener HTML rápido, infraestructura simple y costes mínimos, sin vendor lock-in innecesario para un portfolio/blog.
Contexto: no quería montar un producto, quería un portfolio serio
Este artículo nace de una decisión muy concreta y muy poco épica:
Quería un portfolio (y luego añadí un blog personal), no un SaaS, no un side-project monetizable, no una startup.
No iba a generar dinero.
No iba a tener lógica de negocio con usuarios concurrentes.
No iba a necesitar analítica avanzada ni A/B testing.
Pero sí quería tres cosas muy claras:
- SEO bien hecho
- Core Web Vitals perfectas
- Infraestructura simple, barata y bajo control
Nada más.
Y justo ahí es donde muchas soluciones actuales empiezan a sobrar.
El problema real: cuando la herramienta es más grande que el problema
Durante un tiempo mi portfolio estuvo montado como una SPA en React.
Funcionaba. Visualmente estaba bien. Pero tenía dos problemas claros:
- SEO flojo si no empezabas a meter parches
- CWV mejorables, sobre todo LCP y CLS
Podría haberlo “arreglado”:
- SSR
- prerender
- plugins
- más infraestructura
Pero me hice una pregunta muy simple:
¿Por qué estoy complicando algo que solo necesita servir HTML rápido?
Tenía ganas de probar Astro, sin tocar demasiado la infraestructura que ya tenía. Y ahí empezó todo.
El fork técnico: plataformas modernas vs stack simple
Llegados a este punto había dos caminos bastante razonables.
Opción A: plataforma tipo Vercel
Vercel es popular por algo:
- deploy sencillo
- DX muy cuidada
- capa gratuita tentadora
Para muchos proyectos encaja perfectamente.
No tengo nada que objetar ahí.
Pero en este contexto concreto, aparecían varios “peros”:
- Dependencia total del proveedor
- Costes que se disparan cuando sales del camino feliz
- Infra opaca: funciona, pero no sabes muy bien qué hay debajo
- Pensado para apps, no para HTML estático puro
Para un portfolio sin ingresos, eso era demasiado.
Opción B: Astro SSG + AWS (S3 + CloudFront)
La alternativa era volver a lo básico, pero con cariño técnico:
- Generar HTML estático
- Servirlo desde un CDN que ya tenía montado
- Pagar solo lo imprescindible
- Tener claro qué hace cada pieza
- Aprovechar el código React existente
Aquí es donde Astro empieza a tener sentido.
Por qué Astro y no Next o Nuxt
No necesitaba:
- SSR
- API routes
- middleware
- edge functions
Lo que buscaba era:
- HTML rápido
- build sencillo
- buen soporte para Markdown
- cero fricción en SEO
Astro encaja muy bien en ese escenario porque:
- prioriza Static Site Generation
- no te ata a un framework concreto
- se quita JavaScript de encima cuando no hace falta
- escupe HTML limpio y predecible
Para un blog y un portfolio, está justo en el punto bueno.
SSG no es una moda, es sentido común (aquí)
Un blog con SSG tiene ventajas bastante claras en este contexto:
| Aspecto | SSG |
|---|---|
| SEO | Excelente |
| CWV | Muy fácil de ajustar |
| Coste | Cero |
| Complejidad | Baja |
| Mantenimiento | Mínimo |
No hay base de datos.
No hay backend.
No hay runtime.
Solo archivos.
Eso no es una carencia.
Es libertad.
SSG no es nuevo: WordPress lleva años haciéndolo
Conviene recordar algo sencillo:
el Static Site Generation no es ninguna moda reciente.
WordPress lleva años sirviendo HTML desde el servidor (SSR) y cumple de sobra para blogs y portfolios. Es una opción totalmente válida.
En mi caso no lo elegí por algo muy simple:
mi portfolio ya estaba en React porque me resultaba cómodo y me dejaba tocarlo todo… y, siendo honestos, sé lo justo de PHP y no me apetecía rehacerlo en WordPress.
La lección no va de “WordPress vs Astro”.
Va de entender que generar HTML en servidor siempre ha sido la solución lógica para este tipo de sitios.
Y con Astro se hace con un par de líneas.
También se puede hacer en React con SSG “artesanal” usando un script en NodeJS, pero eso da para otro post.
Infraestructura: aburrida, barata y predecible (como a veces toca)
El stack final quedó así:
- Astro → genera HTML
- S3 → almacena los archivos
- CloudFront → CDN global
- Route 53 → DNS y dominio
Nada más.
Sin intermediarios.
Sin magia.
Sin “plataformas”.
Coste real: hablemos claro
Este punto es clave.
En mi caso concreto:
- Tengo bastantes zonas en Route 53
- El coste ronda los ~0,10 USD / mes
Para alguien normal:
- Route 53 cuesta 0,50 USD / mes por zona
- S3 + CloudFront, con tráfico bajo, salen gratis
El nivel gratuito de CloudFront incluye 10 millones de solicitudes HTTP o HTTPS al mes o 1 TB de transferencia mensual, que a grosso modo equivale a más de 2 millones de visitas (cada página transfiere unos 580 KB).
Si tienes ese tráfico en un blog personal, enhorabuena, eres famoso, probablemente no necesitas leer esto 🤣
| Concepto | Coste mensual |
|---|---|
| Route 53 | 0,50 USD |
| S3 | ~0 USD |
| CloudFront | ~0 USD |
| Total | ~0,50 USD |
No es una estimación optimista.
Es lo que pasa cuando sirves HTML estático.
SEO y CWV como requisito, no como afterthought
Aquí hay un cambio de mentalidad importante.
No optimicé SEO “porque Google lo exija”.
Lo hice por gusto profesional.
- HTML predecible
- URLs limpias
- Nada de JavaScript innecesario
- Control total del render
Con SSG + CDN:
- LCP es casi trivial
- CLS desaparece
- INP deja de dar guerra
No hay trucos raros.
Hay decisiones bien tomadas desde el inicio.
¿Y la analítica?
Esto no es un SaaS.
No necesito funnels, cohortes ni eventos complejos.
Uso:
- Google Search Console para SEO
Y listo.
Si alguien quiere:
- GA4
- Plausible
- lo que toque
Se añade sin drama.
Pero no es obligatorio.
Vendor lock-in: el detalle que casi nadie comenta
Con este enfoque:
- El resultado es HTML
- El hosting es estándar
- El dominio es mío
Si mañana quiero:
- moverlo a otro proveedor
- servirlo desde otro CDN
- cambiar DNS
No hay migraciones dolorosas.
No hay dependencias raras.
Para un proyecto personal, eso da bastante paz mental.
“Si crece, ya migraré” (y por qué aquí tiene sentido)
Este argumento suele usarse mal, pero aquí encaja.
Si algún día:
- el blog crece
- necesito SSR
- aparecen partes dinámicas
Entonces:
- se revisa la decisión
- se ajusta el stack
Pero no hoy.
Hoy el problema es otro y la solución encaja con lo que hay ahora.
Como dijo Elon Musk:
El error más común de un ingeniero inteligente es optimizar algo que no debería existir.
Si algún día tengo 2 millones de visitas al mes en un blog personal, seguro que tendré que preocuparme antes por otras cosas que por la infraestructura.
Qué he cambiado respecto a mi setup anterior
Antes (not bad, but could be better)
- SPA en React
- SEO forzado
- Más JavaScript del necesario
- CWV mediocres
Ahora (ouuuh yeahh! 🎉)
- Astro SSG
- HTML puro
- Infra simple
- CWV excelentes
El cambio no vino por urgencia extrema.
Vino por criterio técnico.
Y por el gustazo de ver (casi) todo en verde en PageSpeed Insights.
Qué queda por hacer (con honestidad)
Este setup no es “perfecto”, es suficiente.
Pendiente:
- Automatizar deploy con GitHub Actions (TODO real)
- Añadir comentarios a los posts
- Giscus (GitHub Discussions)
- Disqus
- etc
De momento, los comentarios por LinkedIn o email funcionan bien.
Nada bloqueante.
Nada que quite el sueño.
Un blog no necesita ser un SaaS moderno
Para un portfolio + blog personal:
- menos es más
- lo simple escala mejor
- lo barato duele menos
- el control pesa más que la comodidad
- solo me preocupo por escribir (que ya es bastante)
Astro + SSG + AWS no es una decisión “moderna”.
Es una decisión sensata para mi situación actual.
Y para este contexto, era justo lo que buscaba.
👉 Post 2: Preparar el proyecto Astro para producción (SSG, sitemap y estructura) y ahí sí entramos en código
