Better diagnostics for “multiple VPC Endpoint Services matched”

[acdha]

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

Description

Under some conditions the aws_vpc_endpoint_service data provider can return this message:

Error: multiple VPC Endpoint Services matched; use additional constraints to reduce matches to a single VPC Endpoint Service

It would be nice if this message listed, for example, the resource in question or the queried service. In my case, this was caused by a module (terraform-aws-modules/terraform-aws-vpc#573 — upgrade to 2.69 or later to get the fix) but the error message did not make that easy to identify and a trace log has hundreds of different resources to review.

New or Affected Resource(s)

• aws_vpc_endpoint_service

[bflad]

Related:

• V2 Data Source Errors Missing Configuration File and Line Context terraform-plugin-sdk#561
• Error Messaging Updates for Diagnostics #17314

[bflad]

For folks that may show up here because of the S3 PrivateLink API changes today, the above Terraform Module has an update that can help address it. For Terraform configurations which had:

data "aws_vpc_endpoint_service" "s3" {
  service = "s3"
}

They can be updated to:

data "aws_vpc_endpoint_service" "s3" {
  service      = "s3"
  service_type = "Gateway"
}

To keep the previous behavior.

[knabben]

data.aws_vpc_endpoint_service.s3 can use service_type as Gateway by default. This is the same behavior as aws_vpc_endpoint.vpc_endpoint_type == Gateway default.

[jqassar]

Hello,

Is there any way to deal with this change when using Terraform 11, either through the use of filters or other methods?

The updated syntax mentioned above was only introduced in 3.10.0, and we have existing code which maintains baselines for accounts which is still on the 2.6x.0 series. In the absence of a service_type which can be configured, I wonder if the data call could somehow default to the legacy endpoint type of gateway (as that is backwards-compatible).

[bflad]

@jqassar you can workaround the data source issue in versions older than 3.10.0 by replacing any references with "com.amazonaws.REGION.s3"

With the aws_region data source:

data "aws_region" "current" {}

# ... other local/resource/output that needs the value ...
... = "com.amazonaws.${data.aws_region.current.name}.s3"

[jqassar]

@bflad, thank you for the tip.
For our use case, we're currently using the (older) terraform-aws-vpc module to generate S3 endpoints for our account baselines, so that invocation is using the flags to enable the S3 endpoint on VPC creation. Rather than fork that module, if we were to turn those flags off and simultaneously add a module to generate an endpoint of the same type and name, would that preserve the existing endpoint, or would it destroy and recreate it?

EDIT: For those experiencing a similar issue, we were able to use the fix above without any obvious destructive changes.

[bflad]

For continuing updates on the particular error multiple VPC Endpoint Services matched; use additional constraints to reduce matches to a single VPC Endpoint Service relating to the S3 PrivateLink rollout, we are actively working with AWS and updating this pinned GitHub issue with all the details including any potential API, configuration, and module updates: #17417 -- please subscribe to that issue for further updates on that topic if interested.

I am going to leave this issue open for tracking any potential changes to the error information surfaced in the Terraform CLI plan output, such as adding more context about which data source is failing and on what API operation. 👍

[acdha]

@bflad Thank you - that is exactly what I was hoping for

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

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