CLOUD Asre Dadeha Asiatech vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• Cloud.ir dá à CLOUD Asre Dadeha Asiatech uma superfície de varejo real: o site oferece servidores em nuvem, planos VPS, armazenamento em nuvem, CDN, comutação em nuvem, serviços de data center em nuvem, um painel do cliente, preços publicados e um SLA, e seu rodapé afirma que o site pertence à Asre Dadeha Asiatech.
• A âncora física é mais estreita que a linguagem do produto. Cloud.ir afirma que sua infraestrutura reside nos data centers da ASIATECH no Irã, e a página sobre diz que Cloud.ir opera desde o ano iraniano 1399 com mais de 20 produtos em nuvem, mas as páginas públicas não identificam o rack exato, a colocação cidade por cidade, a topologia de energia ou os resultados de teste de restauração por trás de cada carga de trabalho do cliente.
• A evidência de rede é forte na camada de plano de controle. O RIPE RDAP nomeia AS60077 como AT-CLOUD para Asre Dadeha Asiatech, RIPEstat mostrou 18 prefixos IPv4 e 14.080 endereços IPv4 anunciados pela AS60077 em 12 de julho de 2026, e o DNS paracloud.irmapeou para um prefixo AS60077. A mesma visualização do RIPE mostrou um vizinho observado no lado esquerdo para AS60077: AS43754, ASIATECH Asiatech Data Transmission company.
• Portanto, a questão de compra não é se existe um produto de nuvem. É se um determinado cliente pode verificar o posicionamento, a margem de capacidade, as rotas independentes, a localidade do backup, a escalada do suporte, as exclusões de manutenção, a continuidade de faturamento e os direitos de saída antes que um rack, upstream, estoque de hardware ou evento de conta transforme um servidor virtual em uma dependência física.

A vitrine é pública, mas a promessa de infraestrutura ainda é em camadas

Cloud.ir não é uma página de marca estacionada. Apágina inicial do Cloud.irapresenta servidores em nuvem, serviços de data center em nuvem, comutação em nuvem, CDN, armazenamento em nuvem, gerenciamento de domínio em nuvem, uma página de preços de serviços, páginas de suporte e um caminho de login do cliente. A mesma página contém um número de telefone, um endereço de e-mail, um endereço de escritório em Teerã e uma declaração no rodapé de que os direitos materiais e intelectuais do site pertencem à Asre Dadeha Asiatech. Para este perfil, isso importa porque a identidade da empresa está ligada a uma superfície de serviço ativa, não meramente a um registro de roteamento.

Apágina sobreadiciona um histórico de serviço. Diz que Cloud.ir começou a operar no ano iraniano 1399 e se tornou um dos principais provedores de serviços em nuvem do Irã, com mais de 20 produtos em nuvem. Os grupos de produtos mencionados incluem distribuição de conteúdo, computação em nuvem, segurança em nuvem, armazenamento em nuvem, rede em nuvem e um marketplace em nuvem. Essas afirmações são declarações da empresa, não medições independentes de capacidade, mas esclarecem a postura comercial básica: CLOUD Asre Dadeha Asiatech vende capacidade hospedada para clientes que não desejam comprar e operar sua própria infraestrutura física.

A oferta de varejo também é específica o suficiente para ser inspecionada. Apágina do servidor em nuvemdiz que os clientes podem criar um servidor em nuvem rapidamente, pagar pelos recursos que usam, alterar recursos, configurar rede, adicionar ou alterar endereços IP, monitorar o uso de recursos e rede, usar um firewall em nuvem e agendar backups. A mesma página descreve opções de servidor Linux, Windows e MikroTik e diz que o suporte para clientes de servidor em nuvem está disponível por meio de abertura de chamados 24 horas por dia. Um comprador deve tratar isso como promessas de produto que precisam de confirmação contratual e teste, mas ainda são mais concretas do que a linguagem genérica de "nuvem".

Apágina de preçosdo Cloud.ir torna o produto ainda mais inspecionável. Ela lista nomes de pacotes VPS como AT-VPS-B2, AT-VPS-G1 e AT-VPS-A2 com memória, CPU, disco, um endereço IP gratuito, tráfego base, suporte a IP adicional, suporte a reconstrução e IPv6 mostrados nos cartões do pacote. Também mostra medição por hora para recursos de servidor em nuvem, como memória, CPU, disco, IP, tráfego recebido e níveis de backup. Páginas de preços não são diagramas de engenharia, mas expõem como o serviço é empacotado: o cliente está comprando unidades finitas de computação, armazenamento, endereço e tráfego que devem existir em algum lugar antes que o painel de controle possa alocá-las.

A empresa também descreve serviços de nível superior em torno da mesma infraestrutura. Apágina do data center em nuvemcomercializa gerenciamento de dados seguro e fácil, escalabilidade, monitoramento, virtualização, conteinerização e backup agendado. Apágina de armazenamento em nuvemapresenta armazenamento escalável, compartilhamento controlado e gerenciamento de níveis de acesso. Apágina da CDNdescreve a distribuição de conteúdo por meio de modos doméstico, centralizado e internacional, com as solicitações dos usuários atendidas por locais de data center geograficamente mais próximos. Apágina do comutador em nuvemapresenta rede virtual gerenciada entre servidores em nuvem e data centers. Cada produto reduz a necessidade do cliente de possuir equipamentos; cada um também introduz uma dependência das decisões de posicionamento, design de rede e suporte do provedor.

Esse é o quadro útil para o resto do artigo. A CLOUD Asre Dadeha Asiatech não é uma concha misteriosa, mas a superfície de serviço visível não elimina a necessidade de testar as camadas inferiores. Um servidor em nuvem pode ser provisionado em segundos apenas quando o provedor já possui capacidade de host adequada, armazenamento, endereços públicos, acessibilidade de rede e autorização de faturamento.

Uma CDN pode rotear uma solicitação para uma borda mais próxima apenas quando essa borda existe, tem conteúdo atualizado, tem capacidade de cache e trânsito suficiente e ainda pode alcançar a origem quando o próprio servidor do cliente está indisponível. Um backup só importa se puder ser restaurado fora da falha que danificou a carga de trabalho primária. As páginas públicas mostram a oferta; elas não provam por si mesmas todas as afirmações de resiliência que um comprador de produção precisa.

A âncora física é a capacidade de data center da ASIATECH no Irã

A afirmação física mais forte do Cloud.ir é explícita: sua infraestrutura em nuvem reside nos data centers da ASIATECH. Apágina do servidor em nuvemdiz que a infraestrutura dos serviços em nuvem do Cloud.ir é implantada nos data centers da ASIATECH, que descreve como a maior rede de data centers do Irã. Ela lista o uso de tecnologias modernas, certificações ISO27001 e TIA-942 Tier 2 e Tier 3, sistemas de segurança, conectividade de rede estável, alto consumo de banda no Irã e suporte a energia AC e DC. Apágina do data center em nuvemrepete o mesmo enquadramento do data center da ASIATECH e diz que os data centers do Cloud.ir em todo o Irã fornecem infraestrutura para clientes que estão iniciando a migração para a nuvem.

Apágina sobreé semelhante. Diz que os data centers do Cloud.ir estão distribuídos por todo o Irã e que sua infraestrutura se baseia em data centers da ASIATECH que cobrem instalações grandes e poderosas com padrões globais. Também lista suporte AC e DC. Essas afirmações são importantes porque movem o serviço da mera abstração de varejo para um limite operacional de instalação nomeada: a marca de nuvem depende do patrimônio de data centers e da rede da ASIATECH, não de uma região hyperscale ultramarina não nomeada.

Fora das páginas da empresa, o registro público fornece um contexto mais antigo, mas útil, para esse patrimônio. O Data Center Dynamics reportou em julho de 2017 que a AsiaTech abriu umdata center de 700 metros quadrados na Milad Tower, no oeste de Teerã. Esse relatório descreveu a AsiaTech como uma empresa privada estabelecida em 2003, disse que obteve uma licença em 2013 para hospedagem, servidores dedicados e compartilhados e colocation, e afirmou que operava cinco data centers e conectava mais de 430 cidades em todo o Irã. O DataCenterMap atualmente lista oAsiatech Milad Tower Data Centere oAsiatech Azadegan Data Centerem Teerã, enquanto sua página de especificações da Milad Tower diz que nenhum dado de capacidade, energia, conformidade, segurança ou construção foi fornecido pela Asiatech.

Essas referências externas devem ser tratadas com cuidado. Elas corroboram que a ASIATECH tem sido associada a instalações nomeadas em Teerã e a um negócio de data center mais amplo. Não provam qual instalação atende a uma VM específica do Cloud.ir, borda da CDN, bucket de armazenamento ou cópia de backup em julho de 2026. Também não provam que a condição da instalação de 2017, a contagem de racks, o projeto de energia ou o número de clientes permanecem inalterados. O histórico de instalações é uma evidência útil de uma empresa real de infraestrutura; não é um mapa de posicionamento atual.

Essa distinção importa para os clientes. Um comprador pode ouvir "data centers em todo o Irã" e presumir que dois servidores pedidos da mesma conta são colocados em edifícios separados. Eles podem não estar. Eles podem cair no mesmo host, dois hosts em um rack, dois racks atrás de uma unidade de energia, dois salões em um edifício, ou edifícios separados cuja fibra metropolitana ou borda upstream ainda converge. Por outro lado, o provedor pode ter melhor separação do que as páginas públicas divulgam. As páginas públicas não resolvem o ponto.

O cliente tem que perguntar sobre controles de posicionamento, regras de anti-afinidade, sites nomeados ou códigos de site, localização do backup e o que Cloud.ir significa por "data center" para cada nível de serviço.

Energia e mão de obra de reparo fazem parte da mesma questão. Cloud.ir pode dizer com justiça que o uso da nuvem evita o ônus do cliente de comprar equipamentos e manter uma sala de servidores. Isso não faz a manutenção física desaparecer. Alguém ainda tem que substituir discos, fontes de alimentação, placas de linha e memória; alguém ainda tem que agendar o trabalho elétrico; alguém ainda tem que testar geradores, baterias, sistemas de refrigeração e combate a incêndio; alguém ainda tem que receber um alerta e alcançar o rack.

Um cliente não precisa saber de todos os detalhes privados do projeto da instalação da ASIATECH, mas precisa saber quais promessas de disponibilidade sobrevivem a um evento de rack, uma janela de manutenção de energia, uma falha de armazenamento e uma escassez de hardware de reposição.

AS60077 é visível, e a rede pai é a dependência óbvia

O registro de rede dá à CLOUD Asre Dadeha Asiatech uma segunda âncora concreta. O RIPE RDAP identificaAS60077como AT-CLOUD e o vincula à Asre Dadeha Asiatech por meio de ORG-ADA42-RIPE. A mesma resposta do RDAP inclui contatos administrativos e técnicos do NOC da Asiatech em um endereço na Miremad Street, em Teerã, além de uma função de abuso da Asiatech. Isso é uma evidência de registro de um sistema autônomo real e uma cadeia de contatos operacionais. Não descreve servidores individuais, clientes ou tempo de atividade, mas confirma que o serviço em nuvem tem seu próprio identificador de rede.

OAS overviewdo RIPEstat para AS60077 relatou o titular como "AT-CLOUD Asre Dadeha Asiatech" e mostrou que foi anunciado no momento da consulta em 12 de julho de 2026. Suavisualização de status de roteamentomostrou 18 prefixos IPv4 e 14.080 endereços IPv4 visíveis a partir de AS60077, com a primeira observação de prefixo datando de 2014 e a observação mais recente no momento da consulta. A mesma visualização do RIPE mostrou alta visibilidade do coletor IPv4 e nenhum espaço IPv6 visível nessa resposta de status específica.

O serviço ativo também aponta de volta para AS60077. Avisualização da cadeia de DNSdo RIPEstat paracloud.irretornou193.151.157.174para o nome apex, e avisualização de informações de redepara esse endereço o mapeou para193.151.157.0/24e AS60077. Isso não prova que toda carga de trabalho do cliente é executada dentro do mesmo prefixo; mostra que a própria presença web pública da empresa é servida a partir do ASN da nuvem.

A dependência está nos dados de vizinhança. Avisualização de vizinhos ASNdo RIPEstat para AS60077 mostrou um vizinho observado no lado esquerdo: AS43754. OAS overviewdo RIPEstat para AS43754 nomeia essa rede como "ASIATECH Asiatech Data Transmission company." Suavisualização de status de roteamentomostrou uma pegada de rede muito maior no mesmo momento da consulta: 316 prefixos IPv4, 209.920 endereços IPv4 e 86 vizinhos observados. A imagem é direta: o ASN da nuvem é visível, mas sua fronteira upstream pública parece ser a rede maior da ASIATECH.

As amostras do looking-glass tornam a visível em caminhos reais. Osdados do looking-glassdo RIPEstat para193.151.128.0/22, um dos prefixos anunciados do AS60077, incluíram caminhos terminando em AS43754 AS60077. Algumas amostras globais também mostraram upstreams anteriores antes do AS43754, mas a dependência consistente próxima à origem permaneceu o AS43754. Isso não é surpreendente para um negócio de nuvem ligado ao mesmo grupo de infraestrutura corporativa, mas importa porque uma falha nessa fronteira pode afetar muitos serviços ao mesmo tempo.

Isso não significa que AS60077 é frágil. Um único relacionamento upstream visível pode ser perfeitamente razoável quando a rede pai tem alcance de operadora, disciplina operacional e redundância suficiente nos bastidores. Também não significa que AS43754 tenha apenas um caminho externo; RIPEstat mostrou muitos vizinhos para AS43754. O ponto importante é mais estreito: as evidências públicas de BGP não provam que o próprio AS60077 tenha múltiplos upstreams independentes, entradas físicas separadas, roteadores de borda separados ou failover independente fora do AS43754.

Os clientes devem tratar AS43754 como o limite operacional upstream visível, a menos que Cloud.ir forneça evidências específicas do produto de separação adicional.

O RPKI responde a uma pergunta diferente. Avalidação RPKIdo RIPEstat para193.151.128.0/22originado por AS60077 retornou status válido com autorizações de origem de rota cobrindo AS60077. Isso é higiene de roteamento positiva: suporta a legitimidade da origem da rota. Não prova capacidade de tráfego, diversidade de rotas, continuidade de energia, qualidade de isolamento do cliente, capacidade de recuperação de backup ou resposta de suporte. Uma rota válida por RPKI ainda pode ser retirada por engano, filtrada por um upstream, isolada por uma falha de cross-connect ou tornada inútil por uma paralisação do lado do servidor.

Capacidade instalada não é a mesma coisa que capacidade de nuvem utilizável

Compradores de nuvem tendem a ver controles deslizantes de recursos. O operador vê inventário. CPU, memória, disco, espaço de backup, endereços públicos, estado do firewall, monitoramento, capacidade de porta, consumo de energia do host e tempo da equipe precisam estar alinhados antes que um controle deslizante de recursos se torne um servidor em funcionamento. As páginas públicas do Cloud.ir são úteis porque revelam alguns desses ingredientes, mas não revelam o nível de estoque.

Apágina de preçoslista pacotes com quantidades fixas de memória, processador, disco e tráfego. Também lista componentes horários separados para infraestrutura em nuvem, incluindo agendamentos de backup. Isso é suficiente para mostrar que Cloud.ir vende o serviço como um pool de recursos com preço. Não é suficiente para mostrar quantos hosts estão no pool, quantos estão reservados para failover, qual desempenho de disco está disponível sob contenção, se o espaço de backup fica em um site separado, quão rápido uma instância danificada pode ser recriada, ou se o provedor pode satisfazer um pedido grande durante uma escassez de hardware.

Os números de rede fornecem uma borda externa, não uma contagem de servidores. Alista de prefixos anunciadosdo RIPEstat para AS60077 mostrou 18 prefixos IPv4 no período de consulta recente, incluindo várias faixas/22,/23e/24. Os 14.080 endereços IPv4 vistos na visualização de status de roteamento são capacidade real de endereço público, mas endereços não são iguais a máquinas virtuais. Alguns endereços servem a roteadores, balanceadores de carga, firewalls, servidores de nomes, instâncias de clientes, funções de gerenciamento ou pools sobressalentes. Um único servidor pode usar vários endereços; muitos serviços podem ficar atrás de um endereço; endereços não utilizados podem coexistir com um cluster de computação completo.

A mesma cautela se aplica às referências IPv6 do Cloud.ir. A página de preços mostra IPv6 nos cartões de pacote VPS. A consulta de status de roteamento do RIPE usada aqui não mostrou espaço IPv6 visível para AS60077 no momento da consulta. Isso não prova que o IPv6 está ausente do produto: o IPv6 pode ser fornecido por meio de um arranjo diferente, exposto apenas em certos planos, visível em outros coletores ou representado de forma diferente em sites de roteamento de terceiros.

Isso significa que um cliente que precisa de IPv6 nativo deve testar a alocação real, roteamento, comportamento do firewall, DNS reverso, acessibilidade de backup e escalada de suporte, em vez de confiar apenas em um rótulo de pacote.

A própria linguagem de produto do Cloud.ir também separa capacidade de resiliência. A página do servidor em nuvem diz que os recursos podem ser aumentados ou diminuídos instantaneamente e que, quando um servidor fica indisponível, os dados são automaticamente disponibilizados a partir de outro servidor. A página do data center em nuvem diz que os dados armazenados são mantidos em múltiplos data centers e que outros data centers preservam a conectividade se um tiver problemas. Essas são afirmações importantes. Elas também precisam de precisão. Quais serviços são cobertos?

A transferência é automática para todos os tipos de servidor ou apenas para dados protegidos por uma camada de armazenamento específica? Dois data centers são usados por padrão ou apenas se o cliente os configurar? O backup é quente, morno ou frio? Existe um tempo de recuperação testado? Os créditos estão disponíveis se a automação falhar?

Sem essas respostas, um comprador deve manter "instalado" e "utilizável" separados. Capacidade instalada é a coleção de hosts, racks, arrays de armazenamento, links e endereços que o provedor possui ou aluga. Capacidade utilizável é o que o cliente pode alocar agora sem sobrecarregar um host, esgotar um pool de endereços, violar uma regra de posicionamento ou depender de um técnico cansado para trocar uma peça depois da meia-noite. As páginas públicas do Cloud.ir provam um produto de nuvem com preço e uma rede visível. Elas não divulgam o suficiente para converter isso em uma reserva de capacidade.

O SLA restringe a promessa exatamente nos pontos que uma falha testará

Cloud.ir publica umapágina de SLA, e isso é uma coisa boa para os clientes porque move parte da conversa sobre risco para o texto público. A parte mais importante da página não é um grande número de uptime; são as limitações. A página diz que a garantia de uptime se aplica apenas à disponibilidade de rede e servidor em nuvem durante a operação normal. Exclui o software do servidor do cliente, sistemas operacionais, problemas de configuração, ataques de negação de serviço contra um servidor em nuvem, servidores suspensos ou parados, interrupções que não sejam de rede ou servidor host, e manutenção ou patches críticos anunciados com antecedência.

A mesma página define o tempo médio para reparo ou recuperação como o tempo médio para restaurar o serviço com base em acordo entre provedor e cliente. Em seguida, lista casos que não incorrem em penalidades, incluindo força maior, equipamento do cliente, paralisação planejada, interrupção solicitada pelo cliente, violações da lei ou do SLA, não pagamento e ordens de autoridades judiciais ou de segurança. Essas exclusões não são incomuns em hospedagem, mas são decisivas para um cliente tentando medir risco. Elas movem muitas interrupções reais para fora de um simples título de uptime.

Considere uma falha de software. Se o sistema operacional convidado quebrar após uma atualização do cliente, o texto do SLA sugere que o problema está fora da garantia de uptime do provedor, mesmo que o cliente experimente perda total do serviço. Isso é razoável se Cloud.ir vendeu computação não gerenciada, mas significa que o comprador precisa de direitos de recuperação separados: acesso ao console, boot de resgate, snapshots, exportação de imagem, rollback, reconstrução e limites de suporte claros. Um "servidor em nuvem" não é continuidade de aplicação gerenciada, a menos que o contrato diga isso.

Considere um evento de negação de serviço. A página do servidor em nuvem promove controles de firewall em nuvem e relatórios de ataques. A página do SLA exclui ataques de negação de serviço contra o servidor em nuvem da garantia de uptime. O produto ainda pode ajudar a mitigar o tráfego, mas o cliente não deve assumir que toda interrupção induzida por ataque cria compensação.

A questão se torna prática: qual volume de tráfego o firewall pode lidar, o que é filtrado na borda da nuvem, o que chega à instância, quem pode alterar filtros durante um ataque e quando o Cloud.ir pode suspender ou limitar a taxa de um alvo para proteger outros clientes?

Considere o faturamento. A exclusão do SLA por não pagamento é comum, mas o risco operacional não é trivial. Uma carteira pré-paga, um pagamento doméstico falhado, um problema com cartão bancário corporativo ou uma fatura contestada podem se tornar um evento de infraestrutura se os servidores forem suspensos antes que um operador resolva a conta.

Uma empresa usando Cloud.ir para produção deve perguntar quantos lembretes são enviados, qual período de carência se aplica, qual retenção de dados ocorre após a suspensão, se os snapshots permanecem acessíveis e se o suporte pode preservar temporariamente o serviço enquanto as evidências de faturamento são revisadas.

Considere ordens de autoridades públicas. O SLA diz que o tempo de inatividade causado por autoridades judiciais ou de segurança está fora do quadro de penalidades. Isso é uma questão de localidade, não um julgamento sobre o provedor. Se as cargas de trabalho, backups e contas de suporte estão dentro de uma jurisdição, o cliente precisa entender como ordens legais ou políticas podem afetar a disponibilidade, acesso a dados, serviço de domínio e comunicações com o cliente. A resposta pode ser aceitável para um site iraniano doméstico e inaceitável para um serviço transfronteiriço com obrigações de conformidade conflitantes.

A mesma localidade física pode ser uma força para latência e uma restrição para governança.

O SLA, portanto, aguça as perguntas do comprador. Não torna Cloud.ir mais fraco; torna a forma do serviço mais conhecível. O cliente deve distinguir disponibilidade de rede, disponibilidade do host, saúde do convidado, integridade do armazenamento, capacidade de recuperação de backup, comportamento da CDN, status da conta e restrições legais. O SLA público não colapsa essas camadas em uma única promessa. Nem um comprador de produção deveria.

CDN, armazenamento e comutação em nuvem expandem o raio de explosão além do conjunto de recursos

Os serviços de CDN, armazenamento e rede virtual do Cloud.ir são úteis porque podem reduzir a carga em um único servidor de origem e dar aos clientes mais opções de arquitetura. Eles também tornam o mapa de dependências mais amplo. Apágina da CDNdiz que a distribuição doméstica pode responder a solicitações por meio de data centers locais e criar tráfego com metade do preço para usuários domésticos; também descreve o roteamento de usuários para servidores mais próximos, compactação e cache de conteúdo, monitoramento de solicitações e respostas, limites de acesso por país e proteção contra ataques. Essa é uma história de produto real, mas transforma um site em uma cadeia: DNS, borda da CDN, estado do cache, acessibilidade da origem, tratamento de certificados, configuração da conta e suporte precisam funcionar juntos.

Se o servidor de origem falhar, a CDN pode continuar servindo conteúdo estático em cache. Também pode servir conteúdo desatualizado, falhar em rotas dinâmicas ou aumentar as taxas de erro quando as falhas de cache atingem uma origem não saudável. Se uma borda da CDN perder a acessibilidade upstream, os usuários em uma região podem ver erros enquanto outros não. Se as regras de acesso estiverem mal configuradas, um recurso de localidade pode se tornar um problema de disponibilidade.

O cliente precisa de controles de purga de cache, comportamento do escudo de origem, logs, regras de fail-open ou fail-closed, visibilidade de renovação de certificados e uma maneira de mover o DNS para longe se o serviço da CDN se tornar a falha.

A oferta de armazenamento tem uma forma de risco diferente. Apágina de armazenamento em nuvemdiz que o serviço permite que os clientes escalem a capacidade, gerenciem arquivos, gerenciem chaves de acesso, conectem armazenamento a domínios, compartilhem arquivos e definam níveis de acesso. Também diz que os dados são protegidos por distribuição em vários servidores. Isso é valioso, mas a durabilidade do armazenamento não é visível do exterior. Um cliente precisa saber se o serviço é armazenamento de objetos, armazenamento em bloco, armazenamento de arquivos ou uma mistura; o que significa replicação; se as réplicas estão em uma sala ou em vários locais; como as exclusões são protegidas; se o versionamento existe; como as chaves são rotacionadas; como a recuperação é testada; e quão rápido uma exportação completa pode ser concluída.

O serviço de comutador em nuvem é igualmente importante. Apágina do comutador em nuvemdescreve rede gerenciada entre servidores em nuvem e data centers, roteando tráfego e criando redes privadas. Também diz que o serviço pode identificar recursos alternativos disponíveis e comutar automaticamente durante a interrupção. Esse tipo de recurso pode reduzir a recuperação manual se for bem implementado. Também pode se tornar um ponto único de mudança se uma configuração incorreta de rede privada isolar um grupo de servidores que de outra forma permanecem saudáveis.

O padrão mais profundo é que um recurso pode ser tanto uma camada de resiliência quanto uma nova dependência. Os backups protegem os dados apenas se forem armazenados fora do limite de falha e puderem ser restaurados rapidamente. A CDN protege a origem apenas se o conteúdo puder ser servido corretamente quando a origem estiver fraca. A rede virtual protege o tráfego leste-oeste apenas se o plano de controle e a estrutura de comutação permanecerem saudáveis. Os firewalls em nuvem protegem os clientes apenas se as alterações de filtro puderem ser feitas com segurança sob pressão.

O cliente não deve perguntar se esses recursos existem em abstrato. Eles devem perguntar como cada recurso se comporta quando um host, rack, rota, cluster de armazenamento, conta ou fila de suporte já está falhando.

Localidade é um atributo do produto, não um slogan

A localidade dos dados é uma das razões mais fortes para comprar da Cloud.ir. As páginas da empresa colocam a infraestrutura em nuvem nos data centers da ASIATECH no Irã, a página da CDN enfatiza as opções de distribuição doméstica, e as evidências de rede mostram o site de nuvem público no AS60077 com uma rede pai iraniana da ASIATECH. Para usuários e empresas iranianas, isso pode significar menor latência, alinhamento de pagamento doméstico, linguagem de suporte familiar, economia de tráfego local e um provedor cujo patrimônio físico está próximo do público-alvo.

Mas a localidade tem que ser definida por serviço. Um servidor virtual pode ser executado no Irã enquanto um relay de e-mail, console de gerenciamento, serviço de análise, cópia de backup ou anexo de suporte segue outro caminho. Um produto de CDN pode oferecer modos de distribuição doméstico e internacional. Um serviço de armazenamento pode replicar em vários servidores sem dizer se esses servidores estão em edifícios separados. Um cliente não pode inferir a localização exata de cada cópia de dados a partir do endereço da empresa, do domínio de topo, do nome do sistema autônomo ou da frase "data centers em todo o Irã".

A própria linha de região do Cloud.ir para um perfil voltado ao comprador pode ser global porque a acessibilidade IP é global e os clientes em nuvem podem estar em qualquer lugar com uma conta funcionando e caminho de rede. Isso é diferente de dizer que a empresa opera regiões globais. As evidências de produto público revisadas aqui apontam mais fortemente para infraestrutura iraniana e o patrimônio de data center doméstico da ASIATECH. Se um cliente precisa de um serviço apenas no Irã, deve solicitar uma declaração por escrito sobre a localidade de computação, armazenamento, backup, log e acesso de suporte.

Se um cliente precisa de continuidade em vários países, deve perguntar se o próprio Cloud.ir fornece isso ou se o cliente deve construir com outro provedor.

A localidade também muda a resposta a incidentes. Um site de conteúdo iraniano doméstico pode preferir o comportamento da CDN doméstica do Cloud.ir e as instalações da ASIATECH porque a maioria dos usuários está perto desses caminhos. Um fornecedor de SaaS internacional pode se preocupar com acesso a pagamentos, exposição a sanções, latência de usuários estrangeiros, filtragem de rotas, resolução de disputas e a capacidade de exportar dados sob pressão.

Um usuário do setor público ou regulado pode valorizar o controle local da instalação, mas precisa de uma declaração mais estrita sobre quem pode acessar dados, onde os snapshots ficam e como as ordens das autoridades são tratadas. A mesma infraestrutura pode ser bem adequada para um cliente e inadequada para outro.

O teste prático é a evidência. Peça as opções de região e site disponíveis no painel do cliente. Pergunte se duas instâncias podem ser colocadas em instalações separadas. Pergunte onde os backups agendados são armazenados. Pergunte onde os logs da CDN e os metadados de armazenamento são mantidos. Pergunte se os engenheiros de suporte podem acessar discos, snapshots, chaves ou consoles do cliente, e de onde. Pergunte se uma exportação completa pode ser concluída sem manter a conta ativa por outro longo ciclo de faturamento.

Um provedor que pode responder a essas perguntas calmamente é mais fácil de confiar do que um que depende apenas de linguagem ampla de localidade.

Os principais caminhos de falha passam por rack, rota, estoque de hardware, status da conta e migração

A falha mais provável do Cloud.ir que um cliente deve planejar não é uma interrupção total dramática. É uma falha parcial que fica entre camadas contratuais. Uma VM pode estar bem enquanto uma rota upstream está degradada. Uma rota pode estar bem enquanto o desempenho do armazenamento colapsa. Um backup pode existir enquanto a taxa de transferência de restauração é muito lenta. Uma CDN pode responder conteúdo estático enquanto funções dinâmicas falham. Um painel do cliente pode estar acessível enquanto o pagamento impede uma reconstrução.

Esses estados intermediários são onde os clientes aprendem se o serviço tem detalhes operacionais suficientes por trás dele.

O caminho do rack começa com hardware físico. Uma falha de host pode mover uma VM bem projetada para outro host se houver armazenamento compartilhado, capacidade de host sobressalente e orquestração funcionando. Também pode deixar um cliente esperando por uma peça se envolver armazenamento local, alocação bare-metal ou um componente não redundante. As páginas públicas do Cloud.ir não divulgam a plataforma de hipervisor, classe de host, escolhas de armazenamento local versus compartilhado ou política de hardware sobressalente.

Os clientes devem perguntar o que acontece quando um servidor físico falha, quais serviços reiniciam automaticamente, quais exigem um chamado, e se há um tempo máximo garantido para reconstruir em hardware equivalente.

O caminho upstream começa com a dependência visível do AS60077 no AS43754. Se o AS43754 filtrar uma rota, tiver um problema de borda, alterar uma política ou sofrer um incidente mais amplo, os serviços do cliente do AS60077 podem ser afetados mesmo quando as VMs do cliente estão ligadas. Como os dados públicos mostram o AS43754 como o limite upstream observado para o AS60077, o cliente deve perguntar se o ASN da nuvem tem roteadores de borda física separados, múltiplas entregas para o AS43754, qualquer trânsito externo direto e testes recentes de failover.

Não basta dizer que a rede pai tem muitos vizinhos; a pergunta relevante é o que acontece na borda da nuvem.

O caminho do estoque de hardware é sobre crescimento e reparo. O preço por hora da nuvem e a escalabilidade instantânea são úteis apenas se houver núcleos de CPU, RAM, discos, endereços e portas de switch sobressalentes. Um comprador planejando uma campanha, evento, lançamento ou migração deve perguntar se a capacidade pode ser reservada, se grandes aumentos exigem aviso prévio e se o provedor pode colocar capacidade extra em um domínio de falha separado. Um comprador menor deve fazer uma pergunta mais simples: se meu host atual falhar, já há espaço sobressalente suficiente para reiniciar meu servidor em outro lugar?

O caminho do suporte é sobre tempo e autoridade. Cloud.ir diz que clientes de servidor em nuvem podem abrir chamados a qualquer hora. Isso é melhor do que um canal estreito de horário comercial, mas o cliente ainda precisa de alvos de escalada. Quem pode alterar uma rota BGP? Quem pode autorizar uma visita ao rack? Quem pode restaurar um backup excluído? Quem pode reverter uma suspensão de conta? Quem pode explicar uma ordem legal ou de segurança? Se a equipe de suporte de primeiro nível só pode encaminhar uma solicitação, o tempo de reparo inclui cada transferência.

O caminho da migração é a rede de segurança final. Um cliente pode tolerar evidências mais fracas se puder sair rapidamente. Isso exige backups atuais, imagens ou arquivos exportáveis, procedimentos documentados de IP e DNS, TTLs conhecidos, acesso à conta que permaneça disponível durante disputas de faturamento e largura de banda suficiente para mover dados. Também exige evitar dependências ocultas: endereços de rede privada que não podem ser reproduzidos, recursos de armazenamento sem um caminho de exportação, regras de CDN que não podem ser recriadas em outro lugar ou snapshots que não podem ser baixados.

As páginas públicas do Cloud.ir descrevem reconstrução, backups e operações de conta, mas não divulgam termos completos de portabilidade. Usuários de produção devem obtê-los antes de precisar deles.

O que um comprador deve verificar antes de confiar na Cloud.ir

A primeira tarefa de verificação é o posicionamento. Cloud.ir deve ser capaz de dizer quais serviços podem ser colocados em quais localizações iranianas, se uma localização é um edifício distinto, salão ou rótulo lógico, e se duas instâncias podem ser mantidas separadas. Se a resposta for "nossa nuvem cuida disso", o cliente deve pedir uma descrição do domínio de falha em linguagem simples. Um provedor pequeno não precisa de terminologia de hyperscale para ser confiável, mas precisa de limites honestos.

A segunda tarefa é a diversidade de rede. AS60077 é visível e legítimo, e AS43754 é uma rede pai substancial. Esse é um bom ponto de partida. Não é o mesmo que provar que o tráfego do cliente pode sobreviver a um evento de borda do AS43754. Pergunte pelo caminho normal, o caminho de backup, o design do roteador de borda, o limite de tratamento de DDoS, as práticas de RPKI e filtragem de rotas, e se Cloud.ir pode anunciar temporariamente um prefixo do cliente ou mover um endereço público durante um incidente. Para a maioria dos clientes VPS a resposta será não, mas a pergunta esclarece a dependência.

A terceira tarefa é a evidência de restauração. Os backups são listados como recursos do produto, e a página de preços distingue componentes de backup semanal, de três dias e diário. O cliente deve perguntar como os snapshots são agendados, o que é capturado, o que não é capturado, onde as cópias de backup são armazenadas, por quanto tempo são retidas, qual é o tempo típico de restauração, se uma restauração pode ser direcionada para outro site e se o provedor tem resultados recentes de teste de restauração. Um backup que não pode deixar o limite danificado é seguro apenas contra uma classe estreita de falhas.

A quarta tarefa é manutenção e exclusões. O SLA exclui manutenção anunciada e patches críticos do cálculo de uptime. Pergunte como a manutenção é anunciada, quanto aviso é dado, se o trabalho de emergência pode ocorrer sem aviso normal, se o cliente pode escolher uma janela e se vários recursos do cliente são mantidos juntos. Uma janela de manutenção não é ruim; uma janela pouco clara é ruim.

A quinta tarefa é a continuidade da conta. Como o não pagamento está fora do quadro de penalidades do SLA, os compradores de produção devem entender o financiamento da carteira, o tempo da fatura, os limites de suspensão, os caminhos de apelação e a retenção de dados após a suspensão. Isso é especialmente importante para equipes fora do Irã, equipes com atrasos de aquisição e equipes cujo acesso de pagamento depende de uma pessoa. A falha de faturamento pode se tornar uma interrupção evitável.

A sexta tarefa é a saída. Exporte uma imagem de servidor pequena, restaure um backup em uma instância limpa, mova um registro DNS para longe da CDN, recrie uma política de firewall em outro lugar e documente o tempo. Esses testes não precisam ser grandes para serem reveladores. Eles mostram se as abstrações do provedor ajudam o cliente a se recuperar ou principalmente ajudam o cliente a ficar.

A tese operacional: serviço real, forte visibilidade de rede, prova física incompleta

CLOUD Asre Dadeha Asiatech merece um nível de confiança maior do que uma empresa com apenas uma entrada de roteamento desatualizada. Cloud.ir está ativo, o catálogo de serviços é específico, a página de preços expõe pacotes de recursos concretos, o SLA é público, e os registros do RIPE colocam AS60077 na tabela de roteamento pública como AT-CLOUD Asre Dadeha Asiatech. O DNS do site da empresa aponta para AS60077. AS60077 tem um patrimônio de endereços visível, e sua dependência de rede pai no AS43754 é observável em vez de oculta.

Isso não torna o serviço totalmente transparente. O registro público não mostra o posicionamento exato do data center das cargas de trabalho do cliente, o número de hosts disponíveis, a quantidade de hardware sobressalente, o tempo real de restauração, a localização de cada backup, a diversidade física das rotas, o design de failover de rota na borda da nuvem, ou os termos de conta e migração em que um cliente confiaria durante uma disputa. O próprio marketing do Cloud.ir faz afirmações fortes sobre disponibilidade e persistência de dados, enquanto seu SLA traça limites práticos em torno do que é coberto.

A leitura correta é, portanto, equilibrada. O produto existe. A rede é visível. A dependência física é real. Um comprador pode considerar razoavelmente a Cloud.ir para cargas de trabalho que se beneficiam da proximidade do data center iraniano, da infraestrutura doméstica da ASIATECH e de um painel de controle de nuvem local. O mesmo comprador deve evitar tratar o rótulo de nuvem como prova de resiliência multissite, diversidade de rotas ou saída perfeita. Esses são fatos de engenharia e contratuais que precisam ser obtidos, testados e registrados.

Para um site pequeno, a incerteza remanescente pode ser aceitável se os backups forem independentes e o DNS puder se mover rapidamente. Para uma propriedade de mídia iraniana de alto tráfego, a CDN e a hospedagem doméstica podem ser valiosas, mas o operador deve testar a falha de origem, o comportamento do cache e a escalada de suporte antes de um lançamento. Para dados regulados ou transfronteiriços, as questões-chave são localidade, exposição à autoridade, acesso de suporte e direitos de exportação.

Para qualquer cliente de produção, a disciplina final é a mesma: compre o serviço de nuvem, mas audite a história do rack, rota, reparo e migração por trás dele.