nvidia.com/gpu resource not found on nodes that clearly had GPUs. Every GPU pod stuck in Pending. This is the story of finding and reproducing a regression in NVIDIA Container Toolkit 1.20.0 that shipped in the EKS NVIDIA AMI v20260818.
After Karpenter launched new nodes using the latest EKS NVIDIA AMI (v20260818, which included NVIDIA Container Toolkit 1.20.0), pods requesting nvidia.com/gpu stuck in Pending:
$ kubectl describe pod llm-inference-xyz
Warning FailedScheduling default-scheduler 0/3 nodes are available: 3 Insufficient nvidia.com/gpu.
But the nodes had GPUs — nvidia-smi showed them, drivers loaded, everything looked fine. The NVIDIA device plugin just wasn't registering the nvidia.com/gpu resource. Something in the toolkit upgrade broke the device plugin's ability to start.
Toolkit 1.20.0 added a new update-application-profile CDI hook. On every container create, this hook runs:
mkdir -p /etc/nvidia/nvidia-application-profiles-rc.d
The NVIDIA device plugin mounts its config at /etc/nvidia as a read-only ConfigMap (--config-file=/etc/nvidia/config). When the hook runs mkdir inside that read-only mount, it fails with EROFS (read-only file system). The hook exits non-zero, createContainer fails, and the device plugin never starts — so the node advertises 0 nvidia.com/gpu.
Error in kubelet logs:
createContainer hook #6: exit status 1 ... mkdirat /etc/nvidia/nvidia-application-profiles-rc.d: read-only file system
I stripped it down to the smallest possible test:
g5.xlarge (A10G), g6.xlarge (L4), or g6e.xlarge (L40S) with the affected EKS AMI (v20260818)/etc/nvidia (read-only)EROFSThe same manifests worked on toolkit 1.19.x.
# Minimal repro - deploy this and watch it fail on 1.20.0
apiVersion: v1
kind: Pod
metadata:
name: toolkit-repro
spec:
containers:
- name: test
image: alpine:3.20
command: ["sleep", "3600"]
env:
- name: NVIDIA_VISIBLE_DEVICES
value: "all" # triggers CDI hook
volumeMounts:
- name: config
mountPath: /etc/nvidia
readOnly: true
volumes:
- name: config
configMap:
name: dummy-config # any ConfigMap
I filed the issue at NVIDIA/nvidia-container-toolkit#2026 with:
NVIDIA engineers confirmed the regression. The fix landed in PR #2028 (by @henry118, merged 27 Aug 2026) — the hook now ignores read-only filesystem errors when creating the application profiles directory.
Released in NVIDIA Container Toolkit 1.20.1.
I also filed a tracking issue at awslabs/amazon-eks-ami#2790 for the EKS AMI update.
If you're on EKS and can't wait for the updated AMI, you have two options:
Option 1: Pin to the previous EKS NVIDIA AMI
# Terraform - pin to known-good AMI ID
resource "aws_eks_node_group" "gpu" {
ami_type = "AL2_x86_64_GPU" # or BOTTLEROCKET_x86_64_NVIDIA
# Use the AMI ID from before v20260818, not "latest"
# Find it in EC2 > AMIs > Owned by Amazon > amazon-eks-nvidia-*
}
Option 2: Mount the device-plugin config elsewhere (keep /etc/nvidia writable)
# Device plugin daemonset patch
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nvidia-device-plugin-daemonset
namespace: kube-system
spec:
template:
spec:
containers:
- name: nvidia-device-plugin-ctr
# Change config mount path away from /etc/nvidia
volumeMounts:
- name: config
mountPath: /etc/nvidia-device-plugin # not /etc/nvidia
volumes:
- name: config
configMap:
name: nvidia-device-plugin-config
Pin critical AMIs. The EKS NVIDIA AMI "latest" moved under us. For GPU workloads, pin the AMI ID in Terraform/Karpenter.
Test GPU registration in CI. Add a step that launches a test node, installs the device plugin, and asserts nvidia.com/gpu > 0.
Upstream first. The fix was a one-line change once reproduced. Reporting it saved everyone else running GPU workloads on EKS.
CDI hooks run on every container create. Not just GPU pods — any pod with NVIDIA_VISIBLE_DEVICES triggers the hook. That's why even non-GPU workloads were affected.
I found, reproduced, and reported this upstream; NVIDIA merged the fix in PR #2028, released in v1.20.1. If you run GPU workloads on EKS, upgrade to Toolkit 1.20.1+ or pin to a known-good AMI.
]]>Draw two lines.
Rightsizing comes before the commitment. A provider coverage suggestion, often something like 65% of current on-demand spend, is calculated on the bill you have today, including waste you are about to delete. Commit to the floor you expect to still be running, not to today's average.
The baseline invoice is mostly commitment, at a utilization you can actually hit. The API line is still variable, and it has its own budget. If a month is quiet, the Savings Plan is still earning its discount on the floor. If a month is loud, the overage is on demand, which is cheaper than having bought a plan sized for the peak.
]]>g6 was not there when the session started. Not on Spot, and not as a normal On-Demand launch either. Karpenter would sit on InsufficientInstanceCapacity while a user was already waiting. I used an On-Demand Capacity Reservation to hold the instance before business hours, then release it when the day was over.
The point was the GPU existing at the right moment. The smaller bill was a side effect.
The session-driven service needs one GPU while someone is in a session, and nothing overnight. Scale-to-zero handles the overnight part. It does not help if AWS has no g6 to give you at 9 a.m.
A normal On-Demand run is still "launch it now and hope the AZ has one." On the days that mattered, it did not. An always-on Reserved Instance would have kept a box overnight that nobody was using. An ODCR is a hold on a specific instance type, in a specific AZ, for a window I choose.
EventBridge fires a Lambda before the users' workday and creates the reservation. A second schedule cancels it afterwards. The window covers US Eastern through Pacific hours. Creating it early is the whole trick: the capacity is already matched before the first session, instead of racing a launch at the moment someone logs in.
Compared shapes were g6.2xlarge, g5.2xlarge, and g6e.2xlarge. The reservation I needed was the g6, because that was the family that kept coming back empty.
A few rules I checked against AWS docs so the hold did not surprise the bill:
open and targeted matching are not the same thing. The NodePool has to be able to land on the reservation you just created, or you pay for a hold that Karpenter never uses.The session path this protects is in Scale-to-zero GPU inference on EKS.
]]>node_exporter and vmagent run on the device. An allow-list means only node_* and up leave the machine. Logs stay local. vmagent keeps a 20 GB on-disk queue, so a site that goes dark for days still drains when the link returns. Alloy's write-ahead log covers roughly 8 hours. That was the deciding gap.
Devices push HTTPS to a path-locked public ALB with WAF. The default response is 403. Only POST on the write path is allowed. vmauth checks a per-device token and forwards to VictoriaMetrics. Grafana reads with a different, read-only token. Uptime Kuma, in push mode, alerts when heartbeats stop, which is how you notice a powered-off machine that cannot scrape itself.
Naming is a device_id plus a token. macOS keeps the agent up with launchd. Onboarding is three steps: a short doc, a script that registers the token, and an onboard script for Linux or Mac. Status codes in the troubleshooting guide map to device, network, receiver, or Grafana, so a 403 is not treated as "the agent is down."
This is phase 3 of the rollout, not a finished fleet.
]]>Weights are baked into a 29.5 GB image. The ALB idle timeout moved from 900 to 1,800 seconds. progressDeadlineSeconds on the Deployment is 3,600. The startup probe allows 15.5 minutes for kernel JIT on first start.
The liveness probe (180 seconds) is deliberately slower than the readiness probe (60 seconds). Heavy compute must not look like a dead process. Without the long startup budget, the kubelet kills the pod mid-compile and it loops forever.
Forcing the FlashInfer attention backend failed. Let vLLM pick the backend.
A spot waterfall is the right default for the rest of the platform, written up in Scale-to-zero GPU inference on EKS. This model is the exception. An L40S cannot run NVFP4. Scheduling it there would Pending in a more confusing way, or serve an error after you paid for the node. Pending on the right family is cheaper.
Canary the AMI on one node and confirm it advertises a GPU before you raise the pool limit. A node that never advertises the device still bills.
]]>nvidia.com/gpu, and change only the value.
The NVIDIA device plugin tolerates by key (operator: Exists), so it still runs on every pool and the nodes still advertise GPUs. Each workload tolerates only its own value (operator: Equal), so other GPU apps are repelled.
A new taint key looks cleaner in a diagram. The device plugin does not tolerate it. It will not run on those nodes. The nodes advertise no GPUs. Pods sit Pending. It looks exactly like a capacity shortage, which is how you waste a day raising quotas.
taints:
- key: nvidia.com/gpu
value: workload-a
effect: NoSchedule
The matching toleration on the workload uses operator: Equal and that same value. The device plugin's toleration stays operator: Exists on the key, with no value.
Karpenter still tries the higher NodePool weight first. Put the preferred family at the higher weight, not the lower one.
A sanitized reference pool — spot with on-demand fallback, a GPU limit, WhenEmpty after 15 minutes, a dated AMI alias, and a 150 GiB gp3 root volume — is the shape behind the Blackwell inference pool. Pin the AMI alias to a dated release. latest is how a toolkit bump reaches every GPU node at once.
Setup: g4dn.xlarge, a 3.6 GB image, one run per configuration. Treat the numbers as indicative, not a paper.
| Test | Configuration | Pull time | vs baseline |
|---|---|---|---|
| t0 | AL2023, gp3, 3 parallel downloads | 94.3 s | — |
| t1 | plus NVMe instance store | 91.0 s | −4% |
| t2 | plus 10 parallel downloads | 82.6 s | −12% |
| t3a | Bottlerocket, EBS, 10 parallel downloads | 76.7 s | −19% |
| t3b | Bottlerocket plus NVMe | 77.4 s | −18% |
| t4 | Bottlerocket plus SOCI lazy loading | 92.8 s | −2% |
| t4b | Bottlerocket plus SOCI parallel-pull | 60.8 s | −36% |
| t5 | AL2023 FastImagePull, EBS at 600 MiB/s | 43.0 s | −54% |
| t5b | Bottlerocket, SOCI parallel-pull, NVMe | 48.5 s | −49% |
Lazy loading barely helps ML images. The process needs the model layers immediately, so "start while the rest pulls" does not hide the bytes. Parallel pulling and disk throughput do.
NVMe on its own was a 4% change. Bottlerocket without a pull-mode change was about 19%. The two configs under 50 seconds both pushed more bytes at once: SOCI in parallel-pull mode, or FastImagePull on a faster gp3 volume.
Test t5 ran on a 4-vCPU instance. FastImagePull is reportedly ignored below 8 vCPUs. The EBS jump from 125 to 600 MiB/s may deserve the credit. Re-test on a larger instance before you publish a claim about FastImagePull itself.
SOCI indexes have to be re-pushed for every image and version-matched to the node. Otherwise they are silently ignored, and you are back on a normal pull with extra CI work.
For a roughly 19-node general apps pool, 300 MiB/s of EBS throughput was the cost-efficient point. GPU root volumes in the inference NodePool are a different story: 150 GiB gp3 at 4,000 IOPS and 600 MiB/s, because the image is tens of gigabytes, not 3.6.
A full inference cold start is still minutes once you add the driver and the model load. This table is only the pull. The platform around it is in Scale-to-zero GPU inference on EKS.
]]>About $1,000 a month needed no redesign:
About $1,400 a month was availability I was not ready to pay for yet: a single ClickHouse replica, no Keeper, and a deferred split between ingest and UI.
| Tier | Monthly cost | What you get |
|---|---|---|
| Pilot | ~$0.55K | 20% trace sampling |
| Lean (shipped) | ~$1.0K | Single ClickHouse node, single-AZ Postgres, one queue node |
| AZ-resilient | ~$1.6K | Survives the loss of an availability zone |
| Full HA | ~$2.5K | Replicated ClickHouse with Keeper, split ingest and UI |
The single queue node looked like silent trace loss in the first design. Langfuse writes the event to S3 before it enqueues it, and the queue holds about 12 hours. A dead queue delays traces. It does not delete them. That is the risk the lean tier accepted.
The as-built runbook overrides the design doc wherever they differ. If you only read the ADR, you will build the $3.4K version.
How the cluster is wired, and the seven outages worth preventing, is in Self-hosting Langfuse on Kubernetes.
]]>These are the seven things that cause real outages, plus how the keys survive the move.
Lean tier, about $1,000 a month:
/api/public/otel, from OpenAI, Bedrock, Vertex, and in-VPC models.Langfuse writes each event to S3 before it queues it. Losing the single queue node mostly delays processing. The raw event stays recoverable, and the queue buffers about 12 hours. That is why a single queue node was acceptable. The original design called it silent trace loss. It is not.
The cost reassessment that got the estimate from about $3.4K to about $1.0K is Auditing my own Langfuse estimate.
NODE_OPTIONS=--max-old-space-size. Node defaults to about a 1.7 GiB heap no matter what the container limit is. This is the most common self-hosted Langfuse crash. Set the heap from the limit you actually gave the pod.
Postgres connections. Prisma's default pool is 9 per pod. At an HPA max around 33 pods that approaches max_connections (about 450). Set connection_limit=5.
ClickHouse system log tables have no TTL and will fill the disk. Disable them in config.d on day one.
The queue is not a cache. Set maxmemory-policy=noeviction and alert on any eviction.
ElastiCache Serverless will not work for this. It has no parameter group, so you cannot set noeviction.
Karpenter will consolidate stateful pods unless you stop it. ClickHouse and the queue do not belong on a pool with aggressive consolidation.
Do not co-locate ClickHouse Keeper with ClickHouse if you later add replication. Keeper is sensitive to fsync latency. The lean tier skips Keeper entirely. The full design does not.
Different salt, encryption key, or auth secret invalidates every existing key. Copy those three values verbatim, and pin the same Langfuse version.
pg_dump -Fc and pg_restore.Four things that corrupt the move:
docker exec -t rewrites bytes. Binary dumps come out wrong. Drop the -t.NEXTAUTH_URL has to match the new URL.Lean took about five weeks. Full HA would have been eight to ten. Each phase had a gate: noeviction and TLS, PVCs binding in-zone, a ClickHouse restore drill, then the first trace end to end. That first-trace gate is what turned an interim budget into a full one. Alerts, SSO, an egress allow-list, and a 3× peak load test come after.
The worker's liveness check is a stalled-queue check, not an HTTP ping. An HTTP 200 from a worker that has stopped draining the queue is a green dashboard over a dead pipeline.
]]>The NVIDIA device plugin time-sliced each physical GPU into two slots. A separate device-plugin DaemonSet, with a node selector, covered the spot GPU nodes. Fallback order was g7e, then g6e, then g6.
Scale-to-zero used a KEDA HTTPScaledObject and went to zero after 30 minutes idle. While a GPU was up, cost was about $0.40–1.20 per hour. Idle was $0. A cold start was about 5 minutes.
Pod anti-affinity had to come off, or the two models could never share a node. After enabling time-slicing, check the node's allocatable GPU count. If it still says 1, the slice config did not land.
Time-slicing context-switches one GPU between processes. It does not give you a second GPU. For these models, throughput did not move.
Each pod now gets its own L40S spot GPU and scales 0 to 4 pods per model from an app-published demand count. That is the KEDA metrics-api scaler, with no interceptor. Cost is about $0.80 per hour per GPU while it is running.
Time-slicing fits many small, bursty models that are idle most of the time and can tolerate context switches. It does not fit a throughput target.
Two operational notes from the move:
metrics-api scaler's default 3-second poll timeout kept tripping fallback. Raising it to 10 seconds stopped that.HTTPScaledObject is deprecated. Plan on InterceptorRoute if you stay on the HTTP add-on.
The wider platform is in Scale-to-zero GPU inference on EKS.
]]>g6e या g7e 24/7 चलाओ तो पहला token जाने से पहले ही लगभग $10k/माह जल सकता है। मैंने तीन महीने में AWS EKS पर एक event-driven MLOps platform बनाया जो GPU replicas को zero तक scale करता है, mission-critical sessions को Spot से दूर रखता है, और 15 GB+ LLM images पर sub-60-second cold starts का लक्ष्य रखता है।
यह GPU path है: architecture, hardware constraints, और scars।
Inference traffic bursty है। Fine-tuning और eval jobs और ज़्यादा। Clinical tool पर sessions तब होते हैं जब कोई उसे इस्तेमाल कर रहा हो, फिर रुक जाते हैं। इनमें से कोई 3 बजे रात को गर्म GPU fleet justify नहीं करता।
जो बार-बार दिखता था:
replicas: 1 (या "HA" के लिए replicas: 2) ऐसे nodes पर जो एक से ज़्यादा inference pod pack ही नहीं करतेgp3 से 5–8 मिनट का event हैInsufficientInstanceCapacity) एक GPU family पर — "सस्ता" NodePool pods को Pending में छोड़ देता हैg6.2xlarge) पर पहले concurrent request के KV cache से पहले ही भर चुकी हैलक्ष्य mechanical था: active_sessions == 0 पर कोई GPU burn नहीं, और Spot सूखने पर defined fallback।
Control loop on-demand GPU inference और quantized Qwen 3.5 (NVFP4) server दोनों के लिए एक है:
Client / App ──HTTP / webhook──► API
│
│ active_sessions metric
▼
KEDA
│
│ replicas > 0
▼
Karpenter
┌───────────────┼───────────────┐
│ │ │
g7e Spot g6e / g6 Spot g5 Spot
│ │ │
└───────┬───────┴───────┬───────┘
│ Spot drought │
▼ ▼
ODCR / On-Demand
reserved pool (clinical)
│
▼
EKS GPU node
│
SOCI lazy-load via ECR + S3 VPC endpoints
│
▼
vLLM / SGLang ──► GPU VRAM (gp3)
│
15 min idle ──► KEDA scale to 0
Trigger एक VPC-only URL है। API GPU pod को internet पर expose नहीं करता। वह active_sessions set करता है और replica count KEDA के पास रहता है।
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: gpu-inference
spec:
scaleTargetRef:
name: gpu-inference
minReplicaCount: 0
maxReplicaCount: 4
cooldownPeriod: 900 # 15 minutes
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus.monitoring.svc:9090
metricName: active_sessions
query: sum(active_sessions{workload="gpu-inference"})
threshold: "1"
Spot families weighted fallbacks हैं: पहले g7e (VRAM bandwidth, कम TTFT), फिर g6e / g6, फिर g5। Capacity type Spot है, जब तक नहीं।
वही scaler। दूसरा engine। vLLM / SGLang Qwen 3.5 को NVFP4 (4-bit floating point) में serve करता है। NVFP4 generation quality को naive INT8 cut से ज़्यादा higher-precision baseline के पास रखता है, और FP8/FP16 से लगभग आधा weight memory लेता है। वह headroom KV cache के लिए है, छोटे GPU पर checkpoint गिराने का कारण नहीं।
NVFP4 सिर्फ़ RTX PRO 6000 या B200 / B300 पर चला। वही GPUs NVFP4 kernels execute करते थे। Spot waterfall (g7e, g6e, g6, g5) दूसरे inference path के लिए है, इस server के लिए नहीं।
जो hardware-software co-design सच में मायने रखता था:
max_num_seqs लोककथा नहीं।weights + KV(concurrent seqs × context) + allocator fragmentation से size करो, safetensor file size से नहीं।On-prem Mac Studio clinical tool चलाता है। Session शुरू होते ही webhook API को hit करता है, active_sessions = 1, और KEDA उस session के लिए EKS GPU node cold-start करता है।
यह pool सिर्फ़ On-Demand है। Session के बीच Spot reclaim cost optimization नहीं है। Failed session है। Idle-spend नियम वही रहता है: session खत्म, cooldown fire, replicas 0।
Production से अलग: कई regions में EC2 GPU boxes (L4 / L40S / A10G) cost-arbitrage और SKU availability tests के लिए। Tag enforcement automated है ताकि FinOps allocation किसी के याद रखने पर depend न करे।
| Traffic shape | Scaler | Capacity |
|---|---|---|
| Baseline business hours | KEDA Cron ~15 मिनट पहले pre-warm | GPU NodePool पहले से join कर रहा हो |
| Spiky GPU jobs | Prometheus active_sessions + Karpenter Spot | GPU Spot waterfall |
| Clinical tool / session-critical | Prometheus active_sessions | On-Demand GPU NodePool |
Scale-to-zero तब तक मुफ़्त है जब तक पहला user docker pull के लिए आठ मिनट न बैठे। असली लड़ाई यही थी।
Seekable OCI (SOCI) ECR images index करता है ताकि runtime सिर्फ़ ज़रूरी files pull करते हुए container शुरू कर सके। Index generation की कीमत CI में है (मैं GitHub Actions में async चलाता हूँ); boot पूरे 15 GB disk पर उतरने का इंतज़ार नहीं करता।
SOCI के बिना cold node यह करता है:
SOCI + private endpoints + disk throughput पर critical path करीब यह है: process start → needed pages fault-in → weights load।
Container pulls और weight objects ECR और S3 gateway/interface endpoints से जाते हैं। NAT bandwidth caps और public internet का extra hop हटता है। Cost control भी: GPU nodes का NAT से भारी image pull silent tax है।
Weights अभी भी disk से GPU memory में जाने हैं। जहाँ node class allow करे, gp3 पर elevated throughput (लगभग 1000 MiB/s) ताकि safetensor load default 125 MiB/s से throttle न हो। Tune disk → CPU → PCIe → VRAM है, Kubernetes startupProbe seconds नहीं।
Physics गायब नहीं होती। जिस model को tens of gigabytes weights छूने हैं, वह 200 ms में cold-start नहीं होगा। लक्ष्य हमारे inference images के लिए एक मिनट से कम था — हर checkpoint के लिए जादू की संख्या नहीं।
Single-family GPU NodePool उसी हफ़्ते fail होगा जब GPUs चाहिए। Waterfall InsufficientInstanceCapacity पर Pending से बचाता है।
Priority 1 — performant Spot: g7e (और जब वही best हो तो g6e)। सबसे ज़्यादा VRAM bandwidth, बेहतर TTFT।
Priority 2 — degraded Spot: ऊपर सूखे तो g6 / g5। Latency और batch size बदलते हैं। Product को यह स्वीकार करना होगा, वरना fallback झूठ है।
Priority 3 — guaranteed: On-Demand Capacity Reservations (ODCR) या dedicated On-Demand pool ताकि pods unschedulable न बैठें।
Karpenter में यह multiple NodePools हैं (या wide instance-type set वाला एक pool + अलग ODCR pool) — कोई काल्पनिक priority: 1 field नहीं। Rough shape:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu-spot-waterfall
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"]
- key: node.kubernetes.io/instance-type
operator: In
values:
- g7e.xlarge
- g6e.xlarge
- g6.2xlarge
- g5.2xlarge
taints:
- key: nvidia.com/gpu
value: "true"
effect: NoSchedule
limits:
nvidia.com/gpu: 8
दूसरा NodePool capacity-type: on-demand (और जहाँ reserved हो वहाँ ODCR) clinical tool और drought के लिए है। Latency flex कर सकने वाले inference pods Spot pool सहते हैं; session-critical सिर्फ़ On-Demand — taints, labels, PriorityClasses; hope नहीं।
| Choice | Flex | Scar | Mitigation |
|---|---|---|---|
| KEDA scale-to-zero | Zero GPU idle spend | पहला user cold-start भरता है | Cron pre-warm; SOCI; gp3 throughput |
| Spot waterfall | Cost + कुछ uptime | TTFT SKU के हिसाब से बदलता है | Workload के हिसाब से SLA; clinical tool On-Demand |
| SOCI lazy load | Sub-minute boots | CI में index build | GitHub Actions में async SOCI |
Weights pull करने वाले GPU pods IRSA इस्तेमाल करते हैं। उन containers में AKIA* keys नहीं। बाक़ी platform पर यही नियम non-GPU post में है।
GPU side ख़ुद जोड़ रहे हो तो:
active_sessions पर KEDA।GPU तरफ NVIDIA Video Search and Summarization blueprints Brev Launchables और NemoClaw agent skills से g6e / g7e पर: synthetic FPS footage पर high frame-rate extraction (HUD noise काटने के लिए edge-crop), और घने dashcam video पर lower-rate, motion-filtered indexing। Production वाली ही सीख — idle GPUs optional हैं; cold-start engineering नहीं।
Provider-level GPU notes: Running GPUs in 2026। Unmanaged GPU VMs को EKS में लाने वाला पिछला लेख: Migrating GPU workloads across clouds।
]]>| हफ़्ता | काम |
|---|---|
| 1 | Host छोटा करो और API छुपाओ। Bottlerocket, फिर private EKS endpoint। |
| 2 | Bugs दिखें। हर PR पर SonarCloud, हर image पर Trivy। |
| 3 | Perimeter बंद करो। WAF, branch protection, hardened Dockerfiles। |
| 4 | Static keys खत्म, cluster upgrade, और external test। |
एक quick audit से स्थिति पता चली:
AKIA* credentials) इस्तेमाल कर रही थीं। ये keys environment variables में stored थीं और manually rotate होती थीं (अगर होती थीं)।Catastrophic नहीं, लेकिन जहाँ होना चाहिए वहाँ नहीं — ख़ासकर regulated environment में जहाँ formal security audits आने वाले थे।
पहला बदलाव सभी EKS nodes को Amazon Linux से Bottlerocket — Amazon का purpose-built container OS — पर switch करना था।
Bottlerocket क्यों matters:
yum, कोई apt, कोई dnf नहीं। इससे supply chain attacks की पूरी एक class eliminate हो जाती है।मैंने पहले production में rollout किया (जहाँ सबसे ज़्यादा matter करता था), फिर staging और UAT में extend किया। Migration straightforward था — node group configuration में AMI type update किया, nodes roll किए, और verify किया कि workloads healthy वापस आ रहे हैं।
EKS API endpoint पर public access disable किया और private-only access enable किया। इसका मतलब kubectl commands सिर्फ़ VPC के अंदर से काम करते हैं — practice में VPN से।
यह एक बदलाव पूरा attack vector eliminate करता है। अगर किसी के पास valid Kubernetes credentials भी हैं, API server internet से reach नहीं कर सकते।
SonarCloud को GitHub में directly integrate किया:
यह बहुत सारा low-hanging fruit पकड़ता है — hardcoded secrets, SQL injection patterns, XSS vulnerabilities, insecure random number usage — इससे पहले कि code production तक पहुँचे।
SonarCloud pass होने के बाद, CI pipeline Docker image build करती है। Deploy होने से पहले, Trivy scan करता है:
Scan results CI console में log होते हैं। उस हफ़्ते log-only mode रखा, critical CVEs के लिए भी, ताकि baseline दिखे और किसी का deploy न रुके। Critical findings पर block तब किया जब backlog इतना छोटा था कि deploys freeze न हों।
सभी applications proper AWS Application Load Balancers के पीछे होने के बाद (internal backend services के लिए, external public-facing APIs के लिए), मैंने external-facing ALBs पर AWS WAF enable किया:
Code side पर, stricter branch protection rules enforce किए:
सभी services के Dockerfiles audit किए और hardening approach standardize किया:
latest नहीं)apt-get update && apt-get upgradeDistroless images और Docker Hardened Images (dhi.io से) भी evaluate किए, लेकिन हमारे ज़्यादातर stack के लिए, apt upgrade approach ने security improvement और developer friction का सबसे अच्छा balance दिया।
यह सबसे impactful बदलाव था, और मैंने इसे आख़िरी हफ़्ते के लिए रखा ताकि nodes, API, और scanners पहले से अपनी जगह पर हों।
Problem: हर application जो AWS services (S3, DynamoDB, SQS, Kinesis, etc.) से बात करती थी, उसका अपना static access keys का set था। ये keys:
s3:* या worse)Solution: IAM Roles for Service Accounts (IRSA) — हर Kubernetes ServiceAccount एक specific IAM role से map होता है जिसमें scoped-down permissions।
हर application के लिए migration ऐसा दिखता था:
Python applications से शुरू किया (simpler AWS SDK configuration) और फिर Java apps पर गया। Cutover चलते हुए, पुरानी access keys पर VPC-restricted policies add किए — ताकि अगर leak हों भी, सिर्फ़ VPC के अंदर से इस्तेमाल हो सकें।
Applications migrate होने के बाद, पुरानी bot access keys revoke कीं और Pod Identity Agent को IRSA annotations के long-term replacement के रूप में deploy किया।
सभी environments में EKS v1.30 से v1.31 upgrade किया। Process:
सबसे tricky part addon version matrix है। हर EKS version के लिए हर addon के specific compatible versions हैं। मैंने Terraform में addon versions explicitly pin किए surprises से बचने के लिए।
| Area | पहले | बाद में |
|---|---|---|
| Node OS | Amazon Linux 2 | Bottlerocket (CIS L1) |
| Container scanning | कोई नहीं | हर CI build में Trivy |
| SAST | कोई नहीं | हर PR पर SonarCloud |
| Access keys | Static, long-lived | IRSA / Pod Identity |
| EKS API | Public | Private (VPN-only) |
| WAF | कोई नहीं | सभी external ALBs पर AWS WAF |
| Branch protection | Optional reviews | Enforced 2+ reviews + सभी checks |
| External assessment | कमज़ोर | काफ़ी improved |
इन hardening techniques की step-by-step guides के लिए, docs में EKS Security Hardening Guide देखें।
]]>मैंने hosted observability platforms evaluate किए, लेकिन data residency requirements की वजह से सब कुछ अपने cloud account में ही रखना था। तो मैंने Langfuse — एक open-source LLM observability platform — AWS पर self-host किया। यह रहा architecture और क्या सीखा।
Langfuse LLM observability के लिए एक open-source platform है। यह देता है:
इसे LLM calls के लिए Datadog समझो। SDKs LangChain, OpenAI, और अन्य LLM frameworks के साथ कुछ lines of code में integrate हो जाते हैं।
तीन कारण:
Langfuse v3 के दो main components हैं: एक web server (UI और API) और एक worker (background processing)। इसके पीछे चार data stores चाहिए।
Web server और worker दोनों ECS Fargate services के रूप में चलते हैं:
Fargate यहाँ सही choice था क्योंकि:
हो सकता है वे database passwords और encryption keys जैसे secrets service configuration के साथ रखें, container image के बाहर।
Langfuse transactional data के लिए Postgres इस्तेमाल करता है — user accounts, project configs, session metadata, evaluation scores। एक छोटा t4g.small RDS instance इसे आसानी से handle करता है। Price/performance ratio के लिए Graviton।
यहाँ trace data रहता है — और यह बड़ा हो सकता है। Langfuse traces, spans, और observations पर analytical queries के लिए ClickHouse इस्तेमाल करता है।
मैं ClickHouse एक single EC2 instance पर चलाता हूँ:
c7g.xlarge (ARM/Graviton, 4 vCPU, 8 GB RAM)Managed ClickHouse service क्यों नहीं? Cost। Single EC2 instance पर ClickHouse managed alternatives से dramatically सस्ता है, और एक internal observability tool के लिए, एक ClickHouse node manage करने का operational overhead acceptable है।
ElastiCache Valkey node web और worker services के बीच caching और job queues handle करता है। एक छोटा single node काफ़ी है।
Langfuse event payloads और media uploads (traces से attached screenshots, audio files) S3 में store करता है। दो prefixes: events/ और media/।
Applications (SDK) ──→ Internal ALB (TLS) ──→ Langfuse Web (:3000)
│
Team (VPN से) ─────→ Internal ALB (TLS) ──→ Langfuse Web (:3000)
│
Langfuse Worker (:3030)
│
┌───────────────┼───────────────┐
│ │ │
Postgres ClickHouse S3
(OLTP) (OLAP) (Blobs)
│ │
└───────┬───────┘
Redis
(Cache/Queue)
Internal ALB TLS terminate करता है और सिर्फ़ VPC के अंदर (और VPN से) reachable है। Langfuse UI के लिए Google SSO enable है ताकि टीम existing corporate accounts से sign in करे।
ECS task definitions official Langfuse Docker images reference करती हैं (langfuse/langfuse:3 web के लिए)। Worker अलग image इस्तेमाल करता है।
Configuration पूरी तरह environment variables से:
DATABASE_URL — Postgres connection stringCLICKHOUSE_URL — ClickHouse HTTP endpoint (private IP)REDIS_HOST — ElastiCache endpointS3_BUCKET — Blob storage bucketNEXTAUTH_URL — Langfuse UI का public URLENCRYPTION_KEY — Postgres में sensitive data at rest encrypt करने के लिएLogs CloudWatch में जाते हैं। हर service के लिए अलग log group — easy filtering के लिए।
कुछ लाख traces per month generate करने वाली team के लिए:
| Component | मासिक Cost (लगभग) |
|---|---|
| ECS Fargate (2 services) | ~$70 |
| RDS t4g.small | ~$30 |
| EC2 c7g.xlarge (ClickHouse) | ~$90 |
| ElastiCache (small Valkey) | ~$15 |
| S3 storage | ~$5 |
| ALB | ~$20 |
| कुल | ~$230/माह |
Scale पर Langfuse Cloud की pricing से compare करो, और self-hosting जल्दी pay for itself कर लेता है।
ARM पर ClickHouse great fit है। Graviton instances per dollar ज़्यादा compute देते हैं, और ClickHouse ARM पर natively चलता है। c7g family इसके लिए ideal है।
शुरू से OLTP और OLAP अलग रखो। Langfuse v3 का Postgres (transactions) और ClickHouse (analytics) वाला architecture सही design है। सब कुछ Postgres पर चलाने की कोशिश मत करो — trace query performance जल्दी degrade होगी।
Internal tools के लिए ECS Fargate underrated है। Stateless web services के लिए Kubernetes से simpler है, ख़ासकर जब EKS की full power की ज़रूरत न हो। Task definitions, service auto-scaling, और ALB integration बस काम करता है।
हो सकता है वे secrets image के बाहर रखें, internal tool के लिए। Production application workloads के लिए Secrets Manager या Parameter Store इस्तेमाल करूँगा।
VPN-only access non-negotiable है। LLM traces में prompts और completions होते हैं जिनमें sensitive data हो सकता है। Langfuse UI कभी public internet पर expose नहीं होना चाहिए।
अगर आप LLM workloads चला रहे हैं और उनमें कोई observability नहीं है, तो Langfuse visibility पाने का सबसे तेज़ तरीका है। Self-hosting में लगभग एक दिन लगता है और small-to-medium team के लिए $250/माह से कम cost है।
]]>यह रहा कैसे मैंने OpenVPN CloudConnexa से इसे डिज़ाइन किया।
मैंने self-hosted OpenVPN, WireGuard, और Tailscale evaluate किए। Deciding factors:
VPN split tunnel के रूप में configured है: सिर्फ़ internal network ranges के लिए destined traffic VPN tunnel से जाता है। बाकी सारा internet traffic सीधे user की device से internet पर जाता है।
यह दो कारणों से ज़रूरी है:
CloudConnexa deploy करने के बाद, मैंने सभी internal tools इसके पीछे रखे:
सभी के लिए traffic flow same है: VPN user → Route 53 DNS → Internal load balancer (TLS के साथ) → Service।
Internal load balancers public internet से reachable नहीं हैं। ये private subnets में हैं और सिर्फ़ VPN CIDR range और VPC से traffic accept करते हैं।
Regulated environments में काम करने वाली teams के लिए, यह architecture क्या provide करता है:
| Requirement | कैसे पूरा होता है |
|---|---|
| Encryption in transit | सारा VPN traffic OpenVPN protocol से encrypted; internal ALBs TLS terminate करते हैं |
| Access logging | CloudConnexa user connections, authentication events, और DNS queries के detailed logs maintain करता है |
| MFA enforcement | Google Workspace SAML handle करता है — bypass का कोई तरीका नहीं |
| Periodic audits | Connection logs और DNS logs audit review के लिए exportable हैं |
| Access control | सिर्फ़ specific user groups specific applications access कर सकते हैं |
| Device control | Per user single registered device |
नए टीम member के लिए day one पर:
Total time: 5 मिनट से कम। कोई IT tickets नहीं, कोई config files नहीं, कोई manual steps नहीं।
CloudConnexa जैसा managed VPN self-hosting का operational burden हटाता है और enterprise-grade access controls देता है। SAML SSO, enforced MFA, split tunneling, और geographic restrictions का combination ज़्यादातर compliance requirements cover करता है बिना solution को overengineer किए।
सबसे अच्छी बात: setup में लगभग एक हफ़्ता लगा, और नए user को onboard करने में 5 मिनट।
]]>चार चीज़ों ने यह फ़ैसला push किया:
लक्ष्य सीधा था: सब कुछ AWS EKS में लाओ जहाँ बाकी infrastructure पहले से है, same CI/CD pipelines और monitoring stack से managed।
यह सबसे complex workload था। हम OpenAI का Whisper model audio transcription के लिए चला रहे थे।
GCP पर, यह NVIDIA GPU वाली VM पर standalone process के रूप में चलता था। AWS पर, मैंने इसे NVIDIA Triton Inference Server और TensorRT-LLM से rebuild किया:
convert_checkpoint.py और trtllm-build (FP16, max batch size 2) से। दूसरा stage compiled engines को lightweight Triton runtime image में copy करता है।Target instance: g6.xlarge (NVIDIA L4, 24 GB VRAM) — Whisper FP16 engines के लिए काफ़ी है।
कई छोटे models host करने वाला general-purpose Triton server। यह सीधा Docker image था (nvcr.io/nvidia/tritonserver:24.06-py3) जिसमें persistent storage से model repository mount होती थी।
AWS पर, यह EKS में Karpenter-managed dedicated GPU node pool पर चलता है। Node pool configured है कि सिर्फ़ GPU workloads schedule हों (taints और tolerations से), तो non-GPU pods कभी महँगे GPU nodes पर नहीं आएँगे।
Internal image generation tasks के लिए Stable Diffusion 3। GCP पर g6.2xlarge-equivalent VM थी। AWS पर, same instance type (g6.2xlarge, NVIDIA L4) EKS में।
Migration के बाद पता चला कि यह workload बहुत कम इस्तेमाल होता है। मैंने node group बंद किया और deployment config Git में रख दिया जब ज़रूरत हो तब के लिए। इससे अकेले g6.2xlarge जितना on-demand cost बचा।
हम open-source large language models evaluate कर रहे थे। मैंने vLLM को OpenAI-compatible API server के रूप में सेट किया:
FROM vllm/vllm-openai:v0.6.3
CMD ["--model", "mistralai/Mistral-7B-Instruct-v0.3", "--port", "8080", "--host", "0.0.0.0"]
बेहद सीधा। Image tag pin करो — latest मत भेजो। vLLM KV-cache management, continuous batching, और tensor parallelism अपने आप handle करता है। API OpenAI के chat completions format के साथ compatible है, तो backend services को switch करने में zero code changes लगे — बस URL बदला।
इस workload के लिए, मैंने कई GPU types पर test किया:
Benchmarking से पता चला कि optimal concurrency GPU और parallelism strategy पर बहुत depend करता है। कोई universal "best" setting नहीं है।
GCP VMs से model weights, embeddings, और persistent data S3 में copy किया। Large models के लिए, gsutil से GCS से local staging area में copy किया, फिर aws s3 sync से target bucket में push किया।
हर workload का अपना Dockerfile बना। मुख्य फ़ैसले:
nvcr.io/nvidia/tritonserver:24.06-py3) इस्तेमाल करो, latest नहीं।सभी workloads EKS में Kubernetes Deployments के रूप में deploy:
PriorityClass (value 100000) — ताकि GPU nodes पर किसी lower-priority pods से पहले इन्हें priority मिले।g6.xlarge, g6.2xlarge) provision करता है और utilization कम होने पर consolidate करता है। Non-critical GPU workloads (training, evals) के लिए Spot instances, production inference के लिए on-demand।जब सारा traffic AWS endpoints से flow होने लगा और parity confirm हो गई:
Migrate करने से पहले containerize करो। अगर workload अभी भी VM पर bare process के रूप में चल रहा है, तो पहले source cloud पर ही containerize करो। Cloud migration की complexity जोड़ने से पहले container issues debug करो।
TensorRT-LLM build complexity के बावजूद worth है। Whisper TRT-LLM का multi-stage build trivial नहीं है, लेकिन vanilla PyTorch की तुलना में inference performance improvement significant है। L4 पर FP16 engines ने fraction of the cost पर ज़रूरी throughput दिया।
Open-source LLMs serve करने का सबसे तेज़ तरीका vLLM है। OpenAI-compatible API का मतलब है कि आपके application code को पता नहीं चलता कि वो self-hosted model से बात कर रहा है। Continuous batching variable concurrency को gracefully handle करती है।
जो GPU workloads कोई use नहीं करता, उनके लिए GPU nodes चालू मत रखो। SD3 instance occasional internal use के लिए real money खर्च कर रहा था। Bursty GPU workloads के लिए scale to zero और demand पर spin up — यही सही pattern है।
Clouds consolidate करने से सब simplify होता है। एक IAM system, एक monitoring stack, एक CI/CD pipeline, एक networking layer। Operational overhead reduction instance cost savings से ज़्यादा valuable है।
GPU workloads को अलग-अलग providers पर कैसे चलाता हूँ, इसके बारे में docs में Running GPUs in 2026 guide देखें।
]]>यहाँ वो 8 चीज़ें हैं जिनसे असल में फ़र्क पड़ा।
अगर आप भी कॉस्ट ऑप्टिमाइज़ेशन पर काम कर रहे हैं, तो उम्मीद है ये नोट्स आपके काम आएंगे। अपनी सीख शेयर करने के लिए मेरे सोशल्स पर जुड़ें।
हमेशा अपने deployments में requests और limits सही से कॉन्फ़िगर करें। मेरे केस में, कई पुरानी ऐप्लिकेशन्स जो बमुश्किल इस्तेमाल होती थीं, उनमें अभी भी डिफ़ॉल्ट resource values थीं — या फिर runtime usage से कहीं ज़्यादा।
मैंने staging और UAT एनवायरनमेंट से शुरुआत की। मॉनिटरिंग से मिले real usage data के आधार पर हर ऐप्लिकेशन की CPU और memory requests को रीकॉन्फ़िगर किया। जब दो हफ़्ते तक सब स्टेबल रहा, तब production में भी यही बदलाव किए।
नतीजा चौंकाने वाला था: स्टैक मुख्य रूप से memory-heavy था और CPU usage बहुत कम। मैं m6a.xlarge, c7i-flex, और r6a.xlarge इंस्टेंसेज़ का मिश्रण चला रहा था — compute-optimized और general-purpose मशीनों का ऐसा कॉम्बिनेशन जो workload प्रोफ़ाइल से बिल्कुल मेल नहीं खाता था।
बदलाव के बाद, मैंने सभी एनवायरनमेंट में पूरी तरह r6a.xlarge और r6a.2xlarge (memory-optimized) पर शिफ़्ट किया। मैंने Vantage के MCP server को Cursor से कनेक्ट करके instance types ब्राउज़ किए और अपने region में सबसे कम spot price खोजा।
नतीजा: कम instances, बेहतर bin packing, और fleet में कम DaemonSet pods।
मैं g6.xlarge और g6.2xlarge इंस्टेंसेज़ (NVIDIA L4 GPUs) चला रहा था — हर node पूरी तरह एक ही pod को dedicated था — whisper audio transcription, image generation, और एक general inference server के लिए।
GPU utilization का ऑडिट करने के बाद पता चला:
मैंने GPU instances को Reserved Instances पर शिफ़्ट किया क्योंकि अब वे long-running और predictable थे। इससे on-demand pricing की तुलना में काफ़ी बचत हुई।
नतीजा: कम GPU nodes, हर node पर बेहतर utilization, और on-demand की जगह RI pricing।
यह सबसे आसान जीत थी और सबसे ज़्यादा रिटर्न वाली। मैंने non-production एनवायरनमेंट से शुरुआत की:
spot और on-demand capacity types मिक्स करते हैंजब spot interruption handling पर भरोसा हो गया, तब production में भी stateless workloads और GPU training jobs के लिए spot एक्सटेंड किया।
मुख्य बात: memory-optimized spot instances इस्तेमाल करें (r6a और m6a families जैसी) क्योंकि ap-south-1 region में इनकी spot availability बेहतर होती है और interruption rates compute-optimized types से कम।
नतीजा: सभी non-production एनवायरनमेंट और bursty production workloads में compute costs में काफ़ी कमी।
Right-sizing के बाद, baseline compute needs की साफ़ तस्वीर थी। मैंने commit किया:
g6.xlarge और g6.2xlarge instances अब predictable और long-running थे — 1-year RIs के लिए बिल्कुल सहीट्रिक यह है कि right-sizing से पहले RIs या Savings Plans न ख़रीदें। मैंने देखा है कि टीमें oversized instances पर commitments लॉक कर लेती हैं और फिर capacity use करने में दिक्कत होती है। पहले right-size करो, फिर commit करो।
नतीजा: सिर्फ़ Savings Plans से ~$550/माह बचत, plus GPU RIs से अतिरिक्त बचत।
Databases एक चौंकाने वाला cost center थे। तीन बदलावों से फ़र्क पड़ा:
DocumentDB से MongoDB Atlas में माइग्रेशन: DocumentDB ~$170/माह खर्च कर रहा था। MongoDB Atlas ने नए customers को credits ऑफ़र किए, और माइग्रेशन सीधा था (export, import, connection strings अपडेट)। पहले साल credits से कॉस्ट कवर हुई, और credits ख़त्म होने के बाद भी Atlas pricing कम थी।
RDS right-sizing: कई RDS instances ओवरसाइज़्ड specs पर चल रहे थे जो शुरू में provision किए गए थे। मैंने CPU, memory, connections, और IOPS के लिए CloudWatch metrics रिव्यू किए — फिर जहाँ safe था वहाँ downsize किया। इससे fleet में ~$150/माह बचत हुई।
Unused databases को archive किया: एक पुराना data science database जिसे महीनों से किसी ने query नहीं किया था, उसका snapshot लिया और बंद कर दिया।
नतीजा: Database बदलावों से कुल ~$320/माह बचत।
Storage costs चुपचाप बढ़ते हैं। मुझे ये मिला:
नतीजा: EBS बदलावों से ~$50/माह, plus S3 lifecycle management से ongoing बचत।
यह सबसे बड़ी category थी। ऐसी services जो किसी ख़ास काम के लिए सेटअप की गईं, कुछ समय इस्तेमाल हुईं, और फिर भूल गए — लेकिन चलती रहीं और बिल आता रहा:
नतीजा: Service deprecation से ~$769/माह — Savings Plans से पहले सबसे बड़ी single category।
दो बदलाव जिनमें कोई infrastructure काम नहीं:
AWS पर invoiced billing में शिफ़्ट किया: Credit card payments की जगह invoiced billing पर गए। इससे better payment terms मिले और account team से volume discounts का रास्ता खुला (committed spend पर typically 5-10% monthly bill पर)।
पुराने cloud accounts बंद किए: एक GCP project था जो AWS में workloads migrate करने के बाद ज़्यादातर unused था। Project archive करने और बचे resources साफ़ करने से GCP bill ~10,000 INR/माह कम हुआ।
नतीजा: AWS पर better payment terms और एक पूरा cloud provider bill ख़त्म।
| Category | मासिक बचत (लगभग) |
|---|---|
| Savings Plans (compute) | $550 |
| Elasticsearch deprecation | $504 |
| CloudWatch Insights | $200 |
| DocumentDB → MongoDB Atlas | $170 |
| RDS right-sizing | $150 |
| Load balancer cleanup | $50 |
| GP2 → GP3 | $50 |
| Lambda cleanup | $15 |
| GCP project closure | ~$120 (10k INR) |
| कुल | ~$1,800+/माह |
Spot instance savings (जिसकी fixed number बताना मुश्किल है) और GPU RI discounts मिलाकर, सालाना आँकड़ा आराम से $20,000 USD से ज़्यादा है।
इन techniques की step-by-step guides के लिए, docs section में Cost Optimization Playbook देखें।
]]>