how to minimize data transfer cost between organizations

D. Ensure that service consumer compute resources use the Availability Zone-specific endpoint service by using the endpoint's local DNS name.

Explanation: By using the Availability Zone-specific DNS names for VPC endpoints, traffic is kept within the same Availability Zone. This approach helps avoid cross-AZ data transfer charges, which are typically higher.

C. Turn off cross-zone load balancing for the Network Load Balancer in all service provider application deployments.

Explanation: Disabling cross-zone load balancing prevents data from being sent across different Availability Zones, which can incur additional charges. Keeping the traffic within the same AZ helps in minimizing these costs.

Why the Other Options Are Less Effective:

A. Use AWS Resource Access Manager to share the subnets that host the service provider applications with other accounts in the organization.

Sharing subnets via AWS Resource Access Manager could help in other aspects of resource management but doesn't directly address the problem of reducing data transfer costs across AZs or between organizations.

B. Place the service provider applications and the service consumer applications in AWS accounts in the same organization.

While this might simplify management, it does not reduce the inherent data transfer costs between AZs or organizations.

E. Create a Savings Plan that provides adequate coverage for the organization's planned inter-Availability Zone data transfer usage.

A Savings Plan might reduce costs for reserved usage but does not specifically target minimizing data transfer costs, especially those that arise from inefficient architecture or traffic routing.

I would start such an optimisation effort by identifying the source of the costs. VPC interface endpoints aren't a particularly cost-efficient construct to begin with. This may be well known to you already, but to make sure we're talking about the same things, the general structure for traffic through a VPC interface endpoint within a region goes like this:

• the client in VPC A connects to the local VPC endpoint
  • if the endpoint ENI is in a different AZ from the client, cross-AZ charges apply (this is what you already identified as a potential savings target by using the endpoint's AZ-local DNS name)
• the traffic passes through the VPC endpoint's ENI to an NLB node in VPC B in the same AZ
  • this traffic always gets charged, since it's passing through the VPC endpoint (PrivateLink) service, regardless of AZs
• the NLB that offers the VPC endpoint service processes the traffic
  • NLB capacity is charged as capacity units, with traffic volumes as one of the metrics that affect the charges, and where AZs don't affect the charges
• the NLB sends the traffic to a target
  • if the target is in a different AZ from the NLB node that processed the traffic, cross-AZ charges apply

Additionally, a fixed hourly fee is charged for every VPC endpoint created in every AZ in every VPC, or put in another way, for every ENI that is connected to the VPC endpoint service. The NLB(s) that offer the service also incur an hourly fee. Both of these hourly fees are charged regardless of the amount of traffic passing through them, including if they are entirely unused.

You're quite correct that reducing or eliminating cross-AZ traffic can help with the costs, but only the part caused by cross-AZ traffic. It will have no effect on the traffic processing charges of the VPC interface endpoint or the NLB, which are always charged. Without knowing the specifics of your cost structure, it's pure guesswork how significant that might be, but in any event, the changes won't reduce the data processing charges of the VPC endpoint or the NLB, nor will those changes affect the hourly fees of either set of components.

I would suggest first using Cost Explorer to identify the source of the costs in both the client and service provider accounts. The traffic processing charges for VPC endpoints charged in the client accounts have the Usage Type VpcEndpoint-Bytes, and their hourly fees have the Usage Type VpcEndpoint-Hours. Traffic processing charges for NLBs have the Usage Type LCUUsage, and their fixed hourly fees are of the type LoadBalancerUsage.

Cross-AZ charges between the workloads in the client VPC and the local VPC endpoints should show as DataTransfer-xAZ-In-Bytes and DataTransfer-xAZ-Out-Bytes. Cross-AZ charges in the service provider VPC between the NLB nodes that provide the VPC endpoint service and the target resource should mostly show as DataTransfer-Regional-Bytes, unless the target is another AWS service with a different charging model.

If you identify that the cross-AZ traffic is the source of the excessive costs, then reducing it is certainly worth considering. That would entail the options C and D on your list. However, at the risk of stating the obvious, disabling cross-AZ load balancing on the NLB would prevent an NLB node in an AZ without healthy targets from connecting to healthy targets in other AZs. Depending on how the application is designed to provide high availability and how significant it is for the application that traffic is load-balanced evenly across the target resources, the effects may be between negligible and highly impactful.

One of the worst-case scenarios would be that if the service provider targets in a specific AZ failed, all the otherwise fully functional clients in other accounts and VPCs in the same AZ would receive no service, because they'd be restricted to using the service solely in the local AZ, where no healthy targets remain. This is exactly what would happen if you set the clients to connect to the AZ-specific DNS names of the VPC endpoints and disabled cross-AZ load balancing on the NLB.

There are many possible ways to deal with this. For example, the applications could call the VPC endpoint primarily with the AZ-local DNS name, but in case of failure, they could retry the request with the multi-AZ DNS name. That would avoid cross-AZ charges when the service is available in the local AZ, while still permitting cross-AZ access when it's needed, but it would require the AZ-aware retry logic to be built into the client application or some supporting structure around it.

A structurally more cost-efficient design would be to use VPC peering to connect to the service provider NLB directly from the client VPCs, without using VPC endpoints at all. This would eliminate both the hourly fees and the traffic processing charges of VPC interface endpoints (PrivateLink) entirely. VPC peering doesn't add any costs of its own, and it doesn't impose restrictions regarding the organisational affiliation of the accounts. Its main requirement is that all the CIDRs of the peered VPCs do not overlap. The costs for the NLB would remain unchanged, and it's equally possible to call the NLB with AZ-specific DNS names either exclusively or primarily, failing over to the cross-AZ name in case of failure, when cross-AZ load balancing is disabled for the NLB or target group.

As the other commenter correctly noted, the organisational affiliations of the AWS accounts or subnet sharing via RAM don't affect any of these charges, except potentially minimally through volume discounts, which may not be shared by the two organisations.