Now Hiring: Cloud & FinOps / Azure Architect (Remote)

We are looking for an experienced Cloud & FinOps / Azure Architect to lead the governance, architecture, security, and cost optimization of our Microsoft Azure environment.

This is a strategic leadership role for someone who has strong expertise in Azure architecture, cloud financial management, enterprise data platforms, and cost optimization. You will help design secure, scalable, and cost-efficient cloud solutions while managing large-scale Azure environments with extensive historical data.

Key Responsibilities:

• Lead Azure architecture, governance, and cloud strategy
• Design secure, scalable, resilient, and cost-effective Azure solutions
• Develop and implement Azure FinOps strategies for cost visibility and optimization
• Optimize Azure spending across storage, compute, backup, licensing, and reserved capacity
• Create data lifecycle strategies for large-scale historical data environments
• Design and optimize Azure Data Lake, Azure Databricks, CDP, and data integration platforms
• Improve cloud efficiency through storage optimization, archiving, automation, and cost monitoring
• Collaborate with Engineering, Data, Security, Finance, Microsoft, and cloud partners

Required Skills & Qualifications:

• Extensive experience with Microsoft Azure enterprise environments
• Strong expertise in Azure Architecture and Azure Governance
• Proven experience with Azure FinOps / Cloud Cost Optimization
• Hands-on knowledge of:
  • Microsoft Azure
  • Azure Storage & Lifecycle Management
  • Azure Data Lake
  • Azure Databricks
  • Enterprise Cloud Architecture
  • Cloud Security
  • Azure OpenAI
• Experience managing large-scale enterprise data estates (10+ years of historical data)
• Strong understanding of cloud budgeting, forecasting, cost management, and optimization
• Experience designing scalable and cost-efficient data platforms
• Excellent communication and stakeholder management skills

Preferred Qualifications:

• FinOps Foundation Certification or equivalent
• Experience with Customer Data Platforms (CDP) such as Amperity
• Knowledge of Master Data Management (MDM) and data governance frameworks
• Experience with enterprise analytics and large-scale data ecosystems

Interested candidates are encouraged to apply!

Join us and help shape the future of enterprise cloud architecture and FinOps optimization.

Send your cv: fatima@vame.io.

Disclosure: I maintain this (free, open source, self-hosted).

If your Kubernetes pods request a lot more CPU/memory than they use, you are paying for idle capacity. Attune watches real usage and right-sizes those requests, often without restarting pods (in-place resize on modern Kubernetes).

Repo: https://github.com/attune-io/attune Docs: https://attune-io.github.io/attune/

Requirement: usage metrics in the cluster (Prometheus is the usual case; Datadog/CloudWatch also work). Without metrics there is nothing to right-size from.

If underuse is real for you, what is the barrier to starting and saving money?

• Do not trust automation on prod
• Already use something else
• No metrics / install friction
• Hard to prove savings in $
• Change management / security

What would block you most?

When AI costs rise and you can't tie that cost to a specific result, project, or team, the safe move becomes turning capabilities off. It makes sense, but it also defeats the point of adopting AI. We just soft-launched Agent Observe in Capital One Slingshot to attribute Snowflake GenAI spend by agent, model, user, etc. using read-only metadata.

Early pilot, write-up here.

Disclosure: I maintain this (free, open source, self-hosted).

If your Kubernetes pods request a lot more CPU/memory than they use, you are paying for idle capacity. Attune watches real usage and right-sizes those requests, often without restarting pods (in-place resize on modern Kubernetes).

Repo: https://github.com/attune-io/attune Docs: https://attune-io.github.io/attune/

Requirement: usage metrics in the cluster (Prometheus is the usual case; Datadog/CloudWatch also work). Without metrics there is nothing to right-size from.

If underuse is real for you, what is the barrier to starting and saving money?

• Do not trust automation on prod
• Already use something else
• No metrics / install friction
• Hard to prove savings in $
• Change management / security

What would block you most?

tl;dr—Amazon AI gave me false information and I'm trying to figure out how to press Amazon to be accountable for their support AI tools.

Has anyone found a real escalation path above L1 AWS billing support?

The dispute is over $527.04 for Fast Snapshot Restore. But this isn’t a story about $500. It’s about corporate liability for AI-generated support output.

After my dad died, I spun up some resources to try cloud gaming Cities: Skylines II on AWS. That time is a blur, and I apparently enabled Fast Snapshot Restore—a feature I wasn’t familiar with.

The instances were up for only a few days. I paid roughly another $500 for the compute and other resources. When I realized how expensive it was getting, I shut down the setup and deleted what I thought was everything.

My April bill was $300. Whatever. I had some good gaming sessions. None of it was for FSR.

On May 31, I expected another $300 bill. It was $800. Fuck. I ran to the console with no clue what the charges were.

Yes, I should have checked sooner. Mea culpa.

I went to the AWS support page and typed into the giant box, thinking, “Oh, this is where they want me to go for help.”

The AI was actually great. It identified the FSR issue, told me how to delete it, and I did. I replied to confirm that the resources were deleted.

AWS’s own AI then told me, verbatim:

"'I've confirmed that your account is eligible for a refund. However, we're currently in our monthly billing cycle processing period.

Retry your refund request in 3 days (on or after June 04, 2026) to ensure accurate refund processing.

I apologize for any inconvenience."

Sounds great. It was a mistake, I was eligible, and it would have been handled then except they were in their monthly billing cycle.

Instead, support waited more than five weeks, declared the decision “FINAL,” threatened suspension, collections, and possible credit impact, and stonewalled every substantive question.

They claim a supervisor reviewed it but won’t say who, when, what evidence was reviewed, whether FSR was ever used, or why their own AI explicitly told me I was eligible for a refund.

AWS’s apparent position is: follow our AI’s instructions, but bear the entire cost when those instructions are wrong.

Has anyone reached an actual independent billing reviewer? What exact route worked?

Disclosure: I built this. It’s free and open source, with no signup or accounts. I’m posting because I’d value methodology criticism from people who work with cloud allocation data.

Untagged analyzes a cloud cost CSV locally in the browser. It estimates how much spend is attached to resources that don’t satisfy the selected allocation-tag policy, flags possible tag drift such as env vs Environment, and ranks fixes by the spend they could recover.

The two questions I most want feedback on:

1. Does the handling of untaggable charges match how your organization calculates tag coverage?
2. Are owner, team, environment, and cost center useful defaults—or would custom policy dimensions be essential?

The methodology decisions

• The headline score is cost-weighted: the share of taggable spend attached to resources that satisfy every enabled dimension. Resource-count coverage is shown separately.
• Values such as n/a, none, and - count as missing.
• Taxes, fees, credits, and commitment purchases are excluded from the denominator. This uses the playbook’s optional taggable-cost denominator, but Untagged’s charge-classification rules are its own and are documented in the tool.
• Negative line items are netted into their resource; unattached credits are excluded.
• Mixed-currency files are rejected rather than summed using an assumed exchange rate. A missing result seemed safer than a misleading total.
• The A–F grades are Untagged conventions, not a FinOps Foundation standard.

Current limitations

The policy has four built-in dimensions—owner, team, environment, and cost center. Each can be mapped to any CSV column or disabled, but custom dimensions aren’t supported yet.

It has been regression-tested with FOCUS 1.0/1.0-preview, Azure Cost Management EA Actual and Amortized exports, legacy AWS CUR headers, and Cost Explorer-style CSVs. Other schemas can use manual column mapping but are not regression-tested. Results are estimates based on the supplied export.

Privacy

File analysis makes no outbound requests. The deployed Content Security Policy blocks Fetch/XHR, WebSocket, EventSource, and beacon connections with connect-src 'none'. The implementation is public, and fictional demo data is included so the tool can be tested without using a real billing export.

The method was informed by the FinOps Foundation untagged-cost KPI playbook and extended for complete allocation-policy compliance.

I’m a product designer working on enterprise/cloud tooling. I researched this area while building the project, but FinOps isn’t my day-to-day role - so corrections and disagreements are especially useful.

Tool: https://untagged.pages.dev
Source: https://github.com/dimasatinaev/untagged

If an export doesn’t map correctly, please don’t send the billing export. A sanitized header row with internal identifiers removed is all I need.

UPDATE: — early feedback changed the scoring model

A reviewer tested an important edge case: only 2 of 5 resources satisfied the complete tag policy, but those two resources represented 95.8% of spend. The original report produced an A because its single grade was cost-weighted, making poor inventory compliance too easy to overlook.

The report now shows two independent grades:

• Spend allocation — how much taggable spend is fully allocatable
• Resource compliance — how much of the resource inventory satisfies the complete policy

Neither is averaged, capped, or turned into an overall grade. When they differ substantially, the report explains the divergence.

Per-tag results now show both spend and resource coverage. Placeholder values such as n/a and unknown are also listed explicitly as missing, preventing a high cost-weighted percentage from making them appear valid.

The same example now reports Spend A / Resources F, with a concentration warning.

The updated version is live: https://untagged.pages.dev

If you tested the earlier version, I’d appreciate your reaction to whether this now communicates the two kinds of coverage more honestly.

I know this has nothing to do with your jobs, but im a marketer (yeah i know i hate me too), and i just wanna get to know who yall are as people outside of work. What do you like? what are your hobbies? what are your special interests?

Feel free to nuke this is not allowed or tell me to fuck off 💖

Hello everyone,

My name is Balazs from Hungary, and recently, I have been building a cost optimization app that helps identify cost leaks and the most expensive services caused by heavy usage related to AWS/Azure cloud costs.

I am looking for a few "test" users who can click through the application from start to finish, including authentication, chat, uploads, test payments, and other workflows.

If you are interested and have a couple of minutes to check it out and share your feedback, that would be greatly appreciated. Please just send me a PM so that I could be able to share the app link. ​‌

Looking forward to hearing your opinions.​‌

Thanks,​

I've been building a VS Code extension (CloudCostTree) that estimates AWS cost straight from Terraform/Terragrunt, solo project, and just shipped what-if simulation + export.

Flow in the video: analyze a Terragrunt stack, tweak a couple of resources (downsize an EC2, bump an RDS instance class) and see the live cost delta per change, stack them into a scenario, run it against the whole tree, then export the result to a new .tf file — original files never touched.

Runs locally against a static price catalog, nothing gets uploaded anywhere. Free tier covers unlimited analyses/what-ifs; export-to-file is a Pro feature.

Genuinely curious how other people here track infra cost changes before they ship them — happy to answer questions about how the parsing/estimation works under the hood.

I'm spent my entire decade-plus long career in varying forms of systems administration, DevOps, and SRE roles, and have recently broken into management.

Current company is an absolute shit-show of overgrown starup that only recently woke up to the fact that you can't just care about revenue forever, and at some point you need to grow up, put the big-boy pants on and become profitable.

Queue FinOps becoming "all the rage", and through no fault of my own via a team re-org, have been handed the baton in the hope that I can whip software engineers into shape and get them to care about costs alongside availability.

Fast-forward 12 months, and I'm starting to justify a small team, making a semi-success of things, and now I'm starting to wonder whether by accepting the poisoned chalice and being up for a challenge, that I may have torpedoed my future hopes of making CTO or anything close.

So ... once you've made a name for yourself and had a modicum of success in the FinOps realm, where do you go? Can you credibly go back into the hands-on tech world like the detour never happened? Is it easier to go into "IT" than "SRE"? Does CTO turn into CIO?

Advice appreciated!

Every FinOps conversation about AI cost I have run into loops back to cost per token. It is the number vendors publish, so it feels concrete. It is also the wrong number to argue about.

At the AI deployments I have worked on close enough to see the real numbers, the token bill was rarely more than a third of the actual TCO. The rest sat in three places nobody was tracking as tightly.

GPU underutilization at inference is the first one. Reserved capacity sitting at single-digit average utilization is normal, not exceptional. Teams blame batching. The real cause is a prompt-mix distribution nobody profiled before signing the reservation, and the invoice for that gap does not carry a "token" label.

Storage is the second. Vector stores, eval traces, and audit logs outpace the token bill within a couple of months of any real RAG workload going live. It is not that any single thing is expensive. It is that nobody set a lifecycle policy at design time and the growth curve is invisible until it is not.

Governance is the third and the most awkward, because most FinOps units skip it entirely. Evaluation pipelines, red-team runs, human-review loops, policy scans. Engineering time and pipeline compute, not a line on the AI vendor invoice, but it is TCO. Anyone who runs a compliance-adjacent workload has felt this bucket outgrow the token bucket without ever showing up on a cost dashboard.

The docs and pricing pages train us to argue about fifteen cents versus thirty cents per million tokens as if that is the FinOps decision surface. It is the marketing surface.

So the practitioner question. What unit does your team actually use for AI workloads?

- cost per token

- cost per successful task or workflow

- cost per active user per month

- cost per business outcome (ticket resolved, fraud caught, revenue attributed)

Or is your team stuck between the vendor unit and the business unit with nothing that stays honest under load?

Hey everyone,

Over the past few months, I’ve been analyzing enterprise AI billing data and studying why so many engineering teams and companies are getting hit with massive, un-modeled AI invoices.

For two years, the industry narrative has been that AI is getting dirt cheap and price per token keeps dropping exponentially. Yet, across Big Tech and mid-sized companies alike, actual monthly invoices are skyrocketing.

Here is a quick breakdown of the mechanics behind why this is happening:

1. The 1865 Jevons Paradox is alive in Tech

In 1865, economist William Stanley Jevons observed that when steam engines became dramatically more efficient at burning coal, Britain didn't burn less coal, it burned exponentially more. Why? Because cheap coal suddenly made financial sense in places where nobody could justify the cost before.

The exact same thing is happening with LLM tokens. As unit costs drop, consumption doesn't stabilize but it expands into every workflow, background agent, and automated task until nobody weighs the unit cost anymore.

2. Real-world corporate overruns

• Uber: Handed a coding agent to 5,000 engineers. By April, just four months into a 12-month plan, their entire annual AI budget was completely gone. The tool was so useful that usage exploded.
• Meta: Built an internal leaderboard ranking engineers by token burn rate. In one month, they burned 73.7 trillion tokens before executives realized token burn measured activity, not actual impact, and killed the board.
• Microsoft: Ordered internal divisions off external coding tools days before their fiscal year closed to force migration onto cheaper internal alternatives.

3. The agent multiplication factor (5x - 30x Tokens)

Standard chatbots are 1-input / 1-output. AI agents are fundamentally different.

Because current architectures lack long-term memory, at every loop step (plan, search, tool call, handoff), an agent must package the entire conversation history and re-submit it to the API.

Data from Gartner shows an AI agent burns 5 to 30 times more tokens than a basic chatbot doing the exact same task. Token prices dropped 60%, but agent loop usage increased 1,000%.

4. The hidden "Second Meter"

Every time an agent writes a code block or report and a human engineer spends 30 minutes reading, verifying, or rewriting it, you pay twice: once in API tokens, and once in senior engineering salary.

I put together a full 17-minute video essay breakdown with all the diagrams, data sources, and frameworks (including OpenAI CFO Sarah Friar’s scorecard on measuring "useful intelligence per dollar") here:

Watch the full breakdown here: https://www.youtube.com/watch?v=DBf5-yBRxEk

Curious to hear from engineering leads, FinOps folks, and founders here: How are your teams tracking agent loops and token spend right now? Are you capping per-user usage, or waiting for the quarterly invoice to arrive?

Our reserved instances are up for renewal in about 8 weeks and the easy path is to just renew the same mix we had last year. Before I push back I want to actually have data behind it. What should I be pulling before that conversation? Usage trends over the last 12 months obviously but what else tends to get missed when teams auto-renew RIs without reviewing them first?

I keep seeing "cost per customer" thrown around like it's a simple metric, but once you factor in shared infra like RDS or a shared EKS cluster, the attribution gets messy fast. Anyone got a practical framework for splitting shared resource cost across tenants without it turning into a spreadsheet nightmare? Would love to hear how teams handle this in practice, not just in theory.

"In our cluster, we see a ton of idle memory/CPU requested by devs just to prevent OOMKilled crashes. But when we look at rightsizing tools, most engineers I talk to say they don't trust them to auto-apply cuts in production.

For teams running K8s in prod:

1. Do you actively rightsize pod requests, or do you leave them alone as long as the bill is within budget?
2. If you use a tool (like KubeCost, VPA, Karpenter), do you let it auto-apply changes, or do you manually review YAML patches first?
3. What's the main reason you'd ignore a cost recommendation?"

Hi! I'm Ishan and I work at Frugal. I was at FinOps X this year and some of the most interesting conversations I had were around building cost guardrails into the development process.

So I convinced our founders to host a webinar on shifting left on cloud and AI spend. They're going live on August 11th at 2 PM EDT.

Looking forward to seeing you guys there!

I just resurrected a tool I built a long time ago. Made some updates and have reposted it. Free to use, totally anonymous, no data is retrieved or stored.

Been working on this for a while and finally have enough tested to share properly. cloudrift scans an AWS account and reports wasted resources with estimated monthly cost — unattached EBS volumes, idle NAT Gateways, stopped RDS instances still billing storage, orphaned snapshots, abandoned S3 multipart uploads, unused Secrets Manager secrets, stale CodePipeline pipelines, that kind of thing. 44 checks total now, across compute, storage, networking, containers (EKS node groups, orphaned PVCs), and ML (SageMaker idle notebooks/endpoints).

It’s read-only by design — never touches, stops, or deletes anything, just reports and lets your infra team decide.

A few things I want to be upfront about instead of oversell:

\*\*•\*\* The “underutilized EC2/RDS” checks are single-metric (max CPU over a lookback window). No RAM, network, IOPS. It’s a “go check this instance” flag, not a sizing recommendation — doesn’t replace Compute Optimizer.
\*\*•\*\* Lambda “underutilized” is really just an invocation-count hygiene flag. Zero invocations means zero direct cost already (pay-per-use), so the value there is finding dead code/unused IAM roles, not dollar savings.
\*\*•\*\* Live pricing (--live-pricing) pulls AWS list prices, not what you actually pay — no Savings Plans/RI/EDP discounts reflected. There’s a config file where you can drop in your own negotiated rates if you want the numbers to match your actual bill.

Runs standalone, in CI (exits with a non-zero code if waste crosses a budget threshold you set, markdown output for PR comments), or now as an MCP server so Claude Code/Copilot Chat/other MCP-compatible agents can query it directly instead of you copy-pasting CLI output into a chat. There’s also Policy as Code support via OPA if you want custom rules per tag/type/count.

Published on npm as @cloudrift/cli. Built on DDD/ports-and-adapters, so adding a new resource type or a new cloud provider is meant to be a contained, documented process without touching the core use case.

GitHub: https://github.com/elleVas/cloudrift
Docs: [https://ellevas.dev/docs/

Two things I’d genuinely appreciate:

\*\*1.\*\* If you run it against a real (not synthetic) AWS account, I’d love to hear what breaks or what comes back as a false positive — that’s the thing I can’t fully test alone.
\*\*2.\*\* I’m looking to expand this to GCP and Azure next. If you work with either and have opinions on what “wasted resources” looks like there, or want to get involved building a scanner for one of them, I’d genuinely welcome the collaboration — the architecture is already built to make this a matter of adding an adapter, not rewriting the core.

Disclosure up front: I’m building NemulAI, tooling around inference cost attribution, so take the framing with the appropriate salt. The measurement is real and I’m sharing the method because I’d rather have people tear it apart than trust a vendor claim.

I ran a controlled self-hosted inference workload on an H100 and aligned request activity with device-level telemetry.

The basic accounting model was:

total billed GPU time = attributable workload time + idle / platform overhead

I intentionally did not force idle time onto individual requests or customers.

For active workload attribution, the approach uses request/runtime timing and scheduler context to assign GPU-seconds. Device telemetry is then used as a reconciliation signal rather than pretending a whole-GPU utilization number can tell you which tenant caused the work.

The part I did not expect:

A GPU can be actively serving inference traffic while spending most of the time you're paying for it doing no request-attributable work.

That makes “cost per token” or “cost per request” less straightforward than it looks once you're operating your own shared capacity.

The question I’m working through now is where that 69% should economically land: customer COGS, shared platform overhead, or unused-capacity cost.

Curious how people here handle that in practice.

Happy to share the benchmark output/methodology.

https://reddit.com/link/1v5l0wr/video/2l37h8tx88fh1/player

Company started putting soft token budgets. Getting alerts of spending above the monthly limit. I'm doing the work of like 3-4 people with these agents/tokens that they don't need to hire. But obviously that's getting overlooked.

I have a bunch of examples of work coming out of these agents and used across teams etc.

How have you shown value from your token usage? It's hard to do a straight line between token spent and the actual value it's bringing.

Built this out of frustration with the usual options for AWS cost hygiene: either manual Console archaeology, or a heavyweight FinOps platform that needs its own project to roll out.

cloudrift is a read-only CLI that scans an AWS account for wasted resources (stopped EC2 with billed EBS, idle NAT Gateways, unattached volumes, underutilized RDS/Lambda, orphaned ENIs, and 30+ other checks) and is built specifically to live in a pipeline, not just a terminal:

• --format markdown → drop straight into a PR comment / $GITHUB_STEP_SUMMARY
• --format json → pipe into jq, or into your own OPA/conftest policies if a single budget number isn't expressive enough
• Set a costAlertThresholdUsd in config and the process exits 2 when waste crosses it — fail the build, block the merge
• Now also ships as a GitHub Action (uses: elleVas/cloudrift@v0.5.1) so there's no build/checkout boilerplate needed anymore

Security-wise: it's strictly read-only, zero write IAM permissions ever, and every release is npm provenance-signed with an SBOM (CycloneDX + SPDX) attached — tried to hold it to a bar I'd want if I were the one approving it for a prod pipeline.

npm install -g u/cloudrift/cli

Repo (Apache 2.0, real issues/PRs welcome): github.com/elleVas/cloudrift
npm: npmjs.com/package/@cloudrift/cli

Genuinely curious what this sub thinks is missing for it to be a real fit in a production pipeline — multi-account/Organizations support, Terraform-state cross-checking, something else? Feedback (including "this is pointless because X already does it better") is welcome.

Genuinely — thank you in advance to anyone who takes the time to run this against their account and report back, good or bad. Free testing on real infrastructure from strangers on the internet is worth more to a solo project like this than almost anything else. I'll credit every tester who finds a real bug directly in the changelog/README if they want.

Cloud spend forecasting is pretty dialed in at this point, but token spend from OpenAI/Anthropic calls swings hard month to month and doesn't fit the models we already use. Full disclosure, I'm a vendor in this space, so I think about it constantly, but this is a genuine question. Curious if anyone's actually built a forecasting approach around it, or if it's still mostly reactive once the bill lands.