Cloud workload placement: follow the dependency before the discount

A warehouse application can look like an easy cloud move until someone follows a single transaction. The screen runs on one server, stock availability comes from another system and the label printer sits beside the packing line. Move the screen’s application tier and the transaction still has to make that journey.

For an infrastructure director, workload placement is a decision about the complete service path. The location with the lowest compute quote may demand the most application redesign. A location close to the data may simplify response times but leave a small team responsible for equipment and recovery. The useful comparison starts with those consequences.

A response-time requirement changes the shortlist

Consider a hypothetical order-confirmation service with a 200-millisecond response-time target. Its current design makes six sequential calls to a database that will remain in the existing facility. If the proposed network path adds 25 milliseconds of round-trip time to each call, those calls add 150 milliseconds before database processing and other application work.

That leaves 50 milliseconds for everything else. It does not prove the move will fail, but it identifies the experiment that matters. Adding bandwidth alone would not remove those sequential round trips. The team might need to reduce the number of calls, move a tightly coupled component or change how the application uses data.

A useful test therefore follows the transaction under representative load, including busy periods. Measure the slow end of the experience as well as the average. If a screen is fast most of the time but stalls when a shift begins, the average tells the infrastructure director too little about the effect on operations.

Each proposed location should also be specific. “Public cloud” is not a deployable design. A region, services, network route, recovery arrangement and support model are. “Keep it on premises” also needs a design: remaining hardware life, capacity, power, support and a recovery location cannot be left outside the comparison.

Local execution does not guarantee independence

AWS Outposts offers a concrete example of why physical location and operating dependency need separate treatment. AWS documents a service link between Outposts and its AWS Region, carrying management traffic and traffic between the Outpost and associated regional VPCs. The documentation calls for redundant connectivity and specifies bandwidth and latency requirements for the link.

For a buyer considering cloud-managed infrastructure at a local site, that connection belongs in the placement decision. Keeping an application near its data does not answer which management activities depend on a remote service. The consequences of losing the link must be established for the proposed configuration; they should not be inferred from the equipment being inside the building.

Apply the same reasoning to identity, name resolution, licence checks and monitoring. A locally hosted application may still rely on a remote identity provider for new logins. A cloud service may rely on a connection back to an internal directory. Draw the boundary around what the business needs to keep doing during a failure, rather than around the servers alone.

Three feasible options may involve three different business cases

For the warehouse example, three broad approaches might remain after the latency test. Keeping the application and database together avoids splitting their existing interaction. Moving both removes that particular split but enlarges the migration. Changing the application to reduce remote calls preserves some local dependencies while adding engineering work.

The trade-offs are easier to inspect together:

Option	What the director needs to establish	Cost that can be missed
Keep the coupled components local	Capacity, support life and recovery can sustain the service	Refresh, facilities and specialist cover
Move application and data together	Connected systems and users can tolerate the new path	Migration, reconciliation and parallel running
Redesign the interaction	Fewer calls or replicated data preserve required behaviour	Development, consistency handling and continued maintenance

A hard requirement should eliminate an unsuitable option before preference scoring begins. If the business cannot tolerate stale stock information for a particular transaction, an asynchronous copy needs an explicit treatment of that constraint. A favourable cost score cannot make the requirement disappear.

At the same time, challenge whether a supposed constraint is real. “It must stay in this building” may be a documented operational need, a contractual condition or simply the current design. Those lead to different decisions. The infrastructure team needs the reason, not just the inherited rule.

Choose the work your team can sustain

The provider’s service boundary changes the skills and cover you need. In its shared responsibility model, AWS distinguishes infrastructure services such as Amazon EC2, where customers manage the guest operating system and applications, from abstracted services such as Amazon S3, where AWS operates more of the underlying stack. Data management and permissions remain customer responsibilities.

The implication is not that one category is always preferable. It is that two designs with similar infrastructure costs can leave materially different jobs with your team. Include patching, changes, incident diagnosis and recovery in the staffing discussion. A managed component may remove one maintenance task while creating a new integration or configuration dependency.

Ask the people who would support the chosen design to explain an ordinary failure. For application hosting, compare the operating responsibilities of Kubernetes and managed application services before treating their compute prices as equivalent. How would they distinguish an application fault from a connectivity problem? Who can make the necessary change overnight? An option that depends on skills you intend to recruit has a delivery dependency as well as a salary cost.

Compare economics after the service boundary is clear

Use a common period and a common level of demand. Include connectivity, data movement, backup, support, migration and any parallel running that applies. Keep one-off transition spending separate from recurring costs so a temporary migration expense is not mistaken for a permanent operating disadvantage.

Also distinguish a cost allocation from cash that will actually disappear. Moving one workload may release capacity without allowing a data-centre contract to end. That capacity can have value, but it is not the same thing as a saving available to fund the migration.

The FinOps Foundation’s unit-economics guidance distinguishes resource measures from business measures such as cost per transaction or case resolved. For this decision, a stable cost per completed warehouse transaction would be more informative than comparing unlike virtual machines. The denominator must mean the same thing across the candidates.

The next step is a like-for-like cost comparison of the designs that survived the requirements tests. At that point the infrastructure director is choosing among workable services, with a clear view of what each asks the organisation to build, fund and operate.