Your Cloud Is Redundant. Is Your Internet Connection?

Modern engineering teams spend enormous amounts of time eliminating single points of failure.

Applications are distributed across availability zones. Databases are replicated. Load balancers redirect traffic when systems fail.

Backups are automated, infrastructure is defined as code, and monitoring systems are designed to detect problems before users notice them.

Yet for many engineers working remotely, access to all of that resilient infrastructure still depends on one surprisingly fragile component: a single broadband connection.

The cloud may have failover. The person responsible for it often does not.

The Last Mile Is Still Part of the Infrastructure

Moving infrastructure to the cloud changed where systems run, but it did not eliminate the physical network required to reach them.

A developer connecting to a cloud console, an SRE responding to an alert or an engineer accessing a production environment still needs a functioning path from their home to the wider internet.

That path begins with the last-mile connection serving their address.

If that connection fails, it may not matter that the application itself is operating perfectly across several availability zones. The engineer can be effectively disconnected from the systems they are responsible for managing.

For teams with employees distributed across cities or countries, this moves part of the reliability problem outside infrastructure the company directly controls.

A Second ISP Does Not Always Mean Full Redundancy

The obvious solution appears simple: get a second internet connection.

But connectivity redundancy is not necessarily as straightforward as having two ISP names on two bills.

Depending on the market, providers can share portions of the infrastructure used to reach customers. Two retail services may use the same underlying wholesale network, physical route or other common infrastructure.

A failure affecting that shared component could therefore disrupt both connections.

“People tend to think of internet redundancy in terms of providers, but the underlying connection matters just as much,” says Tomas Novosad, CEO and founder of Home Internet Plans. “If two services ultimately depend on some of the same infrastructure, adding the second provider may not protect you from the failure you’re trying to prepare for. The more important question is whether your backup actually gives you a different path when the primary connection goes down.”

For engineers applying reliability principles to their own connectivity, that distinction matters.

Think in Failure Domains

Cloud engineers already understand this concept.

Running two virtual machines in the same availability zone provides some redundancy against an individual machine failing. It does not provide the same protection against an availability-zone failure.

Home connectivity can be viewed in a similar way.

Two connections using different technologies may have fewer shared failure points than two services dependent on the same local infrastructure.

For example, a fiber connection backed by cellular connectivity creates a different failure profile from two connections sharing the same wired access network.

Neither configuration guarantees uptime. A local power failure, damaged infrastructure, provider outage, router failure or wider network problem can still cause disruption.

The objective is not to create an “unbreakable” home connection. It is to avoid designing a backup that fails for exactly the same reason as the primary.

Failover Should Be Automatic

Having a backup connection is also less useful if switching to it requires rebuilding the network while an incident is already underway.

Dual-WAN routers and other network equipment can monitor a primary connection and move traffic to a secondary connection when connectivity is lost.

For a remote engineer, automatic failover can turn a broadband failure from a complete loss of access into a temporary interruption.

The configuration still needs testing.

Does the secondary connection activate correctly? How long does failover take? Does the VPN reconnect? Can critical tools still be accessed? Does traffic return cleanly to the primary connection when service is restored?

A backup that has never been tested is an assumption, not redundancy.

That principle should sound familiar to anyone responsible for disaster recovery.

Bandwidth Is Not the Only Consideration

The backup connection does not necessarily need to match the primary connection’s speed.

A developer might normally use a gigabit fiber service, but maintaining another gigabit connection purely for emergencies may provide little additional value.

The backup only needs enough capacity to keep critical workflows operating.

That could mean accessing cloud dashboards, communicating through Slack or Teams, connecting through a VPN, using SSH, reviewing monitoring data or pushing an emergency configuration change.

For that reason, a slower connection delivered through genuinely different infrastructure may provide more useful resilience than another high-speed service with overlapping failure points.

Reliability and maximum throughput are different objectives.

Power Is Another Failure Domain

Internet redundancy can also disappear when the electricity goes out.

A second wired ISP does little good if the modem, router and networking equipment for both connections lose power simultaneously.

For engineers who genuinely require connectivity during incidents, a small uninterruptible power supply can keep essential networking hardware operating through shorter power interruptions

Cellular backup introduces another option because the access network itself is independent of the wired connection, although the equipment inside the home still requires power.

Again, the goal is to think beyond individual components and consider what can cause multiple components to fail together.

Apply SRE Thinking to the Connection

Site Reliability Engineering is built around accepting that systems fail and designing accordingly.

Home internet should not be treated differently when someone’s ability to perform a critical engineering role depends on it.

That does not mean every remote developer needs two ISPs, enterprise networking equipment and battery backup. The appropriate level of redundancy depends on the consequences of losing connectivity.

But teams should at least understand the dependency.

If an engineer participates in an on-call rotation, manages production infrastructure or needs to respond quickly during incidents, their internet connection has effectively become part of the operational chain.

Organizations can therefore ask the same questions they would ask about any other dependency:

What happens when it fails?

What is the backup?

Does the backup share the same failure domain?

Has failover actually been tested?

Redundancy Should Extend Beyond the Cloud

Cloud infrastructure has made it possible to build extraordinarily resilient systems without owning a single physical server.

But humans still need a physical network to reach them.

For remote engineering teams, that makes the last mile an easily overlooked part of the reliability architecture.

Your application may survive a server failure. Your database may survive an availability-zone outage. Your infrastructure may even survive the loss of an entire region.

But if the engineer responding to the incident has one connection and that connection disappears, all of that redundancy suddenly feels a lot further away.

The cloud may be redundant.

It is worth asking whether the path you use to reach it is too.