Cisco Meraki Firewall Sizing in Dubai
Choosing a Cisco Meraki firewall is a capacity-planning exercise, not a simple model-to-bandwidth lookup. The right platform must sustain the traffic profile you actually intend to inspect, the number of devices and flows created by the site, the VPN topology, the remote-access population, the WAN design and the security license tier that will be enabled.
Direct answer: how should a Cisco Meraki firewall be sized?
Cisco Meraki firewall sizing is the process of matching an MX Security and SD-WAN appliance, Cisco Secure Router running Meraki OS, or vMX virtual appliance to the actual workload of a site or hub. These platforms combine routing, firewalling, SD-WAN, VPN and security services, so the limiting factor can change depending on which functions are active.
The products are mainly used to secure branch offices, headquarters, retail locations, clinics, warehouses, schools, hospitality sites, distributed enterprises and cloud-connected environments. Buyers should consider them when cloud-managed operations, SD-WAN, Auto VPN, application visibility, security controls and simplified multi-site management are important to the network design.
The most important point to confirm is the real operating workload: expected internet and inter-site traffic after security services are enabled, total client-device count, concurrent sessions, VPN tunnel scale, remote-user requirements, WAN links, route scale and the amount of capacity that must remain available during peak periods or failures.
FourTeck can help convert those requirements into a model shortlist, identify whether the design belongs on a classic MX platform or the newer Cisco Secure Router with Meraki OS family, review licensing and HA implications, and prepare a UAE quotation around the correct hardware and deployment scope.
Why internet speed alone is not enough
A common sizing mistake is to start with a statement such as “the office has a 500 Mbps line” and immediately pick a firewall whose published firewall throughput exceeds 500 Mbps. That shortcut ignores the fact that the same appliance may have a lower security-inspection figure, a different VPN figure, a recommended client-device scale, a session-table limit and practical limits for VPN topology. The correct question is therefore not “Can this appliance pass the circuit speed?” but “Can it pass our peak traffic while running the features, sessions and tunnels our business requires?”
Cisco publishes separate performance values for firewall throughput, next-generation firewall throughput and VPN throughput. It also publishes recommended device counts and tunnel guidance. This matters because a branch that mostly accesses SaaS platforms has a different workload from a branch that backhauls file transfers over Auto VPN, and both differ from a head office terminating hundreds of VPN tunnels. A 1 Gbps internet connection in a 30-person office may be easy to handle from a session perspective, while a 1 Gbps connection in a dense guest-Wi-Fi venue can create far more flows and simultaneous clients.
Sizing also changes when Advanced Security features are part of the operating requirement. Threat prevention, malware inspection and intrusion prevention add processing work compared with basic forwarding. Cisco’s current sizing guidance explicitly presents NGFW throughput figures for Advanced Security in prevention and detection modes, which is why a security-led deployment should be judged against the NGFW figure rather than the largest headline number on a datasheet.
For procurement, this means the firewall should be selected after reviewing the full site profile. Circuit bandwidth is still important, but it is one input among several. A professional sizing exercise considers security workload, users, endpoints, sessions, VPNs, interfaces, resilience and growth together so that the chosen platform is neither unnecessarily expensive nor undersized from day one.
Current Meraki sizing reference: MX family
The following figures reflect Cisco Meraki’s current sizing guidance for the main MX platforms. They are useful as screening numbers, not as a substitute for a design review. Published benchmark methods can differ from production traffic, and Cisco notes that multi-flow and single-source methodologies may yield different results. For real projects, use the numbers as boundaries and then apply headroom for peak use, inspection, WAN failover and business growth.
| Model family | Recommended devices | Firewall EMIX | NGFW prevention EMIX | VPN EMIX | Max concurrent sessions |
|---|---|---|---|---|---|
| MX67 / MX68 | 50 | 700 Mbps | 300 Mbps | 300 Mbps | 25,000 |
| MX75 | 200 | 1 Gbps | 500 Mbps | 1 Gbps | 50,000 |
| MX85 | 250 | 1 Gbps | 500 Mbps | 1 Gbps | 125,000 |
| MX95 | 500 | 3 Gbps | 1.5 Gbps | 2.5 Gbps | 200,000 |
| MX105 | 750 | 5 Gbps | 2 Gbps | 3.5 Gbps | 250,000 |
| MX250 | 2,000 | 7 Gbps | 2 Gbps | 3.5 Gbps | 500,000 |
| MX450 | 10,000 | 10 Gbps | 5 Gbps | 6.5 Gbps | 1,000,000 |
These values show why there is no single “best” Meraki firewall. MX75 and MX85, for example, share similar published throughput numbers but differ in device-count and session capacity. MX250 has strong general firewall throughput, yet its published NGFW prevention value is materially lower than its firewall figure. That distinction can directly affect a security-heavy design.
How to read firewall, NGFW and VPN throughput
Firewall throughput
This is the starting point for routed and internet traffic, but it represents a less demanding workload than full advanced security inspection. It is most useful when determining whether the platform can physically move the required volume of traffic before stronger inspection requirements are applied.
NGFW throughput
For buyers enabling Advanced Security features, this is often the more relevant performance figure. Cisco publishes separate prevention and detection values. A design that expects sustained high traffic while inspection is active should be checked against this lower security-services ceiling rather than the largest firewall benchmark.
VPN throughput
This matters for Auto VPN, site-to-site traffic, hub designs and organisations moving significant workloads between offices, data centres and clouds. A branch can have modest internet browsing but heavy encrypted inter-site transfers, while a hub can aggregate many smaller sites into a much larger VPN workload.
A practical sizing process should compare all three figures with the expected peak traffic mix. Suppose a business has a 1 Gbps internet service but normally sees 450 Mbps at peak and intends to enable Advanced Security inspection for most user traffic. A platform with 1 Gbps firewall throughput but only 500 Mbps NGFW prevention throughput may be too close to the requirement once growth, bursts and failover are considered. In that situation, the correct answer may be a larger model even though the basic firewall number appears adequate.
The same logic applies to VPN. A site with two 1 Gbps circuits does not automatically require 2 Gbps of encrypted traffic, but the design must account for what happens if one circuit fails and the remaining link carries the important workload. If business continuity requires the surviving link to handle full operation, both WAN bandwidth and firewall capacity should be sized for the failure state, not only the normal state.
Recommended device count is a planning signal, not a user-count synonym
Cisco’s sizing guide uses a recommended maximum device count and explains that the calculation considers device throughput, available features and flow-table capacity, with each client considered to consume up to 50 flows in that sizing method. That is important because “users” and “devices” are not interchangeable. A staff member may simultaneously use a laptop, phone, tablet, IP phone, printer session, video meeting and cloud applications. Guest devices, cameras, IoT sensors, access-control terminals and servers can increase the total without increasing employee headcount.
For example, an office with 80 employees might easily operate 180 to 250 networked devices when wireless clients, phones, meeting-room systems, printers and infrastructure are included. A simplistic “80 users equals a small branch firewall” decision could therefore misrepresent the real workload. Device count should be established from DHCP, switching, wireless-controller or monitoring data where possible, then adjusted for planned growth and unmanaged guest access.
Concurrent-session capacity provides another view of the same problem. Modern browsers and SaaS applications create many parallel connections. Collaboration platforms, endpoint agents, cloud storage and software updates can multiply flow counts rapidly. A model with adequate Mbps but insufficient comfortable session headroom may become the wrong choice for a dense site. For branch and campus sizing, throughput and flow scale must be checked together.
Site-to-site VPN sizing: branches and hubs behave differently
Meraki Auto VPN makes multi-site connectivity operationally straightforward, but a large topology still has scale requirements. Cisco publishes both maximum site-to-site VPN tunnel counts and lower recommended counts for active environments. The distinction is meaningful: the maximum test reflects tunnel scale under constrained lab conditions, while the recommended value is intended for scenarios where client traffic is actually traversing the VPN tunnels.
| Model | Maximum site-to-site tunnels | Recommended site-to-site tunnels | Secure Client / AnyConnect sessions |
|---|---|---|---|
| MX67 / MX68 | 50 | 50 | 100 |
| MX75 | 75 | 75 | 250 |
| MX85 | 200 | 100 | 250 |
| MX95 | 500 | 250 | 500 |
| MX105 | 1,000 | 500 | 750 |
| MX250 | 3,000 | 1,000 | 1,000 |
| MX450 | 5,000 | 1,500 | 1,500 |
A branch that forms only a handful of tunnels is unlikely to be tunnel-count limited, but a hub or concentrator can be. The hub must be sized for the number of branches, the traffic arriving from those branches and the routes learned or advertised across the topology. If the organisation uses full-mesh VPN, the branch design should also be checked for how many peer tunnels each location creates. Network growth can change tunnel count faster than site count when topology becomes more interconnected.
Remote access adds another dimension. A headquarters appliance may need to support both branch VPN and a large Secure Client population. Remote users can create significant encryption and session load during working hours, especially when full-tunnel designs send internet traffic through the head end. Sizing should therefore document the maximum concurrent remote users, expected traffic per user, split-tunnel or full-tunnel policy, and whether business continuity requires a second remote-access endpoint.
Practical branch sizing profiles
Small branch or compact office
Start with actual device count, not employee headcount. MX67/MX68-class capacity may suit genuinely small sites, but the published 300 Mbps NGFW prevention figure becomes important if strong inspection is enabled. A site buying a 500 Mbps or 1 Gbps service should not assume the smallest model can deliver that rate with every security feature active.
Check whether integrated Wi-Fi or cellular variants are relevant, whether dual WAN is required, and whether the site will grow beyond the recommended device scale during the expected hardware lifecycle.
Medium branch or busy professional office
MX75 and MX85 are common comparison points because both publish 1 Gbps firewall and 500 Mbps NGFW prevention throughput, but they differ in recommended device count and concurrent-session capacity. If a site has many endpoints, guest devices or cloud-heavy applications, the higher session headroom of MX85 can matter even when raw bandwidth appears similar.
Also compare interfaces, PoE requirements, VPN scale and anticipated second-circuit capacity. Do not choose solely on nominal internet speed.
Large branch or regional office
MX95 and MX105 step into multi-gigabit firewall territory and much larger device, VPN and session capacities. They become relevant when internet access, SaaS use, inter-site data, wireless density and remote access all grow together. The correct choice depends on the inspected-throughput requirement: MX95 publishes 1.5 Gbps NGFW prevention, while MX105 publishes 2 Gbps.
This tier is also where physical interface planning, uplink speed and downstream switching become increasingly important to avoid creating a bottleneck outside the firewall.
Campus edge or head office
MX250 and MX450 are designed for substantially larger aggregate workloads. They should be evaluated around the real mix of north-south internet traffic, east-west routing design, VPN aggregation, route scale and security inspection. MX450’s current published NGFW prevention throughput is 5 Gbps, while MX250 is 2 Gbps, even though both have much higher basic firewall figures.
Large sites should also review HA, power, rack design, transceivers, upstream ISP handoffs, downstream core switching and maintenance windows as part of the sizing process.
High-density but moderate-bandwidth site
Some schools, hospitality venues, healthcare sites, co-working spaces and IoT-heavy environments have more endpoints than their internet bandwidth suggests. In these cases device count and session capacity can become the primary sizing driver. A modest 300–500 Mbps circuit can coexist with hundreds of endpoints and a large flow table.
For such sites, a larger appliance may be justified by session scale and operational stability rather than Mbps alone. Wireless-client peaks and guest usage should be included in the inventory.
Cisco 8000 Series Secure Routers with Meraki OS
Current Cisco Meraki sizing guidance also includes Cisco Secure Router 8000-Series models running Meraki OS. These platforms extend the portfolio beyond the classic MX hardware and deserve consideration where higher scale, multi-active WAN, higher-speed interfaces or a newer hardware generation better matches the project. The currently documented family includes C8111-G2-MX/C8121-G2-MX, C8355-G2-MX and C8455-G2-MX.
| Platform | Recommended devices | Firewall EMIX | NGFW prevention EMIX | VPN EMIX |
|---|---|---|---|---|
| C8111-G2-MX / C8121-G2-MX | 200 | 2 Gbps | 1 Gbps | 1.1 Gbps |
| C8355-G2-MX | 5,000 | 10 Gbps | 4 Gbps | 5 Gbps |
| C8455-G2-MX | 15,000 | 20 Gbps | 8 Gbps | 10 Gbps |
The C8111/C8121 family is particularly relevant when a branch wants up to 2 Gbps firewall performance with 1 Gbps NGFW prevention performance and more active-WAN flexibility than the traditional dual-WAN pattern. Cisco documents multi-uplink capability on supported models with appropriate firmware. Some C8111/C8121 variants also integrate cellular and Wi-Fi, which can simplify branch design when those capabilities align with the deployment.
C8355-G2-MX and C8455-G2-MX move into higher-capacity enterprise use cases. Their suitability should be evaluated not only from throughput but also from interface type, power, route scale, WAN design, expected feature set and licensing. The portfolio shift means buyers should not automatically repeat the same MX model selected several years ago. A refresh project is a good time to compare the current Secure Router options alongside MX rather than treating the older platform choice as permanent.
Licensing changes the sizing conversation
Meraki MX functionality is license-dependent, and the security edition affects both features and the performance number that should be used for sizing. Cisco documents Enterprise, Advanced Security and Secure SD-WAN Plus editions for MX. Advanced Security adds capabilities such as intrusion prevention, malware protection and content/security controls beyond the base Enterprise feature set. If the business requirement specifically depends on those protections, the hardware should be sized against the security-enabled workload rather than the base firewall benchmark.
Licensing architecture also affects procurement. Under co-termination licensing, Cisco documents MX licenses on a per-model basis and states that licenses are not transferable between appliance models. An MX75 license is not a generic license that can simply cover an MX95 after a hardware change. The license edition is also an organisation-wide property for MX in the co-termination model, so a mixed estate can require careful planning when different security tiers are desired.
Per-device licensing has its own rules, and current documentation likewise states that an organisation uses a consistent MX license edition. A business planning to upgrade from Enterprise to Advanced Security should therefore understand that the decision can affect all MX appliances in the organisation, not only the new branch. This can materially change the renewal budget and should be checked before a hardware-only quotation is approved.
Hardware model
Determines the performance, interfaces, session scale, VPN scale and compatible license SKU.
License edition
Determines which security and SD-WAN capabilities are available and therefore which performance profile should be considered.
License term and model
Affects commercial planning, renewals and how new appliances fit into the existing Meraki organisation.
For a correct quote, provide the existing Meraki organisation licensing model where possible, the desired security edition, term, quantity, whether the purchase is a new deployment or renewal, and whether existing MX appliances remain in the same organisation. These details reduce the risk of selecting hardware correctly but licensing it incorrectly.
High availability: size for failure, not only normal operation
Meraki MX supports warm-spare high availability using VRRP. In a typical HA pair, one appliance is active and the second is ready to take over if the primary fails. Cisco documents that only one MX license is required for the HA pair, so the incremental cost is primarily the redundant hardware and associated deployment infrastructure rather than a second full MX license.
That licensing advantage does not remove the need for careful topology design. Both appliances require uplink connectivity for dashboard access. When virtual IPs are used, the uplink addressing plan needs additional addresses in the same subnet. The LAN side must permit reliable heartbeat communication between the pair, usually through downstream switching designed with spanning-tree considerations. These details should be reviewed with the ISP handoff, switch design and IP allocation before installation day.
Capacity planning for HA should ask what happens after a failure. If two WAN circuits normally share traffic, can one surviving circuit and one active MX handle the critical workload? If the site expects 2 Gbps of aggregate traffic during normal conditions but only a 1 Gbps backup circuit remains during an outage, the limiting factor may be the backup circuit rather than the firewall. Conversely, a fast secondary circuit is of little value if the chosen appliance cannot sustain the required inspected traffic when all users move onto it.
For headquarters and critical branches, the business continuity target should therefore be written explicitly: required surviving bandwidth, maximum acceptable interruption, whether all security services remain enabled during failover, and which applications must continue. Those requirements can justify a larger model even when average normal traffic is lower.
WAN architecture and interface planning
A firewall can be correctly sized for CPU and sessions yet still be the wrong hardware if its interfaces do not match the WAN and LAN design. Buyers should confirm the physical ISP handoff, copper or fibre requirement, port speed, transceiver type, downstream switching speed, PoE requirements where relevant and whether the appliance must connect directly to multiple service providers. When WAN services exceed 1 Gbps, interface capability becomes part of the performance decision rather than an accessory detail.
Classic MX models support dual active WAN across the current mainline family, while newer Cisco Secure Router platforms can support additional active uplinks on supported models and firmware. This can matter for sites combining dedicated internet access, broadband, MPLS or private circuits, and cellular services. The design should document which uplinks are active, which are backup only, what traffic policies apply, and whether Auto VPN must operate across all intended paths.
Cellular should also be treated as a service with its own capacity and policy limits. Some MX67/MX68 variants include integrated cellular options, while other models can use a Meraki MG cellular gateway for failover. Cellular is valuable for resilience, but it should not be assumed to provide the same bandwidth, latency or data allowance as a primary fibre circuit. Critical applications should be identified so that failover policies can prioritize business traffic and avoid unexpected mobile-data consumption.
For fibre uplinks or higher-speed campus connections, confirm compatible optics rather than assuming an SFP or SFP+ cage accepts any transceiver. Cisco publishes accessory compatibility by model. The final bill of materials should include the right transceivers, patch leads, power components and rack accessories where required, because these small items can delay an otherwise correctly sized deployment.
Security services and inspection policy
Security requirements should be written before hardware is chosen. A business that needs basic stateful firewalling, routing and site-to-site VPN has a different processing profile from one that requires intrusion prevention, advanced malware protection, content filtering and other inspection services on most outbound traffic. The latter should be sized with the Advanced Security performance figures in mind and with realistic headroom for peak use.
It is also useful to separate “features available” from “features required on every flow.” Some security controls may apply only to selected VLANs, user groups or internet-bound traffic. Other traffic, such as high-volume private replication between controlled sites, may follow a different policy. Understanding where inspection is applied can improve sizing accuracy without weakening security. The goal is not to turn protections off to fit a smaller appliance; it is to model the actual policy so the hardware is selected for the intended design.
Application visibility, QoS and SD-WAN path selection introduce another dimension. Voice and video may consume moderate bandwidth but have strict latency and loss requirements. Large file transfers can consume bandwidth yet tolerate delay. A Meraki deployment can use traffic policies to steer and prioritize these applications, but the firewall still needs sufficient throughput and session capacity. Therefore, sizing should combine volume with application criticality rather than treating every Mbps as identical.
When HTTPS inspection, cloud-delivered security integrations or third-party inspection services are part of the target architecture, confirm exact platform and license support at design time. These features can have platform-specific conditions, and the correct model may depend on more than the basic MX family table.
vMX sizing for cloud connectivity
vMX is the virtual member of the Meraki security and SD-WAN portfolio and is commonly considered for connecting cloud environments into an Auto VPN fabric. It should not be sized as though it were simply a physical MX with no ports. The primary questions are cloud traffic volume, number of participating VPN sites, routing requirements, cloud-provider architecture, high availability, expected east-west or north-south flows and the size of the applications reached through the vMX.
Cisco’s current sizing guide lists vMX Small, Medium and Large with firewall and VPN throughput figures of 250 Mbps, 500 Mbps and 1 Gbps respectively, along with recommended device counts of 500, 2,500 and 10,000. It also publishes different tunnel and session limits across those tiers. These numbers are useful for screening, but cloud design should also account for the cloud provider’s networking limits, routing tables, availability zones or regions, egress charges and the potential need for redundant virtual appliances.
A branch firewall and a vMX therefore solve different parts of the same topology. The branch may be limited by local devices and inspected internet traffic, while the vMX may be limited by aggregate VPN traffic from many sites. A complete SD-WAN project should size the spokes and cloud hub together so that a well-sized branch is not connected to an undersized cloud concentrator.
Legacy MX refresh: do not repeat an old sizing decision automatically
Many organisations already run Meraki MX appliances and approach a refresh by asking for the “new version of our current model.” That can be a useful starting point, but it should not be the final sizing method. Network workloads change significantly over a hardware lifecycle: internet circuits become faster, SaaS adoption grows, security inspection expands, wireless density increases and more users work remotely. A model selected for a five-year-old traffic profile may no longer represent the right capacity tier.
Firmware support is another reason to re-evaluate. Cisco publishes firmware-version restrictions by hardware platform, and several older MX models have maximum supported firmware trains. A refresh therefore offers an opportunity to move onto current hardware that can run newer Meraki features rather than simply matching historical throughput. The review should identify current model, firmware, license tier, active features, peak traffic, session counts, VPN topology and any operational pain points.
The newer Cisco Secure Router platforms with Meraki OS may also be relevant in refresh projects, especially where higher throughput, more active WAN paths or newer interface requirements are emerging. The correct migration path depends on the installed topology and feature set; not every environment should move to a different hardware family simply because it is newer.
A good refresh outcome preserves what works, removes capacity constraints, supports the target firmware and security roadmap, and avoids purchasing more appliance than the organisation can use. That requires current measurements rather than a one-for-one model substitution.
Build headroom into the design
Sizing exactly at today’s peak is rarely a sensible enterprise procurement strategy. Traffic grows, users add devices, cloud applications become more media-rich and security policies evolve. If a model’s inspected-throughput figure is only slightly above the current peak, the business may have little room for seasonal bursts, software updates, video-heavy events, new SaaS deployments or a second ISP upgrade.
Headroom does not need to be an arbitrary percentage applied to every site. It should be based on business change. A stable 20-person branch with a 100 Mbps service can justify less growth allowance than a new office expecting headcount to double. A retail branch may have predictable traffic but a headquarters site may add VPN branches every quarter. A hospitality property can see guest-device count vary dramatically with occupancy. The right reserve depends on what is likely to change first.
Capacity should also be checked for maintenance and failure states. If a branch normally spreads traffic across two WAN links, ask what peak load remains when one is unavailable. If a data-centre hub has two appliances for redundancy, confirm whether one appliance can carry the entire required load during failover. If remote users normally connect across multiple gateways, ensure the surviving endpoint can support an acceptable number of sessions.
This approach prevents two opposite errors: chronic undersizing and wasteful oversizing. The objective is a model with deliberate, explainable headroom tied to the network roadmap.
A practical Meraki sizing workflow
Measure current traffic
Record normal and peak internet, WAN and VPN throughput. Use several representative business days rather than a single snapshot. Separate internet-bound traffic from inter-site and remote-access flows where possible.
Count devices and sessions
Estimate laptops, phones, wireless guests, servers, IoT, cameras and infrastructure. Where available, review active-client and session data instead of relying only on employee numbers.
Define security policy
Decide whether Enterprise, Advanced Security or Secure SD-WAN Plus functionality is required, and identify which traffic will receive the most processing-intensive inspection.
Map VPN topology
Count branch tunnels, hubs, cloud concentrators and remote users. Document whether traffic is split-tunnel or full-tunnel and whether hubs must aggregate traffic from every site.
Check physical design
Confirm WAN circuits, handoff media, port speeds, transceivers, LAN core connectivity, rack space, power, HA cabling and cellular requirements.
Apply growth and failure headroom
Model the expected lifecycle, new sites, faster circuits and peak/failover conditions. Select the smallest platform that comfortably meets the complete requirement rather than one isolated metric.
What data should be collected from an existing Meraki network?
Existing Dashboard data can make sizing much more precise than estimates. Begin with appliance utilisation and uplink history: peak throughput, typical business-hour throughput, packet loss and uplink failover events. Then review the number of active clients, types of clients, application mix and whether specific VLANs create unusually high traffic. If a site experiences slowdowns, note the time and correlate them with bandwidth and user activity.
For VPN environments, document the number of Auto VPN peers, hub-and-spoke or full-mesh topology, aggregate tunnel traffic and the largest branch-to-hub flows. Remote-access deployments should capture maximum concurrent sessions and typical usage patterns. A workforce that mainly reaches a few internal web applications can have a very different VPN workload from engineers transferring large files or users running full-tunnel video meetings.
Record the current license edition and term, because a move to Advanced Security or Secure SD-WAN Plus can change both the commercial package and the effective performance requirement. Also list interface use: WAN 1, WAN 2, fibre ports, direct LAN connections, downstream switches, PoE needs and any external cellular gateway. The refresh model must support the physical design as well as the traffic.
Finally, record planned change rather than only current state. Upcoming ISP upgrades, office expansion, cloud migrations, new branches, new security controls and remote-work policies may be more important than today’s averages. The best sizing record is therefore a combined current-state and future-state worksheet.
Common sizing mistakes to avoid
Using only ISP bandwidth
This ignores NGFW performance, VPN throughput, clients and sessions. A circuit-speed match can still produce an undersized appliance.
Equating employees with devices
Each employee can use several endpoints, while guest Wi-Fi, IoT and infrastructure add devices with no corresponding headcount.
Ignoring enabled security
A platform’s basic firewall figure may be far higher than its NGFW prevention figure. Size for the security policy that will actually run.
Forgetting the VPN hub
Spokes may be comfortable while the central hub reaches tunnel, session or encrypted-throughput limits as the estate grows.
No failure-state calculation
A site may work well with two links but overload the remaining circuit or firewall capacity when one path fails.
Treating accessories as an afterthought
Wrong optics, power assumptions or port-speed mismatches can block installation even when the appliance itself is correctly sized.
When a larger Meraki platform should be evaluated
A larger model deserves evaluation when any major workload sits too close to the smaller model’s comfortable capacity. The obvious case is inspected throughput: if expected Advanced Security traffic approaches the published NGFW prevention figure, there is little room for growth or bursts. But there are less obvious cases. A site can justify a larger platform because device count, session scale, VPN tunnels or interface requirements exceed the smaller appliance even while internet bandwidth remains moderate.
A larger model can also be justified by the failure state. If the business must preserve full service during an ISP or appliance failure, the surviving architecture needs enough capacity for the combined workload. Headquarters sites may outgrow a platform through branch growth rather than local users. Each new branch increases VPN tunnel count and aggregate traffic at the hub, so the hub should be sized against the network roadmap, not only the number of sites on deployment day.
However, buying the largest platform is not automatically better. Oversizing can increase hardware and license cost without improving business outcomes. It may also introduce unnecessary rack, power or interface complexity for a small office. The best choice is the lowest model tier that meets all verified requirements with deliberate headroom.
When a smaller Meraki platform may be sufficient
A smaller platform can be appropriate when the site has genuinely low device density, modest peak traffic, limited VPN requirements and no near-term growth that would challenge the published capacity. This is especially true for small satellite offices where the WAN service itself is modest and the critical business applications are cloud-based. In such cases, paying for a much larger appliance may offer little operational value.
The decision should still be made using real metrics. If an office has 20 employees, 35–40 total devices, a 100 Mbps internet service and a small number of Auto VPN tunnels, a compact branch platform can be sensible. But if the same office is moving to a 1 Gbps circuit and enabling Advanced Security while adding guest Wi-Fi, the sizing result can change even without more employees.
This balanced approach is important because Meraki’s cloud-managed operating model is available across multiple hardware tiers. The goal is not to maximize appliance size; it is to choose capacity that fits the site and leaves appropriate room for planned change.
Dubai and UAE procurement considerations
For UAE deployments, sizing and procurement should be handled together. The selected appliance must match not only performance but also available ISP handoffs, rack and power standards at the site, delivery requirements, licensing term, support expectations and installation scope. Multi-site organisations should decide whether all branches are being refreshed at once or whether new models must coexist with an existing Meraki estate during a phased rollout.
Accurate quotation requires exact quantities and model intent. If the project needs high availability, specify that each site requires a pair of appliances even though an MX warm-spare pair uses one MX license. If fibre ports are required, identify the ISP or switch optic type and speed. If the site uses cellular backup, confirm whether the plan is integrated cellular on a supported model, an external Meraki MG gateway or another architecture. These details affect the bill of materials.
Licensing term should also be selected deliberately. A one-year term may suit a short project, but many organisations prefer multi-year alignment with hardware lifecycle and budget planning. Existing Meraki customers should provide the current organisation and licensing model details so that the new purchase can be checked for compatibility with the installed estate.
FourTeck UAE can support the sizing discussion, quotation preparation and deployment planning for Dubai and wider UAE projects. The sizing request is most productive when it includes current model, user/device count, bandwidth, VPN topology, security license tier and growth plan.
Deployment and migration planning after sizing
Selecting the hardware is only one stage of a successful firewall project. The migration plan should document WAN addressing, VLANs, static routes, DHCP roles, firewall rules, content policies, site-to-site VPN peers, remote-access settings, public services, port forwarding, identity integrations and monitoring requirements. Existing rule sets should be reviewed rather than copied blindly, particularly where old exceptions no longer serve a business purpose.
For HA deployments, the secondary appliance should be prepared in the Meraki Dashboard before it is physically introduced into the network, in line with Cisco’s documented deployment guidance. Uplink IPs, virtual IP requirements and downstream switch topology should be confirmed in advance. A maintenance window should include rollback criteria, testing steps and access to the ISP or upstream router configuration if WAN changes are required.
Testing should cover more than basic internet access. Validate Auto VPN, remote access, DNS, voice, video, public services, critical SaaS, inter-VLAN policy, failover between WAN circuits and, where applicable, failover between HA appliances. The goal is to prove that the new platform supports the capacity and resilience assumptions used during sizing.
After cutover, collect a new baseline of peak throughput, clients and sessions. This confirms whether the selected headroom is behaving as expected and creates useful evidence for future branch rollouts or upgrades.
Cisco Meraki firewall sizing FAQ
Which Meraki firewall should I use for a 1 Gbps internet connection?
There is no correct answer from circuit speed alone. MX75 and MX85 publish 1 Gbps firewall throughput, but their NGFW prevention figure is 500 Mbps. If the goal is to sustain close to 1 Gbps while Advanced Security inspection is active, a larger platform or newer Secure Router may be required. Device count, sessions, VPN traffic, interfaces and growth should also be checked before selection.
Is MX75 or MX85 better for a medium office?
Both currently publish 1 Gbps firewall throughput, 500 Mbps NGFW prevention throughput and 1 Gbps VPN EMIX throughput. However, MX85 has a higher recommended device count and a much larger maximum concurrent-session figure. If the office has many endpoints or flow-heavy applications, MX85 can offer more capacity even though the headline throughput looks similar. Interfaces and deployment requirements should be compared as well.
How many devices can an MX67 or MX68 support?
Cisco’s current sizing guide lists a recommended maximum device count of 50 for MX67/MX68. This is a sizing recommendation, not a simple hard cutoff, and the workload created by those devices matters. The same guide publishes 25,000 maximum concurrent sessions and 300 Mbps NGFW prevention throughput. A site approaching several of these boundaries should consider the next tier rather than focusing on only one number.
Does enabling Advanced Security reduce effective throughput?
Cisco publishes lower NGFW throughput figures for security inspection than the basic firewall throughput on many models. Therefore, if intrusion prevention and related Advanced Security controls are required, the NGFW prevention figure should be considered during sizing. It is not enough to compare only the highest firewall number with the ISP bandwidth.
Do I need two licenses for an MX high-availability pair?
Cisco documents that an MX warm-spare HA pair requires one MX license for the pair. The spare hardware itself is still required, and both appliances need correct uplink addressing and LAN connectivity. The commercial and topology details should therefore be included in the quote even though a second MX license is not normally required for the warm spare.
How many Auto VPN tunnels can Meraki MX support?
The number varies significantly by model. Cisco publishes both maximum and recommended site-to-site tunnel counts. Current recommended values range from 50 on MX67/MX68 to 1,500 on MX450, with intermediate limits across MX75, MX85, MX95, MX105 and MX250. Hub designs should use the recommended active-traffic figures and should also account for aggregate VPN throughput and route scale.
Can a Meraki firewall be oversized?
Yes. A much larger appliance than the site needs can increase hardware and licensing cost without creating a meaningful operational benefit. Sizing should identify the smallest platform that satisfies inspected throughput, devices, sessions, VPN, interfaces, resilience and expected growth with comfortable headroom. Oversizing should be tied to a documented future requirement rather than uncertainty.
Should a new project compare Cisco Secure Routers with Meraki OS?
Yes, where the use case fits. Cisco’s current sizing material includes the C8111/C8121, C8355 and C8455 Secure Router platforms, with higher throughput and different WAN/interface characteristics across the range. A new deployment or refresh should compare current options rather than assume the classic MX family is the only path.
What information is needed for a Meraki sizing quotation?
Provide site quantity, current and planned WAN bandwidth, user and device counts, peak traffic, existing Meraki model if any, desired license edition and term, number of VPN peers, remote-access users, HA requirement, uplink media and port speed, cellular needs, expected growth and whether installation or migration support is required. These inputs allow a model recommendation to be justified instead of guessed.
Does a 10 Gbps firewall rating mean 10 Gbps with all security features?
No. Published firewall and NGFW figures are separate. For example, MX450 currently publishes 10 Gbps firewall EMIX throughput and 5 Gbps NGFW prevention EMIX throughput. C8455-G2-MX publishes 20 Gbps firewall EMIX and 8 Gbps NGFW prevention EMIX. Security-heavy designs should use the relevant inspection figure and then apply practical headroom.
Can Meraki handle more than two WAN links?
Supported Cisco Secure Router models can provide multi-uplink capability with the required firmware. Cisco currently documents three active uplinks on C8111/C8121 models, with integrated cellular providing an additional path on relevant variants, and four active uplinks on C8455. Exact behavior, Auto VPN support and software requirements should be confirmed for the target platform and firmware.
What is the difference between sizing a branch and sizing a hub?
A branch is often driven by local clients, internet inspection and a relatively small number of VPN tunnels. A hub aggregates traffic and tunnel relationships from many branches, so VPN throughput, tunnel count, route scale, remote access and high availability become more important. The same Meraki model can therefore be comfortable as a branch but unsuitable as a central hub.
Decision recap
What FourTeck needs for an accurate Meraki sizing quotation
Number of branches, hubs, data-centre or cloud locations.
Current and planned counts, including guest and IoT endpoints.
Primary and secondary circuit speeds plus expected upgrades.
Enterprise, Advanced Security or Secure SD-WAN Plus requirement.
Site-to-site peers, hubs and maximum concurrent remote users.
Copper/fibre handoff, port speeds, optics and downstream switching.
Single appliance or warm-spare pair and required failure-state capacity.
Current model, license model, firmware and organisation details where relevant.
Supply only, configuration, migration, installation, testing and support needs.
Get a Cisco Meraki firewall size that matches the real network
A reliable Meraki recommendation should explain why a model fits your throughput, devices, sessions, VPN topology, security tier, interfaces, resilience target and future growth. Share the site profile with FourTeck and we can help turn those requirements into a practical UAE model shortlist and quotation.