Start with where the application runs
Imagine the same shop from Class Four. It can use Azure for its website, operate a cloud reserved for its organisation, or connect an Azure application to equipment it already has in its building (on-premises). This class explains how those arrangements differ.
A deployment model describes who a cloud is provided for and how cloud environments are combined. A service model, from the previous class, describes which tasks are managed for you. These answer different questions. An Azure virtual machine is an IaaS service in a public cloud.
Public cloud does not mean public data. Your Azure application can require sign-in and restrict its network access. Private cloud does not simply mean a private network or a computer you own. It is a cloud provided exclusively for one organisation and can be operated by someone else.
The storefront can run on Azure, but tonight’s till export still lives beside a device in the shop. Ada draws two boxes and an arrow before she chooses a deployment model. One box is the cloud application; the other is the store system. The arrow needs a working route, name resolution and permission. Calling the drawing “hybrid” does not supply those things. And putting an Azure app behind a private address does not turn the underlying public cloud into a private cloud.
Class Four asked what service you use and which tasks you manage. This class asks who the cloud is provisioned for and how environments are combined. A cloud can be privately owned yet offered to the public; a private cloud can be operated by another company. “Private cloud” is also different from “a service with private network access.”
- Public cloud
- Cloud infrastructure offered for public use. Azure is the public provider used in this course. Access to your application can still be restricted; public cloud does not mean your data is public.
- Private cloud
- Cloud infrastructure provisioned exclusively for one organization. It can be owned or operated by the organization, a third party or both, and located on or off premises.
- Hybrid cloud
- In this course’s practical Azure usage: public cloud combined with private cloud or on-premises systems, with coordinated connections or management. The formal NIST definition is a combination of distinct cloud infrastructures joined to support portability.
- Multi-cloud
- Here, use of two or more public-cloud providers. It can coexist with hybrid: an organization may use Azure, another public provider and on-premises systems together.
Hybrid and multi-cloud answer different questions. Hybrid describes combined environments; multi-cloud describes multiple cloud providers. They can overlap.1 Neither term proves the system is secure, cheaper or able to fail over during an outage.
Edge — when the round trip is the problem
Edge computing places processing near the devices or people producing data—for example, analyzing camera footage in a store before sending a summary elsewhere. It can address response time, transfer volume, cost or operation without a connection. It is a placement approach, not an additional formal NIST deployment-model category.
Consider local processing when a tested remote path misses a response deadline, the volume is too large or costly to send, or the site must keep operating while disconnected. Define safe local behavior and how data is synchronized afterward. Edge systems may work with a public cloud, a private environment or both; the right arrangement depends on the workload.
Play it through
A fictional planning exercise: recommend a pilot for a storefront with a reviewed Azure plan, and retain the existing physical POS job while its licence is unresolved. Include the connection, access controls and a review date. No cloud resources are created by the game.
What "private cloud" actually costs
Private cloud is defined by exclusive organizational use, not by a portal alone. It should still provide cloud characteristics such as on-demand self-service, pooled resources and measured use. An ordinary virtualized server room is not automatically a private cloud.
- Private cloud
- Exclusive cloud infrastructure for an organization. Capacity, operation and pricing depend on whether it is self-operated, hosted or managed by a provider. Ownership and payment terms are separate from the definition.
A private pool can allocate and release capacity within its available resources. Expanding physical capacity needs a plan, but public cloud has quotas and capacity limits too. Hosted and managed private options may use recurring payments rather than upfront hardware purchases. Price the actual service instead of treating “private” as a synonym for capital expense.
Compare private and public options against isolation requirements, supported software, performance, costs and operating skills. Dedicated public-cloud capacity may satisfy some isolation needs; a geographic requirement does not automatically require private cloud. Past spending or remaining depreciation alone should not decide a new investment—compare future avoidable costs, migration effort and risks.
Hybrid: a bridge, and sometimes a home
Hybrid can be a migration stage or a long-term design. For example, a public storefront may need a retained on-premises database or batch job. Document why each component is placed where it is, who operates the connection, and how the system behaves when that connection fails.
Two common Azure connectivity options are site-to-site VPN, an encrypted connection between two networks over the internet, and ExpressRoute, a connection to Microsoft through a connectivity provider rather than through the public internet. Private connectivity is not automatically end-to-end encryption or an application response-time guarantee. Decide which encryption (protecting information in transit), routing (where network traffic goes), capacity and backup connection paths your design needs; other application-level connection patterns also exist. See the ExpressRoute overview.
A temporary hybrid design needs milestones and exit criteria. A long-term hybrid design needs a continuing business case and operating plan. Cost, local operation, data dependencies and supported capabilities can justify it as well as licensing or performance. Review the decision periodically; a permanent arrangement is not inherently an unfinished migration.
Azure Arc-enabled servers represents eligible non-Azure machines as Azure resources for management.2 Install and configure the agent, check its connectivity and supported OS, and select the management services you need. Registration does not move the workload to Azure or create the application’s private network connection.
Azure permissions on the Arc resource govern supported Azure management operations; they do not automatically replace local OS accounts. Applicable policies and machine-configuration features depend on the resource type, installed components and permissions. Monitoring, updates and security services require configuration and may add charges. Arc can help coordinate operations; it does not make every Azure VM policy applicable to every local machine.
Multi-cloud: the honest version
Using multiple public providers can meet a specific business need: acquired systems, a required service, provider diversity or a tested recovery arrangement. It can also add integration, identity, staffing and transfer costs. Define the benefit you want and assess the complete architecture instead of assuming that a second provider delivers it.
| The claim | The honest version |
|---|---|
| "It removes vendor lock-in" | It may reduce single-provider dependence, while adding other provider and integration dependencies; test what can actually move |
| "It gives us resilience" | Only with tested recovery, data replication and dependency management; active-passive or active-active may fit different recovery targets |
| "We can pick the best service from each" | Provider-specific services can be used; they add integration and portability decisions rather than requiring every app to use identical features |
| "It strengthens our negotiating position" | Sometimes real — but split spend also thins the volume discounts each vendor offers |
A second provider is an architecture decision, not a recovery plan.
Separate two designs. One organization can use different providers for unrelated applications without duplicating every app. A single application designed to recover across providers needs data consistency, identity, traffic routing, capacity and a tested procedure. Neither design forces every system to use the lowest common feature set. Cost each relevant data path.3
For recovery, define RTO—how long the business can wait for service to return—and RPO—how much recent data it can afford to lose. Active-active serves traffic in both environments; active-passive holds a recovery environment that takes over when needed. Either can fit some targets when designed and tested correctly. Include replication, standby capacity, failover and failback work; do not assume an exact doubling of cost.
Where Campux lands
Choose a deployment arrangement from requirements and a forward-looking cost comparison. A standard provider can simplify operations, but standards are a team policy, not a definition or proof that every workload should move. The table below names questions to investigate, not an exhaustive list of allowed reasons.
| Reach for | Possible reason to evaluate it | The tell in the room |
|---|---|---|
| Public (single cloud) | A supported service meets workload needs with acceptable costs and operations | A reviewed candidate and acceptance criteria |
| Private | Exclusive-use requirements, supported systems, performance or a favorable full cost comparison | Specific requirements verified against available services |
| Hybrid (bridge) | A migration in progress — some systems moved, some not yet | Milestones, dependencies and exit criteria |
| Hybrid (home) | Local operation, data dependencies, licensing, costs or other ongoing requirements | A continuing business case and an operating plan |
| Edge | Latency below the nearest region, bandwidth too large to ship, or operation that must survive a dropped link | Measured response time, transfer volume and disconnected behavior |
| Multi-cloud | Acquired systems, service choice, provider diversity or a tested recovery requirement | A named benefit, costed design and recovery tests if needed |
For each candidate, record the requirement, evidence, costs, unresolved questions and owner. An abstraction such as “flexibility” becomes useful when you define what must move, how quickly and at what cost. That makes the proposal testable without dismissing the business goal.
A public-cloud pilot and a reviewed hybrid connection
For this fictional exercise, assume the storefront’s Azure design passes its compatibility, cost and operating review. A single-provider pilot lets the small team test the business goal without adding an unneeded second deployment. This is a recommendation under stated assumptions, not a rule that private or multi-cloud designs cannot fit small teams.4
Retain the physical POS job while the current licence does not permit the proposed cloud VM. Design the required connection, access controls, monitoring and failure behavior. Assign the licence question an owner and review date. The hybrid connection ends only if the replacement design is approved and its dependencies no longer need that connection.
The decision record should show the options considered, the assumptions behind the chosen pilot, and what evidence would change it. A resolved licence is one input to reassessment; it does not automatically prove that a replacement is ready or that the link can be removed.
Zoom out: every model you add is a surface you now operate
You can name public, private, hybrid, and multi-cloud. Now reason about what each choice does to the whole estate, because a deployment model is a promise about how many worlds your team must keep alive at once.
A second provider adds skills and integration work. Compare that work with the named benefit and decide which common standards or management tools reduce the burden.
A hybrid application may depend on cross-environment routing, identity and name resolution. Trace those dependencies and test loss of the connection instead of assuming that two environments give independent resilience.
Identify the actual limits: team skills, service compatibility, recovery targets, data consistency and budget. Multiple providers do not necessarily require separate teams, but the work still needs owners.
Self-operated private infrastructure needs capacity and hardware-refresh plans; hosted options have different terms. Include the ongoing contract and operating tasks in the comparison.
A hybrid link that is fine for one nightly batch becomes both the bottleneck and the single point of failure once the whole estate depends on cross-boundary traffic.
The engineer who ships is asked "where does it run?" The engineer who gets promoted is asked "and how many worlds does the team now keep alive?" — and has counted the cost of each.
Sort applications by their requirements
If a requirement restricts where data is stored or processed, verify the available services and their commitments first. A suitable public region may fit, or a local component may be required. Hand the responsible teams a documented design and the evidence that its complete data path meets the approved requirement.
Follow the till export
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Store device → office batch job → cloud reporting Office batch depends on local device and licence Reporting accepts a nightly file
Place each component on paper and draw the actual file path.
Mark where route, DNS and authentication must work.
Name the evidence needed before moving the office job.
On your own: change one constraint. The till vendor lifts the licence restriction and publishes a cloud API for exports. Redraw the path: what can move now, and what evidence do you still need first?
Check your reasoning after you finish
On your own: the office batch job can be considered for the cloud once the vendor API, its authentication and the failure handling are tested; the store devices stay where they are. Keep the constrained device-facing job local until its requirements are resolved. The reporting component may run in cloud. Test the cross-boundary transfer and failure handling. Private addresses describe reachability; they do not alone establish a private-cloud deployment.
Examination
Four graded drills and two unscored situations. Try your reasoning before revealing the model response. Practice preserves the first-attempt score; the lesson game can save progress in this browser.
B. In this course’s practical usage, hybrid combines public cloud with private cloud or on-premises systems. Multi-cloud refers here to multiple public providers; the same estate can be both. Private network access and multiple Azure regions do not by themselves create a private cloud or a hybrid estate.
B. The software can allocate resources in the pool; it cannot create extra physical servers. This does not mean private clouds lack elasticity, or that public clouds have unlimited capacity. Both designs need capacity planning, and public services also have quotas and availability limits.
The approved requirement, measured performance and future cost comparison. These are evidence to investigate, not automatic proof that only private cloud can fit. Dedicated public options may meet some requirements. Past spending alone is not a reason to continue; compare the future options.
MEMORANDUM — Resilience via multi-cloud
1. Run the storefront on Azure and a second public cloud in parallel.
2. If one provider suffers an outage, the other serves all traffic.
3. This also reduces our dependence on any single vendor.
4. Cost impact is minimal, since we would pay for the compute either way.
Line four. This proposal runs both environments live, so it needs a budget for both, plus replication, transfer paths, monitoring and operation. Cost impact is not established by saying the team would pay for compute anyway. Other recovery designs may use a standby environment; cross-provider recovery does not universally require active-active operation.
Before approving the plan, define recovery targets, identify shared dependencies and test failover, data consistency and failback. Estimate the actual design rather than assuming either minimal cost or an exact doubling. A second provider alone does not establish resilience.
Start with the desired benefit: what dependence should be reduced, and what recovery or service requirement should be met? Multiple providers can help some goals, but the actual application and operating design determine the result.
Price the proposed integration, skills, identity, transfers, monitoring and standby or live capacity. Separate running unrelated applications on different providers from duplicating this storefront. Do not assume every application must use only features common to both providers.
For the fictional team, recommend the reviewed single-provider pilot unless the additional design has a demonstrated benefit. Standard interfaces, infrastructure definitions and tested exports can help portability; containers and infrastructure as code do not guarantee it. Record a date and conditions for reassessment.
Temporary hybrid needs milestones and exit criteria. Long-term hybrid needs a continuing business case, such as local operation, supported dependencies, cost or licensing. Ask what “just in case” is meant to protect against, then test whether the proposed design actually provides that protection.
Include both environments, the connection, identity, monitoring, updates and recovery in the cost comparison. Hybrid may earn that work through a concrete benefit; without a defined benefit, the team cannot judge whether it is worth maintaining.
For the fictional POS job, retain and support the existing machine while the licence is unresolved. Assign an owner and review date, and test the connection’s behavior. Reassess the replacement and each dependency before retiring the link; completing a migration is not a reason to remove a still-needed capability.
Five things worth carrying out of this class
- Service models describe the service and operating tasks. Deployment models describe intended use and combined environments; ownership and location are separate choices.
- Hybrid combines environments; multi-cloud uses multiple providers. One estate can be both.
- Private cloud is exclusive to one organization and can be hosted by another company. Both private and public options have capacity limits and costs to assess.
- Temporary hybrid needs exit criteria. Long-term hybrid needs a continuing business case and an operating plan.
- Multiple providers do not automatically deliver portability or resilience. Define the benefit, price the design and test recovery if it is part of the goal.
- NIST defines public, private, hybrid and community cloud. Community cloud serves organizations with shared concerns. This course also uses the broader practical Azure meaning of hybrid with on-premises systems. ↩
- The Arc-enabled servers overview describes the management agent and supported integrations. Check each policy, extension, access boundary and service’s charges; registration alone does not configure them. ↩
- Azure bandwidth pricing varies with the source, destination, service and route. Price each transfer direction separately; receiving data does not automatically incur the same charge as sending it. Other providers have their own terms. ↩
- The fictional case illustrates a choice under stated assumptions. Reuse the assessment method, not the conclusion. A geographical requirement, steady load or prior hardware purchase alone does not decide the model. ↩
Distinguish public and private cloud from private network access, and explain a hybrid placement plan using tested requirements.
Play the lesson above to stamp this class.
Next, the three big clouds side by side, without the fan-club noise.
Next · AWS, Azure & GCP →