AWS Config cerró la lección anterior con una limitación honesta: comprueba las reglas que tú le has dicho. Es exacto y es potente, pero no puede avisarte de lo que no se te ha ocurrido preguntar.

Nadie ha escrito una regla que diga «avísame si tengo volúmenes EBS huérfanos costando dinero», porque para escribirla habría que sospechar primero que existen. Nadie ha escrito una regla sobre las IP elásticas sin asociar, que se facturan precisamente por no usarse. Y desde luego nadie ha escrito una regla sobre el límite de vCPU de la cuenta, que —como veremos en esta lección— es la razón real por la que asg-mercadofresco-tienda no puede pasar de cuatro instancias.

AWS Trusted Advisor hace ese repaso. Compara tu cuenta con un catálogo de buenas prácticas que AWS ha destilado de millones de clientes, y te dice lo que no habías pensado en preguntar. No es una herramienta de detección en tiempo real ni un sustituto de nada de lo anterior: es el repaso automático, el equivalente a que alguien con mucha experiencia mire tu cuenta una vez al mes y te señale las cosas obvias que llevas sin ver desde hace meses porque estás demasiado cerca.

Con esta lección se cierra el módulo 5, y con él la capa de observabilidad de MercadoFresco.

1. Qué es Trusted Advisor y en qué se diferencia de Config
2. Y en qué se diferencia de Well-Architected
3. Las cinco categorías
4. Qué comprueba cada categoría
5. Qué ves según el plan de soporte
6. Cómo suplir lo que el plan Basic no da
7. Recorrido comentado de un informe de MercadoFresco
8. Cuotas de servicio: el límite invisible
9. El caso del ASG que no pasa de cuatro instancias
10. Solicitar un aumento de cuota
11. Alarmar antes de chocar con una cuota
12. Automatización: API, exportación y notificaciones
13. Integración con EventBridge
14. Compute Optimizer y Cost Optimization Hub
15. La rutina de revisión mensual de Marta
16. Cierre del módulo: la capa de observabilidad completa
17. Las cinco preguntas del módulo 4, respondidas
18. Coste total añadido
19. Lo que viene: el cuello de botella se ha movido

La diferencia de fondo: Config responde preguntas; Trusted Advisor las hace.

Un ejemplo que lo aclara. MercadoFresco tiene una regla de Config que comprueba que todos los volúmenes EBS están cifrados. Perfecto. Pero ninguna regla comprueba si un volumen sirve para algo, porque a nadie se le ocurrió. Trusted Advisor lo señala sin que nadie se lo pida: «tienes 3 volúmenes en estado available, sin conectar a nada, que llevan costando 24 USD al mes desde marzo».

No compiten. Trusted Advisor te da el hallazgo; Config lo convierte en una regla permanente. El flujo natural es: Trusted Advisor descubre un problema que no habías previsto → escribes una regla de Config para que no vuelva a pasar → la remediación lo corrige sola. Ese es el ciclo completo.

Trusted Advisor mira hacia abajo, a los recursos. Well-Architected mira hacia arriba, a las decisiones. Trusted Advisor te dice que una instancia está infrautilizada; Well-Architected te pregunta si tu estrategia de escalado es adecuada para tu patrón de tráfico. Los dos usan los mismos cinco o seis pilares como marco conceptual, y de hecho las categorías de Trusted Advisor son casi los pilares de Well-Architected, pero operan a alturas distintas.

Well-Architected se estudia en 11-01, abriendo el módulo de buenas prácticas y costes.

Los tres estados posibles de cada comprobación:

Y una advertencia que ahorra frustraciones: el amarillo no siempre es un problema. Trusted Advisor no conoce tu contexto. Una instancia al 5 % de CPU puede ser un servidor de respaldo perfectamente justificado. Un bucket sin versionado puede ser un bucket de ficheros temporales. Los hallazgos son hipótesis que hay que evaluar, no órdenes.

Optimización de costes:

Rendimiento:

Seguridad:

Tolerancia a fallos:

Límites de servicio (cuotas):

Comprueba el uso frente a la cuota de decenas de servicios y avisa cuando se supera el 80 %. Es la categoría más infravalorada y la que más caídas ha causado en la historia de AWS. Tiene sección propia más abajo.

Aquí toca ser completamente honesto, porque es donde más decepciones hay:

Lo que MercadoFresco ve con el plan Basic (0 USD):

Es decir: con el plan Basic, MercadoFresco ve seguridad básica y límites de servicio, que no es poco —son las dos categorías que más caídas evitan— pero no ve nada de coste, rendimiento ni tolerancia a fallos, ni tiene API para automatizar.

¿Merece la pena subir a Business? El cálculo honesto para MercadoFresco:

Con 600 USD de gasto, pagar 100 USD por Trusted Advisor no sale a cuenta solo por las recomendaciones. Pero el plan Business incluye mucho más que Trusted Advisor: soporte técnico 24×7 con respuesta en una hora para producción caída, acceso a arquitectos de soluciones, y la posibilidad de abrir casos técnicos. Esa es la razón real para contratarlo, y hay que decidirlo con ese criterio, no por las comprobaciones.

La decisión de MercadoFresco: seguir en Basic por ahora y suplir lo que falta con lo ya aprendido, con revisión de la decisión cuando el gasto supere los 2.000 USD mensuales o cuando la tienda sea crítica para el negocio hasta el punto de necesitar soporte con SLA. Está anotado en el registro de decisiones, con fecha, igual que la decisión sobre Shield Advanced en 04-04.

Aquí es donde el módulo entero se paga. Cada comprobación que Trusted Advisor no da en Basic se puede reproducir con lo que ya sabes:

Los scripts concretos. Volúmenes huérfanos, con Config:

IP elásticas sin asociar, que se facturan por no usarse:

Balanceadores sin tráfico en los últimos 7 días:

Certificados de ACM próximos a caducar (recuerda: los de CloudFront están en us-east-1):

Los certificados emitidos por ACM y validados por DNS se renuevan solos (03-03), pero los importados no, y un certificado caducado tumba la tienda entera. Esta comprobación merece estar en la rutina mensual.

La conclusión que importa: con Config, CloudWatch y un puñado de scripts, MercadoFresco reproduce la mayor parte de lo que daría el plan Business, gratis. Lo que no puede reproducir es el soporte técnico con SLA, y ese es el verdadero producto que se compra.

Este es el informe completo, incluyendo las comprobaciones que MercadoFresco no ve con Basic pero que hemos reproducido con las técnicas de la sección anterior. Comentado hallazgo a hallazgo.

Comentario. El rojo del puerto 22 es exactamente el mismo hallazgo que dio la regla mercadofresco-ssh-restringido de Config en 05-04. Dos herramientas independientes señalando lo mismo es la mejor confirmación posible de que es real. La diferencia: Config lo remedia solo; Trusted Advisor solo lo señala.

La clave de 412 días es la del usuario integracion-proveedor del ejercicio 2 de 05-03. El arreglo de fondo no es rotarla: es sustituirla por un rol asumible con sts:ExternalId (04-01).

Comentario. Los tres amarillos son ejemplos perfectos de hallazgos que hay que evaluar, no obedecer:

• Los 2 volúmenes sin instantánea son los volúmenes raíz de las instancias del ASG. No necesitan copia: son efímeros por diseño, se recrean desde lt-mercadofresco-tienda, y hacerles instantáneas sería pagar por copiar algo que ya está en la AMI. Se marca como aceptado y se documenta.
• Los 2 buckets sin versionado son mercadofresco-registros-web (registros del ALB) y mercadofresco-catalogo-fotos. El primero, correcto: los registros no se sobrescriben. El segundo sí es un hallazgo real: si alguien sube una foto equivocada sobre una buena, no hay vuelta atrás. Se corrige.
• Los health checks de Route 53 son un hallazgo real y valioso. MercadoFresco tiene un registro alias hacia CloudFront (03-05) sin comprobación de estado. No hay conmutación por error configurada hacia nada. Es una decisión pendiente que merece discusión, no una corrección inmediata.

Comentario. El amarillo de la compresión es dinero directo: activar la compresión automática en CloudFront para las respuestas de la API reduce la transferencia de salida, que es la partida más cara de CloudFront. Es un cambio de una casilla. Se corrige el mismo día.

Comentario, hallazgo por hallazgo:

• Los 3 volúmenes huérfanos quedaron de instancias terminadas manualmente durante las pruebas de 02-01 y 02-02. Nadie los borró porque al terminar una instancia, los volúmenes adicionales no se borran salvo que DeleteOnTermination esté activo. Es el hallazgo de coste más común de AWS. Se borran, tras comprobar que no contienen nada.
• Las 2 IP elásticas son de las pruebas del NAT y de la instancia inicial. Una IP elástica es gratis mientras esté asociada a una instancia en ejecución; cuando no lo está, se factura precisamente para desincentivar el acaparamiento. Se liberan.
• mercadofresco-tienda-01 al 4 % es un hallazgo especialmente interesante. Esa instancia es la original de 02-01, anterior al ASG. Ya no sirve para nada: el tráfico va al ALB y de ahí al grupo. Está encendida desde entonces porque nadie se acordó de apagarla. Es exactamente el tipo de cosa que solo se detecta con un repaso automático.
• Las 4 instantáneas manuales de más de 6 meses son de las pruebas de 02-04. Aquí hay que aplicar criterio: antes de borrarlas conviene comprobar que no hay ninguna obligación de conservación, y esa comprobación es la regla personalizada del ejercicio 2 de 05-04.
• La recomendación de Savings Plans es la de mayor impacto de todo el informe, y deliberadamente no se trata aquí: el análisis de compromisos de uso es la lección 11-05. Trusted Advisor lo señala; la decisión se toma con Cost Explorer delante.

El rojo de las IP elásticas al 100 % es el hallazgo más urgente del informe, y es doblemente interesante: es la misma causa que el hallazgo de coste. Las 2 IP sin asociar están consumiendo 2 de las 5 plazas de la cuota. Si mañana hiciera falta un tercer NAT gateway o una IP para algo, la llamada a la API fallaría con AddressLimitExceeded y nadie entendería por qué. Liberarlas resuelve las dos cosas a la vez.

Y la fila de vCPU es la que lleva al caso siguiente.

Toda cuenta de AWS tiene cuotas (antes «límites de servicio») en prácticamente todo: cuántas vCPU puedes tener corriendo, cuántas VPC, cuántas reglas por grupo de seguridad, cuánta concurrencia de Lambda.

Existen para proteger a AWS de un uso descontrolado —accidental o malicioso— y para protegerte a ti de una factura sorpresa. La mayoría son ajustables; algunas no.

Lo que hace peligrosas a las cuotas es cuándo te enteras: cuando ya has chocado, en el peor momento posible. Una cuenta que funciona perfectamente durante meses puede fallar de golpe el viernes en que necesita escalar.

Service Quotas es la consola donde se ven y se gestionan:

Las cuotas que MercadoFresco vigila y por qué:

Aquí está el caso concreto que anunciábamos, y es un ejemplo perfecto de por qué esta categoría importa.

asg-mercadofresco-tienda está configurado con mínimo 2, deseado 2, máximo 4. Marta siempre había asumido que ese 4 era una decisión de diseño. Al mirar las cuotas descubre que no del todo:

• Las instancias son t3.large: 2 vCPU cada una.
• La cuota de vCPU bajo demanda estándar de la cuenta es 16.
• Otras cargas de la cuenta consumen 8 vCPU.
• Quedan 8 vCPU disponibles = 4 instancias t3.large.

El máximo del ASG no está limitado por el diseño: está limitado por la cuota. Y esto tiene una consecuencia muy concreta y muy fea.

El viernes a las 19:00, con 900 pedidos por hora y una capacidad de 600 pedidos por hora por instancia, MercadoFresco necesita al menos 2 instancias solo para el tráfico normal. Si llega un pico del doble —una campaña, una mención en redes, un viernes de puente— el ASG intenta escalar. Y si otra cosa de la cuenta hubiera consumido vCPU entre medias:

El ASG no escala. Los clientes ven errores. Y la causa no está en ninguna alarma de CloudWatch, ni en ninguna regla de Config, ni en ninguna traza de X-Ray. Está en una cuota de la cuenta que nadie ha mirado nunca.

Peor aún: el fallo se produce en el peor momento posible, porque es precisamente cuando escalas cuando chocas con el límite. Es el fallo latente perfecto.

La alarma mercadofresco-asg-al-maximo de 04-04 avisa cuando el grupo llega a su máximo, que es una buena señal de que hace falta más capacidad. Pero avisa cuando ya estás en el techo; no avisa de que el techo es más bajo de lo que creías.

Los estados posibles: PENDING, CASE_OPENED, APPROVED, DENIED, CASE_CLOSED.

Consejos prácticos, aprendidos a base de disgustos:

1. Solicita con antelación. Los aumentos pequeños se aprueban automáticamente en minutos; los grandes pasan a un caso de soporte y pueden tardar días. Solicitar el viernes por la tarde porque estás chocando ahora mismo es exactamente el escenario que hay que evitar.
2. Pide con margen, pero razonable. Pedir 64 vCPU cuando usas 8 es razonable si esperas crecer. Pedir 10.000 sin justificación se deniega.
3. Justifica. Si el aumento pasa a soporte, explicar el caso de uso —«tienda de comercio electrónico con picos los viernes, ASG que necesita escalar a 12 instancias»— acelera mucho.
4. Las cuotas son por región. Subirla en eu-west-1 no la sube en us-east-1. Si tienes plan de recuperación ante desastres en otra región, súbela también allí, o descubrirás el problema el día del desastre.
5. Algunas cuotas son por cuenta, no por región: IAM, S3, CloudFront.
6. Solicita con Organizations cuando tengas varias cuentas (09-04): las plantillas de cuota aplican valores por defecto a las cuentas nuevas.

Y la aritmética que hay que hacer antes de decidir el valor:

Fíjate en la cuarta fila: un despliegue azul/verde duplica temporalmente el número de instancias. Es un caso que se olvida sistemáticamente al calcular cuotas, y es la causa de que muchos primeros despliegues sin interrupción fallen. Se estudia en 08-03.

Service Quotas publica métricas de uso en CloudWatch en el espacio AWS/Usage. Eso permite alarmar antes de llegar al límite, que es lo que convierte una cuota de trampa en un dato gestionado.

Ese umbral de 11 es el 70 % de 16. La forma elegante de expresarlo, que se ajusta sola si la cuota cambia, es una expresión de métrica con la función SERVICE_QUOTA():

SERVICE_QUOTA() es la función que hace que esto funcione bien: devuelve el valor actual de la cuota para esa métrica. Si mañana AWS aprueba el aumento a 64, la alarma se recalibra sola sin que nadie toque nada. Es exactamente el tipo de detalle que separa una alarma que envejece bien de una que hay que mantener.

La misma técnica para la concurrencia de Lambda, que es la otra cuota que puede morder a MercadoFresco en el pico de subida de fotos al catálogo:

Coste: 0,10 USD por alarma. Dos alarmas de cuota, 0,20 USD al mes, para evitar un fallo de escalado en el pico de un viernes. Es probablemente la mejor relación coste-beneficio de todo el módulo.

Importante: la API de Trusted Advisor (support y trustedadvisor) requiere plan Business o superior. Con Basic, estos comandos devuelven un error de suscripción. Se incluyen porque es lo que usarás en cuanto tu organización tenga ese plan.

La API de support está solo en us-east-1. Es global y se atiende desde ahí, igual que ACM para CloudFront (03-04) o las Web ACL de CloudFront (04-05). Es un patrón recurrente en AWS que ya reconoces.

Un script que exporta el informe completo a CSV para la revisión mensual:

Notificaciones semanales por correo: con plan Business o Enterprise, Trusted Advisor envía un resumen semanal a los contactos configurados. Se activan en las preferencias de la consola, y los destinatarios son los contactos alternativos de la cuenta —el contacto de operaciones, el de seguridad, el de facturación—, que configuramos en 01-02. Si no los configuraste entonces, este es el momento: [email protected].

Trusted Advisor emite eventos cuando el estado de una comprobación cambia. Con EventBridge (07-03) se puede reaccionar automáticamente:

Dos detalles: los eventos de Trusted Advisor se emiten en us-east-1, así que la regla va ahí; y el filtro por check-name es imprescindible, porque sin él recibirías un aviso cada vez que cambia cualquiera de las ~115 comprobaciones.

Lo que EventBridge habilita, y que es el patrón a copiar: no solo notificar, sino actuar. Una regla puede invocar una Lambda que, ante un hallazgo de «clave de acceso expuesta», desactive la clave inmediatamente. Cuando una clave aparece en un repositorio público, cada minuto cuenta. El detalle completo de EventBridge —patrones, objetivos, buses, reintentos— es la lección 07-03.

Dos servicios complementarios que se mencionan aquí y se desarrollan en el módulo 11:

AWS Compute Optimizer analiza las métricas de CloudWatch de los últimos 14 días —más si activas las métricas de memoria del agente que instalamos en 05-01— y recomienda el tipo de instancia óptimo para cada carga. Es gratis para las recomendaciones básicas.

Salida típica para MercadoFresco:

Y aquí conviene una advertencia importante: Compute Optimizer no sabe que mercadofresco-tienda-01 no debería existir. Recomienda reducirla a t3.small y ahorrar 20 USD. La respuesta correcta es apagarla, y ahorrar 60. Las herramientas automáticas optimizan lo que hay; la pregunta de si debe haberlo la sigue haciendo una persona.

Compute Optimizer analiza también volúmenes EBS, funciones Lambda —recomendando la memoria óptima, que en Lambda determina también la CPU— y servicios de ECS en Fargate (módulo 10).

Cost Optimization Hub consolida en un solo sitio las recomendaciones de coste de Compute Optimizer, Trusted Advisor, Cost Explorer y las recomendaciones de reservas, con el ahorro estimado agregado y sin duplicar. Es la lección 11-03.

Esta lección no entra en costes. El módulo 11 entero está dedicado a ello: etiquetado y asignación (11-02), Cost Explorer (11-03), Budgets (11-04) y Savings Plans (11-05).

Esta es la lista de comprobación concreta que Marta ejecuta el primer lunes de cada mes, en una hora. Es el producto operativo de todo el módulo 5.

Seguridad (15 minutos)

• [ ] Trusted Advisor, categoría de seguridad: ningún rojo.
• [ ] Cuadro de cumplimiento de Config: número de reglas no conformes frente al mes pasado.
• [ ] aws cloudtrail validate-logs sobre el mes anterior; guardar la salida.
• [ ] Consulta de Athena: IP de origen desconocidas y AccessDenied agrupados (05-03).
• [ ] Revisar usuarios IAM con claves de más de 90 días.
• [ ] Comprobar que no hay actividad de la cuenta raíz.

Coste (10 minutos)

• [ ] Volúmenes EBS available (consulta de Config).
• [ ] IP elásticas sin asociar.
• [ ] Balanceadores sin tráfico en 7 días.
• [ ] Recomendaciones de Compute Optimizer.
• [ ] Comparar la factura del mes con la del anterior; investigar cualquier desviación mayor del 20 %.
• [ ] Instantáneas manuales de RDS y EBS de más de 6 meses.

Fiabilidad (10 minutos)

• [ ] Trusted Advisor, tolerancia a fallos.
• [ ] Cuotas de servicio: nada por encima del 70 %.
• [ ] Certificados de ACM: ninguno a menos de 60 días de caducar (en las dos regiones).
• [ ] Comprobar que el canario canario-mercadofresco-compra no ha fallado.
• [ ] Revisar que las políticas de DLM han creado las instantáneas previstas (02-02).

Observabilidad (15 minutos) — el más importante y el que más se salta

• [ ] Simulacro trimestral: set-alarm-state sobre una alarma crítica y confirmar que el aviso llega al teléfono de guardia.
• [ ] Suscripciones de SNS: ninguna en PendingConfirmation.
• [ ] Grupos de registros sin retención (regla de Config, debería dar cero).
• [ ] Coste de CloudWatch del mes: ¿ha crecido? ¿por qué?
• [ ] Alarmas que han saltado este mes: ¿alguna fue un falso positivo? Ajustar umbral o borrarla.
• [ ] Alarmas que no saltaron cuando debían: añadir la que falta.

Ese penúltimo punto es el que mantiene vivo el sistema. Una alarma que da falsos positivos repetidos acaba siendo ignorada, y el día que sea real nadie la mirará. Una alarma que se ignora es peor que no tener alarma, porque da una falsa sensación de cobertura. Borrar alarmas es tan importante como crearlas.

Deuda técnica (10 minutos)

• [ ] Revisar el registro de decisiones: ¿alguna con fecha de revisión vencida? (Shield Advanced en 04-04, plan de soporte en esta lección, migración a ADOT en 05-02).
• [ ] Reglas de WAF marcadas como temporales durante un incidente (04-05).
• [ ] Excepciones aceptadas de Config y de Trusted Advisor: ¿siguen siendo válidas?

Las cinco piezas y qué responde cada una, que es el resumen que hay que llevarse:

Y las conexiones entre ellas, que son lo que convierte cinco servicios en un sistema:

• CloudTrail dispara la grabación de Config: sin CloudTrail, Config no se entera de los cambios.
• CloudWatch recibe los eventos de CloudTrail y los convierte en alarmas de seguridad.
• ServiceLens une las métricas de CloudWatch con las trazas de X-Ray y los registros.
• Trusted Advisor descubre lo que no se te ocurrió; Config lo convierte en regla permanente.
• Config remedia; CloudTrail registra la remediación; CloudWatch avisa de que ocurrió.

El camino completo de un incidente, que ahora MercadoFresco tiene entero:

Alarma de CloudWatch → ServiceLens → traza de X-Ray → subsegmento culpable → registro correlacionado → CloudTrail si hubo intervención humana → regla de Config para que no vuelva.

El módulo 4 se cerró con cinco preguntas abiertas. Estas son las respuestas, con nombre y apellidos:

1. «Nadie ha comprobado que un aviso de SNS llegue a un teléfono a las 4 de la madrugada.»

Respondida en 05-01. Se comprobaron las suscripciones de alertas-mercadofresco buscando el temido PendingConfirmation, se suscribió el correo [email protected] y el teléfono de guardia, y se hizo el simulacro con set-alarm-state, que dispara las acciones reales sin tocar la métrica. Se descubrió además que el «no molestar» del móvil silenciaba los SMS de números cortos: la cadena de aviso incluye el teléfono, y el teléfono también hay que probarlo. Queda como simulacro trimestral en la rutina mensual.

2. «Los registros de WAF, VPC, ALB y Lambda se acumulan en cinco sitios sin correlacionar.»

Respondida en 05-01. Centralización en CloudWatch Logs de lo que se puede centralizar —aplicación, nginx, Lambdas, WAF (aws-waf-logs-mercadofresco), flow logs (flowlogs-mercadofresco) y PostgreSQL— con retención por grupo desde el primer día, y con la honestidad de reconocer lo que no va ahí: los accesos del ALB y de CloudFront viven en S3 y se consultan con Athena. Logs Insights consulta hasta 50 grupos a la vez, y eso es lo que hace la correlación posible.

3. «Si un cliente dice que su pedido tarda 8 segundos, Marta no sabe si el problema está en la tienda, en la Lambda o en la base de datos.»

Respondida dos veces. Primero en 05-01, con cuatro consultas de Logs Insights sobre cuatro grupos y una cronología montada a mano: 7.402 ms dentro de PostgreSQL. Después en 05-02, en una sola búsqueda —annotation.pedido_id = "48213"— y una vista de cascada donde el problema se lee en dos segundos: 39 subsegmentos de 190 ms en serie, el 91 % del tiempo, un patrón N+1. Corregido con WHERE id = ANY(...): p95 de 6,8 s a 0,44 s, y DatabaseConnections de 185 a 96 en el pico del viernes.

4. «Nadie sabe quién descifró la última copia.»

Respondida en 05-03. Tres eventos de kms:Decrypt sobre mercadofresco-pedidos: RDS cifrando su copia automática, una instancia del ASG desde 10.0.11.24, y rol-restauracion-copias a las 03:42 desde 198.51.100.77, sin MFA, sobre snapshot-2026-07-27. La investigación completa —congelar la evidencia, encontrar el AssumeRole real, reconstruir la sesión por accessKeyId— llevó a Luis probando una restauración de madrugada. Intención correcta, procedimiento incorrecto. Con acciones correctivas y fechas, y una alarma para la próxima vez.

5. «Nada avisa si alguien desactiva el cifrado de un bucket o abre un SG al mundo.»

Respondida en 05-04. Y no solo avisa: lo corrige. Cronología completa: T+0 alguien desactiva el cifrado, T+3 min Config crea el CI y evalúa NON_COMPLIANT, T+4 min la remediación ejecuta AWS-EnableS3BucketEncryption, T+8 min conforme otra vez. Sin intervención humana, con el rastro completo en CloudTrail. Y el cuadro de cumplimiento inicial encontró catorce recursos que llevaban meses incumpliendo sin que nada los detectara, porque no eran eventos: eran estados.

Y una sexta, que nadie había formulado y que aparece en esta lección: el ASG no puede pasar de cuatro instancias por una cuota de vCPU de la cuenta que nadie había mirado nunca. Ese es exactamente el tipo de problema que solo encuentra un repaso automático, y es el mejor argumento a favor de Trusted Advisor y de Service Quotas.

Puesto en contexto:

La observabilidad es el 9,9 % del gasto total. Es una proporción alta comparada con la seguridad, y merece la pena decir por qué es razonable: el 70 % de esa cifra son CloudWatch y el canario, es decir, la ingesta de registros y la comprobación continua de que se puede comprar. Y frente a lo que cuesta: la corrección del N+1 que encontró X-Ray por 10,60 USD al mes redujo a la mitad la presión sobre la base de datos, evitando una ampliación de instancia RDS que habría costado 80 USD mensuales. La observabilidad se pagó sola el primer mes.

Y las cinco decisiones que mantienen esa cifra en 62 USD en lugar de en 600:

1. Retención en cada grupo de registros el día que se crea (05-01).
2. Ninguna dimensión de cardinalidad alta en métricas personalizadas (05-01).
3. Muestreo de X-Ray al 0 % en /salud y estáticos, 100 % en pedidos (05-02).
4. Selectores de eventos de datos por prefijo y readOnly: false (05-03).
5. recordingFrequency: DAILY para instancias y volúmenes en Config (05-04).

Cinco líneas de configuración que separan 62 USD de más de 600.

1. Esperar que Trusted Advisor lo vea todo con el plan Basic. Con Basic ves seguridad básica y límites de servicio. Nada de coste, rendimiento ni tolerancia a fallos, y sin API.

2. Obedecer los amarillos sin criterio. Trusted Advisor no conoce tu contexto. Un volumen raíz de una instancia efímera no necesita instantáneas. Cada hallazgo es una hipótesis; documenta las que aceptas y por qué.

3. Ignorar la categoría de límites de servicio. Es la que más caídas ha causado, y es de las pocas disponibles en el plan gratuito. Reviéwala siempre.

4. Solicitar un aumento de cuota cuando ya estás chocando. Los aumentos grandes pasan a un caso de soporte y tardan días. Alarma al 70 % y pide con antelación.

5. Olvidar que las cuotas son por región. Subirla en eu-west-1 no la sube en eu-central-1. Si tienes plan de recuperación en otra región, súbela también allí.

6. No contar el despliegue azul/verde al calcular vCPU. Duplica temporalmente las instancias. Es la causa más frecuente de que un primer despliegue sin interrupción falle (08-03).

7. Confundir Trusted Advisor con Config. Config comprueba tus reglas y remedia; Trusted Advisor comprueba las de AWS y solo señala. El ciclo bueno es: Trusted Advisor descubre → Config convierte en regla → la remediación lo corrige.

8. Refrescar comprobaciones a mano constantemente. Se refrescan cada 24 horas solas. Refrescar manualmente antes de una revisión concreta está bien; hacerlo cada hora no aporta nada.

9. Contratar el plan Business solo por Trusted Advisor. Haz el cálculo: si el ahorro detectado no cubre el coste, la razón para contratarlo es el soporte técnico con SLA, no las comprobaciones. Decídelo con ese criterio.

10. Dejar que los hallazgos se acumulen. Un informe con 40 hallazgos permanentes deja de leerse. Resuélvelos, acéptalos formalmente con justificación, o quítalos del alcance. Un informe limpio es un informe que alguien mira.

11. No revisar las alarmas que dan falsos positivos. Una alarma ignorada es peor que no tener alarma. La revisión mensual incluye borrar alarmas, no solo crearlas.

12. Optimizar una instancia que no debería existir. Compute Optimizer recomienda reducir mercadofresco-tienda-01 a t3.small. La respuesta correcta es apagarla. Las herramientas optimizan lo que hay; la pregunta de si debe haberlo la hace una persona.

Consejo final del módulo: la observabilidad no se «termina». Se mantiene. El sistema que has montado en estas cinco lecciones se degrada solo si nadie lo cuida: aparecen alarmas ruidosas, registros sin retención, reglas no conformes que se normalizan, cuotas que se acercan. La hora mensual de la rutina de Marta es lo que mantiene vivo todo lo demás. Sin ella, en seis meses tienes un panel que nadie mira y un montón de servicios facturando.

MercadoFresco crece. Datos actuales:

Planes disponibles: Basic (0 USD), Developer (29 USD/mes o 3 % del gasto, lo que sea mayor), Business (100 USD/mes o del 3 al 10 % del gasto según tramos, lo que sea mayor).

Calcula el coste real de cada plan con ese gasto. Estima el coste de una caída de 95 minutos un viernes en hora punta. Decide qué plan contratarías, justificándolo con números y no solo con las comprobaciones de Trusted Advisor. Indica qué harías con lo que el plan elegido no cubre.

MercadoFresco espera para el Black Friday un pico de 5 veces el tráfico habitual durante 6 horas. Situación actual:

Además, el equipo quiere hacer un despliegue azul/verde la semana anterior para publicar la campaña.

Calcula: cuántas instancias hacen falta en el pico, cuántas vCPU, qué cuotas se quedan cortas y en cuánto. Escribe las solicitudes de aumento con los valores que pedirías y su justificación. Diseña las alarmas de cuota que montarías. Indica qué otros límites no de AWS revisarías, y con cuánta antelación harías cada cosa.

Es el primer lunes de octubre. Marta ejecuta su rutina y encuentra esto:

Seguridad

• Trusted Advisor: 1 rojo — «Grupos de seguridad: puertos específicos sin restricción».
• Config: 3 reglas no conformes (el mes pasado eran 0).
• validate-logs: falta un fichero de resumen del 14 de septiembre.
• Athena: 2.400 AccessDenied de rol-mercadofresco-tienda sobre s3:GetObject.

Coste

• Factura de CloudWatch: de 44 a 71 USD.
• 1 volumen EBS available de 200 GiB, creado el 22 de septiembre.
• Compute Optimizer: las instancias del ASG marcadas como under-provisioned.

Fiabilidad

• Cuota de vCPU al 75 %.
• El canario canario-mercadofresco-compra ha fallado 14 veces, todas entre las 03:00 y las 03:20.

Observabilidad

• La alarma mercadofresco-pedidos-fallidos ha saltado 23 veces este mes; 21 fueron falsos positivos.
• Una suscripción de SNS en PendingConfirmation: el correo de la persona nueva.

Para cada uno de los once hallazgos: di qué significa con toda probabilidad, qué prioridad le das (crítica, alta, media, baja), qué acción concreta tomarías, y de qué lección del curso procede el conocimiento necesario. Identifica cuáles de estos hallazgos están relacionados entre sí, que es la parte que distingue una revisión mecánica de una revisión útil.

Solución 1

Coste real de cada plan con 2.400 USD de gasto mensual:

Ojo con el cálculo de Developer y Business: es el mayor entre el mínimo y el porcentaje. Con 2.400 USD de gasto, Business cuesta 240 USD, no 100.

Coste de una caída de 95 minutos un viernes en hora punta:

Dos caídas al año ≈ 700-900 EUR de margen perdido, más el daño de imagen en una tienda de producto fresco, donde la confianza en la entrega en 24 h es el producto.

La decisión: Business, 240 USD/mes. Y la justificación no son las comprobaciones de Trusted Advisor:

El número que cierra la decisión: 240 USD/mes son 2.880 USD/año. Si el soporte con SLA reduce la duración de una sola caída de 95 a 30 minutos, se ahorran unos 240 EUR de margen. Con dos caídas al año, no llega a pagarse solo por eso.

Pero el equipo son tres personas, una guardia informal y ninguna posibilidad de escalar a nadie a las 4 de la madrugada. El argumento real es de riesgo, no de ahorro: con 185.000 EUR mensuales dependiendo de la plataforma, no tener a quién llamar cuando algo grave falle es un riesgo desproporcionado frente a 2.880 USD anuales. Es el mismo tipo de razonamiento que en 04-04 llevó a no contratar Shield Advanced —allí el coste era 100 veces mayor y el riesgo mucho menor—, aplicado en sentido contrario. La conclusión distinta con el mismo método es lo que demuestra que el método es bueno.

Lo que Business no cubre y hay que seguir haciendo:

Y una condición para que la decisión sea buena: contratar Business y no cambiar nada más sería tirar el dinero. La decisión incluye establecer turnos de guardia formales entre las tres personas, con el simulacro de set-alarm-state verificado para cada teléfono (05-01). El soporte de AWS responde en una hora; alguien de MercadoFresco tiene que estar despierto para leer esa respuesta.

Solución 2

Cálculo de capacidad.

El margen del 50 % no es paranoia: el número de 600 pedidos/hora por instancia se midió en condiciones normales. En el Black Friday el carrito medio es más grande, hay más búsquedas por pedido y más abandonos con reintentos. La capacidad por instancia bajará, no subirá.

Cuotas que se quedan cortas:

Solicitudes de aumento:

Justificación para el caso de soporte, si escala: «Tienda de comercio electrónico de alimentación. Campaña de Black Friday con pico previsto de 5× el tráfico habitual durante 6 horas el 27 de noviembre. Necesitamos escalar el grupo de autoescalado a 12 instancias t3.large y realizar un despliegue azul/verde previo que duplica temporalmente la capacidad. Solicitamos 64 vCPU con margen.»

La fila más importante de la tabla de cuotas es la que no es una cuota de AWS: las conexiones de RDS. Con 12 instancias × 40 conexiones de agrupación = 480 conexiones, contra un max_connections de 200. La base de datos se convierte en el cuello de botella antes que EC2. Y esa no se arregla con una solicitud a AWS: se arregla con arquitectura.

Otros límites que no son cuotas de AWS y que hay que revisar:

La quinta fila es la que un perfil técnico olvida y la que más caro sale: escalar la tienda para aceptar 4.500 pedidos/hora que el almacén no puede preparar convierte un éxito comercial en una catástrofe de servicio al cliente. El límite real de MercadoFresco puede estar en la nave, no en AWS.

Alarmas de cuota a montar:

La tercera es especialmente astuta: instancias atascadas en Pending durante 15 minutos es exactamente lo que se ve cuando los lanzamientos fallan por cuota.

Cronograma, con antelación realista:

La prueba de carga de la cuarta fila es lo que convierte todo lo anterior en un plan y no en una esperanza. Si no lo has probado, no sabes si escala.

Solución 3

Hallazgos, con prioridad y relaciones.

El hallazgo 3 es el más grave de todos y hay que decir por qué. Un fichero de resumen ausente significa que la cadena de integridad de CloudTrail está rota el 14 de septiembre. Puede ser un problema de entrega de AWS —ocurre, raramente— o puede significar que alguien borró ficheros de registro para ocultar actividad. No se puede distinguir sin investigar, y hasta que se descarte hay que tratarlo como un posible incidente de seguridad:

Si el Object Lock en modo COMPLIANCE de 05-04 estaba activo, nadie pudo borrar nada y la explicación es un problema de entrega de AWS: se abre un caso de soporte y se documenta. Si no lo estaba, hay que investigar en serio. Esta es la mejor demostración práctica de por qué Object Lock importaba.

Relaciones entre hallazgos, que es la parte que distingue una revisión útil:

Grupo A: hallazgos 1, 2 y 3 — probablemente el mismo incidente.

Tres reglas de Config que pasaron de conformes a no conformes, un puerto abierto, y un hueco en la auditoría. Es demasiada coincidencia. La línea temporal de Config dirá exactamente cuándo se volvieron no conformes las reglas, y si esa fecha es el 14 de septiembre, ya no es una coincidencia: es un incidente que hay que reconstruir entero.

Grupo B: hallazgos 4 y 5 — el mismo despliegue.

2.400 AccessDenied sobre s3:GetObject significa que hay una funcionalidad rota que ningún cliente ha reportado. Y cada fallo genera una línea de error en el log, lo que explica en buena parte el aumento de CloudWatch de 44 a 71 USD. Un problema de permisos se manifestó como un problema de coste. Arreglar el permiso arregla las dos cosas.

Grupo C: hallazgos 7 y 8 — el mismo problema de capacidad.

Compute Optimizer dice que las instancias se quedan cortas, y la cuota de vCPU está al 75 %. Son las dos caras de lo mismo: MercadoFresco ha crecido y la capacidad no ha seguido. Y hay una trampa: si se resuelve el 7 escalando a más instancias, se agrava el 8. La secuencia correcta es primero solicitar el aumento de cuota, después escalar. Al revés, el ASG intentará lanzar y fallará.

Grupo D: hallazgos 9 y 6 — la ventana de mantenimiento.

El canario falla entre las 03:00 y las 03:20. ¿Qué pasa a esa hora? La ventana de mantenimiento de RDS y la de copias automáticas (02-04). Durante una conmutación Multi-AZ hay unos segundos de indisponibilidad, y el canario lo detecta. Y esto es una buena noticia disfrazada de problema: el canario está funcionando y está midiendo un impacto real que los clientes también sufren, aunque de madrugada afecte a poca gente. Acciones: comprobar si la aplicación reintenta correctamente las conexiones perdidas (patrón de 07-05), y valorar mover la ventana a una hora con menos tráfico aún.

El volumen huérfano del 22 de septiembre probablemente venga de una instancia terminada en ese mismo trabajo de mantenimiento.

Grupo E: hallazgos 10 y 11 — la salud del sistema de avisos, y son los más urgentes de lo que parece poco urgente.

• 21 falsos positivos de 23 significa que mercadofresco-pedidos-fallidos ya no la mira nadie. Su umbral fijo de 10 errores en 5 minutos no aguanta el crecimiento del tráfico: con más pedidos hay más errores absolutos aunque la proporción sea la misma. La corrección es la de la solución 1 de 05-01: alarmar sobre el porcentaje, no sobre el número absoluto, con una expresión de métrica.
• La suscripción pendiente significa que la persona nueva no ha recibido ni un solo aviso desde que entró. Si estaba de guardia alguna noche, no había nadie de guardia. Se reenvía la confirmación y se hace un simulacro con set-alarm-state contra su teléfono, que es exactamente el protocolo de incorporación de 05-01.

Orden de actuación recomendado:

La lección del ejercicio: once hallazgos aislados parecen una lista de tareas. Agrupados en cinco grupos relacionados, son cinco problemas reales: un posible incidente de seguridad, un despliegue con permisos incompletos, un problema de capacidad con una trampa de orden, una ventana de mantenimiento con impacto medible, y un sistema de avisos que se ha degradado en silencio. Esa diferencia es exactamente lo que aporta que la revisión la haga una persona con contexto y no un informe automático.

MercadoFresco tiene la última pieza. Sabes qué es Trusted Advisor y en qué se diferencia de todo lo anterior: Config comprueba tus reglas, Trusted Advisor comprueba las de AWS; Config responde preguntas, Trusted Advisor las hace. Y sabes que el ciclo bueno es encadenarlos: Trusted Advisor descubre lo que no habías previsto, escribes una regla de Config para que no vuelva, y la remediación lo corrige sola. Frente a Well-Architected (11-01), la distinción es de altura: Trusted Advisor mira hacia abajo, a los recursos; Well-Architected mira hacia arriba, a las decisiones.

Conoces las cinco categorías —optimización de costes, rendimiento, seguridad, tolerancia a fallos y límites de servicio— y qué comprueba cada una, con los tres estados y la advertencia de que un amarillo es una hipótesis, no una orden: los volúmenes raíz de las instancias del ASG no necesitan instantáneas, y aceptar formalmente ese hallazgo con su justificación es la respuesta correcta.

Tienes la tabla honesta de qué ve MercadoFresco con el plan Basic: seguridad básica y límites de servicio, que no es poco, y nada de coste, rendimiento, tolerancia a fallos ni API. Y sabes suplir lo que falta con lo ya aprendido: los volúmenes huérfanos con una consulta avanzada de Config, las IP elásticas con describe-addresses, los balanceadores inactivos con RequestCount, las instancias infrautilizadas con Compute Optimizer, el Multi-AZ con una regla de Config. Casi todo lo que daría el plan Business, gratis. Lo que no se puede reproducir es el soporte técnico con SLA, y esa es la razón real por la que se contrata.

Has recorrido un informe completo de la arquitectura de MercadoFresco y has encontrado lo que llevaba meses ahí: 3 volúmenes EBS huérfanos de las pruebas de 02-01, 2 IP elásticas sin asociar que se facturan precisamente por no usarse y que además consumían 2 de las 5 plazas de la cuota, mercadofresco-tienda-01 al 4 % de CPU desde que montamos el ASG y que nadie apagó, el mismo puerto 22 abierto que ya había señalado Config —dos herramientas independientes confirmándose—, y el hallazgo de compresión de CloudFront que se arregla con una casilla.

Y has descubierto la cuota que nadie había mirado: asg-mercadofresco-tienda no puede pasar de cuatro instancias porque la cuota de vCPU de la cuenta es 16 y otras cargas consumen 8. El máximo del ASG no era una decisión de diseño: era un límite invisible. Un fallo latente perfecto, que se manifestaría exactamente en el peor momento —el viernes en que hiciera falta escalar— y que no aparecería en ninguna alarma de CloudWatch, ninguna regla de Config ni ninguna traza de X-Ray. Sabes gestionar Service Quotas: ver el uso, solicitar aumentos con antelación porque los grandes tardan días, recordar que son por región, contar el despliegue azul/verde que duplica las instancias, y sobre todo alarmar al 70 % con SERVICE_QUOTA(), la función que hace que la alarma se recalibre sola cuando la cuota cambie. Dos alarmas, 0,20 USD al mes, para no quedarte sin escalar un viernes.

Conoces la API de Trusted Advisor (Business, y solo en us-east-1, el mismo patrón de ACM y las Web ACL de CloudFront), la exportación de recomendaciones a CSV, las notificaciones semanales a los contactos alternativos de 01-02, y la integración con EventBridge (07-03) que permite no solo notificar sino actuar —desactivar automáticamente una clave de acceso que ha aparecido en un repositorio público—. Y sabes dónde encajan Compute Optimizer y Cost Optimization Hub, con la advertencia que resume la relación entre herramientas y personas: Compute Optimizer recomienda reducir mercadofresco-tienda-01 a t3.small; la respuesta correcta es apagarla. Las herramientas optimizan lo que hay; la pregunta de si debe haberlo la hace una persona.

Y tienes la rutina mensual de Marta: una hora, el primer lunes, con su lista de comprobación de seguridad, coste, fiabilidad, observabilidad y deuda técnica. Con el punto que más se salta y más importa: revisar las alarmas que dieron falsos positivos y borrarlas o recalibrarlas, porque una alarma que se ignora es peor que no tener alarma.

Con esto se cierra el módulo 5. La capa de observabilidad de MercadoFresco está completa: métricas y paneles con mercadofresco-produccion, MercadoFresco/Tienda y trece alarmas verificadas con simulacro; trazas de extremo a extremo con muestreo al 100 % en los pedidos y al 0 % en el health check; auditoría inalterable en trail-mercadofresco con siete años de retención y consultas SQL sobre cada llamada a la API; cumplimiento continuo con 29 reglas de Config y remediación automática que restaura el cifrado de un bucket en ocho minutos; y el repaso automático que encuentra lo que a nadie se le ocurrió preguntar. Las cinco preguntas del módulo 4 tienen respuesta —el aviso llega, los registros se correlacionan, el pedido de ocho segundos era un N+1, la copia la descifró Luis probando una restauración de madrugada, y el cifrado se restaura solo— y por 62,47 USD al mes, el 9,9 % de la factura, con cinco líneas de configuración separando esa cifra de más de 600.

Y ahora, con la casa por fin vigilada, la vigilancia empieza a enseñar algo incómodo. El panel de Marta lo lleva diciendo desde que lo montamos, y los datos de este módulo lo confirman desde tres ángulos distintos: el siguiente cuello de botella es la base de datos.

mercadofresco-pedidos es una única instancia de PostgreSQL que lo hace todo, y lo hace mal por razones distintas en cada caso. El carrito castiga una tabla de sesiones con escrituras constantes de datos que no tienen ninguna necesidad de ser transaccionales ni de vivir para siempre. Los informes de Sara, con sus agregaciones sobre meses de historia, bloquean la producción cuando los ejecuta en horas de trabajo —y la réplica de lectura solo desplaza el problema, no lo resuelve—. El catálogo se consulta miles de veces por minuto para devolver siempre lo mismo: precios y descripciones que cambian una vez al día. Y el propio X-Ray enseñó que incluso después de corregir el N+1, la latencia de la tienda sigue dominada por consultas a la base de datos.

Todo eso está en una sola instancia porque, cuando empezamos en 02-04, PostgreSQL era la respuesta obvia. Y lo era. Pero una base de datos relacional no es la herramienta correcta para todos los trabajos, y forzarla a serlo es la causa más común de arquitecturas que no escalan.

En el módulo 6, «Bases de datos», empezando por 06-01, «Cómo elegir la base de datos adecuada», veremos el modelo de decisión: relacional frente a clave-valor, documental, en memoria, de series temporales y de grafos, con los criterios reales —patrón de acceso, consistencia, latencia, volumen y coste— para elegir cada una. Después DynamoDB para la tabla de sesiones y el carrito, Aurora como la evolución natural de PostgreSQL cuando hace falta más, Redshift para que los informes de Sara dejen de tocar producción, y ElastiCache para que el catálogo se sirva desde memoria en microsegundos. Y todo ello con la ventaja de que, por primera vez en el curso, cada cambio que hagamos se podrá medir: tenemos las métricas, las trazas y los paneles para demostrar si una decisión de arquitectura fue buena o no.