AWS Load Balancer Controller - Ingress Internal LB for SwiftShop Innovations

Deploying Ingress Internal Load Balancer for SwiftShop Innovations

AMJ Cloud Technologies collaborated with SwiftShop Innovations, an e-commerce company, to enhance their AWS Elastic Kubernetes Service (EKS) cluster by deploying an Internal Application Load Balancer (ALB) using Kubernetes Ingress. This project secured internal access to SwiftShop’s microservices (frontend, backend, and default interfaces) by configuring an internal ALB, tested via a curl-pod within the cluster. The solution eliminated public-facing ALB exposure and simplified internal service access, ensuring secure, scalable operations for their e-commerce platform.

Situation

SwiftShop Innovations needed to secure their e-commerce microservices by restricting access to internal network traffic only. Their previous setup used public-facing ALBs, posing security risks for sensitive services. AMJ was tasked with configuring an Internal ALB using Ingress to route traffic to microservices within the EKS cluster, verifying access via a curl-pod, and ensuring robust health checks for reliable operation.

Task

The objectives were to:

• Configure an Ingress manifest with the alb.ingress.kubernetes.io/scheme: internal annotation for an Internal ALB.
• Deploy and verify Kubernetes manifests for microservices and Ingress.
• Deploy a curl-pod to test internal ALB connectivity.
• Verify health checks and routing for frontend, backend, and default services.
• Test application access using the internal ALB DNS (internal-ingress-lb.<region>.elb.amazonaws.com).
• Complete the project within one month.

Action

Our team executed the following steps, adhering to AWS and Kubernetes best practices:

Prerequisites

• Used SwiftShop’s existing EKS cluster (ecommerce-cluster, version 1.31) with the AWS Load Balancer Controller (v2.8.0) installed:

  helm install load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=ecommerce-cluster --set image.tag=v2.8.0

Configure IngressClass

• Used the existing default IngressClass:

  apiVersion: networking.k8s.io/v1
  kind: IngressClass
  metadata:
    name: alb-ingress-class
    annotations:
      ingressclass.kubernetes.io/is-default-class: "true"

Deploy Microservices

• Deployed SwiftShop’s microservices (frontend, backend, default) with NodePort Services:

  apiVersion: v1
  kind: Service
  metadata:
    name: frontend-service
    annotations:
      alb.ingress.kubernetes.io/healthcheck-path: /frontend/index.html
  spec:
    type: NodePort
    ports:
      - port: 80

• Applied similar configurations for backend-service (/backend/index.html) and default-service (/index.html) using files frontend-deployment.yaml, backend-deployment.yaml, and default-deployment.yaml.

Configure Internal ALB Ingress

• Configured the Ingress with the internal scheme annotation:

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: internal-lb-ingress
    annotations:
      alb.ingress.kubernetes.io/load-balancer-name: ecommerce-ingress
      alb.ingress.kubernetes.io/scheme: internal
      alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
      alb.ingress.kubernetes.io/healthcheck-interval-seconds: "15"
      alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
      alb.ingress.kubernetes.io/success-codes: "200"
      alb.ingress.kubernetes.io/healthy-threshold-count: "2"
      alb.ingress.kubernetes.io/unhealthy-threshold-count: "2"
  spec:
    ingressClassName: alb-ingress-class
    rules:
      - http:
          paths:
            - path: /frontend
              pathType: Prefix
            - path: /backend
              pathType: Prefix
            - path: /
              pathType: Prefix

• Applied manifests:

  kubectl apply -f manifests/

Deploy and Test with Curl-Pod

• Deployed a curl-pod for testing:

  apiVersion: v1
  kind: Pod
  metadata:
    name: curl-pod
  spec:
    containers:
      - name: curl
        image: curlimages/curl
        command: ["sleep", "600"]

• Applied the curl-pod manifest:

  kubectl apply -f curl-pod.yaml

• Tested internal ALB connectivity from the curl-pod:

  kubectl exec -it curl-pod -- sh
  curl internal-ingress-lb.<region>.elb.amazonaws.com/frontend/index.html
  curl internal-ingress-lb.<region>.elb.amazonaws.com/backend/index.html
  curl internal-ingress-lb.<region>.elb.amazonaws.com/

Verify Deployments

• Verified Kubernetes resources:

  kubectl get ingress
  kubectl get deploy,pods,svc

• Confirmed ALB settings, listeners (80 only, as HTTPS was not specified), and routing rules in the AWS Console (EC2 > Load Balancers).
• Verified target group health checks and targets in the AWS Console.

Result

The project delivered a secure, internal solution for SwiftShop Innovations:

• Scalability Achievement: Enabled secure internal access for e-commerce microservices via an Internal ALB.
• Automation Level: Fully automated Internal ALB and Ingress setup with Kubernetes manifests.
• Security Improvement: Restricted access to internal network traffic with robust health checks.

Technologies Used

• AWS EKS
• AWS Load Balancer Controller
• Kubernetes Ingress
• Application Load Balancer

Key Takeaways

This case study showcases AMJ Cloud Technologies expertise in securing SwiftShop Innovations’ e-commerce platform with an Internal ALB. The Ingress configuration and curl-pod testing ensured reliable, restricted access to microservices, offering a model for internal service deployments in similar industries.