The Router Cupboard Is Part of Your Cloud Estate
Photo: Jaggery , CC BY-SA 2.0, via Wikimedia Commons
There is a particular kind of quiet in a UK office when the cloud is fine and the internet is not. The provider status page is a soothing green. The finance system is definitely running somewhere. But the team is gathered around a printer, checking whether the Wi-Fi password changed, while someone on mobile data says, “It’s working for me.”
That gap — between the cloud service and the people trying to reach it — is the last mile. It is also the part of cloud resilience that often gets left out of the risk register because it feels like an IT problem rather than a cloud problem. It is both. If your staff cannot reach the service, the service may as well be down.
The bit of the cloud you actually touch
Cloud providers are responsible for a lot. They are not responsible for the fibre entering your building, the router in the cupboard by the loos, or the backup line that was installed during a previous office move and has not been touched since.
For most UK businesses, the cloud estate is really a chain: device, office network, local internet circuit, ISP, internet exchanges, cloud provider, and back again. The provider may have redundancy across availability zones. Your office may have one fibre line and a hopeful expression.
That is not a reason to panic. It is a reason to be specific. A last-mile resilience review is less about buying more kit and more about knowing what you already have, where it fails, and what the team will do when it does.
Three failure modes that hide in plain sight
One fibre, one story
A single business broadband circuit is common and often perfectly adequate. The problem starts when nobody can say whether the backup circuit is genuinely separate. Two lines from the same provider can share ducts, cabinets and exchanges. A second line in the same building may be diverse on the invoice and not diverse in the ground.
Ask for the physical path, not just the product name. If the answer is vague, treat the line as single-provider until proven otherwise. That does not mean replacing it immediately. It means writing down the assumption and planning around it.
The failover that exists on paper
Automatic failover is a lovely phrase. In practice, it may depend on a router configuration from three office moves ago, a SIM that expired, or a switch that nobody has labelled. The only failover you can trust is one you have tested, timed and documented.
A useful test does not need to be dramatic. Pick a quiet Tuesday morning. Disconnect the primary circuit. Watch what happens. Note how long it takes for the backup to come up, which services break, whether voice calls survive, and who gets alerted. Then write it down. If the test causes chaos, congratulations: you have found the problem on a Tuesday rather than during a month-end deadline.
5G backup with a data cap
5G backup is a sensible option for many UK offices, especially where fixed-line diversity is expensive or slow to install. But it is not a magic replacement for fibre. It has coverage quirks, data caps and throttling. A backup link that runs out of data after two days of normal use is not a resilience plan; it is a countdown timer.
Check the tariff, not just the signal bars. What is the monthly data allowance? What happens when it is used up? Is the SIM in a router with an external antenna, or is it sitting in a cupboard behind a metal filing cabinet? Who pays the bill, and what happens if it auto-suspends?
A last-mile resilience audit you can finish
You do not need a week-long project. A half-day with the right people will get you most of the way.
- Draw the circuit map. For each office, list the provider, product, media type, contract owner, support number and entry point into the building. Include any 4G or 5G backup.
- Check physical diversity. Ask whether the backup circuit shares a duct, cabinet or exchange with the primary. If the provider cannot confirm it, record that as a known risk.
- Open the router cupboard. Look for unlabelled boxes, daisy-chained extension leads, missing UPS batteries and a tangle of cables that would make a patch panel weep. Label the important bits.
- Test failover quarterly. Put it in the calendar. Test in business hours, not at 2am, because you want to know what your team experiences. Time the recovery and note what broke.
- Review the 5G plan. Confirm data cap, throttling policy, coverage at the office, antenna placement and who owns the SIM. Consider a low-bandwidth mode for outages: email and voice first, video calls later.
- Map dependencies. Does your DNS, proxy, VPN or voice service depend on the same circuit? A backup line is less useful if the thing that resolves your cloud address is also down.
- Write the office playbook. Who declares an outage? How do staff get told? Where do they go if the office is offline? A simple one-pager beats a perfect document nobody reads.
Questions worth asking procurement
The last-mile conversation is often a procurement conversation in disguise. When the next renewal comes around, ask:
- Is the backup circuit from the same provider, and does it share physical infrastructure?
- What is the restoration priority for this service, and what credits apply if it misses?
- What is the 5G data cap, and what happens when it is reached?
- Who is allowed to change the router configuration, and where are the credentials held?
- What evidence will the provider give us after an outage?
None of these questions are exotic. They are just rarely asked in the same room as the cloud strategy discussion. That is the point.
Make it boring, then make it routine
The best last-mile plan is not heroic. It is a labelled router, a tested backup line, a 5G tariff with enough headroom, and a team that knows where the playbook lives. It is the sort of thing that never makes the slide deck and quietly saves the month-end.
Cloud resilience is not only built in data centres. It is also built in the cupboard by the loos, the contract folder and the calendar reminder nobody enjoys. Put the last mile on your cloud risk register, give it an owner, and test it before the next outage does it for you.