What is workload placement, and how do you choose where apps run?

A workload placement strategy is a written set of rules that decides which environment each application runs in: which public cloud, which region, which on-premises data center or which edge site. It assesses every workload against criteria such as data residency, latency, data gravity, unit cost and hardware availability, and the decision is then enforced at deploy time through scheduling constraints. In a hybrid or multi-cloud setup, placement is where compliance and cost decisions turn into infrastructure.

Placement criteria

Criteria fall into two groups. Hard constraints remove options entirely. Soft criteria rank the options that remain.

Criterion	Question to answer	Type
Data residency and jurisdiction	Where may this data be stored and processed, and under which law?	Usually hard
Latency	How close must the workload be to its users, devices or other systems?	Hard for real-time systems, soft otherwise
Data gravity and egress	Where does the data the workload reads live, and how much of it moves?	Soft, often decisive
Unit cost	What does a vCPU-hour, GB of memory, GB of storage or GPU-hour cost in each option?	Soft
Accelerator availability	Which GPU types can you actually get, in what quantity?	Hard when a specific GPU is required
Reliability	What SLA, number of zones and failure isolation does the option offer?	Hard minimum, soft above it
Managed service dependencies	Does the workload rely on a service only one provider offers?	Hard until the dependency is removed
Existing commitments	Is there owned hardware or reserved capacity that is already paid for?	Soft

Residency is the criterion with legal weight. Under GDPR, transfers of personal data outside the EU are restricted by Chapter V (Articles 44 to 50), so many EU workloads have a hard constraint to EU regions. How to keep cloud and Kubernetes data inside the EU covers how to enforce it. GPU availability is the other common hard constraint, explained in why it is hard to get cloud GPUs.

A worked example

Take three workloads and three possible targets: an owned data center in Frankfurt, an EU region of a large cloud provider, and an EU region of a lower-cost infrastructure provider.

Workload	Hard constraints	Deciding soft criteria	Placement
Customer database with personal data, steady load	EU only	Owned hardware is already paid for, load is constant	Owned data center, with backups in a cloud region
Model training, needs 8 GPUs for a few days each month	Specific GPU type	Pay only while running, data volume is moderate	Whichever EU cloud region has the GPUs available, with the dataset copied there
Public web frontend, traffic spikes during campaigns	EU only, low latency to EU users	Elastic capacity, low price per vCPU	Lower-cost provider, autoscaled, close to the database to limit cross-site traffic

The decisions differ because the deciding criterion differs, not because one target is better overall. Re-run the assessment when prices, regions or regulations change.

Strategy level and scheduling level

Placement happens at two levels. The strategy level picks the provider, region or site for each workload, as in the table above. The scheduling level makes Kubernetes enforce that choice for every Pod. Kubernetes offers several tools for it (Assigning Pods to Nodes):

nodeSelector and node affinity require or prefer nodes with labels such as topology.kubernetes.io/region.
Taints and tolerations keep workloads off nodes unless they explicitly tolerate them, for example keeping general workloads off GPU nodes.
Topology spread constraints spread replicas across zones, regions or providers.

A Pod that must stay in an EU region could carry this rule:

yaml

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/region
              operator: In
              values: ["eu-central-1", "eu-west-1"]

When separate clusters exist per environment, the strategy level also decides which cluster receives each workload. When one cluster spans several clouds, the scheduler applies both levels in one place.

Criteria for evaluating platforms

When you compare platforms or providers for a placement strategy, ask whether they can:

express placement rules per workload and enforce them, not only document them
report where every workload runs at any time, for audits
move a workload between environments without rewriting it
show cost per workload in every environment in the same format

Useful indicators to track over time include the share of workloads with a defined placement rule, cost per unit of compute in each environment, the share of spend that goes to data transfer, and how long it takes to move a workload from one environment to another. The cost side is covered in how to optimize Kubernetes costs across clouds.

Workload placement with Cloudfleet

In Cloudfleet, Fleet constraints limit a Fleet to specific regions, instance families, CPU architectures or purchase types, so every workload on that Fleet inherits the placement rule. Pods can narrow it further with standard labels such as topology.kubernetes.io/region and cfke.io/provider.

Previous
← How do you avoid cloud vendor lock-in?

Next
How do you make Kubernetes highly available across clusters? →