{"id":420,"date":"2025-10-04T07:20:00","date_gmt":"2025-10-04T07:20:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=420"},"modified":"2025-10-04T07:20:00","modified_gmt":"2025-10-04T07:20:00","slug":"aws-load-balancer-controller-on-eks","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=420","title":{"rendered":"Setup AWS Load Balancer Controller on EKS (Complete Guide)"},"content":{"rendered":"

In this step-by-step guide, you will learn to configure AWS Load Balancer Controller on EKS with detailed workflows and configurations.<\/p>\n

What is AWS Load Balancer Controller?<\/h2>\n

The AWS Load Balancer Controller is a Kubernetes controller that manages AWS Elastic Load Balancers for a Kubernetes cluster.<\/p>\n

It automatically provisions Application Load Balancers (ALBs) when you create Kubernetes Ingress resources. <\/p>\n

Also, it provisions dedicated Network Load Balancers (NLBs) when you create Kubernetes Service resources of type LoadBalancer<\/code><\/strong>.<\/p>\n

In short, it is used for exposing Kubernetes services to external traffic using,<\/p>\n

    \n
  1. Ingress resources via ALB’s and <\/li>\n
  2. LoadBalancer services using (NLB’s)<\/li>\n<\/ol>\n

    The following diagram shows how the workflow of AWS Load Balancer controller.<\/p>\n

    \"the<\/figure>\n

    The Controller operates through a continuous monitoring and reconciliation process.<\/p>\n

    Here is how it works.<\/p>\n

      \n
    1. The controller runs as a deployment inside the EKS cluster with required IAM permissions to create\/manage AWS load balancers.<\/li>\n
    2. The Controller Pod continuously monitors the Services<\/strong> and Ingress<\/strong> objects.<\/li>\n
    3. When you create an ingress<\/strong> object, the controller detects it and will provision an Application Load Balancer<\/strong> <\/li>\n
    4. Also, when you create a service type LoadBalancer<\/strong>, the controller detects it and will provision a Network Load Balancer.<\/strong><\/li>\n<\/ol>\n

      The load balancer to pod traffic has supported modes.<\/p>\n

        \n
      1. Instance Mode (default): <\/strong>In this mode, the traffic from the load balancers to the pods are routed via Nodeport.<\/li>\n
      2. IP Mode: <\/strong>In this mode, the controller registers pod IPs directly as targets in the load balancer’s target groups. This removes the need for the NodePort.<\/li>\n<\/ol>\n

        Setup Prerequisites<\/h2>\n

        The Following are the prerequisites for this setup.<\/p>\n

          \n
        1. AWS CLI<\/a> should be installed on your local system with the required privileges.<\/li>\n
        2. EKSCTL should be on your local system<\/li>\n
        3. The Pod Identity Agent addon should be available on the EKS cluster.<\/li>\n
        4. Amazon VPC CNI should be available in the EKS cluster (CNI will be available in the cluster by default)<\/li>\n
        5. Kubectl<\/a> should be on your local system<\/li>\n
        6. Helm<\/a> should be on your local system<\/li>\n<\/ol>\n

          Subnet Configuration<\/h2>\n

          As we discussed, the primary job of the controllers is to manage ALB and NLB for EKS clusters. <\/p>\n

          For the controller to know which subnets in the VPC it can use to create load balancers, you need to tag those subnets.<\/p>\n

          Here are the tags that you need to add <\/p>\n

            \n
          1. kubernetes.io\/role\/elb = 1<\/code> : Tag added to public subnets<\/strong> where you are planning to create internet-facing<\/strong> ALBs or NLBs.<\/li>\n
          2. kubernetes.io\/role\/internal-elb = 1<\/code> : Tag Added to private subnets<\/strong> where you are planning to create internal<\/strong> ALBs or NLBs.<\/li>\n<\/ol>\n

            This way you decide which subnets are allowed for ALB\/NLB creation. It provides good security and network isolation. <\/p>\n

            \n
            \u26a0\ufe0f<\/div>\n
            At least two subnets should be tagged for the controller to create the LoadBalancers<\/div>\n<\/div>\n

            For the examples used in this guide, we are using public subnets. <\/p>\n

            The following AWS CLI comand is used to add these tags to the subnets that belong to the EKS cluster. Replace <your-cluster-name><\/code><\/strong> with your EKS cluster name.<\/p>\n

            export CLUSTER_NAME=<your-cluster-name>\n\nSUBNET_IDS=$(aws eks describe-cluster --name $CLUSTER_NAME --query \"cluster.resourcesVpcConfig.subnetIds\" --output text | tr '\\t' ' ')<\/code><\/pre>\n
            SUBNET_IDS_ARRAY=($(echo $SUBNET_IDS))<\/code><\/pre>\n
            for subnet in \"${SUBNET_IDS_ARRAY[@]}\"; do\n    aws ec2 create-tags --resources \"$subnet\" --tags Key=kubernetes.io\/role\/elb,Value=\"1\"\ndone<\/code><\/pre>\n
            \n
            \u26a0\ufe0f<\/div>\n
            In actual project setup, you should only tag the subnets that are dedicated for the load balancers. Do not tag all the subnets.<\/div>\n<\/div>\n
            Ensure the subnets are tagged by validating it from the console as shown below.<\/p>\n
            \"attaching<\/figure>\n
            \n
            \ud83d\udca1<\/div>\n
            Note: <\/strong><\/b>Instead of Tagging the subnets, you can also directly provide the subnet names on the Ingress object manifest by passing an annotation alb.ingress.kubernetes.io\/subnets<\/code><\/div>\n<\/div>\n
            Step-by-Step Controller Installation<\/h2>\n
            Follow the steps given below for the complete controller setup.<\/p>\n
            Step 1: Create an IAM Policy for the Load Balancer Controller<\/h3>\n
            The AWS Load Balancer Controller will run as Pods inside the EKS cluster, and these controller Pods needs IAM permissions to access AWS Services.<\/p>\n
            Download the IAM Policy<\/strong> JSON file from the official repo.<\/p>\n
            curl -o iam-policy.json https:\/\/raw.githubusercontent.com\/kubernetes-sigs\/aws-load-balancer-controller\/v2.14.0\/docs\/install\/iam_policy.json\n<\/code><\/pre>\n
            Create an IAM Policy<\/strong> using the iam-policy.json<\/code> file.<\/p>\n
            export POLICY_NAME=AWSLoadBalancerControllerIAMPolicy<\/code><\/pre>\n
            aws iam create-policy \\\n    --policy-name ${POLICY_NAME} \\\n    --policy-document file:\/\/iam-policy.json<\/code><\/pre>\n
            To ensure the creation of the IAM Policy and verify the permissions, we can use the AWS Console and shown below.<\/p>\n
            \"The<\/figure>\n
            Now, store the ARN<\/a> of the created IAM Policy in POLICY_ARN<\/code> variable using the following command for the upcoming configuration.<\/p>\n
            export POLICY_ARN=$(aws iam list-policies --query \"Policies[?PolicyName=='${POLICY_NAME}'].Arn\" --output text)<\/code><\/pre>\n
            Step 2: Create IAM Role (Trust Policy for Pod Identity)<\/h3>\n
            The IAM Policy with all the required permissions is ready. Next, we will create an IAM Role<\/strong> and attach that policy to it.<\/p>\n
            Start by creating a Trust Policy JSON file<\/strong>, which defines who is allowed to use this role. A trust policy<\/strong> allows specific AWS services or entities to use the role securely.<\/p>\n
            In this case, the trust policy will allow only the Pod Identity Agent<\/strong> to assume this IAM Role.<\/p>\n
            cat <<EOF > trust-policy.json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"Service\": \"pods.eks.amazonaws.com\"\n      },\n      \"Action\": [\n        \"sts:AssumeRole\",\n        \"sts:TagSession\"\n      ]\n    }\n  ]\n}\nEOF<\/code><\/pre>\n
            Create an IAM Role<\/strong> AmazonEKSLoadBalancerControllerRole<\/code> with the Trust Policy<\/p>\n
            aws iam create-role \\\n  --role-name AmazonEKSLoadBalancerControllerRole \\\n  --assume-role-policy-document file:\/\/\"trust-policy.json\"<\/code><\/pre>\n
            Verify the IAM Role<\/strong> AmazonEKSLoadBalancerControllerRole<\/code> is created, and the Trust Policy<\/strong> is properly attached.<\/p>\n
            \"aws<\/figure>\n
            Attach IAM Policy<\/strong> AWSLoadBalancerControllerIAMPolicy<\/code> with the IAM Role<\/strong> AmazonEKSLoadBalancerControllerRole<\/code> using the folling command .<\/p>\n
            export ROLE_NAME=AmazonEKSLoadBalancerControllerRole<\/code><\/pre>\n
            aws iam attach-role-policy \\\n  --policy-arn ${POLICY_ARN} \\\n  --role-name ${ROLE_NAME}<\/code><\/pre>\n
            The IAM dashboard will help ensure the attachment of the Role and the Policy.<\/p>\n
            \"the<\/figure>\n
            Use the following command to store the Role ARN as an environment variable for the upcoming configuration.<\/p>\n
            export ROLE_ARN=$(aws iam get-role --role-name $ROLE_NAME --query \"Role.Arn\" --output text)<\/code><\/pre>\n
            Step 4: Create Service Account & Pod Identity Association<\/h3>\n
            In Step 2<\/strong>, we created a trust policy for the Pod Identity Agent<\/strong>. This agent runs inside the EKS cluster and is responsible for providing IAM permissions to Pods through their Service Accounts<\/strong>.<\/p>\n
            To enable this, we need to bind the IAM Role<\/strong> that we created to a Kubernetes Service Account<\/strong> using a Pod Identity Association.<\/strong><\/p>\n
            Before creating this association, we will first create a Service Account<\/strong> for the AWS Load Balancer Controller in the EKS cluster.<\/p>\n
            Run the following commands to create the Service Account:<\/p>\n
            export SERVICE_ACCOUNT=aws-load-balancer-controller\nexport NAMESPACE=kube-system\nexport REGION=us-west-2<\/code><\/pre>\n
            cat >lbc-sa.yaml <<EOF\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  labels:\n    app.kubernetes.io\/component: controller\n    app.kubernetes.io\/name: aws-load-balancer-controller\n  name: ${SERVICE_ACCOUNT}\n  namespace: ${NAMESPACE}\nEOF<\/code><\/pre>\n
            kubectl apply -f lbc-sa.yaml<\/code><\/pre>\n
            To list the available Service Accounts<\/strong> in the kube-system<\/code> Namespace.<\/p>\n
            kubectl -n kube-system get sa<\/code><\/pre>\n
            \"the<\/figure>\n
            Before performing the Pod Identity Association<\/strong>, we need to create the Cluster name as an environment variable and ensure that the Pod Identity Agent<\/strong> is present in the cluster.<\/p>\n
            To list the available EKS clusters in a specific region.<\/p>\n
            aws eks list-clusters --region ${REGION}<\/code><\/pre>\n
            To create a cluster name as an environment variable. Change “eks-spot-cluster” with your cluster name.<\/p>\n
            export CLUSTER_NAME=eks-spot-cluster<\/code><\/pre>\n
            To list the available addons in the cluster.<\/p>\n
            aws eks list-addons --cluster-name $CLUSTER_NAME<\/code><\/pre>\n
            \"the<\/figure>\n
            Use the following command if the Pod Identity Agent is unavailable in the cluster.<\/p>\n
            aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent<\/code><\/pre>\n
            The Service Account is ready; we can perform the Pod Identity Association.<\/p>\n
            eksctl create podidentityassociation \\\n    --cluster $CLUSTER_NAME \\\n    --namespace $NAMESPACE \\\n    --service-account-name $SERVICE_ACCOUNT \\\n    --role-arn $ROLE_ARN<\/code><\/pre>\n
            After the successful association, we can list the Pod Identity Associations<\/strong>.<\/p>\n
            aws eks list-pod-identity-associations --cluster-name $CLUSTER_NAME<\/code><\/pre>\n
            \"the<\/figure>\n
            This ensures the Pod Identity Association is properly done to the AWS Load Balancer Controller Service Account.<\/p>\n
            Step 5: Install Controller with Helm Chart<\/h3>\n
            First, we have to add the aws-load-balancer-controller Helm chart<\/a> using the following command.<\/p>\n
            helm repo add eks https:\/\/aws.github.io\/eks-charts<\/code><\/pre>\n
            Update the Helm repository.<\/p>\n
            helm repo update eks<\/code><\/pre>\n
            Install the AWS Load Balancer Controller.<\/p>\n
            helm install aws-load-balancer-controller eks\/aws-load-balancer-controller \\\n  -n kube-system \\\n  --set clusterName=${CLUSTER_NAME} \\\n  --set serviceAccount.create=false \\\n  --set serviceAccount.name=aws-load-balancer-controller <\/code><\/pre>\n
            Step 6: Verify Deployment & CRDs<\/h3>\n
            To check whether the Load Balancer Controller<\/strong> has been deployed, use the following command.<\/p>\n
             kubectl -n kube-system get all -l app.kubernetes.io\/name=aws-load-balancer-controller<\/code><\/pre>\n
            \"the<\/figure>\n
            Custom Resource Definitions also be created during the installation.<\/p>\n
            kubectl get crds | grep -iE \"elbv2\"<\/code><\/pre>\n
            \"listing<\/figure>\n
            The following are the two CRDs used by the LB controller<\/p>\n
              \n
            1. ingressClassParams<\/code> – Adds optional configurations for the IngressClass.<\/li>\n
            2. targetgroupbindings<\/code> – Attach an existing Target Group to the Kubernetes Service to route the traffic.<\/li>\n<\/ol>\n
              Also, there will be a default ingress class created during the controller installation. Validate it using the following command.<\/p>\n
              kubectl get ingressclass<\/code><\/pre>\n
              \"the<\/figure>\n
              Now, the setup is completed, we can test it by exposing a demo application using Ingress.<\/p>\n
              Expose an App with Ingress (ALB)<\/h2>\n
              I am deploying an Nginx Deployment object with three replicas for testing purposes.<\/p>\n
              cat >nginx-deployment.yaml <<EOF\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  labels:\n    app: nginx-deployment\n  name: nginx-deployment\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: nginx-deployment\n  template:\n    metadata:\n      labels:\n        app: nginx-deployment\n    spec:\n      containers:\n      - image: nginx\n        name: nginx\n        ports:\n        - containerPort: 80\n---\napiVersion: v1\nkind: Service\nmetadata:\n  labels:\n    app: nginx-deployment\n  name: nginx-svc\nspec:\n  ports:\n  - port: 80\n    protocol: TCP\n    targetPort: 80\n  selector:\n    app: nginx-deployment\nEOF<\/code><\/pre>\n
              kubectl apply -f nginx-deployment.yaml<\/code><\/pre>\n
              To list the Pods and Services in the current Namespace.<\/p>\n
              kubectl get po,svc -o wide<\/code><\/pre>\n
              \"the<\/figure>\n
              The Service name<\/strong> and the Port number<\/strong> are required to create the Ingress object.<\/p>\n
              Now, we can create an Ingress<\/strong> object to route the external traffic to the Nginx Pod.<\/p>\n
              cat << EOF > ingress.yaml\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  name: nginx-ingress\n  namespace: default\n  annotations:\n    alb.ingress.kubernetes.io\/scheme: internet-facing\n    alb.ingress.kubernetes.io\/target-type: ip\nspec:\n  ingressClassName: alb\n  rules:\n    - http:\n        paths:\n          - path: \/\n            pathType: Prefix\n            backend:\n              service:\n                name: nginx-svc\n                port:\n                  number: 80\nEOF<\/code><\/pre>\n
              To create the Public Load Balancer<\/strong>, the scheme<\/strong> value should be internet-facing<\/code>.<\/strong><\/p>\n
              The target type should be ip<\/code><\/strong>, because the application’s Service<\/strong> type is ClusterIP<\/strong> (Internal Communication)<\/p>\n
              This means that the LB will directly use the Pod IP addresses<\/strong> to route the traffic.<\/p>\n
              \n
              \ud83d\udca1<\/div>\n
              For a NodePort<\/strong><\/b> service, set the target type<\/strong><\/b> as “instance<\/strong><\/b>“. So, traffic goes from the Load Balancer<\/strong><\/b> to the Node’s Port<\/strong><\/b>, and then reaches the Pod<\/strong><\/b>.<\/div>\n<\/div>\n
              To apply the configuration, use the following command.<\/p>\n
              kubectl apply -f ingress.yaml<\/code><\/pre>\n
              The Application Load Balancer<\/strong> will be provisioned when deploying the Ingress<\/strong> object.<\/p>\n
              To check this, we can describe the Ingress.<\/p>\n
              kubectl describe ingress nginx-ingress<\/code><\/pre>\n
              \"the<\/figure>\n
              In the Backends<\/strong> section of the configuration, we can see that all three Pod IPs<\/strong> are mapped.<\/p>\n
              \n
              \ud83d\udca1<\/div>\n
              The Load Balancer Controller will stay in sync with the Ingress object. So, if any Pod is deleted, a new one starts, and the new Pod’s IP<\/strong><\/b> will automatically be updated in the Load Balancer target.<\/div>\n<\/div>\n
              We can ensure the Application Load Balancer is provisioned by using the AWS Console.<\/p>\n
              \"the<\/figure>\n
              The resource map<\/strong> section of the Application Load Balancer clearly shows how the traffic flows.<\/p>\n
              When request come through the Load Balancer, it goes to the target group<\/strong> and routes to the Pod’s IP addresses.<\/strong><\/p>\n
              But, what if we have more than one Ingress objects but want to utilize a single Load Balancer.<\/p>\n
              Share One ALB with Ingress Groups<\/h2>\n
              The Ingress Group<\/strong> feature allow to use one Load Balancer<\/strong> for multiple Ingress<\/strong> resources.<\/p>\n
              The following diagram explains how we can use a single Load Balancer for two set of applications.<\/p>\n
              \"the<\/figure>\n
              The above diagram explains<\/p>\n