Change an answer.Watch the whole design recalculate.

This design uses eight VLANs because the school has eight functionally distinct populations of devices with different trust levels, traffic patterns, and management needs — not because eight is a target number. Splitting them lets the firewall apply different rules to each without one bad actor (a compromised camera, a guest laptop) having a path to staff data or the servers.

The sizing follows directly from headcounts you gave us, with buffers added for realism rather than invented. Staff (10.110.0.0/25, sized for 98) comes from 50 staff at roughly 1.3 devices each — a laptop plus occasional desktop or tablet. Students (10.115.0.0/22, sized for 788) comes from 500 1:1 devices plus a working assumption of spares and loaners, which is why the multiplier there is larger than staff's. Voice (10.120.0.0/25, sized for 84) assumes one physical handset per staff member plus shared phones in common areas and conference rooms — if the school instead plans to run voice as a soft-phone app on staff laptops, this VLAN is oversized and the traffic actually belongs in Staff. Printers (10.12.0.0/28... 10.125.0.0/28, sized for 8) assumes roughly one networked device per twelve staff, a rule-of-thumb ratio, not a count you gave us directly. Cameras (10.130.0.0/26, sized for 36) is anchored to the 24 cameras you specified plus a recorder and headroom. Guest (10.220.0.0/23, sized for 413) assumes roughly half the combined staff-and-student population is present with a personal device at any one time — reasonable for a school, but worth checking against your actual visitor and BYOD volume.

Management (10.10.0.0/26) and Servers (10.12.0.0/28) are sized for infrastructure, not people: about 24 access points and 12 switches plus the firewall on the management VLAN, and a small on-premise server footprint on the server VLAN. Given the stated preference for cloud management, we've assumed most of the school's actual services (identity, filtering, backup, monitoring) live off-site, and the on-prem server VLAN only needs to host what genuinely must stay local. If that assumption is wrong — if there's a plan to run more on-prem infrastructure than eight devices' worth — that VLAN will need to be resized before it's built out.

The design doesn't invent isolation for VLANs where none was specified — printers, for instance, sit on their own VLAN for addressing cleanliness but have no stated deny rules, which is worth a second look given how often print devices are the weak point on a network.

You told us this is a greenfield project driven by "new" — there's no existing network to migrate, which simplifies rollout but means every isolation rule has to be built correctly the first time; there's no fallback "it used to work" configuration to compare against.

Addressing alone does not enforce anything. Putting cameras on 10.130.0.0/26 and guests on 10.220.0.0/23 only creates the boundary — the deny rules listed in the brief have to be configured on the firewall (or a routing switch capable of ACLs) exactly as specified, both directions where relevant. In particular: cameras must be denied all listed destinations and the internet, with only the recorder permitted, and guest must be denied all internal VLANs with only internet permitted. Test both rule sets by attempting to reach a blocked destination from a device on each VLAN after cutover, not just by reading the config back.

Because management preference is cloud, the devices on 10.10.0.0/26 (access points, switches, firewall) will need outbound reachability to whatever cloud controller or dashboard you choose — confirm the firewall's default posture doesn't accidentally block that path while enforcing the other deny rules.

On wireless: staff, student, and guest traffic all ride the same radios but need separate SSIDs mapped to 10.110.0.0/25, 10.115.0.0/22, and 10.220.0.0/23 respectively. Get this mapping right in the AP configuration — a misconfigured SSID-to-VLAN binding is the single most common way guest and staff traffic end up mixed in practice.

On wired ports serving handsets, use LLDP-MED or CDP-based voice VLAN assignment so phones land on 10.120.0.0/25 automatically rather than relying on manual port configuration per desk.

Printers have no isolation rule specified. Decide deliberately whether that's acceptable — an unmanaged printer with staff-VLAN-wide reachability is a common route for lateral movement, and it's worth applying the same restrictive logic used for cameras if these are shared or ageing devices.