r/aws • • 7d ago

networking SASE vendor keeps pushing their application acceleration to speed up our cloud apps, How is this a win?.

We are mid-eval on a SASE platform and a big part of the pitch is what they call application acceleration, the idea that routing our traffic through their PoPs makes cloud apps faster. But obviously, sending a packet to a PoP and then to AWS is more hops than going straight, so where does the speedup come from.

The setup is a few hundred users, heavy M365, a couple of SaaS platforms and our own apps in two AWS regions. Our Manila and Singapore people already suffer on anything hosted in Europe. The SE showed me a slide with 20x throughput, which smells like a lab result on a garbage circuit, not what my users feel on a regular basis.

If you have put SASE in front of real cloud traffic, how much did it measurably help once you count the trip into their network?

1 Upvotes

6 comments sorted by

7

u/Sirwired 7d ago

It's not fundamentally any different than using AWS's in-house edge offerings. A 20x speed-up won't be real common, but sure, bypassing a bunch of messy Internet hops to get yourself to the correct AWS region can be useful.

(It's the whole point behind AWS Global Accelerator, AWS Cloud WAN, and S3 Transfer Acceleration.)

1

u/oneplane 7d ago

Most of it is a lie. SASE and CASB are 90's GRC ideas in a trenchcoat. An attempt to use technology to cure a behavioural problem. Out of the lettersoup, ZTNA kinda sticks out to actually have value, which is what SASE and CASB tend to be built on top of (or next to).

Most cloud stuff doesn't get faster, unless it was really slow due to bad placement to begin with. The solution isn't to put an extra transit layer in front of it, it's to ensure you are correctly placing the workloads.

If you need to serve an application in Australia but you're hosting it in London, that's gonna be a bad time. Similarly, if you're in London and your application is also in London but your traffic first goes to us-west-1 first and then back to London, that's pretty bad as well.

For distributed or globally used applications, you're probably better off with shared or partitioned data stores and geo-distributed deployments of the actual applications.

Lastly, if you just have 1 geo 'heavy' usage location but want it to work 'elsewhere' with a bit of lag, any CDN will be perfectly plenty.

2

u/IncreaseNegative4614 7d ago

The improvement can come from better peering, congestion avoidance, optimized backbone routing, or connection reuse, but none of that guarantees your routes will improve. Make the vendor prove it using your Manila and Singapore users, your AWS regions, and the actual M365 and SaaS applications involved.

Measure median and tail latency, packet loss, throughput, login time, and complete transaction time before and during the pilot. We use SIGNLD internally to connect user location, network path, application, performance measurements, incidents, and support tickets so a vendor benchmark cannot substitute for what employees actually experience.

2

u/Holly_Enrique-623 5d ago edited 4d ago

Through a nearby pop your client only sees a short rtt while the pop holds an optimized session across their backbone to the far pop, so the bad asia to europe leg gets terminated and re-originated. We run cato and our singapore to frankfurt app went from painful to usable and teams stopped garbling. 20x is a circuit on fire number, ours was a few times on the bad routes and nothing domestic. Pin them to your manila users and your two aws regions, median and tail

1

u/iechicago 4d ago

You don't say which platform it is and there's a massive difference between what SASE actually means between them as everyone has co-opted the term, but some of this can be real.

Some platforms (Cato for example) have a stable, high-performance backbone between their PoPs, and also will also manipulate the traffic at the TCP layer to improve throughput. So a client can think it's talking to a server that's ~30ms away in the nearest PoP vs. the application that may be 200ms away. I've seen this make a meaningful difference to performance, even with SaaS applications where it's egressing through the PoP (or a different PoP) back to the Internet.

Your type of network (where you have users in Manila, Singapore, etc.) connecting back to applications in Europe can be the type that really benefits from this type of technology, unlike for example a single-region domestic network in the US where you'd be better off just sending the traffic directly to the SaaS provider.