AWS Elastic Load Balancing vs MetalLB

AWS Elastic Load Balancing distributes incoming application traffic across targets and virtual appliances in one or more Availability Zones. It offers Application, Network, Gateway, and Classic Load Balancers, scales request handling with traffic, and runs configurable health checks on targets. Application Load Balancers support HTTP header-based routing, redirects, fixed responses, HTTP/2, and gRPC. Network Load Balancers support static Elastic IP addresses and AWS PrivateLink for TCP and TLS listeners. The service also supports SSL/TLS termination, certificate management, and client certificate authentication. CloudWatch metrics and logging are available for all four types. A single load balancer can distribute traffic across AWS and on-premises resources. Kubernetes support includes direct-to-pod routing for Application Load Balancers and private EKS clusters for Application and Network Load Balancers. AWS recommends different types for HTTP, transport protocols, third-party virtual appliances, and EC2-Classic applications. Usage charges vary by region; data transfer and public IPv4 address charges may be additional. New AWS customers receive a free tier for six months after account creation, with usage limits and up to $200 in credits.

MetalLB provides network load balancing for Kubernetes clusters that do not run on a cloud provider. It assigns service IP addresses from operator-configured pools and announces them through ARP, NDP, or BGP, depending on the chosen mode. In layer 2 mode, one cluster machine announces an address using ARP for IPv4 or NDP for IPv6. In BGP mode, cluster machines peer with nearby routers, which can distribute traffic across multiple nodes. The recommended FRR-K8s mode supports BFD, IPv6, and merging additional FRR configuration. MetalLB is open source, with no paid plans listed. Installation options include Kubernetes manifests, Kustomize, Helm, and an Operator on OperatorHub. After installation it remains idle until configured with resources such as an IPAddressPool in its deployment namespace. Requirements include Kubernetes 1.13.0 or later, a compatible cluster network, and IPv4 addresses. The project lists AWS, Azure, DigitalOcean, and Google Cloud as unsupported and says it is generally incompatible with cloud providers. MetalLB describes itself as a beta project and cautions that its configuration format may change incompatibly as development continues.