Lesson 1.3.1 — Cloud Deployment Models & Virtual Networking

Domain 1.0 | Networking Concepts — 23% of exam

Learning Objectives

By the end of this lesson, you will be able to:

• Compare the public, private, hybrid, and community cloud deployment models in terms of ownership, control, and typical use case
• Explain how Network Function Virtualization (NFV) decouples network functions from dedicated physical hardware
• Describe a Virtual Private Cloud (VPC) and its role in providing an isolated network environment within a public cloud
• Explain how deployment models, NFV, and VPCs combine in a real-world cloud networking architecture

Key Terms

Term	Definition
Cloud Computing	The on-demand delivery of computing resources (servers, storage, networking, software) over the internet, typically from a third-party provider
Public Cloud	A cloud environment where infrastructure is owned and operated by a third-party provider and shared across multiple customers (tenants)
Private Cloud	A cloud environment dedicated entirely to a single organization, whether hosted on-premises or by a provider on dedicated infrastructure
Hybrid Cloud	A deployment model that combines public and private cloud environments, allowing workloads and data to move between them
Community Cloud	A cloud environment shared by several organizations with common concerns (such as compliance requirements), but not open to the general public
Multitenancy	An architecture where multiple customers (tenants) share the same underlying physical infrastructure while remaining logically isolated from one another
NFV (Network Function Virtualization)	The practice of replacing dedicated physical network appliances with software-based network functions running on general-purpose hardware
VNF (Virtualized Network Function)	An individual network function — such as a firewall, router, or load balancer — implemented as software rather than dedicated hardware
VPC (Virtual Private Cloud)	A logically isolated section of a public cloud provider’s network, giving a customer private, controllable networking within otherwise shared infrastructure
Orchestration	The automated coordination and management of virtualized resources, such as automatically deploying or scaling VNFs as demand changes
Scalability	A system’s ability to handle growth by adding resources over time, such as additional compute or storage capacity
Elasticity	A system’s ability to automatically scale resources up and back down in real time in response to actual, often unpredictable, demand
Service Function Chain	An ordered sequence of virtual network functions that traffic passes through, such as a virtual firewall followed by a virtual load balancer
Multi-Cloud	An architecture that uses services from more than one public cloud provider simultaneously, independent of whether private infrastructure is also involved
CapEx / OpEx	Capital expenditure (large upfront purchases of depreciating hardware) versus operational expenditure (ongoing, usage-based costs) — a key economic distinction between traditional and cloud/NFV-based infrastructure

Explanation

From Owning Hardware to Renting Capability

Traditional networking, including everything covered so far in this course, assumes an organization owns and operates its own physical infrastructure — its own routers, switches, firewalls, and servers, sitting in its own building or data center. Cloud computing changes this by delivering computing resources — servers, storage, networking, and increasingly entire network functions — on demand, over the internet, typically from a third-party provider. This lesson covers two things Network+ expects you to understand about this shift: the different deployment models organizations can choose from, and the two closely related virtualization concepts — NFV and VPC — that make modern cloud networking possible.

The Cloud Deployment Models

Cloud deployment models describe who owns and controls the underlying infrastructure, and who else, if anyone, shares it.

• Public cloud infrastructure is owned and operated by a third-party provider (think of the major hyperscale providers) and shared across many customers simultaneously through multitenancy — each customer’s resources are logically isolated from every other customer’s, even though they run on shared physical hardware underneath. Public cloud offers the lowest up-front cost and the greatest scalability, since a customer only pays for the capacity they actually use and can scale up or down on demand, but it also means less direct physical control over the underlying infrastructure. A startup launching a new application with an unknown and potentially rapidly growing user base is a classic public cloud use case — it can begin small and scale seamlessly without ever predicting demand in advance or purchasing hardware ahead of need.
• Private cloud infrastructure is dedicated entirely to a single organization — it might be physically hosted in that organization’s own data center, or hosted by a provider on hardware dedicated solely to that one customer. This gives an organization maximum control and customization, at the cost of losing the shared-infrastructure economics and elastic scalability that make public cloud attractive. A bank subject to strict regulatory requirements about exactly where customer financial data is physically stored and who can access the underlying hardware often gravitates toward private cloud for exactly this reason.
• Hybrid cloud combines public and private cloud environments, allowing an organization to keep sensitive workloads or data on private infrastructure while taking advantage of public cloud for other workloads — for example, running steady baseline capacity on private infrastructure while “bursting” additional temporary capacity into the public cloud during demand spikes. This gives an organization the regulatory control of private cloud for the workloads that need it, without forgoing the cost efficiency and elasticity of public cloud for everything else.
• Community cloud is shared by several distinct organizations that have common concerns — most often regulatory or compliance requirements, such as several government agencies or several healthcare organizations sharing infrastructure built around a common compliance framework. It’s not open to the general public the way a public cloud is, but it also isn’t dedicated to a single organization the way a private cloud is — it sits conceptually between the two, letting similar organizations share the cost of specialized, compliant infrastructure that none of them could as easily justify building alone.

Side-by-Side: Deployment Models

Model	Who Owns/Controls Infrastructure	Who Else Shares It	Typical Driver
Public	Third-party provider	Many unrelated customers (multitenant)	Lowest cost, maximum scalability
Private	The organization itself (or dedicated hosted hardware)	No one else	Maximum control, customization, security requirements
Hybrid	Mix of the organization and a third-party provider	Varies by workload	Flexibility — keep sensitive workloads private, burst the rest to public
Community	Shared among a defined group of organizations	Other organizations with similar compliance/regulatory needs	Shared compliance requirements without full public exposure

Network Function Virtualization (NFV)

Every device covered earlier in this module — firewalls, load balancers, routers — has traditionally been a dedicated physical appliance: a specific box, built for a specific function, that has to be purchased, racked, cabled, and maintained individually. Network Function Virtualization (NFV) replaces this model by implementing those same functions as software running on general-purpose server hardware instead. A virtual firewall, a virtual load balancer, and a virtual router — each called a VNF (Virtualized Network Function) — can all run as software instances on the same underlying hardware, rather than requiring a dedicated physical box for each one.

This shift delivers several concrete advantages that Network+ expects you to recognize:

• Reduced capital expense — an organization no longer needs to purchase a separate physical appliance for every network function it needs, since multiple VNFs can share the same underlying general-purpose server hardware, and that hardware itself is often commodity equipment rather than expensive proprietary appliances.
• Faster deployment and greater agility — spinning up a new virtual firewall or load balancer is a software operation that can happen in minutes, compared to the lead time of purchasing, shipping, and physically installing new hardware, which can take weeks. This matters enormously when a business needs to respond quickly to a new opportunity, a security incident, or an unexpected traffic pattern.
• Easier scaling — additional VNF instances can be deployed on demand as load increases, and removed again when demand drops, often through orchestration — automated systems that manage this scaling without requiring manual intervention for every change. A physical appliance, by contrast, has a fixed maximum capacity that can only be increased by purchasing another physical unit.
• Vendor flexibility and reduced lock-in — because VNFs run on general-purpose hardware rather than proprietary appliances, an organization has more freedom to change which vendor’s software implements a given function without needing to replace the underlying physical infrastructure it runs on.

It’s worth being precise about a commonly confused pairing: NFV is about virtualizing individual network functions, moving them off dedicated hardware and onto general-purpose infrastructure. This is a related but distinct concept from Software-Defined Networking (SDN), which is about separating the network’s control plane from its data plane to enable centralized, programmable network management — covered as its own Network+ objective later in this module (Lesson 1.8.2). NFV and SDN are frequently deployed together and complement each other well, but they solve different problems, and the exam expects you to keep them conceptually separate.

Virtual Private Cloud (VPC)

A Virtual Private Cloud (VPC) is a logically isolated section of a public cloud provider’s overall network, assigned to a single customer. Even though the underlying physical infrastructure is shared across many customers (as in any public cloud deployment), a VPC gives that customer their own private, software-defined networking space within it — their own IP address range, their own internal network segmentation, and their own control over what traffic is allowed in or out — all without needing to see or interact with any other customer’s resources on the same underlying hardware.

A useful way to think about a VPC: it’s your own walled-off section of a shared building. The building (the public cloud provider’s physical data center) is shared with many other tenants, but your VPC is a private, access-controlled space within it that only you can see into and control.

Within a VPC, an organization can create subnets to segment its cloud resources logically, much as it would segment a physical on-premises network — though the specific connectivity mechanisms for controlling traffic in and out of a VPC (security groups, NAT gateways, internet gateways, and dedicated connections) are covered in the next lesson (1.3.2), since this lesson focuses on establishing what a VPC fundamentally is before layering on how traffic actually moves in and out of one.

How These Concepts Combine in Practice

These ideas aren’t independent choices made in isolation — they typically combine directly. An organization might choose a hybrid cloud deployment, keeping a sensitive database on private infrastructure while running its public-facing web application inside a VPC in the public cloud. Within that VPC, instead of provisioning dedicated physical firewalls and load balancers, the organization deploys VNFs — a virtual firewall and virtual load balancer, both implemented purely in software — giving it the same core security appliance and traffic management functionality covered in Lessons 1.2.2 and 1.2.3, just delivered through NFV inside a cloud environment rather than as dedicated on-premises hardware.

Key Characteristics of Cloud Computing: Scalability, Elasticity, and Multitenancy

Beyond the deployment model question, a handful of characteristics distinguish cloud computing from traditional on-premises infrastructure, and Network+ expects you to recognize each by name:

• Scalability refers to a system’s ability to handle growth by adding resources — for example, adding more virtual machines or more storage capacity as an organization’s needs grow. Traditional on-premises infrastructure can scale too, but doing so means purchasing, shipping, and installing new physical hardware, a process that takes weeks or months. Cloud scalability, by contrast, is typically a matter of provisioning additional resources through a console or API call.
• Elasticity is a related but distinct concept: it refers to a system’s ability to automatically scale resources up and back down in response to actual, often unpredictable, real-time demand — not just growing over time, but expanding and contracting as needed. A retail website that automatically provisions additional server capacity during a holiday shopping surge, then releases that capacity once the surge ends, is exhibiting elasticity. Scalability is the capability to grow; elasticity is the automatic, on-demand application of that capability in both directions.
• Multitenancy, introduced earlier in the context of public cloud, is the architectural foundation that makes public cloud’s cost efficiency possible in the first place: many customers share the same underlying physical infrastructure, with the cloud provider responsible for keeping each tenant’s resources logically isolated and secure from every other tenant, even though they’re running on the same physical servers, storage, and network hardware underneath.

These three characteristics work together: multitenancy lets a provider spread the cost of physical infrastructure across many customers, which is what makes offering elastic, on-demand scalability to any individual customer economically viable in the first place. A single organization renting dedicated hardware outright would have to provision for its own peak demand at all times; a cloud provider spreading elastic capacity across thousands of tenants can provision far more efficiently in aggregate.

Choosing a Deployment Model in Practice

Exam scenarios frequently describe an organization’s constraints and ask which deployment model fits best — so it’s worth thinking through the decision criteria directly rather than just memorizing definitions in isolation. An organization with strict regulatory requirements around exactly where its data physically resides, or one that has already made a large capital investment in its own data center, tends toward private cloud.

An organization prioritizing minimizing upfront cost, needing to scale rapidly and unpredictably, or lacking the staff to manage physical infrastructure at all, tends toward public cloud. An organization that needs both — perhaps keeping regulated customer data on private infrastructure while running its customer-facing website in the public cloud for cost and scalability reasons — lands on hybrid cloud.

And a group of similar organizations, such as several hospitals bound by the same healthcare compliance framework, who want to share the cost of specialized compliant infrastructure without opening it to the general public, lands on community cloud. Recognizing which constraint is driving the decision — cost, control, compliance, or the need to combine more than one of these — is usually the fastest way to identify the correct deployment model in a scenario-based exam question, rather than trying to match the scenario’s wording against a memorized definition word for word.

NFV in More Depth: Chaining Virtual Functions Together

A single VNF rarely operates in isolation. In a real deployment, traffic often needs to pass through multiple virtual network functions in a specific sequence — for example, through a virtual firewall, then a virtual intrusion prevention system, then a virtual load balancer, before finally reaching its destination application.

This ordered sequence of VNFs is called a service function chain, and it’s managed through orchestration software that automatically directs traffic through the correct sequence of virtual functions, and that can automatically scale any individual function in the chain up or down independently based on its own load, without needing to touch the rest of the chain. This composability — mixing and matching virtual functions into whatever sequence a given application needs — is one of NFV’s most powerful advantages over fixed physical hardware, where achieving the same result would mean physically cabling a specific sequence of dedicated appliances together, in a fixed order that’s expensive and slow to change.

VPC in More Depth: Isolation Without Dedicated Hardware

It’s worth reinforcing exactly what makes a VPC’s isolation possible, since it connects directly back to the multitenancy concept covered above. The physical servers, storage, and network hardware underlying a public cloud provider’s infrastructure are shared across enormous numbers of customers simultaneously. A VPC doesn’t carve out dedicated physical hardware for a single customer — instead, it uses software-defined networking techniques (virtual routing, virtual firewalling, and address space isolation enforced by the provider’s underlying platform) to make a customer’s slice of that shared infrastructure behave, from that customer’s perspective, as if it were their own private network.

This is precisely why a VPC can offer meaningfully strong isolation and control while still preserving the cost efficiency of shared, multitenant physical infrastructure underneath. A customer might divide their VPC’s overall address space into several subnets — for instance, one subnet for public-facing web servers and a separate subnet for backend databases — mirroring the same logical segmentation principles used in traditional on-premises network design, just implemented entirely in software within the provider’s platform rather than through physical VLAN-capable switches.

From CapEx to OpEx: The Economics Behind the Shift

Much of the appeal behind both cloud computing generally and NFV specifically comes down to a shift in how organizations pay for infrastructure. Traditional on-premises networking requires capital expenditure (CapEx) — large upfront purchases of physical hardware that then depreciate in value over time, regardless of how much or how little that hardware actually gets used.

Cloud computing and NFV both shift this toward operational expenditure (OpEx) — ongoing, usage-based costs that scale up and down with actual demand, without requiring a large upfront investment or leaving an organization stuck with expensive hardware sitting idle during periods of lower demand. This CapEx-to-OpEx shift is frequently cited as a primary business driver behind cloud adoption, and it’s worth connecting directly back to NFV: a VNF is fundamentally a way of turning what used to be a hardware capital purchase (a dedicated firewall appliance) into a software operating expense (a virtual firewall instance billed by usage).

Hybrid Cloud vs. Multi-Cloud: A Common Point of Confusion

It’s worth explicitly distinguishing hybrid cloud from a related but different concept that often gets mixed up with it: multi-cloud, which simply means using services from more than one public cloud provider simultaneously — for example, running some workloads on one provider and other workloads on a different provider, without necessarily involving any private infrastructure at all. Hybrid cloud specifically means combining private and public infrastructure with the ability to move workloads and data between them; multi-cloud specifically means spreading workloads across multiple public providers, which may or may not also involve any private infrastructure.

An organization can be hybrid, multi-cloud, both at once, or neither — these are two independent architectural decisions, not two names for the same thing, and exam questions that describe “using AWS and Azure together” are describing multi-cloud, not hybrid cloud, unless private infrastructure is also explicitly part of the picture.

A Complete Example: Putting the Pieces Together

Consider a retail company redesigning its infrastructure. It keeps its customer payment database on private cloud infrastructure in its own data center, satisfying strict data residency requirements. Its public-facing e-commerce website runs inside a VPC hosted by a public cloud provider, giving it an isolated, controllable network space within that provider’s shared infrastructure.

Because the two environments are connected and workloads can move between them as needed — the website occasionally needs to securely query the payment database — this overall architecture is a hybrid cloud deployment. Within the VPC, instead of racking physical firewalls and load balancers, the company deploys a service function chain of VNFs: a virtual firewall, then a virtual load balancer distributing traffic across several virtual web server instances.

During a seasonal sales event, elasticity automatically provisions additional web server and load balancer capacity to absorb the traffic spike, then scales back down once the event ends — all without the company needing to purchase a single piece of new physical hardware, reflecting the broader CapEx-to-OpEx shift discussed above. If the company later decides to also run its analytics workloads on a second public cloud provider chosen specifically for its data-analytics tooling, it would additionally become a multi-cloud organization — a separate architectural decision layered on top of, not a replacement for, its existing hybrid cloud design.

Recognition-Level Verification Concepts

This objective is conceptual/comparative, so there’s no hands-on cloud configuration expected on the exam yet. It’s worth recognizing, at a glance, what a cloud provider’s console or CLI output for these concepts generally looks like:

• A VPC is typically identified by a unique ID and an assigned CIDR block (IP address range), along with the region it’s deployed in.
• A deployed VNF (such as a virtual firewall instance) typically appears in a cloud console as a running software instance with an assigned resource type, rather than as physical hardware.
• Elasticity in action is often visible as an automatically changing count of running instances in a console’s monitoring dashboard, rising during a demand spike and falling back down afterward without any manual action from an administrator.

You’ll build directly on this foundation in the next lesson (1.3.2), where the focus shifts from what a VPC is to how traffic actually gets in and out of one — security groups, NAT and internet gateways, and dedicated private connections back to on-premises infrastructure.

Common Exam Traps

• Public vs. private is about ownership and sharing, not about internet accessibility. A private cloud can still be accessed remotely over the internet; what makes it “private” is that the infrastructure is dedicated to one organization, not that it’s cut off from outside access.
• Community cloud is easy to forget entirely — remember it as the middle ground: shared among a defined group of similar organizations, not open to the general public, and not dedicated to just one organization either.
• NFV and SDN are not the same thing. NFV virtualizes individual network functions (turning a firewall or router into software); SDN separates the control plane from the data plane for centralized programmability. They’re complementary, not synonymous — don’t conflate them on the exam.
• A VPC is not the same as a VLAN, even though both create logical isolation. A VLAN segments an existing physical LAN; a VPC is an isolated network space carved out of a public cloud provider’s infrastructure. The underlying context (on-premises LAN vs. public cloud) is what differs.
• Hybrid cloud is a deliberate architectural choice, not just “using more than one cloud provider.” It specifically refers to combining private and public cloud environments with workloads and data able to move between them, not simply having accounts with multiple vendors — that’s multi-cloud, a distinct concept covered above.
• Scalability and elasticity are related but not identical. Scalability is the underlying capability to grow; elasticity is that capability being applied automatically, in real time, and in both directions (up and back down) in response to actual demand. A system can technically be scalable without being elastic if scaling still requires manual intervention.
• Don’t assume “cloud” automatically means “public cloud.” Private cloud, hybrid cloud, and community cloud are all still cloud computing — the term describes the on-demand, virtualized delivery model itself, not any one specific ownership arrangement.