The network is the dependency every other system has and the one least likely to have a current diagram. It is also where a small change has the widest reach, which is why network work attracts both the most caution and the most undocumented exceptions.
This page covers what managing network infrastructure involves across private and hybrid estates, and which parts most reliably cause incidents.
Know the topology, in a form that is true
A network diagram that was accurate at installation is a historical document. What is needed is a description that is maintained: addressing and what owns each range, routing and why it is the way it is, where the boundaries are and what enforces them, and which paths are genuinely redundant rather than nominally so.
The last of those is worth checking rather than assuming. Two circuits into the same building, through the same duct, from the same carrier, are one circuit with a larger invoice.
Address planning is a decision you make once
Private address space feels unlimited and is allocated as though it were, which is how organizations end up unable to connect to a partner, unable to complete an acquisition cleanly, or unable to peer two cloud networks without translation.
A plan that reserves ranges by environment, region and purpose, and that leaves room for growth, costs nothing at the start. Retrofitting one costs an outage per subnet. This is the clearest example in infrastructure of a decision whose cost is entirely determined by when it is made.
Segmentation is the control that limits a bad day
Flat networks are convenient and they mean that anything reaching one host can reach everything. Segmentation divides the estate so that a compromise or a misconfiguration is contained, and it is the control most likely to reduce the severity of an incident rather than its likelihood.
The design question is what the segments are for. Segmenting by department produces boundaries that do not match traffic. Segmenting by sensitivity and function produces boundaries that do, at the cost of a conversation about what belongs where that some organizations avoid for years.
The direction of travel in the wider industry is to stop treating the network boundary as the security boundary at all. NIST frames this explicitly: zero trust is a response to enterprise network trends that include remote users, bring your own device, and cloud-based assets that are not located within an enterprise-owned network boundary, and zero trust security models assume that an attacker is present in the environment. See NIST SP 800-207, Zero Trust Architecture. That does not make segmentation obsolete; it makes it one control among several rather than the control.
Firewall rules accumulate
Every rule was added for a reason. Very few are removed when the reason ends, and after a few years the rule base contains entries nobody can explain, referring to hosts that no longer exist, that nobody dares delete.
The discipline is to require a reason and an owner at the point a rule is created, and to review the base periodically against what actually matches. Rules with no hits in six months are the obvious candidates, and the review is far easier if logging was enabled when they were written.
Connectivity between environments
Hybrid estates depend on a link, and the design question is not bandwidth but what breaks when it fails. A link carrying replication degrades; a link carrying authentication or a synchronous database call stops.
Whichever it is, redundancy should be genuinely diverse, failover should have been tested rather than configured, and the failure mode should be understood by whoever is on call. Hybrid Cloud Infrastructure covers the wider picture.
Cloud providers describe their own diversity in physical terms, and the description is worth reading rather than assuming. Microsoft defines the unit plainly: an availability zone is a logical grouping of one or more physically separate datacenters within a region, each with independent power, cooling and networking. See Microsoft, What are availability zones?. That is a useful standard to hold your own circuits to. If two links do not differ in power, path and provider, they are not diverse in the sense that matters when one of them fails.
Load balancing is where availability is delivered
Load balancers distribute traffic and, more importantly, remove failed backends from rotation. That second function is the one that turns redundancy into availability, and it depends entirely on the health check being meaningful.
A health check that confirms a port is open will keep sending traffic to an application that is running and broken. A check that exercises a real path, including the dependency the application needs, will not. This is covered properly in High Availability and Load Balancing.
DNS is infrastructure, and is treated as an afterthought
DNS failures produce symptoms that look like everything else, which is why they are diagnosed late. It deserves the same treatment as any other critical system: redundant resolvers, monitored records, controlled and logged changes, and time-to-live values chosen deliberately rather than left at whatever a wizard suggested.
Time-to-live matters most during recovery. A record with a long value is cached by resolvers you do not control, so a failover that depends on a DNS change takes as long as the cache says it does. Recovery plans that assume an instant cutover frequently have not checked.
Certificates expire on a schedule and still cause outages
Certificate expiry is the most predictable outage in infrastructure. The date is known at issuance, the failure is total, and it still happens regularly because the renewal depended on a person, an inbox or a calendar entry that left with them.
Automated issuance and renewal solves most of it. An inventory of every certificate, including the ones on internal services and load balancers that automation does not cover, solves the rest. Monitoring expiry as a metric rather than relying on a vendor email is the cheap safeguard.
Change control, and the reason network changes are different
A bad server change affects a server. A bad network change can remove your ability to reach the thing you need to fix. That asymmetry is why network change deserves a heavier process than its size suggests: a tested rollback, an out-of-band access path, and a second person watching.
The out-of-band path is the part most often missing and most often needed. Console access that traverses the network being changed is not out of band.
Capacity, and what saturates first
Capacity planning for networks is usually described as bandwidth and is usually not bandwidth. Links rarely run out of throughput before something else runs out first: a firewall's connection table, a load balancer's concurrent sessions, a NAT gateway's port allocations, or the packets-per-second ceiling on a device sized for a different era.
Those limits are the ones that produce the confusing incident, because the graph everyone looks at shows plenty of headroom. The remedy is to know which limits exist on which device, and to monitor them alongside throughput rather than instead of it. A device at 30 percent of its rated bandwidth and 95 percent of its session table is about to have a bad afternoon.
Cloud networking is the same problem with different words
Virtual networks, security groups and route tables are the same concerns expressed differently: addressing, segmentation, routing and filtering. The differences worth knowing are that the boundaries are software-defined and therefore easy to change and easy to change wrongly, that egress is billed, and that default configurations are permissive in ways that on-premises equipment usually is not.
The advantage is that the entire configuration can be expressed as code and reviewed, which is not true of most physical estates. Estates that take that up get reproducibility and an audit trail for free; estates that click through a console get neither.
Where network management stops and security operations begins
Configuring segmentation, maintaining rule bases and operating connectivity is infrastructure work. Detecting hostile traffic, investigating it and responding is security operations, covered in Managed Cybersecurity Services and in that cluster's Network Security page.
They overlap at the data: the same flow logs serve both. They differ in what is being asked of the data, which is why running them as one function usually means one of the two questions stops being asked.
Inheriting an estate nobody documented
Most network work begins with an estate somebody else built, often years ago, with the people who understood it long gone. The instinct is to redesign. The better first move is to describe what is there accurately enough that a change can be reasoned about, because a redesign built on a wrong assumption inherits the assumption.
That description comes from the devices rather than from anyone's memory: configuration exports, routing and ARP tables, rule hit counts, flow data, and the discrepancies between them. The discrepancies are the useful part. A route to a network that no longer exists, a rule permitting a host that was decommissioned, an interface carrying traffic nobody can account for. Each one is either a finding or a system somebody forgot to mention.
Documentation is the deliverable
The output of good network management is that somebody who was not there can understand the estate. A current topology, an address plan, a rule base with reasons, a certificate inventory and a change history are what make that possible.
They are also what make an incident survivable when the person who built it is unavailable, which is the scenario worth designing for. The infrastructure capability this network work supports sets out where it sits alongside the rest.