

 **Help improve this page** 

To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page.

# Route internet traffic with AWS Load Balancer Controller
<a name="aws-load-balancer-controller"></a>

**Tip**  
 [Register](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) for upcoming Amazon EKS workshops.

The AWS Load Balancer Controller manages AWS Elastic Load Balancers for a Kubernetes cluster. You can use the controller to expose your cluster apps to the internet. The controller provisions AWS load balancers that point to cluster Service or Ingress resources. In other words, the controller creates a single IP address or DNS name that points to multiple pods in your cluster.

![\[Architecture diagram. Illustration of traffic coming from internet users, to Amazon Load Balancer. Amazon Load Balancer distributes traffic to pods in the cluster.\]](http://docs.aws.amazon.com/eks/latest/userguide/images/lbc-overview.png)


The controller watches for Kubernetes Ingress or Service resources. In response, it creates the appropriate AWS Elastic Load Balancing resources. You can configure the specific behavior of the load balancers by applying annotations to the Kubernetes resources. For example, you can attach AWS security groups to load balancers using annotations.

The controller provisions the following resources:

 **Kubernetes `Ingress` **   
The LBC creates an [AWS Application Load Balancer (ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) when you create a Kubernetes `Ingress`. [Review the annotations you can apply to an Ingress resource.](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/) 

 **Kubernetes service of the `LoadBalancer` type**   
The LBC creates an [AWS Network Load Balancer (NLB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)when you create a Kubernetes service of type `LoadBalancer`. [Review the annotations you can apply to a Service resource.](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/)   
In the past, the Kubernetes network load balancer was used for *instance* targets, but the LBC was used for *IP* targets. With the AWS Load Balancer Controller version `2.3.0` or later, you can create NLBs using either target type. For more information about NLB target types, see [Target type](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-type) in the User Guide for Network Load Balancers.

The controller is an [open-source project](https://github.com/kubernetes-sigs/aws-load-balancer-controller) managed on GitHub.

Before deploying the controller, we recommend that you review the prerequisites and considerations in [Route application and HTTP traffic with Application Load Balancers](alb-ingress.md) and [Route TCP and UDP traffic with Network Load Balancers](network-load-balancing.md). In those topics, you will deploy a sample app that includes an AWS load balancer.

 **Kubernetes `Gateway` API**   
With the AWS Load Balancer Controller version `2.14.0` or later, the LBC creates an [AWS Application Load Balancer (ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) when you create a Kubernetes `Gateway`. Kubernetes Gateway standardizes more configuration than Ingress, which needed custom annotations for many common options. [Review the configuration that you can apply to an Gateway resource.](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/gateway/gateway/) For more information about the `Gateway` API, see [Gateway API](https://kubernetes.io/docs/concepts/services-networking/gateway/) in the Kubernetes documentation.

## Install the controller
<a name="lbc-overview"></a>

You can use one of the following procedures to install the AWS Load Balancer Controller:
+ If you are new to Amazon EKS, we recommend that you use Helm for the installation because it simplifies the AWS Load Balancer Controller installation. For more information, see [Install AWS Load Balancer Controller with Helm](lbc-helm.md).
+ For advanced configurations, such as clusters with restricted network access to public container registries, use Kubernetes Manifests. For more information, see [Install AWS Load Balancer Controller with manifests](lbc-manifest.md).

## Migrate from deprecated controller versions
<a name="lbc-deprecated"></a>
+ If you have deprecated versions of the AWS Load Balancer Controller installed, see [Migrate apps from deprecated ALB Ingress Controller](lbc-remove.md).
+ Deprecated versions cannot be upgraded. They must be removed and a current version of the AWS Load Balancer Controller installed.
+ Deprecated versions include:
  +  AWS ALB Ingress Controller for Kubernetes ("Ingress Controller"), a predecessor to the AWS Load Balancer Controller.
  + Any `0.1.x ` version of the AWS Load Balancer Controller

## Legacy cloud provider
<a name="lbc-legacy"></a>

Kubernetes includes a legacy cloud provider for AWS. The legacy cloud provider is capable of provisioning AWS load balancers, similar to the AWS Load Balancer Controller. The legacy cloud provider creates Classic Load Balancers. If you do not install the AWS Load Balancer Controller, Kubernetes will default to using the legacy cloud provider. You should install the AWS Load Balancer Controller and avoid using the legacy cloud provider.

**Important**  
In versions 2.5 and newer, the AWS Load Balancer Controller becomes the default controller for Kubernetes *service* resources with the `type: LoadBalancer` and makes an AWS Network Load Balancer (NLB) for each service. It does this by making a mutating webhook for services, which sets the `spec.loadBalancerClass` field to `service.k8s.aws/nlb` for new services of `type: LoadBalancer`. You can turn off this feature and revert to using the [legacy Cloud Provider](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) as the default controller, by setting the helm chart value `enableServiceMutatorWebhook` to `false`. The cluster won’t provision new Classic Load Balancers for your services unless you turn off this feature. Existing Classic Load Balancers will continue to work.

# Install AWS Load Balancer Controller with Helm
<a name="lbc-helm"></a>

**Tip**  
 [Register](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) for upcoming Amazon EKS workshops.

**Tip**  
With Amazon EKS Auto Mode, you don’t need to install or upgrade networking add-ons. Auto Mode includes pod networking and load balancing capabilities.  
For more information, see [Automate cluster infrastructure with EKS Auto Mode](automode.md).

This topic describes how to install the AWS Load Balancer Controller using Helm, a package manager for Kubernetes, and `eksctl`. The controller is installed with default options. For more information about the controller, including details on configuring it with annotations, see the [AWS Load Balancer Controller Documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) on GitHub.

In the following steps, replace the example values with your own values.

## Prerequisites
<a name="lbc-prereqs"></a>

Before starting this tutorial, you must complete the following steps:
+ Create an Amazon EKS cluster. To create one, see [Get started with Amazon EKS](getting-started.md).
+ Install [Helm](https://helm.sh/docs/helm/helm_install/) on your local machine.
+ Make sure that your Amazon VPC CNI plugin for Kubernetes, `kube-proxy`, and CoreDNS add-ons are at the minimum versions listed in [Service account tokens](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions).
+ Learn about AWS Elastic Load Balancing concepts. For more information, see the [Elastic Load Balancing User Guide](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/).
+ Learn about Kubernetes [service](https://kubernetes.io/docs/concepts/services-networking/service/) and [ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resources.

### Considerations
<a name="lbc-considerations"></a>

Before proceeding with the configuration steps on this page, consider the following:
+ The IAM policy and role (`AmazonEKSLoadBalancerControllerRole`) can be reused across multiple EKS clusters in the same AWS account.
+ If you’re installing the controller on the same cluster where the role (`AmazonEKSLoadBalancerControllerRole`) was originally created, go to [Step 2: Install Load Balancer Controller](#lbc-helm-install) after verifying the role exists.
+ If you’re using IAM Roles for Service Accounts (IRSA), IRSA must be set up for each cluster, and the OpenID Connect (OIDC) provider ARN in the role’s trust policy is specific to each EKS cluster. Additionally, if you’re installing the controller on a new cluster with an existing `AmazonEKSLoadBalancerControllerRole`, update the role’s trust policy to include the new cluster’s OIDC provider and create a new service account with the appropriate role annotation. To determine whether you already have an OIDC provider, or to create one, see [Create an IAM OIDC provider for your cluster](enable-iam-roles-for-service-accounts.md).

## Step 1: Create IAM Role using `eksctl`
<a name="lbc-helm-iam"></a>

The following steps refer to the AWS Load Balancer Controller **v2.14.1** release version. For more information about all releases, see the [AWS Load Balancer Controller Release Page](https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/) on GitHub.

1. Download an IAM policy for the AWS Load Balancer Controller that allows it to make calls to AWS APIs on your behalf.

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy.json
   ```
   + If you are a non-standard AWS partition, such as a Government or China region, [review the policies on GitHub](https://github.com/kubernetes-sigs/aws-load-balancer-controller/tree/main/docs/install) and download the appropriate policy for your region.

1. Create an IAM policy using the policy downloaded in the previous step.

   ```
   aws iam create-policy \
       --policy-name AWSLoadBalancerControllerIAMPolicy \
       --policy-document file://iam_policy.json
   ```
**Note**  
If you view the policy in the AWS Management Console, the console shows warnings for the **ELB** service, but not for the **ELB v2** service. This happens because some of the actions in the policy exist for **ELB v2**, but not for **ELB**. You can ignore the warnings for **ELB**.

1. Replace the values for cluster name, region code, and account ID.

   ```
   eksctl create iamserviceaccount \
       --cluster=<cluster-name> \
       --namespace=kube-system \
       --name=aws-load-balancer-controller \
       --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/AWSLoadBalancerControllerIAMPolicy \
       --override-existing-serviceaccounts \
       --region <aws-region-code> \
       --approve
   ```

## Step 2: Install AWS Load Balancer Controller
<a name="lbc-helm-install"></a>

1. Add the `eks-charts` Helm chart repository. AWS maintains [this repository](https://github.com/aws/eks-charts) on GitHub.

   ```
   helm repo add eks https://aws.github.io/eks-charts
   ```

1. Update your local repo to make sure that you have the most recent charts.

   ```
   helm repo update eks
   ```

1. Install the AWS Load Balancer Controller.

   If you’re deploying the controller to Amazon EC2 nodes that have [restricted access to the Amazon EC2 instance metadata service (IMDS)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node), or if you’re deploying to Fargate or Amazon EKS Hybrid Nodes, then add the following flags to the `helm` command that follows:
   +  `--set region=region-code ` 
   +  `--set vpcId=vpc-xxxxxxxx ` 

     Replace *my-cluster* with the name of your cluster. In the following command, `aws-load-balancer-controller` is the Kubernetes service account that you created in a previous step.

     For more information about configuring the helm chart, see [values.yaml](https://github.com/aws/eks-charts/blob/master/stable/aws-load-balancer-controller/values.yaml) on GitHub.

     ```
     helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
       -n kube-system \
       --set clusterName=my-cluster \
       --set serviceAccount.create=false \
       --set serviceAccount.name=aws-load-balancer-controller \
       --version 1.14.0
     ```

**Important**  
The deployed chart doesn’t receive security updates automatically. You need to manually upgrade to a newer chart when it becomes available. When upgrading, change *install* to `upgrade` in the previous command.

The `helm install` command automatically installs the custom resource definitions (CRDs) for the controller. The `helm upgrade` command does not. If you use `helm upgrade,` you must manually install the CRDs. Run the following command to install the CRDs:

```
wget https://raw.githubusercontent.com/aws/eks-charts/master/stable/aws-load-balancer-controller/crds/crds.yaml
kubectl apply -f crds.yaml
```

## Step 3: Verify that the controller is installed
<a name="lbc-helm-verify"></a>

1. Verify that the controller is installed.

   ```
   kubectl get deployment -n kube-system aws-load-balancer-controller
   ```

   An example output is as follows.

   ```
   NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
   aws-load-balancer-controller   2/2     2            2           84s
   ```

   You receive the previous output if you deployed using Helm. If you deployed using the Kubernetes manifest, you only have one replica.

1. Before using the controller to provision AWS resources, your cluster must meet specific requirements. For more information, see [Route application and HTTP traffic with Application Load Balancers](alb-ingress.md) and [Route TCP and UDP traffic with Network Load Balancers](network-load-balancing.md).

# Install AWS Load Balancer Controller with manifests
<a name="lbc-manifest"></a>

**Tip**  
With Amazon EKS Auto Mode, you don’t need to install or upgrade networking add-ons. Auto Mode includes pod networking and load balancing capabilities.  
For more information, see [Automate cluster infrastructure with EKS Auto Mode](automode.md).

This topic describes how to install the controller by downloading and applying Kubernetes manifests. You can view the full [documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/) for the controller on GitHub.

In the following steps, replace the example values with your own values.

## Prerequisites
<a name="lbc-manifest-prereqs"></a>

Before starting this tutorial, you must complete the following steps:
+ Create an Amazon EKS cluster. To create one, see [Get started with Amazon EKS](getting-started.md).
+ Install [Helm](https://helm.sh/docs/helm/helm_install/) on your local machine.
+ Make sure that your Amazon VPC CNI plugin for Kubernetes, `kube-proxy`, and CoreDNS add-ons are at the minimum versions listed in [Service account tokens](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions).
+ Learn about AWS Elastic Load Balancing concepts. For more information, see the [Elastic Load Balancing User Guide](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/).
+ Learn about Kubernetes [service](https://kubernetes.io/docs/concepts/services-networking/service/) and [ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) resources.

### Considerations
<a name="lbc-manifest-considerations"></a>

Before proceeding with the configuration steps on this page, consider the following:
+ The IAM policy and role (`AmazonEKSLoadBalancerControllerRole`) can be reused across multiple EKS clusters in the same AWS account.
+ If you’re installing the controller on the same cluster where the role (`AmazonEKSLoadBalancerControllerRole`) was originally created, go to [Step 2: Install cert-manager](#lbc-cert) after verifying the role exists.
+ If you’re using IAM Roles for Service Accounts (IRSA), IRSA must be set up for each cluster, and the OpenID Connect (OIDC) provider ARN in the role’s trust policy is specific to each EKS cluster. Additionally, if you’re installing the controller on a new cluster with an existing `AmazonEKSLoadBalancerControllerRole`, update the role’s trust policy to include the new cluster’s OIDC provider and create a new service account with the appropriate role annotation. To determine whether you already have an OIDC provider, or to create one, see [Create an IAM OIDC provider for your cluster](enable-iam-roles-for-service-accounts.md).

## Step 1: Configure IAM
<a name="lbc-iam"></a>

The following steps refer to the AWS Load Balancer Controller **v2.14.1** release version. For more information about all releases, see the [AWS Load Balancer Controller Release Page](https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/) on GitHub.

1. Download an IAM policy for the AWS Load Balancer Controller that allows it to make calls to AWS APIs on your behalf.  
**Example**  

------
#### [  AWS  ]

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy.json
   ```

------
#### [  AWS GovCloud (US) ]

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy_us-gov.json
   ```

   ```
   mv iam_policy_us-gov.json iam_policy.json
   ```

------

1. Create an IAM policy using the policy downloaded in the previous step.

   ```
   aws iam create-policy \
       --policy-name AWSLoadBalancerControllerIAMPolicy \
       --policy-document file://iam_policy.json
   ```
**Note**  
If you view the policy in the AWS Management Console, the console shows warnings for the **ELB** service, but not for the **ELB v2** service. This happens because some of the actions in the policy exist for **ELB v2**, but not for **ELB**. You can ignore the warnings for **ELB**.

**Example**  

1. Replace *my-cluster* with the name of your cluster, *111122223333* with your account ID, and then run the command.

   ```
   eksctl create iamserviceaccount \
     --cluster=my-cluster \
     --namespace=kube-system \
     --name=aws-load-balancer-controller \
     --role-name AmazonEKSLoadBalancerControllerRole \
     --attach-policy-arn=arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerIAMPolicy \
     --approve
   ```

1. Retrieve your cluster’s OIDC provider ID and store it in a variable.

   ```
   oidc_id=$(aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
   ```

1. Determine whether an IAM OIDC provider with your cluster’s ID is already in your account. You need OIDC configured for both the cluster and IAM.

   ```
   aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
   ```

   If output is returned, then you already have an IAM OIDC provider for your cluster. If no output is returned, then you must create an IAM OIDC provider for your cluster. For more information, see [Create an IAM OIDC provider for your cluster](enable-iam-roles-for-service-accounts.md).

1. Copy the following contents to your device. Replace *111122223333* with your account ID. Replace *region-code* with the AWS Region that your cluster is in. Replace *EXAMPLED539D4633E53DE1B71EXAMPLE* with the output returned in the previous step.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
               },
               "Action": "sts:AssumeRoleWithWebIdentity",
               "Condition": {
                   "StringEquals": {
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com",
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:aws-load-balancer-controller"
                   }
               }
           }
       ]
   }
   ```

1. Create the IAM role.

   ```
   aws iam create-role \
     --role-name AmazonEKSLoadBalancerControllerRole \
     --assume-role-policy-document file://"load-balancer-role-trust-policy.json"
   ```

1. Attach the required Amazon EKS managed IAM policy to the IAM role. Replace *111122223333* with your account ID.

   ```
   aws iam attach-role-policy \
     --policy-arn arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerIAMPolicy \
     --role-name AmazonEKSLoadBalancerControllerRole
   ```

1. Copy the following contents to your device. Replace *111122223333* with your account ID. After replacing the text, run the modified command to create the `aws-load-balancer-controller-service-account.yaml` file.

   ```
   cat >aws-load-balancer-controller-service-account.yaml <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     labels:
       app.kubernetes.io/component: controller
       app.kubernetes.io/name: aws-load-balancer-controller
     name: aws-load-balancer-controller
     namespace: kube-system
     annotations:
       eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/AmazonEKSLoadBalancerControllerRole
   EOF
   ```

1. Create the Kubernetes service account on your cluster. The Kubernetes service account named `aws-load-balancer-controller` is annotated with the IAM role that you created named *AmazonEKSLoadBalancerControllerRole*.

   ```
   kubectl apply -f aws-load-balancer-controller-service-account.yaml
   ```

## Step 2: Install `cert-manager`
<a name="lbc-cert"></a>

Install `cert-manager` using one of the following methods to inject certificate configuration into the webhooks. For more information, see [Getting Started](https://cert-manager.io/docs/installation/#getting-started) in the *cert-manager Documentation*.

We recommend using the `quay.io` container registry to install `cert-manager`. If your nodes do not have access to the `quay.io` container registry, Install `cert-manager` using Amazon ECR (see below).

**Example**  

1. If your nodes have access to the `quay.io` container registry, install `cert-manager` to inject certificate configuration into the webhooks.

   ```
   kubectl apply \
       --validate=false \
       -f https://github.com/jetstack/cert-manager/releases/download/v1.13.5/cert-manager.yaml
   ```

1. Install `cert-manager` using one of the following methods to inject certificate configuration into the webhooks. For more information, see [Getting Started](https://cert-manager.io/docs/installation/#getting-started) in the *cert-manager Documentation*.

1. Download the manifest.

   ```
   curl -Lo cert-manager.yaml https://github.com/jetstack/cert-manager/releases/download/v1.13.5/cert-manager.yaml
   ```

1. Pull the following images and push them to a repository that your nodes have access to. For more information on how to pull, tag, and push the images to your own repository, see [Copy a container image from one repository to another repository](copy-image-to-repository.md).

   ```
   quay.io/jetstack/cert-manager-cainjector:v1.13.5
   quay.io/jetstack/cert-manager-controller:v1.13.5
   quay.io/jetstack/cert-manager-webhook:v1.13.5
   ```

1. Replace `quay.io` in the manifest for the three images with your own registry name. The following command assumes that your private repository’s name is the same as the source repository. Replace *111122223333.dkr.ecr.region-code.amazonaws.com* with your private registry.

   ```
   sed -i.bak -e 's|quay.io|111122223333.dkr.ecr.region-code.amazonaws.com|' ./cert-manager.yaml
   ```

1. Apply the manifest.

   ```
   kubectl apply \
       --validate=false \
       -f ./cert-manager.yaml
   ```

## Step 3: Install AWS Load Balancer Controller
<a name="lbc-install"></a>

1. Download the controller specification. For more information about the controller, see the [documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) on GitHub.

   ```
   curl -Lo v2_14_1_full.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.14.1/v2_14_1_full.yaml
   ```

1. Make the following edits to the file.

   1. If you downloaded the `v2_14_1_full.yaml` file, run the following command to remove the `ServiceAccount` section in the manifest. If you don’t remove this section, the required annotation that you made to the service account in a previous step is overwritten. Removing this section also preserves the service account that you created in a previous step if you delete the controller.

      ```
      sed -i.bak -e '764,772d' ./v2_14_1_full.yaml
      ```

      If you downloaded a different file version, then open the file in an editor and remove the following lines.

      ```
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        labels:
          app.kubernetes.io/component: controller
          app.kubernetes.io/name: aws-load-balancer-controller
        name: aws-load-balancer-controller
        namespace: kube-system
      ---
      ```

   1. Replace `your-cluster-name` in the `Deployment` `spec` section of the file with the name of your cluster by replacing *my-cluster* with the name of your cluster.

      ```
      sed -i.bak -e 's|your-cluster-name|my-cluster|' ./v2_14_1_full.yaml
      ```

   1. If your nodes don’t have access to the Amazon EKS Amazon ECR image repositories, then you need to pull the following image and push it to a repository that your nodes have access to. For more information on how to pull, tag, and push an image to your own repository, see [Copy a container image from one repository to another repository](copy-image-to-repository.md).

      ```
      public.ecr.aws/eks/aws-load-balancer-controller:v2.14.1
      ```

      Add your registry’s name to the manifest. The following command assumes that your private repository’s name is the same as the source repository and adds your private registry’s name to the file. Replace *111122223333.dkr.ecr.region-code.amazonaws.com* with your registry. This line assumes that you named your private repository the same as the source repository. If not, change the `eks/aws-load-balancer-controller` text after your private registry name to your repository name.

      ```
      sed -i.bak -e 's|public.ecr.aws/eks/aws-load-balancer-controller|111122223333.dkr.ecr.region-code.amazonaws.com/eks/aws-load-balancer-controller|' ./v2_14_1_full.yaml
      ```

   1. (Required only for Fargate or Restricted IMDS)

      If you’re deploying the controller to Amazon EC2 nodes that have [restricted access to the Amazon EC2 instance metadata service (IMDS)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node), or if you’re deploying to Fargate or Amazon EKS Hybrid Nodes, then add the `following parameters` under `- args:`.

      ```
      [...]
      spec:
            containers:
              - args:
                  - --cluster-name=your-cluster-name
                  - --ingress-class=alb
                  - --aws-vpc-id=vpc-xxxxxxxx
                  - --aws-region=region-code
      
      
      [...]
      ```

1. Apply the file.

   ```
   kubectl apply -f v2_14_1_full.yaml
   ```

1. Download the `IngressClass` and `IngressClassParams` manifest to your cluster.

   ```
   curl -Lo v2.14.1_ingclass.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.14.1/v2_14_1_ingclass.yaml
   ```

1. Apply the manifest to your cluster.

   ```
   kubectl apply -f v2.14.1_ingclass.yaml
   ```

## Step 4: Verify that the controller is installed
<a name="lbc-verify"></a>

1. Verify that the controller is installed.

   ```
   kubectl get deployment -n kube-system aws-load-balancer-controller
   ```

   An example output is as follows.

   ```
   NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
   aws-load-balancer-controller   2/2     2            2           84s
   ```

   You receive the previous output if you deployed using Helm. If you deployed using the Kubernetes manifest, you only have one replica.

1. Before using the controller to provision AWS resources, your cluster must meet specific requirements. For more information, see [Route application and HTTP traffic with Application Load Balancers](alb-ingress.md) and [Route TCP and UDP traffic with Network Load Balancers](network-load-balancing.md).

# Migrate apps from deprecated ALB Ingress Controller
<a name="lbc-remove"></a>

This topic describes how to migrate from deprecated controller versions. More specifically, it describes how to remove deprecated versions of the AWS Load Balancer Controller.
+ Deprecated versions cannot be upgraded. You must remove them first, and then install a current version.
+ Deprecated versions include:
  +  AWS ALB Ingress Controller for Kubernetes ("Ingress Controller"), a predecessor to the AWS Load Balancer Controller.
  + Any `0.1.x ` version of the AWS Load Balancer Controller

## Remove the deprecated controller version
<a name="lbc-remove-desc"></a>

**Note**  
You may have installed the deprecated version using Helm or manually with Kubernetes manifests. Complete the procedure using the tool that you originally installed it with.

1. If you installed the `incubator/aws-alb-ingress-controller` Helm chart, uninstall it.

   ```
   helm delete aws-alb-ingress-controller -n kube-system
   ```

1. If you have version `0.1.x ` of the `eks-charts/aws-load-balancer-controller` chart installed, uninstall it. The upgrade from `0.1.x ` to version `1.0.0` doesn’t work due to incompatibility with the webhook API version.

   ```
   helm delete aws-load-balancer-controller -n kube-system
   ```

1. Check to see if the controller is currently installed.

   ```
   kubectl get deployment -n kube-system alb-ingress-controller
   ```

   This is the output if the controller isn’t installed.

   ```
   Error from server (NotFound): deployments.apps "alb-ingress-controller" not found
   ```

   This is the output if the controller is installed.

   ```
   NAME                   READY UP-TO-DATE AVAILABLE AGE
   alb-ingress-controller 1/1   1          1         122d
   ```

1. Enter the following commands to remove the controller.

   ```
   kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.8/docs/examples/alb-ingress-controller.yaml
   kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.8/docs/examples/rbac-role.yaml
   ```

## Migrate to AWS Load Balancer Controller
<a name="lbc-migrate"></a>

To migrate from the ALB Ingress Controller for Kubernetes to the AWS Load Balancer Controller, you need to:

1. Remove the ALB Ingress Controller (see above).

1.  [Install the AWS Load Balancer Controller.](aws-load-balancer-controller.md#lbc-overview) 

1. Add an additional policy to the IAM Role used by the AWS Load Balancer Controller. This policy permits the LBC to manage resources created by the ALB Ingress Controller for Kubernetes.

1. Download the IAM policy. This policy permits the AWS Load Balancer Controller to manage resources created by the ALB Ingress Controller for Kubernetes. You can also [view the policy](https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy_v1_to_v2_additional.json).

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy_v1_to_v2_additional.json
   ```

1. If your cluster is in the AWS GovCloud (US-East) or AWS GovCloud (US-West) AWS Regions, then replace ` arn:aws: ` with `arn:aws-us-gov:`.

   ```
   sed -i.bak -e 's|arn:aws:|arn:aws-us-gov:|' iam_policy_v1_to_v2_additional.json
   ```

1. Create the IAM policy and note the ARN that is returned.

   ```
   aws iam create-policy \
     --policy-name AWSLoadBalancerControllerAdditionalIAMPolicy \
     --policy-document file://iam_policy_v1_to_v2_additional.json
   ```

1. Attach the IAM policy to the IAM role used by the AWS Load Balancer Controller. Replace *your-role-name* with the name of the role, such as `AmazonEKSLoadBalancerControllerRole`.

   If you created the role using `eksctl`, then to find the role name that was created, open the [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation) and select the **eksctl-*my-cluster*-addon-iamserviceaccount-kube-system-aws-load-balancer-controller** stack. Select the **Resources** tab. The role name is in the **Physical ID** column.

   ```
   aws iam attach-role-policy \
     --role-name your-role-name \
     --policy-arn arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerAdditionalIAMPolicy
   ```