AWS Amplify

Descripción

Amplify tiene dos mitades que conviene no confundir. Amplify Hosting conecta con el repositorio, compila en cada push y publica el resultado en una CDN con HTTPS y dominio propio. Amplify Gen 2 es la parte de backend: se describe en TypeScript y Amplify crea por debajo la autenticación con Cognito, la API con AppSync y el almacenamiento en S3.

Se pueden usar por separado. Un sitio estático solo necesita el hosting, y es el camino más corto entre un proyecto de Astro o React y un sitio en producción sobre AWS.

Lo que Amplify ahorra es justo lo que hay que armar a mano con S3 y CloudFront: el build en cada cambio, la invalidación de la caché, el certificado TLS y las rutas limpias. El precio de esa comodidad es el control: la distribución de CloudFront existe, pero la administra Amplify y no aparece en tu cuenta.

Cómo funciona

1. Conectas un repositorio de GitHub, GitLab o Bitbucket y eliges una rama.
2. En cada push, Amplify levanta un contenedor de build y corre lo que diga amplify.yml: instalar dependencias, compilar y señalar la carpeta que se publica.
3. El resultado se sube a la CDN y la caché se vacía sola: nadie tiene que invalidar nada.
4. El sitio queda en https://<rama>.<id-de-la-app>.amplifyapp.com, o en tu dominio si lo añades.
5. Las reglas de reescritura y las cabeceras deciden qué responde cada URL y con qué instrucciones de caché y seguridad.

Así lo usa este sitio

Este sitio está en Amplify Hosting. No era el plan original —se iba a montar S3 y CloudFront a mano—, pero sin dominio propio la URL de Amplify lleva el nombre del club delante: aws-sbg-ucuenca.d2jrpw2uglkitl.amplifyapp.com. El primer tramo es el nombre de la rama de Git, así que esa rama no se renombra nunca.

Cuatro piezas hacen el trabajo, y tres viven en el repositorio:

• amplify.yml fija las versiones de Node y pnpm, en vez de usar las que traiga la imagen de build ese día, y guarda las dependencias descargadas en la caché de Amplify para que el siguiente build no las baje de nuevo.
• astro.config.mjs arma la URL pública con AWS_BRANCH y AWS_APP_ID, dos variables que Amplify inyecta en cada build. Así las vistas previas de los enlaces apuntan a la dirección correcta sin escribirla a mano.
• customHttp.yml le dice al navegador que guarde un año lo que está en /_astro/, cuyos nombres cambian con cada versión, y añade las cabeceras de seguridad.
• La regla de la 404 es la única que vive en la consola: /<*> → /404.html con estado 404-200.

Esa última costó un tropiezo. Con el estado 404 a secas, Amplify redirige: una URL inexistente respondía 302, cambiaba la dirección del navegador y terminaba en un 200. Se veía bien, pero para un buscador la página existía. Con 404-200 Amplify reescribe: sirve la misma página de error, deja la URL como estaba y responde 404.

Manos a la obra

• Conecta un repositorio con un solo index.html y haz push. En un par de minutos tienes una URL con HTTPS.
• Crea una rama prueba, conéctala también y fíjate en su URL: es la misma de antes con otro nombre delante.
• Pide una página que no existe con curl -I. Compara la respuesta con la regla en 404 y en 404-200: la primera trae una cabecera Location; la segunda, no.
• Añade un customHttp.yml con un Cache-Control propio, haz push y vuelve a mirar las cabeceras con curl -I.
• Al terminar, desconecta la rama de prueba: cada rama conectada vuelve a construirse con cada push que reciba.

Ejemplo visual

La flecha de la izquierda solo se recorre cuando alguien hace push; la de la derecha, en cada visita. Por eso los minutos de build dependen de cuánto se trabaja en el sitio, y la transferencia, de cuánta gente lo visita.