"Where is our data, physically?" is one of the most common questions a board asks after a cloud decision, and one of the least well answered. The usual reply names a provider and a city. That is accurate and nearly useless, because it says nothing about who controls the building, who keeps the power on during a grid failure, who can reach the equipment, or what happens if the site is lost.
Data centres are not one kind of thing. A hyperscale cloud region, a colocation campus, a server room in a head office, a cabinet at a factory, a telecoms exchange and a GPU hall built for AI training are designed for different purposes. They divide responsibility differently. Mixing them up leads to the wrong questions in risk reviews and the wrong assumptions in disaster recovery plans.
CloudNala's view is that executives do not need to know how a data centre is engineered, but they do need to know which kind they depend on, who runs each layer of it, and what that means for power, connectivity and recovery. Those three questions carry particular weight in South Africa.
The running example
Nyala Media is fictional, and its systems and figures are illustrative. In Part 1, Nyala, a Johannesburg digital publisher, worked out how its AWS and Azure estates related. Its board then asked for a one-page view of every facility Nyala's services depended on. The answer turned out to touch all six kinds below, four of them directly.
The six kinds
Hyperscale. The large facilities that make up a public cloud region, owned or leased and fully operated by the cloud provider. You never see the inside and never rent space. You rent services that run there. Nyala's news site runs in one of these.
Colocation. A building operated by a specialist company that rents space, power, cooling and physical security to many customers. Each customer installs and runs its own equipment. Large colocation campuses also contain "meet-me" rooms where telecoms carriers, internet exchanges and cloud providers' private connection services interconnect, which is why many organisations place their network equipment there even after moving workloads to the cloud. Nyala keeps two racks in a Johannesburg colocation facility for its video transcoding servers and its private link to the cloud.
Enterprise. A server room or data centre owned and run by the organisation itself, in its own building. Many South African organisations still have one, often smaller and older than anyone would design today. Nyala's head office has a small server room holding a legacy editorial archive.
Edge. Small facilities, sometimes a single cabinet, placed close to users or machines where low delay or local operation matters: a factory floor, a mine, a retail store, a broadcast studio. Nyala's studio has an edge cabinet that records and encodes live video before it goes to the cloud.
Telecom. Exchanges and network facilities operated by telecoms companies, mainly to run their own networks, sometimes with space offered to customers. Nyala does not use one directly, but its connectivity runs through several.
AI and high-performance computing. Facilities, or halls inside larger facilities, built for dense racks of GPUs. They are distinguished less by their purpose than by their physics: far more power per rack than ordinary IT, and cooling designs, often liquid-based, to match. Training large models happens in these; Nyala uses them only indirectly, through AI services hosted by cloud providers.
In practice the categories overlap. A colocation campus may host part of a hyperscaler's region. An edge site may sit inside a telecom facility. The labels are useful for one reason: they tell you who runs what.
Who runs which layer
The table shows the most important point for risk conversations. In every model, your workloads and data remain your responsibility. What changes is how much of the stack beneath them you also carry.
In your own enterprise data centre you carry all of it, including the building, generators and cooling. In colocation the provider runs the building, power and cooling, and you run your equipment. In a hyperscale cloud the provider runs almost everything underneath your workload, and the network and platform layer is shared: the provider runs the physical network and platform services, and you configure your virtual networks, access rules and services correctly.
Shared responsibility is where audit findings concentrate. "The cloud provider is certified" is true and does not mean your configuration is secure.
The South African questions
Three questions change the answer locally more than anywhere else.
Power. South Africa's years of rotational load-shedding taught organisations that a facility's power design is not an engineering detail. Large colocation and hyperscale facilities are built to run on generators for extended periods and hold fuel and supply contracts for that purpose. Enterprise server rooms often are not: a UPS that lasts thirty minutes and a generator that has not been load-tested in a year is a common finding. Ask how long each facility you depend on can run without the grid, how that has been tested, and what the fuel arrangements are.
Connectivity. A well-powered facility is useless if its connections fail. Ask how many independent fibre routes reach the building, which carriers are present, and whether your own connections use diverse paths or share a trench. Our Cloud Networking 101 series covers how offices, data centres and clouds are connected.
Recovery geography. South Africa's cloud regions and largest colocation campuses are concentrated in Johannesburg and Cape Town. A recovery plan that puts production and backup in the same metro, or depends on one carrier between two cities, may fail the scenario it was written for. Ask where the second copy lives and whether the path to it is independent.
Five questions for any facility you depend on
Whatever the kind of facility, the same short list turns a provider name into a risk view:
- Who runs each layer? Building, power and cooling; hardware; network and platform; your workload.
- How long can it run without the grid, and when was that last tested under load?
- How many independent connectivity paths reach it, and do yours actually use more than one?
- Where is the second copy of what runs there, and is the route to it independent of the first?
- What evidence do you hold? Certifications and audit reports cover the provider's layers, not your configuration.
These questions apply equally to a hyperscale region and a server room down the passage. The answers simply come from different people.
What Nyala's board received
The final page listed each dependency in a simple table: facility kind, location, who runs each layer, power resilience, connectivity, and recovery arrangement. Two findings came out of it. The head-office server room holding the editorial archive had no tested generator and no off-site copy newer than three months. And both Nyala's colocation racks and its private cloud link depended on one carrier.
Neither required new technology. The archive was copied to cloud object storage with a defined retention period, and a second carrier was contracted for the colocation site. The board's question, "where is our data?", had become a better one: "what happens when each of these places has a bad day?"
For when an on-premises or private option remains the right answer, see When on-premises and private cloud remain the right answer.
Next: Part 3, A zero-rand AI architecture is for learning, not a production promise. All parts are on the series page.
How CloudNala can help
We help organisations map the facilities their services actually depend on, clarify who runs each layer, and test power, connectivity and recovery assumptions against South African conditions. The result is a dependency view a board can understand and a short list of gaps worth fixing.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za