In many AWS architectures, load balancers sit directly in the path of almost every request. They distribute traffic across application instances, isolate services behind stable endpoints, and simplify scaling.
Because of that central role, load balancers also become a major point where network traffic accumulates.
In platforms built around microservices — such as an API Manager exposing services to partners, a Campaign Manager serving internal applications, or a Customer Data Platform (CDP) processing incoming events — load balancers often handle both external traffic and service-to-service communication.
At small scale this is rarely noticeable. As traffic grows, however, the amount of data passing through load balancers can introduce additional network costs that are easy to overlook during architecture design.
Load Balancers in Typical Platform Architectures
Most modern AWS platforms rely on load balancers as the entry point for application traffic.
For example, an API Manager used by external partners may follow a flow like this:
Client → CloudFront → Application Load Balancer → API services
Similarly, internal systems such as a Campaign Manager often route traffic through a load balancer before reaching application containers or EC2 instances.
In both cases the load balancer becomes the central gateway for all requests entering the system.
The important point is that the load balancer itself does not generate the traffic — but every request and every response must pass through it. When application workloads grow, the total volume of processed data grows as well.
Cross-AZ Traffic Introduced by Load Balancing
High availability is one of the main reasons engineers distribute workloads across multiple Availability Zones.
Application Load Balancers typically route requests to targets across multiple zones to ensure resilience. While this improves fault tolerance, it can also introduce cross-AZ traffic.
For example, a request entering an ALB in one zone may be forwarded to a service instance running in another zone. When responses travel back to the client, that traffic crosses AZ boundaries again.
In microservice environments where services communicate frequently, this pattern can generate a continuous stream of cross-zone traffic.
The cost behavior behind this traffic pattern is explained in Cross-AZ Traffic Costs in AWS.
Internal Load Balancers and Service-to-Service Traffic
Load balancers are not used only for external requests. Many architectures also use internal load balancers to route traffic between services.
In a Customer Data Platform, for example, ingestion services may receive events and distribute them across processing workers through an internal load balancer.
Similarly, microservices inside a Campaign Manager platform may communicate through service endpoints exposed behind an internal ALB.
Although this traffic never leaves the VPC, it still contributes to the total amount of data transferred inside the architecture.
When service communication becomes frequent — especially in event-driven systems — the volume of internal traffic can grow faster than expected.
Understanding how this traffic contributes to overall network charges is discussed in AWS Data Transfer Costs in Multi-Account Architectures.
Load Balancers in Multi-Account Landing Zone Architectures
In landing zone environments, different systems are often deployed in separate AWS accounts.
For example:
- API Manager in a shared services account
- CDP workloads in a data platform account
- Campaign Manager services in an application account
Traffic between these systems may pass through centralized networking components such as Transit Gateway.
Load balancers frequently sit at the boundary between these environments, receiving requests from other accounts and forwarding them to internal services.
Because of this position, they become part of the overall network path connecting different platforms.
The network model behind these architectures is discussed in Transit Gateway Costs in Multi-Account AWS Architectures.
When Load Balancer Traffic Becomes Noticeable
In many systems the traffic handled by load balancers grows naturally as the platform expands.
For example:
- Partner API traffic increasing in an API Manager
- Customer activity events flowing into a CDP
- Internal services exchanging data inside a Campaign Manager platform
None of these patterns are unusual. They are simply part of normal system growth.
However, because load balancers sit in the request path, they process the combined traffic of many services at once.
Understanding where that traffic originates helps engineers identify which architectural components contribute most to the total network cost.
Conclusion
Load balancers are often treated as simple infrastructure components that route traffic to application instances.
In reality, they are deeply embedded in the data path of most modern architectures.
Platforms built around microservices — including API platforms, campaign systems, and data processing pipelines — rely heavily on load balancers to manage traffic between services.
As these systems grow, the volume of data flowing through load balancers grows with them.
Understanding how that traffic moves across Availability Zones, VPCs, and accounts helps engineering teams design architectures that scale while keeping network costs predictable.