Zscaler Zero Trust Cloud Architecture

Welcome to Zscaler Zero Trust Cloud Architecture! In this module, discover what makes
up the Zscaler Zero Trust Exchange, what the “Zscaler Cloud” is, and how it is built to
scale.
MODULE OVER VIEW

Introduction

Learning Objectives

ZER O TR UST AR CH ITECTUR E

Zscaler Zero Trust Exchange Overview

ZSCALER CLOUD AR CH ITECTUR E

Multi-Tenant Architecture

Major Architectural Advantages

B UILT TO SCALE
 The Largest Inline Security Cloud

SUMMAR Y

Recap
Section 1 of 7

Introduction

In this module, see how organizations can unlock

the power of Security Service Edge (SSE) using
Zscaler’s Zero Trust Exchange. Explore how our
cloud is designed and architected to provide an
unparalleled customer experience. Dive into the
three major components of the Zscaler Cloud, the
technology that powers it, and its ability to scale.

C O NT I NU E
Section 2 of 7

Learning Objectives

By the end of this module, you will be able to:

1 Discover the need for digital transformation and how Zscaler’s Zero Trust Exchange
securely protects organizations on this journey

2 Identify the three major components that make up Zscaler’s Cloud Architecture

3 Recognize Zscaler’s patented technologies that power the Zero Trust Exchange

4 Describe how Zscaler’s Cloud Architecture is built to scale

L E T ' S G E T S TA R T E D
Section 3 of 7

Zscaler Zero Trust Exchange Overview

The Need for Digital Transformation

Hub-and-Spoke network and Castle-and-Moat security architectures served organizations well for
many years when employees were at one central location and on one central device.
 Click image to enlarge
However, many organizations are experiencing digital transformation today, and often we find that
most still have a traditional network and security architecture dependent on deploying firewalls and
VPNs.

These legacy architectures cannot scale and support the shift to cloud, mobility, or work-from-
anywhere in the hybrid world we live in today. This leaves many organizations exposed to
increasingly sophisticated cyber threats and attacks.

This shift from legacy architecture to the cloud creates many customer challenges. Click each card
below to view the top three challenges Zscaler sees customers addressing.

Attack surface with firewalls

and VPNs that bad actors
can exploit
Exposure to lateral threat
movement
Threats in encrypted traffic
 Multiple networking &
security point products
Operational overhead to
integrate & maintain
Slow and costly to adapt
and grow

Poor user experience

backhauling cloud traffic
through the data center
Limited visibility into end-
to-end experience

The Zscaler Zero Trust Exchange

From these challenges, Zscaler recognized that a new architectural approach was required using
the principle of Zero Trust security and created the Zscaler Zero Trust Exchange platform.

The Zero Trust Exchange is a cloud-native platform that powers a complete Security Service Edge
(SSE) to connect users, workloads, and devices without putting them on the corporate network,
following the concept of "never trust, always verify."
By applying the principle of Zero Trust, we eliminate the challenges discussed early. Click each card
below to see how:

Eliminates attack surface

Eliminates lateral threat
movement
Blocks threats in encrypted
traffic

Replaces multiple
networking & security
point products with
secure cloud-based
connectivity
No Hardware/Software
to integrate & maintain
Lowers infrastructure
costs and improves
 Direct-to-cloud
connectivity lowers latency
and improves user
experience
Provides end-to-end
visibility and troubleshooting
of user experience

The Zero Trust Exchange is now the world’s largest security cloud enabling secure digital
transformation journeys for organizations' users, workloads, and devices by combining our core
platform offerings shown below.

This complete and secure digital transformation journey through the Zero Trust Exchange, however,
would not be possible without the power of the Zscaler Cloud. In the next section, let’s explore
what the Zscaler Cloud is, how it is architected, and why that is important.
Zero Trust
To learn more about Zero Trust and Zscaler’s Zero Trust Exchange, visit our website by clicking the
button to the right.
GO TO WEBSITE

Zscaler SSE at a Glance

To learn more about the benefits of Zscaler Security Service Edge (SSE), visit the datasheet by
clicking the button to the right.
GO TO DATASHEET

C O NT I NU E
Section 4 of 7

Multi-Tenant Architecture

Multi-Tenant Cloud Architecture

Zscaler can manage, scale, and power the Zero Trust Exchange due to our multi-tenant cloud
security architecture that is separated into three levels:

1 Central Authority = The Brains

2 Enforcement Nodes & Brokers = The Engines

3 Logging Services = The Memory

Click each marker below to view what each level does and the benefits they provide.
  
 

Central Authority

The Central Authority (CA) is the brain and nervous system of the Zscaler Cloud. It monitors the cloud and
provides a central location for software and database updates, policy and configuration settings, and threat
intelligence.
Benefits:
Centralized policy management
Stores customer’s chosen user management solution
Provides a centralized console for unified visibility
 

Enforcement Nodes & Brokers

Enforcement Nodes & Brokers are the engines for the Zscaler Cloud. Included as part of the engine is
Zscaler’s Public Service Edges.
Public Service Edges are full-featured, inline internet security gateways that inspect all internet traffic bi-
directionally for malware and enforce security and compliance policies and are always deployed in active-
active load balancing mode worldwide.
Benefits:
Available worldwide for all customers
Policy Enforcement Engine
Provide capabilities for SSL Inspection
 

Logging Services

Logging Services are the memory for the Zscaler Cloud. Nanolog clusters store transaction logs and provide
reports. Each cluster consists of one active server and two servers in passive standby mode.
Benefits:
Logs can be stored in the customer's region of choice
Enables streaming for customer retention policies
No limitation to the number of logs stored

Understanding these levels and how the Zscaler Cloud “thinks” when planning with your customer
is essential. This ensures that you will accurately identify and position the Zscaler solution while
feeling confident that you will get consistent and predictable outcomes.
In the video below, hear Brian Deitch, Chief Technology Evangelist at Zscaler explain how these
areas work together to enable the world’s largest security cloud.
Click here for a transcript of the video. –
What's up everybody, my name is Brian Deitch, today we are going to talk about the Zero Trust
Exchange but more importantly, the zero trust architecture that we do. So first and foremost, we
have three tiers that we have going on. The first one is going to be the central authority or the CA.
The next one will be the Service Edge or Zen, some of you might know it by that, and last but not
least, we have the logging plane.
So when we talk about the Central Authority, that's really the brains of the operation. That's where
the centralized policy management exists. This stores the customer's chosen user management
solution and provides a centralized console for unified visibility.
If you think about it, when you log into the Zscaler Cloud and you're doing administrative tasks,
you're logging into the Central Authority. When you're doing API-based stuff talking to the
Central Authority, that's the brains of the operation.
We also have the Service Edge. We aligned that terminology with Gartner for the Secure Service
Edge, or the Zen, depending on the documentation that's out there you're going to see.
So Service Edge or Zscaler Enforcement Node is kind of like the brawn of everything that we do.
This is available worldwide for all of our customers, it is the policy enforcement engine, and last but
not least this actually provides all the capabilities for SSL Inspection.
What you should know about this is we have about 150 points of presence for all of our Service
Edges there. When we have a user that's connecting, it really doesn't matter where they're coming
from, as long as we can get them to the closest Zscaler Enforcement Node that's out there. So
maybe that's Los Angeles, or maybe that is over here in London.
What's actually kind of cool about this is when this user logs in, the Zen and the CA are always
talking. There's this user who comes through and says hey, I want to talk to yahoo.com. We
dynamically steer them to the closest Zscaler Enforcement Node, and then the Enforcement Node
is going to talk to the Central Authority and pull down the user's policy. It does this for every single
transaction that's going through, which is pretty wild. It's a 192 bitmap type of policy that is
enforced, and it's really neat.
What's even cooler about this is as that user goes out to yahoo.com, we take that policy, we
discard it, it's over with, and we don't store it there. As a user goes out to maybe Dropbox, the
Enforcement Node is going to reach over here to the Central Authority and pull that down for
every single transaction. Why is that important?
Well let's say that there's a nefarious website that's out there, we'll call it briandeitch.com. Let's say
that all of your users have the access to talk it. In a non multi-tenant architecture, you'd have to
kind of push that policy out to all 150 points of presence, and it's not like I just have a really big
server right?
I have thousands upon thousands of little worker bees in every one of these data centers that are
out there. That could take a long time. So by constantly doing this pull of the policy, when you
make a change it's instantaneous. That's why when you're in the Zscaler UI and you save it, it is like
two or three seconds after you're done. That's how the enforcement is done.
And last but not least we have the logging services or NSS and this is really the memory. Those
users are flowing through and they're doing things, we have to be able to log that information.
What's neat about this solution, logs can be stored in the customer's region of choice, and enable
streaming of the customer's retention policies. There's really no limitation on the number of logs
stored. There is a time though, and by default, this is six months of logs that are stored.
To connect the dots, when I do talk about the Service Edge or the Zen being the enforcement
portion of this, just know that that's exactly what's going on here. That we have activity here and
this connectivity right here across all things.
Same thing with the logging, and this helps us get away with doing things at line rate, very very
quickly. This is why our architecture fundamentally is different than taking a legacy firewall and
spinning it up in some commodity Cloud.
Every single one of our data centers, largely, is going to be in an Equinox facility for the US and
abroad, then you're mileage may vary depending on the Middle East, India, or mainland China.
Rules and regulations might dictate that we run in other different data centers.
With that said, that is a Zero Trust Architecture.

Zscaler Cloud Architecture

For more information on Zscaler’s Cloud Architecture, visit our help article at the button to the right.
GO TO ZSCALER HELP

C O NT I NU E
Knowledge Check

The Zscaler Cloud is made up of which three components? (Select 3)

Enforcement Nodes & Brokers

SSL Inspection

Central Authority

Private Application Inspection

Logging Services

SUBMIT

C O NT I NU E
Section 5 of 7

Major Architectural Advantages

Major Architectural Advantages

Now that you have learned how the Zscaler Cloud was architected using a three-tier model, let’s
talk about how the design impacts the customer experience.

There are two main areas that differentiate Zscaler and our Cloud Architecture: Public Service Edge
Location and Single Scan Multi-Action. Let's take a look at each of these in more detail.

Differentiator 1: Public Service Edge Location

There are typically two common data center locations used with cloud architectures: compute and
transit provider data centers. Click on each tab below to learn the difference between the two.

COMPUTE DATA CENTERS TRANSIT PROVIDER DATA CENTERS

Compute Data Centers are not located on the internet backbone and typically act as a destination
for traffic. Examples of Compute Data Centers would be Azure, Google Cloud Platform (GCP), and
AWS. Other SSE vendors often ask customers to maintain their offerings in this environment. This
data center location presents challenges for organizations.
Architectural Challenges
Latency
Vendors that require their customers to deploy their SSE architecture in a Compute Data Center lose
out on the peering and direct internet backbone access. As user traffic is sent in and out of these
Compute Data Centers, latency becomes a concern and can noticeably impact the reliability and
overall experience. For example, video conferencing services like Teams and Zoom.
Configuration
Customers must configure IP addressing and routing within the Compute Data Center environment.
The routing configuration includes implementing Border Gateway Protocol (BGP) through all
customer locations and the vendors' cloud instances.
Maintenance
Customers that invest in this type of design are responsible for maintaining a unique set of virtual
appliances in every Compute Data Center they are installed in. Policy updates and software
upgrades that need to be done are the customer’s responsibility and not the SSE vendor itself.

COMPUTE DATA CENTERS TRANSIT PROVIDER DATA CENTERS

Transit Provider Data Centers are uniquely positioned to have direct access to the internet. Zscaler
adopted this transformational approach that eliminates the challenges presented by Compute Data
Center designs.
Zscaler Public Service Edges, where policy enforcement occurs, have been strategically placed
globally in Transit Provider Data Centers. This means that a user’s traffic, once the policy has been
applied by the Public Service Edge, is placed directly onto the internet.
Through numerous Public Peering Exchange Points, Zscaler’s Public Service Edges are usually just
one hop away from thousands of SaaS providers.
Architectural Benefits
Latency
Zscaler’s peering design eliminates additional hops, lowering unnecessary latency and improving the
user experience. For time-sensitive applications like Zoom and Microsoft Teams, this is crucial.
Configuration
Customers are not required to maintain IP Addressing or Tunnel configuration within the Zscaler
Cloud.
Maintenance
Zscaler’s Cloud Architecture removes the burden of maintaining several unique stacks of virtualized
security appliances. Customers no longer have to manage storage for logs, determine compute for
the virtual devices, and maintain updates.
To visualize this design, let’s view a customer’s traffic path to a Zscaler PSE in a Transit Provider Data
Center in the image below.

Now that you know the difference between transit provider and compute data centers, let's review
and expand on this topic by watching Brian discuss Zscaler's data center vs legacy.
Click here for a transcript of the video. –
Hey team, I'm back. This time we're going to talk a little bit around us versus them. When we
talked about that it really means the Zscaler Cloud versus how the legacy vendors do it, and some
of our architectural differences that really help us when achieving scale, performance, reliability, and
upleveling security.
So first and foremost, when we talk about our 150 points of presence, they're all in Equinix's
facilities for the most part.
Now I would say your mileage will vary once we start getting out of the US. Specifically around the
middle east, maybe India and mainland China, local government rules we have to abide by.
The other one is that we're actually using our own purpose-built hardware. So we actually have
actual boxes, we are not virtualizing anything. It is purpose-built as well. It's also a tool or a service
that is born in the cloud, and last but not least there is no BGP.
A big point of emphasis on that would be - when you look at over 150 points of presence, if we're
not doing some sort of weird BGP mesh, that really means that you can't have this operational
accident where maybe someone fat fingers a configuration and then all of a sudden, 100% of our
entire world's traffic is now being routed through Los Angeles. That'd be very bad.
When we started looking at some of the legacy people out there, they're not standing stuff up in
actual data centers. They're virtualizing there, they're leveraging stuff like GCP.
It is nothing more than an old firewall but virtualized, which is silly. It's not purpose-built at all.
Not only taking this thing that they're trying to virtualize, they're throwing it up in the cloud, but
they don't get all the benefits of having their own actual hardware and being able to tie into it. It is
100%, not cloud-native right this thing was running back at the legacy data center and now
they're moving it over here. And on that, the reality is, I would say even on all three of these
things, it's just VPN. VPN is gross, I don't know about you but I want nothing to do with it.
So a lot of our architecture, we look at this and we're like "Oh we got Zscaler Client Connector and
it connects to that cloud", and then the competition is like "Well you know we have global protect
or we have Prisma and it connects to the cloud", but the way that we do it is significantly more
intelligent. We have multiple tunnels distributing traffic wherever it needs to go, as opposed to
maybe one or only two locations over here with his legacy idea.
Last but not least BGP is a very big thing, And really I kind of stated my opinion on that, I don't like
BGP I think it can introduce some type of risk as far as uptime and reliability. They're honing in on
that, they want to have this big old BGP mesh. Good luck trying to figure out where your users are,
what POP they are coming out of, and troubleshooting that.
That was one of the main architectural advantages of Zscaler. It's our own data centers, running
our own hardware, it's purpose-built, and was born in the cloud.
With all that said. Thank you for your time.

Differentiator 2: Single Scan Multi-Action (SSMA)

Another key differentiator of Zscaler’s Cloud Architecture is how we process traffic at the Service
Edge using a patented single Scan Multi-Action (SSMA) technology.
Let’s look at the differences between traditional service chaining commonly used by vendors vs
Zscaler’s unique Single Scan Multi-Action (SSMA) technology by clicking each tab below.

TRADITIONAL APPLIANCES SSMA TECHNOLOGY

Data packets run through independent inspection engines using service chaining. The packets flow
through separate appliances to apply policies such as URL Filtering, Anti-Virus, and Data
Protection.
The packets can then be sent out to the internet, but only after it has been inspected by every
service. This adds latency for every user, and, as everyone knows, high latency makes for a bad
internet experience.

TRADITIONAL APPLIANCES SSMA TECHNOLOGY

With Zscaler SSMA, users' traffic is processed by Zscaler’s different engines simultaneously on the
same Service Edge using dedicated resources. This ensures no added latency from service chaining,
allowing the Zscaler node to make policy decisions extremely quickly.
Before moving on, let's hear back from Brian Deitch as he discusses Zscaler's SSMA technology.
Click here for a transcript of the video. –
I'm back, and this time we are going to talk about an architectural advantage called Single Scan
Multi-Action.
Now before I describe what that is in the Zscaler world, we have to figure out the problem that
we're solving for. I'm going to pick on my previous company, but the fact remains it is kind of the
same across any other traditional appliance that's out there. So I worked F5 for a number of years,
and the way that I would look at this is that you have a user, our client, and they're trying to get to
some resource - maybe it's a website, maybe it's a server - we'll just put server right here.
So one of the cool things F5 did, when it was first coming out, is they created this awesome proxy
called TMOS, Traffic Management Operating System.
Probably the most compelling thing that they did about this, is they took an SSL acceleration card,
put it in here, and offloaded all the expensive decryption things. What it got them was the ability
to take like a 1U appliance and if they can move 10 gigs per second, even with decryption and
crypto, all that stuff combined, it would move like 9.9 gigs. It did very very well. So what happens?
They get really really popular, everyone's doing the load balancing thing, and eventually, they
became a publicly traded company. What happens and you get publicly traded? You got to
innovate, you got to do different things. And this is where the service chain kind of comes back in
and bites them in the butt.
When we talk about TMOS, they went out and said "Oh you know what, maybe we want to do
different things, maybe we're going to start doing Advanced Firewall Manager". Really what that
means from a user perspective, is this traffic is going to come in and it gets service chained. It
comes up, and then back down into this engine, and then that's not enough.
They need to do other things, so then they go out and they're like "Hey you know what maybe I'll
do Application Security Manager", and again that traffic doesn't flow across it has to go back up,
and then back down. The same thing could be said about other things that they did, so we'll pick
on APM or Advanced Policy Manager.
The fact remains, that this traffic would go in and out of TMOS, over and over again, and every
single time that happened it introduced latency before we get to the server.
So you would look at that 10 gig box, and once you started turning on these different features that
box went from 10 gigs to like two and a half gigs.
What does that really mean? Well, you have to buy bigger boxes. When you're spending on
bigger boxes, more money, more skill, the kind of things you have to deal with.
So with Zscaler, if we zoom in on the Cloud, what we did is we came up with this thing called
Single Scan Multi-Action.
What we did is we virtualized the TCP IP Stack and move that from the kernel into userland.
And one of the coolest things that Jay and the founders did is they came out and were like "You
know what? We believe that cloud is a better solution." But rather than come up with a point
solution and then try to figure out how to service chain it later, Single Scan Multi-Action becomes a
very pluggable architecture. So they came out and said, "You know what? We're gonna do some
SSL, and TLS, and what's going on is that as this traffic is coming through, it's firing off on every
single transaction.
So then you come over here and say okay the market is coming out with URL Filtering. Then as
they grew and got bigger they're like "You know what? Maybe we should be doing some AV
Scanning." And then we get bigger and bigger, and now there are things like ML-based Sandbox.
The list kind of goes on and on, maybe Data Protection DLP.
What's neat about this is as that client is coming through, going into our proxy, whether they're
using one thing or all the things, the proxy latency is always the same - very very predictable and
we fire off on everything all at the same time.
Now not that this matters to the end-user or our customers, but our ability to scale and to dedupe,
very cool things with Single Scan Multi-Action helps us out. If you think about our little 1U pizza
box we're using SSL acceleration as well, but instead of having a one-trick pony and then service
chaining things in and out, we came up with a multi-trick pony, as we introduce new features to be
able to accelerate this traffic very very quickly.
On top of that, if I were to take out our SSL acceleration card, what I can do with that one 1U
appliance without that SSL acceleration card would be like 72 pizza boxes to achieve that kind of
scale. So from an architectural difference, this is how we can take in a lot of traffic, in a very cost-
affordable way of doing it, without introducing latency to the user.
Always remember, that is the customer's flowing through our Cloud. It doesn't matter what you're
doing with us. These things are firing on and off, whether you purchase them or not., s take that
into account. You'll be able to safely secure your business to users all at the same time.
With that said that is Single Scan Multi-Action and our architectural advantage over legacy proxies,
firewalls, and more.
In this section, you learned about two critical differentiators of Zscaler’s Cloud that impact a
customer's experience. In the last section of this module, let’s explore how and why our architecture
is built to scale.

C O NT I NU E
Section 6 of 7

The Largest Inline Security Cloud

An Architecture Built to Scale

Customer internet traffic is growing on an average of 30% year over year, requiring the security
provider to be able to grow to meet those changing demands.

Zcaler’s multi-tiered Cloud Architecture has been designed for scalability and growth.

You learned about how our Cloud is architected and the key areas of this design that set us apart.
Now, let's conclude this module by hearing more about how the Zscaler Cloud scales today.
Click here for a transcript of the video. –
Alrighty team, you've learned a lot about our platform, but let's figure out how to wrap this up for
the customers when we are presenting it to them.
So I would go in this direction. Draw the big bad Zero Trust Exchange and let them know we're
built to scale and why that's important to your business. The big thing is we have 150 points of
presence. We are just like Visa, everywhere you want to be. It doesn't matter where you're at in the
world doing transactions, we've got you.
Another big one that might be news to you and hopefully by the time this video goes live, this
number will actually be even bigger. Cumulative, right around the eight o'clock in the morning hour
on Mondays, we're seeing like 3.7 terabytes per second going through our Cloud.
I want to say I think that number is also right around 93% of the traffic is encrypted. So kind of
keep that in the back of your mind as SSMA being able to be decrypt, and how important that is.
Also, we are going to have right around 40 plus million users on our cloud at any given point in
time. That's cool right? We're moving a lot of good stuff but at the same time, it helps with
visibility and that's that whole cloud effect. If I see something I've never seen before, and I put a
bandaid on it I can blast it out cloud-wide for all customers.
So maybe you're a plumbing company over there on the west coast, and some financial company
gets hit with the zero day. Once we identify that, we block it and that benefit gets pushed out to
all customers.
Last but not least, always hone in on the scale and that the architecture matters. From the Central
Authority to the Zscaler Enforcement Nodes, to the Logging Plane that we have in Single Scan
Multi-Action.
This is the reason why so many customers during COVID moved their business to Zscaler. Being
able to achieve and onboard these customers very very quickly was exponentially satisfactory to
everybody.
One example that I can give you was a SLED customer in California where they had to move
60,000 people onto both ZIA and ZPA. They did this in less than 21 days.
With that said, this is how I would wrap up this section on our ability to scale and meet the needs.
Thank you.

C O NT I NU E

Knowledge Check

What is the name of the patented technology that allows Zscaler to avoid
service chaining?

Proxy Cloud Architecture

Single Scan Multi-Action

Data Protection

Central Authority

SUBMIT

C O NT I NU E
Section 7 of 7

Recap

Zscaler’s Cloud Architecture was strategically built to meet the needs of digital transformation.
Throughout this module, you learned how Zscaler accomplishes this through our multi-tenant
design and advanced technology built to scale.

From this module, you should now be able to:

1 Discover the need for digital transformation and how Zscaler’s Zero Trust Exchange
securely protects organizations on this journey

2 Identify the three major components that make up Zscaler’s Cloud Architecture: The
Central Authority, Enforcement Nodes and Brokers, and Logging Services

3 Recognize Zscaler's patented technologies that power the Zero Trust Exchange
including our Public Services Edges and SSMA

4 Describe how Zscaler’s Cloud Architecture is built to scale

C O NT I NU E

Thank You!