Designing Cloud Workload Boundaries and Recovery Around Reconciled Records

What a cloud workload boundary is

A workload boundary marks where one application, data store, network path, or outside provider stops and another begins. An application can fail while its data is intact, a network path can fail while both applications keep running, and an outside provider can fail while everything inside the plant is healthy.

Manufacturing workloads sit at different places on this map. Cloud computing becomes the preferred platform for migrating and modernizing Level 4-5 applications such as Production Planning, ERP, and PLM, according to an AWS whitepaper on manufacturing OT security. The same paper says edge computing extends modernization to MES and SCADA. AWS's description of the Purdue reference model, in turn, places levels 4 and 5 in the IT domain, while the functions at level 3 and below are tied to production operations and control. Shop-floor control sits outside this guide's scope.

Start by listing each system that holds a record of an order, a production result, or a shipment, and note what it depends on: other applications, the network connection, a data store, and any outside provider. That list is the dependency map the rest of the design builds on.

How recovery requirements are expressed

AWS's prescriptive guidance for manufacturing execution systems defines the recovery time objective (RTO) as the acceptable delay between a microservice interruption and its restoration. It defines the recovery point objective (RPO) as the maximum acceptable amount of time since the last data recovery point. In plain terms, RTO is how long the business can be without the function, and RPO is how much recent data it can afford to lose.

The same guidance separates availability from disaster recovery. It describes disaster recovery as focused on discrete copies of the entire microservice or even the whole MES system, whereas availability concerns the components of the microservices. That distinction affects design. Keeping a component running and restoring a whole system after a major failure are different problems with different costs.

An illustrative example: suppose a plant can tolerate no more than a short pause in production reporting but could rebuild a few minutes of order-entry data by hand from customer emails. In that case the two workloads would be given different recovery requirements, even though both run in the same cloud account. The tolerances come from the operation, not from the platform.

Degraded operation and reconciliation

Recovery targets describe restoration. They do not describe what people do while a system is down, or how records are made consistent afterward. A resilience pattern for industrial integration addresses both. Its stated desired outcome is that production data is preserved and synchronized once systems are restored.

The guidance also directs designers to document which operations must continue during cloud connectivity disruptions and to document recovery time objectives and recovery point objectives for different data types. For each workload, the design should therefore answer three questions in advance:

• Which operations continue in a degraded mode, and who may make decisions during it?
• Where are events held while the connection or system is unavailable?
• How are held events and restored records compared and reconciled, and by whom, before anyone relies on them?

Treat reconciliation as a designed step with a named owner, not as cleanup.

Where the patterns fit

The same guidance describes several patterns. Circuit breakers detect failures in downstream dependencies and switch to predefined fallback paths. Failover can use redundant connectivity paths with automated switching. Local storage mechanisms can retain manufacturing data during outages and automatically synchronize when connectivity is restored. Each fits a different boundary: buffering protects data crossing a network or provider boundary, a fallback path protects a dependent function, and redundant connectivity protects the link itself.

Resource planning is a related use of the same map. AWS guidance on aligning resources with production demand tells designers to categorize manufacturing applications as time-critical or non-time-critical, with shop floor control and real-time monitoring in the first group and reporting and data processing in the second. That classification gives a defensible basis for spending more on recovery for the first group than the second.

Limits and tradeoffs

The sources describe patterns and objectives, not guaranteed outcomes. Several limits apply.

First, redundancy and recovery are not interchangeable with each other or with being tested. A recovery objective is a requirement, not evidence that the environment can meet it. Evidence comes from exercises. AWS describes a program of load testing and chaos engineering validating architecture under stress and Game Day exercises that prepare a team for incident scenarios. That description comes from a vendor support offering, so read it as one provider's account of a practice, not proof that any particular result follows. Whatever the approach, ask for restore evidence from your own workloads, not only the existence of a backup.

Second, whether any specific combination of patterns is worth its cost depends on your records and commitments, which these sources do not quantify.

Third, ownership is a decision, not a feature of the platform. AWS's support description relies on named domain specialists who maintain familiarity with the workload architecture, which illustrates the principle that someone specific should understand each workload. Inside a manufacturer, the same question applies to who owns each record, each recovery step, and each reconciliation.

Finally, the retained material here covers manufacturing integration and recovery on one cloud provider's terms. It does not establish how any specific ERP, MES, or WMS product behaves, and these sources do not address the cloud-hosted AI question directly. That part of the design is covered below as a set of questions to answer.

Applying this to your operation

Use the following sequence to turn the explanation into a decision.

1. Map dependencies for each record-bearing system. For ERP, MES, WMS, and any connecting layer, note the application, the data store, the network path, and any outside provider it relies on. Mark which failure would stop each system.
2. Set tolerances with the people who run the work. Ask operations and customer-facing leaders how long each function can be unavailable and how much recent data they could recreate. Record these as RTO and RPO per workload and per data type, as the guidance on resilient integration suggests.
3. Define degraded operation. For each function, state what continues, what pauses, who decides, and where events are held.
4. Define reconciliation. Name the owner, the records compared, the rule for resolving disagreement, and the point at which restored data may be used for orders, production, or shipping commitments.
5. Ask for restore evidence. For each recovery pattern under consideration, request results from a test restore against your own data, and note who ran it and who owns the outcome.
6. Check the records before adding cloud-hosted AI. Before relying on AI that reads operating records, ask whether those records have named owners, whether definitions are consistent across systems, and whether the reconciliation step above makes them dependable after an outage. If not, resolve that first.

The sequence above is a framework for that conversation, and your actual environment determines the answers.

For related background, see our guides on how to change ERP and cloud systems without disrupting customer commitments and on governing cloud cost, recovery, security, and ownership.