DEV Community: Guilherme Marochio

5 Terraform Infrastructure Risks That Can Survive `terraform plan`

Guilherme Marochio — Thu, 13 Aug 2026 22:48:35 +0000

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.

https://stageauto-site.netlify.app

3 Terraform Architecture Decisions That Matter More Than Most Engineers Think

Guilherme Marochio — Sun, 26 Jul 2026 16:32:46 +0000

Terraform is often discussed as a deployment tool.

But in practice, the most important part of Terraform is not whether the code applies successfully.

It's whether the resulting infrastructure is easy to understand, secure to operate, and simple to maintain over time.

Here are three architecture decisions that matter a lot more than they first appear:

Boundary clarity

When public and private resources are mixed too loosely, it becomes harder to reason about exposure. Clear boundaries reduce confusion and improve security reviews.

Resource consistency

Infrastructure becomes much easier to manage when related components follow predictable patterns. Inconsistency increases cognitive load and makes reviews slower.

Risk visibility

A configuration can be technically valid and still create an environment that is difficult to secure or operate. Architecture decisions should make risk easier to see early.

The best Terraform designs are not the ones that only deploy successfully.

They are the ones that remain understandable when the environment grows.

That is usually where long-term operational quality starts.

Website:
https://stageauto-site.netlify.app

5 Terraform Mistakes I Keep Seeing in AWS Projects

Guilherme Marochio — Tue, 07 Jul 2026 15:20:01 +0000

Infrastructure usually doesn't fail because of Terraform itself.

Most issues come from configuration choices that look harmless during development but become expensive later.

Here are five common findings I keep seeing in AWS Terraform projects.

1. Public Security Groups

Opening sensitive ports to the internet increases the attack surface and can expose production resources.

2. Public S3 Buckets

Accidentally exposing storage is still one of the most common cloud security issues.

3. HTTP Without HTTPS

Encrypting traffic should be the default. Leaving applications accessible only through HTTP exposes data in transit.

4. Storage Without Encryption

Databases and storage services should always protect data at rest.

5. No Bucket Versioning

Versioning helps recover from accidental deletions, overwrites and even ransomware scenarios.

None of these problems are particularly difficult to fix.

The challenge is identifying them before they reach production.

That's why infrastructure reviews before deployment can save a significant amount of time, money and operational risk.

Website:

https://stageauto-site.netlify.app

Example Report:

https://stageauto-site.netlify.app/report-example.pdf

5 Terraform Architecture Decisions That Matter More Than Most Engineers Think

Guilherme Marochio — Wed, 01 Jul 2026 23:16:38 +0000

Terraform helps teams deploy infrastructure faster.

But some architecture decisions have long-term consequences that are easy to overlook.

A few examples:

• Enabling versioning for critical S3 buckets

• Designing for high availability (Multi-AZ)

• Enforcing HTTPS from the beginning

• Using encryption as a default, not an afterthought

• Reviewing cost implications before scaling

Infrastructure isn't only about making things work.

It's also about making them secure, resilient, and maintainable over time.

These are some of the patterns I keep thinking about while building StageAuto and reviewing Terraform environments.

What architecture decision do you think teams underestimate the most?

Website:

https://stageauto-site.netlify.app

5 Terraform Security Mistakes That Appear in Real Infrastructure Reviews

Guilherme Marochio — Tue, 23 Jun 2026 15:48:38 +0000

Terraform makes infrastructure deployment fast.

But speed also makes configuration mistakes easier to propagate.

During infrastructure reviews, some issues appear repeatedly:

• Public security groups exposing unnecessary ports
• Missing encryption for storage and databases
• Disabled versioning on S3 buckets
• Missing HTTPS enforcement
• Weak architecture choices affecting availability

Most of these problems are simple to fix.

The challenge is finding them before production.

That's exactly the idea behind automated Terraform reviews: reducing operational and security risks before deployment.

Which Terraform issue do you see most often?

Example report:
https://stageauto-site.netlify.app/report-example.pdf

StageAuto:
https://stageauto-site.netlify.app

Common Terraform Risks I Keep Seeing in AWS Environments

Guilherme Marochio — Fri, 12 Jun 2026 21:38:46 +0000

Common Terraform Risks I Keep Seeing in AWS Environments

Terraform makes AWS infrastructure easier to manage, but it also makes it easy to accidentally deploy security and compliance issues at scale.

After reviewing many Terraform configurations, some patterns appear over and over again.

1. Publicly Exposed Resources

One of the most common findings is infrastructure that becomes reachable from the internet without strict controls.

Examples:

Security Groups allowing unrestricted access
Public S3 buckets
Publicly accessible databases
Missing network segmentation

These issues are often created during testing and remain in production longer than expected.

2. Missing Encryption

Encryption is available almost everywhere in AWS, yet many environments still deploy resources without it.

Common examples include:

Unencrypted S3 buckets
Unencrypted EBS volumes
Unencrypted RDS instances

While these configurations may function correctly, they increase risk and can create compliance concerns.

3. Compliance Gaps

Organizations frequently aim to align with frameworks such as:

CIS Benchmarks
SOC 2
ISO 27001

However, Terraform configurations often contain settings that drift away from those recommendations over time.

Regular infrastructure reviews help identify these gaps before they become audit findings.

Why This Matters

Infrastructure issues are usually much cheaper to fix before deployment than after production incidents occur.

Even small misconfigurations can lead to:

Security exposure
Compliance findings
Increased operational risk
Higher remediation costs

Below are examples of findings generated during Terraform infrastructure reviews.

If you're interested in Terraform security and compliance analysis, I'd love to hear what risks you encounter most often in AWS environments.

Website:
https://stageauto-site.netlify.app

Example Report:
https://stageauto-site.netlify.app/report-example.pdf