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!

Something I've been thinking about a lot lately like regular web apps putting everything under one cloud account makes things pretty simple but AI workloads have very different needs like GPUs, high-speed storage, special networking setups, specific regions and different types of hardware.

I've seen people use services like AWS, Azure, GCP, CoreWeave, Lambda, Yotta Labs and others in all sorts of ways so just wanna know how people view this problem here

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?

Google reports that Gemini 3.5 Flash Cyber can search many code paths cheaply and find unique vulnerabilities in complex systems. In a large cloud estate, faster discovery can create a queue that spans services, owners, regions, dependencies, and maintenance windows.

The bottleneck becomes reproducing the flaw, identifying the affected deployments, testing a fix, coordinating rollout, and proving that the remediation did not break another tenant or workload.

Should cloud security agents be judged on verified remediation time rather than findings produced? Which part of the patch pipeline is least ready for a large increase in valid machine-generated reports?

Source: https://deepmind.google/blog/introducing-gemini-3-5-flash-cyber/

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 😅

[ Removed by Reddit on account of violating the content policy. ]

I am finding it difficult to manage my cloud networks across different locations. Keeping everything connected, secure and easy to update is a major challenge I face. My cloud network needs changes and it is getting hard for me to maintain a good performance while adding new resources, also I am also thinking about trying neevcloud. Now I want a solution that will help me create a cloud network that can adjust according to my business needs. What can be used to build flexible cloud networks that adapt as their needs change? EDIT: Thanks for the advice. Building around reusable patterns seems like the best long term approach.

GigaCloud has agreed to a $2.75 million settlement with investors and eligible shareholders can still submit late claims.

The settlement resolves claims that GigaCloud misled investors about the authenticity of its marketplace revenue and the use of artificial intelligence in its operations.

The case focused on allegations that GigaCloud presented itself as a fast-growing, AI-powered B2B e-commerce platform while failing to disclose that a significant portion of its revenue came from undisclosed related-party transactions involving insiders. After reports raised concerns about the company’s financial reporting, $GCT dropped nearly 19%, and investors filed a lawsuit.

If you purchased $GCT shares between 2022 and 2023, you may be eligible to submit a claim. Late claims are currently being considered, so check your eligibility here.

Not the demo. Not the pilot. The production deployment six months in.

I've been part of enough of these to notice the patterns. Here's what actually goes wrong, in order of how often it happens.

The process wasn't documented before the agent touched it. Everyone assumed the AI would figure out the workflow. It didn't, because the workflow lived in someone's head. The agent did something technically correct that was operationally wrong, and nobody caught it for three weeks.

The agent had too much permission from day one. Not because anyone was careless, but because scoping permissions felt like it would slow down the pilot. So the agent could touch things it never should have touched, and eventually it did.

Nobody decided who owns it when something goes wrong. The team that built it says it's an ops problem. Ops says it's an AI problem. The model gets blamed. The real issue is that nobody drew the accountability line before go-live.

The monitoring stopped at outputs. Teams tracked whether the agent completed the task. Nobody tracked whether the task should have been completed the way it was. Small errors compounded quietly for months before anyone noticed the pattern.

The success metric was usage, not outcomes. Someone measured how many times the agent ran. Nobody measured whether the business result improved. Six months in, the agent was running constantly and delivering marginal value.

None of these are model problems. Swapping to a better model fixes none of them. They're process and governance problems that happen to involve AI.

What's the failure mode you've run into that nobody warned you about?

Is the rise of cloud computing, the reason for the popularity of docker/vm?

Cloud risk used to be mostly uptime, cost, latency, vendor lock-in, and regional availability.

AI adds a messier layer.

If a product depends on frontier models, the real dependency map now includes:

• API availability
• release restrictions
• export controls
• model deprecations
• water and power constraints
• data-center politics
• fallback quality
• inference cost spikes

That means AI architecture is starting to look more like supply-chain planning than normal SaaS integration.

The mistake is treating "call the best model" as a durable architecture.

The better architecture probably needs routing, fallbacks, local modes, quality tests, and logs that explain why a model was used for a task.

Are teams actually planning for model unavailability, or are most AI products still one outage away from being exposed?

Been reading up on how Indian enterprises are approaching the DPDP Act from a technical standpoint, specifically around moving away from perimeter-based security toward a Zero Trust model on Azure. The core idea seems to be treating every access request as unverified by default rather than trusting anything inside a network perimeter, which maps fairly well to a lot of what the Act expects around consent handling, data minimisation, and breach reporting.

Curious what others here are seeing in practice — are teams actually re-architecting their identity and access setups for this, or is it more about layering on monitoring and hoping the existing setup holds up? Also wondering how this compares with how GDPR compliance was handled a few years back, since a lot of the language sounds similar but the enforcement structure seems different.

Found this write-up that goes into the specifics if anyone wants more detail: https://cloud9infosystems.in/dpdp-act-compliance-cloud-security-azure-zero-trust-india/

Cloud teams usually think about reliability as uptime, latency, failover, cost, and capacity.

AI is adding another layer: regulatory reliability.

If a model can become unavailable because of export controls, safety reviews, or national-security concerns, then production AI systems need to treat model access like any other dependency risk.

That means:

• fallback models
• multi-provider routing
• local inference where possible
• clear data boundaries
• degraded modes
• documented model replacement plans
• cost and latency tests before the emergency

The issue is not only "which model is best?"

It is "what happens to the product if that model is unavailable tomorrow?"

Cloud architecture for AI is starting to look less like API integration and more like supply-chain risk management.

Are teams taking model availability seriously enough as an infrastructure risk?

SoftBank announced SB Neo for US AI cloud services. Meta is reportedly exploring a cloud business to sell excess AI compute.

We currently send all blob.core.windows.net traffic on our internal network from our on-prem DC up to an Azure PDNS Zone via private link. We've recently had a requirement to send traffic out to public DNS for a single storage account that a supplier uses. Lets call it storage01.blob.core.windows.net for the sake of this question.
I want to avoid enabling the 'fallback to internet' feature on the Virtual Network link, is there a convenient way for me to route just the storage01 traffic out to public DNS using just the available settings on the PDNS Zone/VNET Link or do I have to eat my vegetables and do this on our DC (I also want to avoid that).

I've noticed that a lot of people starting their cloud journey struggle with AWS networking. Concepts like VPC Peering, Transit Gateway, route tables, and networking in general can be pretty confusing at first.

So I decided to start a series where I explain these topics in a beginner-friendly way, with diagrams and real-world examples.

The first article covers Transit Gateway vs VPC Peering—when to use each, the trade-offs, costs, scalability, and common use cases.

I'd love to hear your feedback and suggestions on what networking topic I should cover next.

https://www.cloudarena.io/blog/transit-gateway-vs-vpc-peering