AWS provider 4.29.0 has breaking changes / backward incompatibilities!

[brikis98]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• 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
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Terraform version 1.2.3
AWS provider version 4.29.0

Affected Resource(s)

A whole bunch, including aws_security_group, aws_eip, etc. See #23625 for the list.

Terraform Configuration Files

Before 4.29.0, the following code worked just fine:

resource "aws_security_group" "instance" {
  name = "example"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Expected Behavior

terraform apply should work on the code above, as it has for years. If it no longer works, then instead of 4.29.0, this breaking change needs to go in to 5.0.0, and be marked with lots of warnings, upgrade guides, etc.

Actual Behavior

You get an error:

╷
│ Error: with the retirement of EC2-Classic no new Security Groups can be created without referencing a VPC
│
│   with aws_security_group.instance,
│   on main.tf line 5, in resource "aws_security_group" "instance":
│    5: resource "aws_security_group" "instance" {
│
╵

Steps to Reproduce

1. terraform apply

Important Factoids

This is due to the EC2 classic upgrade in #23625, but it seems like this breaking change in a "minor" release is not a good way to handle it. This is going to break a lot of Terraform code in the world, with little to no warning. It is already causing issues in sample code in Terraform: Up & Running, blog posts, talks, etc.

As an idea, perhaps version 4 of the provider can automatically use the Default VPC if vpc_id isn't specified instead of erroring out? And then in version 5, there can be a deprecation error if vpc_id isn't specified... And finally, in 6, it can be an error. But at least this way, you have time to update your code rather than getting errors from a minor version number bump!

Actually, thinking about it some more, if the code uses the Default VPC when vpc_id isn't specified, perhaps that behavior is "good enough," and there's no need to have any breaking changes at all?

References

• #23625

[idlanamran]

Facing the same issue. My workaround for now by using AWS Default VPC resource.

resource "aws_default_vpc" "default" {
  tags = {
    Name = "Default VPC"
  }
}

resource "aws_security_group" "aws_sg" {
  name        = "AWS Security Group Demo"
  description = "AWS Security Group Demo Description"
  vpc_id      = aws_default_vpc.default.id
}

[brikis98]

It looks like this issue may have been fixed in 4.30.0, as per #23625 (comment)!

[justinretzolk]

Hey @brikis98 👋 Thank you for taking the time to raise this! We discussed this internally and found that in some cases the way that the AWS API changed to handle the retirement of EC2-Classic is a bit different than what we expected (as @ewbankkit mentioned over on #23625).

We've merged a few PRs to update the aws_security_group, aws_opsworks_stack, and aws_eip resources to use the default VPC when one isn't specified. As you already noted, these went out with the 4.30.0 release of the provider. It seems these are the only resources that currently behave this way, but we're doing some additional work to validate the other resources that were impacted by the EC2-Classic retirement.

[brikis98]

@justinretzolk That's terrific, thank you! I assume this issue is OK to close now?

[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.