CommPulse

Hi everyone, I’m from Korea, and English isn’t my first language, so I used AI to help translate this post. I’ve been experimenting with different AI tools and projects for a while. During that process, I ended up with a much larger token bill than I expected. That experience made me think there should be a better way for people and companies to use AI without constantly worrying about costs, while still keeping the system reliable and safe. At first, I started building something just for my own use. I added features one by one, and over time the project became much bigger than I originally planned. Eventually, I started wondering whether it could become a real business. But I’ve run into a problem. In Korea, I haven’t been able to find many companies that are openly talking about this issue or looking for a solution. I’m not sure whether the problem isn’t serious enough yet, or whether companies simply don’t want to share their AI cost problems publicly. So I’d really appreciate some honest feedback from developers, engineers, founders, or anyone operating AI products in production. Are AI or LLM costs a real problem for you? What part of cost management is the most difficult? How do you currently track costs by model, feature, customer, or request? What kind of tool or service would actually be useful? Have you tried solving this problem already? If so, what didn’t work? Any practical advice or real-world experience would be very helpful. I’m still trying to understand whether this is a problem worth solving and what people actually need. Thank you. submitted by /u/MutedMaintenance6420 to r/FinOps [link] [comments]

Disclaimer: personal affiliation but the tool is free to use https://preview.redd.it/74no8zy0bdhh1.jpg?width=1280&format=pjpg&auto=webp&s=2aadf213c2bce5fba8c0feca988e88dead8d1c50 I built a free CLI that scans AWS for likely waste patterns and reports estimated cost + carbon opportunities. npx greenops-scan Why this might be relevant here: Runs locally and uses read-only AWS APIs. Credentials stay on the operator machine. Produces JSON + PDF findings for triage. I am specifically looking for DevOps feedback on signal quality: which findings are useful vs noisy, and what evidence should be added to reduce false positives. submitted by /u/slawa-pid to r/FinOps [link] [comments]

Disclosure, I work at Login VSI. The FinOps question we keep hearing about AVD Hybrid: which workloads are worth running hybrid vs. fully cloud once you factor licensing and management overhead. Live chat on that, with Marcel Meurer (creator of Hydra, built around cost efficiency), Steve Downs and Andrej Radinger (Microsoft), and Ron Oglesby (Login VSI). Bring questions or drop them here. Thursday, September 10, 11am ET: Register Here submitted by /u/LoginVSIMax to r/FinOps [link] [comments]

If your GitHub Actions jobs are stuck in "Queued" or waiting for a runner, GitHub has now confirmed there is an incident. GitHub says they identified an issue with a database primary and are failing over to a replica. Actions is affected, and GitHub Pages is also experiencing degraded performance. So if you have been checking your workflow, runner settings, permissions or billing, it might not be your configuration. Status page: https://www.githubstatus.com/incidents/y1t7p9fzrlj2 Hopefully this saves someone else from spending an hour debugging their YAML. submitted by /u/Codeblix_Ltd to r/devops [link] [comments]

Currently working at a fast moving startup, and have been assigned work related to providing alerting and monitors to our crucial P0 infrastructure. At a high level, the real goal of this is to provide engineers during incidents a fast way to root-cause whether the page was due to their service breaking, or if the underlying infrastructure is down. For example, if our DNS provider is down, a product engineer may be paged and spend time trying to root-cause why their service is having a bunch of 404s when the actual root cause is down one level of the stack. I was thinking of introducing a common set of protocols that everyone could follow using our paging service (incident.io); they would first spend time to look at our set of monitors and see if anyone was alerted regarding core infrastructure, and if not, they could then move up a level and spend time triaging at the service level. Obviously this would also include aid during the triage by agents. This would also give us metrics on time spent on firefighting our core infra vs service level issues. But I am so totally new to all this, so what does your teams process look like? Has anyone tried something similar before and noticed this was faulty? Truly, I am open ears to anything regarding this sort of triage work, so any insights, small or big is appreciated submitted by /u/MuchoMole101010101 to r/devops [link] [comments]

Hey, for people working with AWS/GCP/Azure and FinOps, What do you find most frustrating about managing cloud costs? Is it actually finding where you're wasting money, or is it more about getting people to do something about the recommendations? For example, if your tools tell you that you could save $10k/month by changing some infrastructure, what usually happens after that? Does someone actually fix it, or does it just sit there because of ownership, risk, engineering effort, etc.? Also curious how you deal with SaaS costs alongside cloud costs. Just trying to understand how people actually handle this in practice. submitted by /u/Severe_Lawyer_3076 to r/FinOps [link] [comments]

Hello everyone, I’m looking for advice on which FinOps certification path would be most relevant for my background: FinOps Practitioner or FinOps Engineer. I currently work as a Cloud Architect, primarily in AWS, across well-architected design, security and compliance, and FinOps-related topics. Cost optimization, governance, and cloud efficiency are already part of my day-to-day work, but I’d like to deepen my FinOps knowledge in a more structured way and become more involved in the community. My goal is not only to earn a certification, but also to improve how I collaborate with engineering, finance, and business stakeholders around cloud spend and value. For someone with this profile, would you recommend starting with the Practitioner certification as the common foundation, or going directly toward the Engineer path? I’d also welcome any advice on the most valuable ways to engage with the FinOps community beyond certification. Thanks a lot submitted by /u/AAAmine8 to r/FinOps [link] [comments]

Authored by Stephen Crowley AWS DevOps Agent was built for modern software environments: engineering teams running heterogeneous infrastructure, juggling multiple observability tools, and without enough bandwidth to manually investigate every service incident. Its GA announcement highlighted reductions in mean time to resolution from two hours to thirty minutes — but that kind of improvement only happens when the underlying telemetry data is clean, structured, and fast to query. This is where Bronto comes in. Not as a point integration built specifically for AWS DevOps Agent, but as a telemetry layer designed from the ground up around the principles that make any AI-driven investigation successful: trust in every result, discovery before every query, full context in every response, and consistent behaviour across every dataset. We put this to the test directly. In a side-by-side evaluation, the same system — the OpenTelemetry demo application — sent data simultaneously to Bronto, Elasticsearch/Lucene (via OpenSearch), and Grafana Loki, all exposed via their respective MCP integrations. AWS DevOps Agent ran the same incident investigation against all three, then we asked it to judge. We gave it a deliberately neutral prompt, designed to let the agent reach its own conclusions based on what it had just experienced: Compare Bronto, Elasticsearch/OpenSearch, and Grafana Loki for use by AI agents (like AWS DevOps Agent) performing incident investigation. Focus the comparison on what matters for AI agents, NOT human usability. Include Recommendations for AWS DevOps Agent. Do NOT focus on: Query syntax complexity (AI handles nested JSON fine), Human readability of responses, Nesting depth. The prompt explicitly told the agent to ignore the things Bronto is often praised for by humans — simple query syntax, flat response structure, readable output. We wanted to know what mattered to the agent itself, working from its own experience querying all three systems during a live investigation. Its verdict was unambiguous. For incident investigation, Bronto is the clear winner. The evaluation identified four factors that actually determine whether an AI agent can investigate reliably: Silent failure risk — Does the system fail quietly with wrong results? Data discovery — Can the agent explore before querying? Response completeness — Does one query return enough context? Deterministic behavior — Does the same query always produce the same behavior? System AI Agent Suitability Primary Issue Bronto High (9.4/10) None significant Elasticsearch/Lucene Medium (5.3/10) Silent failures from case/mapping issues Grafana Loki Low (4.6/10) Limited discovery, minimal context 1. Silent Failure Risk The most critical factor for AI agents is not whether they can express a query — it's whether they can trust the result. When a query returns empty results, the agent must decide: is there genuinely no matching data, or did the query fail silently for some other reason? Unlike a human analyst who might notice something feels off and try a different approach, an AI agent treats an empty result as ground truth and continues its investigation on that basis. Elasticsearch/Lucene uses case-sensitive keyword field matching by default. A filter written as { "term": { "service.name": "Checkout" } } returns zero results if the indexed value is checkout — and it does it silently, with no error. The same silent failure applies to wrong field types ( .keyword vs analyzed), fields that exist in the data but weren't mapped at index setup time, and any variation in field naming between indices. The agent concludes "no data" when the reality is "query did not match." Loki has fewer mapping complexities, but labels are case-sensitive and log content grep is case-sensitive by default. An agent querying {service_name="Checkout"} when the label value is checkout gets zero results with no signal that the label exists with a different casing. Bronto returns a clear error for unknown field names. Its ILIKE operator handles any casing — $service.name = 'Checkout' matches checkout , CHECKOUT , and any other variant. When Bronto returns empty results, the agent can treat that as a trustworthy signal that no matching data exists. Failure Type Bronto Elasticsearch/Lucene Loki Wrong case in query value Still works (ILIKE) Silent empty result Silent empty result Wrong case in field name Clear error Silent empty result Silent empty result Field doesn't exist Clear error Silent empty result Silent empty result Wrong field type ( .keyword vs analyzed) N/A (consistent) Silent wrong results N/A Typo in field name Clear error Silent empty result Silent empty result In our evaluation, Elasticsearch/Lucene returned zero events for every error and warning query across cart, payment, and ad services — even though the events existed in the index. An agent relying on those results would have proceeded under the conclusion that no active errors existed, while multiple services were actively failing. Bronto returned all of them. System When Query Returns Empty Agent Concludes Actually Correct? Bronto No matching data exists "No errors found" Likely correct Elasticsearch/Lucene Unknown reason "No errors found" May be wrong Loki Unknown reason "No errors found" May be wrong 2. Data Discovery Can the agent explore what data exists and verify a query will work before it runs it? This determines whether the agent enters an investigation with confidence or proceeds on assumptions that may silently be wrong. Bronto treats discovery as a first-class workflow — and critically, it works across all data in Bronto, not just OpenTelemetry. The agent calls get_datasets() to get a named catalogue of every dataset. It calls get_keys(log_id="checkout") to list all searchable fields. It calls get_key_values(log_id="checkout", key="$severity_text") to enumerate the actual values present — ["INFO", "ERROR", "WARN"] . By the time the agent issues its first search query, it knows the field exists, knows what values are in it, and can form that query with confidence. Elasticsearch/Lucene's discovery path is complex and unreliable. GET _cat/indices returns a raw index list. GET logs-checkout-*/_mapping returns hundreds of lines of nested JSON that describe field types but not values. To discover what values actually exist in a field, the agent must run a separate aggregation query — and must already know whether the field is .keyword or analyzed to construct it correctly. Loki's discovery is limited to labels. list_loki_label_names() typically returns three or four labels: pod , service_name , stream . There is no way to discover the fields inside log content. Capability Bronto Elasticsearch/Lucene Loki List available datasets get_datasets (all sources) _cat/indices (raw list) Via labels only List searchable fields get_keys (simple list) _mapping (complex nested JSON) Labels only (3–5 fields) List field values get_key_values Terms aggregation query Label values only Verify field exists before query Easy, explicit Must parse mapping Cannot for log content Works across non-OTEL data sources Yes Varies by index config Not applicable Zero-knowledge start Yes No No 3. Response Completeness Does a single query return enough context for the agent to understand what happened, identify impact, and decide what to investigate next? Bronto returns row-based dense JSON where every event is a self-describing object. A single error event reliably includes service name, service version, pod name, node name, namespace, trace ID, and user ID: { "@raw" : "exporter export timeout: rpc error: code = Unavailable" , "@time" : "2026-05-04 11:36:56.845 UTC" , "@status" : "error" , "attributes" : { "$service.name" : "checkout" , "$service.version" : "2.2.0" , "$k8s.pod.name" : "checkout-f86478f-xgclj" , "$k8s.node.name" : "ip-192-168-46-190.ec2.internal" , "$trace_id" : "367379916186c4759c7c226a0350408f" , "$user_id" : "dea7494c-4867-11f1-ab4e-6edbf8c21e43" } } In our live test, Bronto found 15 real error events in 3 queries, with root cause visible immediately: high memory usage causing exporter timeouts. Trace IDs were present on every event, allowing the agent to pivot to trace correlation without an additional query. Elasticsearch/Lucene's response completeness depends entirely on what was mapped when the index was created. The response also wraps every hit in metadata ( _index , _id , _score , _shards ) that the agent must parse past before reaching the actual log data. Loki returned zero application errors in the same test — only synthetic canary logs. Where it does return results, all structured context is embedded inside the raw log line string. Context Needed Bronto Elasticsearch/Lucene Loki Error message @raw field message field Log line Service name $service.name If mapped If label exists Service version $service.version If mapped Rarely available Pod / node name Indexed If mapped Rarely available Trace ID $trace_id If mapped Must parse log line User ID $user_id If mapped Must parse log line Timestamp Human-readable ISO format Nanoseconds Investigation Task Bronto Elasticsearch/Lucene Loki Find error + full context 1 query 1–3 queries 3–5+ queries Correlate with trace 0 additional (trace_id included) 0–1 additional 2+ additional Identify user impact 0 additional (user_id included) 0–1 additional 2+ additional Find related logs by trace 1 query 1 query 5+ queries (per service) 4. Deterministic Behavior Does the agent's investigative workflow work consistently across different services and datasets, or must it learn a different approach for each index it encounters? What is consistent in Bronto is the workflow the agent uses to deal with variation. Discovery is the deterministic part: get_datasets() always returns the catalogue, get_keys(log_id) always returns the actual fields present in that dataset, and get_key_values(log_id, key) always returns the actual values. That same three-call pattern works identically for an OTEL dataset, a syslog dataset, or a custom JSON ingest: # OTEL service get_keys("checkout") → [$service.name, $severity_text, $trace_id, ...] search: "$severity_text ILIKE 'error'" # Custom JSON ingest with a different schema get_keys("legacy-app") → [app_name, log_level, request_id, ...] search: "log_level ILIKE 'error'" # Syslog get_keys("network-devices") → [host, facility, severity, message, ...] search: "severity ILIKE 'err' OR severity ILIKE 'crit'" The fields differ but the workflow does not — so the agent never has to guess. Elasticsearch/Lucene cannot make this guarantee. There is no enforced standard for field naming — one index might store service name as service.name.keyword , another as serviceName (analyzed), another as svc . Two indices with the same conceptual data can require materially different agent logic. Aspect Bronto Elasticsearch/Lucene Loki Discovery workflow Same 3 calls for any dataset _mapping shape varies Labels-only Field types Consistent within a dataset Varies by mapping N/A Query behavior Predictable Depends on analyzers Depends on labels Cross-dataset patterns Discover then query — works for any source Per-index logic likely needed Per-stream logic likely needed What Each Platform Was Built For Each of these platforms reflects the use case it was designed for — and none of them, except Bronto, were designed with AI agents in mind. Elasticsearch/Lucene was built around a human at a dashboard. The Query DSL is JSON because it was meant to be assembled by Kibana on behalf of an analyst clicking through visualisations. Hand the same API to an agent, and the assumptions invert: silent case-sensitivity, mapping-dependent matching, and relevance ranking that buries rare events become failure modes. Grafana Loki was built around a single bet on cost — index only labels, store everything else as opaque log lines, charge less than indexed alternatives. The same minimalism that keeps Loki cheap keeps it opaque to an agent that needs to discover fields, correlate by trace ID, or filter on high-cardinality attributes. The cost argument has weakened independently: Loki Cloud lists $0.50/GB ingested versus Bronto's $0.10/GB. Bronto was built for AI agent investigation from the ground up. Discovery as a first-class workflow, case-insensitive matching by default, dense self-describing JSON responses, deterministic discovery patterns across heterogeneous data sources. Factor Weight Bronto Elasticsearch/Lucene Loki Silent failure risk 30% 9/10 4/10 5/10 Data discovery 25% 10/10 5/10 4/10 Response completeness 20% 10/10 7/10 3/10 Deterministic behavior 15% 9/10 5/10 5/10 Query simplicity 10% 9/10 6/10 7/10 Weighted total 9.4/10 5.3/10 4.6/10 Connecting Bronto to AWS DevOps Agent is straightforward: deploy Bronto's hosted MCP server, route your telemetry to it, and authorise the agent. Both are built on the same open standards, so it works the first time, with no custom skills or pre-configuration. See It in Action We recorded AWS DevOps Agent running a live incident investigation against Bronto — no pre-configuration, no custom skills, just the hosted MCP server connected and pointed at the OpenTelemetry demo. The investigation completed in under a minute. Once started, the agent generated its investigation plan within eight seconds. Within sixty seconds, it had queried Bronto, identified that the ad service was experiencing a high error rate, followed the statement IDs to the specific log lines causing failures, and surfaced the symptom: ads were failing to load. After further analysis — scanning the full codebase and correlating what Bronto's logs revealed — the agent returned its root cause: the adFailure feature flag was controlled entirely by an external flagd service. From alert to root cause, with the data layer doing exactly what it was designed to do. Set Up AWS DevOps Agent with Bronto

Suppose, i have a VM with a boot disk with data, 1 additional disk with some files.Once the zone or region goes down for some hours and becomes available after it,will the GCE contents be same as before the outage ? This is not about MIGs, backup and DR services etc.. just would like to know if the compute engine data in disks and IP address be retained once the zone/region is back after the outage. Please clarify if anyone experienced it submitted by /u/suryad123 to r/googlecloud [link] [comments]

I'm u/teamcloudkeeper . FinOps for AI is about to matter for basically everyone, not just teams running massive training clusters. If you're running any AI workload in production, token pricing, GPU costs, and bursty-vs-continuous usage patterns are already there whether you've built practices around them or not. Every org, big or small, is gonna need this in place sooner than later. We've built our FinOps for AI capability around this, augmented by Lens and Tuner . But it's the human behind the tools making the calls on ownership and tradeoffs. That doesn't get automated away. You've gotta start too. Always open if you want to know more about us cloudkeeper.com . submitted by /u/teamcloudkeeper to r/FinOps [link] [comments]

Hi all, Quick reality check needed. I’m transitioning from a Finance/Business background (French Grande École + US exchange) into an MSIS program in the US (Spring 2027) . My target is landing a FinOps Analyst, Cloud Business Consultant, or IT Data Analyst role and i heard that the personnal skills take are the advantages to get hired in the US market and not the degree so i m trying to improve myself. My Cert Strategy: AWS Cloud Practitioner (CCP) & FinOps Certified Practitioner (FOCP) (Before MSIS) AWS Solutions Architect Associate (SAA) & Power BI/SQL (During 1st MSIS semester) My Questions: Does combining a Finance background + MSIS + FOCP + AWS SAA give me a real competitive edge over pure CS or MBA grads for entry/early-career FinOps roles? Is FOCP respected by hiring managers when paired with AWS SAA for someone breaking into the field? Any key tips to position this profile effectively for internships/OPT? Appreciate any honest feedback! submitted by /u/Zestyclose-Brick5463 to r/FinOps [link] [comments]

We are getting a large number of customers unable to access Google Drive in the APAC region this afternoon, anyone else see anything? Nothing on their status page yet, but down detector is lighting up. https://downdetector.co.nz/status/google-drive/ submitted by /u/Hibernat8 to r/sysadmin [link] [comments]

Hi, We’ve been running Veritas NetBackup in an on-prem setup for a few years, but the cost of licensing + infrastructure is getting harder to justify, so we’re now re-evaluating our backup approach. The main focus is VMware workloads, and we’re trying to understand what actually makes sense today in terms of cost and long-term scalability. For a simplified reference point, here’s a smaller scenario we’re using for modeling: We have 10 VMs (~200GB each). Retention is split, 5 VMs kept for 1 year and the other 5 kept for 30 days. That puts us at roughly 2TB initial backup size, with a small daily change rate (~0.1%). From there, we’re trying to understand how costs scale when you factor in: long-term retention tiers snapshot / backup storage growth data transfer / egress (if applicable) licensing vs managed service pricing What we’re trying to compare is basically: AWS-native approach (AWS Backup / EBS snapshots / S3 lifecycle tiers) Veeam or similar third-party backup tools Legacy enterprise setups like NetBackup / Veritas The part that’s still unclear for us is where the real cost differences actually show up in practice. On paper, AWS-native looks simpler, but I’m not sure if it holds up once you scale retention and restore requirements. On the other hand, tools like Veeam add flexibility, but it’s not obvious if they reduce cost or just shift it into a different layer. Before taking anything to management, I’m trying to get a clearer view of what actually drives cost in real deployments (storage growth, retention policies, licensing, operational overhead, etc.) and whether third-party tools genuinely justify their complexity. Would appreciate any real-world input from anyone who’s done a similar migration or comparison. submitted by /u/Immediate-Screen7893 to r/sysadmin [link] [comments]

A lot of companies rely on FinOps teams or cloud optimization partners to manage their AWS spend. But I’m curious, are there certain cost leakages that are so obvious that anyone managing an AWS environment should be able to spot them? Looking to hear some practical, real-world examples from the community. submitted by /u/whispered_word12 to r/FinOps [link] [comments]

submitted by /u/Morningstar_1 to r/FinOps [link] [comments]

This is something I've been trying to wrap my head around. If the cloud bill goes down, that's obviously good, right? But what if usage also went down? And if the bill goes up but we're serving twice as much traffic, maybe that's actually an improvement. What do you use to measure cloud efficiency beyond the total bill? submitted by /u/whispered_word12 to r/FinOps [link] [comments]

Our Spark line item on AWS keeps growing faster than our data does and it has become a recurring line in budget reviews. We have done spot instances, auto-termination, right-sizing, the standard checklist. Gains show up, then flatten out fast. Looking for what has worked beyond that basic set, esp for teams running tens of TBs a day. Trying to figure out if the next real gain comes from infrastructure changes rather than squeezing the same clusters harder. submitted by /u/Fantastic_Jello1629 to r/FinOps [link] [comments]

For companies using OpenAI, Anthropic and other AI tools heavily, costs can grow fast — and the monthly bill can be hard to predict. I’m trying to understand how painful this is in practice. For founders, CFOs and finance teams: Is AI spend becoming a meaningful line item? Are unpredictable bills making budgeting harder? Would committing annually for a discount create a cash-flow problem? I’m exploring a model to solve this, but before building anything I want to understand whether the problem is actually painful enough. Would love to hear how you’re managing AI spend today. submitted by /u/krxnewman to r/FinOps [link] [comments]

Real pricing pulled from AWS, no credentials or account needed to preview One command, full cost tree: total monthly cost, per-resource breakdown, and which resource is actually driving the bill (RDS Multi-AZ was 56% of it here). Feels like the kind of check that should just be part of a normal plan/apply workflow. Happy to answer questions on how it resolves the plan or what it does with CloudFormation/Pulumi if anyone's curious. submitted by /u/Independent-Ease-609 to r/FinOps [link] [comments]

got the bill yesterday. another surprise. we migrated our phone system to Azure 3 months ago. I did the math. I calculated everything. compute, storage, network, the works. or so I thought. turns out I completely missed the cost of monitoring logs. application insights. I didn't even think about it. and now it's like 15% of our monthly bill. 15%. for logs I barely even look at. I'm starting to understand why people complain about cloud pricing. it's not that it's expensive it's that it's impossible to predict every month there's something new. I've started using the cost management tools more. trying to be better about tagging resources and setting budgets. but I still feel like I'm one wrong configuration away from a 5000 surprise. anyone else feel like Azure pricing is designed to confuse you. or am I just bad at math submitted by /u/dnickell to r/AZURE [link] [comments]