APIGateway and NLB cross account integration

@Malini Agrawal, it hasn't been discussed explicitly, but I'm assuming the reason to have NLB A in account A is to allow it to be used for a private integration with the API Gateway. It is a hardwired requirement in API Gateway that the NLB exposed to the API Gateway as a VPC endpoint service must be in the same account as the API Gateway, regardless of who owns the VPC. If you aren't familiar with private integrations for API Gateway, you can learn about them in more detail (including the account dependency for the NLB) in this documentation section: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-nlb-for-vpclink-using-console.html.

There's also a very comprehensive blog post about various connectivity options for API Gateway here, including scenarios not applicable in this case: https://aws.amazon.com/blogs/compute/understanding-vpc-links-in-amazon-api-gateway-private-integrations/

NLB B, on the other hand, would presumably be in account B so as to be able to reference EC2 instances, container tasks, or other types of resources local to account B in its target groups. They could be configured as static IP address references in a target group for NLB A, but that would create another static IP address dependency that would be strongly contraindicated in many situations beyond the scope of this question.

hi Leo and satish,

I am still not understanding, why NLB in account A need to pass-through?

why can't use API Gateway---->VPC Link----->NLB in B directly , as NLB gets static IP per subnet, and VPC Link integration lets you use the NLB’s DNS, avoiding hardcoded IPs entirely.

Everything is in same VPC, no cross-VPC/private service needed, only Fixed hourly charge, no data cost within same VPC

Let me know if I’m missing something.

Thanks

For your cross-account API Gateway setup, there are indeed better alternatives to your current architecture that can eliminate the need for hardcoded IPs and the double NLB hop.

If you need to maintain the two-account setup, here are better approaches:

1. AWS PrivateLink with VPC Link: You can use AWS PrivateLink to establish a private connection between your accounts. In this architecture:

• Create a VPC Link in Account A (same account as your API Gateway)
• Set up an NLB in Account A that points to the VPC Endpoint private IP addresses of the PrivateLink connection to Account B
• Configure a resource policy on the target service in Account B to allow access from Account A's VPC endpoint

2. VPC Peering or Transit Gateway with Direct Integration: If you already have cross-account VPC connectivity via VPC peering or AWS Transit Gateway:

• Create a VPC Link in Account A (with your API Gateway)
• Configure the NLB in Account A to point directly to the private IP addresses of the resources in Account B
• This eliminates the need for a second NLB and VPC endpoint, simplifying the architecture

3. AWS Cloud Map with HTTP APIs: If you're using HTTP APIs (not REST APIs), you can:

• Use AWS Cloud Map to resolve private resources in Account B
• Connect the VPCs using Transit Gateway for private routing
• Create a VPC Link in Account A that uses AWS Cloud Map to discover services in Account B

Each of these approaches avoids hardcoding IPs and provides a more maintainable solution than your current double-NLB architecture.

As you mentioned, moving the API Gateway to Account B would be the simplest approach if your architecture allows for it, as it would eliminate the cross-account complexity entirely.
Sources
HTTP API - Best Practices for Designing Amazon API Gateway Private APIs and Private Integration
Rest API - Best Practices for Designing Amazon API Gateway Private APIs and Private Integration