Cloud Networking 101: How Cloud Changes Traditional Network Thinking – Key Takeaways
Overview
Yvonne Sharp, a customer engineering leader for infrastructure in North America at Google Cloud, presents this session from the perspective of someone who began in traditional networking, worked across enterprise healthcare environments, VMware, and Google Cloud, and has seen the networking stack evolve over roughly 25 years.
The session is an introduction to how public cloud changes the assumptions that network and infrastructure teams often bring from on-premises environments. It explains why organizations move to cloud, how cloud affects cost and operating models, which traditional skills still apply, and where cloud networking constructs differ in important ways across providers.
The central theme is that public cloud is not simply another data center. Familiar networking knowledge remains valuable, but cloud architectures require different mental models. Teams need to understand the business reason for cloud adoption, the unique behavior of each cloud provider’s constructs, and the operational changes required to design, deploy, secure, and maintain cloud environments successfully.
1. Why Organizations Consider Public Cloud
Organizations often begin evaluating public cloud because they want greater speed and scale. Cloud platforms allow teams to deploy workloads quickly, make changes more quickly, and gain confidence that capacity will be available when the organization needs to grow.
Another major driver is the desire for a different cost model. Traditional infrastructure has commonly depended on three-year, five-year, or seven-year purchasing cycles. That model requires organizations to predict future capacity needs, commit significant capital up front, order and deploy hardware, and then operate within the limits of those purchasing decisions. Public cloud changes that pattern by allowing organizations to deploy what they need when they need it, while the underlying platform evolves with newer technology.
Public cloud also supports a new operating model. Many enterprise IT processes were created in an era when applications ran directly on physical servers or on infrastructure managed through slower hardware-driven workflows. As virtualization, automation, and cloud platforms have changed the technical environment, organizations increasingly look to cloud as a way to modernize how infrastructure is requested, deployed, governed, and operated.
Emerging technology is another important reason for cloud adoption. Instead of procuring and installing hardware simply to test a new capability, organizations can use cloud resources to experiment, iterate, and evaluate technology at lower initial cost. This makes cloud attractive not only for production workloads, but also for innovation and exploratory work.
2. Cloud Adoption Is Often a Business Decision
Moving to public cloud should not be understood only as a technical decision. Organizations may adopt cloud because they want to improve technology capabilities, but the underlying reasons are often tied directly to business goals.
The motivation matters because it shapes architecture. For example, an organization building a mission-critical application intended to drive future business growth will make different design choices than an organization that needs to exit a data center because a lease is expiring within a year. Both scenarios can lead to cloud adoption, but they create different constraints, priorities, risks, timelines, and trade-offs.
Practitioners should understand the business motive behind a migration or new cloud initiative. Knowing whether the goal is speed, scale, cost flexibility, data center evacuation, modernization, experimentation, or support for a strategic application helps technical teams make better architectural decisions and support the organization more effectively.
3. Capacity Planning Changes From Over-Provisioning to Right-Sizing
In on-premises environments, teams have often over-purchased and over-provisioned hardware. Long procurement cycles and large capital investments encourage organizations to estimate future demand conservatively. Because no one wants to run out of capacity after buying infrastructure for the next several years, it is common to overestimate.
Once hardware has been purchased and installed, over-provisioning workloads can feel almost cost-free. If a virtual machine needs 16 GB of RAM, an on-premises team might provision 32 GB simply to provide extra performance headroom. The hardware is already present, so the cost is not always visible at the workload level.
Public cloud changes that behavior because provisioned capacity has a more direct cost impact. The cloud model encourages teams to deploy workloads at the size they actually need for the moment, then scale when requirements change. Instead of buying excess capacity in advance, teams can adjust resources over time.
This creates a different optimization discipline:
- Right-size workloads initially. Avoid carrying over the habit of assigning extra capacity “just to be safe” without understanding the cost.
- Scale horizontally where appropriate. Cloud environments make it easier to add capacity as demand changes.
- Pay attention to what is actually used. Cloud cost control depends on understanding how provisioned resources map to usage and demand.
- Use cloud elasticity as a design input. The ability to scale should influence how workloads are deployed and maintained.
4. Cloud Requires a Different Operating Model
Traditional on-premises deployment processes are often slow because of accumulated complexity, technical debt, and long-standing interdependencies. Those processes made sense in the context in which they were created, but cloud changes both the speed and the mechanics of infrastructure delivery.
Because cloud resources can be deployed on demand and managed as code, organizations need to rethink how change, approval, compliance, and deployment processes work. In many older models, compliance and approval systems run in parallel with technical implementation. Work may be tracked in one system while engineers perform the deployment separately.
Cloud creates an opportunity to integrate those workflows. Infrastructure as code and cloud deployment pipelines can include documentation, approvals, change tracking, and compliance evidence as part of the same technical process. That integration can make work more efficient, more auditable, and less dependent on disconnected back-and-forth approval flows.
This shift affects how organizations track work and how practitioners operate day to day. Cloud environments typically require more scripting, more infrastructure as code, and tools such as Terraform. The most effective operating models connect governance and technical deployment rather than treating them as unrelated processes.
5. Geographic Redundancy Becomes Easier, but Not Automatic
Geographic redundancy has historically been difficult and expensive in on-premises environments. To build redundancy across locations, an organization needed multiple geographically dispersed data centers, physical facilities, connectivity, duplicate hardware, and engineering work across the stack to ensure failover and resilience behaved as expected.
Major public clouds provide a global foundation. Their infrastructure is geographically dispersed, and they are engineered to support redundant architectures. This gives organizations access to redundancy capabilities that would be expensive and complex to build entirely on their own.
However, cloud redundancy is not automatic for every workload. Deploying an application in a public cloud does not by itself make that application resilient across failures. If a workload is deployed in a single region using regional services, and that region experiences an outage, the workload can still be affected.
The important distinction is that the cloud provider supplies the underlying global platform and redundant building blocks. Application and infrastructure teams still need to design their workloads to use those capabilities appropriately. Redundancy depends on architecture, not simply on the fact that a workload runs in cloud.
6. Public Cloud Networking Constructs Are Provider-Specific
Every major public cloud has a virtual network construct, but similar names do not guarantee similar behavior. Google Cloud and AWS both use the term VPC, while Azure uses VNet. These constructs all represent virtual networks in public cloud environments, but their scope, routing behavior, and configuration models differ.
A Google Cloud VPC is global. When a VPC is created in Google Cloud, it is available across global regions, and subnets in that VPC can be routable across regions if firewall rules and access controls permit the traffic.
An AWS VPC is regional. The VPC and its subnets exist within a region. Routing to another geographic region requires additional engineering and configuration. Azure VNets have their own rules as well.
These differences matter because architects cannot assume that a design working in one cloud will transfer directly to another. A construct may have a familiar name or appear to solve a familiar problem, but its operational behavior may be different. Teams need to understand each provider’s specific implementation before designing routing, segmentation, availability, and security patterns.
7. Routing, Access, Automation, and Traffic Behavior Need Careful Review
Cloud networking requires attention to details that may differ from on-premises networks and from one cloud provider to another. Several areas deserve specific review when designing cloud environments:
- Routing and transitivity. If multiple VPCs or virtual networks are connected, teams need to understand whether traffic is routable among all of them, whether transitive routing is supported, and what configuration is required.
- Public internet access and IP addressing. Addressing models and internet exposure need to be understood within the rules of the specific cloud.
- Firewalls, security, and VPNs. Security controls may not map exactly to familiar on-premises patterns.
- Identity and access management. Cloud access is deeply tied to identity and permission systems, not only to network location.
- Regions, zones, and availability. Availability constructs vary across clouds, and sometimes even within a cloud based on region.
- APIs and automation. Automation is provider-specific. Terraform used for one cloud will usually require modification before it can be applied to another.
One especially important caution concerns BUM traffic, meaning broadcast, unknown unicast, and multicast traffic. These are traffic types associated with flood-and-learn behavior. Public cloud networks typically do not allow this kind of traffic by default because it can be dangerous and disruptive.
Applications that depend on multicast are unlikely to work in a public cloud by default. If such an application needs to run in cloud, teams should work with the cloud provider to determine the best supported approach. The answer may involve an overlay or another additional technology, but the key point is that traditional Layer 2 assumptions should not be carried into public cloud without validation.
8. Connectivity Options Have Different Trade-Offs
Connecting on-premises networks to public cloud can be done in several ways. The right choice depends on cost, bandwidth, reliability, operational ownership, and workload criticality.
VPN connectivity is often the first option organizations use. VPNs are low cost, and many organizations already have VPN hardware that can connect to a cloud environment. They can be fully redundant if the organization has the hardware and supporting infrastructure to make them redundant. VPNs are useful for getting started and establishing initial connectivity, but they have bandwidth constraints and are not the best fit for mission-critical production traffic.
Partner-provided connections use an intermediary between the public cloud and the organization’s network. In Google Cloud, this model is represented by Partner Interconnect. An MPLS provider is a useful example: the public cloud can become another node on the organization’s MPLS network. Partner-provided connections are often available at lower speeds and lower costs. The trade-off is that an intermediary manages the connection.
Direct connections are commonly used by organizations that need more reliability and higher bandwidth. A direct connection can link the public cloud to a colocation facility or to a data center the organization owns and operates. This model behaves similarly to a point-to-point circuit between facilities. The cloud provider supplies details about how and where the interconnect is established, while a telco carrier provides the circuit. Direct connections are typically more reliable than VPNs and can support higher speeds than partner interconnect options.
Cloud-to-cloud connections connect infrastructure in one cloud directly to infrastructure in another cloud. In this model, the organization does not need to provide physical infrastructure or order a traditional circuit. For example, an environment in Google Cloud can be connected to an environment in Microsoft Azure by connecting a VPC to a VNet, depending on the services and provider options in use.
Organizations using SD-WAN should also consult both their SD-WAN provider and their public cloud provider to understand the best way to include public cloud environments in the SD-WAN network.
9. Traditional Networking Skills Still Matter
Cloud changes networking models, but it does not make core networking skills obsolete. Foundational knowledge continues to transfer from on-premises environments into public cloud.
Important transferable skills include:
- Subnetting and IP addressing. Understanding IPv4, IPv6, and address planning remains essential.
- Routing. Cloud routing behavior is different in some ways, but routing knowledge remains central to designing and troubleshooting environments.
- Firewalling and security. Network security skills still matter, even as cloud platforms add identity-based controls and provider-specific firewall models.
- Troubleshooting. The ability to diagnose connectivity, routing, access, and performance issues remains valuable in any infrastructure model.
The adjustment is not that network practitioners must abandon what they know. Instead, they need to apply those skills within provider-specific cloud constructs and learn where cloud behavior diverges from traditional assumptions.
10. Well-Architected Frameworks Are a Starting Point
Each major public cloud offers some form of architecture or well-architected framework. These frameworks provide guidance on best practices for deploying workloads in that cloud and are useful starting points for teams that are unfamiliar with a provider’s design patterns.
These frameworks do not remove the need for engineering judgment, but they help teams orient themselves around provider-specific expectations. They can guide decisions about workload deployment, resilience, operations, security, and networking.
The broader lesson is that teams should avoid assuming that an on-premises mental model, or a design from one cloud, will transfer cleanly to another cloud. Routing, IP addressing, access control, security, firewalling, regions, zones, automation, and connectivity models all influence architecture. Public cloud documentation, blogs, and architecture frameworks can help teams learn those differences before they become operational problems.
Key Takeaways
- Cloud changes the capacity model. Instead of buying hardware for multi-year forecasts, teams can provision what they need now and scale as requirements change.
- Cost awareness becomes more direct. Over-provisioning that felt harmless on owned hardware can create visible cost in public cloud.
- Operating models need modernization. Infrastructure as code, scripting, deployment pipelines, and integrated compliance workflows are central to effective cloud operations.
- Redundancy must be designed. Public clouds provide global infrastructure, but a workload deployed in a single region can still experience regional impact.
- Similar names can hide major differences. A Google Cloud VPC, AWS VPC, and Azure VNet are not interchangeable constructs.
- Provider-specific details matter. Routing, transitivity, firewalling, public internet access, IAM, regions, zones, and automation all require careful review.
- BUM traffic is not a safe assumption in cloud. Applications that depend on broadcast, unknown unicast, or multicast behavior may require alternative designs.
- Connectivity choices involve trade-offs. VPNs, partner-provided connections, direct connections, cloud-to-cloud connections, and SD-WAN integrations each fit different needs.
- Networking fundamentals still transfer. Subnetting, IP addressing, routing, firewalling, security, and troubleshooting remain critical skills.
- Business context should guide architecture. The reason for cloud adoption influences the right design and migration approach.
Conclusion
Public cloud requires a shift in how infrastructure professionals think about networking, deployment, cost, and operations. It provides speed, scale, flexible consumption, and access to global infrastructure, but those benefits are realized through deliberate architecture rather than simple relocation of existing systems.
The most important change is the mental model. Cloud is not just an outsourced data center, and cloud networking constructs are not universal across providers. Teams need to understand the specific behavior of the cloud they are using, especially around virtual networks, routing, connectivity, security, automation, and availability.
At the same time, traditional networking expertise remains highly relevant. The practitioners best positioned to succeed are those who combine core networking skills with cloud-specific knowledge and a clear understanding of the business reason behind the move to cloud. That combination helps organizations choose the right design patterns, avoid false assumptions, and build cloud environments that support both technical and business goals.
