5 Cloud Deployment Models: Multi-Site Cold Storage

5.1 Start With the Decision

A cold-store group tracks heat, doors, power, and repairs at many sites. Each data path needs a clear owner and boundary.

5.2 Route Overview

This is part 2 of 2. Review Cloud Deployment Models: Ownership and Risk for the preceding evidence.

5.3 Learning Objectives

• Test scenario: cold storage across many sites with a concrete scenario and pass criteria.
• Validate hybrid fails at movement rules with a concrete scenario and pass criteria.

5.4 Chapter Roadmap

• Scenario: Cold Storage Across Many Sites
• Governance Matrix Without Wide Tables
• Interaction: Placement Decision Check
• Match Models to Boundary Records
• Interaction: Order The Placement Steps
• Readiness Record
• Common Failure Patterns
• Hybrid Is a Contract
• Putting Cloud In A Safety Loop
• Moving Raw Data Before Classifying It
• Assuming Private Means Operated Well
• Using Community Cloud Without Governance
• Placement as Boundary Contract
• Workload Placement Record
• Hybrid Fails at Movement Rules
• Summary
• Key Takeaway
• What’s Next?

5.5 Scenario: Cold Storage Across Many Sites

Consider an organization that monitors cold rooms across many facilities. Sensors report temperature, door status, power state, and maintenance events. The system needs local alarms, central maintenance planning, and shared compliance evidence.

5.6 Governance Matrix Without Wide Tables

Avoid a single wide comparison table. For review, use compact placement cards that fit on mobile and desktop.

At governance matrix without wide tables, Data class makes the architecture testable. In Figure 5.1, Aggregated operations frames this claim: A governance matrix maps data classes to allowed placement zones and required controls. Read it against Data class.

The route through Figure 5.1 is figure-specific: Data class states one concern, Aggregated operations names another, and approval, rollback closes the scope. That structure supports governance matrix without wide tables: A governance matrix maps data classes to allowed placement zones and required controls.

5.7 Interaction: Placement Decision Check

5.8 Match Models to Boundary Records

5.9 Interaction: Order The Placement Steps

5.10 Readiness Record

The final design should leave a short record that another architect can challenge. A deployment decision is weak if it only says “we chose cloud” or “we chose hybrid.” It should identify the workload, boundary, assumptions, controls, and validation results.

The chapter needs visual evidence for readiness record. Figure 5.2 provides it: A deployment readiness record captures the workload, placement, controls, failure behavior, and owner before the design is accepted. Examine Workload together with Access/movement.

The route through Figure 5.2 is figure-specific: Workload states one concern, Access/movement names another, and Evidence/change gate closes the scope. That structure supports readiness record: A deployment readiness record captures the workload, placement, controls, failure behavior, and owner before the design is accepted.

Use these review prompts:

• Workload: What decision, data flow, report, or model job is being placed?
• Boundary: Which zone owns the raw data, derived data, and control path?
• Timing: What latency is required, and what test result proves it?
• Connectivity: What happens when the network, identity provider, or cloud service is unavailable?
• Data movement: What transformations occur before data crosses a boundary?
• Access: Which roles can read, write, approve, or export each data class?
• Operations: Who patches, monitors, backs up, restores, and changes the workload?
• Validation: Which tests, logs, or screenshots prove the design works?

5.11 Common Failure Patterns

5.12 Placement as Boundary Contract

A deployment model is not a provider label. It is a boundary contract for a specific workload: who owns the infrastructure, which data can cross the boundary, which decisions must stay local, which controls are required, and which failure mode has already been tested.

The same IoT product can use multiple placement answers. A local shutdown loop, a raw historian, a fleet dashboard, and an auditor report do not have the same latency, sensitivity, owner, or recovery requirement.

For a cold-storage fleet, write the boundary as four workloads before choosing a provider zone. The alarm workload is edge or private because compressor shutdown and local sirens must work when WAN service is down. The raw-record workload stays in private site services because temperature traces, door openings, and maintenance timing expose operations. The analytics workload can use public cloud after the gateway emits hourly aggregates with schema version, data-quality flags, and approved site identifiers. The auditor workload can use a community or partner zone only for signed reports with expiry, redaction, and dispute rules.

The deployment model is therefore not "hybrid" as a slogan. It is a set of allowed crossings. Raw traces do not cross. Summary features cross one way. Validated model artifacts may return only after release approval. Local control never waits for the cloud path. These statements give engineers, security reviewers, and operations teams something concrete to test when network links, identity services, storage queues, or dashboard services are degraded.

That boundary contract is also the learner's inspection checklist: identify the workload, name the owner, state the allowed movement, and attach the test that proves the placement still works when a dependency fails.

For a cold-storage fleet, the compressor shutdown loop belongs at the edge because it must work during a WAN outage. Raw temperature and door telemetry may stay in a private site store because it exposes operational timing and maintenance behavior. Hourly temperature summaries, device-health aggregates, and signed compliance packages can move to public or community cloud when their audience, retention, and redaction rules are explicit.

The boundary contract should also describe reverse movement. A cloud-trained anomaly model or configuration change is not allowed back into the gateway just because it was produced centrally. It needs a version, validation result, rollback path, and local owner. Without those fields, the design has only named zones, not a deployment model that can survive operations.

5.13 Workload Placement Record

Make one placement record per workload. Do not approve a whole system as public, private, community, or hybrid in one sentence. The record should let a reviewer challenge the exact boundary being crossed.

Write the record in concrete nouns. "Public cloud for analytics" is too vague; "hourly aggregate compressor-health features from sites A through F, written to the central analytics account after identifier removal and schema validation" is reviewable. The record should name the producer, destination, data class, transformation, owner, retention period, and the evidence that proves the route worked under normal and degraded conditions.

For the cold-storage scenario, the local alarm workload needs a latency and outage drill, not a dashboard screenshot. The raw telemetry workload needs data classification, encryption boundary, retention, and restore proof. The summary-export workload needs a schema version, aggregation method, reconciliation check, and access log. The model-return workload needs staged deployment, gateway compatibility checks, drift monitoring, and rollback evidence. Those are different records because they fail in different ways.

5.14 Hybrid Fails at Movement Rules

Hybrid designs usually fail when the boundary is drawn but the movement rule is vague. If raw data, model artifacts, commands, dashboards, and reports all move through the same path, the deployment model stops expressing risk. The architecture needs separate rules for direction, transformation, identity, outage behavior, and rollback.

For example, an MQTT gateway in a cold room can write raw sensor events to a site historian and local object store, then publish only hourly feature rows to a cloud ingestion service such as AWS IoT Core or Azure IoT Hub when policy allows. The outbound message should carry the schema version, device group, aggregation window, quality flags, and release status, not the full raw trace. A cloud analytics job can train or score models against those approved rows, but a model artifact returning to the gateway should travel through a release service with signing, compatibility checks, staged rollout, and a known previous version.

The same movement rule has to survive failure. If the MQTT broker, private link, identity provider, or cloud queue is unavailable, the gateway keeps local alarm logic running and stores bounded summaries for later upload. If the summary queue fills, the system marks missing windows rather than inventing continuous coverage. If a returned model causes unstable alarms, the gateway rejects or rolls back that version and records the reason. The deployment model is operational only when these enforcement points are visible in gateway configuration, queue policy, storage retention, cloud IAM, release metadata, and incident procedures.

These controls make the boundary executable: firmware, broker policy, storage policy, identity roles, model-release metadata, and operator runbooks all encode the same movement decision.

In practice, the movement rule often has to be enforced by more than policy text. Gateways tag records before export, queues separate raw telemetry from approved summaries, object storage buckets use different retention and access rules, and cloud analytics jobs reject unknown schema versions. Identity also has to be directional: the cloud analytics service may read approved summaries, while only a validated release service can push a model artifact back to gateways.

Failure handling is part of the same rule. If the interconnect is unavailable, gateways buffer summaries locally, keep alarms running, and mark late uploads. If the identity provider is unavailable, local control continues with cached permissions while administrative changes wait. If a returned model performs badly, the gateway falls back to the previous approved version. These mechanics are what make hybrid a working deployment pattern instead of a diagram.

5.15 Summary

Cloud deployment models help IoT architects decide where workloads belong:

• Public cloud fits approved elastic workloads and shared analytics.
• Private cloud fits raw, sensitive, local, or site-controlled workloads.
• Community cloud fits governed collaboration among related organizations.
• Hybrid cloud fits systems that need more than one boundary.
• Edge placement protects time-critical control, local continuity, and data minimization.

The strongest design is not the one with the most cloud services. It is the one that can explain why each workload crosses or does not cross a boundary, and can prove the decision with validation records.

5.16 Key Takeaway

Deployment-model choice should follow data sensitivity, latency, connectivity, regulatory, resilience, and operations requirements across public, private, hybrid, and edge patterns.

5.17 What’s Next?

Now that you can place IoT workloads across deployment models, continue with:

• Cloud Security for IoT: identity, encryption, segmentation, and monitoring controls for cloud-connected IoT.
• Cloud Platforms and Message Queues: ingestion, queues, and platform patterns that implement the placement decisions from this chapter.

5.18 Continue Your Route

This final part closes the route from Scenario: Cold Storage Across Many Sites through What’s Next?. Return to Cloud Deployment Models: Ownership and Risk or continue from the reference-architectures module index.