---
title: "The 5 Layers Every Cloud Commitment Depends On"
description: "Long-term hyperscale cloud commitments are presented as distributed-systems problems with expensive consequences when physical assumptions are wrong. The post proposes a dependency sequence across regional and availability-zone topology, power architecture, fit-for-purpose compute, SKU qualification, and network design. It compares application-observable latency with bare-metal RTT, uses power consumption as a migration check, and argues that workload characteristics should drive memory-to-core ratios, silicon generations, instance families, and routing choices rather than provider defaults. It also explains why zone placement, inter-zone and inter-region transfer, and egress pricing affect quorum latency, reliability, and economics, while noting that cross-region traffic may require explicit justification. The conclusion is that these constraints compound over the commitment unless teams manage architectural drift, with software and contracting layers addressed separately."
---

# The 5 Layers Every Cloud Commitment Depends On

[Uber](https://yomu.fyi/company/uber) · May 4, 2026

**Type:** Explainer

## Summary

Long-term hyperscale cloud commitments are presented as distributed-systems problems with expensive consequences when physical assumptions are wrong. The post proposes a dependency sequence across regional and availability-zone topology, power architecture, fit-for-purpose compute, SKU qualification, and network design. It compares application-observable latency with bare-metal RTT, uses power consumption as a migration check, and argues that workload characteristics should drive memory-to-core ratios, silicon generations, instance families, and routing choices rather than provider defaults. It also explains why zone placement, inter-zone and inter-region transfer, and egress pricing affect quorum latency, reliability, and economics, while noting that cross-region traffic may require explicit justification. The conclusion is that these constraints compound over the commitment unless teams manage architectural drift, with software and contracting layers addressed separately.

## Context

The post frames a large cloud commitment as a construction-like engineering sequence: regional and zonal topology constrains power decisions, which constrain compute and hardware choices, which in turn shape network design and economics. It focuses on physical infrastructure and identifies software and contracting as additional layers to address separately.

## Approach / What changed

The proposed approach is to study the deployment in sequence: select regions and zones using fault boundaries, latency, service availability, capacity, and compliance; audit power feeds, redundancy, cooling, and generation; derive hardware requirements from workload characteristics; qualify suitable instance families and silicon; and design traffic placement and routing around latency, reliability, and transfer costs. Power consumption is also used to validate migration sizing.

## Takeaways

- Region and zone selection affects fault isolation, write-path latency, managed-service availability, SKU depth, compliance options, and quorum design. Published RTT figures may understate application-observable tail latency because they omit virtualization and contention effects.
- A migration from a 5 MW on-premises footprint is expected to use approximately 4.25 MW in a hyperscale environment if the stated PUE assumptions hold. A higher result can signal incorrect sizing, misconfiguration, over-provisioning, or stranded resources.
- Frequent communication should be considered for same-zone placement because intra-zone transfer is generally uncharged, while inter-zone and inter-region traffic usually incurs charges. High-volume synchronous cross-region traffic therefore needs explicit justification.

## FAQ

### Why can published cloud latency figures understate application-observable latency?

Published RTT measurements often use NIC-to-NIC physical-layer measurements. VM-to-VM latency also includes hypervisor jitter, noisy-neighbor effects, and switch and SmartNIC driver processing, which can add several hundred microseconds to long-tail latency under contention.

### How can power consumption validate a cloud migration?

The post compares equivalent workload power before and after migration. It says a typical 5 MW on-premises workload should land at approximately 4.25 MW in the cloud under the stated PUE assumptions; a larger figure may expose sizing errors, misconfiguration, over-provisioning, or stranded capacity.

### Why does zone placement affect both cost and reliability?

Intra-zone traffic is generally not charged, while inter-zone traffic within a region usually carries a per-GB fee and inter-region traffic costs more. Zonal isolation also helps separate fault domains, so co-locating frequently communicating services can affect both economics and reliability.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Cloud](https://yomu.fyi/topic/cloud), [Cost Optimization](https://yomu.fyi/topic/cost-optimization), [Distributed Systems](https://yomu.fyi/topic/distributed-systems)

- Source: [Uber](https://www.uber.com/us/en/blog/five-layers-cloud)
- Source URL: https://www.uber.com/us/en/blog/five-layers-cloud
- Ingested by Yomu: 2026-09-17T04:00:54.412Z

[Read original post](https://www.uber.com/us/en/blog/five-layers-cloud)