module fails with aws provider v6.0

[oleg-opsfleet]

Description

Hello team and separate thanks to all contributors here. After new aws provider v6.0 was released, the module now fails with

19:38:49.293 STDERR [ecs/services] terraform: │ Error: Unsupported block type
19:38:49.293 STDERR [ecs/services] terraform: │ 
19:38:49.293 STDERR [ecs/services] terraform: │   on ../../modules/service/main.tf line 635, in resource "aws_ecs_task_definition" "this":
19:38:49.293 STDERR [ecs/services] terraform: │  635:   dynamic "inference_accelerator" {
19:38:49.293 STDERR [ecs/services] terraform: │ 
19:38:49.293 STDERR [ecs/services] terraform: │ Blocks of type "inference_accelerator" are not expected here.
19:38:49.293 STDERR [ecs/services] terraform: ╵

This happens because this field was deleted from new version

resource/aws_ecs_task_definition: Remove inference_accelerator attribute. Amazon Elastic Inference reached end of life on April, 2024. (https://github.com/hashicorp/terraform-provider-aws/issues/42137)

When it will be possible, please update the module. 🙏

[bryantbiggs]

for now, just pin your required_providers to restrict the version to < 6.0

[mattWoolly]

I'm seeing this issue as well. Pinning an older version worked until today.

[bryantbiggs]

No, it's not module version - pin your required_providers for the AWS provider to < 6.0

[jpdoria]

I'm also getting this error. Unfortunately, pinning the AWS provider version to < 6.0.0. is not an option because it will break the VPC module in my project (for reference: https://github.com/terraform-aws-modules/terraform-aws-vpc/issues/1207).

[albertocapella]

I fixed it in terragrunt adding the following block in a .hcl file

generate versions {
  path      = "versions.tf"
  if_exists = "overwrite"
  contents  = <<-EOF
  terraform {
    required_providers {
      aws = {
        source  = "hashicorp/aws"
        version = "< 6.0.0"
      }
    }
  }
  EOF
}

[rcpranavbansal]

when will this be updated ?

[bryantbiggs]

you can pin the version of the providers you use today, no module change required for that. upgrading to support v6 of the AWS provider will be handled here https://github.com/terraform-aws-modules/terraform-aws-ecs/pull/217#issuecomment-2941311433

[rcpranavbansal]

Thanks!

[sadmdbrezack-metabolon]

Whats the ETA on 6.0 support. It's gonna take a very long time to fix this in my current terraform as some of my other modules are already running on 6.0.0.

[sfiguereo]

I am struggling with this as well and will have to fork the module as none of the alternatives given work for me. I wonder if the update will take days, weeks, months? It will be nice to have a ballpark idea so we dont have to reinvent the wheel.

[bryantbiggs]

It will be nice to have a ballpark idea so we dont have to reinvent the wheel.

I would not call forking and making small modification to suite your needs as "reinventing the wheel"

It would also be nice to be paid for what we provide for free, given how much users demand from us 🤷‍♂

[sfiguereo]

I was just respecfully asking for a ballpark so I can plan around, not demanding anything. I appreciate what you do to maintain this module and will definitively consider contributing to your efforts.

[oliverlambson]

@bryantbiggs is there a reason why the module's aws provider isn't currently capped at <6? Since the module doesn't actually work with 6 it seems like that would be the right thing to do in the meantime.

I've opened this PR if you agree

[bryantbiggs]

because users can do this in their required_providers

[oliverlambson]

@bryantbiggs but that means every user who tries to use this module from now until v6 support is added will hit this error and have to debug it. Why not fix it at the source? The module doesn't support v6, so it shouldn't be letting terraform think that it does

[sfiguereo]

Thanks to the contributors for the work done so far.

That said, I want to be very clear: this module is currently broken with AWS provider v6.0+, and pinning the provider version is not a viable long-term solution for many users—especially in larger projects that rely on other modules already using v6.

Refusing to cap the AWS provider version in the module itself forces every new user to hit this known issue and debug it themselves. That’s unnecessary friction and completely avoidable. If the module is not compatible with v6, it should not silently accept it.

To be blunt: if maintaining this module is burdensome or not a priority, that’s understandable—but then it’s worth clearly stating that the module is no longer actively supported. Users can then make informed decisions, such as forking or finding an alternative.

Choosing to maintain a popular module—especially one widely referenced—comes with certain responsibilities. If that's too much to manage, stepping back or inviting new maintainers may be the more responsible route.

Thanks again for the prior work, but this current stance is not helping users and risks damaging the module’s credibility.

[bryantbiggs]

I don't think you understand how version pinning works

[bryantbiggs]

That said, I want to be very clear: this module is currently broken with AWS provider v6.0+, and pinning the provider version is not a viable long-term solution for many users—especially in larger projects that rely on other modules already using v6.

Is impossible - you can't have this module specify < 6.0 in the same workspace of modules that specify >= 6.0

[oliverlambson]

@bryantbiggs I am not asking for prioritisation or even an approval of my PR, but I am trying to understand why it is wrong from your perspective. I think it will be helpful for the thread because others also clearly don't understand.

Currently all the implementations in ./examples will fail as they are documented, because terraform/tofu will resolve to aws v6. This means the main branch is currently failing PR the checklist item "I have tested and validated these changes using one or more of the provided examples/* projects".

Basically I don't really get why placing an upper bound on the provider in the module is incorrect or bad practice in your opinion.

[bryantbiggs]

but I am trying to understand why it is wrong from your perspective. I think it will be helpful for the thread because others also clearly don't understand.

I don't think its wrong - I don't think I've stated that. Its 6 versus half a dozen. we could cap the upper bound, but it won't satisfy half of those commenting here (see above from those who over eagerly migrated to adopt v6 too early). and we have tried this elsewhere, its the same issues just on the other side of the fence now https://github.com/terraform-aws-modules/terraform-aws-eks/issues/3386

if you look at other open source software libraries, you will see that the common approach is to limit the lower bound since you can safely and reliably validate against the minimum supported version. you cannot do the same for the upper bound which is an unknown entity

at the end of the day there is only one correct answer in all of these scenarios, and its the one I've been repeating over and over and its quite maddening that folks shirk the responsibility. if you want stability in your environment, whether that is Terraform, Kubernetes, Javascript, Python, etc.... you should and must pin your dependencies. You have complete control over this, you decide when and if you want to upgrade, etc.

This is the last I'll comment on this thread, I've spent way too much time explaining the basics of software versioning here and we still have a number of modules, such as this one, that we need to add support for the AWS provider v6.0

[sfiguereo]

This response unfortunately confirms my earlier concerns.

Based on the current stance, it is clear that this module cannot be relied upon in a production environment. Lack of compatibility with current AWS provider versions, coupled with dismissive responses to valid concerns about module usability, make it a risky dependency.

For anyone else following this thread, I recommend the approach I’ve taken: remove this module from your production infrastructure and manage the necessary AWS resources directly. While using a module can offer convenience, that benefit does not outweigh the cost of relying on a module that lacks responsible and responsive maintenance.

When stability, clarity, and support are critical—which is the case in any production environment—those values must take priority.

[sfiguereo]

Given the nature of the responses in this thread and the approach to user concerns, I will be taking additional precautions moving forward.

Specifically, I will be reviewing any other Terraform modules used in our environment that are maintained by @bryantbiggs. If they are found to follow a similar pattern of dismissiveness or lack of proactive support, we will be removing those as well. Dependability and maintainability are critical in infrastructure code, and it’s essential that the tools we adopt reflect those standards.

This is not a decision made lightly, but one based on ensuring long-term stability and minimizing risk in our infrastructure.

[bryantbiggs]

For anyone else following this thread, I recommend the approach I’ve taken: remove this module from your production infrastructure and manage the necessary AWS resources directly. While using a module can offer convenience, that benefit does not outweigh the cost of relying on a module that lacks responsible and responsive maintenance.

When stability, clarity, and support are critical—which is the case in any production environment—those values must take priority.

I am quite shocked by this - the lengths you will go to paint me in a negative light for providing something for free, and then claim When stability, clarity, and support are critical—which is the case in any production environment—those values must take priority. - yet you refuse to pin your software versions?

[oliverlambson]

I don't think its wrong - I don't think I've stated that. Its 6 versus half a dozen. we could cap the upper bound, but it won't satisfy half of those commenting here (see above from those who over eagerly migrated to adopt v6 too early). and we have tried this elsewhere, its the same issues just on the other side of the fence now terraform-aws-modules/terraform-aws-eks#3386

Appreciate the answer, difference in opinion but sounds understandable. Thanks for the work on this module, it continues to make my life easier

[sfiguereo]

I am quite shocked by this - the lengths you will go to paint me in a negative light for providing something for free, and then claim When stability, clarity, and support are critical—which is the case in any production environment—those values must take priority. - yet you refuse to pin your software versions?

I want to clarify that my intent was never to paint anyone in a negative light, especially someone contributing to open source. I do appreciate your work and the time you've dedicated—voluntarily—to this module.

However, the suggested workaround of pinning provider versions is not a viable or responsible solution in many real-world environments, including ours. As others have also pointed out, locking the AWS provider to a pre-v6 version to satisfy this single module creates version conflicts with numerous other modules and resources that require or depend on v6 features. Altering our entire Terraform strategy around one module that lacks compatibility is simply not feasible.

As the CEO of a software development company responsible for delivering stable, scalable infrastructure to our clients, I cannot rely on dependencies maintained as charitable efforts without clear support models. This is not a personal critique—it’s a practical decision driven by the demands of production systems.

With that, I’ll step away from this thread. We’ve removed this module from our production stack and will evaluate other dependencies under the same criteria. Thanks again for your prior contributions, and best of luck with the module's future.

[antonbabenko]

This issue has been resolved in version 6.0.0 :tada:

[shellscape]

As the CEO of a software development company responsible for delivering stable, scalable infrastructure to our clients, I cannot rely on dependencies maintained as charitable efforts without clear support models.

Perhaps as a CEO, stick to bizops and leave the technical aspect to people who understand the technical aspect of development and delivery. As CEO you've failed to effectively lead your team (even if you're the entire team) in best practices, as maintainers have repeatedly tried to explain to you. Put down the buzzwords and pick up some more courses on platform development.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.