#terraform - October 2025

Hi all, I need some clarification around licensing with Terraform (HashiCorp’s BUSL-1.1) and our own Terraform code.
I’m trying to understand which parts are covered by HashiCorp’s license vs. what’s governed by how we license our own code.
Specifically:
1. If we give a client access (via GitLab token) so they can run our Terraform code to create AWS resources in their account — do we need any special licensing from HashiCorp?
2. If the client clones our Terraform code and uploads it into their own repo (to run infra for themselves), does that raise any BUSL issues, or is it purely about how we choose to license our own Terraform modules?
3. If we don’t want clients to freely reuse or redistribute our Terraform code outside of the engagement, should we explicitly add a proprietary/custom license to our repo, or is “no license file” enough protection?
Would love some guidance so we make sure we’re both compliant with HashiCorp’s BUSL and clear about our own IP boundaries. 🙏

Anyone infra'ing AKS with Terraform and AzureRM 3.x and unexpectedly experiencing their Windows nodes being forcibly replaced despite no changes to config or code? I've just went into panic mode and reported this https://github.com/hashicorp/terraform-provider-azurerm/issues/30757

Need some help here, I have never used Spacelift, I have my Githib Repo added to it and the stack created but I am trying to create a test s3 bucket using terraform. Any guides would be appreciated.

If anyone able to provide any guidance?

Hey guys, looking to get some help with this terraform module

https://github.com/cloudposse/terraform-aws-codebuild/tree/main

I am creating codebuild projects using atmos and the above module
it's creating the env vars by default which i have not defined and i'm unable to exempt them. any ideas??
the env vars that it currently adds

AWS_REGION
us-east-1
PLAINTEXT

AWS_ACCOUNT_ID
11111111
PLAINTEXT

IMAGE_REPO_NAME
UNSET
PLAINTEXT

IMAGE_TAG
latest
PLAINTEXT

I want to exempt IMAGE_REPO_NAME and IMAGE_TAG variables

Hey Guys, haven't updated my terraform for a few years, whats the best practice for this:
using terragrunt, trying to get clean tflint output etc.
directories are like:
domains/domain1.com/main.tf
domains/terraform.tfvars
production/productionapp1/main.tf
production/terraform.tfvars
modules/

I am currently using domains/terraform.tfvars to define various security rules/whitelist IPs, that are used in some domains, but not all, So if I don't define/use them in each domain folder, terraform or tflint show a warning about it.

Should I just disable the linting rules for that? or else I'm considering a modules/shared_variables and then domain1/main.tf can use shareD_variables.whitelist_ips if it needs to, and it shouldn't throw warnings about unused outputs.

Has anyone found a way to destroy/terminate namespaces created by the Terraform resource kubernetes_namespace when they get stuck in the Terminating state?
Right now, the only thing that seems to work is manually clearing the finalizers, like this:
kubectl get ns "$ns" -o json | jq 'del(.spec.finalizers)' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -

Just wondering if anyone's found a cleaner or automated way to handle this by terraform ?

Office Hours ran long (always worthwhile, thank you to CloudPosse and everyone who contributes!), so I didn't get to ask this question…

What Terraform version adoption statistics have people found? I want to balance compatibility and modernity when distributing open-source modules. Would I be shooting myself in the foot with minima of v1.10 of Terraform from November, 2024 (S3 state without DynamoDB) and v6.0 of the AWS provider from June, 2025 (multi-region without repetition), because typical users are slow to upgrade?

At work, in multiple, fairly large shops, I'm ecstatic 🥲 when I see Terraform v1.x and AWS provider v5.

Thanks for any advice!

Hi, I'm using the ECR aws module (https://registry.terraform.io/modules/cloudposse/ecr/aws/latest). I would like some clarification on the max_image_count and protected_tags_keep_count parameters.
1. Does the max_image_count exclude the images with protected tags?
2. Is the protected_tags_keep_count per unique tag?
We've had some issues with deployed tags being cleaned up and I want to make sure I fully understand these 2 settings. Thanks.

Hey guys, what is the procedure to add or update components in https://github.com/cloudposse-terraform-components ?

For example, if we want to add some features to a component, or we have a completely new component - do we need to ask and discuss somewhere first? Or just send PRs? or..?

Hi! Is there an open source SQS module from cloudposse out there? I was checking the sqs-queue one but it's not listed in their modules library and I couldn't use it directly in tf

Would it be interesting if Cloud Posse offered something like a commercial "Bug Fix Insurance" across our module ecosystem?

👋 I am using the https://github.com/cloudposse/terraform-aws-sso/ module to create permission_sets and assign them to AWS accounts, pretty standard stuff.

I would like to try and customize the trust policy associated with a permissionset to allow for assuming the role in one AWS account, from another AWS account within the same Org, but I'm not finding much to go on as far as examples go in this repo.

I am trying to setup something that would allow users that have been assigned a role in AWS permissions to copy items from an S3 bucket in Account A to an S3 bucket in Account B, within the same region, similar to what's goin gon here: https://stackoverflow.com/questions/73639007/allow-user-to-assume-an-iam-role-with-sso-login

the problem I am running into is I am finding nowhere to actually configure the contents of thePermissionSet Trust Policy, is that just something that is outside of the scope of the terraform-aws-sso module?

I imagine I could create a x-account trust policy like this:

data "aws_iam_policy_document" "xaccount_trust_policy" {
  provider = aws.destination
  statement {
    actions = [
      "sts:AssumeRole",
      "sts:TagSession",
      "sts:SetSourceIdentity"
    ]
    principals {
      type        = "AWS"
      identifiers = ["arn:aws:iam::${data.aws_caller_identity.source.account_id}:root"]
    }
  }
}

but I don't think you can apply it to the permissionset that is being created on the AWS destination account side

Good morning, I've been a longtime fan of the CloudPosse architecture as we used it at one of my former roles. While I was overseeing our architecture at the time, I was not the person that actually set up the original accounts a few year ago. As a result, I'm taking some time to go through the process myself so I can set things up in the future. I'm making really solid progress but seem to have run into a wall and could really use some help.

I've been working through the foundation documents on my own. I'm currently in the Deploy Accounts (https://docs.cloudposse.com/layers/accounts/deploy-accounts/) stage. I've run everything through Step 6 deploying the accounts and account map.

I'm now trying to apply the account-settings module and its failing with two instances of the The given key does not identify an element in this collection value. error. The docs mention that this is usually due to a mismatch of the root_account_aws_name in the account-map. I've confirmed that multiple times and have it set to root. For this troubleshooting, let's assume we are trying to apply the account-settings for the audit account which is called core-audit. The account-settings module appears to be looking for the audit index instead of core-audit.

I've tried setting audit_account_account_name to both core-audit and audit, neither of which are working. I believe the value should be core-audit. Where else could I be going wrong?

FWIW, I've confirmed I'm using the latest versions of all the modules.

Thanks for any suggestions!

Hi CloudPosse team - Any chance we can get an issue to update Terraform awsutils - https://github.com/cloudposse/terraform-provider-awsutils

Updated such that the corresponding awsutils resources support a region parameter? Basically, similar to the AWS 6.0 Terraform provider?

---

Use Case: We now pass in ~15 awsutils providers each with separate regions to delete VPCs for all these regions. It would be amazing to loop over with a region parameter.

👋 I'm trying to figure out what I am doing incorrectly when using the default_security_group_deny_all variable with the terraform-aws-vpc module.

I have several VPCs already created from this module and am working towards removing the default VPC security group default egress & ingress rules. I thought I would be able to do this by simply adding the default_security_group_deny_all variable to my existing Terraform with a value of true and just redeploying my Terraform, however when I make a PR with those changes, my Terraform plan shows 0 changes to be made.

If I set the value to false I see the default security group being removed (I imagine by setting this to false I'll need to make a moved block indicating that I am now managing this security group as part a different Terraform resource), but that's not what i want to do.

Why does setting this value to true not seem to do anything for already created default VPC security groups?

I'm trying to build a tool which require, terraform core's connectivity, using RPC
!!not building a plugin, its like a standalone software that imports terraform core and compares files,
but didn't found any content on youtube, i really do even know how to initiate this project.

i am an intern BTW!

Hello team! 👋

I'm hitting a perpetual diff on various resources originating from the GitHub Provider, used in the aws-argocd-github-repo component. Specifically, the etag property is constantly changing on the GitHub's API side, creating ever-changing plans. Those plans are failing to apply via gitops with plan files have differences.

I found our that recently, this PR was merged, which directly addresses handling of etags on the GH provider. Is my understanding correct that the issue should resolve on its own once the change gets released (currently it is not)? Are you aware of any other workaround here? (fyi. ignore_changes on etag does not work)