How would you publish an internal service running behind a Network Load Balancer so that consumers in other AWS accounts can reach it privately over AWS PrivateLink, and what are the tradeoffs of that model?

## The shape of the mechanism AWS PrivateLink has two sides. The consumer side is the familiar interface endpoint. The provider side is a **VPC endpoint service**: you register a Network Load Balancer (or a Gateway Load Balancer for inline appliances) as the service's front door, and AWS assigns a service name of the form `com.amazonaws.vpce.<region>.vpce-svc-<id>`. Consumers create an interface endpoint for that name, get ENIs with private IPs in their own subnets, and connect to those IPs. PrivateLink carries the traffic between the two VPCs without ever joining them into one routed network. The provider controls who may connect. `--acceptance-required` puts each new endpoint connection into a pending state until you approve it, and the allowed-principals list restricts which accounts, roles or organisations can even create an endpoint. Both are worth using: acceptance gives a human gate, the principal list keeps the service from being discoverable and connectable by everyone who learns the name. ```bash aws ec2 create-vpc-endpoint-service-configuration \ --network-load-balancer-arns arn:aws:elasticloadbalancing:eu-west-1:111122223333:loadbalancer/net/svc/abc \ --acceptance-required aws ec2 modify-vpc-endpoint-service-permissions \ --service-id vpce-svc-0a1b2c3d \ --add-allowed-principals arn:aws:iam::444455556666:root ``` ## Why a lead reaches for it The reason to choose this over other private connectivity is **isolation, not reachability**. PrivateLink exposes exactly one endpoint — the load balancer's listeners — and nothing else in the provider VPC. Traffic is unidirectional by construction: the consumer initiates, the provider cannot originate connections back. The two address spaces are never merged, so overlapping RFC 1918 ranges are a non-issue, and neither side has to coordinate CIDR allocations or route propagation with the other. For a service consumed by dozens of tenants or by another company, this is decisively better than routed connectivity, where every new consumer is another set of routes, another CIDR negotiation, and another network with broad access to yours. It also scales organisationally. Onboarding a consumer is an allow-list entry, not a network change, and offboarding is removing one. That is a governance property as much as a technical one. ## What you give up **Granularity and count.** An endpoint service fronts one NLB. Exposing many microservices either means many endpoint services — each with consumer endpoints to pay for and manage — or a single shared ingress behind the NLB that multiplexes by hostname or path at layer 7. Most mature platforms choose the latter and put a routing tier behind the NLB, accepting that the perimeter is now one door with application-level authorization behind it. **Layer 4 only, and cost.** The service must be TCP-fronted. Consumers pay endpoint-hours per AZ plus per-GB, and providers pay for the NLB and its processing, so a chatty, high-volume integration is materially more expensive than routed traffic. **Caller identity.** Targets behind the NLB see connections whose source is PrivateLink infrastructure, not the consumer's client address, so IP-based allow-lists behind the load balancer are meaningless. To recover provenance you enable **Proxy Protocol v2** on the target group, which prepends connection metadata including a custom field carrying the consumer's VPC endpoint id — but your application must parse it, and TLS termination points have to be arranged accordingly. For anything security-relevant, an application-layer credential such as mTLS or a signed token is the sounder answer, with the endpoint id used for attribution rather than authorization. **Availability zones.** A consumer can only connect from AZs where the endpoint service is available, and AZ *names* are randomised per account, so `eu-west-1a` in one account is not the same physical zone as in another. Coordinate on **AZ IDs**, and make sure the NLB has subnets in every zone consumers need — otherwise a consumer's endpoint in an uncovered zone simply cannot be created, or their traffic crosses zones with the latency and cost that implies. **DNS.** Consumers get endpoint-specific names by default. A provider can configure a private DNS name for the endpoint service — which requires proving domain ownership through a DNS TXT record — so consumers can use your real hostname; without that, every consumer wires up their own private hosted zone. ## The decision in one line Choose an endpoint service when the consumer is a different trust boundary — another team's account, another business unit, a customer — and you want to expose a single TCP front door with no shared network. Choose routed connectivity when the two sides are one trust domain that needs broad, bidirectional access, and accept the CIDR and route coordination that comes with it.