Terraform makes infrastructure reproducible.
But a successful terraform plan does not necessarily mean that an infrastructure configuration is secure, resilient, or cost-efficient.
Terraform can tell you what is going to change.
It does not automatically tell you whether the resulting architecture is a good one.
Here are five examples.
1. Publicly exposed sensitive ports
A security group can technically be valid Terraform while exposing SSH or another sensitive service to 0.0.0.0/0.
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
The configuration can deploy successfully.
The security problem is architectural, not syntactical.
The important question is not:
"Is this valid Terraform?"
It is:
"Should this service really be reachable from the entire internet?"
2. Public storage
An S3 bucket can also be configured as public without Terraform considering the configuration invalid.
resource "aws_s3_bucket" "uploads" {
bucket = "example-bucket"
acl = "public-read"
}
Whether this is acceptable depends on the workload.
For sensitive or internal data, however, public access can create serious security and compliance problems.
This is why infrastructure analysis should consider the security implications of resource configuration, not only Terraform syntax.
3. RDS without Multi-AZ
A database does not need to be "broken" to create an availability problem.
For example:
resource "aws_db_instance" "database" {
engine = "postgres"
multi_az = false
}
Terraform can deploy this configuration normally.
The important question is whether the workload actually requires higher availability.
This is also an example where blindly flagging a missing attribute can create false positives.
If multi_az is not explicitly configured, the analyzer may not have enough information to conclude that the configuration is wrong.
A better analyzer distinguishes between:
- explicitly disabled
- explicitly enabled
- not specified
That distinction matters.
4. Unnecessary NAT Gateway traffic
NAT Gateways can become a meaningful source of infrastructure cost.
A configuration may contain a NAT Gateway while traffic to supported AWS services could potentially use VPC endpoints instead.
For example, S3 and DynamoDB support gateway endpoints.
The important point is not:
"Every NAT Gateway is bad."
It isn't.
The useful question is:
"Which traffic actually needs to traverse the NAT Gateway?"
A cost analyzer should identify this as an optimization opportunity rather than automatically declaring the architecture wrong.
5. EBS or database storage optimization
Storage configuration can also contain optimization opportunities.
For example, an older EBS volume type may be a candidate for migration when a newer volume type satisfies the workload requirements.
The same principle applies to database storage where supported.
Again, this is not necessarily a "security vulnerability."
It is a FinOps opportunity.
A useful infrastructure analyzer should distinguish between:
- security risks
- availability risks
- compliance risks
- cost optimization opportunities
rather than putting everything into one generic risk category.
The bigger lesson
Terraform validates infrastructure configuration.
It does not replace infrastructure review.
A configuration can be:
- syntactically valid
- successfully planned
- successfully deployed
and still have:
- unnecessary public exposure
- weak resilience
- compliance concerns
- avoidable cloud costs
That is why infrastructure analysis should happen before deployment, not only after something goes wrong.
Conclusion
The goal should not be to find as many warnings as possible.
The goal should be to find the warnings that actually matter — while avoiding false positives.
A good infrastructure analyzer should therefore understand context, distinguish explicit configuration from missing configuration, and explain why a finding matters.
That is much more useful than simply reporting that a Terraform resource contains a particular attribute.
StageAuto is being developed around this idea: analyze Terraform infrastructure before deployment and surface security, architecture, compliance, and FinOps risks that may otherwise be overlooked.
Top comments (0)