MercadoFresco tiene ya una red propia, un cortafuegos por capas, un balanceador que reparte el tráfico entre dos zonas de disponibilidad y una CDN que sirve el catálogo desde Madrid por 0,97 USD al mes. Y sin embargo, un cliente no puede comprar nada, porque la tienda responde en alb-mercadofresco-tienda-1234567890.eu-west-1.elb.amazonaws.com y el catálogo en d111111abcdef8.cloudfront.net. Además, los dos certificados de ACM que pedimos en las lecciones 03-03 y 03-04 siguen en PENDING_VALIDATION, esperando unos registros DNS que todavía no existen.

Amazon Route 53 es el servicio de DNS de AWS: traduce nombres a direcciones, sí, pero además comprueba la salud de los destinos y decide a cuál enviar a cada visitante según el peso, la latencia, el país o el estado del sistema. Su nombre viene del puerto 53, el puerto del DNS.

En esta lección Marta pone mercadofresco.example a apuntar a la nube, valida los certificados, cierra el HTTPS pendiente y deja preparadas las políticas de enrutamiento que MercadoFresco va a necesitar: el canario del 10 % para despliegues seguros, la geolocalización para abrir en Portugal y la conmutación por error a una página de mantenimiento. Y con eso cerramos el módulo 3.

1. Repaso práctico de DNS: zonas, delegación, resolución y TTL
2. Registrar y transferir dominios en Route 53
3. Zonas alojadas públicas y privadas
4. Tipos de registro
5. Registros de alias: la pieza que solo tiene AWS
6. Validar el certificado de ACM por DNS
7. Comprobaciones de estado de Route 53
8. Políticas de enrutamiento, una por una
9. Configurar el DNS de MercadoFresco por consola y por CLI
10. Route 53 Resolver y las reglas de reenvío hacia la oficina
11. Costes de Route 53 y limpieza
12. Cierre del módulo: la arquitectura de red completa

El DNS (Domain Name System) es una base de datos distribuida y jerárquica que traduce nombres a direcciones. Su estructura se lee de derecha a izquierda:

Una zona es la porción del árbol de la que alguien es responsable. Cuando MercadoFresco registra mercadofresco.example, se convierte en responsable de esa zona y de todo lo que cuelgue de ella.

La delegación es el mecanismo que conecta los niveles: los servidores de .example no conocen la IP de la tienda; solo saben decir «para todo lo de mercadofresco.example, pregunta a estos cuatro servidores de nombres». Eso se expresa con registros NS.

La resolución recursiva, paso a paso:

Cuatro conceptos que salen de este diagrama:

• Route 53 es el servidor autoritativo: la fuente de la verdad de la zona.
• El resolvedor recursivo (el del operador, o el 8.8.8.8 de Google) hace el trabajo de ir preguntando y guarda el resultado en caché.
• El TTL es cuántos segundos puede cachearse esa respuesta. Route 53 solo cobra las consultas que le llegan, así que un TTL alto ahorra dinero, pero ralentiza los cambios.
• Route 53 usa anycast: los mismos servidores de nombres se anuncian desde muchos puntos del mundo, y cada consulta llega al más cercano.

Cómo elegir el TTL:

La técnica de bajar el TTL a 60 varios días antes de una migración es la que separa una migración tranquila de un domingo largo: el TTL antiguo tiene que caducar en todas las cachés del mundo antes de que el nuevo tenga efecto.

Route 53 hace tres cosas distintas que conviene no confundir:

Se pueden usar por separado: es perfectamente válido tener el dominio registrado en otro proveedor y el DNS en Route 53. Solo hay que cambiar los servidores de nombres en el panel del registrador para que apunten a los cuatro que Route 53 asigna a la zona.

Dos ajustes que hay que verificar siempre tras registrar un dominio:

• Renovación automática activada. Un dominio caducado es una tienda apagada, y recuperarlo puede ser imposible.
• Bloqueo de transferencia activado. Impide que alguien mueva el dominio a otro registrador sin autorización.

Route 53 incluye además la privacidad del registro sin coste adicional: los datos de contacto de MercadoFresco no aparecen en las consultas WHOIS públicas.

Una zona alojada (hosted zone) es el contenedor de todos los registros de un dominio. Hay dos tipos y su diferencia es fundamental:

La zona privada resuelve un problema muy concreto. Hoy la aplicación se conecta a la base de datos con un nombre horrible como mercadofresco-pedidos.abc123xyz.eu-west-1.rds.amazonaws.com. Con una zona privada asociada a vpc-mercadofresco, ese nombre puede sustituirse por bd.interno.mercadofresco.example, que además puede repuntarse a otra instancia sin tocar la configuración de la aplicación.

Requisito importante: para que una zona privada funcione, la VPC debe tener enableDnsSupport y enableDnsHostnames a true. Es exactamente el ajuste que activamos en 03-01 y cuyo olvido es la causa número uno de que una zona privada «no resuelva».

Los registros son las entradas de la zona. Estos son los que MercadoFresco necesita:

Dos que merecen un comentario:

CAA. Con este registro, MercadoFresco declara que solo Amazon puede emitir certificados para su dominio. Si un atacante consiguiera engañar a otra autoridad certificadora, esa autoridad consultaría el CAA y se negaría a emitir. Cuesta cero y evita una clase entera de ataques:

CNAME y su limitación. Un CNAME dice «este nombre es en realidad aquel otro». El RFC 1034 prohíbe que un nombre con un CNAME tenga cualquier otro registro. Y el vértice del dominio (mercadofresco.example, sin www) tiene obligatoriamente registros SOA y NS. Por tanto:

El vértice de un dominio NO puede tener un registro CNAME. Nunca.

Esto es un problema serio, porque un ALB y una distribución de CloudFront no tienen IP fija: solo tienen nombres. No se puede poner un registro A, porque no hay IP que poner, y no se puede poner un CNAME, porque es el vértice. La solución es lo que viene ahora.

Un registro de alias es una extensión propia de Route 53. Por fuera se comporta como un registro A (o AAAA): devuelve una IP. Por dentro, Route 53 resuelve en el momento cuál es la IP actual del recurso de AWS al que apunta.

Tres ventajas concretas y medibles:

1. Funciona en el vértice. mercadofresco.example puede apuntar a CloudFront. Con CNAME sería imposible.
2. Es gratis. Route 53 no cobra las consultas resueltas por alias hacia recursos de AWS. Con 1,2 millones de consultas al mes, son unos 0,48 USD que no se pagan; a escala, mucho más.
3. Es más rápido. Un CNAME obliga al resolvedor a hacer dos consultas: primero el nombre original, luego el destino. Un alias devuelve la IP en una.

A qué puede apuntar un alias:

La regla práctica: si el destino es un recurso de AWS, usa alias siempre. CNAME solo para servicios de terceros.

Ahora se cierra lo que quedó pendiente en 03-03 y 03-04. ACM necesita comprobar que el dominio es tuyo, y la forma de demostrarlo es crear un registro CNAME concreto que solo puede crear quien controle la zona.

Devuelve algo como:

Hay un atajo que crea el registro automáticamente si el dominio está en Route 53 en la misma cuenta:

Hay que repetirlo con el certificado de us-east-1 que pedimos para CloudFront. Detalle útil: como ambos certificados cubren los mismos dominios, el registro CNAME de validación es idéntico, así que en la práctica basta con crearlo una vez y ambos se validan.

Dos propiedades de la validación por DNS que la hacen muy superior a la validación por correo:

• La renovación es automática. Mientras el registro CNAME siga existiendo, ACM renueva el certificado solo, cada año, para siempre. No borres nunca ese registro.
• No depende de que alguien lea un correo. La validación por correo se envía a [email protected] y caduca en 72 horas; si nadie lo abre, hay que empezar de nuevo.

Con los certificados emitidos, ya puedes crear de verdad el escuchador HTTPS del ALB de 03-03 y asociar el dominio propio a la distribución de CloudFront de 03-04. El HTTPS de MercadoFresco queda cerrado.

Route 53 puede vigilar destinos desde una red global de comprobadores y usar el resultado para decidir qué responde. Son la base de la política de conmutación por error.

Detalles importantes:

• Usa la misma ruta /salud que el ALB de 03-03, y por las mismas razones: debe ser rápida y local.
• Los comprobadores de Route 53 vienen de internet, desde unas 15 ubicaciones. El destino tiene que ser públicamente accesible; una comprobación contra una instancia en subred privada nunca pasará.
• Con RequestInterval: 30 y FailureThreshold: 3, un fallo se detecta en unos 90 segundos. Hay una opción de 10 segundos (fast interval) que cuesta más.
• MeasureLatency: true añade gráficas de latencia por región, muy útiles y sin coste extra.
• Coste: 0,50 USD al mes por comprobación de un destino de AWS, 0,75 USD si es externo.

Aquí Route 53 deja de ser «una tabla de nombres» y se convierte en una herramienta de arquitectura. Cada política responde una pregunta distinta.

Un nombre, un destino. Es la política por defecto y la que usa MercadoFresco para casi todo.

No admite comprobaciones de estado. Si el destino cae, Route 53 sigue devolviéndolo.

Se asigna un peso a cada destino y Route 53 reparte proporcionalmente: peso del destino ÷ suma de todos los pesos.

Caso de MercadoFresco: Luis va a desplegar la versión nueva de la tienda y quiere que solo el 10 % de los clientes la reciba, para poder medir errores antes de exponerla a todos.

Tres detalles del JSON:

• SetIdentifier es obligatorio en toda política que no sea simple: es lo que distingue dos registros con el mismo nombre y tipo.
• HostedZoneId: Z32O12XQLNTSW2 no es la zona de MercadoFresco: es el identificador de zona del servicio ELB en eu-west-1, un valor fijo publicado por AWS. Cada servicio y región tiene el suyo, y confundirlo con la zona propia es un error habitual. Para CloudFront siempre es Z2FDTNDATAQYW2.
• EvaluateTargetHealth: true hace que, si un ALB no tiene destinos sanos, Route 53 deje de devolverlo y mande todo el tráfico al otro.

Poner un peso a 0 retira un destino sin borrar el registro: la forma más rápida de abortar un canario. Este mecanismo reaparece en la lección 08-03, cuando CodeDeploy automatice el despliegue progresivo.

Route 53 responde con el destino de la región que menor latencia mide para el resolvedor que pregunta. No es «el más cercano geográficamente», sino el más rápido según mediciones reales de AWS.

Escenario futuro de MercadoFresco: si la expansión funciona y se abre una región en eu-central-1 para Alemania, un cliente de Múnich iría a Fráncfort y uno de Sevilla a Irlanda, con el mismo nombre. Hoy, con una sola región, esta política no aporta nada.

Enruta según de dónde es el visitante: continente, país o, en Estados Unidos, estado. Es una decisión de contenido, no de rendimiento.

Caso de MercadoFresco: abrir en Portugal con la tienda en portugués y precios en su IVA.

El registro por defecto es la parte que se olvida y provoca la incidencia más difícil de reproducir: todo funciona en la oficina y un cliente de Andorra recibe «servidor no encontrado».

Existe además el enrutamiento por proximidad geográfica (geoproximity), que permite desplazar el reparto con un sesgo numérico —«amplía un 30 % el radio de la región de Irlanda»— y que solo se puede configurar con Route 53 Traffic Flow.

Un destino primario y otro secundario. Route 53 devuelve el primario mientras su comprobación de estado esté sana; si falla, devuelve el secundario.

Caso de MercadoFresco: si el ALB cae entero, en vez de un error de conexión, los clientes ven una página estática alojada en S3 explicando la situación y con el teléfono de atención.

La página de mantenimiento vive en un bucket de sitio estático (técnica de 02-03) que debe llamarse exactamente igual que el nombre DNS: directo.mercadofresco.example. Es un requisito de S3 para alojar sitios web con dominio propio.

Y la limitación honesta: el DNS tiene caché. Si el TTL es de 300 segundos, algunos clientes seguirán yendo al ALB caído durante cinco minutos. Por eso la conmutación por error de DNS es una red de seguridad de último recurso, y la alta disponibilidad de verdad es la que ya montamos: dos zonas de disponibilidad detrás de un mismo ALB, que conmuta en segundos y sin depender del DNS.

Devuelve hasta ocho registros sanos a la vez, elegidos al azar, y el cliente prueba uno. Es como el reparto por turnos clásico del DNS, pero con comprobaciones de estado: los destinos caídos no se devuelven.

No es un balanceador: no mide carga, no drena conexiones y depende de que el cliente reintente. Sirve para destinos que no están detrás de un ALB, por ejemplo un conjunto de servidores de correo o de API internas. MercadoFresco no lo necesita, teniendo un ALB.

Las políticas se pueden anidar con Traffic Flow: primero geolocalización por país y, dentro de cada país, ponderada para el canario. Es la forma de combinar «Portugal ve la tienda portuguesa» con «el 10 % de los portugueses ve la versión nueva».

1. Route 53 → Zonas alojadas → mercadofresco.example.
2. Crear registro. Nombre en blanco para el vértice.
3. Activar Alias, elegir «Alias a distribución de CloudFront» y seleccionar la distribución.
4. Política de enrutamiento: Simple. Guardar.
5. Repetir con www, esta vez «Alias a otro registro de esta zona» → el vértice.
6. Para los registros MX, TXT y CAA: desactivar Alias e introducir los valores, uno por línea.

La consola tiene una ventaja real aquí: al elegir un destino de alias lo ofrece en una lista, así que no hay forma de equivocarse con el HostedZoneId del servicio.

change-resource-record-sets aplica un lote de cambios de forma atómica: o se aplican todos o ninguno.

Notas sobre este lote:

• UPSERT crea el registro si no existe y lo actualiza si existe. Es idempotente, lo que lo hace seguro de reejecutar. CREATE fallaría en la segunda ejecución y DELETE exige que los valores coincidan exactamente.
• Los registros de alias no llevan TTL: lo gestiona AWS.
• El registro TXT lleva comillas dentro del valor, escapadas en el JSON. Es un error habitual omitirlas.
• Z2FDTNDATAQYW2 es el identificador de zona de CloudFront, idéntico en el mundo entero; Z32O12XQLNTSW2 es el de ELB en eu-west-1.

Comprobación desde fuera, que es lo único que confirma que funciona de verdad:

El Route 53 Resolver es el resolvedor que vive en la dirección .2 de la VPC (10.0.0.2) y que ya conocimos en 03-01. Además de resolver nombres de AWS y de las zonas privadas, admite dos tipos de regla para conectarse con la red de la oficina:

Su uso real requiere la conectividad de red que solo aporta una VPN o Direct Connect, que mencionamos en 03-01 y que queda fuera del alcance de este curso. Coste orientativo: cada endpoint son dos ENI y cuesta unos 0,125 USD por hora por ENI, así que no es un recurso para dejar encendido por curiosidad.

⚠️ Aviso de coste

Concepto	Precio	MercadoFresco
Zona alojada	0,50 USD/mes cada una (las 25 primeras)	2 zonas → 1,00 USD/mes
Consultas estándar	0,40 USD por millón (primeros 1.000 M)	~1,2 M → 0,48 USD
Consultas resueltas por alias a recursos de AWS	Gratuitas	La mayoría → 0,00 USD
Consultas de enrutamiento especial (latencia, geo)	0,60 USD por millón	Marginal
Comprobación de estado (destino de AWS)	0,50 USD/mes	1 → 0,50 USD/mes
Comprobación de estado (destino externo)	0,75 USD/mes	—
Registro del dominio	Según el TLD, anual	—
Total estimado		≈ 1,60 USD/mes

Route 53 es, con diferencia, lo más barato del módulo. Pero hay un detalle desagradable: la zona alojada se cobra desde el momento en que se crea, aunque no tenga registros, y se cobran las 12 primeras horas aunque la borres. Crear y borrar zonas para practicar no sale gratis.

Limpieza (hay que vaciar la zona antes de borrarla; los registros NS y SOA se van solos):

# Borrar todos los registros que no sean NS ni SOA
aws route53 list-resource-record-sets --profile mercadofresco-dev \\
  --hosted-zone-id "$ZONA_PUB" \\
  --query 'ResourceRecordSets[?Type!=`NS` && Type!=`SOA`]' > registros.json
# (construir el change-batch con "Action": "DELETE" para cada uno y aplicarlo)

aws route53 delete-hosted-zone --profile mercadofresco-dev --id "$ZONA_PUB"
aws route53 delete-health-check --profile mercadofresco-dev --health-check-id "$HC_ID"

Lo que no se puede deshacer: el registro de un dominio no es reembolsable y no se puede cancelar. Solo se registra un dominio cuando se va a usar de verdad.

Y en dinero, la red completa de MercadoFresco:

Los dos NAT Gateway son el 64 % del gasto de red y serán el primer candidato a revisar en la lección 11-03 con Cost Explorer.

La red está construida y protegida a nivel de paquetes, pero quedan cuatro huecos que son exactamente el contenido del módulo 4:

• Permisos finos: quién puede hacer qué en la cuenta. Hoy hay un usuario admin y roles creados a medida, sin política de mínimo privilegio sistemática → 04-01, IAM.
• Cifrado gestionado: la clave alias/mercadofresco-datos existe, pero no se ha estudiado cómo se gobierna, se rota ni se comparte → 04-02, KMS.
• Secretos: la contraseña de mfadmin sigue estando donde no debería → 04-03, Secrets Manager y Parameter Store.
• Protección frente a ataques: la NACL con la que bloqueamos una IP en 03-02 no escala, y una denegación de servicio distribuida tumbaría la tienda pese a todo lo montado → 04-04, Shield y 04-05, WAF, ambos aplicados en el borde de CloudFront.

Intentar poner un CNAME en el vértice del dominio. Está prohibido por el estándar. La respuesta siempre es un registro de alias.

Olvidar el registro por defecto en geolocalización. Un visitante de un país no contemplado no recibe respuesta. Crea siempre el registro con CountryCode: "*".

Confundir el HostedZoneId del alias con el de tu zona. El del AliasTarget es el del servicio de destino (Z2FDTNDATAQYW2 para CloudFront, uno distinto por región para ELB), no el de mercadofresco.example.

Pedir el certificado de CloudFront en la región equivocada. Debe estar en us-east-1. Ya salió en 03-04 y sigue siendo la trampa más repetida.

Borrar el registro CNAME de validación de ACM. Parece basura y no lo es: sin él, ACM no puede renovar el certificado y este caducará en un año, silenciosamente.

No bajar el TTL antes de una migración. Si migras con TTL de 86.400, algunos clientes irán al destino antiguo durante un día entero. Bájalo a 60 con días de antelación.

Confiar la alta disponibilidad al DNS. La conmutación por error de Route 53 está limitada por la caché de los resolvedores. La disponibilidad real la da el ALB entre dos AZ, en segundos y sin depender del DNS.

Usar CNAME donde cabe un alias. Cuesta dinero en consultas, añade una consulta extra de latencia y no evalúa la salud del destino.

Olvidar la renovación automática del dominio. Un dominio caducado es una empresa desaparecida de internet, y recuperarlo puede ser imposible si alguien lo registra.

Consejo de oro: después de cada cambio de DNS, verifica con dig +short <nombre> @<servidor autoritativo> en vez de abrir el navegador. El navegador y el sistema operativo tienen sus propias cachés y te harán creer que el cambio no ha funcionado durante minutos.

MercadoFresco abre en Portugal. Requisitos: los visitantes de Portugal deben ver la tienda portuguesa (un grupo de destino distinto en el mismo ALB), los de España la española, y cualquier otro país la española; además, el 10 % de los visitantes portugueses debe recibir la versión nueva de la tienda para probarla; y si el ALB cae, todo el mundo debe ver la página de mantenimiento. Diseña la estructura de registros indicando políticas, identificadores y anidamiento.

Marta ha creado la zona alojada, ha añadido el alias al vértice y mercadofresco.example sigue sin funcionar 24 horas después, mientras que dig @ns-123.awsdns-45.com mercadofresco.example sí responde correctamente. Explica qué está pasando y escribe las comprobaciones, en orden, para confirmarlo.

MercadoFresco recibe 5 millones de consultas DNS al mes, de las cuales el 80 % se resuelven por alias hacia CloudFront. Tiene 2 zonas alojadas y 3 comprobaciones de estado, una de ellas contra un proveedor externo. Calcula el coste anual, y estima cuánto ahorraría subiendo el TTL de los registros no-alias de 300 a 3.600 segundos.

Solución 1

Hacen falta dos niveles anidados, y como Route 53 no permite anidar políticas directamente en un mismo nombre, se resuelve con nombres intermedios (que es exactamente lo que hace Traffic Flow por dentro).

Nivel 1 — geolocalización en mercadofresco.example:

Nivel 2 — ponderación en pt.mercadofresco.example (solo Portugal lleva canario):

Nivel 2 — es.mercadofresco.example: política simple, alias al ALB con EvaluateTargetHealth: true.

Conmutación por error: se aplica en el nivel 2, en es y en pt, cada uno con su par primario/secundario apuntando al bucket de mantenimiento. Ponerla en el nivel 1 no funcionaría, porque geolocalización y conmutación por error no se pueden combinar en el mismo conjunto de registros.

Detalles que hacen que esto funcione de verdad:

• El registro geo-defecto es imprescindible: sin él, un cliente de Andorra o de Francia no recibe respuesta.
• Los alias a es. y pt. son alias a otro registro de la misma zona, que también son gratuitos.
• Un canario del 10 % limitado a Portugal expone unos pocos cientos de clientes a la versión nueva: suficiente para detectar errores, poco para causar daño. Poner el peso de pt-canario a 0 aborta el despliegue en un minuto.
• En la práctica, y para más de dos niveles, se usaría Route 53 Traffic Flow, que permite dibujar el árbol de decisión y versionar la política.

Solución 2

El síntoma es inequívoco: Route 53 responde correctamente cuando se le pregunta directamente, pero el mundo no llega a preguntárselo. Eso significa que la delegación no está hecha: los servidores de nombres del registrador siguen apuntando a otro sitio.

Si los cuatro nombres de los pasos 1 y 2 no coinciden, ahí está el problema.

Segunda causa posible, si los NS sí coinciden: existen dos zonas alojadas para el mismo dominio (es fácil crear una duplicada), y los registros se añadieron a la que no está delegada. Cada zona tiene servidores de nombres distintos.

Si devuelve más de una, hay que quedarse con la delegada y borrar la otra.

Tercera causa: una zona privada con el mismo nombre que la pública, asociada a la VPC. Desde dentro de la VPC se resolvería la privada y desde fuera la pública, dando resultados contradictorios según desde dónde se pruebe. Es el llamado split-horizon DNS, útil cuando es intencionado y muy confuso cuando no lo es.

Cuarta causa, la más trivial: la caché local. Se descarta comparando dig +short mercadofresco.example (con caché) con dig +short mercadofresco.example @8.8.8.8 (resolvedor externo).

Solución 3

Coste mensual:

Coste anual: 37,80 USD.

Efecto de subir el TTL de 300 a 3.600 segundos. Solo afecta al millón de consultas no-alias, que son las que se cobran. Multiplicar el TTL por 12 reduce las consultas que llegan a Route 53 aproximadamente en la misma proporción, aunque no exactamente: hay muchos resolvedores distintos, cada uno con su propia caché, y algunos clientes ignoran los TTL largos. Con una reducción conservadora del 70 %:

• Consultas facturables: 1.000.000 → ~300.000
• Coste de consultas: 0,40 → 0,12 USD/mes
• Ahorro: 0,28 USD/mes, 3,36 USD al año.

Conclusión honesta del ejercicio: no merece la pena. Ahorrar 3 dólares al año a cambio de que cualquier cambio de DNS tarde una hora en propagarse es un mal negocio. El TTL debe elegirse por criterios operativos —cuánto tardas en poder revertir un cambio— y no por coste, salvo a escalas de cientos de millones de consultas.

Donde sí hay una decisión económica real es en las comprobaciones de estado: 2,10 USD al mes en tres comprobaciones es más que las consultas y las zonas juntas. Y donde de verdad se ahorra dinero es en el 80 % de consultas resueltas por alias: si esos 4 millones fueran CNAME, costarían 1,60 USD al mes adicionales, cinco veces más que todas las consultas facturables actuales.

MercadoFresco está en internet. mercadofresco.example responde, con HTTPS válido, servido desde la edge location más cercana a cada cliente, sobre una red diseñada, filtrada y repartida en dos zonas de disponibilidad. Sabes cómo funciona el DNS de verdad —zonas, delegación por registros NS, resolución recursiva y el papel de la caché—, sabes que Route 53 solo cobra las consultas que le llegan y que el TTL es una decisión operativa: 300 segundos en producción y 60 con días de antelación antes de una migración. Distingues las tres funciones separadas del servicio: registro de dominios, DNS autoritativo y comprobaciones de estado.

Has creado la zona pública de mercadofresco.example y la zona privada interno.mercadofresco.example asociada a vpc-mercadofresco, que solo funciona porque en 03-01 activamos enableDnsHostnames. Conoces los tipos de registro y has añadido un CAA que impide que ninguna autoridad distinta de Amazon emita certificados para el dominio. Y entiendes la limitación que lo explica todo: el vértice de un dominio no puede tener un CNAME, porque ya tiene SOA y NS. De ahí los registros de alias, que son propios de Route 53, funcionan en el vértice, devuelven la IP en una sola consulta, son gratuitos y evalúan la salud del destino con EvaluateTargetHealth. Sabes que el HostedZoneId de un alias es el del servicio de destino —Z2FDTNDATAQYW2 para CloudFront— y no el de tu zona.

Has creado el registro CNAME que valida los certificados de ACM y has cerrado el HTTPS que quedaba pendiente de 03-03 y 03-04, sabiendo que ese registro no debe borrarse nunca porque es lo que permite la renovación automática. Has montado una comprobación de estado contra /salud y has recorrido las políticas de enrutamiento con un caso real de MercadoFresco para cada una: simple para el vértice, ponderada para el canario del 10 % que reaparecerá en 08-03, latencia para el futuro multirregión, geolocalización para la apertura en Portugal —con el registro por defecto que casi todo el mundo olvida—, conmutación por error hacia la página de mantenimiento en S3, y multivalor para destinos sin balanceador. Has aplicado el DNS completo con change-resource-record-sets y UPSERT, has verificado con dig contra los servidores autoritativos, y sabes que Route 53 cuesta a MercadoFresco 1,60 USD al mes: lo más barato de todo el módulo.

Con esto el módulo 3 queda cerrado. La arquitectura de MercadoFresco es hoy: cliente → Route 53 → CloudFront → ALB → grupo de Auto Scaling en dos zonas de disponibilidad → RDS Multi-AZ en subredes privadas sin salida a internet, con el catálogo en S3 cerrado por Origin Access Control y todos los registros en mercadofresco-registros-web. El problema 1, las caídas de los viernes, está resuelto con 2.400 pedidos/hora de capacidad frente a 900 de demanda, incluso perdiendo una zona entera. El problema 3, crecer a más ciudades, tiene ya la infraestructura preparada, y el problema 4, los despliegues arriesgados, tiene el mecanismo de canario listo a la espera de la automatización del módulo 8.

Pero toda esta arquitectura descansa sobre supuestos que aún no hemos examinado. Hay un usuario administrador con permisos amplios y roles creados sobre la marcha sin una política sistemática de mínimo privilegio. La contraseña de mfadmin sigue estando donde no debería. La clave KMS alias/mercadofresco-datos existe pero nadie ha decidido quién puede usarla ni cada cuánto rota. Y la regla DENY numerada 50 con la que bloqueamos una IP abusiva es completamente inútil frente a un ataque distribuido desde diez mil direcciones. En el módulo 4, «Seguridad e identidad», empezando por la lección 04-01 «AWS Identity and Access Management (IAM)», construiremos la capa que falta: identidades, políticas y permisos mínimos; después el cifrado gestionado con KMS, la custodia de secretos con Secrets Manager y Parameter Store, y la protección del borde con Shield y WAF, aplicada justo delante de la distribución de CloudFront que acabas de montar.