At renewal a flagship customer asked three things: keep EU data in region, run inference predictably at peak, and pass their vendor audit without a six-month exception plan. Our answer used to be public cloud only. Procurement read this as not under our control. Then we had to split workloads: core in public cloud, regulated analytics in a private tenancy, and an on-prem edge for latency and data gravity. Same product, different deployment environments. Sales cycles shortened because the architecture matched the customer, not our preference.

In this article I will mention "planes". A plane is a separate deployment environment you operate and secure independently, for example a public cloud account, a private single-tenant VPC, or an on-prem or edge site.

Why this matters

Investors want predictable unit economics and the ability to win regulated deals. They ask: where do workloads run and why? Can you prove residency, key custody, and audit posture per plane? What is real TCO including egress, GPUs, support, and people? How do you fail over or rebuild if a region or provider is unavailable?

Investor expectations: Dos and Don'ts

Workload placement and rationale

Do: Keep a workload map showing each service, constraints, placement, SLOs, and owner, plus the reason (latency, sovereignty, predictability, GPU). Don't run public-only or on-prem-only by dogma with no written rationale.

Residency, keys, and audit posture

Do: For each plane show where data and keys live, how keys are pinned in region (BYOK/CMK or HSM/KMS), and the artifacts that back it up (rotation logs, DPAs/SCCs, SOC 2/ISO, shared-responsibility matrix). Prove failover keeps data and keys in jurisdiction. Don't let KMS or observability cross borders during failover or wave at provider badges without mapping them to your controls.

Cost, capacity, and predictability

Do: Maintain a TCO model per plane including egress, storage growth, GPU reservations, support tiers, compliance and staffing; call out workload predictability and show budget, showback, alerts. Don't hide egress behind averages, rely on uncontrolled spot for production, treat list price as forecast, or assume public cloud is always cheaper.

Security and access

Do: Use one identity baseline across planes: SSO, least-privilege roles, short-lived credentials, secrets management, and the same logging and patching. Don't create security snowflakes where private or on-prem is weaker.

Continuity across planes

Do: Time restores in a clean room per plane, rehearse failover where applicable, keep DNS TTL short on failover records, and run drift detection. Don't present multi-cloud slides without drills or discover configuration drift at promotion.

Implementation guide

Start in layers. Seed and early A teams usually need the first 3. Add the rest as you grow and as customers or regulators demand it. Remember: while public cloud or private tenancy costs are based on a price-lists or negotiated deals, calculating on-prem TCO is much more complex. It includes floor space and structural load approvals, power and cooling capacity, fire suppression, physical security and access logs, network redundancy and cross-connects, hardware lifecycle and spares with vendor maintenance SLAs, plus site audits, permits, and insurance.

  1. Write a placement policy: Simple rules, written down. Regulated PII stays in region under your key custody. Workloads that need guaranteed GPU capacity go to a reserved pool. Batch analytics can move to lower-cost infrastructure if SLOs allow.
  2. Model workload predictability: Keep base load on predictable capacity, burst to public cloud for spikes. If a 3 to 5 year TCO shows steady, high-utilization jobs are cheaper on private tenancy or on-prem and you can operate it, place them there.
  3. Watch egress costs like a hawk. Data transfer often dominates TCO. Minimize cross-region and cross-provider traffic, keep analytics close to data, use peering or private links for chatty paths, and make egress a standing line in every cost review.
  4. Data and keys plan with audit pack: Classify datasets and their placement. Define encryption and custody with region-pinned KMS or HSM and BYOK/CMK where required. Set rotation policy and keep evidence. Maintain a one-pager per environment with datasets, custody, access roles, rotation cadence and last rotation, and the audit artifacts that apply. Include a short log or screenshot showing region pinning and how failover keeps data and keys in jurisdiction.
  5. Connectivity by design: Use private links or peering for noisy paths, zero-trust access for staff, clear egress boundaries, and a single service catalog so teams do not invent ad hoc tunnels.
  6. Unify observability and FinOps: Put operations and cost in one place. Use a single dashboard that shows health and spend side by side. Tag every metric, log, trace, and cloud bill with the same tags for service and environment, plus team and region. Give each team a budget, set up cost anomaly alerts, and use reserved or committed capacity when it saves money. Define simple cost units per API call or job so Product can make trade-offs. Review cost and SLOs together each month.
  7. Capacity strategy: Choose reservations, committed use, or on-demand per workload, provide queues and fair-share scheduling to avoid starvation. Keep a fallback SKU and a tested burst plan.

Stage and stake

Seed and early A: Public cloud by default is fine; show a simple placement policy, a basic landing zone, cost guardrails, and a plan for regulated asks.

Series B and growth: Hybrid readiness for enterprise, private tenancy or VPC peering for regulated customers, a real GPU plan if relevant, a data and key custody note, and continuity tests in the secondary plane.

Control buyouts: Buyers sample the workload map against reality, check residency and key custody artifacts, run a restore test, and review cost predictability under growth, pricing egress exposure and capex or opex to close gaps.

Glossary

  • Plane: a separate deployment environment you operate and secure independently.
  • TCO: total cost of ownership including cloud, licenses, egress, support, and staffing.
  • Data gravity: data size and movement make some placements costly or slow.
  • Edge / On-prem edge: Compute and storage deployed close to where data is produced or used to cut latency, reduce data transfer, meet residency rules, or run during cloud/network outages.
  • Egress: paid data transfer out of a provider or region.
  • BYOK and CMK: customer-controlled keys for encryption at rest.
  • Private tenancy: isolated resources for a single customer inside a provider.
  • Landing zone: standardized account or project setup with guardrails.

Your turn

Which constraint has driven your placement choices: residency, GPUs, latency, or cost predictability. Share the scar and the fix that worked.

Next in the Playbook

Edition 15 will be published after a short break in the second half of October after my vacation. Will dive into platform architecture assessment.

Originally published on the Tech Due Diligence Playbook newsletter on LinkedIn.