La lección anterior dejó la factura de MercadoFresco en 1.749,60 USD al mes, un 22 % por debajo del punto de partida, y con un análisis capaz de explicar cada línea. Pero todo eso es mirar hacia atrás. Si mañana alguien levanta un clúster de pruebas en la cuenta de desarrollo y se olvida, o si una consulta nueva se dispara un viernes por la noche, la factura crecerá sin que nada se interponga en el camino. Nadie ha puesto todavía un límite.

Esta lección pasa de analizar a controlar. Verás la diferencia entre Cost Explorer y Budgets y por qué la alarma de facturación de 01-02 se queda corta, los cuatro tipos de presupuesto y sus periodicidades —incluidos los planificados para la campaña de Navidad—, la distinción entre umbrales sobre coste real y previsto, los presupuestos concretos que crea MercadoFresco por cuenta, servicio, etiqueta y categoría de coste, su creación por consola, CLI y CDK, las notificaciones, y la parte con dientes: las acciones de presupuesto capaces de congelar la cuenta de desarrollo cuando alcanza su límite. Al final, la rutina FinOps que sostiene todo el ciclo.

Aviso de coste. Los dos primeros presupuestos son gratuitos; a partir de ahí cuestan 0,02 USD por presupuesto y día, es decir, unos 0,60 USD al mes cada uno. Los diez presupuestos de MercadoFresco cuestan alrededor de 4,80 USD mensuales, un 0,27 % de la factura, que es probablemente el mejor seguro del catálogo. Las acciones de presupuesto cuestan aparte, unos 0,10 USD por acción y día. Datos, cuentas e identificadores ficticios.

1. Analizar frente a controlar
2. Por qué la alarma de facturación de 01-02 se queda corta
3. Los cuatro tipos de presupuesto
4. Periodicidad: fijos, recurrentes y planificados
5. Coste real frente a coste previsto
6. Umbrales escalonados y a quién avisa cada uno
7. Los presupuestos de MercadoFresco
8. Crear un presupuesto por consola, CLI y CDK
9. El JSON completo, comentado
10. Notificaciones: correo, SNS y Slack
11. Acciones de presupuesto
12. La cuenta de desarrollo que se congela sola
13. La advertencia sobre producción
14. Informes de presupuestos y revisión mensual
15. Buenas prácticas
16. Cuando un presupuesto se supera por una razón legítima
17. FinOps: informar, optimizar y operar
18. La reunión mensual de coste
19. Errores comunes y consejos
20. Ejercicios
21. Conclusión

Las dos herramientas se parecen en la pantalla y son radicalmente distintas en su propósito:

La diferencia práctica es sencilla: Cost Explorer requiere que alguien se acuerde de mirar; Budgets no requiere que nadie haga nada. Y en una empresa de tres personas, todo lo que requiere que alguien se acuerde acaba fallando algún mes.

Conviene también situarlo frente a la detección de anomalías de 11-03, con la que se confunde:

• Detección de anomalías: «este gasto no se parece a tu patrón habitual». Es estadística, no tiene opinión sobre si puedes permitírtelo.
• Budgets: «has superado el límite que tú mismo pusiste». Es una decisión de negocio expresada en un número.

Ambas son necesarias y responden a casos distintos. Una subida gradual del 3 % mensual durante seis meses no dispara ninguna anomalía —es perfectamente normal mes a mes— y sí acaba reventando el presupuesto. Un pico de un día dispara la anomalía y probablemente no mueva el presupuesto mensual.

En la lección 01-02, con la cuenta recién creada, se configuró una alarma de facturación de CloudWatch sobre la métrica EstimatedCharges con un umbral de 10 USD, y también el presupuesto presupuesto-mensual-mercadofresco con el mismo importe. Aquello fue lo correcto entonces y hoy es inútil, por cinco razones:

1. El importe está obsoleto. Lleva veintitantos meses saltando el día 2 de cada mes. Una alarma que siempre está en rojo no es una alarma: es ruido, y ya nadie lee sus correos.
2. Es global. Un solo número para toda la organización no dice dónde está el problema.
3. Solo mira coste real. Se entera cuando ya se ha gastado, no cuando se va a gastar.
4. La métrica EstimatedCharges solo existe en us-east-1 y es de la cuenta de gestión: no permite vigilar una cuenta miembro por separado.
5. No puede hacer nada. Notifica y punto.

La primera acción de esta lección es, por tanto, jubilar aquel presupuesto: subir su importe al valor real y convertirlo en el presupuesto global de la organización. No se borra —conserva el histórico— pero deja de ser un vestigio.

Los dos primeros son los que se usan a diario. Los dos últimos existen porque un compromiso mal aprovechado es dinero perdido de forma silenciosa, y se vuelven imprescindibles a partir de 11-05.

El presupuesto de uso es el menos conocido y resuelve un problema que el de coste no ve: si el precio de un servicio baja, un presupuesto de coste deja de avisar aunque el consumo se haya disparado. MercadoFresco lo usa para los NAT Gateway, donde el volumen de datos procesados es un indicador de salud de la arquitectura además de un coste.

El presupuesto planificado es el que resuelve el problema real de MercadoFresco: en diciembre, la campaña de Navidad multiplica los pedidos y con ellos el gasto. Con un presupuesto mensual recurrente de 2.000 USD, diciembre dispara todos los umbrales y el equipo aprende a ignorarlos justo en el mes en el que más atención hace falta.

El presupuesto planificado de MercadoFresco:

Y con esto se gana algo más valioso que un aviso bien calibrado: la conversación de noviembre. Ponerle un número a diciembre obliga a estimarlo, y estimarlo obliga a hablar con negocio sobre cuántos pedidos se esperan. Un presupuesto es, antes que un control, un ejercicio de previsión.

Cada umbral de un presupuesto se puede evaluar contra dos cosas distintas, y hay que configurar las dos:

El ejemplo que lo aclara. Un presupuesto de desarrollo de 170 USD mensuales:

• El día 9, se han gastado 51 USD. El umbral real del 80 % (136 USD) no dispara: falta mucho.
• Ese mismo día, la previsión de fin de mes es de 170 USD, porque el ritmo diario ha subido desde el día 6. El umbral previsto del 100 % sí dispara.
• Quedan 21 días para corregir. Esa es toda la diferencia entre enterarse a tiempo y enterarse tarde.

Dos advertencias sobre el previsto, que no es magia:

1. Necesita historial. Un presupuesto recién creado, o una cuenta nueva, no genera previsiones fiables durante las primeras semanas. AWS necesita del orden de cinco semanas de datos.
2. Extrapola. Si el día 3 se hizo una migración puntual que consumió mucho, la previsión creerá que eso se repite todo el mes y disparará una falsa alarma. Se aprende a reconocerlas.

La configuración estándar de MercadoFresco combina ambos: previsto al 80 % y al 100 % para anticipar, real al 100 % para constatar, y en el caso de desarrollo, real al 100 % con acción automática.

Un presupuesto con un solo umbral al 100 % avisa cuando ya no se puede hacer nada. Uno con cinco umbrales genera tanto ruido que se ignoran todos. Tres es el número que funciona:

La lógica del escalado tiene un principio detrás: cada umbral debe tener un destinatario distinto y una acción esperada distinta. Si el 50 % y el 80 % avisan a las mismas personas para que hagan lo mismo, uno de los dos sobra. Y el 50 % de MercadoFresco no envía correo a nadie a propósito: alcanzar la mitad del presupuesto a mitad de mes es exactamente lo que debe ocurrir.

Diez presupuestos, todos coherentes con la factura de 1.749,60 USD posterior a las optimizaciones de 11-03:

Cuatro decisiones de diseño de esta tabla merecen explicación:

El margen sobre el gasto actual es de entre el 10 y el 20 %. Ni pegado —dispararía cada mes por variaciones normales— ni holgado —no avisaría nunca—. La regla de MercadoFresco: el presupuesto se fija un 15 % por encima del gasto real de los tres últimos meses, y se revisa cada trimestre.

La suma de los presupuestos por cuenta (1.985 USD) es menor que el global (2.000 USD). Es intencionado: si todos los entornos se acercan a su límite a la vez, el global también avisa. Al revés —presupuestos por equipo que suman más que el global— es el error clásico que hace que nadie se dé nunca por aludido.

Desarrollo es el más estricto y el único con acción. Su margen es del 18 % pero su umbral de acción es el coste real al 100 %, no el previsto, para no congelar la cuenta por una previsión equivocada. Es el entorno donde un error cuesta poco corregirlo y donde más experimentos se hacen.

Hay presupuestos que se solapan a propósito. El de analitica cruza cuentas y el de CloudWatch cruza servicios: ambos capturan gasto que ya está contado en los presupuestos por cuenta. No pasa nada por contar dos veces cuando la finalidad es vigilar dos dimensiones distintas. Lo que no se debe hacer es sumarlos.

Por consola, en Billing → Budgets → Create budget, el flujo es: plantilla o personalizado → tipo → periodicidad e importe → filtros (cuenta, servicio, etiqueta, categoría) → umbrales y destinatarios → acciones. Es cómodo para el primero y desaconsejable para los diez: un presupuesto creado a mano no está en Git, no se revisa por pull request y desaparece si alguien lo borra.

Por CLI, con dos ficheros JSON:

Por CDK, que es como MercadoFresco los mantiene de verdad, en el repositorio mercadofresco-infra:

Tres detalles del código que evitan errores frecuentes:

• TagKeyValue con el formato user:Clave$Valor. Ese $ como separador y el prefijo user: son obligatorios y no aparecen en el sitio más obvio de la documentación. Con la sintaxis mal escrita, el presupuesto se crea sin error y filtra a cero, con lo que nunca avisa.
• include_tax=False e include_credit=False. Coherente con la decisión de 11-03: el número de trabajo es el coste de servicios. Con los impuestos incluidos, un presupuesto de 2.000 USD saltaría con 1.653 USD de gasto real y nadie sabría por qué.
• use_amortized=True. Hoy no cambia nada porque no hay compromisos, pero a partir de 11-05 sí: sin amortizar, el mes en que se pague un Savings Plan por adelantado dispararía todos los umbrales de golpe.

El equivalente por CLI del presupuesto de desarrollo, que es el más completo porque incluye acción:

Y el fichero de avisos, que es un fichero aparte y no una propiedad del anterior:

Los campos que importan:

• ThresholdType admite PERCENTAGE o ABSOLUTE_VALUE. El porcentaje sobrevive a los cambios de importe del presupuesto; el absoluto hay que actualizarlo a mano y se olvida.
• ComparisonOperator admite GREATER_THAN, LESS_THAN y EQUAL_TO. El LESS_THAN tiene un uso legítimo poco conocido: avisar de que la utilización de un Savings Plan ha bajado de un mínimo, que es justo lo que hará falta en 11-05.
• IncludeSupport: true y IncludeSubscription: true se dejan activos: la cuota de soporte y las suscripciones son gasto real que hay que controlar, a diferencia de los impuestos.
• Se pueden mezclar destinatarios SNS y correo en el mismo umbral. Diez suscriptores como máximo por notificación.

Tres canales, con papeles distintos:

Para que Budgets pueda publicar en el tema alertas-mercadofresco hace falta autorizarlo explícitamente en la política del tema, y es el paso que más veces se olvida:

Las condiciones aws:SourceAccount y aws:SourceArn no son adorno: sin ellas, cualquier presupuesto de cualquier cuenta de AWS podría publicar en ese tema. Es el patrón de protección contra el «suplente confuso» que ya se vio en 04-01.

El resultado en Slack, a través del canal #mercadofresco-alertas que el equipo ya usa desde el módulo 5, tiene una ventaja añadida sobre el correo: es público dentro del equipo. Un aviso que ve todo el mundo se atiende; uno que llega a una bandeja de entrada compartida, no.

Aquí Budgets deja de ser un sistema de avisos y pasa a ser un control. Una acción de presupuesto (Budget Action) se ejecuta cuando se alcanza un umbral y puede hacer tres cosas:

Y en dos modos:

• Automático (AUTOMATIC): se ejecuta sola al alcanzar el umbral.
• Manual (MANUAL): notifica y espera a que una persona autorizada la apruebe desde la consola.

La regla que gobierna la elección es sencilla y no admite excepciones cómodas: automático solo donde el peor caso sea una molestia; manual donde el peor caso sea un incidente.

El caso concreto de MercadoFresco: la cuenta 333344445555 tiene un presupuesto de 170 USD y, al alcanzar el 100 % de coste real, se le adjunta automáticamente una SCP que impide crear recursos nuevos.

La política que se aplica:

Y su configuración como acción:

Las decisiones que hacen que esto sea seguro y no una bomba:

• Solo se deniega la creación de recursos caros. Lo que ya está funcionando sigue funcionando: nadie pierde su trabajo en curso. Se puede seguir desplegando código, leyendo registros y consultando bases de datos. Lo único que no se puede es encender algo nuevo y caro.
• Se dispara con coste real, no previsto. Congelar una cuenta por una previsión equivocada sería inaceptable incluso en desarrollo.
• La SCP se aplica solo a la cuenta 333344445555, no a la OU entera. Un error en el TargetIds que apuntara a la OU Cargas congelaría también producción, y ese es exactamente el tipo de accidente que hay que diseñar para que no pueda ocurrir.
• El rol de ejecución tiene permisos mínimos: solo organizations:AttachPolicy sobre esa política y esa cuenta.
• Hay un procedimiento de desbloqueo escrito en mercadofresco-infra/docs/runbooks/, con quién puede ejecutarlo (Marta) y qué se documenta después. Una acción automática sin procedimiento de reversión documentado es una trampa para el equipo.

El efecto real observado el primer mes: el día 24 de septiembre, la cuenta llegó a 170 USD porque Luis había levantado un clúster de EKS para el ejercicio de 10-03 y lo dejó encendido un fin de semana. La SCP se aplicó, Luis vio el aviso en Slack, borró el clúster y Marta quitó la SCP en diez minutos. Coste del incidente: unos 40 USD. Sin el presupuesto, el clúster habría seguido encendido hasta la revisión mensual: unos 220 USD.

Conviene decirlo con toda claridad porque es el error más grave que se puede cometer con esta herramienta:

No apliques nunca una acción automática restrictiva a la cuenta de producción sin entender exactamente qué se rompe.

El escenario que lo explica: un viernes de campaña, los pedidos se disparan, el gasto sube y el presupuesto de producción llega al 100 %. La acción automática deniega ecs:CreateService y elasticloadbalancing:CreateLoadBalancer. Hasta ahí, quizá inofensivo. Pero si la política incluyera ec2:RunInstances o cualquier acción que use el autoescalado, el sistema no podría escalar precisamente en el momento en que más falta hace, y una decisión de ahorro de 300 USD provocaría una caída que cuesta mucho más que eso.

Por eso el presupuesto pres-mf-produccion de MercadoFresco:

• No tiene ninguna acción automática. Ninguna.
• Tiene una acción manual de solo notificación reforzada al 120 %, que exige aprobación explícita y que en la práctica es un recordatorio de que hay que mirar.
• Su margen es mayor que el del resto, porque un mes bueno de ventas debe caber dentro sin generar alarma.

Y el principio general que se deriva: el control de costes nunca debe poder degradar el servicio a los clientes. Un presupuesto superado se corrige con una decisión, no con un corte automático.

AWS Budgets Reports permite programar un informe periódico —diario, semanal o mensual— con el estado de hasta 50 presupuestos, enviado por correo a un máximo de 50 destinatarios. Cuesta 0,01 USD por informe enviado.

MercadoFresco tiene uno:

Su función no es informar —el equipo ya recibe avisos en Slack— sino abrir la reunión mensual con un documento común. Que las cuatro personas hayan visto el mismo PDF antes de sentarse ahorra los primeros quince minutos de toda reunión de costes.

Las siete reglas que MercadoFresco escribe en su documento de gestión de costes:

1. Un presupuesto por unidad con dueño, no solo uno global. Un presupuesto global avisa de que hay un problema; uno por cuenta o por componente avisa de dónde está. El global sin los específicos es casi inútil.
2. Márgenes del 10 al 20 % sobre el gasto real de los últimos tres meses. Pegado genera falsas alarmas; holgado no avisa nunca.
3. Revisión trimestral de todos los importes, coincidiendo con la revisión de un pilar de Well-Architected. Un presupuesto que lleva un año sin tocarse está mal, tanto si sobra como si falta.
4. Umbrales previstos para actuar, reales para constatar. Siempre los dos.
5. Todo en código. Los diez presupuestos viven en mercadofresco-infra y se despliegan con el pipeline. Uno creado a mano en la consola desaparece sin dejar rastro cuando alguien lo borra.
6. Acciones automáticas solo donde el peor caso sea una molestia. Desarrollo sí, preproducción quizá, producción nunca.
7. Un presupuesto superado siempre genera una línea escrita, aunque la conclusión sea «es normal, subimos el importe». Sin ese registro, en seis meses nadie recordará por qué el presupuesto vale lo que vale.

Es el caso más común y el peor gestionado. El negocio crece, los pedidos suben un 35 %, la factura sube un 20 % y el presupuesto salta. No hay ningún error, ningún recurso olvidado y ninguna ineficiencia: simplemente el número era de antes.

El procedimiento de MercadoFresco, en cuatro pasos:

1. Comprobar el coste unitario antes que el total. Si el coste por pedido ha bajado o se ha mantenido, el crecimiento es sano y la conversación es otra. Si ha subido, hay algo más que crecimiento.
2. Identificar la causa concreta. «Han subido los pedidos» no basta; hace falta ver qué líneas de la factura han crecido y comprobar que crecen las que deben —Fargate, Aurora, colas— y no las que no deberían —registros, transferencia, huérfanos—.
3. Decidir explícitamente: subir el presupuesto, optimizar, o ambas cosas. La decisión la toma quien es dueño del presupuesto, no quien lo vigila.
4. Documentar el cambio de importe con su fecha y su motivo en el mismo repositorio donde vive el presupuesto. El commit es el registro.

Lo que no se debe hacer, y se hace constantemente: subir el importe en la consola sin decírselo a nadie. Al cabo de un año, nadie sabe por qué el presupuesto de producción es de 3.400 USD ni quién lo decidió, y el número ha dejado de significar nada.

Todo lo visto en las tres últimas lecciones tiene un nombre en la industria: FinOps, la disciplina de gestionar el gasto en la nube como una responsabilidad compartida entre tecnología, finanzas y negocio. Su modelo tiene tres fases que se repiten en ciclo:

Los tres principios que sostienen el modelo y que conviene no perder de vista:

• Los equipos son dueños de su gasto. No hay una persona que controla el dinero de todos: hay información repartida y responsabilidad local. Por eso el reparto por Propietario de 11-02 importa.
• Las decisiones se toman sobre valor de negocio, no sobre coste absoluto. Gastar más puede ser la decisión correcta. La pregunta nunca es «¿cómo gastamos menos?» sino «¿estamos obteniendo valor por lo que gastamos?».
• Un equipo central habilita, no controla. En MercadoFresco ese equipo es Marta con dos horas al mes. En una empresa grande sería un equipo, pero su papel es el mismo: dar herramientas y contexto, no aprobar gastos.

Quién participa, en una empresa de tres personas:

Marta instaura una reunión de 30 minutos, el día 5 de cada mes, con un guion fijo:

Las tres reglas que hacen que la reunión sobreviva más de tres meses:

1. Empieza por el coste unitario, no por el total. Cambia el tono de la conversación de «gastamos mucho» a «gastamos bien o mal».
2. Una sola acción al mes. Doce acciones ejecutadas al año valen más que cuarenta abandonadas.
3. Nadie se lleva una sorpresa en público. Si el gasto de alguien se ha disparado, se habla antes. Una reunión de costes que se convierte en un tribunal deja de celebrarse.

Error: un único presupuesto global. Avisa de que hay un problema y no dice dónde. Consejo: uno por cuenta como mínimo, y uno por componente crítico. El global es el techo, no el instrumento.

Error: presupuestos por equipo que suman más que el global. Cada uno cree ir bien y el total se dispara sin que nadie se dé por aludido. Consejo: la suma de los específicos debe quedar por debajo del global, dejando margen.

Error: usar solo umbrales sobre coste real. Te enteras cuando ya no se puede hacer nada. Consejo: previsto al 80 % y al 100 % para anticipar, real al 100 % para constatar.

Error: dejar el presupuesto de 10 USD de la primera lección. Salta cada día 2, se ignora, y con él se ignoran todos los demás avisos del mismo canal. Consejo: un presupuesto que siempre está en rojo hace daño activo. Actualízalo o quítalo.

Error: incluir impuestos y créditos en el importe. El presupuesto salta con un gasto real muy inferior y nadie entiende por qué. Consejo: IncludeTax=false e IncludeCredit=false, coherente con el análisis de 11-03.

Error: escribir mal el filtro por etiqueta. El formato es user:Clave$Valor; con otra sintaxis el presupuesto se crea sin error y filtra a cero, de modo que nunca avisa. Consejo: después de crearlo, comprueba en la consola que muestra un gasto actual distinto de cero.

Error: acción automática en producción. Un viernes de campaña, la política deniega el escalado justo cuando hace falta. Consejo: producción nunca; y si algún día se hace, que la política no toque nada que use el autoescalado.

Error: olvidar la política del tema SNS. El presupuesto se crea, los umbrales se alcanzan y no llega nada. Consejo: añade el permiso a budgets.amazonaws.com con aws:SourceAccount, y prueba el aviso creando temporalmente un presupuesto de 0,01 USD.

Error: subir el importe en la consola cuando salta. A los seis meses nadie sabe por qué el presupuesto vale lo que vale. Consejo: el importe vive en el CDK; cambiarlo es un commit con su motivo.

Consejo: crea el presupuesto antes de crear los recursos. Un presupuesto es un límite acordado, no un resumen a posteriori. Cuando se abra un entorno nuevo, lo primero que se despliega es su presupuesto.

Consejo: usa un presupuesto de uso para lo que no quieres que crezca, aunque sea barato hoy: GB por el NAT, GB ingeridos en CloudWatch, peticiones a la API de Cost Explorer. El coste puede bajar de precio; el consumo desbocado sigue siendo un síntoma.

Una empresa ficticia, RopaCircular, vende ropa de segunda mano. Tiene tres cuentas —producción (2.800 USD/mes), preproducción (600 USD/mes) y datos (900 USD/mes)— y un equipo de ocho personas. En noviembre, el Black Friday multiplica sus ventas por tres. El gerente ha pedido «que no se nos vaya de las manos» y ha dado un techo anual.

1. Propón el conjunto de presupuestos con sus importes, tipos y periodicidades.
2. Indica qué umbrales pondrías en cada uno y a quién avisarían.
3. ¿En qué cuenta pondrías una acción automática y con qué política exacta?
4. ¿Cómo tratarías noviembre?

El día 11 de octubre llega este aviso a alertas-mercadofresco:

1. ¿Es motivo de alarma? Razónalo con los datos disponibles.
2. Enumera tres comprobaciones que harías, en orden.
3. Si resulta que los pedidos de octubre van un 22 % por encima de septiembre, ¿qué decisión tomarías y qué documentarías?

Te piden aplicar una acción automática a la cuenta de preproducción 222233334444, con presupuesto de 290 USD, para evitar que se dispare como pasó una vez en desarrollo.

1. Escribe la política que aplicarías, justificando qué incluyes y qué dejas fuera.
2. Elige entre umbral real o previsto y entre modo automático o manual, justificando.
3. Enumera tres cosas que podrían salir mal y cómo las mitigarías.

Solución al ejercicio 1

(1) Conjunto de presupuestos propuesto:

Cinco presupuestos con márgenes de entre el 14 % y el 17 %. La suma de los tres por cuenta (4.950 USD) queda ligeramente por encima del global de 4.800, lo que en este caso es aceptable porque el global es planificado y actúa como techo mensual; si se quiere el patrón estricto, se sube el global a 5.200.

El rc-anual merece un comentario aparte: es el que traduce literalmente lo que ha pedido el gerente. Un presupuesto anual acumula todo el ejercicio y avisa cuando la suma de los meses transcurridos apunta a superar el techo. Es el único que responde a la pregunta «¿vamos a cumplir el año?», que ningún presupuesto mensual puede responder.

(2) Umbrales y destinatarios:

Nótese que el anual usa umbrales reales y más bajos: con un horizonte de doce meses, alcanzar el 75 % en septiembre ya es una señal accionable.

(3) Acción automática: solo en preproducción, y con esta política:

Se deniega crear recursos caros y no se toca nada de lo existente. En producción no se pone ninguna acción, por la razón de siempre: el peor caso es una caída durante el Black Friday, que cuesta muchísimo más que el sobrecoste que se evitaría. En datos tampoco: un proceso de carga interrumpido a medias puede dejar el almacén inconsistente, que es un incidente y no una molestia.

(4) Noviembre. Con un presupuesto planificado que asigne a noviembre un importe acorde con el triple de ventas —unos 8.500 USD globales— y con dos medidas de acompañamiento: subir los umbrales de anomalía durante la campaña, porque el patrón cambia y el detector generará falsos positivos; y desactivar temporalmente la acción automática de preproducción durante la semana del Black Friday, ya que es cuando más pruebas se hacen y una congelación en ese momento bloquearía al equipo justo cuando no puede permitírselo. Ambas medidas se documentan con fecha de reversión, para que nadie olvide volver a activarlas en diciembre.

Solución al ejercicio 2

(1) ¿Es motivo de alarma? No de alarma, sí de atención. Los datos dicen esto: el día 11 se ha consumido el 43,7 % del presupuesto, cuando lo proporcional sería un 35,5 %. La previsión de 1.482 USD supera el presupuesto en un 5,9 %, que es un margen pequeño y está dentro de lo que una previsión puede equivocarse. Además, el aviso es del tipo previsto, no real: quedan 20 días para actuar. Ignorarlo sería un error, y alarmarse también.

(2) Tres comprobaciones, en orden:

1. El coste por pedido. Si octubre lleva más pedidos que septiembre y el coste unitario se mantiene o baja, el crecimiento es sano y la conversación pasa a ser sobre el importe del presupuesto, no sobre un problema técnico. Es la primera comprobación siempre.
2. Vista diaria del mes en Cost Explorer, filtrada a la cuenta de producción. Se busca un escalón: si el gasto diario subió de golpe un día concreto y se mantiene, hay un recurso nuevo o un cambio de configuración; si la subida es gradual, es volumen de negocio.
3. Desglose por servicio comparando con el mes anterior, mirando el valor absoluto de la variación. Si suben Fargate, Aurora y las colas, es actividad real. Si sube CloudWatch, la transferencia de datos o aparece un servicio que antes no estaba, es otra cosa.

(3) Decisión y documentación. Con los pedidos un 22 % por encima y el presupuesto proyectado un 5,9 % por encima, el coste por pedido está bajando de forma notable: el sistema absorbe un 22 % más de negocio con un 6 % más de gasto. Es la mejor noticia posible.

La decisión correcta es subir el presupuesto de producción de 1.400 a 1.600 USD, y no hacer ninguna optimización de urgencia. Lo que se documenta, en el commit que cambia el importe en el CDK:

Con dos apuntes que evitan problemas futuros: hay que revisar también el presupuesto global de 2.000 USD, porque si producción sube a 1.600 la suma de los específicos se acerca demasiado al techo; y conviene anotar la revisión de enero, porque el importe de octubre incorpora un crecimiento que puede no ser permanente.

Solución al ejercicio 3

(1) La política. Preproducción tiene una particularidad que la distingue de desarrollo: debe parecerse a producción, y el pipeline despliega en ella automáticamente. Eso condiciona qué se puede denegar:

Se incluye la creación de bases de datos, clústeres, cachés e instancias, que en preproducción se crean a mano para pruebas puntuales y son lo que dispara la factura. Se deja fuera deliberadamente ecs:CreateService, ecs:RunTask, elasticloadbalancing:*, lambda:* y cloudformation:*, porque todo eso lo usa el pipeline en cada despliegue: denegarlo rompería la integración continua, y un equipo que no puede desplegar a preproducción acaba desplegando a producción sin probar, que es infinitamente peor que gastar 50 USD de más.

(2) Umbral y modo: ACTUAL al 100 % y modo MANUAL.

• Real y no previsto, por la misma razón que en desarrollo: una previsión equivocada no debe bloquear un entorno del que depende el pipeline.
• Manual y no automático, y esta es la diferencia clave con desarrollo. En desarrollo el peor caso es que Luis no pueda levantar una máquina de pruebas durante unas horas: una molestia. En preproducción el peor caso es que se bloquee la validación de un despliegue urgente —por ejemplo, un parche de seguridad—: eso ya es un incidente. El modo manual notifica, muestra la acción propuesta y espera a que Marta la apruebe con un clic, lo que preserva el control sin automatizar el riesgo.

(3) Tres cosas que podrían salir mal y su mitigación:

Un cuarto riesgo que conviene anticipar: el aviso de la acción manual puede quedarse sin aprobar si llega un viernes por la tarde. La mitigación no es técnica sino organizativa: acordar que las acciones manuales pendientes son parte de la revisión diaria de la guardia, que es uno de los hallazgos de excelencia operativa que 11-01 dejó abierto.

MercadoFresco ha pasado de saber lo que gasta a no poder pasarse sin enterarse.

Sabes distinguir analizar de controlar: Cost Explorer mira hacia atrás y requiere que alguien se acuerde; Budgets mira hacia delante y no requiere que nadie haga nada. Y sabes situarlos frente a la detección de anomalías, que responde a otra pregunta —«esto no se parece a tu patrón»— y que no detecta una subida gradual del 3 % mensual capaz de reventar un presupuesto en seis meses. Con las cinco razones por las que la alarma de 10 USD de 01-02 se había quedado inservible, la primera de las cuales es la más grave: un aviso que siempre está en rojo hace daño activo, porque enseña al equipo a ignorar el canal entero.

Tienes los cuatro tipos de presupuesto —coste, uso, Savings Plans y reservas—, con el de uso como el menos conocido y el que detecta lo que el de coste no ve cuando bajan los precios. Y las periodicidades, con el presupuesto planificado resolviendo el problema real de la campaña de Navidad: importes distintos por mes, de 2.000 en operación normal a 2.600 en diciembre, para que el mes que más atención necesita no sea justo el mes en que todos los avisos se ignoran. Con el efecto colateral más valioso: ponerle un número a diciembre obliga a estimarlo, y estimarlo obliga a hablar con negocio.

Tienes la distinción entre umbrales sobre coste real y previsto, y la razón de configurar los dos: el día 9 con 51 USD gastados, el umbral real no dispara y el previsto sí, dejando 21 días para corregir. Con las dos advertencias del previsto —necesita unas cinco semanas de historial y extrapola cualquier gasto puntual— y el escalado de tres umbrales con la regla que lo ordena: cada umbral debe tener un destinatario y una acción esperada distintos, hasta el punto de que el 50 % de MercadoFresco no avisa a nadie a propósito.

Tienes los diez presupuestos concretos sobre la factura de 1.749,60 USD: global de 2.000, producción 1.400, preproducción 290, desarrollo 170, herramientas 70, gobierno 55, más los transversales por etiqueta analitica (220), por servicio CloudWatch (170), de uso de NAT (900 GB) y el planificado de Navidad. Con las cuatro decisiones de diseño: márgenes del 10 al 20 %, la suma de los específicos por debajo del global para que el techo también avise, desarrollo como el único con acción, y presupuestos que se solapan a propósito porque vigilan dimensiones distintas —y que por eso no se suman—.

Tienes la creación por consola, CLI y CDK, que es como se mantienen de verdad, con los tres detalles que fallan: el formato user:Clave$Valor del filtro por etiqueta, que mal escrito crea un presupuesto que filtra a cero y nunca avisa; IncludeTax e IncludeCredit a false para trabajar sobre el coste de servicios; y UseAmortized activado desde ya, para que el mes en que se pague un compromiso no dispare todos los umbrales. Más las notificaciones por los tres canales y la política del tema SNS con aws:SourceAccount y aws:SourceArn, que es el paso que más veces se olvida.

Y tienes la parte con dientes: las acciones de presupuesto, con sus tres tipos —política IAM, SCP y detener instancias— y sus dos modos, gobernados por una regla sin excepciones cómodas: automático solo donde el peor caso sea una molestia; manual donde el peor caso sea un incidente. Con el caso completo de la cuenta de desarrollo 333344445555, que se congela sola al 100 % de coste real mediante una SCP que solo deniega crear recursos caros y no toca nada de lo que ya funciona, apuntada a la cuenta y nunca a la OU, con rol de permisos mínimos y runbook de desbloqueo. Y el incidente real que justificó todo: un clúster de EKS olvidado un fin de semana, 40 USD en lugar de 220. Con la advertencia que hay que grabar a fuego: ninguna acción automática restrictiva en producción, porque una política que impida escalar un viernes de campaña convierte un ahorro de 300 USD en una caída que cuesta mucho más.

Y tienes la rutina que sostiene todo: los informes de presupuestos que abren la reunión con un documento común, las siete buenas prácticas, el procedimiento de cuatro pasos para cuando un presupuesto se supera por una razón legítima —empezando siempre por el coste unitario, y terminando siempre con un commit que explique el nuevo importe—, y el marco FinOps con su ciclo de informar, optimizar y operar, sus tres principios —los equipos son dueños de su gasto, las decisiones se toman sobre valor y no sobre coste, y el equipo central habilita en lugar de controlar— y la reunión mensual de 30 minutos que empieza por el coste por pedido, produce una sola acción y en la que nadie se lleva una sorpresa en público.

Queda una palanca sin usar, y es la única que reduce la factura sin cambiar absolutamente nada de la arquitectura. Todo lo que MercadoFresco tiene funcionando —las tareas de Fargate que están encendidas 24 horas al día, las funciones Lambda que se invocan cada minuto, los nodos de ElastiCache que llevan meses sin apagarse— se está pagando a precio bajo demanda, es decir, al precio de quien podría marcharse mañana. Hay una parte de ese consumo que es completamente predecible y que va a seguir ahí dentro de un año. Y AWS paga por saberlo por adelantado.

En 11-05, «AWS Savings Plans», se cierra el ciclo de optimización comprometiendo capacidad: los cuatro modelos de compra con su descuento y su riesgo, cómo funciona el compromiso por dólar-hora con un ejemplo numérico paso a paso, qué cubre cada tipo y qué no —importante en una arquitectura como esta, mayoritariamente serverless—, cómo se identifica la base estable frente a la parte elástica, y el plan de compra concreto de MercadoFresco con su ahorro mensual y anual. Con el orden que 11-03 ya adelantó y que aquí se justifica del todo: primero apagar lo que sobra, después comprometer.