Summary
- Key Stones Cloud Tech Private Limited has a current, active internet identity. APNIC assigns it AS150024 and the portable IPv4 block
103.191.132.0/23; RIPE saw AS150024 announcing two/24routes to 325 of 326 IPv4 full-table peers on 12 July 2026. - The network is small but not single-homed in the public route view. AS150024 had two observed neighbours, AS138244 Hostzop Cloud Services Private Limited and AS146943 Tier 4 Cloud Services, and both visible routes had valid route-origin authorisation for AS150024.
- The company-to-service boundary is not simple. Key Stones' own website advertises dedicated servers, VPS, colocation, backup and disaster recovery, while its cloud page says cloud VPS is temporarily unavailable. Orders and copy repeatedly point to Hostzop systems, and Hostzop's terms have named Key Stones as the contracting company.
- Hostzop now says a separate company, Hostzop Cloud Services Private Limited, was incorporated as an extension in 2023 and identifies that newer company in current page footers. The two companies have the same two directors in public corporate aggregations, but common leadership and branding do not establish which one owns a given server, rack contract, route, customer agreement or liability.
- Public evidence therefore supports a live hosting operation around Key Stones, not a fully mapped resilient cloud. Buyers need the exact legal supplier, facility and rack location, installed and spare inventory, upstream and fibre-path diversity, support authority, backup isolation, tested restore results, billing continuity and an executable exit method in writing.
AS150024 is a real edge, not a marketing abstraction
The strongest operating evidence for Key Stones sits outside its product copy. The APNIC record for AS150024 names KEYSTONES-AS-IN, gives the country as India, describes the holder as Key Stones Cloud Tech Private Limited and marks the number active. The record was registered on 3 August 2022. Its technical and administrative contact is Rajesh Kumar at the company's keystonescloudtech.com domain and a Choolai, Chennai address. This is a current internet-number record with a maintained abuse contact, not an uncorroborated directory listing.
The route is also visible. At the 12 July 2026 observation point, RIPE's routing-status result showed two IPv4 prefixes covering 512 addresses, no IPv6 space, and two observed neighbours. Of 326 IPv4 full-table RIS peers, 325 saw the ASN. The last-seen route was present at the latest measurement hour. The announced-prefixes result identified 103.191.133.0/24 and 202.155.151.0/24 as the two current origins.
This distinguishes Key Stones from a company that has acquired a number but never used it. RIPE first saw AS150024 originating 103.191.132.0/24 in August 2022, and its route history records a changing set of announcements since then. Address use and upstream arrangements have evolved, but the ASN has a multi-year public history. IPinfo's AS150024 profile also classifies it as hosting, lists the same two current /24 routes and reports responding addresses in each range. Those active responses do not prove that every retail product is available, but they reinforce that the network is carrying systems rather than existing only on paper.
Route-origin security adds another positive signal. RIPE's validation response for 103.191.133.0/24 reports a valid authorisation under the covering Key Stones /23, with a maximum length of /24. Its response for 202.155.151.0/24 likewise reports the observed AS150024 origin as valid. Route-origin authorisation does one useful job: it lets receiving networks distinguish this intended origin from an unauthorised origin. It does not create a second fibre, reserve a spare router, protect a hypervisor or guarantee that a technician can reach a failed server.
That distinction matters throughout this profile. A well-maintained ASN establishes operating intent and visible connectivity. It is not a data-centre inventory. A route can remain visible while all servers behind it are unreachable; a server can remain healthy while a route disappears. The buyer's task is to connect the public edge to the physical and contractual system that delivers the purchased service.
One portable block reveals two operating boundaries
The APNIC address record assigns 103.191.132.0/23 to Key Stones Cloud Tech Private Limited as allocated portable space. The range contains 512 IPv4 addresses, from 103.191.132.0 through 103.191.133.255, and uses the same Chennai contact and company email as AS150024. Portable status is useful because the allocation is associated with the resource holder rather than being a small address slice simply delegated by one transit supplier. It can improve exit options if contracts, routing permissions and technical arrangements permit the holder to move it.
The two halves of that allocation currently tell different stories. 103.191.133.0/24 is originated by Key Stones' own AS150024. The other half, 103.191.132.0/24, is originated by AS138244, Hostzop Cloud Services Private Limited. Hostzop-style reverse names appear throughout the lower half, and the Key Stones website itself has been observed at 103.191.132.77. A public DNS lookup also reports Hostzop nameservers alongside that address. This is not an inherently problematic arrangement. An address holder can authorise another network to originate part of its space. It is, however, a concrete dependency.
The split creates two failure domains within one registered block. If AS150024 has a control-plane problem, services on the self-originated half may lose reachability even while the Hostzop-originated half remains available. If AS138244 or its carrier handoff fails, the Key Stones site and systems on 103.191.132.0/24 can be affected while AS150024 continues announcing its own routes. A customer assigned an address should therefore know which half it comes from, which ASN originates it, whether that origin can change during recovery and whether reverse DNS, mail reputation, firewall allowlists and licences can move with it.
The second AS150024 route introduces a different dependency. The APNIC record covering 202.155.151.0/24 places it inside 202.155.144.0/21, registered to OMAO Singapore Broadband as non-portable space. Yet the /24 is validly originated by AS150024, and third-party observations show Hostzop-style reverse names on many addresses. This looks like leased, delegated or otherwise authorised address space rather than an allocation owned by Key Stones. The exact commercial arrangement is not public. If a provider agreement ends, the addresses may not be portable in the same way as the Key Stones /23.
This is where address quantity can be mistaken for resilience. AS150024 originates 512 IPv4 addresses in two routes, but only half of those addresses sit in Key Stones' own portable allocation; the remaining originated /24 belongs to a larger Singapore-registered block. Meanwhile, the other half of Key Stones' portable allocation is originated by Hostzop's ASN. The count is real. The control rights differ. An exit plan that assumes all 768 addresses associated with these public arrangements can be carried to another provider would be unsafe without route letters, allocation records and contract terms.
Two upstreams reduce one risk, not every risk
RIPE's neighbour view saw two networks to the left of AS150024: AS138244 and AS146943. The first is Hostzop Cloud Services Private Limited. The second is Tier 4 Cloud Services. The independent bgp.tools profile reports the same two upstreams and two originated IPv4 prefixes. At a basic level, this is better than a public route that depends on one upstream ASN.
The topology does not establish physical diversity. Both BGP sessions might terminate on one router. Two routers might use one switch, one meet-me room, one building entrance or one underground duct. Both upstreams could ultimately depend on one metro fibre segment. A power event at the rack could remove both sessions at once. Public AS paths show logical neighbours, not cross-connect identifiers or surveyed fibre paths.
The two upstreams also have different scale and public footprints. Hostzop's AS138244 is directly entwined with the Key Stones address allocation and brand history. Tier 4 Cloud Services is a much larger Indian hosting network; its PeeringDB entry lists multiple exchange points and facilities, including Mumbai, Panvel, Pune and Greater Noida. That wider footprint can make Tier 4 a useful transit option, but the list does not reveal where AS150024 hands traffic to it. The handoff could be local to one Chennai facility or delivered remotely over another party's circuit.
AS150024 itself has no PeeringDB network entity. Participation is voluntary, so absence is not evidence of poor operation. It does mean a buyer cannot use that common public record to confirm Key Stones' facilities, exchange ports, traffic level, interconnection policy, looking glass or network-operation contacts. CAIDA's AS Rank result sees a small edge with one provider in its own data view and a one-AS customer cone. That result lags the richer current neighbour view, but it appropriately describes the network as a small endpoint rather than a broad transit platform.
There is also no visible IPv6 announcement. RIPE recorded zero IPv6 prefixes and zero visibility among 322 IPv6 peers. A hosting buyer that needs native dual stack should not infer it from generic website references to IPv6. It should request the assigned IPv6 prefix, a route observation, reverse-DNS delegation, maximum transmission unit details and a test instance. An IPv4-only public edge can still serve many workloads, but it narrows address strategy and leaves the provider dependent on increasingly scarce IPv4 inventory.
Useful network diligence is therefore specific. Ask for both current upstream names, the routers and facilities at which each terminates, whether they use separate power feeds, whether their fibre paths enter separately, and what AS path appears during a forced failover. Ask for a maintenance notice from each carrier with commercially sensitive fields removed. Then test withdrawal of one path during a scheduled exercise. Two names in BGP are evidence of logical choice. Recovery evidence begins when one can fail without taking the workload with it.
The storefront sells capacity, but its own pages disagree about availability
The Key Stones homepage presents dedicated servers, VPS, web hosting, managed support, colocation, backup, infrastructure management, disaster recovery and data-centre services. It publishes starting prices of Rs.6,500 a month for a dedicated server, Rs.450 for VPS and Rs.250 for web hosting. Its dedicated-server page lists processor generations, RAM, disk options, transfer allowances and 1Gbps ports. These details describe recognisable saleable units rather than a vague technology consultancy.
The order path complicates attribution. Several dedicated-server buttons lead to support.webhostingbingo.com, while cloud and CPU-optimised offers lead to manage.hostzop.com. The copy repeatedly calls the service Hostzop. The Hostzop terms page has explicitly described the agreement as one between Key Stones Cloud Tech Private Limited, using the Hostzop name, and the customer. That is strong evidence that Key Stones historically operated the Hostzop commercial identity.
But the current Hostzop surface identifies a successor or extension. Hostzop's company history says Hostzop Cloud Services Private Limited was incorporated as an extension in 2023. It says the business began offering hosting under the Hostzop name in 2016 and reached a data-centre collaboration in 2024. Public corporate information for Hostzop Cloud Services Private Limited gives a separate corporate identification number, a December 2023 incorporation and the same two directors reported for Key Stones. Current Hostzop pages put the newer company's name and tax registration in the footer.
The resulting picture is more credible than an anonymous storefront, but less simple than one company selling from one site. The older Key Stones company remains the APNIC resource holder and AS150024 operator. The newer Hostzop company fronts current marketing and facility claims. AS138244 is registered in the newer Hostzop company's name and originates half of Key Stones' portable block. Common directors and an explicit "extension" narrative suggest continuity under common leadership.
They do not, by themselves, transfer title to servers, assign old customer agreements, make one company liable for the other's debts or authorise one company to issue service credits under an agreement signed by the other.
There is a second warning in the catalogue. The Key Stones cloud server page displays detailed Linux and Windows configurations but also states that cloud VPS is temporarily unavailable. The CPU-optimised page carries the same message. A product table can persist after stock, platform capacity or commercial priority has changed. The direct statement of temporary unavailability should outweigh generic homepage claims that imply universal availability.
A buyer should consequently treat each order as a fresh factual inquiry. Which legal name appears on the quote, invoice and service agreement? Does that entity own or lease the server? Which ASN and address block will be assigned? Is the order for cloud, VPS, bare metal, colocation or a managed layer on someone else's hardware? Is the advertised configuration in stock now? The answers determine who can repair the service and what can be moved if the relationship ends.
Chennai is the centre of gravity, not a complete rack map
The public evidence repeatedly points to Chennai. APNIC records Key Stones' number-resource contact at 93 Ashtabujam Road in Choolai. Corporate aggregators report Chennai registered offices for Key Stones, including a later Egmore address. Hostzop's current contact page gives an Egmore head office for Hostzop Cloud Services Private Limited and separately identifies an AdaniConneX data centre at SIPCOT IT Park in Siruseri, Chennai. Current Hostzop product pages say servers are based in Chennai and Mumbai.
Those are different kinds of location. A registered office is where corporate notices and records may be handled; it does not prove a server hall. A support office can house staff while the equipment sits elsewhere. A facility address identifies a building or campus but not the contracting tenant, hall, cage, rack or power circuit. "Chennai and Mumbai" can describe product coverage while a specific customer exists in only one site.
The Key Stones colocation page makes older and less settled claims. It describes an "upcoming" 35,000-square-foot high-density facility inside a special economic zone, along with three-route fibre redundancy, central N+1 uninterruptible power and N+1 diesel generators. The future tense is crucial. The page does not name the facility, give a commissioning date or provide an operator certificate. It should be read as a design proposition, not current installed capacity.
Current Hostzop material is more specific about Siruseri and AdaniConneX, but it belongs on pages branded and footered by the newer Hostzop company. One vCore dedicated-server page says the service is hosted in the AdaniConneX Chennai facility. Hostzop's main site sells quarter-, half- and full-rack colocation in Chennai. These are meaningful current sales claims. They do not establish that every system in Key Stones' AS150024, every address in the Key Stones /23 or every older Key Stones customer is in that facility.
The visible route also does not settle geography. IP geolocation services place much of the associated space in Chennai or Mumbai, but those estimates are built from network observations and commercial data. They can identify a plausible metro and are useful for latency planning. They cannot prove the physical custody of a disk, the jurisdiction of a backup copy or the facility named in a contract.
The correct location statement is therefore bounded: Key Stones is a Chennai-registered Indian resource holder with a live hosting ASN; Hostzop-branded material under related leadership advertises Chennai and Mumbai capacity, and the newer Hostzop company names a Siruseri facility. The exact rack location for a particular Key Stones service remains order-specific. A serious buyer should require the facility name, full service address, suite or cage boundary, rack identifier, equipment owner, landlord or colocation counterparty and backup location before relying on locality or multi-site recovery.
Installed capacity is not the same as capacity that can survive a failure
Hosting catalogues translate lumpy equipment into neat monthly units. A virtual machine may be sold as six virtual processors, 16GB of memory and 100GB of storage. A dedicated server may be sold as one older Xeon, 32GB of RAM, a 960GB solid-state drive and 5TB of transfer. A rack plan may include 10U, 20U or 42U and a stated power allowance. Those units help a customer compare prices. They do not disclose the inventory supporting them.
There are at least six useful capacity states. Planned capacity exists in a drawing or purchase intention. Installed capacity is physically present. Commissioned capacity has passed acceptance. Free capacity is not currently allocated. Saleable capacity can be assigned without violating power, cooling, storage or licence limits. Recoverable capacity is kept available so failed hosts or a failed site can be absorbed. Only the last state answers whether a service can survive a fault without evicting another workload.
The Key Stones pages give no host count, rack count, aggregate power draw, storage-cluster fill level, port occupancy or reserved-failover percentage. Current Hostzop pages publish more architectural claims, including AMD EPYC hosts, NVMe storage, OpenStack and Ceph. The Hostzop cloud page says Ceph data is replicated across multiple servers. A separate high-performance page claims live migration, auto-healing nodes and triple-replicated storage. These claims describe a plausible resilient design for the newer Hostzop platform. They do not quantify free capacity or prove that Key Stones' older services use that platform.
Dedicated-server economics are especially physical. Some listed Key Stones configurations use Intel E5 v3 and v4 processors, generations that can still serve ordinary hosting but are no longer current. Low monthly prices may reflect depreciated hardware, wholesale supply, high utilisation or a deliberate margin strategy. None of those explanations is automatically bad. They create different repair risks. If a motherboard fails, the provider needs a compatible board, spare chassis or a migration destination that preserves the customer's disks and network identity.
Cloud capacity faces a different constraint. Live migration requires compatible hosts, working shared storage and enough spare memory and processor capacity. Triple replication requires at least three suitable storage locations, but three copies in one room can still share power, cooling and fire risk. A storage cluster above a prudent utilisation level can struggle to rebuild after a drive or node failure. A buyer should ask for current utilisation ranges, failure-domain labels, rebuild tests and the number of simultaneous host losses the service is designed to absorb.
Colocation customers need power truth rather than floor-area marketing. A 42U rack does not imply that all 42 units can be filled with high-density servers. The limiting factor may be 4kVA of contracted power, cooling per rack, breaker capacity, network ports or floor loading. If a plan includes 4kVA, the customer should ask whether that is rated, usable or protected power; whether A and B feeds are separately metered; and what happens when one feed must carry the whole load.
This is why installed versus usable capacity should appear in the contract review. Ask for the ordered configuration, the actual hardware serial and ownership status, the host or rack assignment, the overcommit policy, storage redundancy, current free capacity and replacement-stock policy. A retail plan proves an offer. It does not prove recovery headroom.
Power, cooling and repair windows shape the real service level
The Key Stones service-level page is unusually revealing because it describes physical operations as well as availability. It defines a network boundary from the customer's cabinet switch to the border router, contemplates facility access, names backup and hardware monitoring among optional services, and promises 99.98% availability for power and cooling. It states a four-hour hardware-resolution target and asks customers to provide a preventive-maintenance window once every quarter.
Those terms make the article's title literal. Hosted capacity depends on racks, transit and repair windows. A quarterly window means maintenance can require customer downtime. The page says the necessary duration depends on the customer's environment and that the environment may be unavailable during the window. It also lists broad exceptions, including scheduled and emergency maintenance, customer links, outside networks, DNS outside the provider's control, customer software and equipment supplied by others.
An availability percentage needs this denominator. At 99.98%, a nominal 30-day month contains about 8.6 minutes outside the target before exclusions. A year contains about 105 minutes. But if planned maintenance, emergency work and several dependency failures do not count, measured contractual downtime can be much smaller than the time a customer cannot use the application. The remedy is also limited: the page describes service credits, with a ticket required to establish eligibility, rather than compensation for lost business.
The four-hour hardware statement needs similar precision. Does "resolution" mean diagnosis, replacement, service restoration or a final update? Does the clock run outside business hours? Is it suspended while the provider waits for customer approval? Is spare hardware on site for every listed server generation? A drive swap can be fast; rebuilding a large array may take much longer. Replacing a failed host is not the same as restoring a customer application if the boot disk, virtual-machine image or licence will not start on the replacement.
Power claims also require a boundary. The older Key Stones colocation page advertises N+1 uninterruptible power and generators, while the service-level text says dual active power from two grids. Current Hostzop materials make similar redundancy claims for the Chennai facility. Two utility feeds can still meet at one switchboard. N+1 generators can share fuel, controls or a common distribution path. A dual-corded server can still be connected to two outlets on one branch circuit. The useful evidence is a one-line diagram, recent generator-load test, transfer test, battery-maintenance record and the rack's actual A/B circuit assignment.
Cooling has the same problem. The service-level page names a 23 degrees Celsius target with a two-degree tolerance. A room can meet that average while a dense rack develops a hot spot. N+1 cooling protects against one component loss only if remaining units can carry the actual load and power distribution survives. Ask for rack inlet measurements, alarm thresholds, containment design and a test showing what happens when one cooling unit is deliberately taken out of service.
Maintenance is not a flaw. Refusing maintenance can be more dangerous than scheduling it. The important issue is whether the customer can design around the window. That requires advance notice, a clear scope, an unaffected recovery location, a tested failover path and authority to postpone non-urgent work when a customer's own redundancy is impaired.
Support and billing can fail while the servers remain healthy
Infrastructure continuity is partly a labour problem. A provider can have power, network and healthy disks while a customer remains offline because no authorised person can reset a switch port, replace a drive, approve a route change or restore account access. Key Stones advertises 24-hour help and managed support. Its service-level text requires the customer to open a trouble ticket and use that ticket to claim a credit. Those are sensible operating conventions, but the public pages do not publish response tiers, escalation names or staffing depth.
The small-company boundary matters here. Public corporate aggregations list two directors for Key Stones. The same two people are listed for the newer Hostzop company. That continuity may make decisions quick, but it can also concentrate commercial and technical authority. Public evidence does not disclose employee count, on-call coverage or whether facility work is performed by company staff, Hostzop staff, an AdaniConneX remote-hands team or another contractor.
A buyer should map authority before an incident. Who can enter the facility at 3am? Who can approve emergency remote hands? Who holds router credentials? Who can authorise an upstream to accept a route change? Who controls the customer portal, domain names, DNS and billing account? If Key Stones issued the original invoice but Hostzop Cloud Services now operates the platform, which service desk is contractually obliged to act?
Billing is its own fault domain. The older Key Stones page sends different products to multiple order systems. A failed payment, disputed invoice or account migration can suspend a service without any physical fault. The public terms on the Key Stones site identify keystonescloudtech.com, LLC, even though the subject is an Indian private limited company; the Hostzop terms identify Key Stones more precisely, while current Hostzop footers identify the newer company. Contract text that shifts names across pages should be resolved before payment, not after suspension.
The customer should require a quote and order form that use one exact corporate name and registration number, identify all incorporated policies, state the billing currency and tax treatment, and explain suspension notice. It should say whether data remains accessible during a billing dispute, how long a terminated service is retained, whether an export can proceed while an invoice is contested and who releases portable addresses or domain transfers.
Support evidence should include a severity table, acknowledgement and restoration targets, escalation contacts, facility remote-hands terms and an example incident report. A public status page can help, but Hostzop's status page appears centred on response time and a single displayed address, 103.191.132.2. That address lies in Key Stones' allocation but is originated by AS138244. Monitoring one reachable endpoint cannot establish the state of every rack, storage cluster, customer network, control panel or AS150024 route. Customers need component-level notices and their own independent monitoring.
Backup is an option until a restore proves otherwise
The Key Stones backup page presents backup as a managed service, and its disaster-recovery page promises preparation for technical and natural disruptions. Current Hostzop pages go further, describing replicated Ceph storage, snapshots, live migration and a 90-day export period in the event of business closure. These claims identify the right concerns. Public pages do not provide a customer-specific recovery point, recovery time, copy location or successful restore record.
Three protections are often confused. High availability keeps a service running through a component fault. Backup preserves an earlier copy that can be restored after deletion, corruption or compromise. Disaster recovery recreates service after loss of a larger failure domain. Replicated storage is valuable for hardware failure, but it can faithfully replicate an accidental deletion or ransomware-encrypted data. A snapshot in the same control account can be deleted with the production system. A backup in the same room can be lost with the room.
A customer should ask where each copy resides, which company operates it, which credentials can delete it and whether it shares the same power, facility, carrier or storage administrator. At least one recovery copy should have a failure domain independent of the primary service and protection against immediate alteration. The provider should state retention, encryption, key custody and the cost and time to retrieve a large dataset.
Restore tests are the evidence. For a virtual machine, export an image, network configuration and attached volumes, then boot it outside the primary environment. For shared hosting, restore files, mailboxes, databases, DNS and certificates into a clean account. For bare metal, test recovery to replacement hardware. For colocation, confirm how backups leave the rack if both customer devices fail. Record the achieved recovery point and recovery time, not merely that a backup job reported success.
Migration is equally physical. A few gigabytes can leave over an ordinary internet link. Tens of terabytes may take days even at sustained gigabit rates, and production changes continue during transfer. Egress limits, throttling, transfer fees and maintenance windows can extend the move. If the customer's addresses come from the non-portable 202.155.151.0/24, renumbering may also require DNS changes, mail warm-up, partner allowlist updates and certificate review.
Portable Key Stones space could improve continuity for eligible customers, but only the resource holder can coordinate route authority and only if the customer agreement permits it. Most small hosting customers receive individual addresses, not rights to carry a provider's block elsewhere. The practical exit package is therefore open-format data, configuration documentation, current DNS zone files, credential transfer, a tested destination and an overlap period in which both services run.
The provider's public closure assurance is a positive market signal, but it appears on a current Hostzop page under Hostzop Cloud Services Private Limited. A Key Stones customer should not assume it automatically amends an older Key Stones contract. The assurance belongs in the signed order with a named custodian and a method that still works if the management portal is unavailable.
Locality is a chain of custody, not an Indian flag beside an IP address
The service area is India, and the strongest physical claims point to Chennai with some Hostzop pages also mentioning Mumbai. That can suit customers seeking Indian latency or local custody. Yet locality requires more than an Indian resource-holder country code or a geolocation result. It depends on where primary disks, replicas, backups, logs and support access actually reside.
The current route mix illustrates the issue. Key Stones' own /23 is registered in India. The second /24 originated by AS150024 is carved from a Singapore-registered larger block. That registration does not prove customer data is in Singapore; IP registry country and server location can differ. Conversely, an Indian route origin does not prove every backup remains in India. The correct answer comes from the service architecture and contract.
India's CERT-In directions are directly relevant to data centres, VPS providers and cloud providers. They require covered organisations to maintain ICT logs securely for a rolling 180 days within Indian jurisdiction and require specified subscriber information to be retained for five years or longer where law requires. A hosting customer should therefore understand what identity, assignment and usage records the provider keeps, where those records are stored and how incident requests are handled.
India's data-protection framework is also in staged implementation. The official Digital Personal Data Protection Rules 2025 page publishes the final rules and commencement material. The commencement notification phases major provisions over one year and eighteen months from November 2025. A customer's obligations depend on its role, data and effective provisions; a server in Chennai is not a substitute for legal analysis.
The operational questions are still concrete. Which legal company processes account and support data? Does it use subcontractors? Can remote support access the server from outside India? Are monitoring records copied abroad? Where do backup and disaster-recovery copies reside? Can the customer select Chennai only, and does that selection cover every replica? What happens to retained identity and access records after cancellation?
Network licensing should not be inferred from an ASN. The Department of Telecommunications describes internet-service authorisations by scope and service area. A hosting company can buy transit and provide hosted compute without operating every type of licensed access service. AS150024 establishes routing activity, not a conclusion about any licence the company may or may not require. If a customer buys regulated connectivity rather than ordinary hosting, it should request the exact authorisation from the contracting party.
Locality is best written as a schedule: named primary site, named recovery site, approved processing countries, backup locations, support-access controls, retention periods and notification before change. That schedule should follow the workload when the provider changes platform or corporate entity.
Who is affected when one layer fails
The user impact depends on the purchased layer. Shared-hosting customers may lose websites, email, databases and control-panel access together because many functions share one server or management domain. VPS customers may retain independent operating systems but still share a host, storage pool, top-of-rack switch and billing system. Dedicated-server customers avoid noisy neighbours at the compute layer but remain dependent on facility power, network, remote hands and spare hardware. Colocation customers own more equipment but must coordinate access, cross-connects and replacement parts.
A route failure affects public reachability. If one AS150024 upstream fails cleanly and the other path is truly independent, traffic can reconverge. If both sessions share a physical path, both can disappear. Customers on the AS138244-originated half of the Key Stones block face a different route boundary from customers on AS150024. A company website failure on 103.191.132.77 would not prove AS150024 is down, and a loss of 202.155.151.0/24 would not necessarily affect the website.
A rack event has a smaller but more physical blast radius. Loss of one power distribution unit can affect single-corded devices. A failed switch can isolate all servers in a rack. A cooling problem can force an orderly shutdown. A disk failure can become data loss if redundancy is already degraded. Customers need to know whether their application components share the same rack and whether the provider alerts them when protection is reduced but service is still running.
A support failure extends every outage. If the only person with authority cannot be reached, a ten-minute hardware replacement can wait hours. If customer records are split between Key Stones and the newer Hostzop company, staff may struggle to verify entitlement or locate the correct device. A current asset register and a clear agency agreement are resilience controls, not clerical details.
A billing or contract failure can be abrupt. Suspension can remove network access while data remains intact. Termination can begin deletion clocks. Insolvency or a dispute with a facility landlord can limit physical access. A customer with portable data but no current export is still trapped by transfer time. A customer with backups but no credentials is not recovered.
Downstream consequences can be wider than the direct account. An agency hosting hundreds of small-business sites can propagate one server failure to many companies. A reseller can lose customer DNS and mail. An online shop can lose checkout, inventory and transactional email at once. A software company can lose application and support portals on the same provider. These users rarely know the ASN, but they experience every shared dependency behind it.
The best mitigation is layered. Use independent DNS where appropriate, keep credentials and zone files outside the hosting account, place backups under a separate control boundary, monitor from outside both upstreams, and maintain a tested destination. For important services, separate the application, backup and recovery control planes enough that one company account or one facility event cannot remove all three.
What evidence would turn a medium case into a strong one
The public case for operation is already substantial. AS150024 is active and widely visible. Key Stones holds portable address space. The address block carries hosted systems. Product pages, order links, terms and public corporate records connect Key Stones to the Hostzop service history. This is enough to reject the hypothesis that the entity has no observable operating footprint.
The case remains medium because the newest and most detailed infrastructure claims belong to Hostzop Cloud Services Private Limited, a separate company incorporated in 2023. The public materials do not show an asset transfer, customer novation, intercompany operating agreement or schedule mapping Key Stones routes to Hostzop racks. They also do not publish site-by-site capacity, independent route tests, spare inventory, restore results or incident history.
A stronger case would begin with corporate clarity: a signed statement identifying the legal supplier for new and legacy accounts; the role of Key Stones and Hostzop Cloud Services; ownership or lease status of AS150024 routers, servers and racks; and the agreement allowing AS138244 to originate part of Key Stones' /23. Existing customers should receive any assignment or novation directly, not infer it from a footer.
Facility evidence should identify the actual Chennai and, where applicable, Mumbai locations, the operating company, cage and rack boundary, contracted power, cooling design and remote-hands provider. A current independent certification can support facility controls, but the scope and certificate holder must match the service. A certificate belonging to a landlord does not automatically cover the tenant's server operations.
Network evidence should include router pairs, separate carrier handoffs, physical-path diversity, current route filters, maximum-prefix controls, route-origin authorisations and a recent forced-failover result. The two public neighbours are a good starting point. The test must show that customer traffic survives loss of each path and that monitoring detects the degradation.
Capacity evidence should show installed hosts and storage, current utilisation bands, reserved recovery headroom, spare drives, power supplies and compatible replacement servers. Cloud customers need failure-domain and rebuild results. Dedicated customers need serialised inventory and replacement times. Colocation customers need circuit and rack assignments.
Recovery evidence should define recovery point and recovery time per product, locate backups outside the primary failure domain, show immutable or separately controlled copies, and include a recent restore report. Exit evidence should include formats, bandwidth, fees, deletion timing, DNS and address handling, and a test export performed before the service is critical.
Finally, the customer should reconcile public promises with the signed agreement. The 99.98% claim, four-hour hardware statement, quarterly maintenance, exclusions, service-credit method, data-loss disclaimer and support escalation should all appear in one coherent contract under the correct company name. Marketing can describe an ambition. The contract determines who acts when the rack, transit link, spare shelf, account system or provider agreement fails.
The verdict: operating network, unresolved asset perimeter
Key Stones Cloud Tech Private Limited has more operating substance than its dated website design suggests. AS150024 is active, broadly visible and protected by valid route-origin authorisations. It originates two IPv4 routes through two observed upstreams. Its portable /23 contains active hosted systems, and its commercial history is tied by first-party terms to Hostzop.
The same evidence exposes the dependency structure. Half of the Key Stones block is originated by Hostzop's ASN. Another AS150024 route is drawn from a non-portable Singapore-registered allocation. Current Hostzop pages identify a newer legal company and make the strongest facility, cloud and recovery claims under that name. The older Key Stones catalogue still advertises services that another page says are temporarily unavailable. Public contract pages use inconsistent identities.
None of this proves service failure or misconduct. It shows why buyers should not collapse brand, company, ASN, address holder, transit provider, facility tenant and hardware owner into one assumed operator. The route evidence earns a medium network grade. A strong service grade requires a current map from the signed customer agreement all the way to the rack, carriers, spare inventory, support authority and recoverable copy.
For an ordinary low-risk website, price and responsive support may be enough. For an application that cannot tolerate long interruption, the buyer should insist on evidence before migration: exact counterparty, named site, tested second path, recoverable capacity, measured restore and an export held outside the account. Cloud capacity is easy to order because the physical commitments were made in advance. Resilience exists only when those commitments remain available during the repair window.