Kubernetes Tutorials: Traffic-Driven Autoscaling on Kubernetes & Comparing KEDA, HPA, VPA & Custom Adapters

Comparing KEDA, HPA, VPA & Custom Adapters for Real-World Scaling with Cost, Complexity & Best Practices

🌐 1 | Architecture Overview

Flow:
Client → DNS → WAF → ALB → TargetGroup → EKS Service/Pods

With EKS Auto Mode, AWS manages node scaling.
Your responsibility is pod-level scaling — deciding how many replicas each service needs based on traffic or resource metrics.

🧩 2 | Namespace-Scoped Design Pattern

• Each microservice (e.g., booking, auth, medical, telematics) lives in its own namespace.
• Each namespace has its Ingress, Service, Deployment, ConfigMap, and autoscaler objects.
• Optionally, multiple namespaces can share one ALB via alb.ingress.kubernetes.io/group.name to save cost while keeping per-namespace isolation.

⚙️ 3 | Ingress & WAF Setup (Shared ALB Example)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: booking-ing
  namespace: booking
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/group.name: shared-edge
    alb.ingress.kubernetes.io/group.order: "20"
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/wafv2-acl-arn: arn:aws:wafv2:ap-northeast-1:111111111111:regional/webacl/mywebacl/abcd1234
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /booking
        pathType: Prefix
        backend:
          service:
            name: booking-svc
            port:
              number: 80

Each namespace can repeat this pattern using different paths (/auth, /legal, etc.) but share the same group.name → one ALB under one WAF.

🚀 4 | Autoscaling Options for Pod Level Control

Below are five viable mechanisms for pod autoscaling inside EKS.

* Cost = relative AWS service charges + operational overhead

🧮 5 | Detailed Analysis of Each Approach

🔹 A | KEDA (Event-Driven Autoscaler)

How it works:
KEDA reads external metrics (CloudWatch ALB RequestCountPerTarget, TargetResponseTime, SQS depth, PromQL queries, etc.) and creates an internal HPA.

Pros

• Supports 50 + scalers (AWS, Azure, Kafka, Prometheus, etc.).
• Scales to zero during idle.
• Simple YAML (ScaledObject) per Deployment.
• Works seamlessly with EKS Auto Mode and NodePools.
• Natively integrates with CloudWatch ALB metrics.

Cons

• Extra component to operate.
• CloudWatch polling → small metric costs and ≈ 1 min delay.
• Needs IRSA permissions for CloudWatch API.

Setup time: ≈ 1 hr (Helm install + ScaledObject YAMLs)
Maintenance: Low (central Helm upgrade + namespace YAMLs)
Recommended for: Multi-namespace EKS clusters with real-traffic scaling.

🔹 B | HPA (Native Horizontal Pod Autoscaler)

How it works:
Built into Kubernetes; scales based on CPU and memory by default.
Can also use custom metrics with an adapter.

Pros

• Native, stable, zero extra components.
• Predictable behavior and fine-grained control.

Cons

• Default metrics = CPU / memory only.
• Cannot scale to zero.
• Needs a metric adapter to use ALB metrics.
• Not event-driven; reactive after load hits CPU.

Setup time: ≈ 30 min
Maintenance: Minimal
Recommended for: Steady workloads or CPU-bound apps.

🔹 C | VPA (Vertical Pod Autoscaler)

How it works:
Adjusts CPU and memory requests/limits per pod automatically.

Pros

• Prevents over/under-provisioning.
• Complements KEDA/HPA.

Cons

• No replica count scaling.
• Not suited for traffic bursts.

Setup time: ≈ 45 min
Maintenance: Low
Recommended for: Batch or steady apps to optimize resources.

🔹 D | Custom Metric Adapters (Prometheus / CloudWatch)

How it works:
Deploy an external-metrics adapter exposing selected metrics to HPA.
HPA then scales on those metrics.

Pros

• Fine control; use any metric you own.
• Integrates into existing monitoring plane.

Cons

• Complex to deploy and maintain.
• Harder to debug.
• No scale-to-zero.
• Usually delayed by scrape interval + adapter polling.

Setup time: 1 – 2 hrs
Maintenance: High
Recommended for: Large orgs with centralized Prometheus or Datadog.

🔹 E | Manual Scaling

kubectl scale deployment <name> --replicas=N

Pros: 100 % control, simple to understand.
Cons: No automation; wastes capacity; high operational risk.
Use only for: testing or stable low-traffic sites.

💡 6 | KEDA Setup Walkthrough (for EKS + ALB)

1. Install KEDA helm repo add kedacore https://kedacore.github.io/charts helm install keda kedacore/keda -n keda --create-namespace
2. Enable IRSA (for CloudWatch) eksctl utils associate-iam-oidc-provider --cluster my-eks --approve
3. IAM Policy { "Version":"2012-10-17", "Statement":[{"Effect":"Allow","Action":[ "cloudwatch:GetMetricData","cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics","cloudwatch:DescribeAlarms" ],"Resource":"*"}] }
4. ServiceAccount + TriggerAuthentication apiVersion: v1 kind: ServiceAccount metadata: name: svc-traffic-autoscale namespace: booking annotations: eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/eks-traffic-autoscale --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: alb-cw-auth namespace: booking spec: podIdentity: provider: aws
5. ScaledObject apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: booking-traffic namespace: booking spec: scaleTargetRef: name: booking-deployment minReplicaCount: 2 maxReplicaCount: 30 triggers: - type: aws-cloudwatch authenticationRef: name: alb-cw-auth metadata: namespace: AWS/ApplicationELB metricName: RequestCountPerTarget dimensionName: TargetGroup dimensionValue: targetgroup/k8s-xyz/abc123456 statistic: Sum period: "60" metricUnit: Count targetValue: "100"
6. Observe Scaling kubectl get hpa -n booking kubectl get pods -n booking -w

📈 7 | Performance & Cost Considerations

🧠 8 | Decision Matrix

🧰 9 | Combining Approaches

A production-grade EKS stack often mixes them:

🔒 10 | Security and Auth Notes

• Keep Firebase OIDC at pod level (not ALB listener), which avoids auth redirect limits.
• Enable IRSA for KEDA & pods requiring AWS API access.
• WAF rules protect ALB from volumetric attacks before KEDA reacts.
• Monitor 5xx errors + TargetResponseTime to guard against scaling loops.

🧭 11 | Final Recommendation

For your multi-namespace, WAF-protected, ALB-routed EKS cluster running in Full Auto Mode,
KEDA is the best fit for traffic-driven autoscaling:

• Event-driven and responsive to real user load.
• Scales independently per namespace/service.
• Integrates cleanly with EKS NodePools for capacity.
• Minimizes cost via scale-to-zero and fine-grained rules.

Use HPA as a fallback for CPU-based logic, VPA for optimization, and custom adapters only when you already maintain Prometheus or Datadog metric infrastructure.

🏁 Summary Matrix

📚 References & Further Reading

AWS Blog – Autoscaling EKS with KEDA & CloudWatch
AWS Docs – EKS Auto Mode & NodePools
KEDA Docs – CloudWatch Scaler
SpectroCloud – Kubernetes Autoscaling Patterns: HPA, VPA & KEDA

✅ Final Takeaway:
If you need hands-off, event-driven, traffic-aware, namespace-isolated scaling for an ALB-fronted EKS cluster,
KEDA + EKS Auto Mode (NodePools) is the modern production-grade combination—
balancing performance, cost, and operational simplicity for any multi-service cloud platform.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.