[Bug]: AWS Provider is using a legacy Terraform SDK.

[Jeff-Lowrey]

Terraform Core Version

1.8.4

AWS Provider Version

5.51.1

Affected Resource(s)

All AWS provider resources.

I say this because there are a large number of issues for specific resources that mention this similar issue.

I can't state that it actually affects every AWS provider resource, since I haven't, and can't test them.

But it should be occurring in a single place in the code - the part where the provider builds requests to the Terraform SDK.

Expected Behavior

There should not be any [WARN] messages in the terraform debug log regarding the AWS Provider using a legacy SDK

Actual Behavior

Terraform plan debug log includes the following:

[WARN]  Provider "registry.terraform.io/hashicorp/aws" produced an invalid plan for aws_instance.<resource_name, redacted>, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .source_dest_check: planned value cty.True for a non-computed attribute
      - .user_data_replace_on_change: planned value cty.False for a non-computed attribute
      - .get_password_data: planned value cty.False for a non-computed attribute
      - .hibernation: planned value cty.False for a non-computed attribute
      - .enclave_options: block count in plan (1) disagrees with count in config (0)
      - .private_dns_name_options: block count in plan (1) disagrees with count in config (0)
      - .maintenance_options: block count in plan (1) disagrees with count in config (0)
      - .root_block_device: block count in plan (1) disagrees with count in config (0)
      - .capacity_reservation_specification: block count in plan (1) disagrees with count in config (0)
      - .cpu_options: block count in plan (1) disagrees with count in config (0)
      - .metadata_options: block count in plan (1) disagrees with count in config (0)

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

Values and variable names are redacted in some cases.

data "aws_ami_ids" "runtime_ami" {
  owners = ["amazon"]
  filter {
    name   = "name"
    values = ["al2024-ami-2024*", "al2023-ami-2023*"]
  }
  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}

resource "aws_instance" "crees_runtime" {
  ami               = data.aws_ami_ids.runtime_ami.ids[0]
  instance_type     = "t3.nano"
  availability_zone = "us-east-1c"
  key_name          = <redacted>

  private_ip             = <redacted>
  subnet_id              = <redacted>
  vpc_security_group_ids = [<redacted>]

  user_data = <redacted, built by cloud-init>

  tags = {
    Name      = "abc"
  }
}

Steps to Reproduce

set the environment variable TF_LOG to DEBUG (in powershell on windows this is $env:TF_LOG="DEBUG", on Unix this would be export TF_LOG="DEBUG". There are also ways to add this environment variable to the terraform command, but that's extra work for each terraform command.

Run
terraform plan 2>tf_plan_debug.txt (or whatever name you want to use.

Debug Output

This is an example for an AWS EC2 instance using the aws_instance terraform object.

2024-05-27T12:08:40.632-0500 [WARN]  Provider "registry.terraform.io/hashicorp/aws" produced an invalid plan for aws_instance.<resource_name, redacted>, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .source_dest_check: planned value cty.True for a non-computed attribute
      - .user_data_replace_on_change: planned value cty.False for a non-computed attribute
      - .get_password_data: planned value cty.False for a non-computed attribute
      - .hibernation: planned value cty.False for a non-computed attribute
      - .enclave_options: block count in plan (1) disagrees with count in config (0)
      - .private_dns_name_options: block count in plan (1) disagrees with count in config (0)
      - .maintenance_options: block count in plan (1) disagrees with count in config (0)
      - .root_block_device: block count in plan (1) disagrees with count in config (0)
      - .capacity_reservation_specification: block count in plan (1) disagrees with count in config (0)
      - .cpu_options: block count in plan (1) disagrees with count in config (0)
      - .metadata_options: block count in plan (1) disagrees with count in config (0)

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[Jeff-Lowrey]

The plan produced is still usable. But the warning message is muddling up any attempts to debug other issues.

[Jeff-Lowrey]

AWS has announced an end of service for the SDK v1 for Go.

Looking through the code, I see a number of places where it is using the AWS SDK v1
aws_sdkv1 "github.com/aws/aws-sdk-go/aws" instead of the current AWS SDK 2.

Doing the following github search
repo:hashicorp/terraform-provider-aws /(\w*)github.com\/aws\/aws-sdk-go\// path:.go

returns '1.5k files'

Doing the same search for v2

repo:hashicorp/terraform-provider-aws /(\w*)github.com\/aws\/aws-sdk-go-v2\// path:.go

returns 2k results.

So it looks like it's a little bit more than 50% converted.

[justinretzolk]

Hey @Jeff-Lowrey 👋 Thank you for taking the time to raise this! Migrating the provider over to use Terraform Provider Framework over the older Terraform SDK version(s) is something that we'll absolutely be doing. Since October of last year, we've required that all new resources and data sources use AWS Go SDK v2 and Terraform Plugin Framework to help ease this transition when the time comes.

For now, we're prioritizing migrating off of AWS Go SDK v1 given the deadlines that you mentioned. Once we've completed that migration, we'll likely start looking into the framework migration. I can't speak to exactly what that timeline looks like just yet, but it's definitely something we're aware of.

With that in mind, I'm going to close this issue, but thank you again for taking the time to bring this up! I'd recommend tracking either of the linked issues for future updates.

[github-actions]

Warning

This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[github-actions]

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.