u/bluearch-group

4 post karma · 8 comment karma · joined Sep 2026

  1. 1points

    is finops dead?

    1 comments · source

  2. 0points

    is finops dead? (self.FinOps) [question ]

    9 comments

  3. 0points

    is finops dead? (self.FinOps) [question ]

    14 comments

  4. 1points

    subagent effectiveness (self.Anthropic) [Other]

    0 comments

bluearch-group

we “tombstone” (mark as deletion target”) then kick off a notification drip campaign (via slack or email) to the owners of those resources.

after the notifications go out, and enough time has passed, we begin terminating the resources.

we also open sourced our tag manager that automates a lot of this process; feel free to use the code: https://www.bluearch.io/products/tag-manager

bluearch-group

link?

bluearch-group

what works to manage spend, in your experience?

bluearch-group

how are finops and cost tracking not related exactly? not sure i’m tracking.

bluearch-group

first repost, be nice 😂 thought the thread was good and worth sharing.

bluearch-group

also agree with garbage in, garbage out. i’m not arguing for automation, im asking “how do we make architects better at their job”.

so its not an “automate or don’t automate” thing. it’s a “how do we automate mundane tasks better to free up our time to work on more complicated things” thing. infracost is a good example of this. sits inside an eng workflow. doesn’t require any eng effort. make better decisions. models can add the same value. eg start with giving claude a list of “donts” to improve dev deployments and basic user auth.

bluearch-group

agree. posted most of this in another thread but it’s relevant here too. once models are able to deploy infra reliably, that burden lessens.

the tooling to manage and deploy infra (from inside the engineering workflow) is getting better and the ability to report on costs (from the finance side) is a solved problem, so while i see the need for the work, i see a dwindling need for the role, if that makes sense

bluearch-group

question was “where the real value for architects?” whats wrong about that?

bluearch-group

agree that eng thinks of usage, but once models are able to deploy infra reliably, that burden lessens.

and on the finance side, once cost as a % of revenue is below budget, and $/m tokens is going down/below target, why focus on the backlog at all? that engineering time is better spent growing revenue.

the tooling to manage and deploy infra (from inside the engineering workflow) is getting better and the ability to report on costs (from the finance side) is a solved problem, so while i see the need for the work, i see a dwindling need for the role, if that makes sense

bluearch-group

lots of features. not sure what the value prop is.

bluearch-group

this is very cool

bluearch-group

+1

bluearch-group

i can’t speak to this use case, but i have been able to successfully vet agents and harnesses on their ability to solve aws/architecture related problems by intentionally misconfiguring an ephemeral environment, then measuring the efficiency on which they are able to solve said problems. only use case in practice that i’ve gotten value from.

that said, still very interested the product(s)!

bluearch-group

bedrock allows you to allocate consumption to a specific user; we already have the company org chart and allocate costs that way; on efficiency we look for one ratio - is token consumption going up while costs are going down?

it’s imperfect, but it’s the most useful metric to begin asking (and answering) other questions related to productive use of llms/agents.

bluearch-group

this

bluearch-group

nothing “broke” the trust per se, but it doesn’t take into account things like the product roadmap - the costs behind the architectural decisions - and the expected usage rates of said releases; so never really had the trust to begin with.

bluearch-group

have you checked out the FOCUS schema?

it standardizes naming convention across all the providers, so you can pull the relevant data using the SDKs, and then centralize in your own data warehouse on the FOCUS labels; then you build your reporting layer on top of that.

the data are not as robust as, say, the CUR, but it covers the basics.

EDIT: as for alerts and remediation, as others mention, automated policies using tags, help; and i would follow the same architecture as the reporting layer: logic in each provider to alert, audited by people, centralize alerts into a dashboard/slack channel/etc.

bluearch-group

aws optimization software for finance and engineering, and a terminal first, hotkey based mission control dashboard for agent fleets.

mostly open source.

https://github.com/xxyjoel/ba-mission-control
https://bluearch.io/

bluearch-group

honest q, why not just use artifacts?

bluearch-group

this looks awesome.

bluearch-group

very much dependent upon what you want to DO with the architecture.