1.2 On-Premises, Cloud & Hybrid Infrastructure Deployment Models
Key Takeaways
- ENCOR v1.2 topic 1.1.a lists cloud alongside 2-tier, 3-tier, and fabric as a high-level enterprise design model, so cloud deployment choices are Architecture-domain exam content, not an optional aside.
- The three service models differ only in where the tenant/provider responsibility line falls: IaaS gives the tenant the guest OS upward, PaaS gives the tenant the application and data, and SaaS leaves the tenant only identity, data, and access policy.
- Private connectivity services such as AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect deliver deterministic latency and committed bandwidth over a provider cross-connect, while IPsec-over-Internet trades that determinism for cost and deployment speed.
- Cisco Catalyst SD-WAN Cloud OnRamp automates cloud attachment in three flavours: Cloud OnRamp for SaaS picks the best-performing path per application, Cloud OnRamp for Multicloud builds and manages transit gateway/vWAN attachments, and Cloud OnRamp for Colocation stitches service chains in a colo facility.
- Backhauling all cloud traffic to a data center hairpin adds a fixed latency penalty and consumes WAN capacity; Direct Internet Access with a cloud security edge (SASE/SSE) removes the hairpin but moves policy enforcement into the cloud.
1.2 On-Premises, Cloud & Hybrid Infrastructure Deployment Models
ENCOR v1.2 topic 1.1.a reads: "High-level enterprise network design such as 2-tier, 3-tier, fabric, and cloud." Cloud is listed as a peer of the campus topologies you studied in Section 1.1 — it is a design model, not a footnote. The exam expects you to reason about where infrastructure lives, who operates each layer, and how enterprise traffic reaches it. This is a describe/explain topic: you will not be asked to configure an AWS VPC, but you will be asked which connectivity model satisfies a stated latency, compliance, or cost requirement.
+-----------------------------------------------------------------------------------+
| WHERE ENTERPRISE INFRASTRUCTURE CAN LIVE (v1.2 topic 1.1.a) |
+-----------------------------------------------------------------------------------+
| |
| ON-PREMISES COLOCATION PRIVATE CLOUD PUBLIC CLOUD |
| +--------------+ +--------------+ +--------------+ +--------------+ |
| | Your DC | | Provider hall| | Your HW, | | AWS / Azure | |
| | Your racks | | Your racks | | cloud-like | | GCP / OCI | |
| | Your power | | Their power | | self-service | | Their HW | |
| | Full control | | Rich peering | | Full control | | Elastic | |
| +--------------+ +--------------+ +--------------+ +--------------+ |
| \____________________\_________________/_________________/ |
| | |
| HYBRID / MULTICLOUD |
| (workloads split across two or more of the above) |
+-----------------------------------------------------------------------------------+
1. Cloud Service Models and the Shared Responsibility Line
The only thing that distinguishes IaaS, PaaS, and SaaS is where the responsibility boundary sits. Memorise the boundary, not the marketing.
| Layer | On-Premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Data and access policy | Tenant | Tenant | Tenant | Tenant |
| Application | Tenant | Tenant | Tenant | Provider |
| Runtime / middleware | Tenant | Tenant | Provider | Provider |
| Guest OS and patching | Tenant | Tenant | Provider | Provider |
| Hypervisor | Tenant | Provider | Provider | Provider |
| Compute / storage / network HW | Tenant | Provider | Provider | Provider |
| Physical facility and power | Tenant | Provider | Provider | Provider |
The rule that survives every exam rewording: the tenant is always responsible for its own data, its own identity and access management, and its own traffic-steering policy — even in SaaS. A question that says "the provider handles security" is describing infrastructure security, never data governance.
- IaaS — you rent virtual machines, virtual networks, and block storage. Examples: AWS EC2/VPC, Azure Virtual Machines/VNet. This is where a network engineer does the most work, because the tenant owns routing, subnetting, security groups, and route tables.
- PaaS — you deploy code against a managed runtime. Examples: Azure App Service, AWS Elastic Beanstalk. Networking shrinks to service endpoints and private link.
- SaaS — you consume a finished application. Examples: Microsoft 365, Salesforce, Webex. Networking shrinks to reachability and performance — which is precisely why Cloud OnRamp for SaaS exists.
2. Cloud Deployment Models
| Model | Definition | Typical driver | Networking consequence |
|---|---|---|---|
| Private cloud | Cloud-style self-service on infrastructure dedicated to one tenant, on-prem or hosted | Data residency, regulated workloads | You own the fabric; VXLAN/EVPN or ACI underneath |
| Public cloud | Multi-tenant provider infrastructure consumed on demand | Elasticity, no CapEx, global reach | You own only the overlay constructs (VPC/VNet, route tables) |
| Hybrid cloud | Orchestrated combination of private and public with workload portability | Burst capacity, DR, phased migration | Requires consistent addressing, routing, and policy across both |
| Multicloud | Two or more public providers used deliberately | Avoiding lock-in, best-of-breed services | Transit/interconnect design becomes the hard problem |
| Community cloud | Shared by organisations with common compliance needs | Government, healthcare consortia | Shared trust and segmentation model |
Hybrid is not multicloud. Hybrid mixes private with public; multicloud uses more than one public provider. An exam stem that says "the organisation runs production in AWS and analytics in Azure" is describing multicloud, even if a private data center also exists.
3. On-Premises vs. Cloud: The Design Trade-Off Matrix
| Dimension | On-premises | Public cloud |
|---|---|---|
| Cost model | CapEx — buy capacity for peak, depreciate over years | OpEx — pay per hour/GB, no idle capital |
| Capacity | Fixed until the next purchase cycle | Elastic within seconds/minutes |
| Latency to users | Deterministic; you control every hop | Depends on region selection and path to the provider edge |
| Control | Full — you choose ASICs, code versions, and maintenance windows | Limited — provider controls the underlay and its change windows |
| Compliance / data residency | You can prove physical location | Must select region and verify provider attestations |
| Failure domain | Your DC is the blast radius | A provider region or AZ is the blast radius |
| Refresh burden | Hardware refresh every 5-7 years | None; the provider refreshes silently |
| Skills | Deep platform expertise | Cloud networking constructs plus automation |
The exam framing: cost is rarely the deciding factor in an ENCOR question. Look instead for the words latency, deterministic, regulated, data residency, seasonal/bursty, or global reach — each maps cleanly to one column.
4. Cloud Connectivity Options
This is the part an ENCOR candidate must know cold, because it is genuinely a routing and WAN-design question.
4.1 Internet-based connectivity
- Direct Internet Access (DIA) — the branch reaches SaaS and IaaS directly over its local broadband/LTE circuit. Lowest latency, no hairpin, but every branch becomes an Internet edge that needs security.
- IPsec VPN over the Internet — an encrypted tunnel from an enterprise router to a cloud virtual gateway (AWS Site-to-Site VPN, Azure VPN Gateway). Fast to deploy, per-tunnel throughput caps (commonly ~1.25 Gbps per AWS VPN tunnel), and best-effort latency.
- Cloud-hosted router — a virtual Cisco Catalyst 8000V deployed inside the provider VPC/VNet, terminating enterprise IPsec/SD-WAN tunnels and running the enterprise routing protocol into the cloud. This gives you full BGP control and transit routing in the cloud.
4.2 Private connectivity services
| Provider | Service | What it actually is |
|---|---|---|
| AWS | Direct Connect (DX) | Dedicated or hosted cross-connect at a DX location; BGP peering; private and public VIFs |
| Microsoft Azure | ExpressRoute | Private circuit via a connectivity provider; private and Microsoft peering |
| Google Cloud | Cloud Interconnect | Dedicated or Partner Interconnect with BGP over VLAN attachments |
| Oracle | FastConnect | Equivalent dedicated cross-connect model |
All four share the same properties: deterministic latency, committed bandwidth, does not traverse the public Internet, and is billed as a circuit plus egress. All four also share the same trap: they are not encrypted by default. If a question requires both a private path and confidentiality, the answer is a private circuit with IPsec (or MACsec) layered on top, not the circuit alone.
4.3 Cloud transit constructs
Once more than a handful of VPCs/VNets exist, point-to-point peering collapses under N-squared growth. Providers solve this with hub constructs:
- AWS Transit Gateway (TGW) — a regional hub that attaches VPCs, VPNs, and Direct Connect gateways; supports route tables for segmentation.
- Azure Virtual WAN (vWAN) — a managed hub with hub-to-hub transit and integrated firewall.
- Google Network Connectivity Center — hub-and-spoke transit for VPCs and hybrid attachments.
The design principle is identical to the campus core: an explicit transit tier scales linearly, a full mesh does not.
5. Cisco Catalyst SD-WAN Cloud OnRamp
ENCOR topic 1.2 covers the SD-WAN solution; cloud attachment is where topics 1.1.a and 1.2 meet. Cloud OnRamp ships in three distinct flavours, and confusing them is a classic exam error.
| Flavour | Problem it solves | Mechanism |
|---|---|---|
| Cloud OnRamp for SaaS | Which path gives the best experience to Microsoft 365 / Webex right now? | WAN Edge probes each transport with HTTP/HTTPS probes to the SaaS endpoint, computes a vQoE score (0-10), and steers the application over the best-scoring path |
| Cloud OnRamp for Multicloud | How do I automate VPC/VNet attachment and segmentation? | SD-WAN Manager orchestrates cloud gateways (Catalyst 8000V) and maps SD-WAN VPNs to cloud VPCs/VNets, TGW, or vWAN |
| Cloud OnRamp for Colocation | How do I service-chain security/optimisation near the cloud edge? | Instantiates virtual network functions in a colo facility and chains traffic through them |
Cloud OnRamp for SaaS is application-path selection. Cloud OnRamp for Multicloud is infrastructure automation. If the stem mentions Microsoft 365 quality, it is SaaS. If it mentions attaching VNets or transit gateways, it is Multicloud.
6. Traffic Patterns: Backhaul, Hairpin, and the SASE Answer
The legacy pattern backhauls every branch flow to a regional data center for inspection, then out to the cloud. That is one extra WAN traversal in each direction — a hairpin. For a branch 40 ms from the DC and 20 ms from the nearest SaaS front door, backhauling turns a 20 ms path into roughly 100 ms round-trip, which is enough to make a voice or virtual-desktop session feel broken.
BACKHAUL (hairpin) DIRECT INTERNET ACCESS + CLOUD SECURITY
Branch --40ms--> DC --20ms--> SaaS Branch --20ms--> SASE PoP --5ms--> SaaS
^ | (policy enforced in the cloud edge)
+---------- return ------------+
~120 ms RTT, DC WAN carries the load ~50 ms RTT, branch WAN carries the load
The modern answer is DIA plus a cloud security edge — Secure Access Service Edge (SASE) or its security-only subset, Security Service Edge (SSE). Policy still exists; it just runs in a provider point of presence instead of your data center. Section 17.2 covers the SASE building blocks in depth.
7. Cloud-Managed vs. On-Premises Controllers
One more axis the blueprint's "cloud" wording covers: the management plane itself can be on-prem or cloud-hosted, independently of where the data plane lives.
- On-premises controller — Cisco Catalyst Center appliance in your data center. You own upgrades, backups, and HA (see Section 15.1).
- Cloud-hosted controller — Cisco Meraki dashboard, or Catalyst SD-WAN Manager hosted in Cisco-managed cloud. The provider owns availability; you own the WAN path to reach it.
The critical operational property is identical in both cases and is a favourite exam point: loss of the management plane does not stop forwarding. A Meraki network keeps switching and routing when the dashboard is unreachable, and an SD-WAN fabric keeps forwarding when SD-WAN Manager is down — exactly as a Catalyst SD-WAN fabric keeps forwarding when all SD-WAN Controllers fail (Section 3.1). Control-plane and management-plane separation is the whole point of the architecture.
A regulated financial services firm must run its core trading application on infrastructure where it can prove the physical location of every disk, choose the exact switch ASIC and IOS-XE version, and schedule its own maintenance windows. It also wants elastic capacity for a quarterly risk-modelling batch job that runs for 36 hours and is idle the rest of the quarter. Which deployment model best satisfies both requirements?
An enterprise establishes an AWS Direct Connect circuit from its data center to a Direct Connect location and runs BGP over a private virtual interface to reach its production VPC. The security team asserts that because the traffic never traverses the public Internet, no additional protection is required for data in transit. Which statement correctly evaluates this position?
A network architect is designing connectivity for 300 branch offices whose users are heavy consumers of Microsoft 365. Today every branch backhauls all traffic over MPLS to a regional data center, where it is inspected and forwarded to the Internet. Users report poor Teams call quality. The architect deploys Cisco Catalyst SD-WAN and needs the WAN Edge routers to continuously measure each available transport toward the Microsoft 365 front door and automatically move the application onto whichever path is performing best. Which Cloud OnRamp capability delivers this behaviour?
An organisation runs its customer-facing application entirely on Salesforce (SaaS). Following a breach investigation, auditors find that a departing employee exported the full customer list because no export restriction had been configured on their role. Under the shared responsibility model, who was responsible for the control that failed?