OpenStack è stato creato da zero per scalare a migliaia di nodi e svilupparsi su diversi datacenter e zone geografiche. Per questo motivo OpenStack può venir suddiviso in 3 zone gerarchiche: Regioni, Zone di Disponibilità e Host Aggregati.

Regioni
Ogni regione ha il suo deployment di OpenStack, endpoint API, network e risorse computazionali incluse. Regioni diverse condividono un set di servizi Keystone e Horizon per garantire un'interfaccia Web e il controllo dell'accesso.

Availability Zone
All'interno di una Regione, i nodi possono venir raggruppati logicamente in Availability Zones (AZ): quando una VM viene lanciata, si può specificare in quale AZ vogliamo venga lanciata l'istanza, o anche su quale nodo specifico all'interno di una AZ.

Host Aggregates
Oltre alle AZ, i nodi possono venir raggruppati logicamente in Host Aggregate.
Gli Host Aggregate sfruttano i metadati per taggare gruppi di nodi, ad esempio tutti i nodi con dishi SSD possono appartenere ad un Host Aggregate, mentre un altro può contenere i nodi con NIC da 10Gb.

Un singolo nodo può appartenere sia ad un Host Aggregate che ad una availability zone allo stesso tempo visto che non sono in conflitto. Inoltre, lo stesso nodo può appartenere a più Host Aggregate.
Gli Host Aggregate sono visibili solo dall'admin e possono venir usate per mischiare diversi Hypervisor nella stessa AZ, ad esempio per risparmiare sui costi delle licenze dal momento che alcuni vendor forniscono guest gratuiti per i loro hypervisor.

Celle
Le celle computazionali di OpenStack permettono di usare il Cloud in modo distribuito. Gli host nel Cloud sono divisi in gruppi chiamati Celle. Le Celle hanno una configurazione ad albero: la cella al livello supremo ("cella API") ha un host che gestisce il servizio nova-api ma nessun servizi computazionale.

Questo permette ad un singolo server API di venir usato per accedere a varie installazioni di Cloud; con un secondo livello di pianificazione (selezione di celle), in aggiunta al numero di host per il servizio nova-scheduler, viene concessa una flessibilità maggiore nel controllo su dove far girare le macchine virtuali.

Diversamente da un singolo endpoint API, le Regioni hanno un endpoint saparato per ogni installazione, garantendo una separazione più netta. Gli utenti che vogliono far girare le istanze fra siti diversi devono scegliere esplicitamente una Regione; in ogni caso, non viene aggiunta complessità nella gestione di un nuovo servizio.