CommPulse

I did something this week that sounds like a mistake and was actually the most useful thing I have learned in months. I locked myself out of my own server. On purpose. A server that was running fine, serving a live website, with no way back in. No SSH, no password, and no keyboard to plug in, because it lives in an Amazon data centre I will never enter. Then I recovered it. And now I understand something most engineers only read about. Logged back into the server that had locked me out. Let me walk through the whole thing, because the recovery only makes sense once you see how the server was built. Renting a computer by the hour The cloud is someone else's computer that you rent by the hour. You get a slice of a machine in a warehouse, use it, and hand it back when you are done. Amazon calls this service EC2, and one rented machine is an "instance." The mental shift that matters: you pay for the machine existing, not for using it. A server you forgot about costs the same as one serving thousands of people. That single fact shapes every decision in this module, and it is why cost discipline shows up at the end. Locking the front door before building anything The very first step had nothing to do with servers. It was locking down the account itself. When you sign up for AWS, you get a "root" account that can do anything, including run up unlimited charges if the credentials leak. There is a whole economy of bots scanning the internet for leaked AWS keys, and they spin up expensive servers within minutes of finding one. So the first move is to lock root away behind multi-factor authentication and create a weaker, everyday identity to actually work with. That everyday identity is an IAM user. Root is the master key you lock in a drawer; the IAM user is the normal key you carry. Root account secured with multi-factor authentication. An everyday IAM user, in an Administrators group, so I never work as root. The server that would not let me in With the account secured, I launched my first instance. And immediately hit a wall. SSH timed out. Not "permission denied," which would mean I reached the server but was not allowed in. A timeout, which means the knock got no answer at all. My security group, AWS's firewall, was correct: SSH open to my IP, web traffic open to everyone. So why the silence? I worked through it one layer at a time. Was my key wrong? A wrong key gets rejected, not ignored. Had my home IP changed? It matched. Was the subnet missing its route to the internet? The gateway was there. Then I found it. A network ACL, a second firewall sitting above the security group, set to deny all traffic. Someone had configured this account's network in a non-standard way long before I arrived. My rules were perfect; the layer above them blocked everything. I made a call that felt like the professional one: stop patching someone else's confusing setup, and build my own clean network from scratch. A fresh VPC, one public subnet, a proper gateway, all wired correctly. I launched into that, and SSH worked instantly. The instance running in my own clean network, finally reachable. The lesson stuck harder than any happy-path tutorial could have taught it. A timeout is not one problem, it is a checklist: security group, your IP, the route, the network ACL. And when you inherit a mess, rebuilding clean often beats untangling. Hardening, against real threats this time I had hardened Linux servers before, but always on my own laptop where the threats were hypothetical. This one had a public address, which means bots start probing it within minutes of it going live. Same baseline, real stakes: patch everything first, put up a firewall that denies everything by default and opens only SSH and the web ports, and run fail2ban to jail anything that hammers the login repeatedly. The firewall: everything denied by default, only SSH and the web ports open. fail2ban standing guard, ready to jail repeat login offenders. Giving it a name and a padlock A raw IP address is no way to reach a website. So I pointed a subdomain of my own domain, app.viviancloud.site, at the server, while carefully leaving my main domain on its existing site. One domain, different subdomains for different things, which is exactly how real companies organise this. Then HTTPS. For years, certificates cost money and were fiddly. A nonprofit called Let's Encrypt made them free and automatic. One tool, one command, and my site loaded with a padlock and a certificate that renews itself. The plain-HTTP postcard became a sealed envelope. My own page, served from the EC2 instance. Reachable by name at app.viviancloud.site. The padlock: HTTPS live, certificate valid and auto-renewing. Data on its own disk I attached a second disk, separate from the one the operating system lives on. The reason is practical: keep your data apart from your OS, and you can rebuild the OS whenever you like without touching the data. Format it, mount it, and add it to the system's startup config so the mount survives a reboot. I proved it by actually rebooting and watching the disk come back on its own. The separate data disk, still mounted after a full reboot. The lockout, and the way back Now the part I opened with. To learn recovery for real, I created the disaster. I emptied the file that lists which keys are allowed to log in, disconnected, and confirmed I was locked out. Permission denied, on my own running server. But before breaking anything, I took a snapshot: a full backup of the disk, my undo button. A snapshot first. Never break something risky without a backup. Here is the recovery, and the single idea that makes it possible: the file that decides who can log in lives on the disk, and a disk is a movable object. So I stopped the server, detached its disk, and attached that disk to a second "rescue" instance as a spare drive. From the rescue instance, I could reach into the locked server's files, and I wrote my key back onto its login list, with the exact ownership and permissions SSH insists on. Then I detached the disk, reattached it to the original server as its boot drive, and started it up. I logged in. The same key that got "permission denied" ten minutes earlier now worked. It is exactly like being locked out of your house, unbolting the front door, carrying it to a locksmith who fits a new lock you have a key for, and rehanging it. The house never changed. You fixed the lock by taking the door somewhere you could work on it. The deeper realisation: a server accepts any key whose public half is written in its login file. So a lost key is never a dead end. You do not recover the old key, you generate a new one and install it. The lock is always replaceable. There are faster recovery routes when you set them up in advance, but the disk-swap always works, with no agent and no preparation. It is the universal fallback, which is why it is the one worth learning first. Building carefully, tearing down completely The module ended where cloud work always should: accounting for the cost and knowing how to remove everything. Total spend for all of this: zero dollars, by staying on free-tier resources and stopping the instance between sessions. I set a billing alarm as a tripwire, and wrote a teardown runbook listing every resource and how to remove it in order, because a resource you forget is a resource you keep paying for. A billing alarm: emails me if estimated charges ever cross five dollars. What I actually learned Not just the steps. The principles underneath them. That cloud bills on existence, not use. That you default everything to closed and open only what each service needs. That a lost key is a lock to replace, not a catastrophe. And that knowing how to cleanly destroy infrastructure matters as much as knowing how to build it. I locked myself out of a server and got back in by hand. I will not forget how that works.

💡 Originally published on devtocash.com — where this guide stays updated. I write hands-on DevOps/SRE deep-dives there weekly. Introduction For years, GitOps had a quiet blind spot. Argo CD would faithfully reconcile whatever lived in your Git repository into the cluster, but it never asked the most basic security question: did the right person actually write this commit? If an attacker pushed a tampered manifest, or a compromised CI bot force-pushed an unsigned change, Argo CD would deploy it without hesitation. The trust boundary stopped at "the repo is the source of truth" and went no further. Argo CD 3.5, released as a release candidate in June 2026, closes that gap. This is the release where GitOps grows up on supply-chain security. Two features stand out: Source Integrity validation , which refuses to sync unsigned or untrusted commits, and mTLS for the repo-server , which encrypts and authenticates traffic between Argo CD's own internal components. There is more in the release — Helm 4 support, a native ApplicationSet UI, impersonation and Source Hydrator both graduating to beta — but the security story is the headline, and it is the one platform teams should act on first. This guide walks through what actually changed, how to turn each control on with copy-paste configuration, and how Argo CD's approach compares to Flux, Rancher Fleet, and Jenkins X. If you run GitOps in a regulated or multi-tenant environment, this is the upgrade you have been waiting for. Why supply-chain security finally reached GitOps The threat model is not hypothetical. A GitOps controller is, by design, a privileged actor: it has cluster-admin-level reach and it deploys whatever the repository tells it to. That makes the repository itself the highest-value target in the whole pipeline. Compromise the repo, or compromise a token that can write to it, and you own production — no need to touch the cluster API directly. Before 3.5, Argo CD had no native answer to this. As InfoQ put it in their coverage of the release, "nothing in Argo CD prevented a compromised Git repository from silently deploying unsigned or tampered manifests." Teams bolted on external admission controllers or Git-provider branch protections, but there was no first-class, in-the-reconcile-loop check. The second gap was internal. Communication between the repo-server and the other Argo CD components — the API server, the application controller, the ApplicationSet controller — was unencrypted. Most teams apply mTLS at the ingress and then forget that the software behind it is chattering in plaintext. In a shared cluster, that internal traffic is exactly the kind of lateral-movement surface a serious attacker looks for. If you have read our Kubernetes security best practices , you already know that "secure the perimeter and trust the inside" is the anti-pattern that keeps incident responders employed. What makes 3.5 notable is who built it. The security features landed from engineers at Red Hat, Octopus Deploy, GoTo, and Intuit. Supply-chain hardening in GitOps is no longer one vendor's pet project; it is a cross-industry priority, which is a strong signal that this is where the ecosystem is heading. Enabling Source Integrity: signed commits, enforced Source Integrity is the feature that makes Argo CD verify that a Git source has been signed, and that the signature validates, before it syncs anything. Credit for the implementation goes to Oliver Gondza at Red Hat. You enable it per-Application in the spec. The minimal form looks like this: apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : payments-api namespace : argocd spec : project : payments source : repoURL : https://github.com/acme/payments-manifests.git targetRevision : main path : overlays/production sourceIntegrity : required : true destination : server : https://kubernetes.default.svc namespace : payments syncPolicy : automated : prune : true selfHeal : true The key line is sourceIntegrity.required: true . With that set, Argo CD will only hydrate and deploy manifests from commits carrying a valid signature. An unsigned commit — or one signed by a key Argo CD does not trust — stops at the door. The sync fails loudly instead of shipping quietly. If you prefer to drive it imperatively, or you are scripting a rollout across many Applications, the CLI flag does the same thing: argocd app set payments-api --source-integrity-required For teams using the Source Hydrator (which separates "dry" un-rendered manifests from their hydrated output), 3.5 extends the same check to dry commits. That means integrity is verified at the very start of the hydration pipeline, before any rendering happens, so a tampered dry manifest never even gets processed. This dry-source support, contributed by Boostrack, is part of what pushed the Source Hydrator to beta. A practical rollout tip: do not flip required: true across every Application on day one. Start with one non-critical workload, confirm your signing setup actually produces commits Argo CD trusts, and only then expand. A misconfigured trust store will happily block every sync, and discovering that during a production incident is not the lesson you want. This is the same canary discipline we advocate in the incident management runbook template : change one thing, watch it, then widen the blast radius on purpose. Turning on repo-server mTLS The second pillar is internal mTLS. In 3.5 the repo-server can require client certificates from every component that connects to it, so the API server, application controller, and ApplicationSet controller all have to prove who they are before they get a manifest rendered. Georgios Papapetrou at Octopus Deploy implemented it. The pragmatic detail that makes this easy to adopt: for environments without custom certificates, the repo-server generates self-signed certs in memory . It does not depend on the filesystem, and it does not require you to stand up a full PKI just to get internal encryption working. That is a deliberate design choice to lower the barrier — you get authenticated internal traffic and better health-check behavior without a certificate-management project attached. In a Helm-based install, you opt in through values on the repo-server component: repoServer : extraArgs : - --repo-server-strict-tls env : - name : ARGOCD_REPO_SERVER_STRICT_TLS value : " true" Once strict TLS is on, any component that connects without a valid client certificate is refused. For organizations that already run an internal CA — or a service mesh issuing workload identities — you can supply your own certificates instead of the in-memory self-signed ones and fold Argo CD's internal traffic into your existing trust hierarchy. Either way, the plaintext-between-components era is over. Think of Source Integrity and mTLS as two ends of the same chain of custody. Source Integrity guarantees the manifest that enters Argo CD is trustworthy; mTLS guarantees it cannot be tampered with or spoofed while moving between Argo CD's own parts. Defense in depth, applied to your delivery system itself. Multi-tenancy: impersonation and per-team ApplicationSets Security is not only about cryptography; it is about who is allowed to do what. Two 3.5 changes matter here. Impersonation graduated from alpha to beta. When you configure it through an AppProject or RBAC policy, Argo CD now assumes the correct user identity automatically for server-side operations — log streaming, resource deletion, and sync all execute with the right permissions instead of Argo CD's blanket service account. In a multi-tenant cluster, that is the difference between an audit log that says "argocd-server did it" and one that says "team-payments-ci did it." GoTo's Alexy Mantha contributed the server-operations work. ApplicationSets in any namespace is now stable, contributed by Red Hat's Mangaal. Previously all ApplicationSets had to live in the Argo CD namespace, which forced central-team bottlenecks. Now each team can own its ApplicationSets in its own namespace with its own access controls — a real enabler for the self-service model that platform engineering keeps promising. Pair that with the new ApplicationSet concurrency controls (which cap how many applications get processed at once so you do not hammer the cluster or your Git provider's API) and large fleets become much safer to operate. If you are still deciding how much autonomy to hand teams versus the platform group, our breakdown of SRE, DevOps, and platform engineering frames the trade-offs these features let you actually implement. How Argo CD 3.5 compares to Flux, Fleet, and Jenkins X Context matters. Some of what 3.5 ships as new has existed elsewhere, and some of it is genuinely ahead. Here is the honest comparison, drawn from InfoQ's analysis. Capability Argo CD 3.5 Flux 2.8 Rancher Fleet Jenkins X Internal component mTLS New: repo-server strict TLS Not needed — controllers talk via K8s API objects Not needed — websocket agent, TLS at ingress Handled at pipeline layer Commit signature verification New: Source Integrity Native GPG ( spec.verify.mode: head ), predates Argo CD Needs Git-provider policy or admission webhook Tekton Chains + GPG-signed releases ApplicationSet preview UI New: Preview Apps tab Flux Operator dashboard, no preview equivalent Rancher CD dashboard section No first-party preview The nuance: Flux avoided the internal-mTLS problem by architecture — its controllers communicate through Kubernetes API objects rather than direct gRPC, so there is no unencrypted internal channel to secure in the first place. And Flux has offered native commit-signature verification longer than Argo CD, so on that specific point Argo CD is catching up, not leading. Where Argo CD 3.5 clearly pulls ahead is the ApplicationSet Preview experience and the breadth of enterprise auth integrations. Choose based on your architecture, not the changelog length. A practical upgrade checklist Before you roll 3.5 into production, work through this: Test the release candidate in a non-production cluster first — it is an RC, and the Argo team explicitly asked for community feedback before the final release. Stand up commit signing in CI before enabling sourceIntegrity.required , so trusted commits exist to sync. Enable Source Integrity on one low-risk Application, verify a signed commit syncs and an unsigned one is rejected, then expand. Decide on certificates for repo-server mTLS: in-memory self-signed for a quick win, or your own CA/mesh identity for a unified trust store. Audit your AppProjects and RBAC so impersonation maps to the identities you actually want in your audit logs. Review ApplicationSet concurrency limits if you manage hundreds of applications, to protect both the cluster and your Git provider's rate limits. If you containerize your own tooling around this pipeline, the same supply-chain mindset applies to your images — our guide to Docker multi-stage builds covers keeping build provenance clean and attack surface small. Related Reading ArgoCD GitOps: Best Practices for Production Deployments — the foundational App of Apps, secrets, and RBAC patterns that Source Integrity and repo-server mTLS build on top of in this release. ArgoCD GitOps: Best Practices for Production Deployments in 2026 — a companion practices guide covering health checks, sync waves, and disaster recovery alongside the security hardening discussed here. Zero-Downtime Deployments with GitHub Actions and Kubernetes — contrast the push-based GitHub Actions deploy model with the pull-based, now cryptographically verifiable GitOps model covered here. Conclusion Argo CD 3.5 is a security release wearing a feature release's clothing. Helm 4 and the ApplicationSet UI will get the demos, but Source Integrity and repo-server mTLS are the changes that alter your risk posture. Together they extend the GitOps trust boundary from "the repo is the source of truth" to "the repo is the source of truth, and we can prove every commit and every internal hop is authentic. " That the work came from Red Hat, Octopus Deploy, GoTo, and Intuit tells you this is not a niche concern — it is where the whole GitOps ecosystem is converging. Signed, verifiable, internally-encrypted continuous delivery is becoming table stakes, not a differentiator. Upgrade deliberately. Sign your commits, turn on Source Integrity for one workload, watch it, and widen from there. Your future incident responder — possibly you at 3 a.m. — will thank you for closing the door before someone walked through it. 📌 Read the latest version of this guide — plus the full library of DevOps, SRE, Kubernetes, observability & cloud-cost guides — on devtocash.com .

Enterprise cloud billing exports (like AWS CUR 2.0 or Azure Cost Management) scale into multi-gigabyte matrices, feature unpredictable column order anomalies, and cause rounding drift when parsed using floating-point types. Billing Data Gateway resolves this structural inefficiency. It is a zero-dependency C11 systems core designed to ingest, auto-detect, and map heterogeneous hyperscaler billing datasets into an immutable in-memory array known as the Intermediate Financial Model (IFM) . To achieve maximum throughput under hardware constraints, the architecture enforces a strict invariant: zero dynamic heap allocations ( malloc / calloc ) inside the row processing loops. 📐 Ingestion Pipeline Architecture Data flows end-to-end within virtual memory, maintaining a layout-decoupled footprint: POSIX mmap() Engine: Projects raw file descriptors straight into the process virtual address space, maximizing kernel-to-userland page fault transfer speeds. Dynamic Provider Registry: Scans the first byte rows at runtime to identify the source hyperscaler schema signature, cleanly loading the correct vendor adapter. Schema Inversion Adapters: Normalizes out-of-order column sequence drift at runtime using dynamic lookup tracking index arrays. Zero-Copy Tokenizer: Winds token positions using fixed slice windows ( str_slice_t ) tracking pointer coordinates and lengths, bypassing string allocation costs. Fixed-Point Currency Core: Parses cost figures natively out of raw text blocks straight into int64_t micro-currency coordinates ($1.00 = 1,000,000 µ$), completely isolating the system from floating-point inaccuracies. 💥 The Crash: A Dangling Pointer in Zero-Copy Memory Space While implementing a zero-allocation streaming JSON output module ( -f json ), the engine hit a hard memory protection violation: Segmentation fault (core dumped) Because a zero-copy parser does not duplicate strings into heap memory, every str_slice_t points straight to the virtual memory addresses paged by the mmap() initialization call. The GDB Investigation Trace Instead of guessing or hacking random logic modifications, the pipeline was compiled with full debug symbols ( -g ) and executed under the GNU Debugger ( gdb ). Capturing the function backtrace ( bt ) isolated the exact breakdown lane inside the standard library string measurement functions: __strnlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 Selecting the loop context frame and printing the record state variable ( print records[0] ) exposed the root architectural mismatch: usage_start_raw = { ptr = 0x7ffff7fbc0d8 <error: Cannot access memory at address 0x7ffff7fbc0d8>, len = 10 } The Diagnosis The length field was valid ( 10 ), but the pointer was pointing to a memory coordinate address space that the operating system kernel reported as unreadable. Tracing the code pipeline layout upstream revealed the lifecycle leak: the parsing function wrapper successfully processed the rows, stored the memory pointers in the record array, and then closed the memory map ( mmap_close() ) to clean up resources before returning control to main() . The moment the downstream JSON serializer attempted to stream out the slices, it was dereferencing dead, unmapped virtual pointers. 🛠️ The Memory Ownership Refactor To preserve the zero-copy capability safely, the memory page lifetime must span the entire lifecycle of both the parsing modules and the output serialization planes. Root Ownership: Transferred the mmap_file_t resource structure allocation wrapper entirely to the top-level application lifecycle execution context ( main.c ). Deferred Teardown: File mapping boundaries are initialized at the absolute system ingress point and unmapped ( mmap_close() ) only after all downstream output formats finish streaming out. /* Output System serialization runs safely while the memory map remains alive */ if ( format_arg && strcmp ( format_arg , "json" ) == 0 ) { serializer_write_json ( stdout , records , out_count ); free ( records ); mmap_close ( & mfile ); /* Safe close out after serialization reads finish */ return 0 ; } 📊 Result & External Validation Recompiling under aggressive compilation target profiles ( -Wall -Wextra -O3 ), the architecture successfully streams high-speed records straight into pipe configurations, verified as 100% syntactically correct JSON via external Linux pipeline tools: ./billing-gateway -i data/aws_cur_shifted.csv -f json | jq . Verified Stream Snapshot [ { "source_line" : 2 , "provider" : "AWS_CUR" , "account_id" : "" , "resource_id" : "" , "usage_start_raw" : "1700000000" , "billed_cost" : 45.800000 } ] 💡 Key Architectural Lessons Memory Ownership is Strategy: In zero-copy processing systems, data structures are bound to the lifetime of their files. Component ownership design must match the data usage spectrum. Evidence Over Speculation: GDB and shell pipeline tools ( jq ) tell the absolute truth. Never rewrite consumer code when your upstream data coordinates are corrupted. 💻 Deep Dive into the Codebase Matrix The source core files, integration test harnesses, and throughput profiling suites are live and public: 👉 GitHub Repository: https://github.com/CloudOps-Financial-Platform/billing-data-gateway

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. submitted by /u/yourcloudguy [link] [comments]

What happens when AI goes down, it is like us-east-1 in AWS going down, work literally stops. Time to go outside and play 😅 submitted by /u/kiwifellows [link] [comments]

I’m hosting a small Python web application on Azure App Service in the Central India region. Right now, I’m using the F1 (Free) plan for development/testing. The problem is that when I try to scale up to Basic (B1, B2, or B3) , Azure shows “Quota Exceeded” for the Central India region. It doesn’t allow me to create or scale to any Basic SKU, while the Standard tiers (S1, S2, S3) are available but are much more expensive than what I need for a simple test environment. Has anyone faced this issue? I’m looking for answers to these questions: Is there any way to request additional quota for App Service Basic SKUs in Central India? Is this a temporary regional capacity issue or a subscription limitation? Would moving to another nearby region be the best option? Are there any other low-cost Azure hosting options that would be suitable for a small web application? I’d like to stay within Azure if possible, but I’m trying to keep the hosting cost as low as possible for a POC/testing environment. Any suggestions or experiences would be greatly appreciated. Thanks! This post is drafted by chatgpt🫥 submitted by /u/Otherwise_Rip_4033 to r/AZURE [link] [comments]

Bottom line, treasury reconciliation for cross border payments only automates cleanly when your payment platform emits structured settlement events instead of swift trace messages. The rail underneath determines what data you can pull into your ERP. We moved off swift wires last year onto a B2B payment platform whose backend runs on cybrid. The reconciliation difference is the data shape. Every settlement event arrives with timestamp, payment id, invoice reference, and rail type as structured fields. Our ERP consumes the webhook and auto posts the journal entry. No manual matching. Key finding from the migration. Manual reconciliation time dropped roughly 70 percent. Period close on international AP went from 5 days to under 2. The fp&a team got back hours weekly that used to go chasing wire confirmations. What still needs human review. Exception cases like partial settlements or fx rate disputes. Volume on those is small but they require judgment so we haven't automated them. For finance teams looking at this, the question to ask your payment platform is what webhook fields they emit and whether the backend is on regulated stablecoin infra. If the backend is swift, automation has a ceiling. If it's on cybrid or a peer, the data quality unlocks real reconciliation savings. submitted by /u/Parking_Pie9457 to r/FinOps [link] [comments]

Ran the same Kubernetes workload across managed providers for an EU SaaS setup: Requirements: high availability, managed PostgreSQL, Redis, WAF, CDN, EU region, €1,500/month budget. Results: Hetzner 614€/mo lock-in 34/100 GDPR 87/100 Scaleway 832€/mo lock-in 46/100 GDPR 89/100 DigitalOcean 899€/mo lock-in 48/100 GDPR 84/100 GCP/GKE 1,264€/mo lock-in 64/100 GDPR 85/100 Azure/AKS 1,418€/mo lock-in 68/100 GDPR 85/100 AWS/EKS 1,652€/mo lock-in 72/100 GDPR 84/100 GKE scores highest on Kubernetes maturity and managed tooling. But the cost is 2x Hetzner for the same workload. The real question for EU workloads: is the GKE operational advantage worth the cost and lock-in delta over Hetzner or Scaleway? For people running GKE in EU production — what tipped the decision? submitted by /u/faouzi_mahmoudi to r/googlecloud [link] [comments]

How are you managing costs? Tracking attribution, etc submitted by /u/sageVsTheWorld to r/FinOps [link] [comments]

Tokensentinel is a tool that watches your token consumption in process with sub ms overhead. The SDK determines 10+ rules such as tool loop, retrieval thrash etc and you can fine tune it according to your app settings with simple args. You can try it for free and check where your app is consuming extra tokens right now. I am also partnering up with few teams on the cloud side features for intervention, slack alerts and budget enforcement, if any of the FinOps team gives feedback, it would be great help for me. Check: https//tokensentinel.dev submitted by /u/Either_Meet_6909 to r/FinOps [link] [comments]

Fascinating quote from AWS's networking team: "We know customers do not like rate-based network charges because it’s hard to predict their cost, which is why we are moving towards flat-rate pricing for new network products." submitted by /u/Much_Preparation_832 to r/aws [link] [comments]

We got our July invoice and noticed that our July invoice was cancelled and rebilled with a significant credit (about 50% of our OpenAI spend). I'm assuming this is related to the discussion in https://old.reddit.com/r/AZURE/comments/1v2kb4d/check_your_azure_openai_bill_we_found_major_gpt54/ but was curious if anyone else saw the same thing? submitted by /u/vedichymn to r/AZURE [link] [comments]

Prompt caching on Claude only pays off if the cached prefix is byte-identical between requests. Sounds obvious written down, but it's surprisingly easy to break without noticing, a timestamp inserted before the cacheable block, a per-user detail placed at the start instead of the end, and the whole cache silently misses on every single call. No error, no warning in the response, just a bill that doesn't reflect the discount it should. Went through a session where this was happening and the cost difference was significant, easily 2-3x more expensive than it needed to be for the same task, purely from cache misses caused by content ordering. Fix was mechanical once identified: move anything that changes per request, timestamps, session IDs, user-specific detail, to the end of the prompt, after the stable system instructions and reference material that should be cached. Separate from caching specifically, long coding sessions also tend to resend full file contents on every message even when the diff is small, and replay the entire conversation history each turn instead of a compressed summary of where things stand. Neither shows up as a mistake in the moment. Both compound quietly across a session into a number that looks wrong a month later with no clear story for why. Wrote up the full audit and the fix here: https://medium.com/@nagatomopedro05/the-hidden-cost-of-long-claude-sessions-2a6cc7655893 submitted by /u/ClickOk5811 to r/aws [link] [comments]

Did anyone else notice that the GitHub status page reported an incident with GitHub Actions, only to deny it 47 minutes later? Our monitors captured it, paged our on-call team, and then GitHub denied that any incident had occurred. https://www.githubstatus.com/incidents/gx7js8bd0jpz submitted by /u/pod_army to r/devops [link] [comments]

Can you recommend either general features to look for in UPS units to stay on during storms or specific models that work properly? Something I have been frustrated by recently is UPS units shutting off when the power flickers during a storm rather than switching to battery. I presume this is because there was a power surge not just a dropout, but it seems to happen with great frequency. As an example, one customer's server is connected to two different 1000VA UPS tower form factor, one from Cyberpower and one from APC. I think they have both turned off instantly during power outages more often than either has actually stayed on during the outage. Both work fine if simply unplugged. submitted by /u/Kamikaze_Wombat to r/sysadmin [link] [comments]

Hi, i don't really know if this the correct place to ask but i hope to get insight and maybe if anyone ever get into the same case. what happen: I was playing with vertex and trying out different model, and after a while want to try claude api from vertex (now they called agent platform) tried to activate the api and run some req, but getting no quota, manually request from console also give no upgrade at all, so i tried contacting the sales support, asking for an increase quota for some sonnet and haiku model, I ask for just mere 20 rpm and 100k tpm output limit increase, because I am just trying out few days later, as of today got an email from ai studio of my billing tier upgraded to tier 3 https://preview.redd.it/gzqn400tkvjh1.png?width=1647&format=png&auto=webp&s=a55dc52f6ec66427d8dc01d1c19a4e842d5d558a I check on my gcp console, now i get the anthropic limit raised to a whopping lot of 2M input, 200k output, and 2k rpm https://preview.redd.it/6lldf52flvjh1.png?width=1853&format=png&auto=webp&s=9debe3966cc109ffb661eb38d3deccb30c06162f what scares me now that my limit are actually increased to the max limit of USD 100,000 and any random shit happen and it potentially ruin my finance. https://preview.redd.it/urg5paexjvjh1.png?width=847&format=png&auto=webp&s=bcde642217a63a23bdb963316d9914a9d651d119 What i want to know did anyone every get into this before? can i actually downgrade to tier 1? as my spending actually small just 1-3usd per month on few months back where can i get the support for this particular issue? Thank in advance :) submitted by /u/x-xiaolongbao to r/googlecloud [link] [comments]

Something looks off on a server, policy blocks installing Sysinternals, and on Server Core there's no GUI either. All of this is built in and works over PowerShell remoting. Most of my work is incident response, which in practice means turning up to networks where I'm not allowed to install anything and being asked to have an opinion anyway. Not an EDR replacement. It's the DIY version for when there's no agent on that box, or you'd rather check yourself than take a vendor's word. Signature , including the catalog-signed system files many Windows binaries use rather than embedded ones: Get-AuthenticodeSignature -FilePath "C:\Windows\System32\suspect.exe" | Format-List * Status should be Valid. HashMismatch means the file changed after signing. Valid isn't the same as safe. What name it was compiled under : (Get-Item "C:\Windows\System32\suspect.exe").VersionInfo | Select-Object OriginalFilename,CompanyName,FileDescription A binary keeps the OriginalFilename it was built with, so a plain rename announces itself where hashing can't see one. The field is attacker controlled though, so it only means something read next to the signature. Unsigned plus "Microsoft Corporation" is loud. Expect noise, roughly 4% of a clean System32 mismatches because Microsoft ships typos and abbreviations. Part of the protected OS set (needs elevation): sfc /verifyfile=C:\Windows\System32\suspect.exe Downloaded rather than shipped : Get-Item "C:\Windows\System32\suspect.exe" -Stream * A Zone.Identifier stream on a system binary is close to conclusive. Timestamps against its neighbours : Get-Item "C:\Windows\System32\suspect.exe" | Select-Object CreationTime,LastWriteTime Timestomping is trivial, so matching timestamps prove nothing while mismatched ones prove a lot. If it's running : Get-CimInstance Win32_Process -Filter "Name='suspect.exe'" | Select-Object ProcessId,ParentProcessId,ExecutablePath,CommandLine Get-NetTCPConnection -OwningProcess <PID> Hashes, and public datasets you can query yourself : Get-FileHash -Path "C:\Windows\System32\suspect.exe" -Algorithm SHA256 Get-FileHash -Path "C:\Windows\System32\suspect.exe" -Algorithm SHA1 winbindex.m417z.com indexes what Microsoft actually shipped. A system binary's name carrying a hash Microsoft never shipped is the clearest signal you'll get. CIRCL hashlookup wraps NSRL and friends, no API key: Invoke-RestMethod "https://hashlookup.circl.lu/lookup/sha1/<sha1>" Query by SHA1, not SHA256. Classic NSRL records carry MD5 and SHA1 only, so SHA256 can't reach them. Coverage skews old, so it's more useful on legacy boxes than a patched 2022 server. One caveat before looking anything up. Submitting a hash is itself a disclosure, and a first ever lookup tells whoever built it that you're looking. What would you add? Genuinely interested in what people check that isn't in here, most of this list came from someone else's answer to the same question ;) submitted by /u/Haunting_Ganache_850 to r/sysadmin [link] [comments]

On the heels of an epic outage, Securence is getting out of their email, web and other cloud online services businesses, with a drop-dead date of November 11, 2026. Feel free to share your comments. Here is the content of an email I received today: First, thank you for your loyalty to US Internet. As you know, USI joined the Metronet family last year. As part of this transition, we are simplifying our product portfolio to focus on delivering fiber internet, voice and network connectivity solutions. We are writing to give you advance notice that the following USI products and services will be retired after Wednesday, November 11, 2026. All Securence services, including: - Standard Email/POP/IMAP Email - Hosted Exchange Mail - Email Filtering (Incoming, Outgoing, Mail Continuity, Archiving and Cyphermail). Hosting services: - Web Hosting - SSL Certificate Services - Domain Registration - DNS Hosting - Managed Database Services VM services: - Backup Storage - VMware Server Hosting Data center network services: - Managed Firewall Email Addresses: - u/usinternet .com - u/usiwireless .com Affected services will remain available through Wednesday, November 11, 2026.Your account uses one or more of these services, and you must transition to another provider before that date to avoid a service interruption or loss of data. Migration instructions and additional resources are available at securence.com/migratefor Securence products or at usinternet.com/migratefor all other services. We recognize this change may affect your day-to-day operations and apologize for any disruption. We are providing advance notice to allow sufficient time to plan and complete your transition, and we remain committed to assisting you throughout the process. You have been a valued customer, and we thank you for many years of service. If you have technical questions or need support, please email us at [ [email protected] or](mailto: [email protected] ) call (952) 253-3290. submitted by /u/MorseScience to r/sysadmin [link] [comments]

RDST (Readyset Diagnostic & SQL Toolkit) is a free desktop app that connects to your RDS or Aurora instances and tells you which queries are driving the load you are paying for. The reason I built it is that Performance Insights is decent at telling you there is load, but going from "there is load" to "here is the query, here is why it is slow, and here is whether fixing it lets me drop an instance class" is still a repetitive manual process: open Performance Insights and find the top SQL by load copy the digest out and go run EXPLAIN ANALYZE against the instance yourself go find the table definitions and check whether the statistics are current work out whether the index you have in mind already exists check max_connections, to see if this is what’s actually biting during the spike go back to the pricing page and work out whether any of this justifies the instance class you are on do it again for the next instance That last step is where the money is. Fix one query dominating CPU and you can often downsize, which on a large instance is hundreds/thousands per month. Full disclosure - I work for Readyset (which is a caching layer for postgres / mysql), and this tool spawned from a recurring question our caching customers kept asking - which queries should we actually cache? And these same queries are the ones that, even without a caching solution, could heavily benefit from performance diagnostics. It runs locally using credentials you already have, SSO or a named profile. Nothing gets installed on the instance and there is no cross-account role to create. It discovers your Aurora clusters and RDS instances, audits all of them, saves query snapshots so you can track regressions over time, and even allows you to ask plain english questions about any / all of your nodes and their queries. The health check feature gives you a sizing verdict with your current monthly cost and a suggested instance class, so making the decision to downsize/upsize should become very clear. The reason this is worth doing: the instance in that report is an Aurora db.r6g.4xlarge running about $1,180 a month on demand. Three unindexed access paths account for roughly 66% of its total database time, and those are what the CPU peaks are made of. With those three indexes in place the audit puts the same workload on a db.r6g.xlarge at about $295. That is $885 a month, a little over $10,600 a year, for what amounts to an afternoon of work. The tool is completely free to use, and we provide free trial tokens for all of the AI powered features. The app is in beta and we plan to release it under an MIT license. It runs locally, stores locally and everything it does is read-only. Full privacy related details: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy Would love feedback from people running Postgres or MySQL on RDS, particularly: Does the sizing verdict line up with what you'd have concluded from Performance Insights? Does it surface the queries you'd investigate first? Would you be comfortable pointing it at a production instance? If not, what would stop you? What's missing? Source: https://readyset.io/docs/readyset-ai/rdst/desktop https://github.com/readysettech/rdst submitted by /u/Frone0910 to r/aws [link] [comments]

Hi everyone, I'm hoping someone with Google Workspace or Google Cloud Billing experience can help me understand this situation. For the past few weeks, I've been receiving collection emails from ABC-Amega (American Bureau of Collections) claiming that I owe Google Workspace approximately INR 1.47 million. The emails contain: Customer: ApexZen - Dhruv Kanziya Collection File: 3531039 Domain: apexzen.store The email says my Google Workspace account has been placed into collections. The problem is: • I have never intentionally purchased or owned apexzen.store. • WHOIS shows the domain was registered on 11 January 2026 through Namecheap. • The domain currently appears offline. • Google Admin recovery recognizes [ [email protected] ](mailto: [email protected] ) as a Workspace account, but I do not know the password. • The recovery Gmail shown by Google is NOT mine. • I cannot recover the account. • I cannot access the Admin Console. • Google Cloud Billing shows I am not an administrator of any billing account. • Google Payments shows no Workspace billing profile. • I have never seen any invoices or billing history related to this account. Another thing I noticed: The collection email tells me to: "Select the account ID mentioned above" However, the email does not include any Google Workspace Customer ID, Billing Account ID, Payments Profile ID, Invoice Number, or Admin Email. The only identifiers in the email are: Customer: ApexZen - Dhruv Kanziya File: 3531039 I have already disputed the debt with ABC-Amega and requested debt validation. My questions are: Has anyone seen Google Workspace collection emails that do NOT include Billing IDs or Customer IDs? Can someone accidentally add unrelated Gmail addresses as billing or notification contacts? Could this be a Google Workspace identity mix-up? What evidence should I request from Google or ABC-Amega to prove whether this account actually belongs to me? I'm attaching screenshots of: - the collection email - WHOIS information - Google Admin recovery - Google Cloud Billing - Google Payments Any advice from Workspace admins or Google Cloud experts would be greatly appreciated. Thank you. https://preview.redd.it/jz3gxpvb4shh1.png?width=1917&format=png&auto=webp&s=c34f77b1516b8ede1e5c385b8a1a7ffaf205c8d4 https://preview.redd.it/1f3xe0da4shh1.png?width=792&format=png&auto=webp&s=71b85ee0abeb80f9d5cfa44ce27ea6b77eda2d6a https://preview.redd.it/bki0ymr84shh1.png?width=955&format=png&auto=webp&s=74d33b34940e91bf935593585c31da8e36c8b551 https://preview.redd.it/n5xb1vb54shh1.png?width=1813&format=png&auto=webp&s=5c1d0f0d62d98e06a5f4f638df4c0e7a83011e24 https://preview.redd.it/2121wqhy3shh1.png?width=1917&format=png&auto=webp&s=318d3a6651e5e8912e31e01279141aadc583ddb5 submitted by /u/Inside-Phone-623 to r/googlecloud [link] [comments]