4 Cloud Deployment Models: Ownership and Risk

4.1 Start With the Decision

This section: Start With the Decision — A cloud model sets who owns the service, hardware, and risk.

A cloud model sets who owns the service, hardware, and risk. Choose the boundary before comparing price or scale.

4.2 Route Overview

This section: Route Overview — This is part 1 of 2.

This is part 1 of 2. Continue with Cloud Deployment Models: Multi-Site Cold Storage.

4.3 Part Objectives

This section: Part Objectives

• Trace deployment models are boundary choices across its components and failure boundaries.
• Validate hybrid boundary pattern with a concrete scenario and pass criteria.

4.4 Chapter Roadmap

This section: Chapter Roadmap

• Start With the Boundary That Must Hold
• In 60 Seconds
• Minimum Viable Understanding
• Quick Check: Workload Placement Proof
• Deployment Models Are Boundary Choices
• The Placement Route
• Edge Is The First Deployment Boundary
• Hybrid Boundary Pattern

4.5 Start With the Boundary That Must Hold

This section: Start With the Boundary That Must Hold — Picture a hospital storing equipment records.

Choose Who Owns the Service and Its Risk

Picture a hospital storing equipment records. A shared outside service may grow quickly and reduce local work. A private service may give the hospital more direct control. Neither choice is safe until ownership, access, outage, and exit plans are clear.

A cloud deployment model describes who owns the computing setting and who shares it. The architect should begin with the data and decision. Name who may reach them, where they may be kept, how fast service must recover, and who answers when a supplier or local site fails.

Compare each option with the same bad-day tests. Remove the outside link, lose one account, restore a saved copy, and move a small record to another setting. Count the staff work as well as the service bill.

Write one page for the choice. Show the boundary, the owner on each side, the facts that cross, and the safe response to loss. Include how the team will leave the setting without losing needed records or breaking the service.

Review the page with support, legal, finance, and service staff. Each group sees a different risk. Repeat the review when the supplier, site, data use, or recovery promise changes. A model name should never replace this shared decision.

Set a date to prove the exit and recovery paths. Restore a small saved record into a clean setting. Remove one user and one supplier link. Check that service owners can find the result without help from the person who wrote the design.

Keep claims narrow. A shared setting can still isolate work well. A private setting can still be poorly run. Judge each control from tested evidence and a named owner, not from where the machines sit.

Use the same scorecard for every option. Who owns the machines? Who can enter? Who can read the data? Where are copies kept? What happens without the outside link? How is service restored? How can the team leave?

Mark each answer as proven, planned, or open. A contract may support a plan. Only a test proves the working path. An open item needs an owner and date. A missing answer blocks any claim that depends on it.

Compare the normal day and the bad day. Count staff work, delay, cost, and lost control. Keep the service outcome in view. The best setting is the one that meets the stated need with risks the team can own and test.

The labels public, private, community, and hybrid do not prove control by themselves. Practitioner records the boundary choices. Under the Hood examines isolation, identity, network paths, and shared responsibility.

A deployment model is not a brand of cloud. It is the boundary around data, control, latency, ownership, and recovery for a specific IoT workload.

Start simple: follow one message from device to decision and mark where it may leave the site, where it must stay local, and who must be able to inspect it later. Public, private, community, and hybrid choices then become boundary choices instead of labels.

4.6 Learning Objectives

This section: Learning Objectives

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

• Compare public, private, community, and hybrid deployment models for IoT workloads.
• Separate cloud deployment decisions from edge placement decisions.
• Classify IoT data and control paths before choosing where each workload runs.
• Design hybrid boundaries that preserve latency, governance, resilience, and auditability.
• Produce a placement record that explains the deployment choice without depending on brittle provider or pricing assumptions.

4.7 Quick Check: Workload Placement Proof

This section: Quick Check: Workload Placement Proof

4.8 Deployment Models Are Boundary Choices

This section: Deployment Models Are Boundary Choices — Do not apply deployment models are boundary choices until its premise is visible near Dedicated use in Figure 4.1: Deployment models separate ownership, sharing, and operating control before any provider choice is made.

The useful question is not “which cloud is best?” The useful question is “which boundary should this workload cross, and what record proves that boundary is safe enough?” A single IoT system can include device firmware, gateways, site services, private cloud resources, public cloud analytics, and shared partner workflows. Treat each part separately.

Do not apply deployment models are boundary choices until its premise is visible near Dedicated use in Figure 4.1: Deployment models separate ownership, sharing, and operating control before any provider choice is made. Inspect the span to Common schema.

+

The axes in Figure 4.1 separate dedicated from shared use and organization from provider or group operation. Private cloud gives a dedicated boundary with local governance over raw data. Public cloud offers shared elastic services and managed ingestion; community cloud serves a governed group with a common schema and tenant rules. Hybrid joins local and shared zones through an explicit movement contract. A cold-storage design can use more than one quadrant, because local protection, site records, fleet reporting, and partner review have different owners. Choose the boundary for each workload and record who controls access, data movement, recovery, and changes before choosing a provider.

4.9 The Placement Route

This section: The Placement Route — Workload placement should follow evidence.

Workload placement should follow evidence. Start with the data and control path, not the cloud product list.

Figure 4.2 turns workload constraints into a placement decision.

+

Start with the control path and data flow, then classify what is raw, derived, shared, and retained. Timing evidence asks which decisions must continue during an outage and what latency each path allows. Those facts narrow placement among edge, private, public, or hybrid resources. Access rules and retention controls then define who can use the data in each location. The final evidence field names the tests, owners, and review record supporting the choice. A diagram location by itself does not settle responsibility; the selected boundary must also say who handles failure and later data review.

Apply that route to each IoT workload by naming the job first: an emergency-stop decision, five-minute telemetry summary, maintenance dashboard, model-training job, or partner report. Then classify its raw readings, derived summaries, identifiers, operating context, calibration evidence, and audit records. Timing narrows the placement further by separating hard real-time control from near-real-time operations, delayed analytics, and archival inspection.

Next, challenge the connectivity assumption. Record what continues locally during an outage, what may queue, and what can safely be dropped before assigning the workload to edge, private cloud, public cloud, community cloud, or a hybrid path. Attach identity, encryption, segmentation, minimization, retention, monitoring, backup, and change-review controls to that choice. The route closes only when a short validation record preserves the assumptions, tests, failure behaviour, and accountable owners.

4.10 Edge Is The First Deployment Boundary

This section: Edge Is The First Deployment Boundary — Edge is not one of the four classic cloud deployment models, but it is often the first boundary an IoT architect must decide.

Edge is not one of the four classic cloud deployment models, but it is often the first boundary an IoT architect must decide. A deployment model that ignores the edge usually becomes unreliable or expensive.

Use edge or site-local processing for:

• Safety, actuation, or equipment protection paths.
• Filtering, compression, and data-quality checks before transmission.
• Offline buffering when connectivity is intermittent.
• Local dashboards used by operators during an incident.
• Data minimization before sending information outside the site.

Use cloud-side processing for:

• Cross-site analytics and long-range trend detection.
• Fleet-wide dashboards and reporting.
• Model training, simulation, and historical replay.
• Shared data products that require controlled access from many locations.

The cloud should not be in the critical path for a decision that must complete faster than the network can reliably support. The edge should not be forced to store or analyze years of data when central systems can do that better.

4.11 Hybrid Boundary Pattern

This section: Hybrid Boundary Pattern — In a strong hybrid design, raw events do not drift casually between zones.

In a strong hybrid design, raw events do not drift casually between zones. The architecture defines a boundary and a transformation rule.

For hybrid boundary pattern, inspect Figure 4.3 at Hybrid Cloud IoT Architecture. Its visible premise is: Hybrid cloud IoT architecture: sensitive data stays in a private cloud with real-time processing while anonymized data flows to public cloud analytics, coordinated by a policy-driven workload router. Then compare Compliance Audit.

+

The router in Figure 4.3 classifies a gateway input before it crosses zones. Time-critical fault detection stays at the site, so it can run when the network is down. Identifiable or sensitive raw data follows the private route. An approved summary can be filtered, summarized, or signed before public analytics receives it; raw sensitive data does not cross that boundary. The figure also marks the need for ingress, classification, movement, return, failure, and change rules. Those rules matter when a model or configuration comes back from cloud to site, because local control and the data class still need an owner and a release check.

A durable hybrid boundary includes:

• Ingress rule: which devices and gateways can write data into the local system.
• Classification rule: how raw, sensitive, aggregate, and public data are tagged.
• Transformation rule: what must be filtered, summarized, anonymized, or signed before movement.
• Movement rule: which zone receives each data class and under what schedule.
• Return rule: what can come back from cloud to site, such as models, dashboards, or configuration.
• Failure rule: how the site behaves when the interconnect, cloud service, or identity provider is unavailable.
• Change rule: who can change the placement policy and how the change is tested.

4.12 Continue to the Next Part

This section: Continue to the Next Part — Carry this evidence into Cloud Deployment Models: Multi-Site Cold Storage, which begins with Scenario: Cold Storage Across Many Sites.

Carry this evidence into Cloud Deployment Models: Multi-Site Cold Storage, which begins with Scenario: Cold Storage Across Many Sites.