AWS Well-Architected · Terraform

The Well-Architected Review your AWS SA doesn't have time for.

Your Terraform, reviewed by AI. Decided by you.

ArchGuard takes your Terraform code and runs a full Well-Architected Review across all six WAFR pillars — delivered within one business day, not weeks. Unlike Checkov or Trivy, which tell you what's wrong, ArchGuard tells you why it matters for your specific workload — and it never touches your infrastructure.

We never write to your state file, never create PRs, never touch your infrastructure. Every finding is specific, reviewable, and linked to AWS Well-Architected guidance.

Created by an AWS Golden Jacket holder

Project

synthr-api — production

HIGH RISK

Security

22

Reliability

42

Cost

92

Performance

92

Operations

69

Sustainability

97

3 Critical5 High6 Medium1 Low

CRITICAL · Security

Immediate

RDS publicly accessible with security group open to 0.0.0.0/0

aws_db_instance.main has publicly_accessible = true and aws_security_group.rds allows TCP 5432 from 0.0.0.0/0 — production Postgres reachable from the internet

Why it matters:Any actor on the internet can attempt auth directly against the production database. Combined with plaintext DB passwords in environment variables, a breach means full data exfiltration.

Blast radius: Full compromise of all application data, job records, and user information

HIGH · Reliability

Immediate

SQS visibility timeout shorter than Lambda worker timeout

No visibility_timeout_seconds set (defaults 30s) vs Lambda timeout = 300s — messages redelivered mid-processing, causing duplicate job execution

Why it matters:A message that causes the worker to run for more than 30s is redelivered repeatedly, writing duplicate results to S3 and DynamoDB and saturating Lambda concurrency.

Blast radius: Entire document processing pipeline; DynamoDB and S3 filled with duplicate entries

Covers 40+ AWS services
Mapped to CIS AWS v3.0, NIST 800-53, SOC 2 & PCI DSS
Terraform-first — .tf files and plan JSON accepted
Expert-informed, not just linting

The Problem

Most AWS teams discover architecture mistakes only after they become expensive

Without a dedicated architect, critical issues stay hidden until they cause an outage, a breach, or a surprise bill.

Cost surprises

Unattached volumes, oversized instances, and misconfigured queues quietly drain your budget. You notice it in the bill, not in the code.

Security blind spots

Overpermissioned IAM roles with wildcard access, publicly reachable databases, open security groups — the blast radius no one mapped.

Reliability gaps

Single points of failure, missing backups, misconfigured health checks. Checkov passes. Your architecture is still broken.

No sanity check before launch

Inherited infrastructure, AI-generated Terraform, a contractor's codebase — and no second opinion before it goes to production.

How It Works

From upload to structured findings in under 24 hours

01

Upload Terraform

Share your .tf files or a post-plan JSON (terraform plan -out=tfplan.json). No AWS credentials required.

02

Add workload context

Describe your architecture in a short brief: team size, environment, key concerns.

03

Receive structured review

Get a prioritized findings report across all six WAFR pillars — with Terraform fix examples, compliance tags, and a 30/60/90-day remediation roadmap — within one business day.

Deliverables

What your ArchGuard report includes

Executive summary

Plain-English risk verdict, top 3–5 business risks ranked by impact, a well-architected score per pillar, and a strengths section — written to share with non-technical stakeholders.

Prioritized findings with blast-radius

Every finding includes severity, the specific Terraform resource and attribute, a "Why it matters" explanation, and blast-radius analysis for Critical and High findings.

Terraform fix examples

Each finding includes a secure Terraform code example — vulnerable config versus the remediated version — ready to adapt and apply directly.

Compliance mapping

Findings are tagged with relevant control references from CIS AWS Foundations Benchmark v3.0, NIST 800-53, SOC 2, and PCI DSS.

Remediation roadmap

Findings grouped into four action phases — Immediate, 30-day, 60-day, and 90-day — so remediation work fits into existing sprint planning.

Risk distribution

Finding counts by severity (Critical / High / Medium / Low) across all six WAFR pillars, giving leadership a quick read on overall exposure.

Sample Report

See what a real ArchGuard review looks like

Based on a real Terraform workload — names changed.

Project

synthr-api — production

HIGH RISK

Security

22

Reliability

42

Cost

92

Performance

92

Operations

69

Sustainability

97

3 Critical5 High6 Medium1 Low

CRITICAL · Security

Immediate

RDS publicly accessible with security group open to 0.0.0.0/0

aws_db_instance.main has publicly_accessible = true and aws_security_group.rds allows TCP 5432 from 0.0.0.0/0 — production Postgres reachable from the internet

Why it matters:Any actor on the internet can attempt auth directly against the production database. Combined with plaintext DB passwords in environment variables, a breach means full data exfiltration.

Blast radius: Full compromise of all application data, job records, and user information

HIGH · Reliability

Immediate

SQS visibility timeout shorter than Lambda worker timeout

No visibility_timeout_seconds set (defaults 30s) vs Lambda timeout = 300s — messages redelivered mid-processing, causing duplicate job execution

Why it matters:A message that causes the worker to run for more than 30s is redelivered repeatedly, writing duplicate results to S3 and DynamoDB and saturating Lambda concurrency.

Blast radius: Entire document processing pipeline; DynamoDB and S3 filled with duplicate entries

HIGH · Operational Excellence

30-day

No CloudWatch alarms defined — Lambda, SQS, and RDS failures are silent

Zero aws_cloudwatch_metric_alarm resources. No alarms for Lambda errors/throttles, SQS queue depth, or RDS CPU/storage/connections

Why it matters:A Lambda error spike, stalled SQS queue, or full RDS disk goes completely undetected until customers report failures. Mean time to detect is unbounded.

MEDIUM · Reliability

30-day

DynamoDB sessions table has no TTL and no point-in-time recovery

aws_dynamodb_table.sessions has no ttl block and no point_in_time_recovery — session tokens accumulate indefinitely and the table cannot be restored after accidental writes

Why it matters:Without TTL the sessions table grows unboundedly, increasing storage costs and query latency. Without PITR, a bug corrupting session records forces a full re-authentication of all users.

Why ArchGuard

More than a linter. Architecture review that explains the why.

Checkov and tfsec already run in your CI/CD pipeline — keep them. ArchGuard is the architectural layer above: it takes your whole Terraform workload and reviews whether the components fit together correctly against the AWS Well-Architected Framework, whether your design handles failure, and whether you're spending money in the right places. Checkov and tfsec catch individual resource misconfigurations. ArchGuard catches the architectural anti-patterns they can't see — and explains the blast radius when they matter. What Checkov misses →

Architecture-level reasoning

Understands how your components interact — not just whether individual resources pass config checks. Catches the blast radius and drift that linters miss.

Terraform-first

Reads your actual IaC. Findings are grounded in what you've defined, not what AWS reports post-deploy.

Evidence-based findings

Every finding includes the specific Terraform resource, the evidence, and why it matters for your workload. Not a generic checklist.

Fix examples, not just flags

Every finding includes a secure Terraform code example — the vulnerable config alongside the remediated version, ready to adapt into a PR. Not a list of things to Google.

Read how the analysis works →

FAQ

Common questions

No. ArchGuard is a structured first-pass that surfaces high-impact issues quickly. For complex migrations or compliance-critical workloads, it complements — not replaces — a full engagement.

All six: Security, Reliability, Cost Optimization, Performance Efficiency, Operational Excellence, and Sustainability. Each finding is mapped to its pillar, and the report includes a per-pillar score so you can see at a glance where your workload is strongest and weakest.

Yes. Every finding includes a concrete recommendation and a secure Terraform code example you can adapt directly. For Critical and High findings, the report also includes blast-radius analysis explaining which downstream resources or services are affected.

Yes. Each finding is tagged with the 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.

Checkov and tfsec catch individual resource misconfigurations through rule-based linting. ArchGuard combines deterministic checks with AI-assisted reasoning that considers how your components interact, what your workload brief implies about acceptable risk, and what architectural anti-patterns a linter can't see. The two approaches are complementary.

It's a complement, not a replacement. Checkov and tfsec are fast, rule-based IaC linters — excellent at catching individual resource misconfigurations in CI/CD pipelines, and you should keep running them. ArchGuard operates at the architectural layer: it reviews how your Terraform components interact against the AWS Well-Architected Framework, includes blast-radius analysis, maps findings to compliance frameworks, and delivers a structured remediation roadmap. If you're looking for something that explains why a pattern is risky and what the downstream impact is — not just that a config value is wrong — that's what ArchGuard provides.

Yes. ArchGuard performs an IaC security audit against the AWS Well-Architected Security pillar — reviewing IAM least-privilege, security group ingress rules, public accessibility settings, encryption at rest and in transit, VPC topology, and secrets handling. Each security finding is tagged with relevant CIS AWS Foundations Benchmark v3.0, NIST 800-53, SOC 2, and PCI DSS controls, making it useful as supporting evidence in formal audits.

Yes. The Security pillar review covers the core Terraform security best practices: IAM roles scoped to least privilege, encrypted storage and in-transit settings, private resource accessibility, restricted security group ingress rules, secrets handling (no plaintext in outputs or variable defaults), and VPC network segmentation. Every finding includes a secure Terraform code example alongside the problematic configuration so you can remediate directly.

Terraform works best. CloudFormation support is on the roadmap. If you're partially using Terraform, we can still review what you have.

You'll receive a structured PDF report covering all six WAFR pillars, a prioritized remediation roadmap, and Terraform fix examples. Delivery is within one business day. For larger or more complex workloads we may send a quick async question first to clarify context.

Get a faster second opinion on your AWS architecture

What am I missing?

Most issues are fixable before they reach production. The expensive ones — the public database, the wildcard IAM role, the SQS timeout causing duplicate billing — are the ones you miss.