Summary

  • AWS assigns application resources such as EC2 instances, RDS databases, Redshift clusters and Lambda functions to the account participating in a shared VPC. It also charges that participant for specified inter-Availability-Zone, peering, internet-gateway and Direct Connect transfers.
  • The VPC owner pays for NAT gateway, PrivateLink, endpoint and other owner-side network charges, plus public IPv4 addresses used in the shared VPC. Stopping the subnet share prevents new participant resources, but existing ones keep running and block deletion of the subnet or VPC until the participant removes them.

The server and its address go to different desks

An AWS Organizations account can place its application resources in a subnet shared by another account. AWS sells this arrangement as a centrally managed VPC with separate accounts for billing and access. That phrase hides an important question: separate which bills? AWS's own billing guide answers it line by line. The participant pays for its EC2, RDS, Redshift and Lambda resources. The VPC owner pays for public IPv4 addresses used in the shared VPC. A participant can own the server without receiving the address charge attached to the shared network.

The split is broader than a single address. Participant accounts pay the data-transfer charges AWS lists for traffic across Availability Zones, VPC peering, internet gateways and Direct Connect gateways. The VPC owner pays applicable hourly, processing and transfer charges across NAT gateways, virtual private gateways, transit gateways, PrivateLink and VPC endpoints. One application's path can therefore have a compute line on one account, a transfer line on that account, and a gateway or address line on another. Looking only at the server owner's invoice will undercount the cost of that application's network design.

AWS says traffic within the same Availability Zone, identified by the AZ ID, is free regardless of which account owns the communicating resources. That matters when a team tries to reconcile a cost jump: a change in traffic path can create a transfer charge without a change in the application resource or the public IPv4 count. The billing guide names the categories; an actual allocation still needs the accounts' usage records and the deployed path.

The person holding the network keys pays another part of the bill

The price split follows a control split. AWS gives the VPC owner the route tables, subnets, NAT gateways and endpoints. A participant can manage its own network interfaces and security groups, but cannot create, delete or even describe NAT gateways in the shared subnet. The account that can change a central gateway is the one AWS bills for it. That can be sensible for a central network team. It becomes politically interesting when a product team can grow traffic through a gateway it does not pay for directly.

Public IPv4 makes the separation especially legible. AWS's standard VPC price page lists US$0.005 per in-use or idle public IPv4 address hour, billed in one-second increments with a 60-second minimum. The shared-VPC billing guide places addresses used in the shared VPC on the owner's bill. A company with several participant accounts may know exactly how many servers each team has and still need a separate address ledger to show which team consumes the owner's IPv4 spend. The public documents supply no actual customer count or invoice; that answer lives in usage records.

A share can end before the workload does

The owner can stop sharing a subnet. AWS then blocks the participant from creating new resources there, while existing participant resources continue to run. The participant can still modify or delete those resources. The owner cannot delete the shared subnet or VPC while participant resources remain. A central network team therefore cannot treat “stop sharing” as a demolition switch. It has to reconcile what the other account still owns before the network can disappear.

This is where the market lesson gets sharp. Shared VPCs consolidate network control, but invoices follow individual metering objects rather than a tidy organization chart. Set an internal price and accountability rule for addresses and shared gateways before inviting another account into the subnet. Otherwise the participant buys the server, the owner buys the road, and both teams can honestly claim their own bill looks fine.

Sources