Methodology
Terraform Architecture Review — What ArchGuard checks and how
Practitioners shouldn't pay for a black-box AI tool. This page explains exactly what ArchGuard reviews, how the analysis works, and what happens to your code.
Why review-only matters
ArchGuard never writes to your Terraform state, never opens pull requests, never holds your AWS credentials, and never executes infrastructure changes. This is a deliberate decision, not a missing feature.
The infrastructure tooling ecosystem has had two reminders this year of why credential isolation matters. The March 2026 Trivy GitHub Action supply-chain incident (Aqua advisory GHSA-69fq-xp46-6x23) saw 76 of 77 version tags force-pushed to credential-stealing payloads. The 2026 Sonar State of Code survey reported 96% of developers do not fully trust AI-generated code, and incidents of AI agents being given destructive Terraform permissions have become a regular feature of community post-mortems.
We process Terraform code, not infrastructure. We return a PDF, not a pull request. There is no scenario in which ArchGuard can do harm to your AWS account — because we do not have the access to do so.
What we never do
- We never access your AWS account or credentials
- We never read or write your Terraform state file
- We never create pull requests or apply changes to your infrastructure
- We never store your Terraform code after the review is complete
What we do
- We read the Terraform files you provide — nothing else
- We run analysis against those files and a workload brief you write
- We return a structured findings report. You decide what to act on.
All six AWS Well-Architected Framework pillars
Security
- · IAM roles and least-privilege
- · Security group ingress rules
- · Public accessibility settings
- · Secrets and credential handling
- · Encryption at rest and in transit
- · VPC network topology
- · Resource exposure via outputs
Reliability
- · Single points of failure
- · Multi-AZ and redundancy coverage
- · Backup and snapshot configuration
- · Queue and event-source timeout alignment
- · Dead-letter queue configuration
- · Health check coverage
- · Failover paths
Cost Optimization
- · Idle and unattached resources
- · Over-provisioned compute
- · Missing TTLs causing unbounded growth
- · Duplicate processing from misconfigured queue settings
- · Rightsizing opportunities
Performance Efficiency
- · Instance type and size appropriateness
- · Auto-scaling configuration
- · Caching layer coverage (ElastiCache, CloudFront)
- · Database engine and query pattern fit
- · Reserved vs on-demand capacity mix
Operational Excellence
- · CloudWatch alarm coverage
- · Log group configuration
- · Access logging on API surfaces
- · Mutable image tags and deployment determinism
- · Observability gaps
Sustainability
- · Right-sizing for actual workload patterns
- · Graviton / ARM instance usage
- · Spot and Savings Plan coverage
- · Idle resource detection across environments
- · Energy-efficient architecture patterns
How ArchGuard reviews Terraform — AI reasoning + deterministic checks
Deterministic checks
Some findings are rule-based and have no ambiguity: publicly_accessible = true on an RDS instance with cidr_blocks = ["0.0.0.0/0"] is always a HIGH security finding. These checks run first and produce high-confidence findings regardless of workload context.
AI-assisted reasoning
Other findings require context: is a single-AZ RDS instance a problem? It depends on whether it's dev or prod, what SLA the workload requires, and whether the team has accepted the risk. AI reasoning applies the workload brief to surface findings that a rule-based linter would miss or incorrectly flag.
Every finding in an ArchGuard report includes a Confidence level (High / Medium / Low) and the specific evidence — the Terraform resource name, attribute, and value — that produced it. If you disagree with a finding, you have everything you need to push back.
What's in your report
Executive Summary
Plain-English risk verdict, overall well-architected score, High-Risk Issue (HRI) and Medium-Risk Issue (MRI) counts per pillar, and top 3–5 business risks expressed in non-technical language. Written to be shared with stakeholders who don't read Terraform.
Pillar Scorecard
A 0–100 score for each of the six WAFR pillars, colour-coded by risk tier. Deductions are calculated from the severity of findings in that pillar.
Detailed Findings
Every finding includes: severity level, the specific Terraform resource and attribute that triggered it, a "Why it matters" explanation tied to real-world attacker capability or business impact, blast-radius analysis for Critical and High findings, a concrete recommendation, and a secure Terraform code example.
Compliance Mapping
Each finding is tagged with relevant control references from CIS AWS Foundations Benchmark v3.0, NIST 800-53, SOC 2, and PCI DSS where applicable. The mapping is informational — ArchGuard is not a formal audit tool.
Remediation Roadmap
Findings grouped into four action phases — Immediate (before next deployment), 30-day, 60-day, and 90-day — so you can plan remediation work across sprints without a separate planning session.
Strengths — What's Working Well
An explicit section covering what your architecture does right. Included because a review should be a conversation, not a pass/fail test — and because executives evaluating engineering quality need to see strengths alongside risks.
Risk Distribution
Finding counts broken down by severity (Critical / High / Medium / Low) across all six pillars to give leadership a quick read on overall exposure.
Data handling — your Terraform code stays private
You provide: your Terraform files (.tf) and a short architecture brief (plain text). We process: the Terraform code and brief to generate findings. No AWS credentials, no state file, no live account access is required or accepted.
Retention: your Terraform code is not stored after the review is delivered. The findings report is retained only to allow you to access it.
Processing: analysis runs in an isolated environment. Your code is not used to train models or shared with third parties.
Scope and limitations of Terraform architecture review
- · Application-layer authentication logic (not visible in Terraform)
- · Resources managed outside Terraform in the provided files
- · Runtime behavior and live traffic patterns
- · Compliance certification (SOC 2, ISO 27001) — findings map to frameworks but are not a formal audit
- · Non-Terraform infrastructure (CloudFormation support is on the roadmap)
Every ArchGuard report includes an Assumptions section that calls out exactly what was and wasn't visible in the provided inputs.
Frequently asked questions
Does ArchGuard run Terraform plan or apply?↓
No. ArchGuard reads your Terraform HCL files statically. It never connects to your AWS account, runs terraform plan, or executes any infrastructure changes.
Which AWS Well-Architected pillars does ArchGuard cover?↓
ArchGuard covers all six pillars: Security, Reliability, Cost Optimization, Performance Efficiency, Operational Excellence, and Sustainability.
Is ArchGuard a replacement for Checkov or tfsec?↓
No — Checkov and tfsec are IaC linters that catch specific configuration violations. ArchGuard provides architectural reasoning: why a pattern is risky, what the blast radius is, and how it maps to the AWS Well-Architected Framework. They are complementary.
How long does a review take?↓
Analysis completes in minutes. You receive an email with a PDF report when it's ready.
Does ArchGuard need access to my AWS account?↓
No. ArchGuard only reads the Terraform files you provide. No AWS credentials, no state file, and no live account access is required or accepted.
Is my Terraform code stored after the review?↓
No. Your Terraform code is deleted after the review is delivered. The findings report is retained only to allow you to access it. Your code is never used to train models or shared with third parties.
How ArchGuard compares to AWS's open-source analyzer
AWS maintains an open-source Well-Architected IaC Analyzer at github.com/aws-samples/well-architected-iac-analyzer. It is a capable tool and we recommend it for the right use cases. Here is when each tool fits.
| AWS WA IaC Analyzer (OSS) | ArchGuard | |
|---|---|---|
| Cost | Free + your Bedrock usage | Subscription or per-review |
| Setup | Deploy CloudFormation stack into your AWS account | Upload zip via web |
| Requires AWS account access | Yes — runs in your account | No — code-only upload |
| Multi-tenant / consultant use | Self-host per client | Built-in workspaces |
| Output | Web UI + assembled PDF | Branded PDF (deliverable) |
| Update cadence | Your responsibility | Continuous |
| Best for | Internal teams comfortable running OSS in their own account | Consultants and CTOs who need a hosted workflow and a deliverable they can hand to a client |
If you have one AWS account, time to deploy a stack, and want to run the analysis yourself, the AWS analyzer is excellent. If you're reviewing someone else's Terraform — a client's workload, an inherited repo, an AI-generated module — or you need a stakeholder-ready report on a schedule, ArchGuard is the workflow we built for that case.
Ready to get your review? View pricing or return to the homepage.