V3.3.10 incompatible with AWS provider v5

[Khuzd]

Hello,

Merging this and ship it in v3.3.10 has introduced a breaking change. Indeed, the stack_set_instance_region argument on aws_cloudformation_stack_set_instance only exists in v6 of aws provider.

Modules in v3.3.10 are no longer compatible with the v5 of AWS provider and requirements have to be updated.

[jose-pablo-camacho]

Hi @Khuzd,

Thanks for bringing this up, are you having specific issues with a specific resource?

I tried an onboarding with the previous version 3.10.9 and then upgrade it to 3.10.10 running a tf init and it worked fine as our modules don't have a pinned dependency for AWS provider v5 and that's the only requirements that need to be updated based on the v6 upgrade list: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-6-upgrade#resource-aws_cloudformation_stack_set_instance.

[Khuzd]

Hi,

Yes, the problem is not when you do a terraform init but when you do a terraform validate, or terraform plan.

Here is an minimalist example where terraform init succeeds, but terraform validate fails

terraform {
  backend "local" {}

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    sysdig = {
      source  = "sysdiglabs/sysdig"
      version = "~>1.48"
    }
  }

  required_version = "1.12.2"
}

provider "aws" {
  region = "us-east-1"
}

variable "sysdig_secure_url" {}

variable "sysdig_secure_api_token" {}


provider "sysdig" {
  sysdig_secure_url       = var.sysdig_secure_url
  sysdig_secure_api_token = var.sysdig_secure_api_token
}

module "onboarding" {
  source  = "sysdiglabs/secure/aws//modules/onboarding"
  version = "~>3.0"
}

module "config-posture" {
  source                   = "sysdiglabs/secure/aws//modules/config-posture"
  version                  = "~>3.0"
  sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id
}

terraform init succeeds because the constraint version ~>5.0 on aws provider is compatible with the constraint of the module >=5.60.0.

But terraform validate exits in error:

╷
│ Error: Unsupported argument
│
│   on .terraform/modules/config-posture/modules/config-posture/organizational.tf line 109, in resource "aws_cloudformation_stack_set_instance" "stackset_instance":
│  109:   stack_set_instance_region = var.region == "" ? null : var.region
│
│ An argument named "stack_set_instance_region" is not expected here.
╵
╷
│ Error: Unsupported argument
│
│   on .terraform/modules/onboarding/modules/onboarding/organizational.tf line 59, in resource "aws_cloudformation_stack_set_instance" "stackset_instance":
│   59:   stack_set_instance_region = var.region == "" ? null : var.region
│
│ An argument named "stack_set_instance_region" is not expected here.

[jose-pablo-camacho]

Hi @Khuzd,

Thanks for the clear example.

You're right, the issue is due to your required_providers constraint on the main terraform snippet:

aws = {
  source  = "hashicorp/aws"
  version = "~> 5.0"
}

This allows up to (but not including) 6.0.0, but the modules use features introduced in later versions and now require >= 5.60.0, which includes 6.x versions. Terraform init resolves a compatible provider (e.g., 6.x), so the plan works, but terraform validate uses your declared constraint and fails because ~>5.0 doesn't support those arguments.

To fix this, you can either:

• Remove the aws block from the required_providers.
• Update it to >= 5.60.0 to allow 6.x:

required_providers {
  aws = {
    source  = "hashicorp/aws"
    version = ">= 5.60.0"
  }
}

Our snippets intentionally avoid setting provider versions to let Terraform resolve them based on module requirements and avoid these kinds of conflicts.

[anapsix]

It is common for top level TF code to specify the provider version requirements by using ~> syntax, to prevent unexpected breaking changes often present in major version upgrades. When TF modules require specific provider versions, the required minimum provider versions are specified with >= syntax.

The trouble in the heart of this Github issue, as I see it, is in the invalid AWS provider version requirements Sysdig modules are specifying. Instead of >= 5.60.0, it should be >= 6.0, since AWS provider 5.x is lacking required functionality.