Most risky AWS changes never touch a pull request.
A 30-engineer company running AWS has dozens of ways a dangerous change can land outside Terraform — and outside any review. You own the blast radius of every single one of them.
- 01
Console edits during incidents (ClickOps)
Someone opens a security group directly in the AWS console to unblock an incident. No PR. No review. No record in your change tracking. You find out when the next incident is already on fire.
- 02
CI jobs changing security groups outside Terraform
Your deployment pipeline opens a security group inline — it is in a shell script, not a Terraform plan, so your PR linter never sees it. The change is real. The review never happened.
- 03
Terraform module bumps that open SSH to 0.0.0.0/0
A one-line module version bump. Looks harmless in the diff. Resolved against your live account and org topology, it opens SSH on 12 instances to the internet. The reviewer approved what they could see.
- 04
AI coding agents calling the AWS API
Coding agents author and apply infra change faster than one person can review. The agent has your repo context. It does not have your account context. That gap is exactly where production breaks.
Production outages from unreviewed infra changes don't arrive gradually. You find out when the page arrives — and spend the next hour reconstructing what happened. Every platform owner has that scar. Guard is built against it.
One check, two places: every pull request and every AWS account you connect.
Connect your Terraform repos and AWS accounts once. Whether a change arrives as a pull request in any of them, or lands through the console, CLI or a CI script, Guard checks it against your live AWS state and alerts only when production is actually exposed.
Alerts within minutes of the change landing
Reads the CloudTrail log files your trail saves to S3. A Slack alert with the resolved effect: what changed, who changed it, and what is now exposed.
Surfaces the danger the diff is hiding
The same check runs on the Terraform plan before apply. One comment on the pull request explains the risk. The status check never blocks a merge on its own.
The second time a tool wastes your attention, you mute it.
So we hold Critical alerts to one danger class and a strict set of conditions.
A security-group change that newly exposes a reachable production resource to the public internet on a sensitive port — whether it came from a pull request, the console, the CLI or a CI job.
New danger classes ship only when they meet the same precision bar.
- a real transition from not-exposed to exposed
- a broad internet CIDR (not your office VPN)
- a sensitive port
- a reachable resource
- a production account
- and not something already baselined as intended
Read-only by default. One IAM role is the only access we get.
The first question every platform owner asks is "why would I let a vendor read my cloud?" Here is what Guard can access, and how that access is limited.
One IAM role, read-only
A single CloudFormation stack creates one cross-account role with read-only permissions. Only CloudBooster's AWS account can use it, and only with your unique External ID. Delete the stack and access ends immediately.
Your CloudTrail logs, no AWS Config
Guard reads the log files your CloudTrail trail saves to S3, and your live configuration through Describe, Get and List calls. No trail yet? One click creates one. It never enables AWS Config. Small AWS cost: about $1 a month per account in S3 request fees.
Advisory by default
The role has no write actions, so by default Guard cannot change your infrastructure. It can change something only if you turn on auto-fix and create a separate write role yourself.
GitHub or GitLab: optional, repos you choose
Pull-request review uses a GitHub App or GitLab integration on the repositories you pick. It posts one comment and a non-blocking status check, and never pushes, approves or merges.
- Your AWS configuration (AWS-managed ViewOnlyAccess policy)
- S3 read access, used only for your CloudTrail log files (including encrypted ones)
- No write actions of any kind
- Only CloudBooster's AWS account can use the role, and only with your unique External ID
- Delete the CloudFormation stack and access ends immediately
Your PR scanner stays. Guard covers what it can't see.
Most dangerous infra change in a real company does not go through Terraform and a pull request. Guard watches both paths with one check.
Built for
Catches changes made outside Terraform (console, CLI, CI)
Reviews pull requests inline
Same verdict in the PR and on the live cloud
Fires only on a real not-exposed → exposed transition in prod
Pricing model
Priced by AWS accounts, not per seat.
Start free on one AWS account. Paid plans add more accounts and team features.
Free
Start here1 AWS account, forever. Prove it catches something real on prod before you spend a cent.
- Live change detection (1 account)
- Slack alerts — Critical tier only
- PR review on connected repos
- First-run landscape map
- 30-day history
Team & Org
Pricing at launchFor more AWS accounts and teams. Early-access members see launch pricing first.
- More AWS accounts
- Longer alert history
- Team and organization features
- Same detection as Free — never more noise
The questions every platform owner asks first.
CloudBooster Guard is an AWS change-alerting tool, read-only by default. It checks every infrastructure change — in Terraform pull requests and on the live AWS account via CloudTrail — against your real account state, and alerts in Slack only when a change actually exposes production to the internet.
No. By default Guard uses a single read-only IAM role. It reads the log files your CloudTrail trail saves to S3 and your live configuration through Describe, Get and List calls. It never enables AWS Config. Write access exists only if you turn on auto-fix and create a separate write role yourself.
A security-group change that newly exposes a reachable production resource to the public internet on a sensitive port — from a pull request, the console, the CLI or a CI job. New danger classes ship only when they meet the same precision bar.
A PR scanner reads the code in a pull request and is blind to changes that never go through Terraform — console edits, CLI calls, CI scripts. Guard runs the same check on pull requests and on the live cloud, and evaluates each change against your actual account state rather than the diff in isolation. Keep your PR scanner; Guard covers what it can't see.
AWS Config and Security Hub evaluate resource configuration against rules and report findings — useful for posture, but you get every rule match, and Config bills per recorded configuration item. Guard looks at each change and alerts only when it newly exposes production, without enabling AWS Config.
You can, and you'll get a message for every security-group change. Guard tells you which change made a production resource reachable from the internet, who made it, and what it opened — and stays quiet about the rest.
Drift detection tells you the live account differs from your code. Not every drift is dangerous, and not every dangerous change is drift — the risky change may be in the code itself. Guard answers a different question: did this change just expose production?
No. Live-cloud detection works with the AWS role alone. Pull-request review on GitHub or GitLab (gitlab.com) is optional.
No, unless you turn on merge gating for a repo or approval holds. By default Guard is advisory: its pull-request status check never blocks a merge on its own, and its AWS role has no write permissions.
About five minutes. You launch a CloudFormation stack that creates one read-only cross-account role (and a CloudTrail trail, if you don't have one), pick a Slack channel, and Guard begins watching — no agents to install, no code changes.
Delete the CloudFormation stack. The role is removed and Guard can no longer read your account.
One AWS account is free forever. Paid plans for more accounts and team features launch with Guard, and early-access members see the pricing first. Pricing is by AWS accounts, not seats.
No. One AWS account is free forever, with the same detection as the paid plans.
Our founders have spent a decade running production AWS.
Guard is built by CloudBooster, founded by the team behind TIDORA, an AWS Advanced Tier Services Partner. Our founders spent a decade as the cloud-engineering function for teams running real, brownfield AWS — Guard is that experience, productized.
Dominik SnopekCEO & Co-founder
Radek ForgačCTO & Co-founder
Know within minutes when production gets exposed.
Join early access. No credit card, no agents, no AWS Config — one read-only role from a template you can read first.
How setup works at launch
- Step 1
Sign up free
No credit card. One AWS account is free for good.
- Step 2
Launch one CloudFormation stack
It creates a single read-only IAM role. Review the template in your AWS console before you create it. About five minutes.
- Step 3
Pick a Slack channel
Alerts go where your team already works. Connect GitHub or GitLab too if you want pull-request review — it's optional.
Need help rolling Guard out across your AWS organization? Implementation support is available through TIDORA, an AWS Advanced Tier Services Partner.