# Zoom Meetings Hybrid Explainer

### Zoom Meetings Hybrid Overview

This section provides an overview of the Zoom Meetings Hybrid service module, supported as a Zoom Node workload. For more information about Zoom Node, an overview of the platform is available at the end of this document in the [Appendix](#appendix-zoom-node).

#### <mark style="color:blue;">Zoom Meetings Hybrid is an on-premises hybrid meeting solution that saves bandwidth by redistributing meeting media within a corporate network</mark>

Zoom Meetings Hybrid is an on-premises hybrid meeting solution that acts as an intermediary connection point between a Zoom client and the Zoom cloud. The solution multiplexes and redistributes a meeting’s audio, video, and screen sharing media streams with [up to 400](#each-sfu-immr-supports-up-to-400-standard-definition-or-200-high-definition-user-connections-per-mod) connected participants within the same corporate network. This design reduces the number of external cloud media connections, which can significantly reduce external bandwidth consumption.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfVVVppbW-NhmkwGFDkKpMlcYUACkI-syd0I8Z9QJRs5Jx5cWiavnwIg6ux2KTaXksBeGy6kXWu82mQQIrAUkHY-7V5OWuHkW5G-X_ez2V-_okacRJToZXB2YPpxjYL9tT6BDfT?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt=""><figcaption></figcaption></figure>

#### <mark style="color:blue;">Zoom Meetings Hybrid supports two modes: cloud-hybrid and internal-only</mark>

Zoom Meetings Hybrid supports two modes of operation: a cloud-to-premises hybrid mode known as Selective Forwarding Unit mode (SFU), and an internal-only mode (iMMR) for non-cloud meetings. Meetings are configured for cloud-hybrid connections by default, but can be designated as internal-only when users schedule or edit a meeting. Both meeting types can also be supported by the same module [simultaneously](#meetings-hybrid-can-simultaneously-support-cloud-hybrid-and-internal-only-meetings).

#### <mark style="color:blue;">Cloud-hybrid mode connects users within your corporate network to the cloud through the hybrid module</mark>

In cloud-hybrid mode (SFU mode), users within your corporate network connect to the hybrid module as an intermediary connection point between their client and the cloud. The hybrid module multiplexes and redistributes a meeting’s audio, video, and screen sharing media streams between the users and the cloud.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXc50B_h67Ut7sgvHu6UKbM1przxAdYsmKumIfrvd4gPimstYApeW5szR0HWWPA-m8jPiRLVm1A8826j31BenyVNSy28NaBRLHsfhM5tr9F13-yqaDUFmT5TmyOm5GGmYx0USmCvxg?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt=""><figcaption></figcaption></figure>

<mark style="color:blue;">**Cloud-hybrid meetings do not affect cloud-to-client signaling connections**</mark>

Although the Zoom Meetings Hybrid module can redistribute a cloud-hybrid meeting’s *media*, the module does not handle cloud-to-client signaling connections. Users connected to the Meetings Hybrid module will continue to establish a bandwidth-light signaling connection with the meeting’s cloud server for in-meeting data and operations, like starting a cloud recording or updating the participants list.

{% hint style="danger" %}
**Warning**

Client devices **must** have proxy or default route access to the Internet capable of reaching Zoom cloud services. HTTPS proxy is supported, but devices without access will be unable to connect to meetings.
{% endhint %}

#### <mark style="color:blue;">Internal-only mode connects users to an on-premises meeting, and does not allow participants outside of the network to join</mark>

When a meeting is scheduled as internal-only, the hybrid module acts as an internal multi-media router (iMMR), multiplexing and redistributing a meeting’s audio, video, and screen sharing media between users within the corporate network. These meetings are isolated to the corporate network and **cannot** connect or cascade to cloud meeting servers or services, preventing external network participants or services like cloud recording from joining the meeting.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfKz6ul7kIwWkfMyYF8vjUPA8kZ_oVR-iGTGyojShz0rDy-rnq7VW6AZ4SRV6haB6NkDLwyd6UusHp8dK_Lkym7QM-5jQnAXdPxV3OoMxdwpKvaROL9QRlnCoCFHJ0nLRsjgUx9Gw?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt=""><figcaption></figcaption></figure>

<mark style="color:blue;">**Internal-only meetings route both signaling and media connections through the hybrid module**</mark>

Unlike the cloud-hybrid model, internal-only meetings route both media *and* signaling within the network to the hybrid module. This creates a complete on-premises meeting type, without the possibility of external connections.

<mark style="color:blue;">**Employees outside the corporate network can join internal-only meetings through VPN**</mark>

Employees outside the corporate network can join internal-only meetings while connected to a VPN if the VPN server can communicate with the hybrid module across the corporate network. However, users **must** be signed into their company Zoom account to join.

For example, a remote employee is connected to the company’s VPN from their home network without split tunneling. So long as the user is signed into their company Zoom account and the connected VPN server can communicate with the hybrid module within the corporate network, the remote user can connect to an internal-only meeting remotely.

#### <mark style="color:blue;">Meetings Hybrid can simultaneously support cloud-hybrid and internal-only meetings</mark>

Meetings Hybrid can simultaneously support cloud-hybrid and internal-only meetings, negating the need for separate deployments for each use case.

For example, a company has one hybrid module deployed within their network, with 400 connected users. In this scenario, 200 users can connect to cloud-hybrid meetings, with the remaining 200 users connected to internal-only meetings. For each connected meeting type, the Meetings Hybrid module will respect the intended connection routing: cloud-hybrid meetings will route media through the module and signaling to the cloud; internal-only meetings will route both media and signaling exclusively on-premises.

#### <mark style="color:blue;">Zoom Meetings Hybrid keeps all media on-premises if no external participants are present and all users are connected to the same hybrid module</mark>

If users are connected to a cloud-hybrid enabled meeting through the same Meetings Hybrid module, but no external participants are present, the hybrid module will not transmit media between the Zoom Cloud. Instead, all meeting media will be kept on-premises and routed within the corporate network through the hybrid module. Meeting media will only leave the network after an external participant has joined from the cloud, or if a second hybrid module within the network connects to the meeting.

For example, a group of users within a corporate network are joining the same cloud-hybrid enabled meeting. All users are connected to the same hybrid module and all meeting media is being routed within the corporate network. Once an external user joins the meeting from the cloud, or a second hybrid module connects to the meeting, the hybrid module(s) will open a media connection with the cloud, and redistribute the meeting’s media to and from the cloud.

{% hint style="info" %}
**Note**

Internal users can also establish external media connections if the hybrid infrastructure is [at capacity](#each-sfu-immr-supports-up-to-400-standard-definition-or-200-high-definition-user-connections-per-mod).
{% endhint %}

#### <mark style="color:blue;">Zoom Meetings Hybrid supports end-to-end encrypted meetings for both meeting modes</mark>

Zoom Meetings Hybrid supports [end-to-end encrypted](https://support.zoom.us/hc/en-us/articles/360048660871-End-to-end-E2EE-encryption-for-meetings) (E2EE) meetings in both cloud-hybrid and internal-only meeting modes. This provides an extra layer of security for confidential meetings, and can be paired with internal-only meetings for meetings demanding the highest levels of security available within the Zoom platform.

#### <mark style="color:blue;">Customers can deploy multiple region-specific hybrid zones across their data centers</mark>

Zoom Meetings Hybrid supports multiple zone deployments, allowing customers to deploy separate hybrid environments for different locations or regions. When multiple zones are in place, users will connect to the closest hybrid module based on their ping time to available appliances.

For example, if a business has a New York and Los Angeles office, a single hybrid deployment in one location may cause latency or performance issues due to extended travel time. Instead, customers can deploy a hybrid environment for each specific location or region to improve the user experience. When a user attempts to connect to a meeting, the user’s client will ping available hybrid modules and will connect to the module with the lowest latency.

#### <mark style="color:blue;">Zoom Meetings Hybrid does not replace Zoom’s Meeting Connector</mark>

Zoom’s Meeting Connector is a Zoom Node workload that offers a cloud-managed, on-premises solution for creating a meeting zone within your company’s data center, without cloud support or fallback. With Meeting Connector, all meeting servers and appliances are owned and maintained by your company, and must allow external connections for external participants to join your meetings.

Unlike Meeting Connector, Zoom Meetings Hybrid continues to utilize cloud meeting infrastructure in conjunction with hybrid appliances in your data center, and does not require hosting meeting servers or allowing external participants to connect to your data centers.

The following table outlines some of the key differences between these two products:

| Capability                       | Meetings Hybrid                   | Meeting Connector |
| -------------------------------- | --------------------------------- | ----------------- |
| On-Premises Server               | ☑️                                | ☑️                |
| Supports Multiple Zones          | ☑️                                | ☑️                |
| Media Exclusively On-Premises    | <p>☑️<br>(While in iMMR Mode)</p> | <p>☑️<br><br></p> |
| Cascade to Cloud                 | ☑️                                | <p><br></p>       |
| Users Can Join Through Cloud     | ☑️                                | <p><br></p>       |
| Cloud Services (Recording, etc.) | ☑️                                | <p><br></p>       |
| Allows External User Connections | <p><br></p>                       | ☑️                |

### Zoom Meetings Hybrid Functionality

This section discusses the functionality and design of the Zoom Meetings Hybrid service module.

#### <mark style="color:blue;">Zoom Meetings Hybrid is comprised of two components: a Selective Forwarding Unit/Internal MMR, and a Zone Controller Proxy</mark>

To deploy Zoom Meetings Hybrid within a network, two Zoom Node components are required: a Selective Forwarding Unit (SFU)/Internal MMR (iMMR), and a Zone Controller Proxy (ZCP). Refer to the Appendix at the end of this document for more information [on service modules](#service-modules-are-the-services-that-run-on-the-zoom-node-os-and-are-easily-deployed-through-the-we).

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeysx0MZgb95ALpMcee5-kcn38XGTnAvcoxL64d6V_Y872u28Tj-xa73F1GTpxIRCchEb_yuzWFKR7mLhIxWq2QRTx6k-13sdLs8EGGL61eG9awOHR9rZQscz2fOb-m7TCabWrhMw?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt=""><figcaption></figcaption></figure>

#### <mark style="color:blue;">The SFU/iMMR operates like a power strip, redistributing media to connected Zoom clients</mark>

The Selective Forwarding Unit (SFU)/Internal MMR (iMMR) module is central to the Zoom Meetings Hybrid design. Similar to a power strip, the SFU/iMMR is a centralized network “plug-in” that distributes media to connected Zoom clients. However, the function of the SFU/iMMR module varies depending on the meeting type.

In hybrid meetings, the SFU/iMMR acts as the primary connection point for internal Zoom clients, multiplexing and redistributing meeting media between connected Zoom clients within the network and the cloud.

For internal-only meetings, the SFU/iMMR acts as a local multi-media router, centrally multiplexing and distributing media to connected users and other SFU/iMMR units (if connected) without the Zoom Cloud.

#### <mark style="color:blue;">Each SFU/iMMR supports up to 400 standard definition or 200 high definition user connections per-module</mark>

Each SFU/iMMR module supports up to 400 concurrent, standard definition participants per-module, or up to 200 concurrent high definition (720p) participants. At maximum capacity for a single meeting, the SFU/iMMR module can reduce external bandwidth consumption by a ratio of 400:1 or 200:1, depending on meeting resolution.

#### <mark style="color:blue;">A SFU/iMMR can support multiple meetings at the same time</mark>

The SFU/iMMR module supports simultaneous meeting connections, allowing one module to support multiple unique, concurrent meetings, including both cloud-hybrid and internal-only meetings.

For example, 400 users within a location are concurrently connecting to 25 different meetings in standard definition with external users present. With Zoom Meetings Hybrid, one SFU module can support connecting all users to their respective meetings, reducing the number of external media streams from 400 to 25. At an average of 1.2 Mbps per-media connection, the SFU module can save the campus approximately 450 Mbps of external bandwidth in this scenario.\\

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXf5110xPOu5I8wpiiWGRVJB2LRVtVCM3wsqGErLZTh5wn9kQb4Uz-OtoDsPmFBAzS_RBo4uOfCvrJVB6K1AWZkj9AMUY18WW0sleDi_PgaeavqOPnXu0viOvnfg05c3Dir8u4-X?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt=""><figcaption></figcaption></figure>

#### <mark style="color:blue;">A SFU/iMMR can support cloud-hybrid and internal-only meetings at the same time</mark>

A SFU/iMMR module can simultaneously support cloud-hybrid and internal-only meetings, negating the need for separate deployments for each use case. For each connected meeting type, the hybrid module will respect the intended connection routing: cloud-hybrid meetings will route media through the module and signaling to the cloud; internal-only meetings will route both media and signaling exclusively through the on-premises hybrid module.

For example, 400 users within a location are concurrently connecting to three separate meetings in standard definition. Two meetings are cloud-hybrid with external users present, and 300 users from the corporate network are connected through the SFU/iMMR module operating in SFU mode. The third meeting is internal-only, with 100 users connected to the same SFU/iMMR module operating in iMMR mode.

In this example, users connected to the cloud-hybrid meetings have a bi-directional media connection with the SFU/iMMR module, and have independent, bi-directional signaling connections with the cloud. Meanwhile, users connected to the internal-only meeting have bi-directional signaling and media connections exclusively with the same SFU/iMMR module, which keeps all internal-meeting data on-premises and does not cascade to the cloud.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXemWHF_V9W6Jm-C_Eo-2VFinM_90aZ8DZpd6YepQ23y6Npn_vovt6-hgIXywXmC1t2NlZTbhPV0_6XKo9jks23JVUprVTslZ3Jh8jFj97-WoHjtULZM1dhgsnhJMtbrbuiUIp2QOA?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt=""><figcaption></figcaption></figure>

#### <mark style="color:blue;">For cloud-hybrid meetings, the SFU/iMMR acts only as a forwarding device, and does not have access to any meeting or user keys</mark>

When connected to a cloud-hybrid meeting (SFU mode), SFU/iMMR modules do not require and do not have access to meeting encryption keys. Instead, the modules maintain media mixing roles as encrypted meeting media processors, incapable of accessing the contents of the media stream.

#### <mark style="color:blue;">For internal-only meetings, the SFU/iMMR generates and distributes all encryption keys within the corporate network</mark>

When operating as a multi-media router for internal-only meetings (iMMR mode), the top-level SFU/iMMR in a meeting is responsible for generating and distributing in-meeting encryption keys. Encryption keys are generated and distributed using the same cryptographic methods as cloud-based MMRs.

#### <mark style="color:blue;">SFU/iMMR modules cannot communicate with each other across a network when connected to a cloud-hybrid meeting</mark>

SFU/iMMR modules do not support cross-network (east-west) communication within a data center when connected to a cloud-hybrid meeting. All SFU-to-SFU communication for cloud-hybrid meetings must be routed through the Zoom cloud infrastructure (north-south) by design.

#### <mark style="color:blue;">SFU/iMMR modules can communicate with each other across the network when connected internal-only meeting</mark>

Unlike with cloud-hybrid meetings, internal-only meetings support cross-network (east-west) communication due to the internal meeting design. Cloud-hybrid meetings require each SFU/iMMR module to subscribe to the “top” cloud MMR’s media feed; however, internal-only meetings do not utilize cloud media feeds. Instead, the first iMMR/SFU module to create an internal-only meeting is the “top” MMR, and additional SFU/iMMR modules subscribe to the top MMR feed, allowing for cross-network communication.

#### <mark style="color:blue;">The Zone Controller Proxy module connects the SFU/iMMR to the Zoom Cloud</mark>

The Zone Controller Proxy module is responsible for connecting SFU/iMMR modules to Zoom’s cloud meeting infrastructure, when applicable.

During a user’s meeting connection process, Zoom web services sends a request between the Zone Controller Proxy and a cloud Zone Controller to fetch the meeting server information. This information is relayed from the Zone Controller Proxy to the SFU/iMMR, which will connect to the Zoom cloud for cloud-hybrid meetings, or initialize a meeting for internal-only meetings.

#### <mark style="color:blue;">Deployments require at least two Zone Controller Proxies per location</mark>

Each geographic location Zoom Meetings Hybrid is deployed requires at least two Zone Controller Proxies for resiliency and stability.

For example, if a company is deploying Zoom Meetings Hybrid to their Los Angeles and New York offices, each location should deploy two ZCP modules at each location, totalling four.

#### <mark style="color:blue;">If a SFU/iMMR module unexpectedly fails, users will failover to alternate connections when possible</mark>

Although unexpected, in the event a hybrid module fails (i.e., crashes) while users are connected, users will begin to failover to alternate connections if possible. These scenarios are described in the following three sections.

#### <mark style="color:blue;">Users connected to a cloud-hybrid meeting will failover to an alternative SFU/iMMR module if available, and to the cloud as a last resort</mark>

If users are connected to a cloud-hybrid meeting through an SFU/iMMR module that abruptly fails, user clients will automatically attempt to failover to other SFU/iMMR modules available within the network. If other resources are at capacity or unavailable, user clients will establish independent cloud connections as a final failover solution.

#### <mark style="color:blue;">Users connected to an internal-only meeting will failover to a different SFU/iMMR module if the failed module was not the top MMR</mark>

If users are connected to a internal-only meeting and their SFU/iMMR module fails, users will failover to alternative SFU/iMMR modules if available, providing that their SFU/iMMR was not the top-level MMR host of the internal meeting.

#### <mark style="color:blue;">If the SFU/iMMR that started an internal-only meeting fails, the meeting must be restarted</mark>

Due to the network design for internal-only meetings, the SFU/iMMR module that initiates the meeting is designated as the top-level MMR for the meeting. If the top-level MMR of a meeting fails, quits, or leaves the meeting, the meeting will collapse and must be restarted. Top-level MMRs **cannot** failover to alternative hybrid resources.

#### <mark style="color:blue;">Zoom Meetings Hybrid connections display as a “data center controlled by your Zoom account owner” within the client</mark>

When connected to Meetings Hybrid infrastructure, users will see that they are “...connected to the Zoom Global network… via a data center controlled by your Zoom account owner” within the client. Alternatively, users connected to cloud infrastructure will see the message they are “Connected to the Zoom Global Network.”

The following images display what users will see when connected to a Zoom Meetings Hybrid meeting compared to a cloud-based meeting.\\

{% columns %}
{% column %}

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeL9BwtbA2YYCCRgCa-kUpcsTzKme2Eiii6jGh9_uIrhfrsw10IxgyRZIFoXUPw64sdVaQVDfk-niTaFnSDeurtUEyfRwLipjgWeDgbKyuVdWCmatm4DfUw_fzlJH1ger5CvEcK?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt="" width="375"><figcaption></figcaption></figure>
{% endcolumn %}

{% column %}

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdBgfJcS9paUxZSekZ6p5YD-qHLA3hZEV60TdXzDE2s1KAXflpINJS2Dhn-VoIW8kitzfQfSHwfrklim5QvAeYt9X7Bc_omR4Ad0lHlBM5QgpzsE-iiFt840hIK-BhrK5GCj3Qh?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt="" width="375"><figcaption></figcaption></figure>
{% endcolumn %}
{% endcolumns %}

#### <mark style="color:blue;">Zoom Meetings Hybrid uses Zoom’s standard firewall configuration and does not require special rules</mark>

Zoom Meetings Hybrid does not require any additional firewall rules or configurations outside of [Zoom’s default recommendation](https://support.zoom.us/hc/en-us/articles/201362683-Zoom-network-firewall-or-proxy-server-settings). Media connections will continue to use UDP/TCP 8801 and TCP 443 (TLS 1.2) as standard ports for the service.

{% hint style="info" %}
**Note**

Port separation for media (UDP 8801-8803) is supported. Ensure firewall rules are configured to include 8802 and 8803 if port separation is enabled.
{% endhint %}

### Appendix: Zoom Node

This section provides a general introduction to the Zoom Node platform and its core concepts.

#### <mark style="color:blue;">Zoom Node brings key parts of the Zoom service to your own data centers and offices</mark>

Zoom Node is a hybrid solution that integrates your data center servers with Zoom’s cloud to help deliver Zoom services to your offices.

Featuring a cloud-driven deployment model, Zoom administrators can dynamically and quickly deploy Zoom hybrid services to their data center servers from a centralized dashboard on the web. This dashboard additionally includes tools for service management, upgrades, log management, performance reporting, and a robust troubleshooting framework.

#### <mark style="color:blue;">Zoom Node is a modular design, where you only deploy the service modules you need</mark>

Instead of requiring separate software for each hybrid service, Zoom Node is an “all-in-one” modular platform that allows companies to manage and deploy multiple hybrid services using one common framework.

Zoom Node achieves this modular design by installing the Zoom Node OS (a Linux-based operating system) onto enterprise datacenter servers, transforming them into Nodes. Once the software is installed, the Node registers to the Zoom Node Platform in the cloud and awaits installation of various service modules that provide Zoom service functionality

#### <mark style="color:blue;">Zoom Node includes a feature-rich dashboard for service management, upgrades, alerts, troubleshooting, and more</mark>

As a central hub for managing Zoom Node deployments, the Zoom Node dashboard includes tools for service management, deployments, upgrades, log management, performance reporting, and a robust troubleshooting framework.

#### <mark style="color:blue;">Service modules are the services that run on the Zoom Node OS, and are easily deployed through the web</mark>

Service modules are the service applications that run on the Zoom Node operating system, allowing services to function. Zoom administrators assign services to nodes through the Zoom Node dashboard on the web portal. After assigning the service to a Node, the Zoom Node Platform pushes the chosen service module to the Node and installs automatically. Once installation is complete, the Node endpoint is ready for use with its designated hybrid service(s).

#### <mark style="color:blue;">Each Zoom Node can support up to four service modules</mark>

Each Zoom Node appliance can support up to four service modules per machine, except for the Zoom Phone Local Survivability module. Additional Nodes can be created and linked for additional requirements or resiliency.

For example, a company is deploying Zoom Meetings Hybrid across several data centers, beginning with New York. Each data center is equipped with several Zoom Node endpoints connected to the Zoom Node Platform, but none has been assigned a Node service for functionality, as seen in the following image.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeutD-2geglZBY9wv2h9od07rrVNko-KOW7cTmhmyj-8W9hDlcpptUcHPH95fxdB7OPQGYRtKTaXWEbBUUIeeJ7vCTlCsran7jlZKsHCuZu-tVXSKoeZy8W4nEQYqJXoWsGphInRg?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt="" width="563"><figcaption></figcaption></figure>

Once the company is ready to deploy Zoom Meetings Hybrid within their network, an account admin deploys one Zone Controller Proxy service, and three SFU/iMMR modules to Nodes 1 and 2. The admin also deploys an extra SFU/iMMR module to the third Node as a buffer. The Zoom Node Platform pushes and installs all Node services to each Node endpoint, and after the installation is complete, Zoom Meetings Hybrid ready for use as seen in the following image.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXcS8UUa_h7FzrCbkuc2EZ8OBua6PQkWs-tWWtcpAcYkYT_CcVCHYZ_CrBrcjCfus2U6m1C55uR5Cld4mB47aCvjiWouzN2XgmSOsQQ23DbLsdUdFH4QhNce8t-CnHLH10ImqnwWrA?key=Z3rnkTkRPWE0oHdIjBvbxQ" alt="" width="563"><figcaption></figcaption></figure>

#### <mark style="color:blue;">Zoom Node supports end-to-end automated PKI certificate generation (Auto-PKI)</mark>

Zoom Node includes end-to-end automated public certificate management through DigiCert. All costs for generating and renewing certificates are paid by Zoom, but Zoom does not handle or have access to customer's private keys through this process.

Customers with an existing certificate strategy can choose to generate, renew, and support certificates manually with a certificate authority of their preference, but these costs will not be paid for by Zoom. Customers that intend to use an alternative certificate authority should speak with their account team in advance.

#### <mark style="color:blue;">Each Zoom Node has a dynamic DNS entry using the account’s Vanity URL: \*.zoomonprem.com (Auto-DNS)</mark>

Zoom Node automatically generates dynamic DNS entries for each server under the \*.zoomonprem.com domain using the host account’s existing Vanity URL, e.g. `success01.zoomonprem.com`.

This system simplifies firewall management when connecting to Zoom Node deployments used by other Zoom customers. Individual customers will no longer require firewall rules to connect to another Zoom Node customer, but can instead approve the entire zoomonprem.com domain using wildcard values.

#### <mark style="color:blue;">Zoom Node runs on virtual machines</mark>

Zoom Node is designed to run on server-grade hardware, using virtual machines, installed with the hardened Zoom Node operating system image. All services will require static internal IP addresses, with some services requiring public IPs for external connectivity.

The hardware requirements and specifications will be unique to your hybrid deployment goals. Please refer to your account team for more information on identifying your organization’s needs for a hybrid deployment.

#### <mark style="color:blue;">Zoom Node is not for every customer</mark>

Every enterprise has unique requirements when it comes to unified communication services. These needs must be carefully considered before making a decision to deploy a hybrid environment. In most cases, the traditional Zoom cloud configuration is the optimal solution for most companies; however, there are organizations that benefit from hybrid configurations. Organizations should be thorough in considering the implications of establishing and maintaining a hybrid environment.

#### <mark style="color:blue;">Scaling can be difficult and expensive to manage</mark>

Scaling the hardware to support a large number of users in hybrid environments can be costly. Depending on the services deployed, supporting 10,000 users could require between 7-13 Zoom Nodes, while supporting 100,000 users may require between 60-120 Zoom Nodes.

Managing, maintaining, and supporting the hardware and/or hypervisor infrastructure required for Zoom Node also creates additional overhead for any organization and should be heavily considered when examining hybrid deployments.

#### <mark style="color:blue;">Security advantages are limited</mark>

Zoom Node does not offer additional encryption methods or major security advantages over the native Zoom cloud service, apart from the potential to serve as a specialized web proxy or local log residency.

Hybrid deployments also require additional firewall rules and configurations to make Node endpoints available with external services. Network security teams should be mindful of these additional firewall and security requirements when considering deploying hybrid environments.

#### <mark style="color:blue;">Hybrid environments and VPNs require configurations</mark>

Remote employees may require a VPN connection or a split-tunnel configuration to route their meeting traffic to Zoom Node services if desired. This increase in traffic can potentially overwhelm the VPN infrastructure if it cannot handle the additional bandwidth being sent and received. Careful planning is required when combining hybrid services with remote workers and remote network infrastructure.

#### <mark style="color:blue;">Sharing server logs requires careful consideration</mark>

Although maintaining local control over Zoom Node logs and records is a component of hybrid deployments, this feature can be obstructive when troubleshooting hybrid infrastructure.

Service logs are maintained locally by default, and include data, diagnostics, and other information not available to Zoom for viewing. However, in order to effectively troubleshoot hybrid configurations and quality concerns, hybrid data logs are required to be shared with Zoom for troubleshooting purposes. Zoom Node offers a secure log file upload service through the web portal at customer discretion, but uploading these logs can expose service metadata that is otherwise not shared with Zoom in hybrid deployments. This data may include names of participants joining locally, Zoom version number, operating system information, and more.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-meetings-hybrid/zoom-meetings-hybrid-explainer.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.