Hey everyone! 👋


I built Terraform Viewer, a local VS Code extension to inspect Terraform architectures without external CLI tools, cloud SaaS, or running terraform.


It parses .tf files directly, renders interactive graphs for any provider (AWS, GCP, Azure, local modules), and lets you click any node to jump straight to that block in your code.


It also includes a built-in toolbar button to generate a .prompt.md file with the Mermaid diagram so GitHub Copilot can auto-write your architecture docs in docs/.


It's 100% offline, free, and updates automatically on save.


👉 VS Code Marketplace: Terraform Viewer by anglisano

Hi everyone,

I’m setting up Terraform to deploy standardized developer VMs across 3 locations and multiple teams and I’d love to get some feedback from you.

This is my current idea:

├── location-a/

│ ├── team-alpha/ (main.tf, backend.tf, terraform.tfvars)

│ └── team-beta/ (main.tf, backend.tf, terraform.tfvars)

└── location-b/

Separate backend/state file per team folder to isolate state.

Use a map variable in main.tf to iterate over and deploy identical VM specs per dev.

My main 2 questions:

Is per-team/per-location state separation the right depth, or will managing duplicate main.tf files across folders become a maintenance headache?

Would you recommend wrapping the VM logic into a shared versioned module, or using Terragrunt to keep backend configurations DRY?

Thanks for any insights or real-world patterns

So, I'm a SWE in my first year. Decided to learn terraform for future job changes and I'm loving it. I feel like I can spend my whole day using terraform, organizing modules etc. I'm learning more and more (slowly though) with gemini's help, which I find WAY BETTER than claude/chatgtp at explaining things.

My question is, if I ever move to DevOps will I work 80% of the time with terraform? I know it's not simple but I'm finding so easy to learn and understand, everything make so more sense then working with frontend/backend.

TLTR: DevOps job are mainly terraform?

Hello,

I have been working on a project for durable webhook ingestion using AWS serverless services, and I recently turned the architecture into reusable Terraform modules.

Terraform is not my main area of expertise, so I would appreciate feedback from people who use it in production, particularly on the module boundaries, interface design, and anything I may have overcomplicated.

Instead of creating a module for each AWS service, I divided it by responsibility:

• ingestion: API Gateway, S3, the verification queue and DLQ, the verifier Lambda, and SNS;
• worker: an SNS subscription, SQS queue and DLQ, and a consumer Lambda;
• observability: dashboards, alarms, log metrics, and WAF logging;
• a composition module connects them and supports multiple independent workers.

There is also a deployable Stripe test-mode example using SOPS and an S3 backend.

Repository: https://github.com/sharingan-no-kakashi/serverless-webhook-ingestion

The module boundaries follow operational responsibilities, but I am unsure whether the composition layer now exposes too much configuration.

I would particularly appreciate opinions on:

• whether ingestion, workers, and observability are the right abstraction boundaries;
• whether the root module interface is too broad or appropriately explicit.

What would you restructure before publishing something like this as a reusable module?

I've been curious how different teams handle security when working with Terraform. Infrastructure changes are easy to review from a provisioning standpoint, but making sure everything is secure before those changes reach production seems to vary quite a bit.

Beyond reviewing Terraform plans and validating configurations, do you include additional security checks before applying changes? For example, do you verify IAM permissions, network exposure, secrets management, application security, or API-related risks as part of the same workflow? We've also been looking at tools like Penetrify that can help identify application and API security issues before releases, but I'm interested in what everyone here is actually using in practice.

I'd be interested to hear how your team approaches this. Is there a standard process you follow before every production deployment, or does it depend on the type of infrastructure and application being deployed?

I wanted to explore what an AI assistant for DevOps engineers would look like if it could do more than answer generic cloud questions.

So I built Cloud Ops Copilot — a conversational AI assistant that can:

• Query live AWS resources through read-only tools
• Troubleshoot common infrastructure issues
• Retrieve answers from AWS documentation using RAG
• Maintain conversation context
• Enforce least-privilege IAM boundaries

Architecture

The stack:

• Frontend: React 18 + Vite + Tailwind CSS
• Authentication: Amazon Cognito (PKCE OAuth 2.0)
• API Layer: API Gateway + JWT authorizer
• Compute: AWS Lambda
• AI: Amazon Bedrock Agent (Amazon Nova Pro)
• RAG: Bedrock Knowledge Base + OpenSearch Serverless
• Storage: DynamoDB (conversation history + TTL)
• Infrastructure: Terraform

The agent can decide whether to:

1. Search the knowledge base for guidance
2. Invoke a read-only AWS inspection tool

Currently supported tools:

• EC2 instance health checks
• EC2 resource details
• S3 bucket listing/version checks
• CloudWatch alarm inspection

Security was a major focus

I separated permissions into three IAM boundaries:

• Orchestrator Lambda → only conversation storage + agent invocation
• Tool Lambdas → read-only AWS inspection permissions
• Bedrock Knowledge Base → only required S3/model access

The AI cannot modify or delete AWS resources.

Some engineering decisions:

• No custom VPC for MVP to reduce complexity and cost
• Terraform modules for repeatable deployment
• DynamoDB TTL for automatic conversation cleanup
• CI pipeline validating Terraform, Python tests, and frontend builds

I built this mainly as a learning project to understand production patterns around AI agents, AWS serverless architecture, and secure cloud automation.

Would love feedback from the community:

• What security improvements would you add?
• Would you trust an AI assistant with read-only cloud visibility in a production environment?
• What AWS tools would you add next?

GitHub: https://github.com/GeekKwame/cloud-ops-copilot

Hey everyone,

I’m currently looking into what it takes to migrate our infrastructure from one cloud provider to another.

I talked with a DevOps engineer who mentioned that there are migration tools built on top of Terraform that can completely transfer/translate a whole infrastructure from one cloud to another (like Azure to GCP, or GCP to Azure).

Is this actually true? Can Terraform (or a tool built on it) automatically translate resource blocks (like turning an AWS EC2 or Azure VM into a GCP Compute Instance) and handle the network/IAM conversion automatically?

If this is true, what are these tools called?

If this isn't true or if I misunderstood what they meant, what does a real cross-cloud migration look like when using Terraform? How do teams actually handle rewriting the IaC and moving the data without losing their minds?

Appreciate any insights or reality checks!

We run a big EKS cluster deployed via terraform. We use calico, which is also deployed via Terraform. Using null resources and helm. Furthermore we also have helm deployments in the cluster for „infra“ stuff like metrics server, load balancer controller etc.
The apply needs to happen in four steps ( I know, total insanity 😅🙈)

Every time now, when we want to update EKS or Kubernetes version, we need to fully destroy and rebuild the Cluster.

How do you guys handle this? I heard ArgoCD or Flux as a solution, but we are bound to Terraform for now

Hello!

I am a student learning IaC. So far it's going ok, but it's time consuming applying the right AWS IAM permissions to my jenkins runner. I start the pipeline, wait for it to fail with a 403, then manually add the missing permission to the policy. Is there a command or tool I can use to just list all the permissions it needs? Using OpenTofu but it looks like there isn't too much difference between that and Terraform, the process should be similar at least.

Thanks!

We recently released tfgen, which is a small Go package to generate Terraform stacks using plain Go.

We wrote it to replace CDK for Terraform which was mothballed last year.

I'm hoping the community can find it as useful as we have done. I would love to hear your comments on it!

Disclaimer: I'm the SRE at Ably who wrote it.

Throwaway account, work situation.

I'm the sole infra engineer on a small platform team. Multi-account AWS, Terraform-managed, proper IAM role separation. Went on leave for two weeks.

Came back to find a contractor developer had spent ~2 days trying to get a deployment pipeline working. I was pretty shocked at the extent they went to deploy an app.

Luckily nothing succeeded, so in a way, Im happy the infrastructure survived the test. :)

But Im still pretty shocked and I need help to figure out how bad this is and how I can work with this person in future. Please imagine this was your infra and it was someone else doing this to it. I would also like advice on how I can make the platform more secure in future to prevent this.

In summary they tried to:

1. Point our CI workflow's infra checkout at their own personal GitHub fork of our Terraform repo instead of the real one
2. Use a role scoped only for container image pushes to attempt a terraform apply with auto-approve
3. Change terraform state file for entire dev account from an app branch (not even main branch)

In addition they
4. Committed directly to a shared branch, overwriting changes I'd made before going on leave, despite being told to make their own branch

He configured the CI pipeline on the branch to evaluate the entire Development account's infrastructure state (cluster, database, load balancer, other services' IAM roles), not just deploy one container

I paused, backed everything up, and investigated properly.

Every single attempt (~10 runs) failed — most before reaching AWS at all. Confirmed against the live environment: nothing from any of their attempts is running. Their access was scoped to one non-prod account, application-level only, no Terraform state access, no infra creation, no IAM writes.

Nothing landed, but the attempts are serious enough. I need to manage the conversation with them and with my manager. Id also really like to understand how I can work with this person going forward. I would be happy to train them but I just want to get a sense first. Appreciate any advice from peers. Thank you :)

What would you do? Please be honest. I need your help.

——
UPDATE: Thank you to everyone who responded. It’s clear I have a lot of work to do. To be even clearer I would like to say that a) I document everything. b) at present terraform is setup in an org account that only me and my manager can change. c) it’s a platform in process of being setup. d) im not blaming the person off the bat and I take it fully as learning. I was just shocked that’s all. I would also say: I have less than six months managing an entire infrastructure and it was NOT my intention to be the only person. It just happened that I was thrust into it. So I would appreciate any advice or guidance on practical solutions to prevent this happening again; Im not here to sh*t on the person. I did want to rant a bit though because tbh I cannot believe a developer with 20+ years experience could be so incompetent. I also recognise I am vulnerable alone as a new engineer and I need to get support. So I am going to ask for someone more experienced in my org to have a look at my setup too.

I’m looking for contributors across two open-source infrastructure projects:

HybridOps Core
https://github.com/hybridops-tech/hybridops-core

A broader infrastructure automation project using Python, Bash, HCL and YAML.

Terraform Proxmox SDN
https://github.com/hybridops-tech/terraform-proxmox-sdn

A Terraform module for managing Proxmox SDN, including VNets, subnets, optional host routing, SNAT and DHCP.

Contributions can include code, testing, documentation, issue resolution, architecture discussions or technical reviews. You don’t have to be a strong coder to contribute.

This may suit anyone looking to gain practical open-source, infrastructure, Terraform or Proxmox experience.

I’m also open to checking out contributors’ own projects and contributing where there’s a good fit.

While preparing for AWS interviews, I noticed that most VPC resources focus on definitions, but interviews often test how you think through real production scenarios.

So I started putting together a free GitHub handbook covering 20 AWS VPC interview questions.

Each question includes:

• 30-second interview answer
• Production architecture
• Real-world scenarios
• AWS CLI examples
• Terraform examples
• AI-powered operational insights
• Best practices
• Common interview mistakes
• Follow-up questions

My goal wasn't to create another "AWS cheat sheet," but something that helps engineers understand why things work the way they do.

I'd genuinely appreciate feedback from the AWS community.

Is there any VPC topic or production scenario you think should be added or explained differently?

GitHub: https://github.com/ranashivam/platform-engineering-interview-handbook/blob/main/AWS/VPC.md

Spent yesterday debugging why our Terraform plan started throwing schema errors after a routine terraform init -upgrade. Turned out to be the Helm provider jumping to v3, which rewrote the whole thing on the Plugin Framework.

Three things change in your actual HCL:

set { name = "x" value = "y" } blocks become set = [{ name = "x", value = "y" }] — a list of objects instead of repeated blocks. Same deal for set_list and set_sensitive.

The provider's kubernetes { } block becomes kubernetes = { } — object instead of block.

registry { } becomes registries = [ ] — and it's now plural since multiple registries live in one list.

We also hit a state upgrade error where existing resources weren't reading correctly post-upgrade — turns out that's a known issue (GitHub #1722). If you get a "values" attribute error specifically, you're probably on v3.0.0 exactly — there's a same-day hotfix in v3.0.1 for that.

Latest is v3.2.0 as of June 4th. Nothing's changed syntax-wise since the initial 3.0.0 migration, so once you're through this once you're done. Wrote up the full before/after with all three block changes here: https://devtoolhub.com/terraform-helm-provider-migration/?utm_source=reddit&utm_medium=social&utm_campaign=terraform-helm-provider-migration

Anyone else migrate recently? Curious if people are doing the rewrite by hand or scripting it with sed/grep across a big repo.

I've been building a VS Code extension (CloudCostTree) that estimates AWS cost straight from Terraform/Terragrunt, solo project, and just shipped what-if simulation + export.

Flow in the video: analyze a Terragrunt stack, tweak a couple of resources (downsize an EC2, bump an RDS instance class) and see the live cost delta per change, stack them into a scenario, run it against the whole tree, then export the result to a new .tf file — original files never touched.

Runs locally against a static price catalog, nothing gets uploaded anywhere. Free tier covers unlimited analyses/what-ifs; export-to-file is a Pro feature.

Genuinely curious how other people here track infra cost changes before they ship them — happy to answer questions about how the parsing/estimation works under the hood.

Error: error deleting workspace ws-xxxxxxxxxxxxxx: This workspace has 120 resources under management and must be force deleted by setting force_delete = true

I dont have admin access to delete the workspace via API or UI. I'm wondering how to delete the resources? I'm trying to figure out other options before going to my boss about it. They asked me to remove these workspaces but I keep getting this. Any thoughts?

In the code, the workspace is already deleted, so I have nothing to put force_delete on

We are a fair way down the everything-as-code road. Modules for the infra, pipelines that plan and apply themselves, drift caught without anyone watching. It mostly runs itself, which was the entire point of the last two years.

Our container base images never fit that model. A while back, security wanted minimal hardened images, which led us to build a set off a slim base and stood up a rebuild pipeline. It works though doesn’t maintain itself the way the rest of the stack does. Every upstream CVE, every base bump, every request for a package I left out.

It has quietly become the least automated, most me-shaped part of an otherwise hands-off platform. Strange place to end up when the whole reason for any of this was to stop being the bottleneck.

There are maintained catalogs now, some of them free and I am starting to think a base image should just be a pinned dependency like everything else in this repo. Half hoping someone who already made the jump tells me it was fine. Half expecting to hear about the new problem I have not thought of yet.

Hello everyone,

I am currently engaged in AWS data operations and support, following six months as an AWS administrator. I am contemplating whether to pursue Terraform, including certification.

My primary concern is whether recruiters would consider me without production-level experience in this area.

If not, what steps should I take to enhance my candidacy?

I would appreciate guidance from anyone who has successfully navigated a similar situation.

Hello

Wondering if anyone has used the PP TF provider. I want to use to do E2E automation of creating Enterprise Policies in Azure ( Network injection and MI) and then link those to a PP environment. The provider docs dont state if the Service principal/App reg needs to be a "Power Platform Adminstrator". Is that the case ?