aws_lambda_function.vpc_config always detects a change when empty

[hashibot]

This issue was originally opened by @rochdev as hashicorp/terraform#10900. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

0.8.2

Affected Resource(s)

aws_lambda_function

Terraform Configuration Files

# Only relevant parts shown

variable "subnet_ids" {
  default = []
}

variable "security_group_ids" {
  default = []
}

resource "aws_lambda_function" "lambda" {
  vpc_config {
    subnet_ids         = ["${var.subnet_ids}"]
    security_group_ids = ["${var.security_group_ids}"]
  }
}

Expected Behavior

Right after applying, terraform plan should not detect any change since there aren't any.

Actual Behavior

Right after applying, terraform plan detects a change in vpc_config. If you apply the change, terraform plan will still detect the same change over and over again.

Relevant part of the output:

-/+ module.auth.authorizer.authorizer_lambda.aws_lambda_function.lambda
    vpc_config.#:        "0" => "1" (forces new resource)
    vpc_config.0.vpc_id: "" => "<computed>"

Steps to Reproduce

1. terraform plan
2. terraform apply
3. repeat

References

Seem to be related:

• provider/aws: Fix Lambda VPC integration (missing vpc_id field) terraform#6157
• Not Error out on AWS Lambda VPC config if both subnet_ids and security_group_ids are empty. terraform#6191

[jgillard]

Still seeing this on 0.9.8

[mandos]

I checked on 0.9.11 and it seems to be fixed.

[mikedal]

I am still seeing this issue in 0.9.11. EDIT: and 0.10.8
Like the original example, I am passing in subnet_ids and security_group_ids as variables, but I was also able to reproduce the bug like this

vpc_config {
  security_group_ids = []
  subnet_ids         = []
}

[nagas]

+1

It is really troublesome if you have to manage Lambda functions in Classic and VPC.

[grahamlyons]

Still seeing this in Terraform 0.11.0 with AWS provider 1.5.0.

[nickm4062]

0.11.1 as well with 1.6.0

although the error chagned a bit for me

Error: Error applying plan:

3 error(s) occurred:

* module.source_lambda.aws_lambda_function.lambda: 1 error(s) occurred:

* aws_lambda_function.lambda: vpc_config is <nil>
* module.builds_lambda.aws_lambda_function.lambda: 1 error(s) occurred:

* aws_lambda_function.lambda: vpc_config is <nil>
* module.deployment_lambda.aws_lambda_function.lambda: 1 error(s) occurred:

* aws_lambda_function.lambda: vpc_config is <nil>```

[ChinmayAmin]

Still experiencing this issue on version v0.11.3

[bflad]

This might be resolved or at least partially fixed with something like #1341 and/or #3473

[oktaviandi-nugraha]

Anyone has any luck with this? I'm on version 0.11.5 and it's still happening.

Ideally I'd like to create one module for both normal and in vpc lambda. If there's no workaround creating two modules seem the easiest workaround.

[jonwinton]

Still happening for me on 0.11.7 and AWS provider 1.20.0

[giuliocalzolari]

any ETA ?

[mdlavin]

@giuliocalzolari If you are interested in testing out this feature in a patched v1.21.0 version, I've made some Alpine Linux x64 binaries available here: https://github.com/lifeomic/terraform-provider-aws/releases/tag/v1.21.0_patched_5f7d0def

That fork will likely see future patched versions as well. I haven't had a chance to update it for the latest release yet but I'm sure it will happen.

[bflad]

In version 1.35.0 of the AWS provider, releasing shortly, the aws_lambda_function resource should now accept the following configuration and show no differences for an unconfigured VPC setup:

vpc_config {
  security_group_ids = []
  subnet_ids         = []
}

[bflad]

This has been released in version 1.35.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!