Cloud and Data-Center Networking

Introduction and Context

Cloud computing has changed networking from a largely hardware-centred discipline into a programmable, distributed systems discipline. A modern data centre may simultaneously support virtual machines, containers, storage traffic, databases, high-performance analytics, public-facing applications, and cross-region replication. These workloads require high bandwidth, predictable latency, rapid provisioning, isolation, automation, and controlled cost.

Traditional three-tier data-centre networks were designed around north–south traffic: clients entered through access and aggregation layers and applications were reached through a core. Contemporary applications generate substantial east–west traffic between services, databases, caches, and observability systems. Consequently, scalable data centres commonly use a leaf–spine fabric, while cloud and container platforms use software-defined overlays to separate logical network design from physical topology.

This chapter examines virtual networks, leaf–spine architectures, VXLAN/EVPN, cloud connectivity, container and Kubernetes networking, service meshes, multi-cloud design, and cost-aware scaling. The central design challenge is not merely connectivity. It is the simultaneous management of performance, availability, security, operability, portability, and economic efficiency.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Explain how virtualization and software-defined networking create logical networks over physical infrastructure.
2. Design and evaluate a leaf–spine data-centre fabric.
3. Describe VXLAN encapsulation and EVPN control-plane operation.
4. Compare cloud connectivity options and select suitable architectures.
5. Explain container and Kubernetes networking, including Services and network policies.
6. Analyse the role and limitations of service meshes.
7. Design multi-cloud connectivity with attention to routing, security, resilience, and cost.
8. Apply quantitative reasoning to capacity, availability, latency, and bandwidth decisions.

1. Virtual Networking as an Abstraction

A physical network forwards frames and packets through switches, routers, links, and network interface cards. A virtual network presents logical interfaces, segments, routes, and security policies that may not correspond one-to-one with physical devices.

A hypervisor can create virtual network interfaces (vNICs), virtual switches, port groups, and virtual routers. A virtual machine sends a frame through its vNIC to a virtual switch; the frame may then be forwarded locally, passed to a physical interface, or processed by a virtual network function such as a firewall. Cloud platforms extend this model with virtual private clouds (VPCs), subnets, route tables, security groups, load balancers, and private endpoints.

The principal abstractions are:

• Tenant or project: an administrative boundary for users, resources, quotas, and billing.
• Virtual network: a logically isolated address space and routing domain.
• Subnet: a partition of an address space, usually associated with a failure domain or availability zone.
• Virtual router: software that performs Layer 3 forwarding between logical networks.
• Security group: a stateful policy applied to virtual interfaces or workloads.
• Network function virtualization: implementation of functions such as firewalls, NAT, VPN gateways, and load balancers in software.
• Software-defined networking (SDN): separation of forwarding from centralized or logically centralized control and programmable policy management.

Isolation can be implemented through VLANs, VXLAN segments, VRFs, ACLs, cryptographic tunnels, or combinations of these. Isolation is not identical to encryption: a separate VLAN may reduce accidental communication but does not by itself protect traffic from a privileged or compromised infrastructure operator.

Addressing and Routing Design

Cloud and data-centre addressing should be hierarchical, summarizable, and compatible with growth. IPv4 planning must account for reserved addresses, subnets, dual-stack operation, and future expansion. IPv6 provides a much larger address space but does not eliminate the need for segmentation, route control, or policy.

A route table can be viewed as a function that maps a destination prefix to a next hop and interface. Longest-prefix matching selects the most specific matching route. For example, a route to 10.20.0.0/16 is less specific than a route to 10.20.4.0/24; traffic for 10.20.4.8 follows the /24 route when both are present.

VRFs allow multiple independent routing tables on one physical router. They are useful for tenant separation, management-plane isolation, and overlapping address spaces. However, overlapping addresses complicate troubleshooting and interconnection; translation or controlled route leaking may be required.

2. Leaf–Spine Data-Centre Fabrics

A leaf–spine fabric is a two-stage Clos-style topology. Every leaf switch connects to every spine switch, while leaf switches connect to servers, storage, firewalls, and external routers. Spines generally do not connect directly to endpoints. Traffic between two endpoints attached to different leaves traverses one spine and therefore has a predictable number of hops.

Figure: A leaf–spine fabric provides predictable paths and multipath connectivity.

Capacity and Oversubscription

A leaf’s uplink capacity may exceed its downlink capacity. The ratio is commonly called oversubscription. If a leaf has n server-facing links, each of bandwidth d, and m spine-facing links, each of bandwidth u, a simple nominal ratio is:

The expression assumes all links are simultaneously usable, have comparable bidirectional capacity, and that the design compares aggregate access capacity with aggregate uplink capacity. A ratio of 4:1 means access-facing nominal capacity is four times uplink capacity; it does not predict actual application throughput. Workload locality, traffic distribution, packet size, congestion control, and failure conditions matter.

For example, 24 server links at 25 Gb/s and 6 uplinks at 100 Gb/s produce (24 × 25) ÷ (6 × 100) = 600 ÷ 600 = 1:1 nominal oversubscription. If only three uplinks are usable during maintenance, the effective ratio becomes 2:1.

Equal-cost multipath (ECMP) distributes flows across multiple next hops. Hashing typically selects a path using fields such as source and destination addresses and ports. A single large flow generally remains on one path to avoid packet reordering, so aggregate capacity scales better than the capacity of an individual flow.

Layer 2 and Layer 3 Fabrics

A Layer 3 fabric routes between leaves and spines, often using BGP or an interior gateway protocol. It limits broadcast domains and improves failure containment. Layer 2 extension may still be required for particular workloads, but large stretched Layer 2 domains increase broadcast, unknown-unicast, and failure-propagation risks.

A sound design keeps the physical underlay simple, uses loop prevention appropriate to the selected protocol, automates configuration, and observes link, route, queue, and control-plane health. The underlay should not depend on undocumented behaviour in the overlay.

3. VXLAN and EVPN Overlays

VXLAN, or Virtual Extensible LAN, carries an Ethernet frame inside a UDP packet. It enables logical Layer 2 segments to span a routed IP underlay and uses a 24-bit VXLAN Network Identifier (VNI), allowing many more segments than the 12-bit VLAN identifier space.

The encapsulation path is:

1. An endpoint sends an Ethernet frame to a tunnel endpoint.
2. The ingress VTEP (VXLAN Tunnel Endpoint) adds a VXLAN header.
3. The packet is placed inside UDP and an outer IP header.
4. The routed underlay forwards the packet to the egress VTEP.
5. The egress VTEP removes the outer headers and delivers the original frame.

VXLAN adds overhead, commonly about 50 bytes for IPv4 outer encapsulation, although the exact value depends on headers and options. The physical MTU must therefore be large enough for the inner packet plus encapsulation. If an inner payload has size P and the encapsulation overhead is H, the required physical payload capacity is at least P + H. Fragmentation and path-MTU inconsistencies can cause difficult failures, so MTU validation must cover every underlay path.

VTEPs may learn remote endpoints through data-plane flooding or through a control plane. EVPN, carried commonly using MP-BGP, distributes MAC and IP reachability information. Important EVPN route types include:

• Type 1: Ethernet Auto-Discovery, used for multihoming and aliasing.
• Type 2: MAC/IP Advertisement, used to advertise endpoint reachability.
• Type 3: Inclusive Multicast Ethernet Tag, used to establish membership for broadcast, unknown unicast, and multicast traffic.
• Type 4: Ethernet Segment route, used in multihoming procedures.
• Type 5: IP Prefix route, useful for distributing Layer 3 prefixes across an EVPN domain.

EVPN reduces dependence on uncontrolled flooding and supports distributed gateways. A distributed anycast gateway allows endpoints attached to different leaves to use the same default-gateway address, reducing tromboning and improving mobility. Correctness depends on consistent VLAN–VNI mapping, route-target policy, ARP/ND handling, MTU, and failure convergence.

VXLAN is an encapsulation mechanism, not a complete security architecture. It does not inherently encrypt traffic or authenticate tenants. Sensitive traffic may require IPsec, MACsec, application-layer encryption, or cloud-provider encryption controls.

4. Cloud Connectivity and Network Architecture

Cloud connectivity choices differ in bandwidth, latency, operational control, resilience, and cost.

A VPN should be evaluated for encryption, tunnel redundancy, routing protocol support, throughput under encryption, and failure detection. A private circuit is not automatically secure; access control and encryption may still be required. Conversely, an Internet VPN can be highly secure but may exhibit variable performance.

Routing and Failure Domains

Hybrid designs should define which platform is authoritative for each route, whether routing is dynamic or static, and how asymmetric paths are handled. Route summarisation reduces table size but can hide failures if the summary remains advertised after constituent prefixes become unreachable.

Resilience should be designed at more than one layer: redundant customer equipment, separate circuits, diverse providers or facilities, redundant cloud gateways, and independent power or availability zones. A second tunnel that shares the same physical carrier is not fully independent.

Availability of independent components is often approximated as:

This product applies to a strictly serial system in which every component must be available and component failures are independent. For a parallel pair where either component can serve the workload, availability is:

These are simplified models; common-cause failures, maintenance, correlated provider outages, and imperfect failover reduce their predictive value. If two independent links each have availability 0.99 and either can carry traffic, the ideal parallel availability is 1 − (0.01 × 0.01) = 0.9999, or 99.99%.

Bandwidth and Cost

A rough traffic requirement can be estimated from the number of flows, mean rate, peak factor, and headroom:

Here N is the number of concurrent flows, r_mean is mean rate per flow in bit/s, p is a peak-to-mean multiplier, and h is fractional headroom. This is a planning approximation, not a guarantee. Bursty workloads, packet-rate limits, protocol overhead, and traffic direction must be considered.

For example, 2,000 flows averaging 2 Mb/s, with a peak factor of 1.5 and 25% headroom, require 2,000 × 2 × 1.5 × 1.25 = 7,500 Mb/s, or 7.5 Gb/s, before additional protocol overhead. A practical design would select the next supported service tier and test burst behaviour.

5. Container and Kubernetes Networking

Containers share the host kernel but have isolated network namespaces. A container interface is commonly connected to a host-side virtual Ethernet pair and then to a bridge, virtual switch, or overlay. The Container Network Interface (CNI) standardizes how plugins configure interfaces, addresses, routes, and policy.

Kubernetes networking expresses several expectations:

• Pods can communicate with one another without requiring address translation.
• Nodes can communicate with pods without requiring address translation.
• A pod sees its own IP address as the address used by other nodes.

Implementations vary. Some use routed pod networks, while others use overlays such as VXLAN or Geneve. Datapaths may use iptables, IPVS, eBPF, or hardware offload. These choices affect observability, performance, upgrade procedures, and policy semantics.

A Kubernetes Service provides a stable virtual address and selects pods through labels. ClusterIP is internal; NodePort exposes a port on nodes; LoadBalancer usually integrates with a cloud or external load balancer. Ingress traditionally manages HTTP/HTTPS routing into a cluster, while Gateway API provides a more expressive, role-oriented model for traffic management.

Kubernetes NetworkPolicy is normally additive: traffic is allowed if permitted by applicable policies, subject to the CNI implementation. A policy with no matching allow rule may isolate selected traffic, but default-deny behaviour should be deliberately implemented and tested for both ingress and egress. Policies must account for namespaces, labels, service discovery, DNS, control-plane traffic, and external dependencies.

The Kubernetes data plane is dynamic. Pod addresses are ephemeral, deployments replace instances, and autoscaling changes endpoints. Therefore, policy should target stable identities such as namespaces, service accounts, or labels rather than individual pod addresses wherever possible.

6. Service Meshes

A service mesh provides a platform for service-to-service communication, commonly including traffic encryption, identity, retries, timeouts, load balancing, telemetry, and policy. A data-plane proxy handles traffic near each workload, while a control plane distributes configuration and identities.

Mutual TLS (mTLS) authenticates both communicating services and encrypts their connection. However, mTLS does not prove that an application request is authorised to perform a particular business action. Application-level authorisation, input validation, and data governance remain necessary.

Retries require particular caution. Retrying a non-idempotent operation can duplicate effects. A mesh should use bounded retries, exponential backoff, jitter, deadlines, and circuit breaking. A useful timeout relationship is that an end-to-end deadline must exceed the sum of processing, queueing, network, and downstream delays, while also accounting for retry budgets. Excessive retries can create a retry storm and worsen an outage.

Service meshes improve uniformity and visibility but add CPU, memory, latency, configuration complexity, and another control plane. They are most valuable when heterogeneous services require consistent identity and traffic policy. They may be unnecessary for a small, homogeneous system or where platform-native networking already satisfies requirements.

7. Multi-Cloud and Distributed Architectures

Multi-cloud may be motivated by regulatory requirements, acquisition, resilience, specialised services, bargaining power, or avoidance of concentration risk. It is not automatically more resilient. Complexity, inconsistent semantics, data-transfer charges, duplicated operations, and common application dependencies can create new failure modes.

A multi-cloud design should separate:

• Connectivity: VPN, private interconnection, transit routing, and DNS.
• Identity: federation, workload identity, privileged-access management, and key ownership.
• Policy: segmentation, egress control, security baselines, and logging.
• Data: replication, consistency, residency, retention, and deletion.
• Operations: monitoring, incident response, configuration management, and recovery testing.

Active–active architectures can reduce recovery time but require traffic steering, data conflict handling, capacity in both sites, and careful consistency design. Active–standby designs may be simpler and cheaper but have slower recovery and risk untested failover. A workload should be placed according to latency, data gravity, compliance, service availability, and total cost rather than provider fashion.

DNS-based failover is useful but is constrained by caching, resolver behaviour, client caching, and health-check accuracy. Anycast can provide proximity and rapid distribution, but it requires routing expertise and does not solve application-state or data-consistency problems.

8. Cost-Aware Scaling and Capacity Governance

Network cost includes ports, gateways, egress, inter-region transfer, load balancers, public IPv4 addresses, cross-zone traffic, observability, security appliances, and operational labour. A design that minimizes equipment cost may increase transfer charges or reduce reliability.

A simple monthly network cost model is:

C_fixed represents recurring fixed charges; V terms are traffic volumes in the provider’s billing units; c terms are unit prices; and C_services includes gateways, load balancers, addresses, monitoring, and security services. Prices, tiers, minimums, and regional rules must be verified against current provider documentation.

Cost-aware scaling practices include:

• place chatty services in the same failure domain when reliability requirements permit;
• avoid unnecessary cross-zone or cross-region data movement;
• use private endpoints where they reduce hairpinning and egress;
• aggregate small flows carefully, without creating a bottleneck;
• right-size gateways and load balancers using both bandwidth and packet rate;
• use autoscaling with minimum capacity and failure headroom;
• monitor cost per request, per transaction, or per gigabyte processed;
• reserve capacity only when demand and commitment risk are understood.

Optimising only for cost can violate availability, latency, security, or regulatory objectives. A useful governance process makes these trade-offs explicit.

Applied Case: Illustrative Retail Analytics Platform

Background

A fictional retailer, Northstar Retail, operates online stores, warehouse systems, and data analytics. Its transactional services run in a public cloud, while warehouse control systems remain in two private data centres. The company expects seasonal traffic to increase fivefold and wants to introduce Kubernetes for customer-facing services.

Problem

The initial design used one large Layer 2 domain, static VPN routes, unrestricted pod egress, and a central inspection appliance through which all east–west traffic passed. During a promotion, the appliance became a bottleneck. Cross-zone database traffic increased cost, and a route change in one data centre affected unrelated tenants.

Analysis

The principal issues were coupled failure domains, insufficient route segmentation, excessive hairpinning, weak workload identity, and capacity planning based on average rather than peak traffic. The team measured bandwidth, packets per second, latency, flow concentration, and egress by service. It also mapped data residency and payment-security requirements.

Approach

The revised architecture used:

1. A routed leaf–spine underlay with ECMP and redundant spines.
2. EVPN/VXLAN for selected tenant and mobility requirements, with Layer 3 boundaries between major domains.
3. VRFs for production, development, management, and warehouse traffic.
4. Dual VPN tunnels initially, followed by diverse private connectivity for critical systems.
5. Kubernetes namespaces, default-deny policies, controlled egress, and workload identity.
6. A service mesh only for selected services requiring mTLS and progressive delivery.
7. Local read replicas and placement-aware workloads to reduce cross-zone database traffic.
8. Capacity thresholds based on peak demand, packet rate, and failure scenarios, not average utilisation alone.
9. Centralised observability for routes, VTEP health, drops, DNS, policy decisions, and cost allocation.

Outcome

The design removed the single inspection bottleneck, limited route propagation, and reduced unnecessary inter-zone traffic. Failover was tested quarterly rather than assumed. The organisation accepted that not every service required a mesh or global active–active deployment; architecture was selected according to workload criticality.

Learning Points

The case demonstrates that network modernisation is an architectural governance problem as well as a technical upgrade. Overlay technology cannot compensate for poor addressing, unclear ownership, weak observability, or untested recovery. Cost and resilience must be evaluated together, because traffic placement and redundancy decisions affect both.

Challenges, Governance, and Contemporary Developments

Important challenges include overlay troubleshooting, MTU inconsistency, control-plane scale, route leaks, asymmetric paths, noisy neighbours, packet-rate bottlenecks, and insufficient failure testing. Encryption and segmentation may also conflict with performance monitoring or lawful inspection requirements.

Governance should define ownership of underlay, overlay, cloud accounts, Kubernetes clusters, identities, certificates, and policies. Logs may contain personal or commercially sensitive metadata. Data minimisation, retention limits, access controls, and regional processing requirements therefore apply to flow logs and telemetry. Network automation should use peer review, testing, least privilege, protected state, and rollback procedures.

AI-assisted operations can help classify anomalies, correlate telemetry, predict capacity, and suggest configuration changes. It should not receive unrestricted authority to alter production routing. Models can produce unsafe recommendations because of incomplete topology, stale data, or misleading correlations. Human approval, change controls, simulation, and audit trails remain necessary.

Current practice is moving toward intent-based networking, eBPF-powered datapaths, programmable switches, Gateway API, zero-trust workload identity, confidential computing integration, and richer network digital twins. These developments improve programmability but increase the importance of version compatibility, formal policy testing, and skills in distributed systems.

Best-Practice Design Checklist

1. Start with workload communication patterns, regulatory constraints, and failure objectives.
2. Use hierarchical, summarizable addressing and document ownership.
3. Keep the underlay simple, routed, observable, and independently testable.
4. Use overlays only where their mobility or segmentation benefits justify complexity.
5. Validate MTU, ECMP behaviour, convergence, packet rate, and failure paths.
6. Separate tenants and environments with explicit routing and policy boundaries.
7. Treat Kubernetes identity and policy as dynamic; do not rely on pod IP permanence.
8. Introduce service meshes selectively and control retries and timeouts.
9. Design cloud connectivity for diverse failure domains, not merely duplicate tunnels.
10. Measure cost per workload outcome and include egress and operational effort.
11. Test disaster recovery, route withdrawal, certificate expiry, and provider failure.
12. Automate safely with validation, staged rollout, and rollback.

Chapter Summary

Cloud and data-centre networking combines physical fabrics with programmable logical abstractions. Virtual networks provide isolation and flexible routing, while leaf–spine fabrics offer predictable paths and ECMP-based scale. VXLAN extends logical segments over a routed underlay; EVPN supplies a control plane for endpoint and prefix reachability, but neither technology alone provides encryption or complete security.

Hybrid and multi-cloud architectures require deliberate choices among VPNs, private circuits, transit hubs, and peering. Availability formulas and bandwidth estimates are useful only when their assumptions are understood. Container networking must accommodate ephemeral identities and dynamic endpoints, while Kubernetes Services and NetworkPolicy provide stable discovery and policy primitives. Service meshes add identity, encryption, and traffic controls but introduce measurable operational cost.

Strategic designs balance performance, resilience, security, governance, portability, and cost. The strongest architecture is not the one with the most features; it is the one whose complexity is justified by workload requirements and whose failure modes are observable and tested.

Key Terms

Virtual network: A logically isolated network implemented over shared physical infrastructure.

VPC/VNET: A cloud provider’s virtual private network boundary.

VRF: A virtual routing and forwarding instance with an independent routing table.

Leaf–spine fabric: A two-stage data-centre topology connecting every leaf to every spine.

ECMP: Equal-cost multipath forwarding across multiple equivalent routes.

Oversubscription: The ratio of aggregate access-facing capacity to aggregate uplink capacity.

VXLAN: UDP-based encapsulation that carries Ethernet frames across an IP underlay.

VNI: VXLAN Network Identifier used to distinguish logical segments.

VTEP: VXLAN Tunnel Endpoint that encapsulates or decapsulates VXLAN traffic.

EVPN: An MP-BGP-based control plane for Ethernet and IP reachability information.

Underlay: The physical or routed network that transports an overlay.

Overlay: A logical network carried across an underlying network.

CNI: Container Network Interface specification and plugin ecosystem.

Kubernetes Service: A stable virtual access point for a dynamic set of pods.

NetworkPolicy: A declarative rule set controlling permitted workload traffic.

Service mesh: A platform for consistent service-to-service identity, policy, and telemetry.

mTLS: Mutual Transport Layer Security, providing bilateral authentication and encryption.

Transit hub: A central routing construct connecting networks, sites, or cloud environments.

Egress: Traffic leaving a network, region, or cloud provider.

Anycast: Advertisement of the same address from multiple network locations.

Review Questions

Short Answer Questions

1. What problem does a leaf–spine topology solve compared with a traditional hierarchical network?
2. What is the function of a VTEP in VXLAN?
3. Why does VXLAN require MTU planning?
4. State two differences between a Kubernetes Pod and a Kubernetes Service.
5. Why is mTLS insufficient as a complete authorisation mechanism?

Long Answer Questions

1. Explain how EVPN improves VXLAN operation and discuss the roles of EVPN route types.
2. Compare Internet VPNs, dedicated private circuits, transit hubs, and direct peering for hybrid cloud connectivity.
3. Design a resilient leaf–spine fabric for a multi-tenant data centre, including routing, redundancy, and observability.
4. Explain the benefits and costs of introducing a service mesh into a Kubernetes platform.
5. Discuss the architectural and governance challenges of operating a multi-cloud platform.

Analytical / Application Questions

1. A leaf switch has 32 server-facing 25 Gb/s ports and 8 spine-facing 100 Gb/s ports. Calculate its nominal oversubscription ratio. Recalculate it if two spine links fail, and interpret the result.
2. An organisation estimates 3,000 concurrent flows averaging 1.5 Mb/s. Peak demand is 1.8 times the mean and required headroom is 20%. Estimate required bandwidth and identify at least three factors that could make the estimate inaccurate.
3. Two independent connectivity links each have availability 0.995, and either link can carry the workload. Using the ideal independent parallel model, calculate system availability and explain why real availability may be lower.

Multiple Choice Questions with Answers

Question 1

Which property is most characteristic of a leaf–spine fabric?

A. Every leaf connects to every spine

B. Spines connect directly to all servers

C. All traffic must pass through a central firewall

D. Layer 2 is required between every data centre

Correct Answer: A. Every leaf connects to every spine

Question 2

What is the primary purpose of a VXLAN VNI?

A. To encrypt the inner Ethernet frame

B. To identify a logical VXLAN segment

C. To select a TCP congestion algorithm

D. To assign a Kubernetes pod identity

Correct Answer: B. To identify a logical VXLAN segment

Question 3

Which EVPN route type advertises MAC and IP reachability for an endpoint?

A. Type 1

B. Type 2

C. Type 3

D. Type 5

Correct Answer: B. Type 2

Question 4

A leaf has 24 × 25 Gb/s server links and 6 × 100 Gb/s uplinks. What is its nominal oversubscription ratio?

A. 1:1

B. 2:1

C. 4:1

D. 6:1

Correct Answer: A. 1:1

Question 5

Which statement about Kubernetes NetworkPolicy is correct?

A. It always encrypts permitted traffic

B. It normally targets stable pod IP addresses only

C. Its effective semantics depend partly on the CNI implementation

D. It replaces all identity and application authorisation

Correct Answer: C. Its effective semantics depend partly on the CNI implementation

Question 6

What is a major risk of unrestricted service-mesh retries?

A. They eliminate all queueing

B. They can create retry storms during an outage

C. They prevent mTLS negotiation

D. They guarantee idempotent operations

Correct Answer: B. They can create retry storms during an outage

Question 7

Which connectivity option generally provides a private, provider-supported path without relying solely on the public Internet?

A. Dedicated private circuit

B. Unencrypted DNS

C. Public web proxy

D. Local container bridge

Correct Answer: A. Dedicated private circuit

Question 8

Two independent links each have availability 0.99, and either can serve traffic. What is the ideal parallel availability?

A. 0.9801

B. 0.99

C. 0.9999

D. 1.99

Correct Answer: C. 0.9999

Question 9

Which statement best describes VXLAN security?

A. VXLAN inherently encrypts all tenant traffic

B. VXLAN provides segmentation but is not, by itself, encryption

C. VXLAN replaces workload identity

D. VXLAN prevents all route leaks

Correct Answer: B. VXLAN provides segmentation but is not, by itself, encryption

Question 10

Which cost-control action can reduce unnecessary cloud network charges when reliability requirements permit?

A. Move all traffic through a distant region

B. Increase cross-zone database traffic

C. Place chatty services in the same suitable failure domain

D. Disable traffic measurement

Correct Answer: C. Place chatty services in the same suitable failure domain