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

Resumo

• O Cloud.ir dá à CLOUD Asre Dadeha Asiatech uma verdadeira superfície de varejo: o site oferece servidores em nuvem, planos VPS, armazenamento em nuvem, CDN, cloud switching, serviços de data center em nuvem, painel do cliente, preços publicados e um SLA, e seu rodapé indica que o site pertence à Asre Dadeha Asiatech.
• A ancoragem física é mais estreita do que a linguagem do produto. O Cloud.ir indica que sua infraestrutura se baseia nos data centers da ASIATECH no Irã, e a página "sobre" indica que o Cloud.ir opera desde o ano iraniano 1399 com mais de 20 produtos de 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.
• As evidências de rede são sólidas no nível do plano de controle. O RIPE RDAP nomeia a AS60077 como AT-CLOUD da Asre Dadeha Asiatech, o RIPEstat mostrou 18 prefixos IPv4 e 14.080 endereços IPv4 anunciados pela AS60077 em 12 de julho de 2026, e o DNS paracloud.ircorrespondia a um prefixo da AS60077. A mesma visão do RIPE mostrou um vizinho esquerdo observado para AS60077: AS43754, a empresa ASIATECH Asiatech Data Transmission.
• A questão de compra, portanto, não é saber se um produto de nuvem existe. Trata-se de saber se um determinado cliente pode verificar a colocação, a capacidade disponível, as rotas independentes, a localidade dos backups, a escalação do suporte, as exclusões de manutenção, a continuidade do faturamento e os direitos de saída antes que um rack, um upstream, um estoque de hardware ou um evento de conta transforme um servidor virtual em dependência física.

A vitrine é pública, mas a promessa de infraestrutura permanece estratificada

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

Apágina "sobre"adiciona um histórico de serviço. Ela afirma que o Cloud.ir iniciou suas operações no ano iraniano 1399 e se tornou um dos principais provedores de serviços em nuvem do Irã, com mais de 20 produtos de nuvem. Os grupos de produtos nomeados incluem distribuição de conteúdo, computação em nuvem, segurança em nuvem, armazenamento em nuvem, rede em nuvem e um marketplace de nuvem. Essas afirmações são declarações da empresa, não medidas independentes de capacidade, mas esclarecem a postura comercial básica: a 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 de servidor em nuvemindica que os clientes podem criar rapidamente um servidor em nuvem, pagar pelos recursos que utilizam, modificar recursos, configurar rede, adicionar ou modificar 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 afirma que o suporte para clientes de servidor em nuvem está disponível 24 horas por dia, 7 dias por semana, via abertura de ticket. Um comprador deve tratar essas promessas como promessas de produto que exigem confirmação contratual e de teste, mas elas são, no entanto, mais concretas do que uma 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 exibidos nos cartões de pacote. Ela também mostra preços por hora para recursos de servidor em nuvem, como memória, CPU, disco, IP, tráfego recebido e níveis de backup. As páginas de preços não são esquemas de engenharia, mas expõem como o serviço é empacotado: o cliente compra 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á-los.

A empresa também descreve serviços de nível superior em torno da mesma infraestrutura. Apágina de data center em nuvemcomercializa gerenciamento seguro e fácil de dados, 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 de CDNdescreve a distribuição de conteúdo nos 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 de cloud switchapresenta uma 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 colocação, design de rede e suporte do provedor.

Esse é o quadro útil para o restante do artigo. A CLOUD Asre Dadeha Asiatech não é uma casca misteriosa, mas a superfície de serviço visível não elimina a necessidade de testar as camadas inferiores. Um servidor em nuvem só pode ser provisionado em segundos se o provedor já tiver a capacidade de host apropriada, armazenamento, endereços públicos, acessibilidade de rede e autorização de faturamento. Um CDN só pode rotear uma solicitação para uma borda mais próxima se essa borda existir, tiver conteúdo atualizado, cache e capacidade de trânsito suficientes, e ainda puder alcançar a origem quando o próprio servidor do cliente falhar.

Um backup só tem valor 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 cada afirmação de resiliência que um comprador de produção precisa.

A ancoragem física é a capacidade dos data centers da ASIATECH no Irã

A declaração física mais forte do Cloud.ir é explícita: sua infraestrutura de nuvem se baseia nos data centers da ASIATECH. Apágina de servidor em nuvemafirma que a infraestrutura dos serviços em nuvem do Cloud.ir está implantada nos data centers da ASIATECH, que descreve como a maior rede de data centers do Irã. Ela enumera 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 largura de banda no Irã e suporte a energia AC e DC. Apágina de data center em nuvemrepete o mesmo quadro de data center da ASIATECH e afirma 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. Ela afirma que os data centers do Cloud.ir estão distribuídos por todo o Irã e que sua infraestrutura se baseia nos data centers da ASIATECH, cobrindo instalações grandes e poderosas com padrões mundiais. Ela também lista suporte AC e DC. Essas alegações são importantes porque movem o serviço de uma abstração puramente de varejo para uma fronteira de operação de site nomeada: a marca de nuvem depende do parque de data centers e da rede da ASIATECH, não de uma região hyperscale no exterior não identificada.

Fora das páginas da empresa, os registros públicos fornecem um contexto mais antigo, mas útil, para este conjunto. O Dynamics Data Centers relatou em julho de 2017 que a AsiaTech havia aberto um data center de 700 metros quadrados na Torre Milad, no oeste de Teerã. Esse relatório descrevia a AsiaTech como uma empresa privada fundada em 2003, afirmava que ela havia obtido uma licença em 2013 para hospedagem, servidores dedicados e compartilhados e colocation, e indicava que operava cinco data centers e conectava mais de 430 cidades em todo o Irã.

O DataCenterMap lista atualmente o data center Asiatech Milad Tower e o data center Asiatech Azadegan em Teerã, enquanto sua página de especificações da Milad Tower indica 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 esteve associada a instalações nomeadas em Teerã e a uma atividade mais ampla de data center. Elas não provam qual instalação atende a uma VM específica do Cloud.ir, uma borda de CDN, um bucket de armazenamento ou uma cópia de backup em julho de 2026. Elas também não provam que o estado da instalação de 2017, o número de racks, o projeto elétrico ou o número de clientes permanece inalterado. O histórico de instalações é uma evidência útil de uma empresa de infraestrutura real; não é um mapa de colocação atual.

Essa distinção importa para os clientes. Um comprador pode ouvir "data centers em todo o Irã" e supor que dois servidores encomendados na mesma conta cheguem a edifícios separados. Esse pode não ser o caso. Eles podem chegar ao mesmo host, dois hosts em um rack, dois racks atrás de uma unidade de energia, duas salas em um edifício ou edifícios separados cuja fibra metropolitana ou borda upstream ainda converge. Inversamente, o provedor pode ter uma separação melhor do que as páginas públicas divulgam. As páginas públicas não resolvem a questão.

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

A energia e a mão de obra de reparo fazem parte da mesma questão. O Cloud.ir pode dizer com razão que o uso da nuvem poupa o cliente do ônus de comprar equipamentos e manter uma sala de servidores. Isso não faz desaparecer a manutenção física. Alguém ainda precisa substituir discos, fontes de alimentação, placas de linha e memória; alguém ainda precisa planejar trabalhos elétricos; alguém ainda precisa testar geradores, baterias, refrigeração e sistemas de incêndio; alguém ainda precisa receber um alerta e chegar ao rack.

Um cliente não precisa saber cada detalhe privado do projeto das instalações da ASIATECH, mas precisa saber quais promessas de disponibilidade sobrevivem a um evento de rack, uma janela de manutenção elétrica, uma falha de armazenamento e uma escassez de hardware de reposição.

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

O registro de rede dá à CLOUD Asre Dadeha Asiatech uma segunda ancoragem concreta. O RIPE RDAP identificaAS60077como AT-CLOUD e a vincula à Asre Dadeha Asiatech através de ORG-ADA42-RIPE. A mesma resposta RDAP inclui contatos administrativos e técnicos do NOC da Asiatech em um endereço na rua Miremad, em Teerã, bem como uma função de abuso da Asiatech. Esta é uma evidência de registro de um sistema autônomo real e de uma cadeia de contato operacional. Ela não descreve servidores individuais, clientes ou disponibilidade, mas confirma que o serviço de nuvem tem seu próprio identificador de rede.

Avisão geral da AS para AS60077do RIPEstat relatou o titular como "AT-CLOUD Asre Dadeha Asiatech" e mostrou que estava sendo anunciado no momento da consulta em 12 de julho de 2026. Suavisão de status de roteamentomostrou 18 prefixos IPv4 e 14.080 endereços IPv4 visíveis a partir da AS60077, com a primeira observação de prefixo datando de 2014 e a última observação no momento da consulta. A mesma visão do RIPE mostrou alta visibilidade do coletor IPv4 e nenhum espaço IPv6 visível nesta resposta de status específica.

O serviço ativo também aponta para AS60077. Avisão da cadeia DNS paracloud.irdo RIPEstat retornou193.151.157.174para o nome apex, e avisão de informações de rede para esse endereçoo mapeou para193.151.157.0/24e AS60077. Isso não prova que cada 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 de nuvem.

A dependência está nos dados de vizinhança. Avisão de vizinhos ASN para AS60077do RIPEstat mostrou um vizinho esquerdo observado: AS43754. Avisão geral da AS para AS43754do RIPEstat nomeia essa rede como "ASIATECH Asiatech Data Transmission company." Suavisã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 de nuvem é visível, mas sua fronteira upstream pública parece ser a rede maior da ASIATECH.

Amostras de looking glass tornam a relação visível em caminhos reais. Osdados de looking glass para193.151.128.0/22, um dos prefixos anunciados da AS60077, incluíam caminhos terminando em AS43754 AS60077. Algumas amostras globais também mostravam upstreams mais acima antes de AS43754, mas a dependência próxima da origem permanecia AS43754. Isso não é surpreendente para um negócio de nuvem ligado ao mesmo grupo de infraestrutura empresarial, mas importa porque uma falha nessa fronteira pode afetar muitos serviços de uma só vez.

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

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

O RPKI responde a uma pergunta diferente. Avalidação RPKI para193.151.128.0/22originado pela AS60077retornou um status válido com autorizações de origem de rota cobrindo a AS60077. Isso é uma higiene de roteamento positiva: apoia a legitimidade da origem da rota. Isso não prova capacidade de tráfego, diversidade de rotas, continuidade elétrica, qualidade do isolamento do cliente, recuperabilidade de backups ou resposta do suporte. Uma rota RPKI válida ainda pode ser retirada por erro, filtrada por um upstream, isolada por uma falha de cross-connect ou tornar-se inútil devido a uma falha do lado do servidor.

A capacidade instalada não é o mesmo que a capacidade de nuvem utilizável

Os compradores de nuvem tendem a ver controles deslizantes de recursos. O operador vê um inventário. CPU, memória, disco, espaço de backup, endereços públicos, estado do firewall, monitoramento, capacidade da porta, consumo de energia do host e tempo da equipe devem estar alinhados antes que um controle deslizante de recursos se torne um servidor funcional. 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, CPU, disco e tráfego. Ela também lista componentes horários separados para infraestrutura de nuvem, incluindo agendamentos de backup. Isso é suficiente para mostrar que o Cloud.ir vende o serviço como um pool de recursos precificados. 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 está em um site separado, com que rapidez uma instância danificada pode ser recriada ou se o provedor pode atender a um pedido grande em caso de escassez de hardware.

Os números de rede fornecem um limite externo, não um número de servidores. Alista de prefixos anunciados para AS60077mostrava 18 prefixos IPv4 no período de consulta recente, incluindo várias faixas/22,/23e/24. Os 14.080 endereços IPv4 vistos na visão de status de roteamento são uma capacidade de endereços públicos real, mas os endereços não são iguais a máquinas virtuais. Alguns endereços atendem a roteadores, balanceadores de carga, firewalls, servidores de nomes, instâncias de clientes, funções de gerenciamento ou pools de reserva. Um único servidor pode usar vários endereços; muitos serviços podem estar atrás de um único 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 através de um arranjo diferente, exposto apenas em alguns 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, o roteamento, o comportamento do firewall, o DNS reverso, a acessibilidade do backup e a escalação do suporte, em vez de confiar em um único rótulo de pacote.

A linguagem do produto do Cloud.ir também separa a capacidade da resiliência. A página de servidor em nuvem afirma 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 de data center em nuvem afirma que os dados armazenados são mantidos em vários data centers e que outros data centers preservam a conectividade se um deles tiver problemas. Essas são afirmações importantes. Elas também exigem 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 configurá-los? O backup é quente, morno ou frio? Existe um tempo de recuperação testado? Créditos estão disponíveis se a automação falhar?

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

O SLA reduz a promessa exatamente aos pontos que uma falha colocará à prova

O Cloud.ir publica umapágina de SLA, e isso é bom para os clientes porque move parte da conversa sobre riscos para um texto público. A parte mais importante da página não é um grande número de disponibilidade; são as limitações. A página afirma que a garantia de disponibilidade se aplica apenas à disponibilidade de rede e servidor em nuvem em operação normal. Ela exclui software de servidor do cliente, sistemas operacionais, problemas de configuração, ataques de negação de serviço contra um servidor em nuvem, servidores suspensos ou desligados, falhas 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 de reparo ou recuperação como o tempo médio de restauração do serviço com base em um acordo entre o provedor e o cliente. Ela então lista os casos que não resultam em penalidades, incluindo força maior, equipamento do cliente, paradas planejadas, 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 o risco. Elas movem muitas falhas reais para fora de um simples título de disponibilidade.

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 disponibilidade do provedor, mesmo que o cliente sofra perda total de serviço. Isso é razoável se o 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 emergência, snapshots, exportação de imagem, restauração, reconstrução e limites claros de suporte. Um "servidor em nuvem" não é continuidade de aplicação gerenciada, a menos que o contrato assim o diga.

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

A questão se torna prática: qual volume de tráfego o firewall pode suportar, o que é filtrado na borda da nuvem, o que chega à instância, quem pode modificar os 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 com falha, um problema com cartão de crédito empresarial ou uma fatura contestada pode se tornar um evento de infraestrutura se os servidores forem suspensos antes que um operador resolva a conta.

Uma empresa usando o 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 segue 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 examinadas.

Considere as ordens de autoridades públicas. O SLA afirma que as paralisações causadas por autoridades judiciais ou de segurança estão fora do quadro de penalidades. Esta é 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 única jurisdição, o cliente precisa entender como ordens legais ou políticas podem afetar a disponibilidade, o acesso a dados, o serviço de domínio e as 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 a latência e uma restrição para a governança.

O SLA, portanto, refina as questões do comprador. Ele não torna o Cloud.ir mais fraco; torna a forma do serviço mais conhecível. O cliente deve distinguir disponibilidade de rede, disponibilidade de host, saúde do convidado, integridade do armazenamento, recuperabilidade de backups, comportamento do CDN, status da conta e restrições legais. O SLA público não reduz essas camadas a uma única promessa. Um comprador de produção também não deve fazê-lo.

O CDN, o armazenamento e o cloud switching ampliam o raio de impacto, bem como o conjunto de funcionalidades

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 de CDNafirma que a distribuição doméstica pode atender a solicitações através de data centers locais e criar tráfego pela metade do preço para usuários domésticos; ela também descreve o roteamento de usuários para servidores mais próximos, compressão e cache de conteúdo, monitoramento de solicitações e respostas, limites de acesso por país e proteção contra ataques. Esta é uma verdadeira história de produto, mas transforma um site em uma cadeia: DNS, borda CDN, estado do cache, acessibilidade da origem, gerenciamento de certificados, configuração da conta e suporte devem funcionar juntos.

Se o servidor de origem falhar, o CDN pode continuar servindo conteúdo estático em cache. Ele 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 de CDN perder a acessibilidade upstream, os usuários em uma região podem ver erros enquanto outros não. Se as regras de acesso forem mal configuradas, um recurso de localidade pode se tornar um problema de disponibilidade.

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

A oferta de armazenamento tem uma forma de risco diferente. Apágina de armazenamento em nuvemafirma 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. Ela também afirma que os dados são protegidos por distribuição em vários servidores. Isso é valioso, mas a durabilidade do armazenamento não é visível externamente. Um cliente precisa saber se o serviço é armazenamento de objetos, armazenamento em bloco, armazenamento de arquivos ou uma mistura; o que a replicação significa; se as réplicas estão em uma única sala ou em vários sites; como as exclusões são protegidas; se o versionamento existe; como as chaves são rotacionadas; como a recuperação é testada; e com que rapidez uma exportação completa pode ser realizada.

O serviço de cloud switch é igualmente importante. Apágina de cloud switchdescreve uma rede gerenciada entre servidores em nuvem e data centers, roteando tráfego e criando redes privadas. Ela também afirma que o serviço pode identificar recursos alternativos disponíveis e fazer failover automaticamente em caso de interrupção. Esse tipo de funcionalidade pode reduzir a recuperação manual se for bem implementada. Também pode se tornar um único ponto de falha se uma configuração incorreta de rede privada isolar um grupo de servidores que de outra forma estariam saudáveis.

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

O cliente não deve perguntar se essas funcionalidades existem no abstrato. Ele deve perguntar como cada funcionalidade se comporta quando um host, um rack, uma rota, um cluster de armazenamento, uma conta ou uma fila de suporte já está falhando.

A localidade é um atributo do produto, não um slogan

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

Mas a localidade deve ser definida por serviço. Um servidor virtual pode ser executado no Irã enquanto um relay de e-mail, um console de gerenciamento, um serviço de análise, uma cópia de backup ou um anexo de suporte percorre outro caminho. Um produto de CDN pode oferecer modos de distribuição doméstica 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 deduzir 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 regional do Cloud.ir para um perfil orientado a compradores pode ser global porque a acessibilidade IP é global e os clientes de nuvem podem estar em qualquer lugar com uma conta funcional e um caminho de rede. Isso é diferente de dizer que a empresa opera regiões globais. As evidências de produto público examinadas aqui apontam mais fortemente para a infraestrutura iraniana e o parque de data centers doméstico da ASIATECH. Se um cliente precisa de um serviço exclusivamente iraniano, deve solicitar uma declaração por escrito sobre a localidade da computação, armazenamento, backup, logs e acesso ao suporte.

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

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

Um usuário do setor público ou regulado pode valorizar o controle local das instalações, mas precisa de uma declaração mais rigorosa sobre quem pode acessar os dados, onde os snapshots estão localizados 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 são as evidências. Pergunte sobre 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 de CDN e metadados de armazenamento são mantidos. Pergunte se os engenheiros de suporte podem acessar discos, snapshots, chaves ou consoles dos clientes, e de onde. Pergunte se uma exportação completa pode ser realizada sem manter a conta ativa por outro longo ciclo de faturamento.

Um provedor que pode responder a essas perguntas com calma é mais fácil de confiar do que outro que se apoia apenas em uma linguagem ampla de localidade.

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

A falha mais provável do Cloud.ir para a qual um cliente deve planejar não é uma falha total dramática. É uma falha parcial que fica entre as 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 restauração é muito lenta. Um CDN pode responder por conteúdo estático enquanto as funções dinâmicas falham. Um painel do cliente pode estar acessível enquanto o pagamento impede a 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 o hardware físico. Uma falha de host pode mover uma VM bem projetada para outro host se houver armazenamento compartilhado, capacidade de host de reserva e orquestração funcional. Ela também pode deixar um cliente esperando por uma peça se armazenamento local, alocação bare-metal ou um componente não redundante estiver envolvido. As páginas públicas do Cloud.ir não divulgam a plataforma de hipervisor, a classe de host, as escolhas de armazenamento local versus compartilhado ou a política de hardware de reserva.

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

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

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

O caminho do estoque de hardware diz respeito ao crescimento e ao reparo. A precificação por hora da nuvem e a escalabilidade instantânea só são úteis se houver núcleos de CPU, RAM, discos, endereços e portas de switch de reserva. Um comprador planejando uma campanha, evento, lançamento ou migração deve perguntar se a capacidade pode ser reservada, se aumentos grandes exigem aviso prévio e se o provedor pode colocar capacidade adicional 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 de reserva suficiente para reiniciar meu servidor em outro lugar?

O caminho do suporte diz respeito ao tempo e à autoridade. O Cloud.ir afirma que clientes de servidor em nuvem podem abrir tickets a qualquer hora. Isso é melhor do que um canal de horário comercial restrito, mas o cliente ainda precisa de objetivos de escalonamento. Quem pode modificar uma rota BGP? Quem pode autorizar uma visita ao rack? Quem pode restaurar um backup excluído? Quem pode cancelar uma suspensão de conta? Quem pode explicar uma ordem legal ou de segurança? Se a equipe de suporte de primeira linha só pode encaminhar uma solicitação, o tempo de reparo inclui cada transferência.

O caminho da migração é a última rede de segurança. Um cliente pode tolerar evidências mais fracas se puder sair rapidamente. Isso requer backups atuais, imagens ou arquivos exportáveis, procedimentos documentados de mudança de IP e DNS, TTLs conhecidos, acesso à conta que permanece disponível durante disputas de faturamento e largura de banda suficiente para mover dados. Isso também requer evitar bloqueios ocultos: endereços de rede privada que não podem ser reproduzidos, funcionalidades de armazenamento sem 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 as condições completas de portabilidade. Os usuários de produção devem obtê-las antes de precisar delas.

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

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

A segunda tarefa é a diversidade de rede. A AS60077 é visível e legítima, e a AS43754 é uma rede pai substancial. Este é um bom ponto de partida. Não é o mesmo que provar que o tráfego do cliente pode sobreviver a um evento de borda da AS43754. Pergunte sobre o caminho normal, o caminho de fallback, o design do roteador de borda, o limite de tratamento de DDoS, as práticas de RPKI e filtragem de rotas, e se o 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 funcionalidades 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 é, 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 sair da fronteira danificada é um seguro apenas contra uma classe estreita de falhas.

A quarta tarefa é a manutenção e as exclusões. O SLA exclui manutenção anunciada e patches críticos do cálculo de disponibilidade. Pergunte como a manutenção é anunciada, quanto aviso é dado, se um 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 cronograma de faturas, os limites de suspensão, os caminhos de recurso e a retenção de dados após a suspensão. Isso é particularmente importante para equipes fora do Irã, equipes com atrasos de fornecimento e equipes cujo acesso ao pagamento depende de uma única pessoa. Uma falha de faturamento pode se tornar uma falha evitável.

A sexta tarefa é a saída. Exporte uma pequena imagem de servidor, restaure um backup em uma instância limpa, mova um registro DNS para longe do 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 ajudam principalmente o cliente a permanecer.

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

A CLOUD Asre Dadeha Asiatech merece um nível de confiança mais alto do que uma empresa com apenas uma entrada de roteamento desatualizada. O 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 a AS60077 na tabela de roteamento pública como AT-CLOUD Asre Dadeha Asiatech. O DNS para o site da empresa aponta para a AS60077. A AS60077 tem um parque de endereços visível, e sua dependência da rede pai AS43754 é observável em vez de oculta.

Isso não torna o serviço totalmente transparente. Os registros públicos não mostram a colocação exata em data center das cargas de trabalho do cliente, o número de hosts disponíveis, a quantidade de hardware de reserva, o tempo real de restauração, a localização de cada backup, a diversidade física das rotas, o design de failover de rotas na borda da nuvem ou as condições de conta e migração nas quais um cliente confiaria em 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 o Cloud.ir para cargas de trabalho que se beneficiam da proximidade dos data centers iranianos, 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 evidência de resiliência multissite, diversidade de rotas ou saída sem costura. Esses são fatos de engenharia e contratuais que precisam ser obtidos, testados e documentados.

Para um site pequeno, a incerteza restante pode ser aceitável se os backups forem independentes e o DNS puder ser movido rapidamente. Para uma propriedade de mídia iraniana de alto tráfego, o CDN e a hospedagem doméstica podem ser valiosos, mas o operador deve testar a falha da origem, o comportamento do cache e a escalação do suporte antes do lançamento. Para dados regulamentados ou transfronteiriços, as questões-chave são localidade, exposição a autoridades, acesso ao 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, da rota, do reparo e da migração por trás dele.