Module 2: The Bedrock Cost Model

4. Hands-on: Infracost, inherited

Next →

Description

This lesson doesn't install anything. It's, on purpose, this module's shortest lesson in new work: it confirms that the same Infracost binary finops-and-cost-guardrails-guide already installed, verified, and documented up to its exact authentication limit is still available, with no extra step, for this guide's new Terraform. Zero reinstallation — the same inheritance discipline you already saw with conftest, Trivy, and cosign in Module 5.

Connection to the module

Lessons 1 through 3 gave the complete cost and quota model, in prose and with cited figures — but without executing a single command. This lesson opens the module's executed block: first it confirms the tool (this lesson), then it puts it to the test against a real Bedrock resource, for the first time in this guide (lesson 5).

Step 1 — Confirming the binary is still there

infracost --version

What to expect (literal — run against the real binary in this environment):

infracost version 2.16.1

This is the exact same number finops-and-cost-guardrails-guide, Module 2, lesson 3 already fixed, installed at ~/.local/bin/infracost with the official script (curl -fsSL https://raw.githubusercontent.com/infracost/cli/main/scripts/install.sh | sh), no sudo. No guide in this ecosystem reinstalls Infracost — each one that needs it confirms the inherited version and moves on.

Step 2 — Confirming the command vocabulary

infracost scan --help

What to expect (literal — run against the real binary):

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

Three details from this --help, already confirmed by finops-and-cost-guardrails-guide but worth reviewing before pointing scan at a Bedrock resource in the next lesson. First, [path] is a positional argument, not a flag — infracost scan andes-cargo-infra/ is correct, infracost scan --path andes-cargo-infra/ doesn't exist in this CLI version. Second, scan expects a directory with .tf files, not an already-exported tfplan.json — unlike conftest/Trivy, which can point directly at a JSON plan. Third, and this is new compared to what finops-and-cost-guardrails-guide already documented: --oauth-use-device-flow shows up explicitly among the global flags — a hint that, besides the browser-based PKCE flow that guide already found, there's a second authentication path via device flow, meant for environments "without access to localhost." This module's lesson 5 runs into that second path live, without having asked for it.

Step 3 — A quick diagnostic, before risking anything against bedrock.tf

One last command, also needing no logged-in session, is worth running before trying something new with an inherited tool: Infracost's own diagnostic.

infracost doctor

What to expect (literal — run against the real binary):

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

Two real confirmations in this output, neither trivial. First: the line Version 2.16.1 (latest) — it not only matches the version finops-and-cost-guardrails-guide already fixed, the CLI itself confirms that, at the moment this diagnostic runs, that version is still the most recently published one. No pending update happened between when that sibling guide was written and this module inherited it. Second: the one check that fails (✗ No credentials found) is, exactly, the same limit lesson 5 is going to run into again, now against a real Bedrock resource — infracost doctor anticipates it precisely, without needing to attempt a real quote yet. The three checks marked ⊘ (skipped) cascade from the first one: with no credentials, neither the token, nor access to an organization, nor connectivity to the API can be verified — the same dependency cascade the next section's diagram shows for scan.

What this lesson confirms, and what it still hasn't tried

This lesson ran two commands — --version, scan --help — that never require a logged-in session, exactly as finops-and-cost-guardrails-guide already established: they're, along with infracost doctor, the only ones Infracost runs to completion without requesting authentication. What this lesson hasn't done yet is point scan at a real directory with an aws_bedrock_guardrail resource declared — that, with the real result of trying it, is exactly lesson 5's job.

   WHAT THIS LESSON CONFIRMED             WHAT LESSON 5 ATTEMPTS

   infracost --version                     infracost scan andes-cargo-infra/
   infracost scan --help                        │
        │                                       ▼
        ▼                              Does it require a session? -- lesson 4
   Never require a logged-in            of finops-and-cost-guardrails-guide
   session (confirmed, inherited)       already confirmed it does, for
                                         any real scan/price. This lesson
                                         confirms it again, now against a
                                         specific Bedrock resource, with
                                         its own result.

Common mistakes

Reinstalling Infracost "just in case," instead of confirming the inherited version (unnecessary distrust mistake). What happens: someone, starting a new module in a different guide, reruns the full installation script, assuming each guide needs its own copy. How to spot it: if your first step in this lesson was running curl ... | sh again, instead of simply confirming --version. How to fix it: Infracost, like conftest, Trivy, and cosign, is a tool on your machine, not on a specific project — once installed, every later guide in this ecosystem reuses it. Reinstalling doesn't break anything, but it's repeated work this guide deliberately doesn't ask for.

Confusing --oauth-use-device-flow with a way to avoid authentication entirely (rushed-reading mistake). What happens: someone sees the --oauth-use-device-flow flag in this lesson's --help and assumes there's a way to run scan with no session logged in at all. How to spot it: if your conclusion is "so there is a way with no login." How to fix it: --oauth-use-device-flow changes the authentication mechanism (a code you enter on another device, instead of a local server receiving a browser callback) — it doesn't remove the need to log in. It still requires completing the flow in a real browser, on some device. Lesson 5 shows exactly what this flow looks like in practice.

Skipping this lesson because "it was already covered in finops-and-cost-guardrails-guide" (omission mistake). What happens: someone, familiar with that guide, decides confirming --version again is redundant work and jumps straight to lesson 5. How to spot it: if you didn't verify, on your own machine, that the reported version number exactly matches 2.16.1. How to fix it: this lesson's point isn't to teach something new about Infracost — it's to confirm, with a real command run right now, that inheritance between guides actually works. If your version differs, that's real, useful information (Infracost publishes updates frequently) to have before interpreting any result from lesson 5.

Exercises

Exercise 1 — Explain, without looking at this lesson's --help, the difference between a positional argument and a flag, using scan as the example. A colleague, used to other command-line tools, writes infracost scan --path andes-cargo-infra/ and the command fails. Explain to them, from memory, why.

See solution

scan receives the project's path as a positional argument — the value gets written directly after the command, with no flag name preceding it: infracost scan andes-cargo-infra/. A flag, on the other hand, has an explicit name, generally preceded by --, like --currency or --include-warnings. Infracost's CLI doesn't recognize --path as a valid scan flag in this version, so the command would fail with an unknown-flag error, not because the path is misspelled.

Exercise 2 — Name the three Infracost commands that run to completion without needing a logged-in session, based on what this lesson and finops-and-cost-guardrails-guide already confirmed together. Without looking back, what are they?

See solution

infracost --version, infracost --help (or the --help for any specific subcommand, like scan --help), and infracost doctor. All three run to completion, with real output, without requesting any login — they're the only ones in the whole CLI with that property. Any command that actually quotes something (scan, price, inspect) requires a logged-in session, as this module's lesson 5 confirms.

Exercise 3 — Predict, before reading lesson 5, which authentication mechanism is most likely to appear when running infracost scan in this specific writing environment, based on this lesson's --oauth-use-device-flow note ("useful when you don't have access to localhost"). Browser PKCE, or device flow? Justify it.

See solution

There's no way to be completely sure without running it — and that's why lesson 5 runs it for real, instead of assuming it —, but a sandboxed writing environment, with no browser of its own and no direct access to localhost from outside the process, is exactly the scenario --oauth-use-device-flow's description points to as its use case: "useful when you don't have access to localhost." It's reasonable to predict that the PKCE flow (which depends on a local server listening on a specific port, as finops-and-cost-guardrails-guide already documented) could fail or be forced to fall back to device flow in this kind of environment — lesson 5 confirms, with real output, whether that prediction holds.

Summary and next step

This lesson confirmed, with two real commands that never require a logged-in session, that Infracost remains available with no extra step: the same version (2.16.1) finops-and-cost-guardrails-guide already fixed, and the same scan vocabulary (positional argument, full directory, not an exported tfplan.json). It also noticed a new detail, unexplored in the sibling guide: the --oauth-use-device-flow flag, a hint that Infracost's authentication flow has more than one possible path.

Before moving on you should be able to: run infracost --version on your own machine and confirm the binary is still installed; explain why this lesson didn't reinstall anything; and anticipate, with a reasoned hypothesis, which authentication mechanism might show up when attempting scan in an environment with no browser of its own.

Lesson 5 points, for the first time in this guide, infracost scan at a directory with a real aws_bedrock_guardrail resource — the first bedrock.tf, even if in its minimal version — and documents exactly what happens, without assuming the result beforehand.

Resources

  1. Infracost — CLI commands — the official reference for scan, confirmed against this lesson's real --help.
  2. finops-and-cost-guardrails-guide, Module 2, lessons 2 and 3 — the original source for the installation and the authentication finding this lesson inherits without repeating.
  3. Infracost — Authentication — official documentation of Infracost's authentication flows, including device flow.
← Previous3. Bedrock quotas: the limit no bill showsNext →5. Hands-on: the honest attempt of `infracost scan` on `bedrock.tf`