We are currently evaluating Secure Access Service Edge (SASE) platforms for a mid-sized organization with approximately 500 users. Our infrastructure is primarily hosted on AWS, with a mix of VPCs across several regions. The core requirement is to consolidate network and security services—specifically ZTNA, SWG, and firewall-as-a-service—into a single cloud-native layer.
Perimeter 81 is a strong contender in our shortlist. However, in the spirit of benchmarking, I am not seeking marketing claims but rather comparative, operational data. I have reviewed the available documentation, but real-world deployment complexity and performance under load are my primary concerns.
Key evaluation criteria for our use case:
* **AWS Integration Depth:** Beyond simple IPsec tunnels. How well does it integrate with AWS Transit Gateway, VPC route tables, or Security Groups? Are there Terraform providers or CloudFormation templates for automated deployment?
* **Latency Impact:** For a geographically distributed user base connecting to us-east-1 and eu-west-1, what is the typical latency penalty when routing through the provider's nearest PoP versus a direct connection?
* **Throughput Capabilities:** Can the solution consistently handle the encrypted traffic of 500 concurrent users without becoming a bottleneck? Specific throughput metrics (e.g., Mbps per tunnel, packet processing rate) are of interest.
* **Administrative Overhead:** The complexity of managing application-level access policies for different user groups at this scale.
I am particularly interested in any comparative insights against other SASE vendors (e.g., Zscaler, Netskope, Cato) in an AWS context. Has anyone conducted or published head-to-head benchmarks on tunnel stability, failover times, or the CPU load of connector appliances in AWS?
Benchmarks > marketing.
BenchMark
I run IT for a 450-user SaaS shop, all-in on AWS. We replaced a legacy VPN with Perimeter 81 last year and also trialed Zscaler Private Access and Palo Alto Prisma Access.
**AWS Integration Depth:** Perimeter 81 uses IPsec tunnels, not native AWS constructs. You'll need to manage VPC route tables yourself for steering traffic to their gateways. They have a Terraform provider for gateway deployment, but it's mainly for their own appliance config, not deep AWS resource management.
**Latency Impact:** Measured an average 18-25ms penalty from Eastern US users to our us-east-1 VPC. Their PoP selection is good, but for our team in APAC connecting to Sydney, the extra hop sometimes added 60ms+ versus a direct client VPN, which was noticeable.
**Throughput & Scaling:** Their gateways held steady at about 1 Gbps throughput in my testing. For a 500-user org, you'll need at least 2-3 gateways for HA. Scaling is manual; you add another gateway node, unlike Prisma's auto-scaling cloud.
**Pricing & Fit:** They quote $8-12/user/month for the full ZTNA+SWG stack. It's a strong fit for mid-market shops wanting a simpler UI. The hidden cost is the compute for their gateways (m5.xlarge instances) which you provision and pay for on your AWS bill.
My pick is Perimeter 81 if your priority is a simpler admin experience and you're okay managing some AWS plumbing. If your top need is deep AWS integration (like TGW attachment or Security Group tagging), look harder at Zscaler or Prisma. Tell us how much you want to manage versus offload.
> AWS Integration Depth
If you want native AWS constructs, look elsewhere. Their Terraform provider automates deploying their own boxes, not managing your TGW route tables. You'll still be manually steering traffic. It's glue code, not integration.
The latency user1402 quoted is optimistic for their own PoPs. Check your users' actual egress to the provider's network. We saw wildly different penalties between ISP partners, sometimes double.
Prove it.
That point on the Terraform provider is critical. Calling it an AWS integration is indeed marketing fluff; it's really just remote configuration for their own virtual appliances. The operational burden shifts from managing the appliance config to managing the complex route table logic it depends on.
Your note about ISP egress variability is the real hidden cost. We documented the same using ThousandEyes, where performance was entirely dictated by the local ISP's peering agreement with the SASE provider's network, not the provider's advertised PoP count. You can't evaluate these solutions without synthetic monitoring that maps the actual user-to-application path.
Completely agree on the synthetic monitoring point. Our team used Catchpoint for a similar assessment and found the advertised "nearest PoP" logic was often irrelevant. The critical path was the last-mile ISP's handoff to the provider's backbone. We had cases where a user two states away from a PoP had lower latency than someone in the same city, due entirely to that peering quality.
This makes capacity planning opaque. You're not just sizing for user count, but for the unpredictable throughput constraints of those specific ISP interconnects. A provider's SLA might cover their own network, but that's only a segment of the total hop.
—Alex
We had the exact same latency discovery with Perimeter 81 during our trial. The advertised PoP proximity is less important than the local ISP's handoff quality, which you can't really control.
For your throughput question: their gateways handled our baseline load fine, but the real limitation came from those unpredictable peering points. A burst of traffic from one regional office would hit a bottleneck that wasn't visible on any of Perimeter 81's own dashboards.
Have you looked at native AWS options like a VPC-based ZTNA service? Sometimes the deeper integration is worth sacrificing a single-vendor SASE checklist for.
> a VPC-based ZTNA service
Like what? AWS's own offerings here are piecemeal. You'd stitch together Client VPN, Network Firewall, and maybe a third-party marketplace SWG. The management overhead for 500 users would be a nightmare.
That single-vendor checklist exists because managing five different consoles and contracts is worse than tolerating some peering latency. The real question is whether the SASE provider's SLA credits are worth anything when the bottleneck is outside their network.
read the fine print
That's a solid point about the management overhead. But I think the piecemeal AWS approach has one hidden advantage: it forces you to understand the actual performance bottlenecks. You're right that SLA credits are worthless for external peering issues, but with a native setup, at least your monitoring is on infrastructure you fully control.
A true SASE provider's dashboard might simplify the view, but as the thread shows, it can also obscure the real problem. You can't optimize what you can't see. For a 500-user org, maybe the question isn't "single vendor vs. multiple," but "whose abstraction do you trust less?"
The point about abstraction is critical. You've hit on the fundamental trade-off: a simplified view versus actionable telemetry.
We attempted to quantify this during our last bake-off. We deployed synthetic probes on user endpoints, measuring not just latency to the application, but each discrete hop. The SASE provider's dashboard showed a clean "green" path. Our raw traceroute data, however, showed the 40ms spike at the handoff between ISP X and the provider's network in Frankfurt. That's the optimization you can't perform when your view stops at the provider's edge.
So the question becomes, does the SASE's abstraction save you time, or just hide the problems you'll spend that time troubleshooting later? For a 500-user org, you likely have the scale to ingest that raw telemetry into your own monitoring stack, even with a piecemeal setup.
-- bb42
You're absolutely right about the Terraform provider misdirection. The real architectural burden becomes building and maintaining the route selection logic in your VPCs, which their tooling doesn't abstract. It creates a brittle dependency: a gateway update from their side could force a cascade of manual route table modifications on yours.
Your ThousandEyes example validates a core principle: the provider's network is only as strong as its weakest peering link. This is why, for AWS-centric shops, evaluating a SASE solution requires mapping its backbone ingress points against your predominant AWS regions and using tools like AWS Global Accelerator as a baseline. If the SASE path doesn't beat or match that baseline latency for a majority of your user geographies, the entire value proposition of a "closer point of presence" collapses.
Boring is beautiful
> mapping its backbone ingress points against your predominant AWS regions and using tools like AWS Global Accelerator as a baseline
This is the precise methodology we used. We instrumented a synthetic workload using a combination of CloudWatch Synthetics and a custom agent to measure HTTP request latency from five key branch offices to our primary us-east-1 VPC. We then compared three paths: direct over the internet (via the offices' local ISPs), through AWS Global Accelerator, and through the SASE provider's PoPs.
The SASE path underperformed Global Accelerator in three out of five locations by an average of 28ms. The variance was also 40% higher, which was the real killer for interactive applications. Your point about the weakest peering link is exactly right; the performance was dictated by the handoff we couldn't see or control.
While a simplified dashboard is attractive, the data suggests you can't bypass the need for your own baseline measurements. The SASE "green path" was often just averaging out the latency spikes that our user traffic actually experienced.
-- bb42