RED CLOUD INFORMATION TECHNOLOGY SERVICES COMPANY sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Red Cloud has a real, currently visible network identity. APNIC registered AS153394 in November 2024, and RIPEstat observed its sole announced prefix, 160.191.191.0/24, from November 2024 through the current measurement window. The route was visible to all 325 IPv4 RIS peers counted in the 12 July 2026 routing-status snapshot and had a valid route-origin authorization.
• The visible edge is concentrated. Public routing views identify AS55330, Afghan Telecom's Government Communications Network, as the only observed neighbour or upstream. No PeeringDB network entry was returned for AS153394, no IPv6 space was announced, and no public exchange or facility presence was found for Red Cloud.
• Red Cloud's own business-solutions page advertises IaaS, virtual machines, storage and networks, plus multiple availability zones, redundant systems, off-site backup and disaster recovery. It does not name a zone, data centre, facility operator, power design, server estate, storage architecture, service level, recovery objective or tested failover result. Those claims should therefore be treated as offers to verify, not established capacity.
• The company is easier to verify as a Kabul internet-access and network-services provider than as a cloud operator. Its website markets fibre, point-to-point and point-to-multipoint wireless, microwave, WLAN, satellite, leased-line and IP-VPN services. That access estate could support cloud customers, but it also creates physical dependencies on towers, rooftops, line of sight, last-mile fibre, upstream transit, power and field support.
• The public evidence grade is Weak. Red Cloud has stronger operating evidence than a name-only company, but the evidence does not establish where customer data resides, whether two independent production sites exist, how much capacity survives a failure, or how a customer retrieves workloads if service or the commercial relationship ends.

A cloud promise attached to a small, real network

The most important thing about Red Cloud is not that its website uses the language of cloud computing. Many technology consultancies do that. The important thing is that the company also controls a visible internet-routing identity. APNIC's autonomous-system record names RED CLOUD INFORMATION TECHNOLOGY SERVICES COMPANY as the holder of AS153394, gives Afghanistan as the country, marks the resource active and records registration on 5 November 2024. RIPEstat's current overview says the ASN is announced. Those are concrete operating signals.

They are also narrow signals. An autonomous system is a routing boundary, not a cloud region. It can originate customer-access addresses, infrastructure addresses, hosted services, office traffic or some mixture of them. The IPinfo profile classifies the network as an ISP and sees a consumer-like daily activity pattern. It reports one upstream, no downstream networks and no hosted domains in its current scan. That interpretation aligns more naturally with Red Cloud's access-provider pages than with a large public IaaS estate, although a third-party classification cannot reveal every private or provider-addressed workload.

Red Cloud's own site makes both sides of the business visible. The home page promotes internet access across Afghanistan, business connectivity and resilient wireless and fibre networks in Kabul. Its business-solutions page then moves up the stack: connectivity, cloud, on-premises systems and Microsoft services. Under cloud, it advertises virtual machines, storage, networks, backup, disaster recovery, private and hybrid deployments, and migration.

This combination is plausible. A local connectivity provider can add managed servers or resell infrastructure, and an IT contractor can build a cloud service around leased racks or another provider's platform. But the combination also makes ownership boundaries essential. The public pages do not say whether Red Cloud owns servers, rents cabinets, resells another cloud, manages customer-owned equipment, or combines those models. Until that boundary is disclosed, a customer cannot know whether Red Cloud controls the repair or merely opens a ticket with the party that does.

The right starting point is therefore neither trust nor dismissal. It is a split finding: the network edge is observable; the hosted estate is not. AS153394 proves that Red Cloud participates in public routing. It does not prove that the advertised availability zones contain independent compute and storage capacity, or that a workload can survive the loss of one of them.

What the route table can prove

Red Cloud's public address footprint is compact enough to describe precisely. RIPEstat's routing-status view showed one announced IPv4 prefix containing 256 addresses and no announced IPv6 space on 12 July 2026. The prefix is 160.191.191.0/24. APNIC's broader address registration covers 160.191.190.0/23, a 512-address block, while the globally visible route is the more specific upper /24. Public routing data did not show the lower /24 as a separate current announcement.

That distinction matters. Registered space is not the same thing as routed space, and routed space is not the same thing as service capacity. An allocation can sit unused, be reserved for later deployment, be reachable through another arrangement, or be held while only part is originated. Conversely, 256 visible addresses can support many translated access users or many virtual services. Address count alone cannot reveal server count, storage capacity, customer count or revenue.

The route is not merely a registry entry. RIPEstat recorded it as first seen on 13 November 2024 and last seen in the current 12 July 2026 observation. Its routing-history series contains successive announcement intervals from the first observation onward, albeit with changing collector visibility. At the current point, 325 of 325 counted IPv4 RIS peers saw the route. BGP.tools likewise described AS153394 as an active small network with one upstream and one peer, and its prefix page identified Red Cloud as the origin.

The route also has useful origin protection. RIPEstat's validation result marked the AS153394 and 160.191.191.0/24 pair valid. In practical terms, networks performing route-origin validation have cryptographic authorization to accept Red Cloud as the intended origin for this prefix. That lowers one category of accidental or malicious route-origin risk.

It does not guarantee delivery. A valid route can lead to an overloaded link, failed router, powered-down server or unreachable customer radio. Nor does it prove that all customer services use this range. Route-origin authorization answers who may announce an address block. It does not answer where data sits, how traffic reaches the rack, how quickly a disk is replaced or whether a second site can take over.

The positive conclusion is still worth stating clearly: Red Cloud's public network has been visible for roughly twenty months and is not just an unannounced ASN. The negative conclusion is equally important: one routed /24 is a small observation surface, and no public data ties specific cloud products to specific addresses inside it.

One observed neighbour concentrates the external path

The sharpest public resilience signal is the neighbour count. RIPEstat's ASN-neighbours result showed one unique neighbour, AS55330. IPgeolocation's ASN view, IPIP's registry mirror and IPinfo independently identify the same network as Red Cloud's upstream: AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK. No public downstream network was listed.

An observed neighbour is not a complete contract inventory. Red Cloud could have a private backup that route collectors do not see, a satellite path used only during failure, or access bought under provider-addressed space. It could also participate in local exchange arrangements without publishing them under AS153394. Public routing sees active paths, not every signed agreement.

Even with that caveat, the visible topology is concentrated. If AS55330 stops carrying 160.191.191.0/24, the public record shows no second autonomous-system path by which the same Red Cloud route would continue to propagate. A second circuit from the same upstream could protect against one cable or port failure, but it would not remove dependence on the upstream's routing policy, account state, maintenance decisions or core network. A satellite backup could preserve limited operations, but only if it is provisioned, powered, routed and sized before the primary path fails.

The upstream itself is not a trivial network. IPinfo's AS55330 profile lists numerous external peers and downstream networks, while an APNIC account of Afghanistan's national exchange says Afghan Telecom was among the exchange's members. That can give AS55330 multiple ways onward. Yet upstream diversity inside Afghan Telecom is different from supplier diversity for Red Cloud. A customer of Red Cloud still depends on Red Cloud's attachment to AS55330 and on the commercial and operational chain between them.

There is no Red Cloud entry in the PeeringDB network API. This is not proof that Red Cloud lacks peering or a facility presence; PeeringDB is voluntary and self-maintained. It does mean there is no public operator-supplied profile naming exchanges, facilities, interconnection policy, traffic levels or contact roles for AS153394. The Internet Society's May 2026 NIXA view listed 16 member ASNs, and Red Cloud was not among them.

For a buyer, the missing evidence turns a broad promise of redundancy into precise questions. Is there a second default-capable upstream? Does it enter through a separate duct or rooftop path? Is it on another border router and power feed? Can it carry the full critical load? Is failover automatic, and when was it last exercised? If the answer is a satellite circuit, what throughput and latency remain under contention? If the answer is a second Afghan Telecom circuit, which common failures remain?

The company is publicly clearer about access than compute

Red Cloud's access pages describe a recognisable physical business. Its point-to-point wireless page offers site surveys, line-of-sight analysis, design, installation, monitoring and support. It says links may reach 1 Gbps or more and span more than 100 kilometres depending on terrain and line of sight. Its point-to-multipoint page describes a central base station serving multiple endpoints, with claims of up to 500 Mbps per endpoint and a radius of 30 kilometres or more. Its microwave page describes rooftop or tower antennas and links over distances of up to 50 kilometres or more.

Those figures are vendor claims, qualified even on the pages themselves by terrain, line of sight and design. They should not be read as an inventory of installed links. What they do establish is the kind of work Red Cloud offers: surveys, radios, antennas, towers or rooftops, customer endpoints and field maintenance. The home page adds fibre, satellite, WLAN and branches or service claims in Kabul, Samangan, Balkh, Kandahar, Faryab and Jowzjan. It also says resilience applies to the company's wireless and fibre networks in Kabul.

That service mix changes the cloud analysis. A Red Cloud customer may not be buying only a virtual machine. It may buy the access circuit to reach that machine, the managed firewall in front of it, the Microsoft account used by staff, and the support team responsible for all three. Vertical integration can simplify accountability when the same provider genuinely controls the layers. It can also widen the blast radius when the layers share one upstream, office, support roster or billing system.

Wireless access has failure modes that a cloud sales page does not show. A point-to-point link depends on both endpoints, mounting stability, unobstructed line of sight, correct alignment, clean spectrum, weather tolerance, power and a path from the far radio into the wider network. A point-to-multipoint base station concentrates several customers on one site and shared radio capacity. Microwave backhaul can avoid trenching but still depends on tower access and replacement equipment. Fibre avoids radio interference but can be cut, rerouted or disabled by a common aggregation fault.

Satellite can provide geographical independence from terrestrial fibre, but it introduces a different supplier, terminal, power and capacity model. It is not automatically a seamless substitute for a terrestrial business circuit. Red Cloud's business page describes pooled and quota-based VSAT as well as point-to-point satellite service, which makes the capacity question explicit: a backup that is shared or quota-limited may preserve messaging and control traffic while being unable to carry normal customer demand.

The public material is therefore strongest where physical work is visible and weakest where abstract capacity begins. Red Cloud explains what a radio link is and what installation includes. It does not provide the corresponding physical account of its cloud: no site names, rack arrangement, host count, storage replication design, capacity pool or fault-domain map.

"Multiple availability zones" needs a map of independent failure

Red Cloud's business-solutions page says its IaaS platform lets companies deploy virtual machines, storage and networks, and says multiple availability zones and redundant systems provide availability for critical applications. Those are consequential claims. An availability zone is useful only if the customer can understand what can fail independently.

Two rooms in one building may protect against a rack-level event but share utility power, generators, cooling, security access and carrier entrances. Two buildings in Kabul may avoid a local fire but share one upstream, one city fibre corridor or one control system. Two logical clusters in one server room may isolate software maintenance while remaining exposed to the same power and physical-access event. A remote backup held in another provider's region can improve data protection without providing live compute failover.

The public site does not say which interpretation applies. It does not name an Afghanistan National Data Centre presence, another Kabul facility, a provincial site or a foreign cloud region. It does not say whether zones are active-active, active-standby, backup-only or simply options available through a third party. It does not identify the operator of any facility. A search of Red Cloud's public pages and interconnection records found no facility address associated with the advertised cloud beyond the company's Taimani contact addresses.

The contact details themselves vary. APNIC's organisation record gives Taimani Project Street #3, House No. 19 and one telephone number. The website gives 22 Prozhae Taimani 3rd Street A and two different numbers. TechBehemoths lists Taimani Project Street 3, House 19. These may describe the same operating office in different formats, but none is labelled as a data centre. An office address should not be converted into a rack location by assumption.

The evidence needed is straightforward and commercially normal. Red Cloud could identify the country and city of each production and recovery site, distinguish company-owned equipment from leased or resold capacity, state which facility operator controls power and physical access, and explain which dependencies are shared. It could disclose whether customer virtual disks are synchronously replicated, asynchronously copied or protected only by scheduled backup. It could provide the failure that each zone is designed to survive.

Without those facts, "multiple availability zones" remains a statement of product intent. It is not yet evidence that a customer can lose one site and continue operating. The omission is especially significant because the visible public route still has one observed upstream. Separate compute zones that share a single external route may protect against server failure while leaving public reachability concentrated.

Installed capacity is not usable or recoverable capacity

Cloud economics relies on pooling. A provider buys servers, storage, network ports, power and support capacity, then allocates them across customers. Pooling can make local infrastructure cheaper and better managed than a server in each customer's office. It can also make the difference between installed and usable capacity hard to see.

Installed capacity is the equipment and connectivity nominally present. Usable capacity is what customers may consume under ordinary constraints. Surviving capacity is what remains after the largest credible fault. Recoverable capacity is what can be restored within the customer's time and data-loss limits. Those four quantities are rarely equal.

Red Cloud publishes none of the inputs needed to estimate them. There is no host count, processor generation, memory pool, storage medium, storage redundancy level, oversubscription policy, reserved headroom, public bandwidth commit or maximum customer allocation. There is no indication of how many spare servers, power supplies, disks, radios or optical modules are held locally. There is no public maintenance calendar or admission policy for recovery capacity.

The single /24 does not fill that gap. Two hundred and fifty-six IPv4 addresses could front a modest number of directly addressed servers, a much larger translated customer base, network appliances or access subscribers. IPinfo currently reports no hosted domains on the range, but domain scans miss services behind content-delivery networks, private names, VPNs and customer-managed DNS. The observation suggests the prefix is not an obvious mass web-hosting range; it cannot establish what runs behind it.

The company's pricing page is not public in a way that would permit an economic comparison of compute, storage, data transfer or support. Its home page does show a retail connectivity recommendation of 100 Mbps for AFN 1,000 per month, but that interactive recommendation is not a cloud price and should not be treated as a binding service offer. TechBehemoths likewise says project pricing is not disclosed. The economics remain contractual.

A serious capacity discussion should focus on the degraded state. If one host fails, does spare capacity already exist in the other zone, or must equipment be procured? If one storage node is rebuilding, what performance remains? If the primary upstream fails, what bandwidth is available on the alternate path? If a nationwide incident affects many customers at once, how many restores and support calls can the team process concurrently? Average utilisation cannot answer those questions.

This is the practical meaning of the article's title. Hosted capacity depends on racks even when customers never see them. It depends on transit even when the service is presented through a local console. It depends on repair windows because spare parts, site access and skilled labour determine how long installed capacity remains unavailable.

Power and facilities set the first hard boundary

Every virtual machine eventually becomes heat in a physical room. Reliable service needs utility supply, backup generation or batteries, power distribution, cooling, fire protection, access control and monitoring. Red Cloud does not publicly disclose any of those systems for its cloud offer.

That absence should not be converted into a claim that the systems do not exist. Smaller providers often withhold exact site information for security or commercial reasons. A buyer does not need a public floor plan. It does need enough private evidence to understand fault domains and restoration authority.

The first question is who operates the room. If Red Cloud owns the facility, it should control site maintenance, generator fuel, spares and physical access. If it leases colocation, the facility operator controls at least part of the repair sequence. If it resells another cloud, the underlying provider controls the hardware and may also control network, backup and account recovery. Each model can work, but the service commitment must match the authority Red Cloud actually has.

The second question is how power redundancy is tested. Two power supplies in a server are useful only when they connect to independent distribution paths. A UPS protects a limited interval; a generator protects longer only if it starts, carries load and has fuel. A second site protects a facility failure only if it does not share the failed utility, generator, switchgear or operational team. Cooling and fire systems create their own common modes.

The third question is physical reach. Red Cloud's wireless offers imply rooftop, tower and customer-premises equipment across multiple locations. Those sites need power as well. A cloud rack can remain healthy while customer access disappears because a base station, relay, fibre handoff or building power feed fails. A customer buying both access and hosted capacity should ask for separate availability measures: one for the hosted workload, one for the access circuit and one for end-to-end service.

Afghanistan's broader operating environment makes this more than theoretical. Georgia Tech's Internet Outage Detection and Analysis project reported that BGP signals and active probing dropped sharply during a nationwide disruption on 29 September 2025. The Associated Press described a near-total national telecoms disruption amid reported fibre restrictions. Those events do not establish a Red Cloud outage, but they show that recovery planning in Afghanistan must include policy and nationwide transport failure, not only broken hardware.

Routing security is a strength with a narrow scope

Red Cloud deserves credit for a valid route-origin authorization. RPKI deployment is not automatic, and an authorized origin helps networks distinguish the intended route from an invalid one. APNIC's records and RIPEstat agree on the current valid state for the announced /24.

There is a subtlety in the validation data. The result includes a valid authorization for 160.191.191.0/24 with maximum length /24. It also sees a covering authorization for 160.191.190.0/23 whose maximum length is /23, making that covering record alone too short to authorize the more-specific /24. The dedicated /24 authorization is what leaves the observed route valid. This is a positive sign that the active announcement has been considered at the resource-control layer.

Origin validation does not secure the rest of the route. It does not ensure that AS55330 has spare capacity, that filters prevent every route leak, that customer prefixes are protected, or that the router configuration is recoverable after a bad change. It does not authenticate the full AS path. It also cannot keep a route visible when the only observed upstream withdraws it.

The operational question is therefore whether the resource-security practice extends further. Does Red Cloud maintain current IRR route objects and prefix filters? Are route and firewall changes reviewed? Are router configurations backed up outside the devices? Is management access independent of the customer network? Can the company roll back a failed change without relying on the same link that was disrupted?

Public records expose one warning at the contact layer. APNIC's current RDAP output marks the address [email protected] as invalid in the incident-response record. The extra "e" distinguishes it from the working company domain, redcloudict.com, used in the registrant record and on the website. APNIC also shows that the administrative and abuse roles use the misspelled domain, while the registrant organisation uses the correctly spelled address.

That does not prove customers cannot reach support. Red Cloud publishes other phone numbers and a correctly spelled email on its site. It does show why registry hygiene belongs to resilience. During a routing abuse report or urgent coordination event, an invalid incident contact can slow the people outside Red Cloud who are trying to reach the network operator. Correcting it would be a small but measurable improvement.

Support labour is part of the infrastructure

Red Cloud advertises round-the-clock support on its home and service pages. Its wireless pages include monitoring and maintenance; its cloud page says management and monitoring can be ongoing. Those promises are relevant because a compact provider may rely on a small number of people with broad responsibilities.

The public accounts do not settle the staffing question. LinkedIn's company page describes a privately held company founded in 2022, gives a size band of 11 to 50 employees and exposes one employee in the public view. TechBehemoths gives a similar 10-to-49 range, while its profile says the firm undertakes one to five projects a year. These are self-reported or directory figures, not audited headcount, and the LinkedIn page does not identify a network operations or cloud operations roster.

Small teams can provide excellent support when services are well bounded, automation is reliable and escalation rights are clear. They become vulnerable when one engineer holds exclusive knowledge, several incidents arrive together, or repair depends on a third party. The relevant capacity is not total headcount. It is qualified coverage by function and time: who can change BGP, repair a radio, restore storage, enter a facility, approve an emergency purchase and communicate with customers.

Red Cloud's contact surfaces are fragmented enough to merit testing. The APNIC organisation record, APNIC incident role, website, LinkedIn and TechBehemoths profiles publish different telephone or email details. The website's contact page presents a subscription form rather than a visibly detailed incident channel. None of this proves support failure. It means a customer should verify the actual escalation path before relying on a 24-hour claim.

A credible support schedule would name the response channel for urgent incidents, distinguish acknowledgement from restoration, define severity levels and state when telephone escalation is available. It would also explain which supplier is involved for facility, upstream, satellite, fibre and hardware faults. A status page hosted outside the production network would let customers distinguish a company-wide event from a fault in their own service; no public Red Cloud service-status page was found.

The repair clock begins when monitoring detects the fault, not when an engineer reaches the rack. Detection, classification, authority, travel, building access, spare availability and supplier response all consume time. Customers should ask for measured examples from recent incidents or exercises, with sensitive details removed if necessary. A support promise becomes infrastructure evidence only when it can be tied to owners and elapsed time.

Hardware stock determines whether failure becomes an outage

The cloud page promises that customers avoid the cost and complexity of physical hardware. The hardware does not disappear; its inventory risk moves to Red Cloud or to Red Cloud's supplier. This transfer is one of the main economic reasons to buy hosted capacity, and one of the main reasons supplier evidence matters.

A provider needs production equipment and repair stock. Servers require power supplies, fans, memory, disks and sometimes specialised controllers. Storage requires replacement media and enough spare performance to rebuild after failure. Network edges require routers, switches, optics and cables. Wireless services add radios, antennas, mounts, surge protection and customer-premises units. Satellite services add terminals and provider-specific equipment.

Red Cloud publishes no stock policy or hardware standard. It does not say whether failed parts are replaced from Kabul inventory, borrowed from another project, sourced internationally or handled by a facility or equipment vendor. It does not state whether compute hosts are homogeneous enough for workload movement, whether storage can tolerate simultaneous failures, or whether firmware and replacement compatibility are controlled.

This uncertainty affects the recovery promise. A backup copy can be intact while no spare compute exists to run it. A virtual machine can be portable in theory while the destination lacks memory, storage performance or network addresses. A radio link can be well designed while the exact replacement model is unavailable. In each case, the customer's data may survive while the service does not.

Procurement should ask Red Cloud for evidence by service layer rather than a universal uptime number. For cloud: host-failure tolerance, storage-failure tolerance, reserved recovery headroom and replacement time. For access: spare radio and optical inventory, tower or rooftop access arrangements and alternate backhaul. For the edge: spare router capability, configuration restoration and upstream escalation. For managed on-premises systems: whether replacement hardware is customer stock, Red Cloud stock or ordered after failure.

The provider-contract boundary is especially important here. If Red Cloud's "cloud" is built on another public platform, stocking physical parts may be the underlying provider's responsibility. Red Cloud's obligation would then be architecture, support escalation, account continuity and customer communication. A customer should not demand the wrong proof; it should demand an accurate responsibility statement.

Billing and supplier contracts can stop service without broken equipment

Infrastructure failure is not always mechanical. An unpaid upstream invoice, expired domain, suspended reseller account, exhausted quota or disputed support entitlement can make healthy equipment unreachable. Red Cloud's service mix creates several possible commercial chains: customer to Red Cloud, Red Cloud to Afghan Telecom, Red Cloud to a satellite provider, Red Cloud to a facility, Red Cloud to software vendors and possibly Red Cloud to an underlying cloud operator.

The public web footprint illustrates one such separation. The company site resolves to 66.45.255.122 rather than to Red Cloud's own 160.191.191.0/24. ARIN's record for that web address assigns the surrounding block to InterServer in the United States. Verisign's domain record shows the domain was registered in February 2023 and delegates DNS to names under 2N Business Consulting; it is not DNSSEC-signed at the delegation. Outsourcing the public website is normal and may keep communications available when AS153394 has a fault. It also means website continuity depends on suppliers and renewals outside Red Cloud's own network.

The company's cloud offer may have similar external dependencies, but the public page does not name them. If Red Cloud resells virtual infrastructure, customers need to know whether their account can be transferred if Red Cloud ceases trading or loses access. If Red Cloud owns the hardware in leased space, customers need to know what happens if the colocation contract ends. If Microsoft licensing is bundled, customers need to know whether identities and subscriptions can be moved without service interruption.

Contract continuity is not a demand for private prices. It is a demand for operational rights. Can a customer obtain current data while an invoice is disputed? Is there a cure period before suspension? Are backups retained after termination, and for how long? Can domain, address, certificate and administrative credentials be transferred? Does Red Cloud have the right to let a customer retrieve equipment or media from an underlying facility?

The most resilient arrangement avoids a single administrative key. Customers should control or have emergency access to their own domain registration, critical DNS, encryption keys, identity administrators and current backups. They should know which public IP addresses can move and which belong to Red Cloud. A service can survive a server fault yet fail completely because nobody outside one account can make the required change.

Data locality remains unverified

Red Cloud's Afghanistan registration and Kabul address do not establish where hosted data resides. An ASN country identifies the resource holder's economy; it does not locate every server, backup, log or support session. The company's own website being hosted on InterServer space in the United States is a useful demonstration of the distinction. A Kabul company can operate a service on foreign infrastructure without anything improper occurring.

The cloud page creates several possible locations. "Off-site" backup implies that at least one copy is separated from the primary site, but the page does not state whether off-site means another Kabul building, another Afghan province or another country. Private and hybrid cloud services may place some data on customer premises and some elsewhere. Microsoft 365 services introduce Microsoft's own location and account terms. Migration services may temporarily create additional copies.

For customers with sovereignty or confidentiality obligations, the placement unit is broader than the main disk. It includes snapshots, backup copies, object storage, monitoring data, security logs, support tickets, crash dumps, administrator access and any temporary transfer area. It also includes the keys needed to decrypt the data and the identities capable of authorising access.

Red Cloud does not publish a data-location schedule, subprocessors, retention periods or cross-border support model. The site makes a general reference to local data rules and international standards on its on-premises security page, but it does not identify a specific certification or cloud compliance report. Marketing references to ISO or GDPR are not evidence that the company or service is certified or that a particular legal regime applies.

This supports the controlled topic "Data sovereignty and locality" precisely because the answer is unresolved. A buyer should request a location matrix covering primary compute, primary storage, replicas, backups, logs, support records and administrative access. The matrix should name the legal contracting party and any underlying provider. It should also state whether the customer can select a location and how movement is recorded.

Locality has an availability trade-off. Keeping every copy in one city may simplify local control but expose all copies to a city-wide power, fibre or policy event. Keeping a recovery copy abroad may improve disaster tolerance while changing jurisdiction, latency and transfer dependencies. There is no universal right answer. There is only a need to disclose the design so the customer can choose deliberately.

Migration is part of recovery, not an afterthought

Red Cloud advertises cloud migration as an end-to-end service. The inverse operation matters just as much: moving a customer away. A provider's resilience should be judged partly by whether customers can leave without reconstructing their business from screenshots and memory.

Portability starts with formats and ownership. Can a virtual machine be obtained in a standard image format? Can storage be copied without proprietary dependencies? Are network rules, identity settings, certificates, logs and backup histories available? Does the customer receive enough configuration information to rebuild service on another platform? If managed Microsoft or on-premises components are included, who controls the licences and administrative accounts?

It also depends on bandwidth. A large data extraction can take days across a constrained link, and the visible AS153394 edge has only one observed upstream. During an incident, the same path may be degraded or needed for ordinary operations. A provider that can restore locally but cannot deliver a current copy elsewhere has only partial portability.

The customer should therefore measure exit time before an emergency. A small representative workload can be extracted, validated and started on an independent destination. The test should include data integrity, application configuration, DNS change, identity access and the time needed for Red Cloud support. It should identify which steps still depend on the original service being healthy.

Recovery objectives need two numbers: how long service may be unavailable and how much recent data may be lost. Red Cloud's public disaster-recovery text says restoration is quick and downtime is minimised, but it publishes no numerical objectives. Without values, a customer cannot tell whether the offer is suitable for a payroll system, a public website, an archive or a bank branch.

The strongest evidence would be a recent restore or failover result for the purchased service class. It should state what was isolated, where the workload restarted, how long it took, what data interval was lost and what manual actions were required. A contractual remedy after a missed target is useful, but it does not restore operations; tested portability gives the customer another recovery route.

Afghanistan's exchange ecosystem shows an available alternative

Red Cloud's single-neighbour view should be understood in the context of Afghanistan's developing interconnection ecosystem. APNIC wrote in 2022 that the National Internet Exchange of Afghanistan was established in 2018 at the Afghanistan National Data Centre in Kabul and had attracted roughly half of the country's then 64 registered ISPs. The Internet Society's May 2026 view reports 16 listed member ASNs, 13 using the route server and 14 with at least one valid route-origin authorization.

Local exchange participation can reduce the distance, cost and external dependency involved in reaching domestic networks and services. It can also provide additional routing relationships for local traffic. It does not replace international transit, and an exchange attachment can itself have common facility and switch dependencies. Still, the presence of NIXA gives a concrete benchmark against which Red Cloud's undisclosed interconnection can be assessed.

No Red Cloud membership appeared in that current public list. The company may connect indirectly through Afghan Telecom, use a private arrangement not listed under AS153394, or have no direct exchange port. Each possibility has different economics and recovery behaviour. An indirect path may be operationally sensible for a small network, but it places more routing and commercial control with the upstream.

The Ministry of Communications and IT's public ISP list is another imperfect comparison. It lists 58 providers and does not include Red Cloud, while Red Cloud's LinkedIn and TechBehemoths profiles say the company is registered or authorised by communications authorities. The ministry page may be old, incomplete or based on a different licence category, so absence cannot establish that Red Cloud lacks authority. It does mean the authorisation claim is not independently resolved by that public list.

A customer buying internet access should request the current licence name, number, scope and expiry directly. A cloud or IT-services contract may not require the same authority as public internet service, while radio links, spectrum use, satellite service and national ISP operation can involve distinct permissions. The legal entity on the licence should match the entity on the contract and the network-resource records.

These public gaps are not accusations. They are signs that Red Cloud is at a stage where operational disclosure has not caught up with the breadth of its offer. Publishing a PeeringDB profile, correcting APNIC contacts, naming exchange participation and clarifying licence scope would make the network easier for customers and other operators to evaluate.

Six failure paths customers should model

The first path is rack or facility failure. A server, storage node, power distribution unit, cooling system or whole room becomes unavailable. The critical unknown is whether Red Cloud has independent compute and current data elsewhere, and whether that capacity is already reserved. A backup-only copy does not keep an application online; it begins a restoration process whose duration is undisclosed.

The second path is upstream or routing failure. AS55330 withdraws the route, the Red Cloud border router fails, a link is cut or a routing change is rejected. The current public topology exposes no second neighbour. A customer should know whether any private alternative exists, which services use it, how much traffic it carries and whether Red Cloud has tested failover of 160.191.191.0/24.

The third path is access-network failure. The cloud service remains healthy, but a fibre, point-to-point radio, point-to-multipoint base station, microwave relay, satellite terminal or customer power supply fails. This path matters especially when Red Cloud sells both the workload and the circuit. End-to-end availability can be lower than either component's individual figure, and shared sites can make failures correlated.

The fourth path is hardware-stock and labour failure. The broken part is known, but no compatible spare is in Kabul, the qualified engineer is unavailable, or access to the roof, tower or facility is delayed. Red Cloud's broad catalogue means the support team may cover many technologies. The customer needs local stock and escalation evidence for the specific service bought, not a general claim of technical experience.

The fifth path is billing or provider-contract failure. An account is suspended, a licence expires, an underlying supplier refuses work, or Red Cloud loses access to a platform or site. No cable has broken, yet the customer loses service or administrative control. Cure periods, independent credentials, current copies and step-in rights reduce this risk.

The sixth path is migration failure. The customer decides to leave during a degradation but discovers that data is slow to extract, application state is incomplete, address space cannot move, or only Red Cloud controls critical identities. Portability must be exercised while the relationship is healthy. An untested exit is not a recovery plan.

These paths interact. A nationwide transport disruption can prevent engineers reaching management systems and customers reaching backups. A facility fault can flood support. An upstream fault can block the data movement needed for migration. A commercial dispute can prevent access to the very copy intended for recovery. The purpose of modelling them separately is not to pretend they stay separate; it is to identify the point at which each dependency acquires an independent fallback.

What evidence would raise the grade

Red Cloud already has the beginnings of a stronger assurance case. It has a registered ASN, a long-visible route, a valid origin authorization, company-controlled service pages, public contact details and a specific connectivity catalogue. Those are better than anonymous reseller claims. The grade remains weak because the evidence stops before the expensive parts of the promise.

The first improvement would be a clear service ownership statement. For each cloud product, Red Cloud could say whether it owns hardware, leases colocation, resells another provider or manages customer equipment. It could name the contracting party and the party with physical repair authority. This would let customers ask for the right evidence.

The second would be a locality and fault-domain statement. Cities and countries are enough for public disclosure; exact rack locations can remain private. The statement should distinguish production, replica, backup and management locations and identify shared power, facility and network dependencies. It should define what "availability zone" means in the Red Cloud offer.

The third would be measurable service and recovery terms. Useful figures include service availability, support response, restoration target, data-loss target, backup frequency, retention, extraction time and degraded-path capacity. The terms should state exclusions and the service boundary, especially when Red Cloud supplies both access and hosting.

The fourth would be external network hygiene. A current PeeringDB profile could disclose AS153394's network type, traffic policy, facilities or exchange connections and network-operations contacts. APNIC incident contacts should use the correct domain. A public status page outside AS153394 would preserve communication during a route failure. IPv6 deployment would remove an obvious protocol gap, although it would need the same operational support as IPv4.

The fifth would be test evidence. A recent host failover, storage restore, site-isolation exercise, upstream failover, support escalation and customer data extraction would show what the system does under stress. Results do not need to expose customer data. Dates, scope, elapsed time, data outcome and lessons are enough to distinguish rehearsed capability from intent.

Finally, customers should keep their own controls. Independent monitoring of AS153394 and 160.191.191.0/24 can show route withdrawal or origin changes. Customer-held backups, domain control, encryption keys and administrator access can reduce lock-in. A second access path from an independent supplier can separate local reachability from Red Cloud's own edge. Provider assurance and customer resilience are complements, not substitutes.

The verdict: operating evidence without resilience proof

RED CLOUD INFORMATION TECHNOLOGY SERVICES COMPANY is not a paper-only subject. AS153394 is active; 160.191.191.0/24 is globally visible; its route-origin authorization is valid; and the route history extends back to November 2024. The company also publishes a detailed set of access, wireless, business and cloud offers. Those facts justify treating Red Cloud as an operating infrastructure dependency candidate in Afghanistan.

The same evidence does not justify treating its cloud claims as independently verified capacity. The public route footprint is one IPv4 /24 with one observed neighbour and no IPv6 announcement. There is no PeeringDB profile, no listed NIXA membership under AS153394, no named facility, no disclosed zone location, no host or storage inventory, no service-level schedule, no recovery objective and no public failover result. The company's own website is hosted outside its ASN, illustrating how little company location alone says about service location.

The difference matters to several groups. A small business may depend on Red Cloud for both internet access and a managed application. A bank branch may depend on a terrestrial or satellite link. A government office or NGO may use managed connectivity, cloud backup or on-premises support. A reseller may depend on Red Cloud's routing and escalation. When the system fails, the effect is not "the cloud is down" in the abstract. Staff lose access, transactions wait, backups stop, remote sites isolate and migration becomes harder at exactly the moment it is most needed.

The evidence grade is Weak, not negative. The visible network and detailed service pages are positive operating signals. The downgrade reflects the distance between those signals and the claims of multiple availability zones, redundant systems and rapid recovery. The facts required to close that distance are knowable: who owns the equipment, where the fault domains are, which paths are independent, what capacity survives, who answers at night and how a customer gets its workload out.

Red Cloud's most useful next move would not be another broad statement about seamless service. It would be a compact, testable account of the physical and contractual system behind the offer. Until then, customers should treat the company's cloud as a potentially real service whose external edge is visible, but whose racks, locality, redundancy and recovery remain matters for direct evidence and contract.