Continuity / Perimeter
Your perimeter doesn't go down because one box did.
A single firewall is a single point of failure for three things at once: your internet egress, the tunnel to your plant and your remote people's access. We leave you with two, in separate availability zones, with their configuration in sync and the failover tested before we touch your production.
What goes down with it
| When the single box fails | What stops |
|---|---|
| Internet egress | Email, SaaS, updates, telemetry |
| Site-to-site tunnel | The plant loses the ERP and the MES |
| User VPN | Nobody gets in from outside, including whoever has to fix it |
It isn't three risks. It's one, three times.
What stays up
Two nodes, one in each availability zone. Configuration replicates between them automatically, so the passive node isn't a three-month-old copy; it's the same firewall.
- Two zones. If a whole zone degrades, the other one already carries the traffic.
- Synchronized configuration. Rules, policies and network objects live on both nodes. No manual drift.
- Deployed as code. The entire architecture comes from versioned templates, so it can be audited, rebuilt and redeployed.
What's in scope
- Included. Analysis of your current rules, policies and network objects. An active-passive cluster across two availability zones, deployed as code. A full build and failover test in an isolated sandbox before production. A cutover plan with its rollback.
- What we need from you. An export of your current firewall configuration, people from your network and security teams for the tests, and an agreed window for the cutover.
How we operate
We capture what you have today
We collect the live configuration of your current firewall: rules, security policies and network objects. We don't start from a clean-sheet design, we start from yours, because the rules nobody documented are the ones that sink a cutover.
We design the topology
Subnet segmentation, routing, interfaces and internet egress. This is where the requirements the design has to meet get written down, and it is tested against them later.
We build it and break it in an isolated environment
We write the infrastructure as code and deploy it to a sandbox, not to your production. There we configure the cluster, sync the configuration between nodes and cause the failure on purpose until the failover behaves the same way every time. Whatever breaks, breaks there.
Cutover plan and go-live
A document with the steps, who runs each one and the criteria for aborting. You set the window. Cutover day isn't the first time we see the failover work; it's the last.
After go-live
A high-availability perimeter degrades on its own. Firmware ages, someone changes a node by hand, the rules drift out of sync, and the failover stops working without telling anyone. The day you find out is the day of the real outage.
That's why the project ends and operations begin. Managed Cloud Team can take over the cluster: monitoring, patches, keeping the nodes in sync and scheduled failover tests.
Questions
How long will my operation be down during the cutover?
The cutover happens within the window you set. Before it opens, the plan is already written: the steps, the timings and the rollback procedure.
Is this the same as a disaster recovery plan?
No. High availability means a component fails and traffic keeps flowing. Disaster recovery means you lose an entire site and can bring the operation up in another. One doesn't replace the other. If the second one is what keeps you up at night, the page you're looking for is Disaster recovery.
Does my public IP change when the firewall fails over?
No. Egress runs through an address that moves to whichever firewall is active, so your partners, your SaaS allowlists and your plant tunnel keep seeing the same IP after a failover.
A 30-minute call.
Tell us what you have on your perimeter today, and we'll tell you whether this applies or whether you're solving a different problem.