Introduction

On Amazon EKS, the exact redirect setup depends on which ingress controller you are using. If you are using the AWS Load Balancer Controller with an ALB-backed Ingress, the standard HTTPS redirect is driven by ALB annotations, not by NGINX annotations. The core pattern is: listen on both 80 and 443, attach a certificate, and enable the ALB SSL redirect annotation.

AWS Load Balancer Controller Redirect

The controller documentation defines:

alb.ingress.kubernetes.io/ssl-redirect: '443'

That tells the HTTP listener to redirect traffic to HTTPS on port 443.

A typical Ingress looks like this:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5  annotations:
6    kubernetes.io/ingress.class: alb
7    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
8    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:123456789012:certificate/abcd-1234
9    alb.ingress.kubernetes.io/ssl-redirect: '443'
10spec:
11  rules:
12    - host: app.example.com
13      http:
14        paths:
15          - path: /
16            pathType: Prefix
17            backend:
18              service:
19                name: app-service
20                port:
21                  number: 80

This is the usual EKS answer when ALB is handling ingress.

What the Annotation Actually Does

The AWS controller docs note two behavior details that matter:

• the redirect port must exist in listen-ports
• once SSL redirect is enabled, each HTTP listener gets a default redirect action and other HTTP rules are ignored

That means you should not try to combine custom HTTP routing logic with the same redirected HTTP listener and expect both to run.

TLS Certificate Requirement

Redirecting to HTTPS only helps if the HTTPS listener has a valid certificate. On EKS with the AWS Load Balancer Controller, that usually means an ACM certificate referenced through:

alb.ingress.kubernetes.io/certificate-arn

Without a valid certificate, the redirect may happen but the HTTPS endpoint will still be unusable.

In practice, that means HTTPS redirect is usually configured together with DNS, ACM, and the Ingress manifest, not as an isolated Kubernetes-only change.

NGINX Controller Is Different

If you are using ingress-nginx instead of the AWS Load Balancer Controller, the configuration changes. In that case, an annotation such as:

nginx.ingress.kubernetes.io/ssl-redirect: "true"

is relevant.

So the first debugging question should always be: which ingress controller is actually reconciling this Ingress?

IngressGroup Caveat

The AWS controller docs also point out that ssl-redirect is exclusive across an IngressGroup. If one Ingress in the group defines it, the setting affects every Ingress in that group.

That can surprise teams that assume each Ingress object is isolated. On shared ALBs, redirect policy can become group-wide behavior.

If you share an ALB across services, review group-wide annotations carefully before turning redirect on in just one manifest.

Basic Verification Steps

After applying the Ingress:

kubectl describe ingress app-ingress
curl -I http://app.example.com
curl -I https://app.example.com

The HTTP request should return a redirect status such as 301 or 302, and the HTTPS endpoint should succeed with the expected certificate and backend response.

If curl -I on HTTP does not redirect, inspect the generated ALB listeners first, because the problem is usually at the load balancer layer rather than in the service.

Common Pitfalls

The biggest mistake is using NGINX annotations on an ALB-backed EKS ingress, or the reverse.

Another mistake is enabling ssl-redirect without defining an HTTPS listener and certificate.

A third issue is forgetting that ALB IngressGroup behavior can make one redirect annotation affect multiple Ingress resources.

Summary

• On EKS with the AWS Load Balancer Controller, use alb.ingress.kubernetes.io/ssl-redirect: '443'.
• Also define HTTP and HTTPS listeners and attach an ACM certificate.
• The redirect applies at the ALB listener level, not inside your application.
• If you are using NGINX instead of ALB, the annotations are different.
• Verify the controller type first, then configure redirect using that controller's documented mechanism.