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

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

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

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

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

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

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

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

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

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

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

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

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

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

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