Hace once módulos, MercadoFresco era una tienda online con un servidor que se caía los viernes, unas copias de seguridad que nadie había restaurado nunca y un despliegue que consistía en copiar ficheros por SSH un martes por la noche. Hoy tiene una arquitectura elástica, segura, observable, desplegable desde un pipeline, descrita en código, repartida en cinco cuentas, auditada con método y con una factura que cuesta un 24,8 % menos de lo que costaba hace dos meses.

Esta lección no enseña ningún servicio nuevo. Hace cinco cosas: recorre la arquitectura completa asociando cada pieza al módulo donde se aprendió y cierra el balance de los cinco problemas iniciales; plantea el proyecto final, que es un reto real con diez entregables; ofrece una solución de referencia comentada con sus alternativas descartadas; traza los caminos para seguir aprendiendo, con las certificaciones, los recursos y lo que este curso no ha tocado; y cierra el curso con la lista de limpieza de todo lo creado, para que nadie siga pagando por un laboratorio terminado.

Aviso de coste. Esta lección incluye la limpieza final de todos los recursos del curso. Si has seguido las prácticas en una cuenta real, esa sección no es opcional: un clúster de EKS olvidado cuesta 73 USD al mes, un grupo de ElastiCache más de 100, y siete endpoints de VPC unos 112. El orden de borrado importa, porque hay dependencias. Datos, cuentas e identificadores ficticios.

1. La arquitectura completa de MercadoFresco
2. Cada componente y el módulo donde se aprendió
3. Los cinco problemas y su métrica
4. Errores comunes y consejos
5. Ejercicios: el proyecto final
6. Soluciones: la arquitectura de referencia comentada
7. Los caminos de certificación de AWS
8. Recursos oficiales para seguir
9. Lo que este curso no ha tocado
10. Qué sabes hacer ahora
11. La limpieza final, en el orden correcto
12. Conclusión

El curso empezó con cinco problemas concretos. Este es el balance, con números y no con adjetivos:

Cinco problemas, cinco soluciones, y en los cinco casos un número que se puede enseñar. Esa es la diferencia entre haber migrado a la nube y haber resuelto algo.

Error: creer que la arquitectura final era el objetivo desde el principio. Nadie diseña esto de una vez. MercadoFresco llegó aquí en once pasos, cada uno resolviendo un problema concreto que dolía. Consejo: cuando diseñes, empieza por el problema, no por el diagrama.

Error: copiar esta arquitectura tal cual. Tiene sentido para una tienda con estos volúmenes, estos problemas y este equipo. Para 200 pedidos al mes es un disparate, y para 200.000 al día se queda corta. Consejo: copia el método de decisión, no las cajas del diagrama.

Error: entregar un proyecto de arquitectura sin números. «Usaremos DynamoDB porque escala» no es una justificación; «usaremos DynamoDB porque son 400 escrituras por segundo con acceso por clave y latencia de un dígito de milisegundos, y el coste estimado es de 22 USD al mes» sí lo es. Consejo: cada decisión, un número.

Error: no escribir las alternativas descartadas. El evaluador —y tú dentro de un año— necesita saber qué consideraste y por qué lo dejaste fuera. Consejo: por cada decisión importante, una alternativa descartada con su motivo.

Error: terminar el curso sin borrar los recursos. Es el error más caro de todos y le pasa a mucha gente. Consejo: haz la limpieza del final de esta lección hoy, no «cuando tenga un rato».

Consejo: el mejor proyecto no es el que usa más servicios, sino el que justifica mejor por qué no usa algunos. Descartar Shield Advanced, descartar EKS y descartar Beanstalk fueron tres de las decisiones más valiosas de este curso.

Consejo: guarda tu solución del proyecto. Dentro de seis meses, releerla te dirá más sobre lo que has aprendido que cualquier examen.

El encargo. MercadoFresco crece y el negocio plantea tres cosas a la vez para el próximo año:

1. Apertura en Portugal y Francia. Lisboa y Oporto primero, París y Lyon después. Los clientes portugueses y franceses deben tener una experiencia equivalente a la española.
2. Aplicación móvil para iOS y Android, con dos funciones nuevas: seguimiento del reparto en tiempo real —el cliente ve el vehículo moverse en el mapa— y recomendaciones de productos personalizadas según su historial de compra.
3. Mantener el coste por pedido. El gerente ha sido explícito: puede subir la factura, pero el coste por pedido no debe subir.

Los requisitos, escritos:

Lo que hay que entregar. Diez apartados:

(a) Diagrama de arquitectura. Un diagrama —mermaid, draw.io o papel fotografiado— con las regiones, las cuentas, los componentes y los flujos principales. Debe distinguir lo que ya existe de lo que se añade.

(b) Región o regiones y estrategia multirregión. ¿Una región o varias? ¿Cuáles? ¿Activo-activo, activo-pasivo, o una sola región con distribución en el borde? Justifica con los requisitos de latencia, residencia y disponibilidad, y di explícitamente qué descartas y por qué.

(c) Motores de datos para las dos funciones nuevas. Qué usarías para el seguimiento en tiempo real y qué para las recomendaciones, con el patrón de acceso, el volumen estimado y el coste aproximado de cada uno.

(d) Plan de seguridad y cumplimiento. Identidades, cifrado, secretos, protección perimetral, auditoría, y específicamente cómo tratas los datos de geolocalización de repartidores y clientes bajo el RGPD.

(e) Plan de observabilidad con SLI y SLO. Al menos tres indicadores con su objetivo, su ventana y su presupuesto de error; qué alarma dispara qué, y qué paneles necesita cada perfil.

(f) Pipeline y estrategia de despliegue para el nuevo ámbito multirregión y para la aplicación móvil, que tiene un ciclo de publicación distinto al de la web.

(g) Infraestructura como código y estructura de cuentas. Qué cambia en la organización actual de seis cuentas y cómo se despliega lo mismo en varias regiones sin duplicar código.

(h) Presupuesto mensual estimado con desglose por servicio y el coste por pedido resultante, comparado con el objetivo de 0,00934 USD.

(i) Revisión Well-Architected de tu propia propuesta: los tres riesgos principales que introduces, su pilar y su mitigación.

(j) Plan de migración por fases, con hitos, criterios de avance y qué haces si una fase falla.

Rúbrica de evaluación:

Criterio general: una entrega que justifique bien tres alternativas descartadas vale más que una que enumere quince servicios. Y cualquier apartado sin un número es un apartado incompleto.

Un compañero propone la solución más simple posible para el requisito de latencia: quedarse solo en eu-west-1 y resolver Portugal y Francia con CloudFront y AWS Global Accelerator, sin desplegar nada en otra región.

1. ¿Qué requisitos del enunciado sí resuelve esa propuesta y cuáles no?
2. Estima la latencia de red desde Lisboa y desde París hasta Irlanda, y di si el requisito de 200 ms es alcanzable.
3. ¿Qué le responderías sobre disponibilidad del 99,95 %?

Con la factura actual de 1.681,60 USD y 180.000 pedidos, el coste por pedido es de 0,00934 USD. El volumen se multiplica por cuatro hasta 720.000 pedidos.

1. Si la factura creciera linealmente, ¿cuánto costaría y cuál sería el coste por pedido?
2. Identifica cuatro partidas de la factura que no crecen con el volumen y estima cuánto pesan.
3. Estima la factura real con ×4 de pedidos y calcula el coste por pedido. ¿Se cumple el objetivo?

Solución al ejercicio 1: arquitectura de referencia comentada

Esta es una solución válida, no la única. Su valor está en las razones, no en las cajas.

(a) y (b) Regiones y estrategia multirregión.

La propuesta: eu-west-1 (Irlanda) sigue siendo la región principal y única para el estado transaccional, reforzada con CloudFront en todo el borde europeo y AWS Global Accelerator para el tráfico de la aplicación móvil. Se añade eu-west-3 (París) únicamente para dos cosas: el destino de la recuperación ante desastres y, si las mediciones lo justifican, una réplica de lectura del catálogo.

Por qué:

• La latencia se resuelve en el borde, no moviendo la base de datos. El requisito es de primer byte, y el 90 % del contenido de una tienda es estático o cacheable: fotos, catálogo, JavaScript. CloudFront ya lo sirve desde puntos de presencia en Lisboa, Madrid, París y Marsella. Para las llamadas dinámicas de la API, Global Accelerator mete el tráfico en la red troncal de AWS en el punto de presencia más cercano, lo que recorta entre un 20 y un 40 % de la latencia frente a internet público.
• La residencia del dato ya se cumple: Irlanda es la UE. El RGPD exige que los datos permanezcan en la UE o en países con decisión de adecuación, no que estén en el país del cliente. Este es el malentendido más frecuente en este tipo de proyectos.
• Una segunda región activa multiplicaría por dos la complejidad y por casi dos la factura, y el requisito de 99,95 % no la necesita: 99,95 % mensual son 21,9 minutos de indisponibilidad al mes, perfectamente alcanzables con Multi-AZ bien hecho dentro de una sola región.

Alternativas descartadas y por qué:

(c) Motores de datos para las funciones nuevas.

Seguimiento del reparto en tiempo real. Dos problemas distintos que la gente suele mezclar:

• Ingerir la posición: 200 repartidores enviando su posición cada 5 segundos son 40 mensajes/segundo, 3,5 millones al día. Es un volumen pequeño y constante.
• Entregarla al cliente: cada cliente con un pedido en curso quiere ver el vehículo moverse con menos de 3 segundos de retraso.

La propuesta:

Coste estimado: unos 95 USD al mes con este volumen, dominado por las conexiones WebSocket y las escrituras de DynamoDB.

Alternativa descartada: hacer que la aplicación pregunte por HTTP cada 3 segundos. Con 3.000 pedidos en curso serían 1.000 peticiones por segundo contra la API, es decir, más tráfico que toda la tienda, y una batería del móvil agotada en dos horas.

Recomendaciones de productos. Aquí la clave está en un requisito que el enunciado da y que mucha gente pasa por alto: «actualizadas a diario; no en tiempo real». Eso cambia toda la solución.

Coste estimado: unos 40 USD al mes.

Alternativa descartada: Amazon Personalize. Es el servicio específico para esto y probablemente daría mejores recomendaciones. Se descarta en la primera versión por tres razones: cuesta bastante más, añade un servicio nuevo que mantener a un equipo de cinco personas, y no hay todavía una medida de si las recomendaciones funcionan. La decisión escrita: empezar con reglas sencillas —«compraron esto también», «vuelves a necesitar esto»— sobre datos que ya están, medir la conversión durante tres meses, y entonces decidir si Personalize compensa. Introducir aprendizaje automático antes de tener una métrica de éxito es la forma más cara de no saber si algo sirve.

(d) Seguridad y cumplimiento.

Lo existente se mantiene y se extiende: Identity Center, alias/mercadofresco-datos para todo lo nuevo, secretos en Secrets Manager, WAF en CloudFront y en el ALB, Shield Standard, CloudTrail y Config centralizados en 444455556666.

Lo que se añade por la aplicación móvil:

• Amazon Cognito para la identidad de los clientes, con inicio de sesión federado. Los tokens caducan; nada de claves en la aplicación.
• Certificados por dispositivo en IoT Core para los repartidores, con política que solo permite publicar en su propio tema. Un repartidor no puede publicar la posición de otro.
• Limitación de velocidad y protección de bots en el WAF de la API móvil, que es el nuevo objetivo obvio.

Y la parte delicada, la geolocalización:

Y la advertencia que debe figurar en la entrega y que forma parte de la nota: esto es un diseño técnico, no un dictamen jurídico. El tratamiento de geolocalización de trabajadores es uno de los puntos más sensibles del RGPD y de la normativa laboral, exige evaluación de impacto y debe revisarlo un profesional de protección de datos antes de ponerse en producción. Una propuesta que resuelve la geolocalización sin mencionar esto está incompleta por muy buena que sea técnicamente.

(e) Observabilidad con SLI y SLO.

Con tres decisiones importantes: las alarmas se ponen sobre la tasa de consumo del presupuesto de error, no sobre umbrales instantáneos, para no despertar a nadie por un pico de 30 segundos; los paneles se separan por perfil —mercadofresco-produccion para el turno de guardia, mercadofresco-negocio para Sara y gerencia, y uno nuevo mercadofresco-movil—; y el coste por pedido sigue en el panel de negocio, junto a los pedidos, como se estableció en 11-02.

(f) Pipeline y despliegue. Se mantiene pipeline-mercadofresco-tienda con blue/green y reversión, y se añaden tres cosas: una etapa por región para lo que se despliegue en eu-west-3, siempre desplegando primero en la región secundaria y solo después en la principal; un pipeline propio para la API móvil, que se versiona de forma independiente porque las aplicaciones publicadas en las tiendas no se pueden revertir —una versión antigua puede quedar instalada meses, así que la API debe mantener compatibilidad hacia atrás durante al menos dos versiones—; y banderas de funcionalidad para activar el seguimiento en tiempo real por ciudad, lo que permite abrir Lisboa sin tocar el código.

(g) IaC y estructura de cuentas. La organización de seis cuentas no cambia: sigue siendo la adecuada, y el Entorno sigue siendo la mejor dimensión de separación. Lo que cambia es la parametrización: las plantillas red-mercadofresco.yaml y aplicacion-mercadofresco.yaml y las pilas del CDK reciben la región como parámetro, con ss-mercadofresco-linea-base extendido a la nueva región. Un solo repositorio, una sola definición, dos destinos.

La única cuenta que se plantea añadir es una de datos para la analítica y las recomendaciones, y se descarta por ahora: con cinco personas, una cuenta más es más gobierno del que aporta. Se revisará si el equipo de datos crece.

(h) Presupuesto estimado.

El objetivo se cumple con holgura, y la razón es exactamente la que 11-02 anticipaba: hay una parte importante de la factura —NAT, ALB, endpoints, gobierno, observabilidad base— que no crece con el volumen, y al repartirse entre cuatro veces más pedidos hace bajar el coste unitario. Multiplicar el negocio por cuatro multiplica la factura por 2,7.

(i) Los tres riesgos principales de esta propuesta:

(j) Plan de migración por fases:

Dos principios que gobiernan el plan: cada fase es reversible sin afectar a lo que ya funciona —banderas de funcionalidad, no despliegues irreversibles— y la prueba de carga es requisito para abrir el segundo país, no una tarea que se hace si sobra tiempo. Es exactamente el hallazgo de riesgo alto que 11-01 dejó abierto.

Solución al ejercicio 2

(1) Qué resuelve y qué no. La propuesta de una sola región resuelve: la residencia del dato, porque Irlanda es la UE; el coste, porque es con diferencia la opción más barata; la simplicidad operativa, decisiva con cinco personas; y la latencia del contenido estático, que es el grueso de una tienda. No resuelve por sí sola: la latencia de las peticiones dinámicas si no se añade Global Accelerator o algún mecanismo de aceleración; y no aporta nada frente a una caída regional completa, que sigue siendo el riesgo número uno de la propuesta.

(2) Latencia estimada. El ida y vuelta de red desde Lisboa hasta eu-west-1 ronda los 40-55 ms, y desde París los 25-35 ms. Sobre eso hay que sumar el establecimiento de TLS —que con reutilización de conexión y TLS 1.3 se amortiza— y el tiempo de proceso en el servidor, que en MercadoFresco está por debajo de 900 ms en el p99 pero mucho más bajo en la mediana. El requisito de 200 ms de primer byte es perfectamente alcanzable para contenido servido desde CloudFront —donde la latencia es la del punto de presencia local, del orden de 10-20 ms— y alcanzable para la API dinámica con Global Accelerator y conexiones reutilizadas. Lo que no sería alcanzable es servir cada petición dinámica desde Irlanda sin caché ni aceleración y con una consulta lenta detrás.

(3) Sobre el 99,95 %. Aquí hay que ser preciso con los números, porque es donde la conversación se suele torcer. 99,95 % mensual son 21,9 minutos de indisponibilidad al mes. Eso es perfectamente alcanzable en una sola región con Multi-AZ bien hecho: ALB en dos zonas, Aurora con conmutación por debajo de 30 segundos, tareas repartidas y despliegues sin corte. Lo que una sola región no cubre es una caída regional completa, que es un suceso raro pero real.

La respuesta honesta al compañero es que tiene razón en la propuesta y le falta una frase: la arquitectura de una sola región cumple el SLO comprometido, y el riesgo residual —una caída regional— debe estar escrito, cuantificado y aceptado por quien firma el contrato de 99,95 %, exactamente como se hizo en 11-01 con el RPO regional de 6 horas. Si el negocio no acepta ese riesgo residual ahora que hay tres países en juego, entonces la conversación cambia y hay que presupuestar luz piloto en eu-west-3: +12 % de factura, unos 550 USD al mes con el nuevo tamaño.

Solución al ejercicio 3

(1) Crecimiento lineal. Sería 1.681,60 × 4 = 6.726,40 USD, y el coste por pedido se mantendría exactamente igual en 0,00934 USD, porque el crecimiento lineal es la definición de coste unitario constante.

(2) Cuatro partidas que no crecen con el volumen:

A esas cuatro habría que añadir la base fija de CloudWatch —paneles, alarmas, métricas personalizadas— y la parte de Redshift que depende del número de informes y no del volumen de pedidos.

(3) Estimación realista.

Lo que coincide, dentro del margen de una estimación, con los 4.600 USD del apartado (h) de la solución de referencia.

Se cumple el objetivo con un 31,6 % de margen. Y la conclusión de fondo es la que da sentido a todo el módulo 11: el coste por pedido baja al crecer porque el 37 % de la factura es infraestructura fija que se reparte entre más pedidos. Es la razón por la que presentar el coste absoluto en la reunión mensual conduce a decisiones equivocadas, y por la que la métrica unitaria de 11-02 es la que hay que enseñarle al gerente. Con una advertencia: esta ventaja solo existe si la parte fija se mantiene bajo control. Si al crecer se añaden cuentas, regiones, clústeres y herramientas sin criterio, la parte fija crece con ellos y la economía de escala desaparece.

Este curso no prepara para ninguna certificación en concreto, pero cubre buena parte del temario de varias. El mapa:

Tres consejos sobre certificaciones, dichos sin rodeos:

1. La Associate de arquitecto es la que mejor relación tiene entre esfuerzo y utilidad si ya has hecho este curso. Con dos o tres semanas de repaso enfocado y exámenes de práctica, es alcanzable.
2. Una certificación no sustituye a haber construido algo. Abre puertas en procesos de selección y no enseña a decidir. Las decisiones difíciles de este curso —descartar EKS, descartar Shield Advanced, elegir un año en lugar de tres— no salen en ningún examen.
3. Si vas a certificarte, hazlo por el temario, no por el sello. El valor real está en las áreas que el examen te obliga a estudiar y que tú nunca habrías tocado por tu cuenta.

Y un consejo sobre cómo leerlos: la documentación de AWS es enorme y está pensada para consultarla, no para leerla. La forma productiva de usarla es tener un problema concreto, buscar la página exacta y leerla entera, incluida la sección de cuotas y la de precios, que son las dos que más disgustos evitan.

Once módulos y unas doscientas horas de AWS después, esto es lo que queda fuera y es el siguiente paso natural:

Y el orden que tiene más sentido después de este curso: primero Resiliencia, porque cierra el riesgo abierto más grave; después Analítica, porque es donde está el valor de negocio inmediato; y luego lo que pida el problema que tengas delante.

Al empezar este curso probablemente sabías que AWS existía y que «tiene muchos servicios». Ahora sabes hacer cosas concretas:

• Diseñar una arquitectura de tres capas en la nube, con red aislada, cómputo elástico y datos gestionados, y explicar cada decisión.
• Elegir el motor de datos adecuado a partir del patrón de acceso en lugar de por costumbre: relacional, clave-valor, en memoria, columnar.
• Poner una aplicación en contenedores sin gestionar servidores, con autoescalado, despliegue progresivo y reversión automática.
• Aislar y proteger: identidades sin credenciales permanentes, cifrado con claves propias, secretos rotados, WAF y grupos de seguridad con mínimo privilegio.
• Saber qué está pasando: métricas, registros, trazas, alarmas y paneles que responden a preguntas de negocio y no solo de infraestructura.
• Desacoplar con colas, temas, buses y máquinas de estados, y hacerlo bien: idempotencia, reintentos, colas de mensajes fallidos y compensación.
• Construir un pipeline que lleve un commit a producción sin intervención manual y que sepa volver atrás solo.
• Describir toda la infraestructura en código y desplegarla en varias cuentas y regiones sin copiar y pegar.
• Gobernar una organización multicuenta con unidades organizativas, políticas de control y una línea base común.
• Auditar lo construido con método —seis pilares, hallazgos, riesgos y plan priorizado— y documentar decisiones con sus alternativas descartadas.
• Leer una factura de AWS, repartirla por entorno y componente, encontrar lo que sobra y ponerle límites.
• Y sobre todo: decir que no. Descartar Shield Advanced con criterio, descartar EKS con seis condiciones escritas, descartar Beanstalk, descartar Personalize hasta tener una métrica. Un arquitecto se reconoce por lo que deja fuera.

Si has seguido las prácticas en una cuenta real, esto no es opcional. El orden importa, porque muchos recursos no se pueden borrar mientras otros dependan de ellos.

Antes de empezar, dos comprobaciones: revisa Cost Explorer con granularidad diaria para saber qué está costando de verdad, y filtra por la etiqueta Proyecto=mercadofresco en Tag Editor para tener el inventario completo. Cambia de región y repite: lo olvidado suele estar en us-east-1.

Fase 1 — Detener lo que consume ahora (minutos).

Fase 2 — Cómputo y contenedores. Servicios de ECS, luego el clúster; funciones Lambda; instancias EC2 —terminar, no parar, porque una instancia parada sigue pagando su volumen EBS—; grupos de Auto Scaling; y las imágenes de ECR, que se cobran por GB almacenado.

Fase 3 — Balanceo y entrega. Oyentes del ALB, luego el ALB, luego los grupos de destino. La distribución de CloudFront hay que deshabilitarla primero y esperar a que se propague antes de borrarla, lo que tarda del orden de 15 minutos. Las direcciones IP elásticas se liberan aparte: una IP sin asociar cuesta más que una asociada.

Fase 4 — Datos. Aquí conviene pararse a pensar, porque es irreversible. Clústeres de Aurora y RDS con --skip-final-snapshot solo si de verdad no quieres conservar nada; grupos de réplica de ElastiCache; tablas de DynamoDB; y los buckets de S3, que hay que vaciar antes de borrar, incluidas las versiones antiguas y los marcadores de borrado si el versionado está activo, que es la causa número uno de «no puedo borrar este bucket».

Fase 5 — Red. El orden es estricto y no admite atajos:

Los endpoints de interfaz son la fuga más silenciosa: cuestan unos 0,011 USD por hora, por AZ y por endpoint, aunque no pase un solo byte. Siete endpoints en dos AZ son 112 USD al mes por nada.

Fase 6 — Observabilidad y gobierno. Alarmas y paneles de CloudWatch; grupos de registros, que siguen costando almacenamiento indefinidamente; canarios de Synthetics; el grabador de Config, que cobra por elemento de configuración; los trails de CloudTrail más allá del primero, que es gratuito; y las reglas de EventBridge.

Fase 7 — Seguridad y gestión. Programar el borrado de las claves de KMS, con un periodo de espera de entre 7 y 30 días —cuestan 1 USD al mes mientras tanto—; secretos de Secrets Manager, también con periodo de recuperación; parámetros avanzados de Parameter Store, que son los únicos que cobran; y las Web ACL de WAF, que cuestan 5 USD al mes más 1 por regla aunque no estén asociadas a nada.

Fase 8 — Comprobación final. Cuatro pasos que nadie hace y que evitan la sorpresa del mes siguiente:

1. Espera 48 horas y vuelve a mirar Cost Explorer con granularidad diaria. Lo que siga apareciendo es lo que se te ha olvidado.
2. Recorre las regiones, especialmente us-east-1, donde acaban las Web ACL de CloudFront y muchas pruebas.
3. Revisa Trusted Advisor, que lista recursos huérfanos.
4. Deja un presupuesto de 1 USD activo con aviso al 100 %. Es tu red de seguridad permanente y cuesta cero.

Y lo que no hay que borrar: la cuenta en sí, si quieres seguir practicando; el trail de gestión, que es gratuito; y el presupuesto de vigilancia. Cerrar la cuenta es la opción nuclear y solo tiene sentido si no vas a volver.

Aquí termina el curso, y merece la pena mirar el camino completo antes de cerrar.

Empezaste con una cuenta vacía y una tienda que se caía los viernes. Terminas con una arquitectura que sirve a cuatro ciudades con 900 pedidos por hora en el pico, que se despliega casi cinco veces por semana en horario laboral, que se restaura en cuatro minutos, que está descrita íntegramente en código, gobernada en seis cuentas, auditada con los seis pilares del marco Well-Architected y presupuestada hasta el céntimo por pedido. Los cinco problemas que abrieron el curso están resueltos y cada uno tiene un número al lado.

Pero lo que te llevas no son los servicios. Los servicios cambian: la mitad de las pantallas de este curso serán distintas dentro de tres años y habrá nombres nuevos que hoy no existen. Lo que no cambia es el método, y eso es lo que has practicado once módulos seguidos: empezar por el problema y no por la tecnología; elegir el motor de datos por su patrón de acceso; medir antes de optimizar y optimizar antes de comprometer; probar la recuperación en lugar de suponerla; automatizar lo que se hace dos veces; escribir las decisiones con sus alternativas descartadas; y poner un número al lado de cada afirmación.

Y con ese método viene su parte menos vistosa y más valiosa: la capacidad de decir que no. Este curso descartó Shield Advanced con criterio, descartó EKS con seis condiciones escritas que lo cambiarían, descartó Elastic Beanstalk, descartó una segunda región activa, descartó Personalize hasta tener una métrica de éxito y descartó un compromiso a tres años que habría condicionado la arquitectura. Ninguna de esas decisiones sale en un diagrama y todas ellas son el trabajo real de un arquitecto. Se te reconocerá antes por lo que dejes fuera con argumentos que por lo que consigas encajar.

Queda un último consejo, y es el único que de verdad importa a partir de aquí: monta algo tuyo. No otro laboratorio guiado, ni otro tutorial. Algo pequeño y real, que resuelva un problema que te importe: la web de un club, un servicio para automatizar algo tedioso, un panel con datos que te interesen. Ponlo en una cuenta propia con MFA y un presupuesto de cinco dólares. Rómpelo. Arréglalo a las once de la noche. Descubre por ti mismo que las copias no funcionaban, que aquel grupo de seguridad estaba abierto y que el endpoint que dejaste encendido te ha costado catorce dólares. Ese día habrás aprendido más que en cualquier módulo de este curso, porque el error propio se recuerda y el ajeno se olvida.

MercadoFresco, mientras tanto, sigue repartiendo producto fresco en veinticuatro horas. Los viernes por la tarde, cuando entran novecientos pedidos por hora, las tareas ya están arriba desde las 16:45 porque alguien programó ese escalado. Nadie se entera. Y esa es exactamente la señal de que el trabajo está bien hecho: la mejor arquitectura es la que nadie nota.

Gracias por llegar hasta aquí. Ahora borra los recursos y ve a construir algo.