Audit a staging API on AWS

This example walks through auditing a small environment already running on AWS — a VPC, a Postgres database, and a Fargate service running an API container — with cbx audit aws end to end. Expect about 10 minutes.

What you'll audit

A staging environment that:

• Lives in its own VPC in eu-west-1.
• Runs a containerized API on Fargate with two tasks behind a load balancer.
• Uses managed Postgres (RDS) with credentials in Secrets Manager.

Prerequisites

• An AWS account you can read with the SDK — your normal credential resolution (environment, shared config, or SSO) must work. Confirm with aws sts get-caller-identity.
• The cbx CLI installed. Run cbx version to confirm.
• A local LLM CLI on PATH for grounding — claude (default) or codex. cbx audit aws cites CloudBooster's curated AWS knowledge and rule pack through this executor, so one must be installed and authenticated.

1. Authenticate to CloudBooster

cbx audit aws fetches the curated AWS knowledge and rule pack over the CloudBooster knowledge API, so sign in first:

cbx login

2. Make sure a grounding LLM is ready

The audit runs a pre-discovery preflight against the LLM executor and aborts with E_LLM_PREFLIGHT if it isn't ready — before any AWS calls. Verify it up front:

cbx llm cli test claude-code

If you authenticate via an API provider instead of a local CLI subscription, log in once:

cbx llm api login claude

To use Codex instead of Claude, test cbx llm cli test codex and add --llm-executor codex to the audit command below.

3. Run the audit

cbx audit aws --region eu-west-1

On the first online run, cbx resolves the AWS rule pack from the registry and caches it under ~/.cache/cbx/rulepack/, then discovers your live resources, inlines the curated knowledge alongside them, and runs the local LLM to produce grounded, cited findings. You'll see findings such as "RDS instance is single-AZ" (expected for staging) plus the security baseline checks, each tied back to a rule.

Scope or tune the run as needed:

# Audit several regions (--region is repeatable, or use --region all):
cbx audit aws --region eu-west-1 --region eu-central-1
 
# Lower AWS-side concurrency on large/throttling accounts:
cbx audit aws --region eu-west-1 --aws-concurrency 4
 
# Get a recommended least-privilege IAM policy for the read calls it makes:
cbx audit aws --region eu-west-1 --diagnose

4. Wire it into CI

For machine-readable output, use the global JSON flag — findings are wrapped in the standard envelope and the process exits non-zero when findings meet the severity threshold:

cbx audit aws --region eu-west-1 -o json --no-tui --strict

• -o json — structured output for parsing.
• --no-tui — disable the interactive TUI in headless runners.
• --strict — treat discovery-integrity warnings (timeouts, throttling, truncated lists) as failures, so a partial scan can't pass.

In CI, make sure the grounding CLI is installed and authenticated on the runner, and pin the rule pack for reproducibility:

cbx audit aws --region eu-west-1 -o json --rulepack-version 2026.06.1

If the runner can't reach the rule-pack registry, bake a local copy in and point CBX_AUDIT_RULES_FILE at it.

Remediating findings

Fixing findings is a portal flow: open the finding, let CloudBooster propose a ChangeSet, and review and apply it. On the next audit, resolved findings drop off.

Where next

• Run it in CI — see Run cbx audit in GitHub Actions.
• Understand grounding — see Audits for what the rule pack and knowledge API contribute.
• Manage LLM executors — cbx llm list, cbx llm default, and cbx llm model control which executor and model the audit uses.