AWS: exposure and health checks

Verified against primary documentation on 2026-10-11.

Exposure

Load balancers have a scheme of internet-facing or internal. The nodes of an internet-facing load balancer have public IP addresses; the nodes of an internal one "have only private IP addresses" and "can only route requests from clients with access to the VPC". AWS gives multi-tier applications as the reason: web servers face the internet, database servers only the web servers (Internal load balancers).

Subnets are public when their route table sends internet traffic to an internet gateway and private when it does not (Internet gateways).

On EKS, the AWS Load Balancer Controller takes the same values through alb.ingress.kubernetes.io/scheme and service.beta.kubernetes.io/aws-load-balancer-scheme (Load Balancer Controller annotations). The cluster API server endpoint is public, private or both (Cluster API server endpoint).

API Gateway endpoints are edge-optimized, Regional or private, chosen by "where the majority of your API traffic originates from" (API endpoint types). App Runner services have a public endpoint or a private endpoint reached through a VPC Ingress Connection (Enabling private endpoints).

One port for gRPC and HTTP

An Application Load Balancer target group has a protocol version of HTTP/1.1, HTTP/2 or gRPC, and each accepts only some client protocols (Target groups for Application Load Balancers):

Client sends	HTTP1 target group	HTTP2 target group	GRPC target group
HTTP/1.1	success	error	error
HTTP/2	success	success	success for POST
gRPC	error	success if targets speak gRPC	success

No single target group accepts both HTTP/1.1 clients and gRPC. A gRPC target group lets the load balancer route "based on the package, service, and method", so a port that carries both is served by two target groups pointing at it: a gRPC one behind listener rules for the gRPC paths, and an HTTP/1.1 one for everything else. Both versions need an HTTPS listener.

Identity

Network reach and identity are separate settings. Lambda function URLs take an auth type of AWS_IAM or NONE (Function URL auth). VPC Lattice groups services into a service network for reach and attaches auth policies for identity, denying all traffic once auth is on and no policy allows it (Auth policies).

Staff tools sit behind AWS Verified Access, whose controls "do not depend on traditional network controls or network perimeters" (How Verified Access works).

Health checks

HTTP target group health checks request / and expect 200 by default. gRPC target group health checks call /AWS.ALB/healthcheck and expect 12, UNIMPLEMENTED, by default, so a service that implements no health method at all still passes. Checking grpc.health.v1 takes setting the path to /grpc.health.v1.Health/Check and the success code to 0 (Target group health checks).

The load balancer runs its own check and does not read the Pod's readinessProbe. Pod readiness gates, enabled with the elbv2.k8s.aws/pod-readiness-gate-inject namespace label, hold a Pod not ready until the load balancer reports it healthy, so a rollout does not remove old Pods before new ones receive traffic. AWS recommends load balancer health checks alongside Kubernetes probes, not in place of them (EKS best practices: load balancing).

The same guide says not to make liveness depend on anything outside the Pod, and warns that "readiness probes that depend on external factors, such as connectivity to a database, can cause all pods to fail the probe", leading to an outage or a cascading failure. AWS also advises against giving liveness and readiness the same specification (Probes and checks).