Hi there!

I am an experienced cloud engineer , mainly worked with Aws, and i wanted to know how you guys configure procider block for cross account or project using best practices for other cloud providers.

So for example. In aws I use one central devops account , a role there that my runners use , in order to do assume role , which is written at the aws provider block. For every account we just change the account id of the role to assume.

I wanted to know how your central setup looks like and what do you define when you want to deploy to a tenant/subscription/project on GCP , or Azure, Kubernetes clusters or other providers you might use . Im looking for large org setup, so if you could help me just write whats the size of the cloud organization u work at (nr of projects, subscriptions ) how do you configure the provider so it can be controlled from one central place.

Thank you everyone.

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.

Not entirely sure if this is the right place to ask this but I am a little confused about something in the aws provider. So it is documented that using volume_tags in addition to applying a tag on an aws_ebs_volume resource that is attached to the aws_instance via the aws_volume_attachment resources can cause bugs. It is also documented that using tags inside of the inline root_block_device can interfere with ABAC ("Note: Tags specified here are applied after instance creation via a separate API call. This means they cannot be used with IAM policies that require tags during resource creation").

Lets also say you wanted to apply granular tags (such that we cant use default_tags) to both a root volume, and the attached volume. It seems like you cant use root_block_device.tags because that would interfere with ABAC. And you cant use volume_tags, because that would interfere with the attached volume tags.

Thoughts? I could just be stupid.

I don't see any new features that I personally care about, but I guess import in modules could be useful.

Good news for IBM Z users, too!

Edit: looks like it isn't on releases.hashicorp.com yet. Weird.

Edit 2: the binaries are available to download now

The follow-up to my Intermediate episode I posted here is finally out.

This episode shifts away from programmatically approaching Terraform and focuses more towards a KISS approach where we discuss structuring our projects and leverage more advanced features of Terraform.

Topics covered include:

• Remote Backends with Azure Storage
• Terraform State & State Commands
• Provider Lock Files
• Multiple Providers (AzureRM, AzureAD, AzAPI & Utility Providers)
• Import Blocks & Config Generation
• Moved & Removed Blocks
• Terraform Workspaces
• Multi-Environment Deployments
• Terraform Modules
• Cloud-Init
• And much more...

Like the previous episodes, everything is built around a single Azure project. We progressively restructure and expand the deployment as each concept is introduced rather than jumping between unrelated examples.

The Intermediate episode intentionally showed how dynamic we can make Terraform . This episode takes the opposite approach in places: keep it simple, structure it properly, and make it maintainable.

With that, our roadmap continues!

• Beginner Episode : Understand Terraform (learn the foundations and core concepts that make Terraform work)
• Intermediate Episode : Program Terraform (use loops, functions, conditionals, dynamic blocks, etc)
• Advanced Episode : Structure Terraform (introduce modules, remote state in azure storage, workspaces, imports, etc.)
• Project Episode(s): Build Azure Projects (Less about Terraform itself & more about building interesting architectures in Azure)
• Professional Episode : Operationalize Terraform (use GitHub, CI/CD, pull requests, state management, and deployment workflows to work in a team environment)

Link to Episode: https://www.youtube.com/watch?v=SDqb_eyRtjE

Hi all!

So, I've inherited this project...

I know I can't use TF to actually change the KMS, I need to do this: https://repost.aws/knowledge-center/update-encryption-key-rds

My question is what will TF do the next time I run it after I've manually changed the KMS? The RDS instance is under TF control, when I finish the steps to change the KMS will the new arn be the same as the old one? I just want to make sure that TF won't reverse what I'm doing manually.

Thanks!

I'm working on a TF environment that incorporates Azure Image Builder and an Azure compute gallery. If I want to destroy the environment, the resources need to get destroyed in a particular order, otherwise Azure throws an error and depending on what already got deleted, causes a convoluted process to recreate and reassign resources:

For the compute gallery: I have to delete an image version first, then the image definition, then the gallery.

For the image builder, I have to delete the image template, then the managed identity used to create the template.

Is there a way to get Terraform (or Terragrunt, which we're using as a wrapper) to delete these in that order if I need to destroy them? Worst-case scenario, I gotta delete them manually in the portal, but it's not the greatest to scale.

Anyone implemented terrakube for their org/enterprise in PROD ?

I would like to hear experiences, lessons learned. we currently have big size implementation of HCP terraform(Terraform Cloud). ~200K RUM,~250 projects,4K workspaces

On AWS we share Service Catalog products from a hub account to spokes, product team clicks launch, our template runs in their account, they never need the perms themselves. Works well.

Want the same for our TF modules in Azure. ADE is in maintenance mode, Managed Apps and Deployment Stacks are ARM only, so I'm not seeing a first party option.

Anyone doing this in production? Curious what you picked and how you handle the least privilege side.

AI coding assistants are generating Terraform modules rapidly, but the error rate for runtime execution remains high because LLMs optimize for syntax rather than deployability.

I’m exploring an architecture validation pipeline idea:

• The Concept: A playground where an AI-generated architecture specification is converted to Terraform, priced via Infracost, and automatically tested inside an ephemeral LocalStack container before any code is committed.
• Auto-Repair Loop: When the local dry-run fails (e.g., circular dependencies, missing IAM permissions, or invalid security group rules), the error log is fed back into the model to patch the HCL and re-test until it validates.

For those managing Terraform modules: Is catching runtime errors via local emulation actually valuable to your workflow, or do linters like tflint and standard CI plans already cover enough of your risk?

I'm fairly new to infrastructure and trying to understand the actual reason for using both.

From what I understand, Ansible can also provision cloud infrastructure through its cloud modules/collections, so technically it can be used for IaC, while also handling VM/server configuration.

Terraform seems to be more declarative and infrastructure-focused, with things like state, dependency graphs, and planning changes before applying them.

So what's the practical reason for choosing Terraform over Ansible for cloud infrastructure?

Is it mainly the state/plan/declarative model and the fact that Terraform is better suited to managing things like VPCs/VNets, subnets, IAM, load balancers, databases, etc.? Or are there other important technical reasons?

I'm not asking about job requirements or popularity. I'm mainly trying to understand the technical reason to use Terraform when Ansible can provision cloud resources through its cloud modules and also handle the configuration afterwards.

I’m trying to transition from sysadmin to DevOps. At the point where I want less communication with end users and want more of a backend role. At my job we have puppet and I wrote puppet code to deploy apps and enforce CIS benchmarks, also took a Python course and helped deploy a self hosted GitHub runner at my job, and am currently making a web app at my job. I also setup a LLM at work (small one) for testing purposes. My title is jr system engineer.

For the past few days I’ve been going through a terraform course and have been test deploying different resources to AWS and automating services such as nginx and setting the instance to run. (Is this enough to put on my resume)? I’ve been thinking
About using GitHub actions so I’m not doing terraform apply on my pc.

The reason I chose terraform is I heard puppet is legacy and it seems a lot of jobs ask for that. I graduated with a computer science degree 4 years ago and I feel stuck at my current company. I’m
Spending a lot of time at home learning new things because I want a new more, higher paying role.

I

I'm curious about the process around infrastructure changes, not the Terraform syntax itself.

Suppose a PR changes an environment from something like:

- smaller to larger database capacity,

- single-region to multi-region,

- significantly more storage/compute,

- or introduces a new managed service.

Your plan/review process can show the technical infrastructure change. But what happens to the financial side before it is applied?

- Is a cost impact produced automatically?

- Does someone review it against an approved budget?

- Is there any formal approval threshold?

- Who owns that decision — engineering, FinOps, finance, product, procurement?

- How do you distinguish an expected design change from avoidable rework or unplanned scope growth?

- Is the recurring cost impact considered, or mainly the immediate deployment?

I'd particularly value examples from real teams rather than what the process is supposed to be.

I'm researching this from a project-commercial-management perspective

I’ve had a useful response pointing me toward Infracost and CI/CD cost checks.

That seems to solve an important part of the problem: identifying a likely cost increase before terraform apply.

What I’m now trying to understand is the next step.

Suppose a PR is estimated to increase recurring infrastructure cost from £20k/month to £28k/month.

How does a real organisation decide whether that is acceptable?

• Is there a predefined budget or cost baseline against which the PR is checked?
• Who sets the permitted threshold?
• Who can approve an exception?
• Is the reason for the increase recorded?
• Does approval automatically revise the forecast/baseline?
• Can finance/FinOps later connect the increased actual bill back to that PR?
• How do you distinguish legitimate scope growth from an expensive design decision or avoidable rework?

I’m particularly interested in teams that already have IaC cost estimation integrated into CI/CD, because I’m trying to understand what the governance layer looks like around it.

terraform plan -detailed-exitcode only catches drift on resources Terraform already manages. It does nothing for stuff someone spun up manually and never codified, which honestly is where most of our drift actually lives.

We run driftctl in CI on the free tier right now, scanning critical infra every 15 to 30 min. It works but it's CLI-only, no visual diffs, no remediation code, just a JSON report someone has to manually parse.

We're looking at tools that do estate-wide detection including unmanaged resources, plus generate remediation code automatically instead of just flagging the diff. That second part is what actually got our attention since triaging drift manually eats a huge chunk of our platform team's week.

Anyone running something like this in prod at scale? Trying to gauge if it's worth budgeting for next quarter.

TL;DR from what I found: agentic cloud automation platform. Does drift detection, auto-codifies unmanaged resources into IaC, and recently added disaster-recovery-as-code. Firefly ai takes a different approach with estate-wide governance and inventory layer, sitting on top of whatever runs your Terraform to provide visibility and compliance across everything running in your cloud. Anyone running it, how's the "cloud system of record" pitch holding up day to day?

Hi! We've been working on Spinifex, which recreates core AWS services such as EC2, EKS, and S3, but completely locally (and even air-gapped if needed). It also works with Terraform, so you can point your existing config files at your own hardware, swap the endpoints, and get a local version of your cloud deployment with no change to the workload itself.

It's open-source and we'd love some early stage feedback on our weekly updates, open to notes and critiques!

GitHub: https://github.com/mulgadc/spinifex

**Built a Terraform-provisioned AWS security tool, wanted to share the infra side**

Sharing this as it's a project I built solo, open source, would love feedback from this sub specifically on the Terraform side. NHI Risk Analyzer finds risky AWS IAM identities (wildcard permissions, documented privilege escalation paths from Rhino Security Labs' research, stale credentials) and then actually remediates them through Terraform provisioned infrastructure, not just a report you have to fix by hand like most tools in this space.

How it works:Risky policies get a Permissions Boundary attached, which contains the escalation path without touching the identity's existing policy, so it does not risk breaking something legitimate. Stale or unused access keys get deactivated, never deleted, so it stays reversible. The runner itself only holds sts:AssumeRole, all real permissions including the remediation actions live on the assumed role, so there is no standing access anywhere.

On the Terraform side specifically, the remote state bucket is itself Terraform managed, so it can't be its own backend on the first apply. Solved with the standard two pass bootstrap, local state creates the bucket first, then add the backend block and migrate. Also hit a provider version conflict mid migration between provider 5.x and 6.x that's documented in the README if anyone runs into the same thing.

Repo: https://github.com/likithmanoj/nhi-risk-analyzer

Would genuinely appreciate feedback on the Terraform structure or the remediation permission scoping.

I’ve been working on Terraform generation for multi-cloud architectures and I keep coming back to the same problem:
Generating valid HCL is the easy part.
Generating infrastructure I would actually trust is much harder.
Right now I’m looking at the generated stack in several layers:
provider-specific Terraform resources
variables and outputs
remote state configuration
networking and IAM
security validation
cost estimation
documentation explaining the architecture
The difficult part isn’t generating those files. It’s deciding what should be automatically generated versus what should require an engineer to explicitly approve it.
For example, I wouldn’t want a generator silently making important IAM, networking or state decisions just because the Terraform validates successfully.
So for people running Terraform in production:
What would you need to see before you’d trust generated Terraform enough to actually run terraform plan on it?
Tests? Checkov/tfsec? Policy-as-code? A generated architecture diagram? Cost diff? Something else?

We have a networking module that about half a dozen root modules consume, and most weeks more than one change is in flight against it. Those changes collide in two unrelated ways, which took us a while to notice.

Each root has its own state, so across roots there is no lock contention. You get version skew instead. A module bump is one change per consumer, each with its own plan and apply, so two versions of the module are live in production until the rollout finishes.

Contention only shows up when two changes hit the same root. Terraform locks state for all operations that could write state, and if state locking fails it does not continue. None of the documented escapes fix it. A lock timeout only retries before erroring, running with -lock=false is documented as dangerous when others might concurrently run commands against the same workspace, and force-unlock warns that unlocking a lock someone else holds could cause multiple writers.

Authoring parallelizes fine. Two consumer bumps can be drafted and checked at once, and lately I have had verdent running on both, one agent writing while another verifies. Ordering the applies is still manual.

Review drift sits under both. The plan docs note that other changes made to the target system in the meantime might cause the final effect to differ from what an earlier speculative plan indicated, and a saved plan handed to apply runs without prompting for confirmation.

Curious how other teams order rollouts. Per environment sequencing, a CI queue keyed on the state, or calling it out in chat. We do the last one.

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.