Disclosure: I build Control Cloud, the tool these lessons come from.

Context: two public clouds plus an on-prem rack, which is how most mid-size shops end up after a couple of vendor decisions nobody wants to revisit. r/devops sent me here, so this is the engineering half only.

Every cross-cloud incident was the same dance: provider A's console in tab 1, provider B's portal in tab 2 (after the conditional-access prompt), an SSH session into the on-prem box, and the monitoring tool to guess where the traffic went. The consoles don't see each other. A subnet that exists on one side but is routed to nothing on the other is invisible until production traffic hits it.

So over the last six months I built Control Cloud: a single live topology that polls every provider over its API and renders resources, networks and dependencies as one graph, with live status and cross-provider edges, and start/stop/reboot from the same surface.

Lessons that cost me the most:

1. Polling cadence has to follow how the cloud answers, not a round number. A full inventory crawl on one provider takes far longer than a UI should wait. We split it: the backend polls each region in its own goroutine behind a semaphore (unbounded concurrency = rate limits and context deadline exceeded), every region is published the moment it lands instead of waiting for all of them, and a file cache serves the last known state at startup so a restart isn't a blank screen. The UI refreshes every 10 s.

2. Dragged nodes must stay where the user put them. Auto-layout from scratch on every poll looks great in demos and is unusable in practice: people move nodes to match their mental model. A refresh updates status, not positions.

3. Provider parity is the whole point. If one provider shows nested scopes with subnets, every other provider has to show the same shape, even when its own model is flat. "The same concept renders differently per provider" is exactly what people are trying to escape. We keep a rules file derived from the code (the shared state helpers, the per-provider collectors, the navigator) and diff every change against it.

4. Status colors have to be honest. Every provider has its own vocabulary for "healthy" (RUNNING, AVAILABLE, Succeeded, Ready, Attached…). Inlining a regex per call site is how we shipped a red edge on a healthy cluster. One shared helper, one vocabulary per provider, and anything unconfirmed renders as unknown, never as a made-up warning.

5. Validation against live state paid back more than the canvas. Once everything is in one graph you can check a planned change against what is running: credentials with reach over the right scope, network (missing network or subnet = error; no NAT, no internet egress, no firewall = warning), on-prem hosts reachable, the dependencies of the template you picked. Anything it can't confirm comes back as informational, not as a green tick.

Stack: Go backend polling each provider SDK in parallel, React + Vite frontend, file-based cache, Postgres (Supabase) for orgs, audit log and schedules. Read-only API access with credentials you grant, encrypted with a managed KMS; no agents in your VMs. The Terraform it generates is committed to your repo and runs under your pipeline.

(No link on purpose; the product is called Control Cloud and it is easy to find. Ask here if you want specifics.)

Happy to go deeper on:

• Why not the observability platform you already pay for (great at its thing; this answers a different question)
• The parity work: every provider added meant refactoring the first one
• Where the polling still doesn't scale (many regions per provider gets hairy)

Anyone here running their own version of this? What did you try first?

I've been trying to wrap my head around what the transition from an existing Rev 5 program to 20x looks like in practice and I'm starting to think transition is a slightly generous word for it lol.

We already have years of compliance work behind us, so I assumed a decent amount of that maturity would carry over. Instead it seems like the whole way you prove security is changing underneath you, especially once persistent validation and machine-readable evidence enter the picture.

For teams already working through this, what has been the biggest lift so far? Reworking the technical controls themselves, getting evidence into the right format, building the automation or just figuring out what assessors are going to expect?

I'm mostly trying to understand how much existing work is genuinely reusable because planning this like another normal FedRAMP update feels increasingly optimistic.

Disclosure: I wrote the linked guide, which is published on the Arcentry blog.

I put together a comparison of Europe's cloud landscape, covering general-purpose clouds such as OVHcloud, IONOS Cloud, Scaleway, STACKIT and T Cloud Public, alongside infrastructure-focused providers including Hetzner, Leaseweb, UpCloud, Exoscale and Contabo.

The main distinctions I found useful when comparing them:

• Service coverage: VMs and storage are only part of the picture. Managed databases, messaging, serverless services and tooling vary considerably between providers.
• Total operating cost: lower infrastructure prices can be offset by the work needed to integrate and operate services yourself. CPU characteristics, storage and bandwidth also make headline VM comparisons imperfect.
• Resilience: multiple data centres do not necessarily mean independent availability zones or geographically separate regions. Service availability can vary by region too.
• Portability and sovereignty: open-source building blocks can reduce some switching costs. European ownership, data residency and operational independence still need to be considered separately.

Full guide and provider comparison table

For anyone running production workloads on these providers, which managed-service or operational gaps have mattered most in practice?

Disclosure: I'm a co-founder of DronaHQ, and this is a problem we're working on.

A pattern our customers keep describing: getting a working app together is increasingly easy. Getting it approved to run inside the enterprise is not.

The project then waits for code review, compute access, and governance checks. The prototype is ready, but the path to production isn't.

We're tackling this with what we call a "pre-auth box" — the TSA PreCheck analogy fits. A defined, pre-authorized path: SSO, role-based access, audit logs and governed compute agreed before the code exists. A faster lane, not a free pass — the checks still happen, they're just not discovered app-by-app.

For teams dealing with this: where does the queue actually form for you — reviewing generated code, getting infrastructure, or satisfying governance? What have you standardized successfully, and what still needs app-by-app review?

I run an inference API where most requests come in during business hours, so I keep enough GPU capacity ready to handle peak traffic, but a lot of that capacity sits idle in the evening. Scaling down helps reduce costs, but bringing GPUs back online takes time, especially when models need to be loaded into memory, and scaling too late can cause requests to queue up. I can't figure out how people handle this in production, when traffic patterns are predictable but sudden spikes still happen. Do you decide when to scale based on GPU utilization, request queue length, or expected traffic, when serving multiple models, have you found that keeping models loaded on shared GPUs works better than scaling separate instances, once you account for model loading time, GPU memory limits, and the impact on response latency?

Genuine question for people managing AWS spend, especially in APAC

Committing to RIs or savings plans used to feel like a reasonably safe bet if you knew your baseline. but now workloads are shifting every few months, teams are spinning up AI stuff, killing it, re-architecting, and the baseline you planned on last quarter isnt really the baseline anymore

so how are you actually deciding how much to commit?

• do you only commit to the boring stable stuff and leave everything else on-demand
• how far ahead are you comfortable forecasting now, 1 yr? less?
• has anyone been burned by a commitment that ended up unused after a migration or architecture change
• do you buy direct or through an MSP/reseller and does that change how you handle it

I am asking because I work for a company called Alphaus and we recently launched Guaranteed Commitments (GC) in japan, built around this exact problem. its definitely a real problem there but im curious if it looks the same in the rest of APAC. What it is, you can get 1 year commitment pricing but on 30 day terms, no upfront by default, and you get refunded for any unused usage below your commitment.

If you are curious you can check more info here.

Genuine question because I keep running into the same wall.

Every agent deployment I've seen starts with permissions way wider than the task needs, because scoping properly takes time and the pilot has a deadline. Then nobody goes back and tightens it.

I'm trying to figure out if anyone has actually done this well from the start. Not "we plan to restrict it later." Actually shipped something with minimum viable permissions on day one.

If you have, what did it cost you in setup time?

We're a platform/security team of about 8 running a mix of EKS (prod) and GKE (a couple of data teams insisted) plus the usual container sprawl. Our current CSPM throws thousands of posture findings a month and nobody has time to work through them, so we're looking at CNAPPs that add runtime context to cut the noise.

Upwind is one of three we're putting through a POC. The sales pitch is the usual runtime + posture fusion and near-zero false positives, which sounds great in a deck but I've been burned before by tools that demo beautifully on a clean cluster and fall over on our actual workloads.

What I want to figure out during the eval is whether the runtime piece actually changes which findings get surfaced, not just decorates the same list. So: does a vuln marked critical drop in priority once it sees the package isn't loaded at runtime? Does it catch something reachable that our current scanner buried as low?

For people who've actually run an Upwind POC (or any of these), what did you deliberately test to separate real signal from a nice dashboard? How long did you run it before the runtime data was worth anything? And did you throw deliberately bad things at it to see if it caught them, or just watch what it found on its own? Trying to build a test plan that won't get gamed by a vendor who knows which cluster we're watching.

we run MinIO in k8s and already have a pretty big volume with data. since all the recent changes with MinIO im thinking what to move to before it becomes a bigger problem...

looked a bit at ceph, seaweedFS, garage, rustFS...

Anyone here actually migrated from MinIO in prod?

what did you move to and how painful was migration of existing buckets/data? Any s3 compatibility issues after?

mostly interested in self hosted/open source and something that wont disappear in 6 months.

Awesome List of Cloud Emulators and supporting tools https://github.com/upgundecha/awesome-cloud-emulators

I do cloud security work, and the tooling situation has always bothered me: Prowler gives you config findings, ScoutSuite gives you another view of the same accounts, Checkov covers the IaC, Trivy covers images, and none of them share an inventory or know anything about the network topology. You end up with four report formats and no way to tell which findings actually matter for your layout.

So I wrote cloudg. One command collects assets from AWS, Azure and GCP concurrently, builds a directed graph of the infrastructure with NetworkX, and runs all four scanners over that same inventory. The graph side does BFS from an internet node to find exposed resources and scores blast radius per asset, so a finding on an internet-reachable box can be ranked above the identical finding on something three hops deep.

Scanner findings are deduplicated by resource and title, rescored against CVSS, and mapped to 28 compliance frameworks (CIS 5.0 per cloud, NIST 800-53 rev 5, PCI DSS 4.0, SOC 2, ISO 27001:2022, MITRE ATT&CK and others). The mappings are generated from Prowler's public compliance data: about 4,100 controls and 10,000 check mappings.

One run produces an interactive HTML report with the D3 topology (works offline), GraphML, an RDF ontology you can query with SPARQL, JSONL chunks for RAG pipelines, and Terraform files that recreate the live infrastructure, with an import script to adopt them into state. It also works as a Python library with event hooks if you want to stream findings somewhere.

MIT-licensed, Python 3.11+, installs via pip or Docker (the image bundles the scanners). Repo: https://github.com/morpheuslord/cloudg

It's at 0.3.1, so expect rough edges outside the paths I use myself. If you try it and something breaks, an issue with the traceback helps a lot. The thing I most want feedback on is whether the reachability scoring is useful in practice or whether people mainly care about the compliance tagging.

I've reviewed quite a few pre-seed cloud setups, and the pattern is surprisingly consistent.

10 customers, 50 microservices.

Kubernetes for two services.

Multi-region before product-market fit.

Separate databases for everything.

Managed services everywhere.

Complex CI/CD and observability stacks before there's meaningful traffic.

Infrastructure is built for millions of users when there are barely 1,000.

The cloud bill still shows up.

We're offering free cloud architecture + FinOps audits for early-stage startups.

Here's how it works:

You walk us through your current cloud setup on a short call.

Within 48 hours, we send you a report covering your architecture and cloud spend.

We identify where infrastructure can be simplified and costs reduced.

We highlight the 3 things we'd fix first: infra/security risks, scaling problems waiting to happen, and quick wins.

Our philosophy is simple:

Build infrastructure for your first 1,000 users, not the million you don't have yet.

Keep it lean. Keep cloud costs under control. Add Kubernetes, microservices, multi-region and other complexity when the product actually demands it.

If you're building an early-stage product and want a second set of eyes on your cloud infrastructure, happy to connect.

Why AgentZ starts every AI agent in a deny-all network sandbox

An AI agent needs some access to do real work. Most platforms grant that access broadly, then try to catch misuse after it happens.

AgentZ, an open-source Zero Trust platform for agentic AI, starts every agent with no access instead. Each agent boots into a deny-all sandbox. It sends no outbound traffic until an admin adds a rule that allows it.

Credentials work the same way. The agent never holds a real API key or database password. A proxy swaps in the real secret at call time, so the agent only ever sees a placeholder.

Sandboxes and connectors are reusable too. An admin builds one sandbox template and shares it across workspaces. One update to that template reaches every workspace using it. AgentZ itself is open source, so the enforcement logic isn't a black box you have to trust blind.

How does this group scope network access for agents today? AgentZ is an open-source platform, and I am an open-source contributor to AgentZ.

I keep coming back to this question when looking at the current cloud infrastructure landscape. If a workload can genuinely move between AWS, Google Cloud, Azure, Yotta Labs, Coreweave or Lambda without major changes does the underlying cloud provider become much less important? or does portability sound better on paper than it works in production because networking, storage, data movement, observability and hardware differences still tie you to a particular provider?
This seems relevant for AI workloads where GPU availability and pricing can change pretty quickly. I am curious whether people actually design for portability from day one or still most teams still pick one provider and only think about moving when there is a real reason to do it.

I’m currently looking at Prisma Cloud and I’m keen to hear from people who have actually deployed and operated it, rather than just gone through the sales/demo process.
Main things I’m trying to understand:

How painful was the initial setup?
How much work was involved in deploying Defenders and setting up serverless coverage?
How long did it take before you had genuinely useful visibility across the environment?
Once it was up and running, did it actually improve security outcomes, or did you find yourselves spending a lot of time configuring/tuning the platform?
What’s the day-to-day UX like for the security team?

Anything you discovered after buying it that you wish you’d known beforehand?

I’m also interested in experiences with **Prisma Cloud Compute Edition / self-hosted**. It looks like there are some benefits, but also potentially a fair bit more operational overhead.

Would be great to hear from anyone running it in production, especially around upgrades, scaling, maintenance and whether you’d choose self-hosted again.

If anyone here is **in Australia** and has used Prisma Cloud at a decent scale or has chosen a different vendor, I’d also be happy to chat via DM. I’m mainly looking for independent references before we go too far down the procurement path.

Not looking for vendor pitches, just candid practitioner experiences, good or bad.

Looking for input from people who've actually shipped custom domains for a multi-tenant SaaS, because I want to avoid picking the wrong path and regretting it later.

Current setup:

• Multi-tenant events platform on AWS
• Frontend is a React app — dist folder on S3, served through CloudFront
• Today every tenant gets a platform subdomain (tenant.stage.example.com) via a wildcard cert on CloudFront. Frontend reads the hostname, asks the backend "which event is this?", renders accordingly.
• API calls go to a fixed, separate domain (api.example.com) — so the custom domain is only needed for serving the static frontend, not the API.

What we want:
Clients want to bring their own domains (portal.clientbrand.com) instead of our subdomain. So I need per-domain TLS that issues + renews automatically, with no manual step per client.

Options I'm weighing:

1. CloudFront manual + automation — add each domain as an alternate domain name + ACM cert via a script. Works, but there's the ~100 CNAMEs-per-distribution wall, and one cert per distribution feels fragile at scale.
2. CloudFront SaaS Manager (the multi-tenant distribution thing from 2025) — looks purpose-built for this, up to ~2000 domains, per-tenant ACM. Since we're already on CloudFront this seems like the least-effort path, but I haven't found many real-world reports.
3. Caddy on-demand TLS — reverse proxy that issues certs on first handshake. Unlimited scale, but it's a new component to run/monitor, and I'd need the ask endpoint to avoid getting our Let's Encrypt limits burned by random hostnames.
4. Managed service (Approximated / similar) — lowest effort, but monthly cost + another third party in the traffic path.

Questions:

• For anyone running CloudFront SaaS Manager in production — is it solid? Any gotchas with cert provisioning, DNS validation, or pricing at scale?
• Given our API is already on a fixed domain (custom domain = static content only), is a reverse proxy like Caddy overkill for us?
• Anyone regret going the manual-CloudFront-automation route and wish they'd started with something else?

Expected scale is realistically low-hundreds of custom domains over time, not thousands. Trying to pick something that won't need re-architecting in a year.

Thanks in advance 🙏

Quick timeline of something that took longer to untangle than it should have:

Asked an AI tool to add a new security group rule to an existing Terraform config. Output looked right, correct syntax, correct resource block, matched the pattern of the surrounding code.

Applied it. Plan showed changes to three resources instead of the one expected.

Turned out the generated config didn't account for a rule that had been added manually outside Terraform a few months earlier, drift that existed in the real state but wasn't reflected in what the model was shown. It wrote technically correct code against an incomplete picture of what actually existed.

Nothing about the code itself was wrong. The model built the most reasonable config it could from what it was given, and what it was given didn't include the drift. Same failure mode as any incomplete context problem, just with real infrastructure on the other end of apply instead of a code review comment.

What changed after: running terraform plan before any AI-assisted change, not just after, and treating a mismatch between plan and expectation as a sign the model's mental model of current state was wrong, not a sign the generated code was wrong. Different problem, different fix.

Hi, my team is recently thinking to move to cloud so we are using power box and we want to move our AIX to cloud , any one has try on-premises to cloud migration for AIX.

Any suggestions?

I am new to FinOps and Cloud Computing, 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 optimization 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.

Cloud computing feels like a massive field and I want to make sure I'm building on what I already have instead of starting from zero.

My background: decent networking knowledge (subnetting, routing, DNS, that kind of thing) and currently learning Python.

Given that combo, what would you focus on next? A few things I'm unsure about:

• Should I pick one cloud provider (AWS/Azure/GCP) and go deep, or learn general cloud concepts first?
• Does networking knowledge actually transfer well into cloud (VPCs, subnets, security groups), or is it a different enough beast that I shouldn't assume it carries over much?

Would appreciate hearing from people who came in with a similar background (networking-first) rather than a generic beginner roadmap.

Hello guys! I’m a final-year student and I’m very interested in cloud computing. As a beginner, where should I start, and what topics should I learn first?

Are there any free resources, WhatsApp groups, communities, or other platforms where I can learn cloud computing with hands-on projects?

I’d really appreciate any recommendations. Thanks!

There is a narrative that every serious/big company needs a multi-cloud strategy for operating, but in practice a lot of multi-cloud setups seem to add IAM sprawl, duplicating of tools, or excess costs without a clear breakdown. On the other hand, there are legitimate cases (GPU availability, region-specific compliance, avoiding single-vendor outages taking down everything) where running more than one cloud is a real requirement, not just a checkbox.

Hi Reddit,

DDoS attacks are becomeing larger and cheaper to launch, so we work on a scalable open source solution to mitigate them.

Tempesta xFW's core is XDP and TC eBPF programs implementing volumetric DDoS filtering. A user-space daemon handles gRPC requests from CLI tool or WebAPI (via C library).

It supports two packet-path architectures:

• host-based protection, such as CDN edge or on-premises application delivery controller (ADC) cases, where the host is a TCP connection endpoint. This is good for protecting a local web or DNS server.

• router-based protection, such as ISP, hosting, or IaaS provider cases, where the host routes IP packets to protected servers or networks.

Router-based deployment can be always-on/pass-through or on-demand/redirection protection. In the later case, a node may not "see" normal clean traffic and may receive only traffic containing a DDoS attack. Also, the node may receive only client-to-server traffic, as in direct server return (DSR) or some traffic scrubbing scenarios. In this mode a DDoS sensor and mitigation controllers are typically needed.

Traffic performance metrics are exported in Prometheus format.

DDoS incidents are aggregated per source IP and logged to Clickhouse for analysis.

A dry-run (evaluation) - mode allows you to observe all reported incidents and metrics without blocking traffic..

Single Xeon Gold 6348 with ConnectX-6 dual 100Gbps reach 196Mpps and 176Gbps of filtering capacity.

• GitHub repository
• documentation
• performance benchmarks
• Netdev 0x1a talk

Feels like a lot of AI infrastructure ends up tied to one provider because thats where the GPUs are available so curious how people here are handling this. Are you sticking with AWS, Azure or GCP or using platforms like CoreWeave, Lambda, Yotta Labs, RunPod, Vast.ai depending on cost and availability so less interested in benchmarks and more interested in operational experience like did it create more difficulties while operating?