Growth planning and headroom — sizing the firewall for next year, not this week

A firewall sized for today’s traffic fails on tomorrow’s. Growth is the most common reason a firewall needs replacement or upgrade — not a hardware failure, not a feature gap, but a deployment that has outgrown the original sizing. The operator who plans for growth absorbs the increase gracefully; the operator who sized for today scrambles to add capacity when the firewall saturates.

This lesson covers the growth planning discipline — the dimensions along which a firewall deployment grows, the headroom calculation, the trigger points for capacity expansion, and the continuous planning process that catches growth before it becomes an emergency.

The dimensions of growth

The firewall deployment grows along several dimensions simultaneously:

• User count. The number of users behind the firewall grows. Each new user adds traffic, state entries, and potentially new applications.
• Traffic volume. Per-user traffic grows (richer applications, video, collaboration tools). Total traffic grows roughly linearly with user count, but per-user traffic can grow super-linearly as new applications are adopted.
• Number of sites. Branch offices, cloud VPCs, partner networks. Each new site adds VPN tunnels, BGP peers, and routing complexity.
• Feature adoption. New features turn on — TLS interception, advanced IDS rulesets, additional logging. Each feature adds CPU or storage cost.
• Compliance scope. New compliance regimes (PCI-DSS, HIPAA, SOC 2) add logging requirements, retention policies, and access controls.

Each dimension has its own growth curve and its own trigger point. The operator plans for the dimension that will saturate first.

The headroom calculation

The headroom is the difference between the deployment’s peak load and the firewall’s capacity. The rule of thumb is 50% headroom: the firewall should be capable of twice the deployment’s peak load.

headroom_factor = firewall_capacity / peak_load
target_headroom_factor = 2.0 (50% headroom)

For a deployment with peak throughput of 500 Mbps:

• Firewall capable of 1 Gbps: headroom factor of 2.0 (target met).
• Firewall capable of 800 Mbps: headroom factor of 1.6 (target missed).
• Firewall capable of 1.5 Gbps: headroom factor of 3.0 (overprovisioned; cost may be wasted).

The 50% target is the rule of thumb; some deployments require more (high-growth, bursty workloads), some less (stable workloads, predictable traffic).

The dimensions of headroom:

Trigger points for capacity expansion

The trigger point is the utilisation level at which the operator plans capacity expansion. The convention:

The trigger points give the operator time to act. Capacity expansion takes weeks (procurement, deployment, testing); the operator who plans at 70% has months of runway; the operator who plans at 95% has days.

# The current state of every dimension.
# Throughput: average and peak over the last 30 days.
# State table: current count and limit.
# CPU: average and peak over the last 30 days.
# Disk: usage and growth rate.
# IDS: kernel_drops and alert_queue.dropped.

Patterns of growth

The operator must understand the growth pattern to plan capacity:

• Linear growth. User count and traffic grow by a constant amount per month. The projection is straightforward: trend over the last 6 months, project forward.
• Exponential growth. User count and traffic grow by a constant percentage per month. The projection is more aggressive — the doubling time is constant.
• Step growth. Growth happens in discrete events — new office opens, new application adopted, new compliance regime. The projection is event-driven.
• Bursty growth. Steady most of the time, with periodic bursts (quarterly close, holiday shopping, end-of-month reporting). The projection must account for peaks.

The discipline: measure the deployment’s growth pattern; project forward; identify when the binding constraint will saturate.

The capacity plan

The capacity plan is a document that captures:

1. Current state. Every dimension, current utilisation, peak utilisation, growth trend.
2. Projection. Where each dimension will be in 6 months, 12 months, 24 months.
3. Trigger points. The utilisation at which expansion is planned, urgent, or emergency.
4. Expansion paths. The options when expansion is needed — more CPU, more RAM, faster NIC, additional firewall in HA pair, replacement.
5. Cost. The cost of each expansion path; the cost of saturation.
6. Review cadence. When the plan is reviewed — quarterly, annually.

The discipline: the capacity plan is reviewed at the cadence the growth pattern requires. A high-growth deployment is reviewed monthly; a stable deployment is reviewed quarterly.

# Capacity plan template (illustrative).
# Review date: 2026-08-14
# Next review: 2026-11-14 (quarterly)

# Current state
# Throughput: 450 Mbps avg, 780 Mbps peak (last 30 days)
# State table: 65,000 entries avg, 87,000 peak (last 30 days)
# CPU: 35% avg, 62% peak (last 30 days)
# Disk: 220 GB used of 500 GB (/var/)
# IDS: 0 kernel_drops, 0 alert_queue.dropped

# Projection (12 months)
# Throughput: 700 Mbps avg, 1.2 Gbps peak (assumes 50% growth)
# State table: 100,000 avg, 140,000 peak (assumes 50% growth)
# CPU: 55% avg, 90% peak (assumes 50% growth)
# Disk: 440 GB used (assumes 100% growth due to verbose logging)
# IDS: 0 kernel_drops expected (no growth planned)

# Trigger points
# Throughput: 700 Mbps avg -> plan expansion
# State table: 100,000 avg -> plan expansion
# CPU: 55% avg -> monitor quarterly
# Disk: 400 GB used -> expand storage

# Expansion paths
# 1. Upgrade CPU/memory (when CPU saturates): $5,000, 2 weeks lead time
# 2. Add faster NIC (when throughput saturates): $1,500, 1 week lead time
# 3. Add second firewall to HA pair (when HA is needed): $8,000, 4 weeks lead time

# Cost of saturation: 4-hour outage, ~$50,000 revenue impact.

Continuous capacity planning

The capacity planning discipline is continuous:

1. Measure. Every dimension is monitored continuously (Prometheus, Grafana). The trends are visible.
2. Project. Quarterly or monthly, the operator reviews the trends and projects forward.
3. Identify the binding constraint. Which dimension will saturate first?
4. Plan. When the binding constraint crosses the trigger point, plan expansion.
5. Act. When the binding constraint is at the urgent level, execute the expansion.
6. Review. After expansion, the new capacity is the new baseline; the planning cycle continues.

The discipline: the operator who treats capacity planning as a continuous process catches growth before saturation. The operator who treats it as a one-time exercise finds out about saturation from user complaints.

Warning signs that capacity is approaching

The warning signs that capacity is approaching:

• Peak utilisation rising over multiple months. The trend is the signal, not the absolute value.
• Burst-induced latency. Latency rises during bursts but returns to baseline after. The bursts are getting longer or more frequent.
• Suricata kernel_drops rising. The IDS is saturating during peaks.
• State table utilisation above 70%. The state table is approaching the limit.
• Disk usage above 80%. Logs are filling the disk.
• CPU saturation during business hours. The CPU is binding during normal operation.

The discipline: monitor these signals; investigate when they appear; plan expansion when the trigger points are crossed.

Verification

After implementing the capacity planning process, verify:

1. Every dimension has a current utilisation measurement — the operator can answer “what is our throughput / state table / CPU / disk usage right now?”
2. Every dimension has a projection — the operator can answer “where will we be in 6 months?”
3. Trigger points are defined — the operator can answer “when do we plan expansion?”
4. Expansion paths are identified — the operator can answer “what do we do when expansion is needed?”
5. The plan is reviewed at the cadence the growth pattern requires — the plan is alive, not dormant.

A capacity plan that meets 1-2 but fails 3-5 has measurement but no action. The operator monitors but does not plan.