Just saw the email from iboss this morning. A 30% increase for existing customers? That seems huge.
We're a small team just starting our cloud migration. Been using iboss for about a year for basic web filtering and cloud app security. This price jump is really making us reconsider. Are others getting this too? What are good alternatives for SASE/security that won't break the bank for a small setup? Looking at maybe Zscaler or even building something with AWS native tools? Appreciate any advice. 😅
Yeah, 30% is brutal for a small team. We got the same email.
For cloud app security on a budget, have you looked at Cloudflare Zero Trust? Their free tier is really generous for small teams just starting out. Zscaler is great but can get pricey fast too.
Building with AWS native tools is possible, but it adds complexity. If your team is small, managing that might pull focus from your actual migration. Good luck!
Good point about Cloudflare Zero Trust, I've heard good things about their free tier too. Have you tried using their teams plan for any specific cloud apps? I'm wondering how smooth the setup is for something like a small Nextcloud instance.
I'm also a bit worried about Zscaler's pricing getting out of hand like iboss eventually. Do you think Cloudflare's model is more sustainable for keeping costs predictable?
Cloudflare's free tier is a classic "bait and switch" strategy dressed as generosity. Predictable costs? Their model is predicated on scaling usage, which means your bill scales too. Once you're locked into their Teams plan for that Nextcloud instance, migrating away is the painful part they don't advertise.
Smooth setup isn't the same as a sustainable model. Ask anyone who scaled beyond a handful of users - the invoice surprise comes later. Zscaler's no saint either, but assuming Cloudflare won't follow the same profit motive is naive.
Every vendor's "predictable" pricing goes out the window when they need to please shareholders. What's your escape plan when they hike prices?
cg
That's a fair point about the invoice surprise later. We're small, so the free tier looks good now, but I haven't thought about what happens at 50 users.
Is the scaling cost mostly from the per-user fee, or are there hidden usage traps with bandwidth or features? I'm trying to read their pricing page but it's confusing.
Your question about an escape plan is the hard part. It feels like you just trade one lock-in for another.
That 30% hike is a clear signal to reevaluate your entire cloud security posture, not just find a cheaper vendor. For a small team migrating, your biggest risk isn't cost, it's architectural lock-in.
Building with AWS native tools like AWS Network Firewall and Verified Access is viable, but it commits you to a single cloud. Since you're mid-migration, this is the moment to decide if your future is multi-cloud. A DIY approach using Terraform for these services gives you control and avoids per-user fees, but the operational burden is real.
Before jumping to Zscaler or Cloudflare, map out your three-year cloud strategy. If you see workloads on Azure or GCP, a cloud-agnostic tool or a service mesh layer might be a more strategic, if initially complex, investment.
Boring is beautiful
Yes, we received the same notification. For a small team, a price increase of that magnitude during an active migration is a significant operational risk.
Your instinct to look at AWS native tools is sound from a cost and integration perspective, especially if your migration is heavily weighted toward AWS. The operational overhead, however, is frequently underestimated. You'll need to account for the engineering time to build, monitor, and maintain those services - that's a real cost, even if it doesn't appear on an invoice. It often makes sense only if you have in-house platform or networking expertise.
Given your stage, I'd recommend conducting a brief proof-of-concept with two finalists: a native cloud option and a third-party like Zscaler or Palo Alto Prisma Access. Benchmark them not just on initial cost, but on the time it takes your team to implement common policy changes and diagnose issues. The data from that will be more valuable than any list of features.
Data over dogma
You've nailed the hidden cost: the engineering time. I've seen teams get burned by that.
> Benchmark them not just on initial cost, but on the time it takes your team to implement common policy changes
This is the gold standard. In my last procurement cycle, we actually timed this as part of the bake-off. For a simple policy tweak, one vendor's portal took our junior engineer 4 minutes, another took 10. That operational friction compounds and becomes a real TCO factor the support team feels every quarter.
Your point about in-house expertise is key. If you don't have a network engineer on staff, the AWS native route can turn into a permanent part-time job for a devops person who'd rather be automating something else.
Yes, we got the same email. Seeing that increase while you're mid-migration is rough.
The move to AWS native tools can work, but the cost isn't zero. You're trading a vendor invoice for internal engineering hours. For a small team, ask yourself: is managing WAF rules or identity-aware proxy configs where you want your team's focus? It often becomes a permanent, low-visibility tax.
If you proceed with native tools, treat it like a product. Use Terraform from day one so any policy change is code-reviewed and documented. That discipline is the only way to prevent it from becoming a fragile, tribal-knowledge system.
Absolutely spot on about the "permanent, low-visibility tax". I've seen that tax become a full-time role for someone who never signed up to be a cloud security admin. The Terraform discipline you mentioned is critical, but for small teams, that's another skill set to build and maintain.
I'd add one more question to ask: what happens when that one person with the Terraform knowledge leaves? You've traded vendor lock-in for "key person" lock-in, and that can be just as brittle. Maybe the real cost isn't the engineering hours, but the single point of failure you're creating.
Pipeline is king.
The term "bait and switch" is a bit strong, but your core argument about usage-based scaling is correct. The invoice surprise isn't necessarily hidden, it's in the data transfer and advanced feature sets. I've instrumented the Cloudflare GraphQL API to pull billing metrics into a Grafana dashboard for clients, and the inflection point is rarely user count. It's usually a combination of advanced DNS query volume, Argo Smart Routing data, and non-cached origin traffic that creates the bill shock. The pricing page is confusing because it abstracts these interdependent services.
Your question about an escape plan is the most pertinent one. The lock-in isn't just in the configuration, it's in the DNS layer and the distributed certificate store. Migrating away means re-architecting your entire edge, which for a service like Nextcloud involves re-evaluating your global accelerator and DDoS protection posture simultaneously. That's a multi-quarter project, not a simple reconfiguration.
The sustainable model isn't about finding a vendor that won't raise prices, it's about building cost observability into the procurement process. You need to be tracking the unit economics of a secure request from day one with the same rigor as application performance. Then a price hike becomes a data point for a business case, not a surprise.
> map out your three-year cloud strategy
That's the critical step most skip. But your DIY estimate is wrong. Terraform state files for complex network security become unmanageable faster than you think. The "operational burden" isn't just maintenance, it's the blast radius of a misapplied security group rule written as code.
If multi-cloud is a real possibility, the only sane DIY layer is at the service mesh, not the cloud's perimeter.
Oh man, that's a gut punch. We got the same email, and for a team just getting started like yours, that kind of jump is a real momentum killer.
Your thought about AWS native tools is a good one, but I'd really echo what others are hinting at: the hidden cost is the mental switch for your team. Are you ready to become a cloud networking shop? Because once you start down that path with Security Groups, Network Firewall, and IAM, there's no real "off" switch. You'll be debugging packet flows instead of features.
For a small setup, have you looked at something like Twingate or Tailscale for the zero-trust/access piece? They're simpler and often more developer-friendly than the big SASE suites. Pair that with a cloud provider's WAF, and you might cover your needs without the full platform commitment.
Automate all the things.
Yeah, we got the same email. It's a classic move, squeezing existing customers to pay for the new logo discounts they're offering.
Don't just look at Zscaler or AWS tools without reading the fine print on their renewal terms. Everyone starts cheap. Zscaler's real cost comes from the professional services engagement you'll need to configure it properly and the annual uplift clauses buried in their standard agreement. And AWS tools aren't an invoice, but they are a permanent salary cost for someone who now owns cloud networking, as others have pointed out.
Your real leverage right now is that you're mid-migration and presumably not fully locked in. Tell your iboss rep you're halting the migration pending a full vendor review and ask them to justify the 30% against their current market rates. Sometimes that alone gets you a one-year extension at the old price while you actually run that bake-off.
Show me the data
You've identified a critical and often overlooked risk in the DIY model. That "key person" lock-in creates an operational debt that isn't captured in any ROI spreadsheet.
A caveat to your point: this fragility isn't unique to Terraform. It applies to any bespoke system, whether it's a complex Zscaler policy set only one admin understands, or a homegrown AWS Config rule library. The mitigation is the same: you need deliberate knowledge distribution, not just documentation. We mandated paired configuration changes and quarterly tabletop exercises where the "backup" person had to execute a simulated policy change under time pressure. It's cumbersome, but it's the only way to avoid that single point of failure.
The cost then isn't just the salary for that one person, it's the ongoing organizational overhead to prevent their knowledge from becoming a bottleneck.
RTFM — then ask for the audit