Módulo 2: The Bedrock Cost Model

4. Manos a la obra: Infracost, heredado

Siguiente →

Descripción

Esta lección no instala nada. Es, a propósito, la lección más corta de este módulo en trabajo nuevo: confirma que el mismo binario de Infracost que finops-and-cost-guardrails-guide ya instaló, verificó y documentó hasta su límite exacto de autenticación, sigue disponible, sin ningún paso adicional, para el Terraform nuevo de esta guía. Cero reinstalación — la misma disciplina de herencia que ya viste con conftest, Trivy y cosign en el Módulo 5.

Conexión con el módulo

Las lecciones 1 a 3 dieron el modelo de costo y de cuota completo, en prosa y con cifras citadas — pero sin ejecutar un solo comando. Esta lección abre el bloque ejecutado del módulo: primero confirma la herramienta (esta lección), después la pone a prueba contra un recurso de Bedrock real, por primera vez en esta guía (lección 5).

Paso 1 — Confirmando que el binario sigue ahí

infracost --version

Qué esperar (literal — corrido contra el binario real en este entorno):

infracost version 2.16.1

Este es exactamente el mismo número que finops-and-cost-guardrails-guide, Módulo 2, lección 3 ya fijó, instalado en ~/.local/bin/infracost con el script oficial (curl -fsSL https://raw.githubusercontent.com/infracost/cli/main/scripts/install.sh | sh), sin sudo. Ninguna guía de este ecosistema reinstala Infracost — cada una que lo necesita confirma la versión heredada y sigue.

Paso 2 — Confirmando el vocabulario de comandos

infracost scan --help

Qué esperar (literal — corrido contra el binario real):

Scan your IaC and derive FinOps costs and policy violations

Usage:
  infracost scan [path] [flags]

Examples:
  # Scan the current directory
  $ infracost scan

  # Scan a specific project path
  $ infracost scan ./terraform

  # Scan against a different organization's policies & prices
  $ infracost scan --org acme

Flags:
      --currency string       ISO 4217 currency code to use for prices (e.g. USD, EUR, GBP)
  -h, --help                  help for scan
      --include-warnings      Also show warning-severity diagnostics in the summary
  -o, --option stringArray    Specify a plugin-specific option e.g. -o infracost/terraform.option=yes
      --ssh-key-file string   Comma-separated SSH private key file(s) to use for fetching private modules over SSH (defaults to the standard ~/.ssh keys)

Global Flags:
      --access-token-use-cache   Read and save access tokens from a cache file (disable to force a fresh login) (default true)
      --debug                    Enable debug logging
      --json                     Output logs and command results as JSON
      --llm                      Output command results in a compact, token-efficient format intended for LLM prompts
      --no-color                 Disable colored output
      --oauth-use-device-flow    Use device flow for authentication instead of PKCE (useful when you don't have access to localhost)
      --org string               The organization slug or ID to use

Tres detalles de este --help, ya confirmados por finops-and-cost-guardrails-guide pero que vale la pena repasar antes de apuntar scan a un recurso de Bedrock en la lección siguiente. Primero, [path] es un argumento posicional, no una bandera — infracost scan andes-cargo-infra/ es correcto, infracost scan --path andes-cargo-infra/ no existe en esta versión del CLI. Segundo, scan espera un directorio con archivos .tf, no un tfplan.json ya exportado — a diferencia de conftest/Trivy, que sí pueden apuntar directo a un plan en JSON. Tercero, y este es nuevo frente a lo que finops-and-cost-guardrails-guide ya documentó: --oauth-use-device-flow aparece explícitamente en las banderas globales — una pista de que, además del flujo PKCE por navegador que esa guía ya encontró, existe un segundo camino de autenticación por device flow, pensado para entornos "sin acceso a localhost". La lección 5 de este módulo se topa con ese segundo camino en vivo, sin haberlo pedido.

Paso 3 — Un diagnóstico rápido, antes de arriesgar nada contra bedrock.tf

Un último comando, también sin necesitar sesión iniciada, vale la pena correr antes de intentar algo nuevo con una herramienta heredada: el diagnóstico propio de Infracost.

infracost doctor

Qué esperar (literal — corrido contra el binario real):

Infracost Doctor 2.16.1 - running 7 checks

Authentication
  ✗  No credentials found
     →  Run `infracost auth login` to authenticate
  ⊘  Token valid
     →  skipped (No credentials found)
  ⊘  Organization accessible
     →  skipped (No credentials found)
  ⊘  API reachable
     →  skipped (Organization accessible)

CLI
  ✔  Version 2.16.1 (latest)

Configuration
  ✔  Config file valid
  !  Default org set
     →  No organization data available

  ✔  2 passed  !  1 warning  ✗  1 issue  ⊘  3 skipped

Run infracost doctor --fix to attempt auto-remediation
Info: 1 health check(s) failed

Dos confirmaciones reales en esta salida, ninguna trivial. Primera: la línea Version 2.16.1 (latest) — no solo coincide con la versión que finops-and-cost-guardrails-guide ya fijó, el propio CLI confirma que, al momento de correr este diagnóstico, esa versión sigue siendo la más reciente publicada. No hubo actualización pendiente entre que esa guía hermana se escribió y este módulo la heredó. Segunda: el único chequeo que falla (✗ No credentials found) es, exactamente, el mismo límite que la lección 5 va a encontrar de nuevo, ahora contra un recurso de Bedrock real — infracost doctor lo anticipa con precisión, sin necesitar intentar una cotización real todavía. Los tres chequeos marcados ⊘ (omitidos) dependen en cascada del primero: sin credenciales, ni el token, ni el acceso a una organización, ni la conectividad a la API pueden verificarse — la misma cascada de dependencia que el diagrama de la sección siguiente muestra para scan.

Lo que esta lección confirma, y lo que todavía no intenta

Esta lección corrió dos comandos —--version, scan --help— que nunca requieren sesión iniciada, exactamente como finops-and-cost-guardrails-guide ya estableció: son, junto a infracost doctor, los únicos que Infracost ejecuta completos sin pedir autenticación. Lo que esta lección no hizo todavía es apuntar scan a un directorio real con un recurso aws_bedrock_guardrail declarado — eso, con el resultado real de intentarlo, es exactamente el trabajo de la lección 5.

   LO QUE ESTA LECCIÓN CONFIRMÓ            LO QUE LA LECCIÓN 5 INTENTA

   infracost --version                     infracost scan andes-cargo-infra/
   infracost scan --help                        │
        │                                       ▼
        ▼                              ¿Requiere sesión? -- la lección 4
   Nunca piden sesión iniciada          de finops-and-cost-guardrails-guide
   (confirmado, heredado)               ya lo confirmó que sí, para
                                         cualquier scan/price real.
                                         Esta lección lo confirma otra vez,
                                         ahora contra un recurso de Bedrock
                                         específico, con su propio resultado.

Errores comunes

Reinstalar Infracost "por las dudas", en vez de confirmar la versión heredada (de desconfianza innecesaria). Qué pasa: alguien, al empezar un módulo nuevo de una guía distinta, vuelve a correr el script de instalación completo, asumiendo que cada guía necesita su propia copia. Cómo detectarlo: si tu primer paso en esta lección fue correr curl ... | sh de nuevo, en vez de simplemente confirmar --version. Cómo corregirlo: Infracost, igual que conftest, Trivy y cosign, es una herramienta de tu máquina, no de un proyecto específico — una vez instalada, cualquier guía posterior de este ecosistema la reusa. Reinstalar no rompe nada, pero es trabajo repetido que esta guía, deliberadamente, no pide.

Confundir --oauth-use-device-flow con una forma de evitar la autenticación por completo (de lectura apresurada). Qué pasa: alguien ve la bandera --oauth-use-device-flow en el --help de esta lección y asume que existe una forma de correr scan sin ninguna sesión iniciada. Cómo detectarlo: si tu conclusión es "entonces sí hay un camino sin login". Cómo corregirlo: --oauth-use-device-flow cambia el mecanismo de autenticación (un código que ingresas en otro dispositivo, en vez de un servidor local que recibe un callback del navegador) — no elimina la necesidad de iniciar sesión. Sigue exigiendo completar el flujo en un navegador real, en algún dispositivo. La lección 5 muestra exactamente cómo se ve este flujo en la práctica.

Saltarse esta lección porque "ya se vio en finops-and-cost-guardrails-guide" (de omisión). Qué pasa: alguien, familiarizado con esa guía, decide que confirmar --version de nuevo es trabajo redundante y pasa directo a la lección 5. Cómo detectarlo: si no verificaste, en tu propia máquina, que el número de versión reportado coincide exactamente con 2.16.1. Cómo corregirlo: el punto de esta lección no es enseñar algo nuevo sobre Infracost — es confirmar, con un comando real corrido en este momento, que la herencia entre guías realmente funciona. Si tu versión difiere, es información real y útil (Infracost publica actualizaciones con frecuencia) antes de interpretar cualquier resultado de la lección 5.

Ejercicios

Ejercicio 1 — Explica, sin mirar el --help de esta lección, la diferencia entre un argumento posicional y una bandera, usando scan como ejemplo. Un compañero, acostumbrado a otras herramientas de línea de comandos, escribe infracost scan --path andes-cargo-infra/ y el comando falla. Explícale, de memoria, por qué.

Ver solución

scan recibe la ruta del proyecto como un argumento posicional — el valor se escribe directamente después del comando, sin ningún nombre de bandera que lo preceda: infracost scan andes-cargo-infra/. Una bandera, en cambio, tiene un nombre explícito, generalmente precedido por --, como --currency o --include-warnings. El CLI de Infracost no reconoce --path como una bandera válida de scan en esta versión, así que el comando fallaría con un error de bandera desconocida, no porque la ruta esté mal escrita.

Ejercicio 2 — Nombra los tres comandos de Infracost que corren completos sin necesitar sesión iniciada, según lo que esta lección y finops-and-cost-guardrails-guide ya confirmaron juntas. Sin mirar atrás, ¿cuáles son?

Ver solución

infracost --version, infracost --help (o el --help de cualquier subcomando específico, como scan --help), e infracost doctor. Los tres corren completos, con salida real, sin pedir ningún inicio de sesión — son los únicos de todo el CLI con esa propiedad. Cualquier comando que efectivamente cotice algo (scan, price, inspect) exige sesión iniciada, como confirma la lección 5 de este módulo.

Ejercicio 3 — Predice, antes de leer la lección 5, qué mecanismo de autenticación es más probable que aparezca al correr infracost scan en este entorno de escritura específico, basándote en la nota de --oauth-use-device-flow de esta lección ("useful when you don't have access to localhost"). ¿PKCE por navegador, o device flow? Justifica.

Ver solución

No hay forma de estar completamente seguro sin correrlo —y por eso la lección 5 lo corre de verdad, en vez de asumirlo—, pero un entorno de escritura en sandbox, sin navegador propio ni acceso directo a localhost desde fuera del proceso, es exactamente el escenario que la descripción de --oauth-use-device-flow señala como su caso de uso: "useful when you don't have access to localhost". Es razonable predecir que el flujo PKCE (que depende de un servidor local escuchando en un puerto específico, como ya documentó finops-and-cost-guardrails-guide) podría fallar o verse forzado a caer a device flow en este tipo de entorno — la lección 5 confirma, con la salida real, si esa predicción se cumple.

Resumen y siguiente paso

Esta lección confirmó, con dos comandos reales que nunca requieren sesión iniciada, que Infracost sigue disponible sin ningún paso adicional: la misma versión (2.16.1) que finops-and-cost-guardrails-guide ya fijó, y el mismo vocabulario de scan (argumento posicional, directorio completo, no un tfplan.json exportado). También notó un detalle nuevo, no explorado en la guía hermana: la bandera --oauth-use-device-flow, una pista de que el flujo de autenticación de Infracost tiene más de un camino posible.

Antes de avanzar deberías poder: correr infracost --version en tu propia máquina y confirmar que el binario sigue instalado; explicar por qué esta lección no reinstaló nada; y anticipar, con una hipótesis razonada, qué mecanismo de autenticación podría aparecer al intentar scan en un entorno sin navegador propio.

La lección 5 apunta, por primera vez en esta guía, infracost scan a un directorio con un recurso aws_bedrock_guardrail real —el primer bedrock.tf, aunque sea en su versión mínima— y documenta exactamente qué pasa, sin asumir el resultado de antemano.

Recursos

  1. Infracost — CLI commands — la referencia oficial de scan, confirmada contra el --help real de esta lección.
  2. finops-and-cost-guardrails-guide, Módulo 2, lecciones 2 y 3 — la fuente original de la instalación y del hallazgo de autenticación que esta lección hereda sin repetir.
  3. Infracost — Authentication — documentación oficial de los flujos de autenticación de Infracost, incluido device flow.
← Anterior3. Cuotas de Bedrock: el límite que ninguna factura muestraSiguiente →5. Manos a la obra: el intento honesto de `infracost scan` sobre `bedrock.tf`