Page 1 of 2
Once a system needs to run across multiple regions - for latency, for redundancy, or both - networking stops being something you configure once and becomes something you actively design. The central tension is that keeping data consistent across regions and keeping the system fast and available are pulling in opposite directions: every cross-region round trip costs real latency (tens to hundreds of milliseconds depending on distance), so the naive approach of just replicating every request to every region gets expensive fast.
Real designs pick a topology deliberately rather than defaulting to one. Active-active runs every region live and serving traffic simultaneously, maximizing availability and letting users hit their nearest region, but it forces hard decisions about data consistency between regions that are both accepting writes at once. Active-passive keeps one region as the source of truth and others on standby, which sidesteps the consistency problem but means failover is a real event with real risk, not a seamless non-event. Neither is strictly better - it's a judgment call based on what the system actually needs: raw availability, strict consistency, or lowest possible latency, because you generally cannot maximize all three across a network with real physical distance in it.
A service mesh takes the cross-cutting networking concerns that used to live inside application code - retries, timeouts, mTLS, traffic metrics, circuit breaking - and moves them into infrastructure, via a sidecar proxy deployed alongside every service instance. Every bit of network traffic in and out of a service passes through its sidecar first, which is what lets the mesh enforce and observe behavior consistently without every team reimplementing the same logic in every service's own codebase.
This builds directly on the service discovery and health checking that Kubernetes networking (hard tier) already provides - a mesh doesn't replace that, it adds a uniform policy and observability layer on top of it. Two capabilities are worth calling out specifically. mTLS everywhere means every service-to-service connection is mutually authenticated and encrypted by default, not just the boundary at the internet - which is a meaningfully stronger security posture than "encrypt at the edge, trust everything internal," and it's the natural mesh-scale version of the network segmentation discussed in the hard tier. Traffic shaping - canary releases, weighted traffic splits, fault injection for testing - becomes something you configure declaratively at the mesh level rather than something each service has to implement for itself.
The real tradeoff to be honest about: a mesh adds genuine operational complexity and a real latency cost (every hop now passes through an extra proxy), and it's worth deploying deliberately for the specific problems it solves - not adopted by default just because it exists.
SDN (Software-Defined Networking) separates the control plane (deciding how traffic should flow) from the data plane (actually moving the packets), letting network behavior be defined in software and changed programmatically rather than requiring manual configuration of physical switches and routers. This is the foundational idea underneath most modern cloud networking.
VPC peering connects two virtual networks so resources in each can talk to each other by private IP as if they were one network - useful, but it doesn't transitively chain (peering network A to B and B to C does not let A reach C), which is a common source of "why can't these reach each other" confusion at scale, and it's a real design constraint once you're managing many VPCs.
Container networking is SDN applied at an even finer grain: an overlay network creates a virtual network spanning multiple physical hosts, letting containers on different machines communicate as if they were on the same local network, encapsulating that traffic inside regular IP packets to actually cross the underlying physical network. The tradeoff is a real one - overlay networks add encapsulation overhead (packing a packet inside another packet) that shows up as extra latency and lower effective MTU, which ties directly back to the MTU fragmentation issue from the hard tier: overlay networks are one of the most common places that problem actually shows up in practice.
Traditional network security draws a hard perimeter and trusts everything inside it - get past the firewall, and you're broadly trusted. Zero trust rejects that assumption entirely: no request is trusted by default just because of where it originated, including from inside the network. Every request is authenticated and authorized on its own merits, every time.
In practice this means identity-based access control rather than network-location-based access control - a service proves who it is (often via mTLS certificates, tying directly back to service mesh identity) rather than being trusted just because its packet came from an internal IP range. It also generally means the smallest reasonable blast radius by default: a service gets access only to the specific things it needs, not blanket internal network access, which is network segmentation (hard tier) taken to its logical extreme rather than a separate idea. The operational payoff is real: a compromised service can't simply pivot to attack everything else reachable from the same network the way it could under perimeter-only trust - but it does mean identity and policy infrastructure become genuinely load-bearing, not an optional add-on, so their own availability and correctness now matter as much as the network itself.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.