aws_vpc_endpoint_service requires additional filter block or name resolution

[TrickMcCarthy]

SDK version

aws provider 2.40

Use-cases

https://www.terraform.io/docs/providers/aws/d/vpc_endpoint_service.html
This only supports service_name and service. It is missing support for the Name attribute.
The service_name and service are auto-generated each time the service endpoints are created.
The only way to utilize the data source is to hardcode the generated service_name or service id.
In the case I am experiencing the service endpoint is generated by a different service with different terraform state file.

Without supporting retrieval using an end user specified name, this hardcoded value needs to be manually updated each time the service endpoint is recreated. This creates a tight coupling between the services and requires coordination whenever the service endpoint is recreated. It would be much better to reduce this tight coupling.

Attempted Solutions

While the remote_state can be used as a workaround, but it leaves things with tight coupling and this coupling is not suitable when you are trying to upgrade terraform between versions where the state file formats change.
https://www.terraform.io/docs/providers/terraform/d/remote_state.html

Proposal

Add filter block support or retrieval based on the Name attribute, or both.

References

I could not find any, but the original data source was added by this PR
hashicorp/terraform-provider-aws#8396

[ghost]

This issue has been automatically migrated to hashicorp/terraform-provider-aws#11168 because it looks like an issue with that provider. If you believe this is not an issue with the provider, please reply to hashicorp/terraform-provider-aws#11168.

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