Summary
- Cloud.ir gives CLOUD Asre Dadeha Asiatech a real retail surface: the site offers cloud servers, VPS plans, cloud storage, CDN, cloud switching, cloud data-center services, a customer panel, published prices and an SLA, and its footer says the website belongs to Asre Dadeha Asiatech.
- The physical anchor is narrower than the product language. Cloud.ir says its infrastructure sits on ASIATECH data centers in Iran, and the about page says Cloud.ir has operated since Iranian year 1399 with more than 20 cloud products, but public pages do not identify the exact rack, city-by-city placement, power topology or restore test results behind each customer workload.
- The network evidence is strong at the control-plane layer. RIPE RDAP names AS60077 as AT-CLOUD for Asre Dadeha Asiatech, RIPEstat showed 18 IPv4 prefixes and 14,080 IPv4 addresses announced by AS60077 on 12 July 2026, and DNS for
cloud.irmapped to an AS60077 prefix. The same RIPE view showed one observed left-side neighbor for AS60077: AS43754, ASIATECH Asiatech Data Transmission company. - The buying question is therefore not whether a cloud product exists. It is whether a given customer can verify placement, capacity headroom, independent routes, backup locality, support escalation, maintenance exclusions, billing continuity and exit rights before a rack, upstream, hardware stock or account event turns a virtual server into a physical dependency.
The storefront is public, but the infrastructure promise is still layered
Cloud.ir is not a parked brand page. The Cloud.ir home page presents cloud servers, cloud data-center services, cloud switching, CDN, cloud storage, cloud domain management, a service-price page, support pages and a customer login path. The same page carries a phone number, an email address, a Tehran office address and a footer statement that the material and intellectual rights of the website belong to Asre Dadeha Asiatech. For this profile, that matters because the company identity is tied to a live service surface, not merely to a routing record.
The about page adds a service history. It says Cloud.ir began operating in Iranian year 1399 and has become one of Iran's leading cloud-service providers with more than 20 cloud products. The product groups named there include content distribution, cloud computing, cloud security, cloud storage, cloud networking and a cloud marketplace. Those claims are company statements, not independent measurements of capacity, but they make the basic commercial posture clear: CLOUD Asre Dadeha Asiatech sells hosted capacity to customers who do not want to buy and operate their own physical infrastructure.
The retail offer is also specific enough to inspect. The cloud server page says customers can create a cloud server quickly, pay for resources they use, change resources, configure networking, add or change IP addresses, monitor resource and network use, use a cloud firewall and schedule backups. The same page describes Linux, Windows and MikroTik server options and says support for cloud-server customers is available through ticket submission around the clock. A buyer should treat those as product promises that need contract and test confirmation, but they are still more concrete than generic "cloud" language.
Cloud.ir's price page makes the product even more inspectable. It lists VPS package names such as AT-VPS-B2, AT-VPS-G1 and AT-VPS-A2 with memory, CPU, disk, one free IP address, base traffic, add-on IP support, rebuild support and IPv6 shown on the package cards. It also shows hourly metering for cloud-server resources such as memory, CPU, disk, IP, received traffic and backup tiers. Price pages are not engineering diagrams, yet they expose how the service is packaged: a customer is buying finite compute, storage, address and traffic units that must exist somewhere before the control panel can allocate them.
The company also describes higher-level services around the same infrastructure. The cloud data-center page markets secure and easy data management, scaling, monitoring, virtualization, containerization and scheduled backup. The cloud storage page presents scalable storage, controlled sharing and access-level management. The CDN page describes content distribution through domestic, centralized and international modes, with user requests served through geographically closer data-center locations. The cloud switch page presents managed virtual networking between cloud servers and data centers. Each product reduces the customer's need to own equipment; each also introduces a dependency on the provider's placement, network design and support decisions.
That is the useful frame for the rest of the article. CLOUD Asre Dadeha Asiatech is not a mystery shell, but the visible service surface does not remove the need to test the lower layers. A cloud server can be provisioned in seconds only when the provider already has suitable host capacity, storage, public addresses, network reachability and billing authorization. A CDN can route a request to a closer edge only when that edge exists, has fresh content, has enough cache and transit capacity, and can still reach the origin when the customer's own server is sick.
A backup matters only if it can be restored outside the failure that damaged the primary workload. The public pages show the offer; they do not by themselves prove every resilience claim that a production buyer needs.
The physical anchor is ASIATECH data-center capacity in Iran
Cloud.ir's strongest physical statement is explicit: its cloud infrastructure sits on ASIATECH data centers. The cloud server page says the infrastructure of Cloud.ir cloud services is deployed on ASIATECH data centers, which it describes as the largest data-center network in Iran. It lists use of modern technologies, ISO27001 and TIA-942 Tier 2 and Tier 3 claims, security systems, stable network connectivity, high bandwidth consumption in Iran, and AC and DC power support. The cloud data-center page repeats the same ASIATECH data-center framing and says Cloud.ir data centers across Iran provide infrastructure for customers beginning cloud migration.
The about page is similar. It says Cloud.ir's data centers are distributed across Iran and that its infrastructure rests on ASIATECH data centers covering large and powerful facilities with global standards. It also lists AC and DC support. These claims are material because they move the service from pure retail abstraction to a named facility operator boundary: the cloud brand depends on ASIATECH's data-center estate and network, not on an unnamed overseas hyperscale region.
Outside the company pages, the public record gives older but useful context for that estate. Data Center Dynamics reported in July 2017 that AsiaTech opened a 700 square meter data center in Milad Tower in western Tehran. That report described AsiaTech as a privately owned company established in 2003, said it had obtained a license in 2013 for hosting, dedicated and shared servers and colocation, and said it ran five data centers and connected more than 430 towns and cities across Iran. DataCenterMap currently lists Asiatech Milad Tower Data Center and Asiatech Azadegan Data Center in Tehran, while its Milad Tower specs page says no capacity, power, compliance, security or building data was supplied by Asiatech.
Those outside references should be handled carefully. They corroborate that ASIATECH has been associated with named Tehran facilities and a broader data-center business. They do not prove which facility serves a particular Cloud.ir VM, CDN edge, storage bucket or backup copy in July 2026. They also do not prove that the 2017 facility condition, rack count, power design or customer count remains unchanged. Facility history is useful evidence of a real infrastructure company; it is not a current placement map.
That distinction matters to customers. A buyer may hear "data centers across Iran" and assume that two servers ordered from the same account land in separate buildings. They may not. They could land on the same host, two hosts in one rack, two racks behind one power unit, two halls in one building, or separate buildings whose metro fiber or upstream edge still converges. Conversely, the provider could have better separation than the public pages disclose. The public pages do not settle the point.
The customer has to ask for placement controls, anti-affinity rules, named sites or site codes, backup location, and what Cloud.ir means by "data center" for each service tier.
Power and repair labor are part of the same question. Cloud.ir can fairly say that cloud use avoids the customer's burden of buying equipment and maintaining a server room. That does not make physical maintenance disappear. Someone still has to replace disks, power supplies, line cards and memory; someone still has to schedule electrical work; someone still has to test generators, batteries, cooling and fire systems; someone still has to receive an alert and reach the rack.
A customer does not need to know every private detail of ASIATECH's facility design, but they do need to know which availability promises survive a rack event, a power-maintenance window, a storage failure and a shortage of replacement hardware.
AS60077 is visible, and the parent network is the obvious dependency
The network record gives CLOUD Asre Dadeha Asiatech a second concrete anchor. RIPE RDAP identifies AS60077 as AT-CLOUD and links it to Asre Dadeha Asiatech through ORG-ADA42-RIPE. The same RDAP response includes Asiatech NOC administrative and technical contacts at a Miremad Street address in Tehran, plus an Asiatech abuse role. This is registry evidence of a real autonomous system and operating contact chain. It does not describe individual servers, customers or uptime, but it confirms that the cloud service has its own network identifier.
RIPEstat's AS overview for AS60077 reported the holder as "AT-CLOUD Asre Dadeha Asiatech" and showed it announced at the 12 July 2026 query time. Its routing-status view showed 18 IPv4 prefixes and 14,080 IPv4 addresses visible from AS60077, with the first-seen prefix observation dating to 2014 and the latest-seen observation at the query time. The same RIPE view showed high IPv4 collector visibility and no visible IPv6 space in that particular status response.
The active service also points back into AS60077. RIPEstat's DNS-chain view for cloud.ir returned 193.151.157.174 for the apex name, and the network-info view for that address mapped it to 193.151.157.0/24 and AS60077. This does not prove that every customer workload runs inside the same prefix; it does show that the company's own public web presence is served from the cloud ASN.
The dependency is in the neighbor data. RIPEstat's ASN-neighbor view for AS60077 showed one observed left-side neighbor: AS43754. RIPEstat's AS overview for AS43754 names that network "ASIATECH Asiatech Data Transmission company." Its routing-status view showed a much larger network footprint at the same query time: 316 IPv4 prefixes, 209,920 IPv4 addresses and 86 observed neighbors. The picture is direct: the cloud ASN is visible, but its public upstream boundary appears to be the larger ASIATECH network.
Looking-glass samples make the relationship visible in actual paths. RIPEstat's looking-glass data for 193.151.128.0/22, one of AS60077's announced prefixes, included paths ending in AS43754 AS60077. Some global samples also showed earlier upstreams before AS43754, but the consistent near-origin dependency remained AS43754. That is not surprising for a cloud business attached to the same corporate infrastructure group, yet it matters because a fault at that boundary can affect many services at once.
This does not mean AS60077 is fragile. A single visible upstream relationship can be perfectly reasonable when the parent network has carrier reach, operational discipline and enough redundancy behind the scenes. It also does not mean AS43754 has only one external path; RIPEstat showed many neighbors for AS43754. The important point is narrower: public BGP evidence does not prove that AS60077 itself has multiple independent upstreams, separate physical entrances, separate edge routers or independent failover outside AS43754.
Customers should treat AS43754 as the visible upstream operating boundary unless Cloud.ir provides product-specific evidence of further separation.
RPKI answers a different question. RIPEstat's RPKI validation for 193.151.128.0/22 originated by AS60077 returned valid status with route origin authorizations covering AS60077. That is positive routing hygiene: it supports the legitimacy of the route origin. It does not prove traffic capacity, route diversity, power continuity, customer-isolation quality, backup recoverability or support response. An RPKI-valid route can still be withdrawn by mistake, filtered by an upstream, isolated by a cross-connect failure or made useless by a server-side outage.
Installed capacity is not the same thing as usable cloud capacity
Cloud buyers tend to see resource sliders. The operator sees inventory. CPU, memory, disk, backup space, public addresses, firewall state, monitoring, port capacity, host power draw and staff time all have to line up before a resource slider becomes a working server. Cloud.ir's public pages are useful because they reveal some of those ingredients, but they do not reveal the stock level.
The price page lists packages with fixed memory, processor, disk and traffic quantities. It also lists separate hourly components for cloud infrastructure, including backup schedules. That is enough to show that Cloud.ir sells the service as a priced resource pool. It is not enough to show how many hosts are in the pool, how many are reserved for failover, how much disk performance is available under contention, whether backup space sits in a separate site, how fast a damaged instance can be recreated, or whether the provider can satisfy a large order during a hardware shortage.
The network numbers provide an outer edge, not a server count. RIPEstat's announced-prefix list for AS60077 showed 18 IPv4 prefixes in the recent query period, including several /22, /23 and /24 ranges. The 14,080 IPv4 addresses seen in the routing-status view are real public-address capacity, but addresses do not equal virtual machines. Some addresses serve routers, load balancers, firewalls, name servers, customer instances, management functions or spare pools. A single server can use several addresses; many services can sit behind one address; unused addresses can coexist with a full compute cluster.
The same caution applies to Cloud.ir's IPv6 references. The price page shows IPv6 on VPS package cards. The RIPE routing-status query used here showed no visible IPv6 space for AS60077 at the query time. That does not prove IPv6 is absent from the product: IPv6 may be supplied through a different arrangement, exposed only in certain plans, visible in other collectors or represented differently on third-party routing sites. It does mean a customer needing native IPv6 should test actual allocation, routing, firewall behavior, reverse DNS, backup reachability and support escalation rather than relying on a package label alone.
Cloud.ir's own product language also separates capacity from resilience. The cloud server page says resources can be increased or decreased instantly and that when one server becomes unavailable, data is automatically made available from another server. The cloud data-center page says stored data is kept in multiple data centers and that other data centers preserve connectivity if one has trouble. Those are important claims. They also need precision. Which services are covered? Is the transfer automatic for all server types or only for data protected by a particular storage layer?
Are two data centers used by default or only if the customer configures them? Is the backup hot, warm or cold? Is there a tested recovery time? Are credits available if the automation fails?
Without those answers, a buyer should keep "installed" and "usable" separate. Installed capacity is the collection of hosts, racks, storage arrays, links and addresses the provider owns or leases. Usable capacity is what the customer can allocate now without overloading a host, exhausting an address pool, violating a placement rule or depending on one tired technician to swap a part after midnight. Cloud.ir's public pages prove a priced cloud product and a visible network. They do not disclose enough to convert that into a capacity reserve.
The SLA narrows the promise at exactly the points a failure will test
Cloud.ir publishes an SLA page, and that is a good thing for customers because it moves part of the risk conversation into public text. The most important part of the page is not a large uptime number; it is the limitations. The page says the uptime guarantee applies only to network and cloud-server availability during ordinary operation. It excludes the customer's server software, operating systems, configuration problems, denial-of-service attacks against a cloud server, suspended or stopped servers, outages other than the network or host server, and maintenance or critical patches that were announced in advance.
The same page defines mean time to repair or recovery as the average time to restore service based on agreement between provider and customer. It then lists cases that do not incur penalties, including force majeure, the customer's equipment, planned down time, customer-requested interruption, violations of law or the SLA, nonpayment, and orders from judicial or security authorities. These exclusions are not unusual in hosting, but they are decisive for a customer trying to measure risk. They move many real outages outside a simple uptime headline.
Consider a software failure. If the guest operating system breaks after a customer update, the SLA text suggests that the issue is outside the provider's uptime guarantee even if the customer experiences total service loss. That is reasonable if Cloud.ir sold unmanaged compute, but it means the buyer needs separate recovery rights: console access, rescue boot, snapshots, image export, rollback, rebuild and clear support boundaries. A "cloud server" is not managed application continuity unless the contract says so.
Consider a denial-of-service event. The cloud server page promotes cloud firewall controls and attack reporting. The SLA page excludes denial-of-service attacks against the cloud server from the uptime guarantee. The product may still help mitigate traffic, but the customer should not assume that every attack-induced interruption creates compensation. The question becomes practical: what traffic volume can the firewall handle, what is filtered at the cloud edge, what reaches the instance, who can change filters during an attack, and when can Cloud.ir suspend or rate-limit a target to protect other customers?
Consider billing. The SLA exclusion for nonpayment is ordinary, but the operational risk is not trivial. A prepaid wallet, a failed domestic payment, a corporate bank-card issue or a disputed invoice can become an infrastructure event if servers are suspended before an operator resolves the account. A company using Cloud.ir for production should ask how many reminders are sent, what grace period applies, what data retention follows suspension, whether snapshots remain accessible, and whether support can temporarily preserve service while billing evidence is reviewed.
Consider public authority orders. The SLA says downtime caused by judicial or security authorities is outside the penalty framework. That is a locality issue, not a judgment on the provider. If the workloads, backups and support accounts are inside one jurisdiction, the customer needs to understand how legal or policy orders can affect availability, data access, domain service and customer communications. The answer may be acceptable for a domestic Iranian website and unacceptable for a cross-border service with conflicting compliance obligations. The same physical locality can be a strength for latency and a constraint for governance.
The SLA therefore sharpens the buyer's questions. It does not make Cloud.ir weaker; it makes the service shape more knowable. The customer should distinguish network availability, host availability, guest health, storage integrity, backup recoverability, CDN behavior, account status and legal constraints. The public SLA does not collapse those layers into one promise. Neither should a production buyer.
CDN, storage and cloud switching expand the blast radius as well as the feature set
Cloud.ir's CDN, storage and virtual networking services are useful because they can reduce load on a single origin server and give customers more architecture choices. They also make the dependency map broader. The CDN page says domestic distribution can answer requests through local data centers and create half-price traffic for domestic users; it also describes routing users to closer servers, compressing and caching content, monitoring requests and responses, access limits by country and protection against attacks. That is a real product story, but it turns a site into a chain: DNS, CDN edge, cache state, origin reachability, certificate handling, account configuration and support all have to work together.
If the origin server fails, the CDN may continue serving cached static content. It may also serve stale content, fail on dynamic routes, or increase error rates when cache misses hit an unhealthy origin. If a CDN edge loses upstream reachability, users in one region may see errors while others do not. If access rules are misconfigured, a locality feature can become an availability problem. The customer needs cache purge controls, origin shield behavior, logs, fail-open or fail-closed rules, certificate renewal visibility and a way to move DNS away if CDN service becomes the failure.
The storage offer has a different risk shape. The cloud storage page says the service lets customers scale capacity, manage files, manage access keys, connect storage to domains, share files and define access levels. It also says data is protected by distribution across multiple servers. That is valuable, but storage durability is not visible from the outside. A customer needs to know whether the service is object storage, block storage, file storage or a mixture; what replication means; whether replicas sit in one room or multiple sites; how deletes are protected; whether versioning exists; how keys are rotated; how recovery is tested; and how fast a full export can be completed.
The cloud switch service is equally important. The cloud switch page describes managed networking between cloud servers and data centers, routing traffic and creating private networks. It also says the service can identify available alternative resources and switch automatically during disruption. That type of feature can reduce manual recovery if it is implemented well. It can also become a single point of change if a private-network misconfiguration isolates a group of servers that otherwise remain healthy.
The deeper pattern is that a feature can be both a resilience layer and a new dependency. Backups protect data only if they are stored outside the failing boundary and can be restored quickly. CDN protects the origin only if content can be served correctly when the origin is weak. Virtual networking protects east-west traffic only if the control plane and switching fabric remain healthy. Cloud firewalls protect customers only if filter changes can be made safely under pressure. The customer should not ask whether these features exist in the abstract.
They should ask how each feature behaves when a host, rack, route, storage cluster, account or support queue is already failing.
Locality is a product attribute, not a slogan
Data locality is one of the strongest reasons to buy from Cloud.ir. The company pages put the cloud infrastructure on ASIATECH data centers in Iran, the CDN page emphasizes domestic distribution options, and the network evidence shows the public cloud site on AS60077 with an Iranian ASIATECH parent network. For Iranian users and businesses, that can mean lower latency, domestic payment alignment, familiar support language, local traffic economics and a provider whose physical estate is close to the intended audience.
But locality has to be defined per service. A virtual server may run in Iran while an email relay, management console, analytics service, backup copy or support attachment takes another path. A CDN product may offer domestic and international distribution modes. A storage service may replicate across several servers without saying whether those servers are in separate buildings. A customer cannot infer the exact location of every copy of data from the company address, the top-level domain, the autonomous-system name or the phrase "data centers across Iran."
Cloud.ir's own region row for a buyer-facing profile can be global because IP reachability is global and cloud customers can be anywhere with a working account and network path. That is different from saying the company operates global regions. The public product evidence reviewed here points most strongly to Iranian infrastructure and ASIATECH's domestic data-center estate. If a customer needs an Iran-only service, they should request a written statement about compute, storage, backup, log and support access locality.
If a customer needs multi-country continuity, they should ask whether Cloud.ir itself provides that or whether the customer must build it with another provider.
Locality also changes incident response. A domestic Iranian content site may prefer Cloud.ir's domestic CDN behavior and ASIATECH facilities because most users sit near those paths. An international SaaS vendor may worry about payment access, sanctions exposure, foreign-user latency, route filtering, dispute resolution and the ability to export data under pressure. A public-sector or regulated user may value local facility control but need a stricter statement about who can access data, where snapshots sit and how orders from authorities are handled. The same infrastructure can be well suited to one customer and unsuitable for another.
The practical test is evidence. Ask for the region and site choices available in the customer panel. Ask whether two instances can be placed in separate facilities. Ask where scheduled backups are stored. Ask where CDN logs and storage metadata are kept. Ask whether support engineers can access customer disks, snapshots, keys or consoles, and from where. Ask whether a full export can be completed without keeping the account active for another long billing cycle. A provider that can answer these questions calmly is easier to trust than one that relies only on broad locality language.
The main failure paths run through rack, route, hardware stock, account status and migration
The most likely Cloud.ir failure that a customer should plan for is not a dramatic total outage. It is a partial failure that sits between contractual layers. A VM may be fine while an upstream route is degraded. A route may be fine while storage performance collapses. A backup may exist while restore throughput is too slow. A CDN may answer static content while dynamic functions fail. A customer panel may be reachable while payment prevents a rebuild. These middle states are where customers learn whether the service has enough operational detail behind it.
The rack path begins with physical hardware. A host failure can move a well-designed VM to another host if there is shared storage, spare host capacity and functioning orchestration. It can also leave a customer waiting for a part if local storage, bare-metal allocation or a non-redundant component is involved. Public Cloud.ir pages do not disclose the hypervisor platform, host class, local-versus-shared storage choices or spare-hardware policy.
Customers should ask what happens when a physical server fails, which services restart automatically, which require a ticket, and whether there is a guaranteed maximum time to rebuild on equivalent hardware.
The upstream path begins with AS60077's visible dependence on AS43754. If AS43754 filters a route, has an edge issue, changes a policy or suffers a broader incident, AS60077 customer services may be affected even when customer VMs are powered. Because public data shows AS43754 as the observed upstream boundary for AS60077, the customer should ask whether the cloud ASN has separate physical edge routers, multiple handoffs into AS43754, any direct external transit, and recent failover tests. It is not enough to say the parent network has many neighbors; the relevant question is what happens at the cloud edge.
The hardware-stock path is about growth and repair. Hourly cloud pricing and instant scaling are useful only if there are spare CPU cores, RAM, disks, addresses and switch ports. A buyer planning a campaign, event, launch or migration should ask whether capacity can be reserved, whether large increases require notice, and whether the provider can place extra capacity in a separate failure domain. A smaller buyer should ask a simpler question: if my current host fails, is there already enough spare room to restart my server elsewhere?
The support path is about time and authority. Cloud.ir says cloud-server customers can submit tickets at any hour. That is better than a narrow business-hours channel, but the customer still needs escalation targets. Who can change a BGP route? Who can authorize a rack visit? Who can restore a deleted backup? Who can reverse an account suspension? Who can explain a legal or security order? If the first-line support team can only forward a request, the repair time includes every handoff.
The migration path is the final safety net. A customer can tolerate weaker evidence if they can leave quickly. That requires current backups, exportable images or files, documented IP and DNS change procedures, known TTLs, account access that remains available during billing disputes, and enough bandwidth to move data. It also requires avoiding hidden lock-in: private network addresses that cannot be reproduced, storage features without an export path, CDN rules that cannot be recreated elsewhere, or snapshots that cannot be downloaded.
The public Cloud.ir pages describe rebuild, backups and account operations, but they do not disclose full portability terms. Production users should get them before they need them.
What a buyer should verify before relying on Cloud.ir
The first verification task is placement. Cloud.ir should be able to say which services can be placed in which Iranian locations, whether a location is a distinct building, hall or logical label, and whether two instances can be kept apart. If the answer is "our cloud handles it," the customer should ask for a failure-domain description in plain language. A small provider does not need hyperscale terminology to be reliable, but it does need honest boundaries.
The second task is network diversity. AS60077 is visible and legitimate, and AS43754 is a substantial parent network. That is a good starting point. It is not the same as proving that customer traffic can survive an AS43754 edge event. Ask for the normal path, the backup path, the edge-router design, the DDoS handling boundary, the RPKI and route-filtering practices, and whether Cloud.ir can temporarily announce a customer prefix or move a public address during an incident. For most VPS customers the answer will be no, but the question clarifies the dependency.
The third task is restore evidence. Backups are listed as product features, and the price page distinguishes weekly, three-day and daily backup components. The customer should ask how snapshots are scheduled, what is captured, what is not captured, where backup copies are stored, how long they are retained, what restore time is typical, whether a restore can target another site, and whether the provider has recent restore test results. A backup that cannot leave the damaged boundary is insurance only against a narrow class of failures.
The fourth task is maintenance and exclusions. The SLA excludes announced maintenance and critical patches from the uptime calculation. Ask how maintenance is announced, how much notice is given, whether emergency work can occur without normal notice, whether the customer can choose a window, and whether multiple customer resources are maintained together. A maintenance window is not bad; an unclear window is bad.
The fifth task is account continuity. Since nonpayment is outside the SLA penalty framework, production buyers should understand wallet funding, invoice timing, suspension thresholds, appeal paths and data retention after suspension. This is especially important for teams outside Iran, teams with procurement delays, and teams whose payment access depends on one person. Billing failure can become an avoidable outage.
The sixth task is exit. Export one small server image, restore one backup into a clean instance, move one DNS record away from the CDN, recreate one firewall policy elsewhere and document the time. These tests do not need to be large to be revealing. They show whether the provider's abstractions help the customer recover or mainly help the customer stay.
The operating thesis: real service, strong network visibility, incomplete physical proof
CLOUD Asre Dadeha Asiatech deserves a higher confidence level than a company with only a stale routing entry. Cloud.ir is active, the service catalogue is specific, the price page exposes concrete resource packages, the SLA is public, and RIPE records place AS60077 in the public routing table as AT-CLOUD Asre Dadeha Asiatech. DNS for the company site points into AS60077. AS60077 has a visible address estate, and its parent-network dependency on AS43754 is observable rather than hidden.
That does not make the service fully transparent. The public record does not show the exact data-center placement of customer workloads, the number of available hosts, the amount of spare hardware, the real-world restore time, the location of every backup, the physical diversity of routes, the route failover design at the cloud edge, or the account and migration terms a customer would rely on during a dispute. Cloud.ir's own marketing makes strong statements about availability and data persistence, while its SLA draws practical boundaries around what is covered.
The right reading is therefore balanced. The product exists. The network is visible. The physical dependency is real. A buyer can reasonably consider Cloud.ir for workloads that benefit from Iranian data-center proximity, ASIATECH's domestic infrastructure and a local cloud control panel. The same buyer should avoid treating the cloud label as proof of multi-site resilience, route diversity or seamless exit. Those are engineering and contractual facts that have to be obtained, tested and written down.
For a small website, the remaining uncertainty may be acceptable if backups are independent and DNS can move quickly. For a high-traffic Iranian media property, the CDN and domestic hosting may be valuable, but the operator should test origin failure, cache behavior and support escalation before a launch. For regulated or cross-border data, the key questions are locality, authority exposure, support access and export rights. For any production customer, the final discipline is the same: buy the cloud service, but audit the rack, route, repair and migration story behind it.