Anshul Singh Chauhan

You got here in ms, measured just now.This page measures itself in your browser. This site's Terraform, pipeline and scans are public.

Live Measured in your browser, or written by this site's pipeline.

These numbers are measured in your browser, so they need JavaScript.

How this page reached you, measured in your browser

Step	Measured

This site right now

Up since

3 Nov 2026

Last deploy

3 Nov 2026, 15:26 UTC

Last commit

3d55701

• Pipeline passing
• Trivy passing

See how this site is builtRead the code

An EKS lab with tiers split by taints and affinity. TLS ends at the ALB, and here's what's still exposed.

Recorded Real config from the Three Tier Lab repo, with IDs, ARNs and domains removed.

Top layer, the public subnets: the ALB along the back, the NAT Gateway, the bastion and two frontend nodes. Bottom layer, the private subnets: two API and database nodes, each with its taint marker on top.

The parts, and why each is there

ALB

AWS Load Balancer Controller creates it from the Ingress, so routes live with the app's manifests, and TLS ends there with an ACM certificate.

kind: Ingressmetadata:  annotations:    alb.ingress.kubernetes.io/scheme: internet-facing    alb.ingress.kubernetes.io/target-type: ip    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'    alb.ingress.kubernetes.io/certificate-arn: <removed>    alb.ingress.kubernetes.io/ssl-redirect: "443"spec:  ingressClassName: alb  rules:    - host: <removed>      http:        paths:          - path: /            pathType: Prefix            backend:              service:                name: frontend                port:                  number: 3000

NAT Gateway

Private-subnet API and database nodes reach out for images and patches without public IPs.

README only: documented, no manifest exists

• In a public subnet.
• Egress for the private nodes.
• Used for ECR pulls and OS updates.

Bastion

The EKS API is private, so kubectl needs one controlled way in.

README only: documented, no manifest exists

• IMDSv2 enforced (HttpTokens: required).
• SSH restricted to the operator's IP.
• SSM Session Manager as secondary access.

Taints and affinity

Keep the API and database on their own private nodes.

Node group: taint dedicated=db-api:NoSchedule, label workload=db-api.

affinity:  nodeAffinity:    requiredDuringSchedulingIgnoredDuringExecution:      nodeSelectorTerms:        - matchExpressions:            - key: workload              operator: In              values:                - db-apitolerations:  - key: dedicated    operator: Equal    value: db-api    effect: NoSchedule

What breaks here

• TLS ends at the ALB. Traffic behind it is plain HTTP.
• MongoDB uses a HostPath volume, so its data is lost if the node is replaced.
• There's no cluster autoscaler, so node count doesn't follow load.
• The frontend runs on a public-subnet node, which widens the blast radius.
• Both deployments use an image pull secret, so image delivery isn't credential-free.

Autoscaling reacts late. Jump the dial and watch latency climb before pods arrive.

Simulated Runs in your browser on the repo's real config. Assumptions are listed below, dated 2 Nov 2026.

This demo runs in your browser and needs JavaScript. The picture shows its resting state.

Pods, running copies of the app

• Ready
• Ready

Latency: how long a request waits, log scale

Dial: requests per second10

200: 2 pods' limit 600: 6 pods' limit

Jump past the first mark. Turn it slowly and the pods keep up.

Kill a pod

Run in real timeStart again

Latency

21 ms

Ready pods

2 of 2

Timed out

0

New pods took

no climb yet

Peak latency

no climb yet

Simulated time

0 s

Clock speed

5× real time

Ready pods

This picture shows the resting state. The pods list is live.

Steady. 2 pods are handling 10 requests a second.

What breaks here

• The CPU target is measured against the 100m request, not the 500m limit. At target, six pods use 360m of a 3,000m combined limit, so the autoscaler runs out of pods long before they run out of headroom.
• The readiness probe calls /ok, which doesn't check MongoDB. A pod can be Ready with the database down.

Assumptions

From the repo

Minimum 2 pods, maximum 6, CPU target 60%. CPU request 100m, limit 500m. Readiness probe on /ok: first check at 5 s, then every 5 s.

Kubernetes defaults

The controller runs every 15 s with a tolerance of 0.1. Scale-down waits 300 s. Scale-up adds the larger of 4 pods or 100% every 15 s. Pods not yet ready count as 0% on the way up.

Assumed, 2 Nov 2026

Metrics every 15 s, the value in metrics-server's shipped manifest. 5 ms of CPU per request, 20 ms base latency, 12 s for a container to serve, 30 s client timeout, 5m idle CPU, 1 s to create a replacement. MongoDB and node capacity aren't modelled. Latency values depend on these assumptions.