Add support for cross account vpc endpoint service discovery

[anavarreteuk]

Is your request related to a new offering from AWS?

This feature is not bound to a specific AWS feature

Is your request related to a problem? Please describe.

Yes — currently, the module's behavior causes failures when trying to configure cross-account AWS PrivateLink (VPC interface) endpoints.

Specifically, the module unconditionally evaluates the aws_vpc_endpoint_service data source for each endpoint, even when a fully-qualified service_endpoint is explicitly provided. This leads to issues when the target service is hosted in another AWS account and is not discoverable via the data source due to visibility restrictions.

As a result, users are unable to use the module to define PrivateLink endpoints pointing to cross-account services, even when they know and provide the correct service name.

Describe the solution you'd like.

Update the data "aws_vpc_endpoint_service" block's for_each expression to conditionally evaluate only when service_endpoint is not defined.

This ensures that:

When service_endpoint is explicitly provided, the data source is skipped entirely (no unnecessary lookup).

When service_endpoint is not defined, the module behaves as it currently does — resolving the service name via the data source.

This change would make the module compatible with cross-account PrivateLink usage while maintaining full backward compatibility.

Proposed change:

data "aws_vpc_endpoint_service" "this" {
  for_each = {
    for k, v in local.endpoints : k => v
    if !try(contains(keys(v), "service_endpoint"), false) # Skip if service_endpoint is defined, needed when the vpc endpoint service is in a different AWS account than the vpc endpoint
  }

Describe alternatives you've considered.

Forking the module and maintaining a patched version (which we're currently doing).

Trying to expose the PrivateLink service in the same account (not always feasible due to organizational or account boundaries).

Using a separate resource block outside the module to create the VPC endpoint, reducing the value of using the module itself.

These alternatives add unnecessary complexity or do not fully solve the issue.

Additional context

This enhancement allows for more flexible and robust usage of the module in multi-account AWS environments, especially where centralized services (via PrivateLink) are common.

We’ve tested this change in a forked version of the module, and it resolves the issue without affecting any existing behavior.

[bryantbiggs]

without a reproduction its hard to tell what you are describing

[szhekpisov-katanox]

Let me add some input here - for example, I need securely pass access to the https service from account A to account B. For that I create a VPC Endpoint Service in AWS account "A", and I need to create a VPC Endpoint in account B, which will refer to VPC Endpoint service in Account A.

           Account B                          Account A
(Consumer -> VPC Endpoint) -> (VPC Endpoint Service -> Producer)

And here comes the request - we need to be able to create such VPC Endpoint in account B with the module, where it's connected not to Amazon service (like S3, ECS, etc.), but to VPC Endpoint service from another account.