Terraform Architecture Review: A Complete Guide (2026)

Terraform is now the dominant way to describe AWS infrastructure. But “described in Terraform” and “correctly architected for your workload” are not the same thing. Plenty of infrastructure can be syntactically valid, pass every linter check, and still carry significant risk — because the risk lives in the relationships between resources, in what is absent, and in whether the configuration is appropriate for the workload it serves.

A Terraform architecture review is the process of evaluating infrastructure code against a structured framework — specifically the AWS Well-Architected Framework — to answer whether the architecture is sound for its intended purpose, not just whether individual attributes are correctly set.

This guide explains what that process involves, how it differs from the linting step you already run in CI, and how to execute it yourself — or with tooling — in a structured and repeatable way.

A Terraform architecture review is a structured evaluation of your infrastructure code against a set of architectural standards — typically the six pillars of the AWS Well-Architected Framework. It treats your Terraform as a system: reading relationships between resources, evaluating cross-service blast radius, and assessing whether the configuration as a whole is appropriate for the workload it describes.

It produces a prioritised list of findings — each one mapped to a WAF control, assigned a severity based on workload context, and accompanied by a remediation recommendation.

Crucially, the review is informed by workload context: the same Terraform configuration can be Low severity in a development environment and Critical in production. A Terraform architecture review begins by capturing this context — service type, environment, SLA, data sensitivity — and uses it to weight every finding accordingly.

Both processes read your Terraform. Both produce findings. They are not interchangeable.

Linters catch violations. Architecture reviews catch patterns.

Checkov asks: “Is this config valid?”
An architecture review asks: “Is this architecture sound for your workload?”

IaC linters — Checkov, Trivy, tfsec — apply a library of deterministic rules to individual resource attributes. Each rule evaluates one attribute against a known-bad condition. This is fast, reproducible, and free of false negatives for the conditions each rule covers. Checkov currently has over 1,000 rules for Terraform and runs in CI without any context about what the infrastructure does.

The ceiling on linting is structural. A linter cannot evaluate:

• ·Cross-resource relationships — whether an IAM role can reach a KMS key that encrypts a specific S3 bucket, and what that access path means for blast radius.
• ·Workload context — whether the environment is production or development, whether the SLA requires multi-AZ, whether the data is regulated.
• ·Absent resources — a Lambda without a Dead Letter Queue, an RDS instance without cross-region backup, a VPC with no Flow Logs. Linters read what is there; architecture reviews also evaluate what should be there but isn't.
• ·Pattern-level risks — overly broad IAM permissions that are not wildcards (and therefore pass CKV_AWS_40) but still violate the principle of least privilege for the specific workload.

For a detailed walkthrough of three specific Terraform examples that pass all linter checks but fail an architectural review, see What Checkov Catches — and What It Misses.

Not every change warrants a full review. The moments where it pays off most are:

The AWS Well-Architected Framework is the structured standard that AWS uses for architecture reviews. It organises cloud architecture quality into six pillars, each containing a set of design principles and specific controls (called High Risk Issues, or HRIs).

Using the WAF as the review standard — rather than a custom checklist — means findings map to the same controls that AWS Partner Network consultants, AWS Solutions Architects, and the AWS Well-Architected Tool use. This makes the output meaningful to stakeholders who are familiar with the framework, and ensures the review covers the full scope of architectural risk, not just security.

The Security pillar covers identity and access management, detection, infrastructure protection, data protection, and incident response. For Terraform, the highest-impact controls are around IAM (SEC 2: grant least privilege; SEC 3: no long-lived credentials), network protection (SEC 5: network layers; SEC 6: no unnecessary connectivity), and data protection (SEC 8: encryption at rest and in transit).

The Security pillar is where linting coverage is highest — most Checkov rules map to Security controls. But even here there are gaps: linters cannot evaluate IAM blast radius, principal scope breadth in bucket policies, or whether VPC endpoint policies restrict access appropriately.

The Reliability pillar covers service quotas, network topology, workload architecture, change management, and failure management. Key Terraform controls: REL 6 (distribute workloads across multiple AZs), REL 7 (deploy Auto Scaling Groups with appropriate capacity), REL 8 (use load balancers for static stability), REL 9 (back up data at the correct recovery point objective), and REL 10 (use fault isolation boundaries).

The Reliability pillar is where linting coverage is weakest. Checkov has almost no rules that check for multi-AZ configuration, minimum instance counts, or backup retention against SLA requirements. These are the most common source of architectural findings in production Terraform.

The Cost Optimization pillar covers cloud financial management, cost-effective resources, demand management, and optimisation over time. Key Terraform controls: COST 1 (implement cloud financial management practices — including tagging), COST 5 (select the correct resource type), and COST 6 (select the correct resource size).

For Terraform, cost findings are almost entirely absent from linters. The most common findings: untagged resources (making cost attribution impossible), oversized EC2 instances, and resources without lifecycle policies for data that could be tiered to cheaper storage.

The Operational Excellence pillar covers organisation, prepare, operate, and evolve. For Terraform, the highest-impact controls are OPS 7 (understand workload health — CloudWatch alarms on error rates and latency) and OPS 11 (learn from operational events — Dead Letter Queues, structured logging, SNS alerting).

Observability infrastructure — CloudWatch alarms, log groups with retention periods, SNS topics for alerting — is entirely invisible to IaC linters. These are some of the most valuable findings a Terraform architecture review produces, because silent failures are the hardest incidents to diagnose.

The Performance Efficiency pillar covers selection of the right resource types, reviewing resource configurations over time, and performance monitoring. In Terraform, this surfaces primarily as instance type selection, cache layer configuration, and database instance sizing relative to query patterns.

The Sustainability pillar (added to the WAF in 2021) covers minimising the environmental impact of cloud workloads — right-sizing, Graviton instance selection, and avoiding idle resources. Both pillars are lower-priority than Security, Reliability, and Cost for most first-time reviews, but are worth including in the scope for mature workloads.

A full review reads all Terraform resources in scope and evaluates them across six domain areas that map to the WAF pillars. Below is what each domain area covers, with a representative HCL example showing the type of finding that only surfaces through architectural review — not linting.

IAM review covers role trust policies, permission boundaries, managed policy attachments, and inline policies. The architectural concern goes beyond “are there wildcard actions?” — it asks whether the permissions granted are appropriate for what the principal actually needs to do.

The following Lambda execution role passes all Checkov IAM rules: no wildcard actions, no AdministratorAccess managed policy. The architectural finding is that two of the four actions are unnecessary for a read-only function — and their presence increases blast radius if the role is compromised.

Network review covers VPC structure, subnet segmentation, security group rules, NACLs, VPC endpoints, and routing tables. Linting covers the most obvious violations: 0.0.0.0/0 on port 22 or 3389, missing VPC flow logs flag. Architectural review goes further.

Common architectural network findings:

• ·Security groups using /8 or /16 CIDRs that cover entire internal networks, not specific service CIDRs — passes linters, violates defense-in-depth.
• ·RDS instances in a public subnet even when public_access = false — the route exists even if currently blocked.
• ·No VPC endpoint for S3 or DynamoDB — traffic routes through the internet gateway unnecessarily, increasing latency and egress cost.
• ·Single NAT Gateway serving multiple AZs — a NAT Gateway AZ failure takes all private instances offline, not just those in its AZ.

Storage review covers S3 bucket configuration (encryption, access logging, lifecycle policies, versioning, bucket policies), EBS volume encryption, RDS storage encryption and backup, and Secrets Manager vs. plaintext configuration values.

Checkov covers encryption-at-rest and public access blocks well. Architectural review adds: does the S3 lifecycle policy match the data retention requirements of the workload? Is access logging enabled — a WAF SEC 4 control that most linters do not enforce? Is the KMS key customer-managed (with rotation) or AWS-managed? For regulated data, this distinction matters for compliance.

For a complete technical walkthrough of S3 encryption requirements in the Well-Architected Security pillar, see the upcoming post on S3 Encryption in Terraform: What the Well-Architected Framework Actually Requires.

The five most common Terraform misconfigurations that fail a Well-Architected Security review — including S3 and IAM — are covered in detail in The Five Terraform Misconfigurations That Fail an AWS Well-Architected Security Review.

Compute review covers EC2 Auto Scaling Group configuration, ECS service deployment settings, Lambda concurrency and timeout settings, and instance type selection. This is the domain with the largest linting gap: almost no Checkov rules evaluate fault tolerance, AZ distribution, or minimum capacity.

Cost review covers resource tagging (necessary for attribution), instance type and size selection, data transfer architecture, and the presence of cost monitoring resources (AWS Budgets, CloudWatch billing alarms).

The most universal cost finding is missing tags. Without consistent tagging, cost cannot be attributed to the service, team, or environment that generated it — making cost optimisation decisions impossible.

Observability review covers CloudWatch alarms, log group configuration (retention periods and structured format), SNS topic alerting chains, and Lambda Dead Letter Queue configuration. This is the domain where linting coverage is effectively zero: no Checkov rule checks for the presence of CloudWatch alarms on any resource type.

A repeatable review process has six steps. Following them in order prevents the most common failure mode: conflating linting findings with architectural findings and producing a report that mixes the two without distinguishing severity or remediation effort.

The following checklist covers the highest-impact controls across the four primary WAF pillars for most Terraform workloads. It is not exhaustive — the full AWS Well-Architected Framework contains over 300 controls — but it covers the findings that appear most frequently in production Terraform reviews.

These five patterns appear consistently in production Terraform reviews. All five pass standard linting. All five carry real architectural risk.

No single tool covers the full scope of a Terraform architecture review. The current landscape splits across two categories: static linters (fast, free, CI-native, attribute-level) and architectural review tools (contextual, WAF-aligned, workload-aware). The right answer for most teams is both layers, not a choice between them.

Checkov — open source, maintained by Bridgecrew (Prisma Cloud), the most widely used Terraform linter. Over 1,000 checks for Terraform, fast CI integration, SARIF output support for GitHub Advanced Security. The right tool for the attribute-level linting layer. Use it.

Trivy — broad scanner covering container images, Terraform IaC, OS packages, and SBOM. Absorbed the tfsec IaC capability in 2023. Note: in March 2026, a supply chain attack on Trivy’s GitHub Actions distribution affected 75 of 76 published tags — if you use Trivy in CI, pin to a specific verified digest rather than a floating tag.

Terrascan — archived by Tenable in November 2025 and no longer maintained. Teams using Terrascan should migrate to Trivy or Checkov.

AWS Trusted Advisor — runtime checks against your deployed AWS environment. Useful for catching live issues that Terraform does not describe (idle resources, underutilised instances). Not Terraform-native and requires Business or Enterprise support tier for the full check library.

ArchGuard — uploads your Terraform and returns a WAF-aligned PDF report covering Security, Reliability, Cost, and Operational Excellence findings with contextual severity based on your workload. Designed to complement, not replace, your existing linting layer. See a sample report.