CommPulse

This article explains how to build and test a cross-cloud currency agent. An Amazon Bedrock master agent , built with Strands Agents and hosted on Amazon Bedrock AgentCore Runtime in AWS us-east-1 , delegates to a Google ADK worker on GCP Cloud Run in us-central1 over A2A v1.0 . The master cross-checks the worker against an MCP exchange-rate tool and measures the latency, reliability, and failure behavior of cross-cloud verification. What is this project trying to do? Most Agent-to-Agent (A2A) protocol demos stop at "look, the HTTP 200 OK request succeeded." That is a smoke test, not an interoperability benchmark. This project goes further: the Bedrock master owns the user interaction and benchmark policy. It discovers and calls a Google ADK worker running on GCP Cloud Run, then compares the worker result with a local MCP stdio exchange-rate tool backed by live Frankfurter daily reference rates. We also compare the performance, developer experience, and wire compatibility with a previous benchmark run using Microsoft Foundry in Azure ( gpt-5-mini ). Together, the runs cover components hosted across AWS, Azure, and GCP. The benchmark addresses four questions: Can an AgentCore-hosted Bedrock master discover and invoke a Google ADK worker through an A2A agent card with no framework-specific glue? What latency and token overhead does remote-agent verification add? Does independently verifying an MCP tool result over A2A improve correctness or failure recovery enough to justify that overhead? Which measurements are portable across coordinators, and which require a fully hosted AgentCore benchmark run? Reusing the original currency agent This builds directly on the currency agent from the previous articles in this series: Getting Started with MCP, ADK and A2A | Google Codelabs GitHub - jackwotherspoon/currency-agent That agent — built with Google ADK, Gemini 2.5 Flash, and a FastMCP exchange-rate server backed by the free Frankfurter API — serves as the remote worker and independent verifier in this project. The new repository adds the AgentCore coordinator and benchmark suite: GitHub - xbill9/bedrock-adk-a2a-currency Architecture CLI / Boto3 Test Runner (AWS SigV4 Auth) | Bedrock AgentCore Runtime hosted master (AWS, us-east-1, Amazon Nova Micro) Strands Agents orchestration | +-- MCP stdio --> Frankfurter rates (in-container stdio process) | +-- A2A v1.0 --> Cloud Run (GCP, us-central1) | Google ADK worker (gemini-2.5-flash) | MCP HTTP --> Frankfurter rates The Bedrock master answers every conversion request through three distinct evaluation modes: Mode What happens Why it exists mcp_only Bedrock master calls the local MCP rate tool Baseline single-agent performance a2a_only Bedrock master delegates to the GCP ADK worker over A2A v1.0 Measure remote-agent behavior and network latency verified MCP result independently checked against the remote ADK agent over A2A Measure the accuracy-versus-overhead tradeoff Both sides read the same Frankfurter daily reference rates on purpose: when the two clouds disagree, that measures protocol, model, and orchestration behavior, not data-source skew. Rule one: the model never does math Currency conversion is a poor job for an LLM and a good job for Python's Decimal . The domain layer is framework-independent and uses Pydantic models. Numeric agreement is evaluated in code using relative difference; no LLM is asked, "Do these numbers look close to you?" difference = abs ( primary . converted_amount - verifier . converted_amount ) relative = difference / abs ( primary . converted_amount ) agreed = relative <= tolerance # default 0.005 (0.5%) The failure policy is explicit rather than emergent: MCP fails, A2A succeeds → return the remote result, labeled unverified . A2A fails, MCP succeeds → return the tool result with a "verification unavailable" warning. Both succeed but disagree → return both quotes and issue a warning; never silently pick the LLM's preferred rate. Both fail → return a strongly typed failure ( validation , provider , authentication , transport , timeout , protocol ); never fabricate a rate. Because "which layer broke" is a core research question, every adapter exception is normalized into exactly one typed failure at the boundary. The wire mismatch: A2A v0.3.0 vs. v1.0 The first attempt to connect the AgentCore coordinator to the Google ADK currency agent died immediately on invocation: a2a.utils.errors.MethodNotFoundError: Method not found Observed root cause: a protocol-version mismatch between A2A v0.3.0 and v1.0, with no automatic fallback negotiation in the tested client. The modern A2A client ( a2a-sdk>=1.0 ) calls the A2A v1.0 JSON-RPC method SendMessage . Older ADK agents ( a2a-sdk 0.3.x ) only expose the v0.3.0 method message/send . The client fetched the agent card — which explicitly declared protocolVersion: 0.3.0 — but attempted the v1.0 method anyway. The initial ecosystem package pins were also mutually exclusive: Package a2a-sdk Requirement Status strands-agents 1.50.2 >=1.0.0,<2 Compatible google-adk 2.1.0 – 2.4.0 >=0.3.4,<0.4 Incompatible google-adk 2.5.0 >=0.3.4,<2 Compatible ✅ a2ui-agent-sdk (through 0.4.0) <0.4.0 Incompatible ❌ google-adk 2.5.0 updated its dependencies to support a2a-sdk 1.x . However, A2UI extensions currently pin the older v0.3.0 protocol. For this benchmark, A2UI was omitted so both AWS and GCP sides could operate on A2A v1.0 ( a2a-sdk 1.1.2 ) . Hosting the Bedrock master on Amazon Bedrock AgentCore Deploying the master to Amazon Bedrock AgentCore Runtime involved navigating several fast-moving SDK and platform details observed during our build on 2026-07-28: 1. Model selection: Anthropic access requirements vs. Amazon Nova Micro In the account used for this build, Anthropic models such as Claude 3.5 Sonnet required a one-time use-case submission ( PutUseCaseForModelAccess ) and an AWS Marketplace subscription agreement. To keep the setup automated, we configured the coordinator to use Amazon Nova Micro ( us.amazon.nova-micro-v1:0 ). Nova Micro required no approval form in our test account, supported native tool calling in the tested workflow, and produced subsecond model responses. 2. Inference profile IDs In our deployment, using the bare model ID ( amazon.nova-micro-v1:0 ) returned an HTTP 400 ValidationException requiring on-demand throughput configuration. Passing the regional inference profile ID ( us.amazon.nova-micro-v1:0 ) resolved the error. 3. CLI tooling transition The older Python pip -based starter toolkit ( agentcore configure / agentcore launch ) was deprecated in June 2026. Deployment now uses the official @aws/agentcore npm CLI (Node 20+, CDK-based). Coordinator entry point (abridged from app/CurrencyCoordinator/main.py ) from bedrock_agentcore.runtime import BedrockAgentCoreApp from strands import Agent , tool from coordinator.hosted_tool import run_currency_benchmark from model.load import load_model app = BedrockAgentCoreApp () tools = [ tool ( run_currency_benchmark )] # The full source defines a bounded, session-scoped agent factory here. @app.entrypoint async def invoke ( payload , context ): session_id = getattr ( context , " session_id " , " default-session " ) agent = get_or_create_agent ( session_id ) prompt = payload . get ( " prompt " , payload . get ( " messages " , "" )) result = await agent . invoke_async ( prompt ) return { " result " : str ( result )} if __name__ == " __main__ " : app . run () The hosted runtime also fails closed when its GCP worker is missing: { "name" : "CURRENCY_REQUIRE_GCP_ADK" , "value" : "1" } With that setting, a2a_only and verified return gcp_adk_not_configured if CURRENCY_A2A_ENDPOINT is absent. A deployment can no longer appear to exercise A2A while silently using a local fixture. The Bedrock model configuration also sets BEDROCK_MAX_TOKENS=1024 explicitly to bound output and quota usage. The Google side: ADK on Cloud Run The remote verifier container colocates two processes: the FastMCP Frankfurter server on localhost and the A2A app listening on $PORT . Gemini API keys are retrieved securely from GCP Secret Manager: gcloud secrets create gemini-api-key --data-file = " $HOME /gemini.key" gcloud run deploy currency-adk-a2a \ --source adk_agent --region us-central1 \ --allow-unauthenticated --min-instances = 0 --max-instances = 2 \ --set-secrets "GOOGLE_API_KEY=gemini-api-key:latest" \ --set-env-vars "MCP_SERVER_URL=http://127.0.0.1:8081/mcp,GENAI_MODEL=gemini-2.5-flash" Setting --min-instances=0 allows Cloud Run to scale to zero when idle. The coordinator's timeout is set to 60 seconds to accommodate initial container cold starts. How to run the benchmark The repository includes a complete local test suite that runs deterministically without credentials or cloud infrastructure: # 1. Clone & install dependencies git clone https://github.com/xbill9/bedrock-adk-a2a-currency cd bedrock-adk-a2a-currency pip3 install --user -e ".[dev]" # 2. Run unit and integration tests (deterministic fixtures) pytest # 3. Test local CLI modes currency-benchmark 100 USD CAD EUR --mode mcp_only currency-benchmark 100 USD CAD EUR --mode verified --transport mcp-stdio # 4. Execute full evaluation matrix currency-evaluate --output /tmp/currency-results.jsonl --summary /tmp/currency-summary.json To deploy and test the hosted Bedrock master: ./infra/sync_app.sh agentcore deploy -y agentcore invoke "Convert 100 USD to EUR and CHF in verified mode." Hosted smoke test: Bedrock master → GCP ADK worker On 2026-07-29, I deployed the updated master to AgentCore Runtime in us-east-1 and invoked all three modes through the hosted InvokeAgentRuntime API: Hosted mode Observed result mcp_only HTTP 200; live mcp-stdio:frankfurter-live quote a2a_only HTTP 200; live gcp-adk-a2a-worker quote verified HTTP 200; MCP and GCP ADK agreed exactly for EUR and CHF The verified request converted 100 USD to EUR and CHF. The deterministic comparison recorded relative_difference: "0" and agreed: true for both currencies, with no failures or warnings. The benchmark tool completed in approximately 3.08 seconds. This was an end-to-end smoke test, not a full hosted latency distribution. It exercised the complete path: AWS SigV4 invocation → AgentCore Runtime → Nova Micro tool selection → MCP stdio / Frankfurter → A2A v1.0 → GCP Cloud Run → Google ADK / Gemini → deterministic Decimal comparison The smoke test also found a real orchestration bug. On the first request, Nova Micro read “Convert 100 USD to EUR” but claimed the target currency was missing and asked the user to confirm it. The master prompt now includes an explicit natural-language parsing rule and forbids confirmation requests for information already present. After redeployment, the same request called the benchmark tool directly. A regression test preserves that behavior. Cross-cloud benchmark results We executed the 38-case evaluation matrix across all three modes: 114 records per run. The 2026-07-28 warm run exercised the framework-independent coordinator locally against the live GCP Cloud Run ADK endpoint; it did not measure the AgentCore hosting layer. The 2026-07-27 run is the retained Azure-era baseline. Keeping those labels explicit avoids attributing local harness latency to AgentCore. Observed run Evaluation mode Success rate Median latency p95 latency Agreement rate 2026-07-28 warm local harness → GCP mcp_only 100% 286 ms 540 ms N/A 2026-07-28 warm local harness → GCP a2a_only 100% 2.09 s 6.10 s N/A 2026-07-28 warm local harness → GCP verified 100% 1.87 s 4.33 s 96.77% 2026-07-27 Azure-era baseline → GCP mcp_only 100% 297 ms 1.09 s N/A 2026-07-27 Azure-era baseline → GCP a2a_only 100% 1.69 s 4.82 s N/A 2026-07-27 Azure-era baseline → GCP verified 100% 1.71 s 4.15 s 96.77% Key findings The live protocol path was reliable: the warm 2026-07-28 run completed all 114 records successfully. Fault-injection cases are included in the aggregate, so agreement rate is not expected to be 100%. Concurrent execution limits verification overhead: verified-mode latency is dominated by the remote A2A round trip rather than the sum of MCP and A2A latency. Hosted AWS → GCP interoperability was observed: all three modes completed through AgentCore. The verified EUR and CHF quotes had zero relative difference, no failures, and no warnings. This remains a smoke-test result, not a 114-record hosted latency distribution. Hosted performance remains to be measured: token usage, cost, and repeated warm/cold AgentCore distributions are still open benchmark work. Lessons learned Check A2A SDK major versions first: A2A v0.3.0 ( message/send ) and v1.0 ( SendMessage ) are wire-incompatible. If you see MethodNotFoundError , inspect the a2a-sdk version on both client and server before debugging prompt logic. Use inference profile IDs on Bedrock: In our hosted deployment, the regional inference profile ID ( us.amazon.nova-micro-v1:0 ) avoided the on-demand throughput error returned for the bare model ID. Account for remote cold starts: A 10-second client timeout worked locally, but the Cloud Run scale-from-zero path needed a longer window. We used 60 seconds for this benchmark. Keep math out of the prompt: Deterministic Python Decimal arithmetic prevents LLM calculation errors from affecting conversion and agreement checks. The checks therefore measure differences in returned results, not the model's arithmetic ability. A2A verification provides independent fault detection: The faster mcp_only path is useful as a baseline, while cross-cloud A2A verification adds an independent result for failover and anomaly detection. Whether the overhead is justified depends on the workload. Test natural-language argument extraction: Tool availability is not enough. The master model can still fail before invocation by misreading an argument that is plainly present. Keep a hosted smoke case for natural-language parsing, not only structured tool calls. Repository and source code The complete benchmark codebase, deployment scripts, test suite, and raw evaluation datasets are available on GitHub: GitHub - xbill9/bedrock-adk-a2a-currency If you are building multi-cloud agent systems with Amazon Bedrock AgentCore, Google ADK, or Microsoft Agent Framework, feedback and benchmark contributions are welcome.

Pulled our numbers for the renewal and the AI and GPU line is about 4x last year, but our cost tool drops nearly all of it into one 'other' row I can't split by team or even by service. Good on EC2 and RDS, useless on the part that's growing fastest. PointFive is the name three separate people pointed me to for this, mainly because it doesn't treat the AI and GPU spend as a footnote. Sat through the demo, looked good, they always do. The one thing a demo can't answer, when it flags waste is it stuff my current tool already nags me about or does it surface things we didn't know were running. If someone's live on it and it found waste their old tool was blind to, that's the only reason I'd rip out a renewal to switch. submitted by /u/Flateland-Chio to r/FinOps [link] [comments]

I am new to FinOps, i wanted to ask people who have experience in the FinOps space. Is there any financial modelling or specifically business case modelling done in FinOps? E.g. if there is any optimisation opportunity or a new workload, is this a requirement from a CFO or board that they need to see a detailed financial model to show ROI and justify the spend? Reason I am asking is because I come from a core finance background just wanted to see if there is an overlap of my finance experience. submitted by /u/Appropriate_Class572 to r/FinOps [link] [comments]

Is anyone else seeing these issues. Just got a call from Help Desk to check it out. Sharepoint home pages are accessible but no files are. Down detector shows a spike but only 128 reports so far. Central/East US region. submitted by /u/AncientVase to r/sysadmin [link] [comments]

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

Disclosure: I work with Haevek, a data compute platform. This isn't a pitch and there's nothing to sign up for. Flagging it because this sub asks you to declare. We're putting together a community content series where we interview people who build and run modern data and AI infrastructure. No product talk, no script, no gated landing page. Conversations that get published for whoever finds them useful and nothing gets published without your review. Our view, which you're welcome to tear apart: the bill isn't the software, it's the infrastructure to run it. Open source compute is free to license, but the clusters stay on and consumption pricing climbs with every workload, so cost grows faster than the value coming back. We think the fix is a more efficient engine, not a bigger budget. Plenty of people disagree, which is usually the more interesting conversation. Topics people have picked so far: Where data and AI compute cost actually goes, and why the bill keeps growing as teams do more Scaling AI and agent workloads, where the limit is the cost of running inference over and over rather than the model or the talent What teams get wrong about controlling data and AI cost? Who I'm hoping to talk to: Director or Head of FinOps, Head of Cloud Cost / Cloud Economics VP or Head of Data Platform / Data Engineering who's had the cost conversation forced on them anyone who's actually cut a big data or AI compute line item and can explain what they did Company-wise, anywhere the bill is big enough to be political. Enterprise, scale-up, public sector, doesn't matter. 30 minutes, remote, you get the recording and can cut clips from it. If that's you, or you know someone, DM me. submitted by /u/Sad-Fishing-7666 to r/FinOps [link] [comments]

Hi everyone, I would like to hear how experienced DevOps engineers approach monitoring for large public-facing applications. We have a .NET e-commerce platform with: - ASP.NET Core MVC + Angular - SQL Server - Elasticsearch (~10M products) - RabbitMQ - IIS hosting - Multiple public domains/subdomains - Heavy SEO crawling and unknown bots One thing we learned is that monitoring only CPU, memory, and disk is not enough. We have experienced situations where: - CPU and RAM looked normal, but the application was slow - The server was reachable, but users experienced downtime - TCP exhaustion caused issues - Elasticsearch had problems affecting search performance - Bots generated a lot of unnecessary traffic - Slow requests were not obvious from infrastructure metrics I would like to know what metrics and alerts you consider essential for this type of system. Some things I think are important: Application level: - Request rate (RPS) - Response time (p50/p95/p99) - HTTP status codes (4xx/5xx) - Slow endpoints - Exception rate - Thread pool starvation - GC pauses - .NET runtime counters - Memory allocations IIS / Web server: - Current connections - Request queue length - Worker process health - Application pool recycling - Failed requests - Connection errors Network: - TCP connections - TIME_WAIT count - Connection failures - Bandwidth usage - Top clients/IPs - Suspicious user agents Elasticsearch: - Cluster health - JVM memory pressure - Heap usage - Search latency - Query failures - Slow queries - Unassigned shards - Disk usage SQL Server: - CPU - Blocking queries - Deadlocks - Query duration - Connection pool usage - Wait statistics RabbitMQ: - Queue length - Consumer count - Message processing time - Dead letters - Memory usage Security / traffic: - Requests to suspicious paths: - /.env - /.git - wp-admin - Bot traffic percentage - High-frequency clients - Rate limit violations My question: If you were responsible for operating a public .NET application like this, what dashboards and alerts would you consider mandatory? Also, what are some metrics you discovered were extremely valuable only after a production incident? I am especially interested in real-world experience rather than a theoretical checklist. Thanks! submitted by /u/No-Card-2312 to r/devops [link] [comments]

New feature I shipped: --optimize takes the FinOps recommendations CloudCostTree already shows you and applies the ones that are safe to apply mechanically, no architecture or availability trade-off involved. What gets auto-applied: gp2 to gp3 (EBS and RDS storage), provisioned IOPS to gp3 where it's not needed, previous-generation instance types to current-gen, RDS backup retention capped at 30 days, DynamoDB provisioned to on-demand, non-production resources rescheduled to business hours. On Pro with --with-usage, also confirmed orphaned EBS volumes and snapshots, empty target-group load balancers, and unassociated Elastic IPs. What it will never auto-apply: x86 to Graviton (changes CPU architecture), removing Multi-AZ (changes your failover story), CPU or memory based right-sizing from real usage data (measured but still inferred). Those stay as suggestions you confirm yourself. Screenshots show the flow in the VS Code extension against a small test file: the two safe recommendations it found (save $7.01/mo switching off a previous-gen instance, $4.00/mo off a gp2 volume), picking which to apply, and the result, total down from $87.97 to $76.97/mo and the Cost Score up from B to 88. Free tier, and the same thing works from the CLI with cloudcosttree analyze --optimize. https://cloudcosttree.com submitted by /u/Independent-Ease-609 to r/FinOps [link] [comments]

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

We run a SaaS company in Brazil. Our entire production stack sits in AWS account 393686273302: EKS, RDS, ElastiCache, SES, S3. Application code, customer data, payment records. We think a card change triggered the flag. When we opened the account, the agency that builds our platform (Specter) registered one of their corporate cards so they could provision infrastructure while we set up our own payment method. When the first invoice came due, we replaced that card with our company card and paid the invoice in full. AWS restricted the account after that payment cleared. Our billing console shows R$ 0.00 outstanding today. No open invoice. The suspension notice says non-payment. We have fought verification flags on this account since July: - AWS denied two EC2 vCPU quota increases (L-1216C47A on-demand, L-34B43A08 spot), then granted them after we appealed. - AWS denied SES production access in case 178458595700478, then granted it after we appealed. - CloudFront returned 403 "verification required" and the flag never cleared. - On August 10, RunInstances began returning "This account is currently blocked and not recognized as a valid account". CreateFleet returned MaxFleetCountExceeded while we ran zero fleets. Our Spot quota read 0. Our MediaConvert queue flipped to PAUSED and UpdateQueue returned Forbidden. We opened case 178638951500949 on August 10 and wrote in it that our launch was the next day. We opened a second case; AWS closed it as a duplicate and pointed us back to the first. Nobody from the verification team wrote to us. On August 11st, AWS suspended the account. AWS Health reports our EKS cluster kloel-eks-prod as IMPAIRED: "We couldn't assume the Amazon EKS cluster management service-linked-role" and "We couldn't find or access the AWS KMS key associated with your cluster", with a warning that the control plane shuts down in two days. The NLB in front of our API stopped accepting connections, so api.kloel.com and checkout-api.kloel.com time out from every network we tested. IAM keys that worked before the suspension now return InvalidClientTokenId, so we cannot read our own resources or export a backup. We processed real customer payments hours before the suspension, card and PIX. Those customers now hit a dead platform. We opened case 178647610300640 and uploaded every document AWS requested through their verification link the same day. Nobody has answered us since. Support answered that case with this: > "As this particular inquiry is handled by one of our program support teams, I've forwarded your case directly to them. A member of this team will be in touch with you soon. Our program support team can only communicate through email." We received the same sentence on the earlier case, and nobody contacted us after it. We scheduled our launch for August 11. It did not happen. We are fielding questions from investors and partners about why the product we demoed to them is unreachable. Every minute our platform remains unreachable, the pressure over our company and workers grow, if this goes any further the damage can be inestimable. Two questions for anyone who has been through this: Is there a way to reach a human who can review a payment and reinstate an account? Support forwards our cases and nobody answers. How do we get written confirmation from AWS that our RDS database, EBS volumes and snapshots stay intact while the review runs? We paid the invoice, replaced the card, sent the documents and opened the cases. If anyone from AWS reads this: account 393686273302, cases 178647610300640, 178638951500949 and 178458595700478 have the full history, and we will send anything else you need by DM. submitted by /u/Pandowso to r/aws [link] [comments]

Before deploy: running the analysis against your IaC files up front shows you the full cost breakdown plus savings recommendations, and applies whatever's safe to apply without a human decision, before anything actually gets provisioned. After deploy: once it's live, re-running the same analysis with real CloudWatch usage data (via your own read-only AWS credentials) refines those recommendations against actual utilization instead of static config assumptions. The reason this matters for FinOps specifically: static config tells you what something was provisioned for, not what it's costing you in practice. A right-sizing call made purely from declared instance types will miss real idle capacity, and one made purely from live usage misses waste that never should've been provisioned in the first place. Catching both requires checking at both points in the lifecycle, not just once. (Built this into CloudCostTree, a CLI I've been working on, happy to go into specifics if useful.) submitted by /u/Independent-Ease-609 to r/FinOps [link] [comments]

Our CFO caught me after standup and asked a totally fair question, how much is each team spending on all this AI stuff. I said I'd have a number by Friday. Took me until the following Wednesday to admit I couldn't. I'd assumed it would be like AWS where I can slice spend by team in a few clicks, atleast we tagged everything. Then opened the billing expecting the some breakdown but it's just a big monthly number and a graph that goes up. One team lead keeps insisting their usage is not that substancial which without the numbers i cant prove otherwise. We'd handed his squad a shared API key so their spend was all piled onto one. Now, even if I nailed the attribution, most of an agent's bill is the framework re-sending its whole setup every turn, not anything the dev ever typed. I'd be walking into a room to bill someone for tokens they never wrote and can't even see. There's a paper going round with the numbers, arxiv 2607.12161. Anyway. I still owe her that spreadsheet. submitted by /u/Dalius-Gabryelle to r/FinOps [link] [comments]

Doing some research around cloud and AI/token commitment economics and helping NGEN gather feedback on the model. Curious to get the FinOps community’s perspective. The idea is to aggregate compute/token demand across companies, negotiate larger commitments with providers, and use prepayment/financing to offer better pricing and more flexibility. A few things I’m curious about: How much additional savings would make this worthwhile — 5%? 10%+? Is commitment flexibility potentially more valuable than additional savings? Does this make more sense for mid-market companies that don’t already have significant negotiating leverage? NGEN is also collecting anonymous, non-binding indications of demand here (takes ~1 min, no commitment/signature): https://www.ngencompute.com/indication Would genuinely love to hear why you think this would or wouldn’t work. submitted by /u/melc10 to r/FinOps [link] [comments]

I’m 22 studying engineering final year. Planning to start out a service business online. I’m looking into providing bookkeeping & FinOps as a service for creative/marketing agencies & eCom businesses Any advise on prerequisites of providing this service from experts in this field could be of help. Thanks, appreciate your time:) submitted by /u/FirstMechanic2151 to r/FinOps [link] [comments]

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

Sat through our annual IR tabletop yesterday. Consultant reads a scenario, we all sit around a table, discuss calmly, agree on a plan, write it down, done. Two hours, nobody's blood pressure moved. I've been on the other side of an actual ransomware incident, and nobody was calm. Legal wasn't reachable at 2am, the exec wanted answers before we had them, and half the "plan" from the last tabletop was irrelevant because reality didn't match the script. If your tabletop feels like a calm meeting and not remotely like the real thing, is it actually testing anything? Or is it just a compliance box that happens to have a meeting attached to it? submitted by /u/VegetableFault5149 to r/sysadmin [link] [comments]

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 . submitted by /u/noasync to r/FinOps [link] [comments]

FOCUS 1.3 solved a real problem: every cloud provider used to bill in its own format, so cross cloud cost comparison meant building custom normalization pipelines just to ask basic questions. Now there’s a common schema. That part is genuinely good. But adoption of the schema is not the same as fixing FinOps. I keep seeing teams roll out FOCUS, get their data normalized, and still can’t answer the question that actually matters to leadership: who owns this cost, and why did it move. The reason is that FOCUS standardizes the shape of usage and cost data. It says nothing about your tagging discipline, your allocation model, or who is accountable when an engineering team spins up something that triples a bill overnight. Those three things are where the actual FinOps work lives, and they’re organizational problems, not schema problems. You can have perfectly FOCUS compliant data and still have zero cost accountability, because accountability comes from tagging governance and process, not from the spec. The teams that get real value from FOCUS are the ones who treat it as the foundation for building an allocation and accountability model, not as the finish line. If your rollout stopped at “we ingest FOCUS data now,” you’ve done the easy 20 percent. I went deep enough on this that I ended up writing a book on it, “Cloud Money,” working through the FOCUS spec at a practitioner level alongside cost allocation strategy and accountability models. Not trying to sell it here, just flagging it in case anyone wants the longer version of this argument. Happy to talk through the tagging governance side in the comments if people have specific setups they’re stuck on. submitted by /u/aliihashmiii to r/FinOps [link] [comments]

I am working on Azure Data Explorer to optimise its cost usage for my clients, currently I am suggesting downsizing the engine instance SKU type based on the following metrics : CPU utilization < 45% Cache utilization factor < 55% IngestionUtilization and StreamingIngestUtilization < 45% If these holds downsize to the very next lower sku type. But the blocker i am having is that , there's this limit of 50% ram/node for a query , so this will break and cause my queries to fail , is this for real or only latency will increase. Can anyone help me out with that. submitted by /u/sirius_black19 to r/AZURE [link] [comments]

I've been building Cognocient for a few months now, a proxy that sits between your app and OpenAI/Anthropic/Gemini and tells you what each feature actually costs, before the call goes out instead of after you get the bill. For a while the only way in was a 10 day trial with full access, then you had to pick a paid plan. That made sense for teams evaluating it for real budgets. It made no sense for someone who just wants to drop it into a side project and see what their AI calls actually cost. So I added a free tier that doesn't expire. What's in it: one provider connection, the real time proxy and attribution dashboard by feature and model, one budget with alert level enforcement, 7 day retention. Capped at $50/mo of tracked spend, after that the proxy keeps forwarding your calls (I will not break your app over a free tier limit) but stops logging new attribution until the next cycle. Setup is one line, you swap your base\_url for the Cognocient proxy URL and nothing else in your code changes. If you're already tracking spend some other way I'd genuinely like to know what you're using, half the reason I built this is I couldn't find anything that did pre-call enforcement instead of after the fact dashboards. [cognocient.com]( http://cognocient.com ) if you want to poke at it. submitted by /u/MaverikSh to r/FinOps [link] [comments]