4.4Cloud and edge

When migrating a business system to the cloud, a network designer faces a chain of decisions: not just "which service model to use," but "how to connect on-premises and the cloud (dedicated connection or VPN)," "how to partition the cloud's virtual network," and "where to run latency-sensitive processing (in the cloud or at the edge)." This section teaches the perspective needed to design on-premises/cloud connectivity based on requirements such as latency tolerance, security, and cost.

4.4.1IaaS/PaaS/SaaS and cloud connectivity

• IaaS (Infrastructure as a Service) provides infrastructure—virtual servers, storage, networking—as a service, with the user managing everything from the OS up. PaaS (Platform as a Service) additionally provides the OS and middleware, letting the user focus solely on implementing the application. SaaS (Software as a Service) provides the application itself as a service, with the user only configuring and using it. The scope the user must manage narrows in the order IaaS -> PaaS -> SaaS.
• Connections between on-premises and the cloud fall broadly into dedicated connections (a physical leased line, wide-area Ethernet, or similar link directly into the cloud provider's data center, bypassing the public Internet) and VPN connections (an IPsec tunnel over an Internet VPN). A dedicated connection offers bandwidth guarantees, low latency, and high security but costs more and takes longer to provision, while a VPN connection is quick and cheap but has a weaker SLA over the public network—the same shape of tradeoff as WAN selection in Section 1.

4.4.2VPC (virtual network)

• A VPC (Virtual Private Cloud) is a service that builds a logically isolated virtual network per user while sharing the cloud provider's physical infrastructure. Users can freely design the IP address range (CIDR), subnets, routing, and access control, configuring the network in the cloud much as they would an on-premises network.
• When connecting on-premises to a VPC, it is essential to design the IP address ranges of both sides in advance so they do not overlap (overlapping ranges break routing). Regardless of whether a dedicated connection or VPN is used, the VPC side must have a virtual gateway ready to accept routes from on-premises, with reachability controlled via route tables.

4.4.3Edge computing, CDN, and IoT/M2M

• Edge computing places processing near the source of the data (a factory control device, a self-driving car, etc.), building an architecture that completes processing on the spot without waiting for the round-trip latency (RTT) to the cloud. Compared to a centralized model that sends all data to the cloud for processing, it suits control/decision processing where low latency is essential, but trades off against increased per-site equipment and operating cost.
• A CDN (Content Delivery Network) delivers static content (images, video, static pages, etc.) from cache servers placed near the user, reducing both the load concentrated on the origin server and delivery latency. Whereas edge computing performs "processing" nearby, a CDN performs "delivery" (of already-existing content) nearby—a different purpose. IoT/M2M (Machine to Machine) refers to a scheme in which many sensors and devices exchange data automatically without human intervention; efficient simultaneous connectivity for a large number of devices (mMTC, Wi-Fi 6's OFDMA, etc.) becomes the key design concern.

Suppose a factory runs anomaly detection for its production line using an AI model in the cloud, but faces the problem that "the reaction time from detecting an anomaly to stopping the line is too long." Analyzing the cause reveals that the round-trip latency (RTT) of sending sensor data to the cloud and receiving the inference result back is too large for the time-critical requirement of an anomaly that should trigger an immediate stop. The right design decision here is not "switch the cloud connection to a dedicated connection to reduce latency" (even a dedicated connection cannot reduce the latency inherent in physical distance to zero); it is switching to edge computing, placing the inference processing itself inside the factory (at the edge). By deploying the trained model to an edge server inside the factory and performing inference/decision-making on sensor data on the spot, a stop command can be issued without waiting on a round trip to the cloud. On the other hand, if this same factory delivers video product-catalog content to sites nationwide, the logic flips—delivering static content such as video is a job for a CDN, which places caches near each site, and there is no need to build a processing site the way edge computing does (since only delivery, not decision processing, is required). Furthermore, when connecting the factory's sensors to a cloud IoT platform, the wireless side would use Wi-Fi 6 (OFDMA) to raise efficiency for many simultaneously connected devices, while the on-premises-to-cloud-VPC connection—given the importance of control data—would use a dedicated connection, with the VPC's CIDR designed in advance so its IP address range does not overlap with on-premises. The trap to avoid here is the misconception that "edge computing and CDN are the same because both are about placing things nearby"—edge is about executing low-latency processing, while CDN is about delivering existing content, a different purpose, and conflating them leads to over-investment such as building unnecessary edge processing sites.

4.4.4Section summary

• The scope the user manages narrows in the order IaaS/PaaS/SaaS. A dedicated connection is high-quality and costly; a VPN connection is quick, cheap, and has a weaker SLA
• A VPC requires avoiding IP address overlap with on-premises. Edge computing is for low-latency processing and CDN is for static content delivery—different purposes
• IoT/M2M hinges on efficient simultaneous connectivity for large numbers of devices (mMTC, OFDMA, etc.)