Static Analysis: The Spellchecker (`tflint`)

Catching Errors Before You Even Try

Before you run Terraform, you should check your code for obvious mistakes — the same way a spellchecker catches typos before you send an email. Static analysis tools read your code and flag problems without executing anything. No cloud credentials, no API calls, no cost.

tflint is a linter built specifically for Terraform. A linter is a tool that reads source code and reports issues based on a set of rules. tflint goes well beyond basic syntax checking:

• Deprecated syntax: Flags patterns that will break in future Terraform versions.
• Unused variables: Catches variables declared but never referenced, which clutter your code and confuse readers.
• Invalid resource arguments: For example, using an EC2 instance type like t2.nano in a region where it doesn't exist, or passing a string where a number is expected.
• Naming conventions: Enforces consistent naming across your codebase (e.g., all resources must use snake_case).
• Provider-specific rules: Via plugins, tflint can load rule sets for AWS, Azure, and GCP that know the valid values for cloud-specific arguments.

tflint runs in milliseconds and is the first line of defense in any CI pipeline. It catches the class of bugs that would otherwise only surface when Terraform tries to call the cloud API — which might be minutes into a terraform apply.

A typical tflint configuration enables the provider-specific plugin (AWS, in most cases) alongside whichever rules the team wants to enforce — a naming convention check, an unused-declaration check, and so on — and runs against the current directory with no arguments beyond an initial plugin download.

Key point: tflint is not a replacement for terraform validate. They are complementary. terraform validate checks that your HCL is syntactically correct and internally consistent (e.g., all referenced variables exist). tflint checks for semantic problems — things that are syntactically valid but logically wrong or risky. Run both.