Summary

  • AFRINIC's 2025 Annual Report says it began reducing its physical data-centre footprint while increasing cloud and hybrid use; it also records modern Bacula, AWS S3 off-site backups, full critical-service coverage, quarterly restoration testing and Ansible automation.
  • These are credible improvements, not evidence of a failure. But a completed backup, a restored snapshot, a running application and a member's successful service action are different states and should not be reported as one undifferentiated recovery result.
  • A compact public service-to-recovery control map could show targets, test scenarios, integrity and acceptance checks, supplier-controlled stages, exceptions and the latest independent-environment exercise without exposing credentials, bucket names, keys or emergency procedures.

A smaller room creates a longer proof

The most revealing line in an infrastructure report is sometimes the one that sounds least dramatic. AFRINIC says it initiated a strategic shift towards a smaller physical data-centre footprint and greater use of cloud and hybrid models. The intended benefits are resilience, disaster recovery and more predictable costs. Around that decision sits a practical year of work: obsolete and end-of-life equipment was decommissioned, faulty network and storage components were replaced, backup capacity expanded, and redundant routing and uplink designs prepared across locations including Mauritius, Johannesburg, Parklands, Mombasa and Isando.

This is the strongest case for the strategy. Old hardware is not sovereignty. It is often just an ageing failure mode with a maintenance contract attached. Retiring it can reduce operational friction. An off-site copy can survive a local physical incident. Cloud capacity can make recovery resources available without waiting for another owned room to be fitted out. Modern Bacula and Ansible can make a procedure repeatable rather than heroic. Quarterly restoration testing is substantially more informative than a dashboard that merely says yesterday's backup job finished.

None of those gains should be discounted to make a governance point. The point is that the evidence required for recovery changes when the estate changes. With a larger owned footprint, the institution may control more of the physical chain while carrying more hardware risk. In a cloud or hybrid design, some physical burdens recede, but the proof must cross accounts, permissions, contracts, regions, encryption arrangements, restoration semantics and supplier action. The building becomes smaller. The control surface does not necessarily do so.

AFRINIC's report gives enough information to see the direction but not enough to reconstruct the recovery path. It says critical services have full backup coverage and that AWS S3 is used for off-site backups. It does not say which authoritative data classes are in those copies, whether every service follows the same path, which storage region is used, who controls the relevant account and keys, what was restored in each quarterly exercise, where the restored service ran, which checks passed, or whether a test ever crossed into an independently controlled environment. Those are deliberately absent facts, not implied defects.

Nine states that should not collapse into one

“Restore tested” can describe several materially different achievements. A backup job may complete. A stored object may be readable. A selected snapshot may restore into a destination. Schema, signatures and referential integrity may then pass. An application may start. An endpoint may respond. A member or relying party may complete the transaction that matters. The result may meet the declared recovery-point and recovery-time objectives. Finally, the authoritative state may prove recoverable in an environment not controlled by the normal supplier path.

Each step is useful. None automatically establishes the next.

The distinction is especially important for a regional Internet registry. A web home page responding is not the same as a member completing an authenticated registry action. A database process starting is not the same as the restored data preserving the relationships, signatures and timing needed by downstream systems. A bucket containing objects is not the same as an application accepting them. A service recovered inside the same identity, key and regional arrangement is not proof that it can be recovered after that arrangement becomes unavailable.

This does not require public disclosure of an attacker's map. AFRINIC need not name accounts, buckets, credentials, facility rooms, network diagrams or emergency commands. It can publish control outcomes. The difference resembles a financial audit: the public does not need the safe combination to know whether the cash was reconciled.

The supplier boundary is already in the public contract

AFRINIC's Service Level Commitment is marked Version 1, November 2015. It covers registration and customer services, database and public online services, reverse DNS, billing and service infrastructure. It names WHOIS, MyAFRINIC, the service websites, IRR, DNS, DNSSEC, mail and RPKI among maintained services. It commits to 99.8 per cent uptime per service and for the network, while excluding third-party unavailability from the calculation.

The same document says AFRINIC cannot provide service-level commitments for third-party suppliers, though it will strive to reflect its own commitments in relationships with suppliers affecting core services. That is not evidence that a supplier has failed or breached a contract. It is an explicit allocation of measurement risk. When a strategy increases cloud and hybrid use, the border between AFRINIC's public obligation and a supplier's performance becomes more operationally important, even if the service improves.

The 2025 report says some initiatives remained dependent on supplier timelines and approvals. Again, dependency is not failure. It does, however, raise a concrete question: when the registry reports that a recovery objective was met, which elapsed time is inside the target and which delay can be classified as external? A recovery clock that stops at the supplier boundary may be contractually tidy while giving members an incomplete account of how long their service was unavailable.

Availability creates a similar temptation. AFRINIC reports that critical services were typically above 99.7 per cent through 2025. Its current public status page showed WHOIS Database, MyAFRINIC Portal, AFRINIC Web Sites, Mailing Lists, New Member Registration Portal, DNS Services, RPKI Systems and Other Systems as Operational at the evidence cutoff. The root components carried no metrics summary in the captured page. These observations can coexist. Neither proves recovery readiness.

An annual availability percentage describes an outcome over an interval; a green present-tense label describes now; a restoration exercise tests a path from failure to usable service.

S3 changes what a restore can mean

AWS documentation helps explain the control boundary without telling us anything unreported about AFRINIC's configuration. Under AWS's shared-responsibility account, AWS operates the infrastructure layer for managed services such as S3, while the customer remains responsible for the resilience of its data, including its choices about backup, versioning and replication.

The product can support continuous or periodic backup, point-in-time recovery and direct access to backup data. The AWS Backup route for S3 requires S3 Versioning. Restore outcomes can also depend on permissions, access-control-list behaviour, the destination's versioning state, region, encryption-key availability and whether objects with the same name or version already exist. A restore to the original bucket is non-destructive; it does not simply overwrite every object. Some objects can be skipped. A cross-region copy can be restored only in the region containing the source or copy.

These are product conditions, not claims about AFRINIC. The public evidence does not establish that AFRINIC uses AWS Backup, Versioning, Replication, cross-region copies, a particular IAM design or any named encryption arrangement. The lesson is narrower and more useful: “the S3 backup restored” is incomplete as a public control statement unless the scenario and acceptance checks are defined. Two technically successful restores can leave different authoritative states.

For example, an object-level test can show that retained bytes were retrievable. An application-level test can show that a selected service consumed the data. A functional test can show that a member completed the protected action. An exit test can show that recovery did not depend on the ordinary account, region, identity plane or provider. The tests answer different questions. Reporting their type is more valuable than publishing a larger number without a type.

A public map without a public blueprint

AFRINIC could turn its existing work into a small, security-safe service-to-recovery control map. Each row would name a public service component and the authoritative data class at a useful level of abstraction. It would state the recovery-point and recovery-time targets, a non-sensitive snapshot or exercise identifier, its as-of time, an integrity hash and the retention class.

The row would then separate AFRINIC-controlled stages from supplier-controlled ones. It would identify the restoration scenario and destination class, and say whether the exercise crossed an account, region or provider boundary. Permission and key custody could be expressed as control classes rather than secrets. Results would distinguish completeness, schema, signature, referential-integrity, application-start, endpoint and user-acceptance checks. Start time, usable-service time and accepted-restoration time would make the clock legible.

Exceptions matter as much as passes. The map should record skipped objects, unresolved supplier approvals, the remediation owner and due date, and the rollback or correction path. A failed check need not become a scandal; an unexplained disappearance of the check is worse. A history of tests would allow members to see whether recovery is getting faster and whether the same exception recurs.

The final column should record the latest independent-environment exercise. “Independent” need not mean a permanent duplicate platform. It can mean that AFRINIC has proved, at an appropriate interval, that an authoritative state and its minimum service can be reconstructed beyond the ordinary supplier control plane. The exact architecture can remain confidential. The governance fact is whether an exit path has been exercised rather than merely contemplated.

What the evidence does not show

Nothing in the checked material establishes an AFRINIC outage, failed restore, missing backup, breach or data loss. It does not show that every critical service or every authoritative registry record is stored in S3. It does not show supplier default, present lock-in, an inability to leave AWS, or a defect in the reported 99.7 per cent availability. The public status page is not a historical availability ledger, but that does not make its operational labels false.

Nor would a public control map guarantee recovery. A report can be stale or selective. Independent assurance and sampled evidence may still be needed. The map's value is more modest: it gives members a stable grammar for asking what was actually tested and which boundary the test crossed.

AFRINIC's modernisation is therefore not a story about whether cloud is good or bad. The infrastructure report has already made the practical case for retiring obsolete equipment, expanding off-site backup and automating exercises. The governance question is whether the proof travels with the service as responsibility becomes distributed. A smaller physical footprint can be an improvement. It should also produce a more precise recovery record.

Sources