Last Notes
10 hosts with APM on datadog = $460/mo before a single log line. in practice the real bill lands 2-3x that, because they meter hosts hourly and bill the whole month at the peak.
honest annual range: $6k-$18k to know whether your own servers are healthy.
for a small team that's not a rounding error. it's a hire. a junior engineer's quarter, handed to a vendor to tell you your CPU is high.
self-hosting trades it for one fixed cost: S3 + the box it runs on.
https://rajesh.medampudi.com/blog/lgtm-for-small-teams/
#datadog #observability #selfhosting #devops
https://media.medampudi.com/8665048c4125ba810b175ea35434aefe8c3fdb909cf18871bb89ca5f56f6204d.png
My signing key for software releases (minisign, key ID 0CDC6DA063220C50): RWRQDCJjoG3cDNBpGGjFdULwyP1xWiSk6MiPBFrWysMlDfVuGvaG13Xz — full verify guide: https://rajesh.medampudi.com/verify
vcluster earns its weight in exactly one place: tenants that need their own crds, operators, or cluster-admin. each gets its own api server as a pod on the host cluster, a syncer schedules their pods onto the shared nodes.
if your tenants trust each other and just want their own apps — namespaces + the four native controls. don't run a control plane per tenant for isolation you didn't need.
https://rajesh.medampudi.com/blog/multi-tenant-infra-small-team
#kubernetes #selfhosting #infrastructure #devops
https://media.medampudi.com/cfa1d7fdce2a3c5ff794010c96565641aa6298bec295b05852c155e8e17e6024.png
networkpolicy without a cni that implements it does nothing. the api server accepts your default-deny, enforcement is zero, traffic flows anyway. the silent failure.
test it: two pods, two namespaces, confirm the connection is actually refused. if it isn't refused, your policy is decorative.
https://rajesh.medampudi.com/blog/multi-tenant-infra-small-team
#kubernetes #security #selfhosting #devops
https://media.medampudi.com/bcd11ce7f56cff68822ebd7406f37d0bc6a23be3dd6baeaf9c467c62183d6402.png
i'll argue for self-hosting observability. but conviction cuts both ways, so: when NOT to.
if you fit grafana cloud's free tier — 10k series, 50GB logs, 50GB traces, 14-day retention, 3 users, $0 — self-hosting buys you nothing. it's a hobby with a pager. use the free tier.
also skip it if nobody will own the upgrades, or if your real problem is compliance retention not cost.
the strongest argument names where it loses.
https://rajesh.medampudi.com/blog/lgtm-for-small-teams/
#selfhosting #observability #grafanacloud #devops
https://media.medampudi.com/aaf5bb508d4941c7b6ac257b2879e0c0f9f69864aa0e3e95d822d7bfe7eb425b.png
the k8s quota gotcha that bites everyone once: set a cpu/memory quota on a namespace and every new pod must declare requests or limits, or the api server rejects it at admission. tenants suddenly can't deploy and don't know why.
fix: ship a limitrange in the same namespace so pods without requests get sane defaults. quota sets the ceiling, limitrange fills the floor. together or not at all.
https://rajesh.medampudi.com/blog/multi-tenant-infra-small-team
#kubernetes #infrastructure #devops #selfhosting
https://media.medampudi.com/a3582d866c5faada4cfbc4fd5a919bd040bf0911a739b781d409c78bfa21b105.png
a k8s namespace is not a security boundary. it gives you two things — naming isolation and policy scope. that's it.
the isolation comes from what you wrap around it: namespace-scoped rbac (least privilege, no clusterrolebindings per tenant), resourcequota, default-deny networkpolicy. the namespace is the shelf, the controls are the lock.
https://rajesh.medampudi.com/blog/multi-tenant-infra-small-team
#kubernetes #security #selfhosting #devops
https://media.medampudi.com/514ae64abfa57b5c77cba89d379ae062e607b15e3c598ecafae5b5a285abe25a.png
ran the 3-year math on one personal box (4 vcpu / 16 gb): ~$195 owned (box + power), ~$972 on hetzner, ~$4,400 on aws.
a $150 n100 pays its hardware back vs the cheapest serious cloud in under 6 months — under 6 weeks vs aws. after that it's ~$15/yr of electricity against $324+/yr of cloud you stopped paying.
the box doesn't just pay for itself. it deletes a recurring bill you were treating as a law of nature.
https://rajesh.medampudi.com/blog/home-colo-lab-pays-for-itself
#selfhosting #homelab #infrastructure
https://media.medampudi.com/9e9c021223d97bc00eedc46c32046e28d0bc9db28f26c63afc59053d248c3317.png
most teams building multi-tenant k8s skip the only decision that matters: do the tenants trust each other?
yes → namespaces + rbac + quota + default-deny netpol. native, cheap, enough.
no → no amount of yaml fixes a shared api server and a shared kernel. vcluster or separate clusters.
walk it in order, stop at the first "no".
https://rajesh.medampudi.com/blog/multi-tenant-infra-small-team
#kubernetes #selfhosting #infrastructure #devops
https://media.medampudi.com/51cb31b36f88292776b39866e0f6c223d63e60fdc861042e0d10f199688dd1ea.png
a 10w mini-pc running 24/7 burns ~88 kwh a year. here in hyderabad that's ~₹485/yr. us average, ~$15.5/yr.
i live on this box: nextcloud, self-hosted bitwarden, a bitcoin full node, a nostr relay — one modest machine, and the power cost disappears into the noise of the monthly bill. less to power for a year than two months of the cheapest serious cloud vps.
https://rajesh.medampudi.com/blog/home-colo-lab-pays-for-itself
#selfhosting #homelab #bitcoin #nostr
https://media.medampudi.com/4d12ee749fc3976415ace392552b7735aa55f27b5fb6ebeeb7bd11082a3b1fdb.png
promtail and grafana agent are both dead. agent hit EOL nov 2025, promtail's LTS clock ran out too. if your tutorial installs either, it's stale.
alloy replaces all of it — one binary collecting logs, metrics, traces, profiles, built on opentelemetry. where you ran three agents with three configs, now it's one.
rare deprecation that's a refund, not a tax. there's a converter if you're migrating off promtail.
https://rajesh.medampudi.com/blog/lgtm-for-small-teams/
#grafana #opentelemetry #observability #selfhosting
https://media.medampudi.com/966765f32dbfa78d67f484e9aa3561d9a06a2a483ea0bc3b1019c3381bc16cd1.png
the used enterprise server is a trap for a personal lab. a dell r720 idles ~100w, an r730 ~85w. an n100 mini-pc: ~10w, running the same personal stack.
that's ~10x the running cost, 24/7, for cores a personal workload never touches. cheap to buy, expensive to own — you're buying someone else's discarded power bill. lifetime cost is the number, not sticker price.
https://rajesh.medampudi.com/blog/home-colo-lab-pays-for-itself
#selfhosting #homelab #hardware
https://media.medampudi.com/efa1601643d5ac451463ddd72c98a5e36f97b0df10dc28273e3dda8ae1a8357a.png
single-u colo runs $79+/mo in the us — more than the ~$27 hetzner node it would replace. the same box at home: ~$1.25/mo in power. in india it's worse: rack space sells by the full rack, ₹25k–60k/mo.
colo only pays off amortised across many machines, or when the workload truly needs data-centre power + network. for one personal box, it stays home. don't pay rack rent to host a pi-hole.
https://rajesh.medampudi.com/blog/home-colo-lab-pays-for-itself
#selfhosting #homelab #colocation
https://media.medampudi.com/91adc3829af8ea74063ecd7157e8b1d8123348d0451e74531b2eda8c2e432ccd.png
the $5 vps anchor is why nobody runs the home lab math. a lab doesn't replace one tiny box — it replaces pi-hole + nextcloud + jellyfin + git remote + nostr relay + side projects, plus storage, plus the egress you stop paying for.
price the real spec (4 vcpu / 16 gb) honestly: ~$27/mo cheapest (hetzner, after their apr 2026 hike), ~$122/mo on aws. every month. going up. against that, a $150 mini-pc breaks even in under 6 months.
https://rajesh.medampudi.com/blog/home-colo-lab-pays-for-itself
#selfhosting #homelab #cloudcost
https://media.medampudi.com/8e6bcaca50a1c29f05fc8fe9d9558d12018042c8978703aa0a864622726c763b.png
the part the scaling docs bury, and it's the whole thing:
loki, tempo, mimir each run as a single binary — monolithic mode, every component in one process. not a hack, the supported default. grafana's own docs say monolithic handles ~20GB logs/day.
then point all three at one S3 bucket. compute stays small, data lives in object storage at a couple cents/GB-month. do it day one — retrofitting storage later is the migration you don't want.
https://rajesh.medampudi.com/blog/lgtm-for-small-teams/
#selfhosting #observability #s3 #grafana
https://media.medampudi.com/6c1b56853a35b1b69c132ffb6ab29c01ee80eaaae94ec4a1b27e42a0a74e8568.png
most observability advice is written for someone who isn't you. datadog's quote assumes someone else pays. the 40-service enterprise build assumes you have a platform team.
small team needs neither. loki + grafana + tempo + mimir, simplest mode each, one alloy agent, one S3 bucket. one box. that's the whole thing.
pick the build that matches the team you have, not the one in the tutorial.
https://rajesh.medampudi.com/blog/lgtm-for-small-teams/
#selfhosting #observability #grafana #devops
https://media.medampudi.com/935fe30e7d76163fff3987995334ce28b1f528c5093d8f685450355ba7f314e6.png
whether to leave the cloud isn't ideology. it's five questions, in order:
bill under ~$2k/mo? traffic spiky? someone who WANTS to own infra? egress or steady compute your biggest cost? can you treat a hardware failure as planned, not invisible?
the first "yes" that points back to the cloud wins. i run bare metal because my workload sits on the far side of all five. most don't.
https://rajesh.medampudi.com/blog/bare-metal-vs-cloud
#infrastructure #kubernetes #selfhosting #devops
https://media.medampudi.com/3ed28f7528935a46e8f178bb37b0e9c58b609a4f1d1302e2e7d9a4db221baa35.png
what you're actually paying aws for, and no pricing page shows it: an on-call hardware team you don't staff, elasticity for spiky traffic, and the freedom to NOT become an infra team.
that last one eats senior attention — the scarcest thing a small team has. the cloud's price isn't a scam. i left, and i'd still tell most people who ask me not to.
https://rajesh.medampudi.com/blog/bare-metal-vs-cloud
#infrastructure #kubernetes #cloud #devops
https://media.medampudi.com/6006debd6ef71417e7d2aa43db464ba08bf86e5eaf4afa9a2dc389311b83c826.png
the break-even line for leaving the cloud is more specific than the zealots admit: ~$2-5k/mo spend + workloads above ~50% utilisation.
below it, stay — the hours cost more than the hardware saves. above it, bare metal wins hard. a box at 15% utilisation is expensive no matter who owns it. find your number first, then decide.
https://rajesh.medampudi.com/blog/bare-metal-vs-cloud
#infrastructure #cloudcost #finops #kubernetes
https://media.medampudi.com/c71a540b6cfa84b23876077304663d8a70d429ac0ad0c2ffc57a8d4b515c952c.png
egress is the moat. ship 20 TB out of aws in a month → ~$1,800. the same 20 TB off a hetzner dedicated box → $0.
you can't reserve your way out of egress the way you can with compute. it just scales with how many people use your product. if bytes-to-users is your biggest line item, that alone can justify leaving.
https://rajesh.medampudi.com/blog/bare-metal-vs-cloud
#infrastructure #awscost #selfhosting #egress
https://media.medampudi.com/be9a9d2539ef2a0fba0d58c93217eb304fa28bc25973b9280747df8102e67c6e.png
same class of machine: a hetzner box (16c / 128GB / NVMe) is €119/mo. the nearest aws instance, half the RAM, is ~$677. that's ~5x, on compute alone.
the number is real — i run six of these boxes because of it. but "5x cheaper" is not "you should move." the part that actually decides it never shows up on a pricing page.
https://rajesh.medampudi.com/blog/bare-metal-vs-cloud
#infrastructure #kubernetes #selfhosting #cloud
https://media.medampudi.com/cdcb2e9057a945304e162c3e4c60ce59ba812ced7fbd921bdaf644f06b21730a.png
intelligent-tiering is the right default when you don't know the access pattern — and the wrong one for billions of tiny objects. the difference is a fee most people never read.
on unknown access it's excellent: monitors each object, drops it to IA after 30 days idle, archive instant after 90, no retrieval fee when it gets read again. turn it on, stop thinking about it.
the catch is the monitoring charge is per object, not per GB. a bucket of a billion small objects pays a monitoring fee that dwarfs the savings — and objects under 128KB are never auto-tiered anyway, so you pay the overhead and get none of the benefit. unknown + decent size → intelligent-tiering. known or tiny → plain lifecycle, or just standard.
https://rajesh.medampudi.com/blog/s3-cost-optimization-playbook
https://media.medampudi.com/7c18af54eaf3268dbf773071bd8b247054af359b4b50be2488e6c5a456f08336.png
storage is rarely the biggest line. it's the easiest free money on the bill.
two moves, different in kind. tier it down — S3 lifecycle or intelligent-tiering ages cold data to cheaper classes. standard $0.023 vs deep archive ~$0.001 is 20x on the same bytes. that's recurring savings.
then delete the graveyard: unattached volumes, old snapshots, idle IPv4. tiering recurs. the graveyard is pure waste — delete it and it never comes back.
https://rajesh.medampudi.com/blog/audit-50k-aws-bill
https://media.medampudi.com/a131ef8f6f02806ae8be7e5375b8a149f54e1314c37a83812657d8076ea82b24.png
archive is cheap to store and never free to read. everyone watches the storage line; the retrieval and minimum-duration lines are what ambush you.
colder class = higher per-GB read fee. glacier flexible and deep archive add a per-request fee on top, and deep archive's slowest tier is measured in hours, not seconds. put frequently-read data in glacier to save on storage and then pay retrieval on every read — that's the most expensive mistake in the whole subject. the retrieval bill can beat what standard would've cost outright.
and minimum duration: delete a standard-IA object before 30 days you still pay 30, glacier bills 90, deep archive 180. before you tier anything down, ask the one question that governs all of it — how often is this actually read?
https://rajesh.medampudi.com/blog/s3-cost-optimization-playbook
https://media.medampudi.com/32af24f796388552cf27951cbccdd2494f8d6d16faece807b68e5c0890a80f4d.png
compute optimizer points the direction. but the wins that actually move a bill are three moves, not a CPU spreadsheet.
gp2 → gp3: same volume, ~20% cheaper, and faster.
x86 → graviton: ARM, ~20% less for the same work.
right requests: real usage, not guesses.
i moved an EKS fleet (grafana LGTM, 6 TB/day) to ARM graviton2 under karpenter — 40% off compute, no perf loss. do this before you commit.
https://rajesh.medampudi.com/blog/audit-50k-aws-bill
https://media.medampudi.com/967c56e0a484d9c58329472e0a640eb1386f2e401b7da585d500eb922f49ef17.png
two questions decide whether you write an s3 lifecycle policy or hand it to intelligent-tiering, and most people skip both.
do you know the access pattern? logs cold after 30 days, backups after 90 — if you know, write the policy and s3 moves the data on a schedule. if you don't know — user uploads, a data lake, hot and cold mixed unpredictably — that's exactly what intelligent-tiering is for.
second question: are the objects big enough and not billions of them? if they're tiny or short-lived, neither pays off, stay in standard. and if you do write a policy, set Expiration — storage you delete is storage you stop paying for forever, and it's the most underused line in s3.
https://rajesh.medampudi.com/blog/s3-cost-optimization-playbook
https://media.medampudi.com/33f34908218d7f453df0248d9fa8b89ed58a5e7dadd141a9da5bbcabaafb1339.png
give me read access to a $50k/mo AWS bill and i'll show you where the first fifth is hiding. usually the same four places.
i've run this enough that the pattern is boring. data transfer nobody instruments, boxes sized for a load test two years ago, on-demand on a baseline that never moves, storage rotting in the priciest class.
the audit isn't a pitch before the work. the audit is the work.
https://rajesh.medampudi.com/blog/audit-50k-aws-bill
https://media.medampudi.com/1b9f04c74bbfc9151469e28255c26601e0296c1eb9bc91ae35f127abd4f22f59.png
showback before chargeback. the order matters more than people think.
showback shows each team its slice of the bill with no money attached. chargeback moves the cost onto its budget. lead with chargeback and you get a turf war — teams litigate the allocation instead of fixing the waste.
most over-spend isn't malice, it's invisibility. show a team its number and a real fraction self-corrects before anyone enforces anything. order of operations: inform, then showback, then chargeback for the stubborn remainder. start at the bottom.
https://rajesh.medampudi.com/blog/infra-bill-as-product-metric
https://media.medampudi.com/b912e8d310f46bb47dd7b371997ffc7dad0923952bd31afc42ec634562a4cf66.png
the whole "RIs or savings plans?" decision routes in two questions.
is it redshift or opensearch? → reserved node / reserved instance. no savings plan exists. done. is it another managed database — rds, aurora, elasticache, dynamodb and the rest? → database savings plan, 1-year no upfront, for steady-state.
otherwise it's ec2/fargate/lambda: compute SP for flexibility, ec2 instance SP for the deepest rate, a reserved instance only if you need a capacity guarantee in an AZ or a resale exit. everything else → compute SP, the safe default.
https://rajesh.medampudi.com/blog/ri-vs-savings-plans
https://media.medampudi.com/867f02b20e4e550ffc58c6100359f21580907c25f8cd7b03c729d58f72b1138a.png
before you fix anything, measure. fifteen minutes in cost explorer tells you whether this is a $30 problem or a $3,000 one.
group by usage type. NatGateway-Hours is your fixed cost, number of gateways times hours — not much to chase there. NatGateway-Bytes is the one worth chasing.
then turn on vpc flow logs and see where those bytes go. if a large share is heading to s3, ecr, or dynamodb, that's spend you can zero out with a route-table edit. don't optimise on a hunch.
#aws #cloudcost
https://rajesh.medampudi.com/blog/aws-nat-gateway-hidden-tax
https://media.medampudi.com/a4f409c5c5547e95a656d84443c83d6b36e98a0c6f52f5346c179bc39d652525.png
free s3 win almost everyone leaves on the table.
if your EC2/ECS/lambda in a VPC talk to s3, by default that traffic leaves through a NAT gateway — which bills an hourly charge plus per-GB data-processing on every byte. pulling terabytes from s3 that way is a tax you're paying for nothing.
an s3 gateway VPC endpoint routes the same traffic privately for $0. no hourly, no per-GB, no transfer charge for same-region s3. one route-table edit. caveat: it only covers same-region VPC-to-s3 — on-prem, cross-region or transit-gateway paths need the paid interface endpoint. for the common case you should've created it on day one.
https://rajesh.medampudi.com/blog/s3-cost-optimization-playbook
https://media.medampudi.com/e9ebd4d8469fd412af7e69cea7bc1bf7a8399c65af6e4a2f66b854878424cafe.png
the most expensive AWS mistake isn't paying on-demand. it's locking in a multi-year commitment on a fleet you're about to halve.
the gate is simple. fleet rightsized? if no, resize first — don't commit. stable baseline? if yes, buy the compute savings plan, up to 66% off, sized to that baseline.
a smaller baseline buys a cheaper, more accurate commitment. that's why the order matters.
https://rajesh.medampudi.com/blog/audit-50k-aws-bill
https://media.medampudi.com/6a1d140d1d3f107259f3423330bc6828d61f4d2b03c40404b8ddafb0e808ce77.png
a metric that lives in a monthly finance review is not a metric anyone who moves it ever sees.
the cost of a code path is a property of that code path, same as its latency. so put cost per request on the same grafana board as latency. same screen, same on-call engineer.
an engineer who sees a new endpoint costs 4x per call fixes it in the PR, context hot, for the price of a code review. the same regression caught six weeks later in a finance reconciliation is a forensic investigation. same bug. timing decides the fix cost.
https://rajesh.medampudi.com/blog/infra-bill-as-product-metric
https://media.medampudi.com/cecf5dccb2ead8cf0001dc5a3a0fc5190dda76408d4ef6c96c7279e34ecdc281.png
worth noticing: aws now recommends savings plans over reserved instances for compute. the vendor selling you the RI is telling you to buy the other thing.
the logic is clean. the convertible RI exists for flexibility — the compute SP does that better, automatically, no manual exchanges. the standard RI exists for the deepest rate — the ec2 instance SP matches the 72% and stays flexible inside the family.
both reasons the RI existed for ec2 are now done better by a savings plan. that's why the recommendation flipped.
https://rajesh.medampudi.com/blog/ri-vs-savings-plans
https://media.medampudi.com/106caa05673e1f22154f74fea930693759dec7e634609445090de724d892e09b.png
cutting a nat bill, the order matters more than any single fix, because the cheap no-downside moves capture most of the money.
s3 + dynamodb gateway endpoints — free, one route-table edit. start here.
interface endpoints for ecr and logs — $0.01/GB, under a quarter of nat's rate. cheap, but do the per-service math.
cross-AZ cleanup, and the honest question of whether the subnet needs nat at all.
fck-nat — real savings, but no default failover and a patching burden. last resort.
most teams never get past step two.
#aws #infrastructure
https://rajesh.medampudi.com/blog/aws-nat-gateway-hidden-tax
https://media.medampudi.com/fe1fcb6aff2cf82aceb738151e99359921a3a0f88387d442d119de9c70b40d89.png
before you buy a single savings plan, sweep the free money. none of it needs a commitment and all of it is just sitting there.
unattached EBS volumes still billing. old snapshots nobody deletes. idle public IPv4 — $0.005/hr each since feb 2024, attached or not. and untagged spend, because you can't cut what you can't see.
clean the dead weight first. then size the commitment to a real baseline.
https://rajesh.medampudi.com/blog/audit-50k-aws-bill
https://media.medampudi.com/52e881edf6c6496cf1ea5d208c555354b5c3ad0fefbee4bc74b07b3406ed5b3a.png
the order isn't decoration. each decision makes the next possible.
cut the waste first — free, mostly attention not architecture. then own past your break-even (datadog past my line → built it ~8x cheaper on LGTM). then observe cheaply, because you can't decide the first two without numbers. then staff light. i run all four — k8s, self-hosted observability, the services on top — alone, from a modest house in hyderabad. the load is far lower than the staffing story implies.
https://rajesh.medampudi.com/blog/what-lean-infrastructure-means
https://media.medampudi.com/c95edc690ffc1a48ebfca479d963396f3a5dd1392e01cc3dec514e40e751b38e.png
there's storage on your s3 bill you can't see in the console and you're paying for it right now.
upload a big object in parts, the upload fails partway — dropped connection, crashed job, sdk that didn't clean up — and the parts that landed stay in the bucket. you get billed for them. they don't show in the object listing. they pile up for years.
the fix is one lifecycle rule on every bucket: AbortIncompleteMultipartUpload, 7 days. applies to existing + future uploads, and per aws it doesn't trigger early-delete charges. no downside. set it today before you touch anything else — cheapest win in the whole thing.
https://rajesh.medampudi.com/blog/s3-cost-optimization-playbook
https://media.medampudi.com/fb3ce950d9a5b69530f225814c7fdd772ba75a713109dce3be771c06d9245722.png
four signs your nat gateway is doing a job a free endpoint should be doing: s3 reads from private subnets, ecr image pulls on every deploy, a nat sitting in a different AZ than your workloads, and one nat carrying multiple terabytes a month.
you don't have to guess. turn on vpc flow logs for the nat'd subnets and look at where the bytes go. a big share heading to s3, ecr, or dynamodb is the smell — and the cheapest fix you'll find this quarter.
#aws #devops
https://rajesh.medampudi.com/blog/aws-nat-gateway-hidden-tax
https://media.medampudi.com/578b5a8b735f7b0f79f976f722a28935fe0d566b4548bc929e2cc1ef20e2f53f.png
total dollars on a bill lie, and here's exactly how.
the signal arrives weeks after the decision that caused it. it lands in front of finance, who can read it but can't fix it. the engineer who can fix it never sees it. and total $ can't tell a bill that doubled on growth from one that doubled on waste.
four failures, all structural. divide into a per-unit number and all four fix at once — timely, actionable, owned by the right person, and it tells growth from waste at a glance.
https://rajesh.medampudi.com/blog/infra-bill-as-product-metric
https://media.medampudi.com/8413e1805c253a74e08b91eea5a034217055f472bb16d6ec664326741585818e.png
on 2 december 2025 aws finally launched database savings plans — the gap that kept most database spend stuck on reserved instances for years.
covers aurora, rds, dynamodb, elasticache, documentdb, neptune, keyspaces, timestream and dms. up to 35% on serverless, 20% on provisioned, and it follows the workload across engine, family, size and region.
two catches worth saying out loud: it's 1-year no-upfront only at launch, and it does NOT cover redshift or opensearch — i've already seen that stated wrong. check the official service list.
https://rajesh.medampudi.com/blog/ri-vs-savings-plans
https://media.medampudi.com/6290713b4b767b36083f722f9605d173a09a14665c0e548b14b3490616cb308a.png
how a $120K/mo observability bill quietly happens: three systems billing at once. datadog the official tool. cloudwatch still alive underneath that nobody turned off. and engineers SSHing into boxes to grep logs during incidents because paid search was too slow to trust.
none of them complete, all of them on the meter, spend climbing 15%/mo. the fix isn't clever — one stack you own: grafana LGTM backed by s3, on your own kubernetes, data stays yours. costs become compute + storage, which scale slow. no vendor between you and the 3am fix. one bill you can actually read.
#infrastructure #cloudcost #selfhosting
https://rajesh.medampudi.com/blog/observability-cost-kill
https://media.medampudi.com/4c5f790130f016a44a40e7b9b777c8e4020009ec21c33c66c606757d9f06d03a.png
people hear "lean" and think "cheap." it's the opposite.
cheap is cutting the thing that matters to save a small number — you win a line item and lose the business. lean is spending deliberately on what actually buys you something, so you have room to do the work that moves the business. the point of cutting a $120K/mo observability bill was never the $120K. it was no longer being held hostage by it.
https://rajesh.medampudi.com/blog/what-lean-infrastructure-means
https://media.medampudi.com/48b5d0bd39ae2fd2acd61be99460b98da1c31178256118e58b2a6dbebb8ccb0b.png
give me read access to a $50k/mo AWS bill and i'll find the first 20-30% in a day. not clever — it's always the same four places, same order.
data transfer → rightsize → commit → storage cleanup.
the order is the whole thing. each step makes the next one cheaper. don't commit before you rightsize, don't rightsize a fleet still leaking free traffic through a paid NAT. run it bottom to top.
https://rajesh.medampudi.com/blog/audit-50k-aws-bill
https://media.medampudi.com/fbfa54a6a72776daf71bc14f3d809ab5dc315f246baf3b043324ba44be99cc48.png
the trap that quietly reverses your s3 savings: standard-IA, one zone-IA and glacier instant all bill every object as if it were at least 128KB.
so you take a bucket of 10KB thumbnails, move it to a "cheaper" class to save money, and now each object bills at 128KB. you're paying for ~12x the bytes you actually store. the per-GB label looked cheaper, the bill came back higher.
small objects stay in standard. check your average object size before tiering anything down — under 128KB and IA is just wrong, no matter how cold the data is.
https://rajesh.medampudi.com/blog/s3-cost-optimization-playbook
https://media.medampudi.com/3af0ba4769d6f20212edfc5d130ee400bcfeb98db854620cccae3ecc582644ba.png
the whole unlock is dividing.
total infra cost over requests = cost per request. over tenants = cost per tenant. the finops foundation calls it unit economics. the arithmetic is trivial. the shift it forces is not.
two buckets worth keeping separate: resource-efficiency (cost per GB, per vCPU, per token) tells you how the machinery is wasting. business metrics (cost per tenant, cost to serve) tell you whether it matters. once cost is per-unit, a rising bill stops being scary by default.
https://rajesh.medampudi.com/blog/infra-bill-as-product-metric
https://media.medampudi.com/f0a2a892befca3dbce052749842d659326fc732e5331af05ce9cd44110d722a0.png
savings plans are the default now, but not the answer to everything. there are exactly three corners where the reserved model is still the only lever you have.
redshift uses reserved nodes, opensearch uses reserved instances — no savings plan covers either, even after the dec 2025 launch. a zonal RI reserves capacity in a specific AZ; a savings plan reserves none. and a standard RI can be sold on the marketplace; a savings plan can't be cancelled mid-term.
everything outside those three → savings plan.
https://rajesh.medampudi.com/blog/ri-vs-savings-plans
https://media.medampudi.com/50cd1bf2b44060836666e028d1b4be3b5d505a137c898f3a384c8616042d211f.png
the most common reason a nat gateway bill creeps: s3 reads from private subnets going out through nat at $0.045/GB.
the fix is free and almost nobody does it first. gateway endpoints for s3 and dynamodb cost nothing — no hourly fee, no per-GB fee. you add a route, and that traffic goes over a private aws path instead of through the meter. it never touches nat again.
do this before anything fancier. most teams never need to go further.
#aws #cloudcost
https://rajesh.medampudi.com/blog/aws-nat-gateway-hidden-tax
https://media.medampudi.com/fb94d6dc380dd2dc3a6d29d8189aa815d8ac91e3fa6cfc351706e18bc03dd332.png
a fifth of enterprise cloud spend — ~$44.5B in 2025 — goes to resources nobody is using (harness, finops in focus 2025).
that's not carelessness. it's the default state of a bill nobody is actively cutting. idle instances, commitments bought on a guess, storage that should've aged into a cheaper tier months ago. assume you're overspending — the data says you are — and go look once a month. you'll find the leak.
https://rajesh.medampudi.com/blog/what-lean-infrastructure-means
https://media.medampudi.com/bf3b3b0a7b4ea55698a22ea374ac3976ac7a61d18f189366ae7655ffdff5f344.png
the stack that replaced the saas bill, and it's boring on purpose: loki for logs, mimir for metrics, tempo for traces, grafana for dashboards + LogQL. running on our own kubernetes, 50+ nodes, 200 services, all backed by s3 underneath.
two surprises: log search was faster than the paid tool, and with no per-seat cost 15 teams onboarded in month one instead of rationing licences. we ran it in parallel with the old tooling for a full month before decommissioning anything — you don't pull monitoring during a tournament with 100k players online and hope.
#observability #grafana #kubernetes
https://rajesh.medampudi.com/blog/observability-cost-kill
https://media.medampudi.com/c2d867877ab5ecc80c0dffc68656b2b8ad0b5fc87438d2de5d39c860c3412b46.png
