The OSI Model describes network communication through seven conceptual layers. Layer 1, physical, concerns transmitting signals over media. Layer 2, data link, concerns local delivery using frames and link-layer addressing. Layer 3, network, concerns logical addressing and routing, commonly using IP. Layer 4, transport, concerns communication between endpoints through protocols such as TCP and UDP. Layer 5, session, concerns managing communication sessions. Layer 6, presentation, concerns data representation, encoding, and related transformations. Layer 7, application, concerns protocols used by applications, such as HTTP and DNS.
This is a reference model, not a requirement that every implementation contain seven separate components. Internet protocols follow the TCP/IP architecture, whose layers do not map exactly to OSI layers. Session and presentation responsibilities are often implemented within application libraries and protocols. Cloud infrastructure also abstracts physical and link-layer details, but those underlying responsibilities still exist.
For cloud design, the most useful distinction is often what information a component uses to make a forwarding decision. A Layer 3 router forwards traffic according to IP routing information. A Layer 4 load balancer distributes transport flows without needing to interpret application requests. A Layer 7 load balancer understands an application protocol and can make decisions using information such as an HTTP hostname, URL path, or header.
For example, AWS Application Load Balancer operates at Layer 7 and can route requests for /orders and /images to different target groups. This allows multiple web services to share an entry point rather than requiring a dedicated load balancer for each service. Network Load Balancer operates at Layer 4 and is appropriate for transport-level traffic distribution, including TCP and UDP workloads, or requirements such as static IP addresses. It does not provide HTTP path-based routing.
Gateway Load Balancer addresses a different requirement: distributing network traffic across virtual appliances such as firewalls and intrusion detection systems. It operates at Layer 3 and uses GENEVE encapsulation over UDP port 6081 to exchange traffic with compatible appliances. The UDP encapsulation does not make its primary purpose ordinary Layer 4 application load balancing. It is not a substitute for HTTP-aware routing or a general-purpose web application load balancer.
Choose the required behavior before comparing prices. Evaluate load balancer hours, capacity-unit consumption, processed traffic, applicable data-transfer charges, and operational overhead. Sharing an Application Load Balancer can reduce duplicated infrastructure, but traffic volume and rule evaluations still affect cost. A Network Load Balancer is not automatically cheaper because it operates at a lower layer. Adding appliance inspection also introduces appliance charges, processing overhead, and additional network-path complexity.
Layer labels are useful shorthand, not complete product specifications. Network Load Balancer can terminate TLS even though it is categorized as Layer 4; TLS termination alone does not provide HTTP content routing. Similarly, forwarding encrypted HTTPS traffic does not mean a device can inspect its paths or headers without decryption. During troubleshooting, separate routing failures, transport connection failures, TLS negotiation failures, and application errors. A successful TCP connection proves neither that TLS works nor that the application can successfully serve a request.
Amazon VPC