#terraform - September 2025

Hi, I raised this PR a few weeks ago to fix an issue with the module (as a new version of the helm provider has broken this module)

Is there anything I need to do to get it reviewed? Or should I just fork and start using a personal reslease?

https://github.com/cloudposse/terraform-aws-helm-release/pull/78

Join us for "Office Hours" every Wednesday 01:30PM (PST, GMT-7) via Zoom.

This is an opportunity to ask us questions on terraform and get to know others in the community on a more personal level. Next one is Sep 10, 2025 01:30PM.

👉️ Register for Webinar

#office-hours (our channel)

Join us for "Office Hours" every Wednesday 01:30PM (PST, GMT-7) via Zoom.

This is an opportunity to ask us questions on terraform and get to know others in the community on a more personal level. Next one is Sep 17, 2025 01:30PM.

👉️ Register for Webinar

#office-hours (our channel)

Is there any appetite for Feature Request for supporting custom rules · Issue #131 · cloudposse/terraform-aws-config?

Join us for "Office Hours" every Wednesday 01:30PM (PST, GMT-7) via Zoom.

This is an opportunity to ask us questions on terraform and get to know others in the community on a more personal level. Next one is Sep 24, 2025 01:30PM.

👉️ Register for Webinar

#office-hours (our channel)

I would love to understand your reasoning around provider pinning. I know Hashicorp's recommendations are currently
1. use minimum constraints >= for modules
2. use pessimistic semver constraints ~> for root modules
but which of those does an Atmos terraform component fit into?
We are building our own components for a brownfields deployment and have based all of our components on the cloudposse example module template which uses the cloudposse test-harness to ensure that provider versions are pinned with only minimum constraints. However, there are cases like https://medium.com/@mr.ryanflynn/why-hard-pinning-terraform-provider-versions-is-essential-a-lesson-from-an-aws-eks-issue-a03928ae410f and recommendations from seasoned terraform users in reddit that suggest versions should always be hard-pinned with =.
I can also see the test-harness did allow pessimistic semver constraints at some point, I just can't see why it was allowed or why it was changed.
We are also exploring the idea of using a component repo as either a component (root module) or a module (eg. an EKS component that includes the generic IAM component as a module to add roles using the cluster's own OIDC provider so we don't have to call the IAM component from atmos a second time)

This message was deleted.

I am trying to upgrade terraform-aws-msk-apache-kafka-cluster from v1.4.0 to v2.5.0
The plan shows that the whole msk cluster needs a replacement.
Is there any guideline how to do or avoid that?

  # module.kafka.module.kafka.aws_msk_cluster.default[0] must be replaced
-/+ resource "aws_msk_cluster" "default" {

there is a guide for older releases that looks similar
https://github.com/cloudposse/terraform-aws-msk-apache-kafka-cluster/blob/main/docs/migration-0.7.x-0.8.x+.md
looks like this issue has some guideline
https://github.com/cloudposse/terraform-aws-msk-apache-kafka-cluster/issues/93

Hey all! We're working through an IAM role delegation pattern for a central primary role (for Spacelift/Terraform executions), which would then assume into downstream account roles.

The setup:
• Primary role in the "Identity" account (Spacelift or any automation system like GHA assumes this)
• The primary role can then assume into delegated admin roles in downstream accounts (trust policy allow)
• The delegated roles have admin permission in their respective accounts
BUT, now how do we, if we want to perform Terraform locally, assume into the Primary role in the Identity account?
1. Chain role
a. Users authenticate via AWS SSO -> Primary TF admin role Identity account
b. How do we do this? Leapp, we can do this via Chained Roles... but local CLI, we'd have to do an additional step to assume role via AWS CLI
2. We don't assume into primary role, Delegated roles directly have trust policy to allow the AWS SSO admin role in the Identity account.

This is very similar to the CloudPosse's architecture guide, https://docs.cloudposse.com/layers/identity/centralized-terraform-access/ but from the Permission Set -> intermediary Primary role in the Identity account, how is that assumption usually done? Is an additional AWS CLI command the best option? I'm not sure which is the best path.

Hi everyone, I’m Idan. I’m working on an open-source project that helps monitor and control everything in an organization, with integrations to third-party tools.

We’re looking for someone with Terraform experience to contribute code and help automate a demo environment so users can try it out quickly.

Stars are of course very welcome ⭐️
Check it out here:

https://github.com/OpsiMate/OpsiMate

Join us for "Office Hours" every Wednesday 01:30PM (PST, GMT-7) via Zoom.

This is an opportunity to ask us questions on terraform and get to know others in the community on a more personal level. Next one is Oct 01, 2025 01:30PM.

👉️ Register for Webinar

#office-hours (our channel)

Super random question, why do some CloudPosse modules support passing a permissions boundary but not path? I don't want to act like I have a ton of knowledge here but in my corporate experience if a permissions boundary is required so is a path. I have run into this with both EC2 & lambda module

Join us for "Office Hours" every Wednesday 01:30PM (PST, GMT-7) via Zoom.

This is an opportunity to ask us questions on terraform and get to know others in the community on a more personal level. Next one is Oct 08, 2025 01:30PM.

👉️ Register for Webinar

#office-hours (our channel)