Bandwidth for
the work you do.

A sizing method

From workload to service size.

1. 01

   Estimate the busy period

   Measure or estimate traffic that crosses the connection at the same time. Add expected new workloads that are not already included in your measurements.

2. 02

   Calculate each direction

   Add concurrent download needs separately from upload needs. For time-sensitive transfers, calculate the sustained rate needed for the deadline. Account for VPN paths and avoid counting the same traffic twice.

3. 03

   Add room to operate

   Include a planning margin for growth, bursts, overhead, and uncertainty. For illustration, the examples below use 30%; the appropriate margin depends on the business and the evidence available.

4. 04

   Compare available services

   Choose an available service that meets the estimated need in both directions, then check its commitments, upgrade options, and the capacity of the firewall, equipment, and path. Validate the choice with real usage and application performance.

01 / Find the busy period

Measure traffic during busy periods.

Start with traffic graphs from your router, firewall, or network monitoring system. Review both directions over representative business days, including peak periods and scheduled backups. Check for short bursts as well as averages: a five-minute average can hide a brief spike.

Ask when the connection is busiest, which applications use it, and whether users see issues at the same time. A link that reaches its limit may deserve closer investigation; graphs alone do not establish where congestion occurs or how much capacity an application would use if unconstrained.

Research & planning

What does an office use?

There is no reliable universal number of megabits per employee. Different jobs, applications, locations, and meeting patterns can produce very different traffic. A per-person assumption is a starting point for an estimate, not a measurement or a service guarantee.

Google’s Meet planning guidance estimates demand using concurrent participants and provides different figures for large organizations and smaller groups. The figures are planning guidance for Meet, not a measurement of all office traffic. Read Google’s network guidance.

For planning meetings, Microsoft’s Teams Network Planner uses locations and user activity patterns to estimate demand, rather than a single fixed allowance per employee. Its calculations address Teams and cloud voice, so other applications and transfers still need to be considered. Explore Microsoft’s Network Planner.

02 / Both directions

Don’t overlook upload.

Download brings data into your business. Upload sends it out. Cloud backups, sending large files, video meetings, and services hosted in your office can make upload capacity important.

A symmetrical service offers the same stated rate in each direction; verify the service terms. Track peak upload and download separately, because the busier direction may change over the day.

03 / Everyday work

Plan for simultaneous meetings.

Video bandwidth varies with the application, resolution, screen sharing, and network conditions. For its best-performance video guidance, Microsoft lists up to 4 Mbps in each direction per Teams endpoint. Zoom lists 3.8 Mbps upload and 3.0 Mbps download for 1080p video, subject to its feature and device requirements. Google lists up to 3.6 Mbps each way for 1080p Meet video in its small-organization or individual guidance; its large-organization averages use different assumptions. These figures describe individual scenarios, not a complete office connection. A person using both a laptop and a phone may count as two endpoints. Microsoft Teams · Zoom · Google Meet

Count the meetings and endpoints likely to use the connection at the same time. Consider cloud applications and other traffic separately. Avoid counting the same video traffic twice if it is already included in measured utilization.

Voice and video quality also depend on delay, jitter, packet loss, and Wi-Fi. Extra bandwidth alone will not fix every call-quality issue.

Remote work & VPNs

Include remote users and their path.

VPN traffic can consume office upload and download capacity when remote employees connect to systems at the office. A full-tunnel design may also send remote users’ cloud and Internet traffic through the office before it reaches its destination. Consider each direction across the office connection and the capacity of the VPN gateway and firewall.

For example, when a remote employee downloads a cloud file through a full-tunnel VPN, the data arrives from the Internet at the business, then leaves the business through the VPN to the employee. An upload takes the reverse path: it arrives at the business through the VPN, then leaves for the cloud service. When both legs use the same office Internet connection, the traffic consumes capacity in both directions.

A remote employee downloading a file stored on an office server is different: that transfer primarily uses office upload capacity. Tunnel encryption also adds processing work. If VPN and cloud traffic use different links, account for each path separately.

Microsoft recommends considering split tunneling for specific Microsoft 365 services to reduce VPN and network load. It changes where traffic travels and which controls inspect it, so an organization’s IT and security teams should evaluate policy and vendor guidance before making a change. Microsoft’s VPN guidance.

Business applications

Account for cloud work beyond meetings.

Google Workspace and Microsoft 365 include email, documents, file sharing, and other services as well as meetings. Individual activity may be modest or bursty, while file uploads, downloads, synchronization, and many users working at once can add to peak demand.

Google Drive for desktop synchronizes files between a computer and the cloud. Traffic depends on file sizes, sync settings, and when devices are active. Measure usage at the office connection and account for expected changes. Google Drive for desktop guidance.

Remote desktops & cloud applications

Remote desktops and cloud applications.

A virtual desktop sends a view of the remote computer to the user and returns their keyboard and mouse input. Bandwidth varies with display size, screen activity, the application, and protocol settings. File transfers and other redirected traffic can add to the load.

For Amazon WorkSpaces Pools, AWS gives illustrative per-user recommendations of 2 Mbps for business productivity, 5 Mbps for graphics, and 10 Mbps for high-fidelity workloads. These describe what an individual may need at a point in time, not sustained traffic or an estimate for every WorkSpaces product. AWS also provides workload-specific round-trip latency guidance. AWS recommendations.

Microsoft’s Azure Virtual Desktop guidance explains how Remote Desktop Protocol adapts to network conditions and how activity, display resolution, and redirected transfers affect usage. Measure representative sessions and account for the number active at the same time. Azure Virtual Desktop guidance.

Salesforce notes that latency between a user and the Salesforce environment, including indirect VPN routing, can affect page load times. Check the application path and responsiveness as well as available bandwidth. Salesforce network guidance.

04 / Data movement

How long can a transfer take?

Large backups, media files, and data sets may be more sensitive to available capacity than everyday browsing. The amount of data and the time allowed are useful planning inputs.

For a rough estimate, divide the data size in bits by the transfer window in seconds. Then account for other traffic and practical overhead. Confirm that storage, servers, firewalls, and the destination can sustain the rate.

05 / AI workloads

Where does the data travel?

Interactive AI, model inference, and training have different network needs. A text request may exchange relatively little data; large documents, images, video, model files, or data sets can require much more. The workload, concurrency, and transfer deadline matter.

Training inside your own network does not automatically consume Internet bandwidth. Data exchanged with a cloud service or another site may cross the Internet connection or a separate private link, depending on the design. Confirm the actual path before adding it to an Internet estimate.

For interactive workloads, also measure latency to the service and consider application and model processing time. A larger link can reduce large-transfer time and queueing when a connection is busy, but it does not by itself guarantee a faster model response.

06 / The rest of the path

Capacity is one part of performance.

Latency is the time traffic takes across a measured path. Jitter is variation in delay; packet loss means data does not reach its destination. The provider’s network, Internet paths, remote service, and your own equipment can each affect the experience.

Check that the router, firewall, interface, optics, and cabling can support the intended traffic. A firewall’s capacity with inspection or encryption enabled can differ from its advertised port speed. See the speed-test guide for measurement methods and limitations.

07 / Sizing examples

Three ways to estimate demand.

These examples use illustrative workloads and a 30% margin. They are not measurements or recommendations for a particular business. Actual traffic, timing, and growth will change the result.

08 / Make a decision

Review your estimate before choosing a service.

• Compare peak upload and download needs, including overlapping workloads.
• Consider large-transfer deadlines and whether transfers can be scheduled.
• Review latency, reliability, and support as well as bandwidth.
• Check the capacity of the firewall, router, interfaces, and the rest of the path.
• Understand the service commitment, upgrade options, and contract terms.
• Measure again as the business and its applications change.

The bandwidth calculator can help organize an initial estimate. For a Stealth service discussion, contact sales@stealth.net.