MVH

Appearance

Configuring ALB Ingress on EKS Auto Mode ​

One of the selling points of EKS Auto Mode is that it handles networking infrastructure automatically.

EKS Auto Mode includes built-in support for AWS Application Load Balancer (ALB) through a pre-installed controller. This eliminates the manual setup you'd typically need with the AWS Load Balancer Controller. However, you still need to configure ingress classes properly and ensure your subnets are tagged correctly.

This post walks through setting up an internal ALB ingress controller on EKS Auto Mode.

How Auto Mode Networking Works ​

In standard EKS clusters, you'd install and manage the AWS Load Balancer Controller yourself, including IAM roles, service accounts, and controller deployments. EKS Auto Mode eliminates this overhead by including a built-in ALB controller.

The key difference is in how you configure ingress classes. Instead of using the standard AWS Load Balancer Controller annotations, Auto Mode uses a custom IngressClassParams resource that's specific to EKS.

Prerequisites: Subnet Tagging ​

Before deploying any ingress resources, you need to tag your subnets correctly. This is critical and easy to miss. The ALB controller won't be able to create load balancers without these tags.

For internal load balancers, tag your private subnets:

bash
# Tag private subnets for internal ALBs
aws ec2 create-tags \
  --resources subnet-03cca5bfbe0945398 subnet-05f81c1043c2d4852 \
  --tags Key=kubernetes.io/role/internal-elb,Value=1

For internet-facing load balancers, tag your public subnets:

bash
# Tag public subnets for external ALBs
aws ec2 create-tags \
  --resources subnet-xxxxxxxxx subnet-yyyyyyyyy \
  --tags Key=kubernetes.io/role/elb,Value=1

Setting Up Internal ALB Ingress ​

Let's configure an internal ALB to expose services within your VPC. This is useful for private APIs or internal tools that shouldn't be publicly accessible.

Step 1: Define IngressClassParams ​

The IngressClassParams custom resource is where you specify ALB configuration like subnet placement and whether the load balancer should be internal or internet-facing:

yml
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
  name: internal-class
spec:
  scheme: internal
  subnets:
    ids:
    - TO_OVERLAY # subnet-05zd122043cfedftg
    - TO_OVERLAY # subnet-02f8df1343c2d4833

Replace the subnet IDs with your actual private subnet IDs. The scheme: internal parameter tells AWS to create an internal load balancer that's only accessible within your VPC.

Step 2: Create the IngressClass ​

The IngressClass links the EKS Auto Mode controller to your parameters:

yml
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: internal-alb
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  # Configures the IngressClass to use EKS Auto Mode
  controller: eks.amazonaws.com/alb
  parameters:
    apiGroup: eks.amazonaws.com
    kind: IngressClassParams
    # Use the name of the IngressClassParams set in the previous step
    name: internal-class

A few important details here:

  • controller: eks.amazonaws.com/alb - This is the Auto Mode controller, not the standard AWS Load Balancer Controller
  • The is-default-class annotation makes this the default ingress class. Any Ingress resources without an explicit ingressClassName will use this class
  • The parameters section references the IngressClassParams we created earlier

Step 3: Deploy Your Application ​

For this example, I'll deploy a simple nginx application:

yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

And expose it with a Service:

yml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

The ALB will handle external connectivity, so the service only needs to be reachable within the cluster.

Step 4: Create the Ingress Resource ​

Now create an Ingress resource to expose the service through the ALB:

yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: internal-alb
  rules:
  - host: nginx.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

The ingressClassName: internal-alb tells Kubernetes to use the ingress class we configured earlier. The host-based routing (nginx.local) and path-based routing work exactly as they would with any other ingress controller.

Verifying the Setup ​

After applying the manifests, check that the ingress was created successfully:

bash
# Check ingress status
kubectl get ingress nginx-ingress

# Get the ALB DNS name
kubectl get ingress nginx-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

You should see an AWS-generated hostname like internal-k8s-default-nginxin-xxxxxxxxxx-yyyyyyyyyy.us-east-1.elb.amazonaws.com.

Since this is an internal load balancer, you'll need to test from within the VPC:

bash
# From a bastion host or EC2 instance in the VPC
curl -H "Host: nginx.local" http://<alb-hostname>

Security Group Configuration ​

The ALB controller automatically creates and manages security groups. However, make sure your node security groups allow traffic from the ALB security group on the necessary ports.

Internet-Facing ALB Configuration ​

To create an internet-facing ALB instead, change the scheme in your IngressClassParams:

yaml
spec:
  scheme: internet-facing
  subnets:
    ids:
    - subnet-public-1
    - subnet-public-2

And make sure your public subnets are tagged with kubernetes.io/role/elb=1 instead of kubernetes.io/role/internal-elb=1.

Key Takeaways ​

EKS Auto Mode simplifies ALB ingress configuration by eliminating the need to install and manage the AWS Load Balancer Controller manually. However, there are a few things to keep in mind:

  1. Subnet tagging is not optional - Tag your subnets before creating ingress resources. Use kubernetes.io/role/internal-elb for private subnets and kubernetes.io/role/elb for public subnets.
  2. Use the Auto Mode controller - The controller is eks.amazonaws.com/alb, not the standard AWS Load Balancer Controller.
  3. IngressClassParams is EKS-specific - This custom resource is unique to EKS Auto Mode and provides a cleaner interface than annotation-heavy configurations.
  4. Default ingress class behavior - If you set is-default-class: true, any ingress without an explicit class will use this configuration. This can be convenient but be aware of it when migrating existing workloads.

The built-in ALB controller is one of the better features of Auto Mode. It's significantly simpler than managing the AWS Load Balancer Controller yourself.

Additional Resources ​