Resumo
- A Wholesale Communications Group Pty Ltd continua sendo uma empresa privada australiana ativa e consta na mais recente declaração pública do grupo Vocus sobre escravidão moderna. Isso apoia a continuidade corporativa dentro do grupo Vocus, e não a conclusão de que a WCG ainda opera como uma marca de nuvem de varejo independente.
- O APNIC marca o AS18104 como ativo e o associa ao nome WCG e à Vocus como declarante. No entanto, a observação independente de roteamento não mostra anúncios IPv4 ou IPv6 atuais do AS18104 e registra sua última rota observada em junho de 2012. Um sistema autônomo registrado não é a mesma coisa que uma rede de entrega ativa.
- O PeeringDB lista uma presença de site da WCG na Equinix SY1/SY2 em Sydney e nenhuma conexão a um ponto de troca público. A declaração do site foi atualizada pela última vez em 2016, portanto, trata-se de uma evidência operacional histórica, e não de uma prova de um rack atual, de uma frota de servidores ligados ou de uma interconexão.
- Os documentos atuais da Vocus oferecem capacidade de infraestrutura de Sydney, Melbourne e Perth e indicam que o grupo opera 14 data centers australianos, conectando-se a mais de 150 outros. Essas afirmações estabelecem uma superfície de entrega plausível no nível do grupo controlador, mas não divulgam quais sites, racks, pools de recursos ou condições de suporte se aplicam a um cliente que compra sob o nome WCG.
- As condições públicas da Vocus expõem a mecânica subjacente à capacidade hospedada: a conectividade pode ser separada, a recuperação de desastres deve ser contratada expressamente, os clientes assumem responsabilidades significativas de backup e restauração, os endereços IP atribuídos não são portáteis, e manutenções ou falhas de terceiros podem limitar os recursos. Um comprador precisa de uma arquitetura específica do site e de um plano de migração executável antes de tratar a capacidade nominal como capacidade recuperável.
O nome WCG sobreviveu mais claramente do que sua rede independente
A infraestrutura hospedada é frequentemente comprada por meio de um nome que esconde várias camadas de maquinário. Um cliente pode ver uma única fatura e um único número de suporte enquanto o serviço em si atravessa uma subsidiária legal, uma rede do grupo, um espaço de data center alugado, uma plataforma de virtualização, software de terceiros e técnicos de campo. Isso não é necessariamente um defeito. Provedores integrados usam regularmente várias empresas do grupo e fornecedores. O risco surge quando o cliente confunde um nome duradouro com um sistema operacional autônomo.
A WCG é um exemplo particularmente marcante. O registro de empresas australiano (Australian Business Register)identifica a Wholesale Communications Group Pty Ltdcomo uma empresa privada australiana ativa, registrada para GST desde junho de 2004, com sede no estado de Victoria. A declaração do governo australiano sobre escravidão moderna de 2025 do grupo Vocus inclui a Wholesale Communications Group Pty Ltd entre as entidades declarantes. Esses são fatos sólidos de identidade. Eles mostram que a WCG não simplesmente desapareceu como nome jurídico.
Eles não mostram que a WCG atualmente comercializa servidores virtuais, bare metal, armazenamento ou hospedagem gerenciada em seu próprio nome. A posição histórica da WCG é mais fácil de estabelecer. O relatório anual de 2010 da M2 indica que a M2 adquiriu a Wholesale Communications Group em maio de 2007 e descreve o conjunto mais amplo de varejo da M2 como incluindo redes privadas virtuais corporativas e hospedagem remota. Orelatório anual depositadotambém descreve a empresa adquirida como parte da expansão de atacado da M2. Orelatório anual de 2020da Vocus lista então a Wholesale Communications Group Pty Limited como uma subsidiária australiana integralmente detida.
A sequência corporativa é, portanto, sustentável: a WCG tornou-se parte da M2, e o grupo M2 tornou-se parte da Vocus. Mas a história não é uma ficha de produto atual. Seria perigoso transformar a expressão "hospedagem remota" em um relatório de 2010 em uma afirmação de que um serviço de computação específico da WCG está disponível em 2026 com a mesma plataforma, os mesmos locais ou o mesmo contrato. A questão operacional atual é mais restrita: quais recursos ainda carregam a identidade WCG, qual infraestrutura pode ser verificada no nível do grupo Vocus e onde a evidência termina?
Essa distinção é comercialmente importante. Se um comprador assina com a Wholesale Communications Group Pty Ltd, mas recebe um serviço projetado, operado ou suportado por outras entidades da Vocus, o pedido deve identificar qual empresa fornece cada componente, quais condições prevalecem e onde está a responsabilidade. A continuidade corporativa pode ser reconfortante. Ela não substitui o fato de saber qual entidade controla o rack, a porta de rede, o sistema de backup e o técnico que atenderá às 3 da manhã.
A superfície de venda pública agora é uma superfície Vocus
O próprio domínio da WCG ainda existe, mas não apresenta um catálogo de vendas público atual. Como observado em julho de 2026,wcg.net.auresolvia para um endereço IPv4 e mantinha nomes de hosts de e-mail e servidores de nomes da era WCG e M2, enquanto as consultas web comuns não retornavam um site WCG funcional. Oresumo DNS público para wcg.net.aurelata o endereço 203.132.224.176, servidores de e-mail sobm2core.com.aue servidores autoritativos sobwcg.net.au. Também relata a ausência de um servidor web configurado. O DNS é dinâmico e o resumo de terceiros pode estar atrasado em relação às alterações, mas isso corresponde ao padrão mais amplo: o espaço de nomes permanece mantido sem funcionar como uma vitrine de produtos atual.
O endereço em si não é uma prova de que o AS18104 hospeda o site. Oresultado RIPEstat para 203.132.224.176o coloca em um prefixo originado por outra rede Vocus, não AS18104. Oregistro APNIC para o endereçofornece o contexto do registro para esse bloco. Um registro A ativo demonstra, portanto, a continuidade do domínio e da rede do grupo, mas não pode ser usado como um exemplo de carga de trabalho que prova uma nuvem WCG ativa.
A oferta atual visível está nas páginas públicas da Vocus. Apágina de Infrastructure as a Serviceda Vocus descreve pools de recursos em Sydney, Melbourne e Perth, hospedados em seus data centers e interconectados por sua rede principal. Ela anuncia alocações de processamento, memória e armazenamento, várias opções de largura de banda, precificação de backup e suporte 24 horas. Aficha técnica do IaaSassociada nomeia os mesmos três pontos de entrega e lista as políticas de backup, bem como um service desk.
A Vocus indica separadamente em suapágina de soluções de data centerque opera 14 data centers na Austrália e se conecta a mais de 150 locais adicionais, incluindo instalações de parceiros. Isso é uma evidência significativa de que o grupo controlador possui um vasto parque físico e de interconexão. Ainda é um agregado de nível de marketing. Não nomeia os 14 sites nessa página, não especifica a potência ou o inventário de computação disponível em cada um, nem associa os três pools de recursos IaaS a um pedido WCG específico.
A leitura cautelosa não é que a WCG não tem serviço. É que as evidências públicas apoiam um serviço atual do grupo Vocus e uma identidade corporativa contínua da WCG, deixando não especificada a relação comercial atual entre eles. Um cliente potencial deve perguntar se a WCG é o fornecedor contratante, um nome de conta histórico, um revendedor, uma subsidiária operacional ou simplesmente a identidade histórica associada a certos recursos de rede. A resposta determina qual portal de suporte, qual calendário de serviço, qual aviso de privacidade e qual processo de rescisão realmente se aplicam.
AS18104 está registrado, mas atualmente não anuncia nenhuma rota
O número do sistema autônomo da WCG é o elemento de evidência mais tentador para ser mal interpretado. O registro RDAP do APNIC paraAS18104marca o número como ativo, o nomeia WCG-AS-AP e descreve a Wholesale Communications Group como um provedor nacional de comunicações de atacado em Sydney. A entidade declarante é a Vocus Pty Ltd. O registro também mantém um contato de operação de rede WCG, enquanto seu papel de abuso aponta para a Vocus. Essa combinação é consistente com um recurso que passou por integração corporativa sem perder todos os seus rótulos antigos.
Um status de registro ativo não significa que o número está originando tráfego. A distinção é básica, mas importante. Um registro regional da Internet registra a atribuição, os contatos de declaração e a situação administrativa. Os coletores de rotas globais observam o que as redes realmente anunciam. Os dois conjuntos de dados respondem a perguntas diferentes.
O resultado de status de roteamento doRIPEstat para AS18104não relata nenhum espaço IPv4 ou IPv6 anunciado no momento da observação em julho de 2026, nenhum vizinho observado e visibilidade zero entre seus pares coletores de rotas. Ele registra a primeira rota observada em janeiro de 2002 e a última rota observada, 125.168.0.0/16, em 19 de junho de 2012. Seu resultado deprefixos anunciadosnão retorna nenhum prefixo na janela de observação atual. A visão de roteamento doCloudflare Radar para AS18104oferece uma segunda superfície de observação pública, enquanto apágina AS18104do Hurricane Electric preserva a identidade da rede e o contexto histórico de roteamento.
Essas observações não provam que todo dispositivo outrora associado à WCG foi desligado. Um sistema autônomo pode permanecer registrado enquanto seus endereços são anunciados por outra rede do grupo, usados internamente, mantidos para uso futuro ou tornados desnecessários. Os serviços também podem funcionar por trás de endereços do provedor sem que o antigo ASN apareça na rota pública. O que os dados estabelecem é que o AS18104 não deve ser apresentado como o caminho independente atual pelo qual as cargas de trabalho hospedadas da WCG alcançam a Internet.
A política de roteamento administrativa no APNIC ainda nomeia AS9942, AS2764 e AS9654 nas instruções de importação. Essas instruções não são medidas de trânsito atuais. O texto da política de registro pode permanecer muito tempo após as mudanças de topologia, e a ausência de anúncios atuais significa que não há rota AS18104 na qual observar esses vizinhos agora. Listar os três números como uma diversidade de upstream viva transformaria um texto de configuração histórica em uma afirmação operacional sem suporte.
Há uma verificação cruzada útil no contrato de nuvem atual da Vocus. OCloud Service Scheduleda Vocus lista vários sistemas autônomos sob os quais a Vocus declara manter e operar sua rede para Cloud Internet. O AS18104 não aparece nessa lista. A Vocus se reserva o direito de adicionar ou remover números, portanto a lista não é imutável. No entanto, isso reforça a conclusão da observação de roteamento: a acessibilidade atual da nuvem deve ser avaliada como um projeto de rede Vocus, e não inferida a partir do ASN WCG herdado.
Um registro antigo de site em Sydney não pode sustentar uma reivindicação de capacidade nacional
A entrada de rede do PeeringDB paraWCGassocia o AS18104 a um único site, Equinix SY1/SY2 em Sydney, e a nenhum ponto de troca público. A entrada qualifica a rede como regional, principalmente de entrada e seletiva em sua política de peering. Ela não divulga nenhum nível de tráfego nem nenhum número de prefixos IPv4. Suas informações de site foram atualizadas pela última vez em março de 2016, seus contatos em março de 2016 e o registro de rede em julho de 2022.
É uma evidência, mas tem uma meia-vida longa. O PeeringDB é mantido pelas organizações participantes. Uma linha de rede para site significa que a entidade representou a rede como presente naquele local; não divulga se essa presença era um roteador em um rack completo, uma pequena alocação em um espaço compartilhado, uma porta remota, uma interconexão fornecida por outra parte ou um arranjo que depois mudou. A antiguidade da atualização do site é particularmente importante, dada a ausência de anúncios atuais do AS18104.
A Equinix SY1 e SY2 são sites de interconexão importantes em Sydney, mas os atributos desses edifícios não podem ser automaticamente atribuídos à WCG. A linha pública não especifica as unidades de rack, a alocação de energia, o número de links, o número de interconexões, o inventário de servidores, a arquitetura de armazenamento ou os direitos de acesso remoto. Não diz que a WCG possui o site. Nem prova que a configuração de 2016 ainda está instalada em 2026. A conclusão apropriada é que a WCG tinha uma presença declarada em Sydney no banco de dados de interconexão, com status atual não verificado.
A ausência de linha de ponto de troca público é importante de forma igualmente limitada. Isso significa que o PeeringDB atualmente não mostra o AS18104 em uma LAN de troca. Isso não exclui interconexão privada, trânsito pago, peering remoto ou acessibilidade por meio de outro ASN Vocus. Mas combinado com a ausência de rotas atuais, não fornece nenhuma base para reivindicar uma diversidade de peering atual da WCG ou um alcance de troca independente.
A pegada mais ampla da Vocus deve ser tratada separadamente. O site atual do grupo controlador reivindica três cidades de entrega IaaS, 14 data centers australianos operados e conexões a mais de 150 locais de data center adicionais. Sua página jurídica inclui cronogramas para suas próprias instalações de colocation e para operadores terceiros, incluindo Equinix e NEXTDC:https://www.vocus.com.au/help-and-support/legal-contracts. Essa amplitude pode suportar um serviço resiliente se o cliente realmente comprar os sites, caminhos e réplicas pertinentes. Não pode retroativamente tornar a linha PeeringDB da WCG uma plataforma de computação em três cidades.
A evidência que resolveria a questão é simples: um pedido de compra atual identificando o site ou a zona de entrega, uma alocação de rack ou recurso virtual, os detalhes de entrega de rede e uma confirmação por escrito das entidades operacionais e contratantes. Sem esses elementos, a pegada pública é melhor descrita como uma declaração histórica única em Sydney mais um parque de grupo atual mais amplo, cuja alocação a clientes sob a marca WCG é desconhecida.
A capacidade é uma cadeia de alocações, não um número em uma página de produto
A capacidade em nuvem parece divisível porque é vendida em pequenas unidades. Um comprador pode solicitar um processador virtual, um gigabyte de memória ou um volume de armazenamento adicional sem ver um servidor instalado. A promessa econômica é que uma plataforma compartilhada absorverá essa demanda de forma mais eficiente do que o hardware próprio do comprador. O limite físico não desapareceu; ele se moveu para trás de um sistema de alocação.
O cronograma IaaS da Vocus torna esse limite particularmente visível. Ele define máquinas virtuais em unidades de processamento, memória e armazenamento adquiridas, ao mesmo tempo que indica que o tempo de CPU será equilibrado entre os recursos solicitantes em caso de contenção. Ele indica que a capacidade de armazenamento criada não pode ser reduzida. Também indica que os clientes continuam responsáveis pela alocação contratada mesmo que o uso real seja inferior. Essas cláusulas não revelam o uso atual, mas mostram por que a capacidade contratada, instalada e utilizável são quantidades diferentes.
A capacidade contratada é o que aparece no pedido de compra. A capacidade instalada é o hardware, armazenamento e equipamento de rede fisicamente disponíveis no pool de recursos relevante. A capacidade utilizável é a parte que pode ser alocada sem violar as restrições de desempenho, resiliência ou energia. A capacidade recuperável é ainda menor: a parte que permanece disponível, ou pode ser restaurada no prazo exigido, quando um host, sistema de armazenamento, rack, site ou caminho falha.
Para a WCG, nenhuma dessas quantidades é publicada no nível da empresa. Não há número público de servidores, geração de processadores, suporte de armazenamento, alocação de racks, energia comprometida, número de uso ou proporção de hosts de reserva associados à WCG. Os documentos públicos da Vocus fornecem dimensões do produto e locais, mas não inventário livre. Uma plataforma em três cidades ainda pode ter margem de manobra desigual. Uma cidade pode estar disponível para novos pedidos, mas carecer de capacidade de reserva suficiente para absorver todas as cargas de trabalho de outra cidade em caso de falha regional.
O estoque de hardware faz parte da mesma equação. Uma plataforma pode ter capacidade virtual de reserva até que uma placa-mãe, controlador, módulo óptico ou modelo de disco falhe. A restauração depende então de peças compatíveis, suporte do fornecedor e um técnico com acesso ao site. A questão pertinente não é se o grupo é grande o suficiente para comprar equipamento. É saber se o serviço contratado possui um estoque de reposição na cidade certa, dentro dos limites de segurança corretos, e se o tempo de substituição está incluído no objetivo de restauração.
A energia é outra alocação. O cronograma de serviço NEXTDC atual da Vocus define racks com uma alocação de energia acordada e descreve a energia condicionada como finita. Ele adverte que o uso excessivo pode afetar o cliente, outros clientes e o resfriamento. O cronograma diz respeito a um serviço de colocation de terceiros oferecido pela Vocus, não uma prova de que a WCG utiliza a NEXTDC. Seu valor é explicativo: mesmo em uma instalação altamente técnica, o espaço de rack vendável é limitado pelos quilowatts contratados, fontes de alimentação equilibradas, resfriamento e regras operacionais.
O resultado é uma definição mais exigente de capacidade. Um comprador não deve apenas perguntar quantos processadores virtuais podem ser contratados. As perguntas úteis são: qual margem de manobra em caso de falha existe na cidade escolhida, a capacidade está reservada no site de recuperação, quais componentes estão estocados localmente e o que acontece quando um reparo requer aprovação de terceiros ou uma janela de mudança.
A diversidade de trânsito pertence ao serviço entregue, não à família corporativa
A ausência atual de rotas AS18104 não significa que um serviço contratado da WCG seria inacessível. Significa que o cliente deve identificar a rede de entrega efetiva. O cronograma de nuvem da Vocus indica que a Cloud Internet pode ser alcançada por meio de sistemas autônomos operados pela Vocus e que a rede internacional inclui peering e trânsito com muitas redes. Também se reserva o direito de modificar esses arranjos sem aviso prévio.
Isso é uma reivindicação de resiliência no nível do grupo, não um diagrama de caminho específico do site. Uma máquina virtual em Sydney pode alcançar a Internet por meio de roteadores redundantes e vários provedores de acesso; pode também depender de um único firewall do cliente, um único circuito de acesso ou uma única entrega não protegida. Uma rede privada pode evitar a Internet pública enquanto depende de um único provedor de última milha. Dois contratos podem compartilhar o mesmo pool de recursos de nuvem e ter superfícies de falha muito diferentes.
O cronograma estipula que a conectividade não está incluída, a menos que seja explicitamente indicada. O acesso pode ser pela Internet ou por uma rede privada, conforme especificado no pedido. Essa cláusula evita um erro de categoria comum: comprar computação não compra necessariamente um caminho diversificado até ela. O comprador deve ver o serviço de Internet, a conexão privada, a interconexão e o equipamento do lado do cliente como componentes separados, cada um com seu próprio nível de proteção.
A ficha técnica do Cloud Connect da Vocus indica que o grupo alcança mais de 100 data centers públicos e suporta conexões privadas aos principais provedores de nuvem, com opções de camada 2 e camada 3. Esse alcance pode reduzir a dependência de caminhos públicos da Internet. Mas uma conexão a um provedor de nuvem não é automaticamente redundante. O número de portas, a diversidade metropolitana, a diversidade de roteadores e as próprias exigências do provedor de nuvem ainda contam.
O mesmo ponto se aplica à acessibilidade por meio de pontos de troca. Um operador pode ter peering extenso sob seu ASN principal, enquanto um ASN de subsidiária herdado não tem porta de troca. Os clientes se importam com o caminho que seus pacotes realmente percorrem, não com os registros que existem em outro lugar no grupo. O projeto do serviço deve identificar o ASN de origem, o tipo de endereço do cliente, o caminho de upstream ou conectividade privada, o status protegido ou não, e o que acontece durante a manutenção.
O endereçamento atribuído pelo provedor cria uma dependência adicional. O cronograma de nuvem indica que os endereços atribuídos pela Vocus permanecem propriedade da Vocus, não são transferíveis e deixam de ser utilizáveis no final do serviço. A Vocus pode modificá-los com aviso prévio, ou imediatamente se uma alteração urgente for necessária para estabilidade ou correção de defeitos. Endereços fornecidos pelo cliente podem ser possíveis, mas a portabilidade não está disponível em todos os locais ou com todos os serviços.
Um cliente que integra endereços do provedor em listas de permissão, DNS, certificados ou sistemas de parceiros, portanto, integrou um custo de migração em seu projeto de rede.
Para a WCG, a evidência decisiva seria um trace route atual e uma especificação de serviço provenientes da carga de trabalho real, e não do registro do AS18104. Até lá, o ASN herdado é útil para entender a história e a integração corporativa. Não é um certificado de redundância atual.
As janelas de manutenção expõem o limite de propriedade
Uma falha se torna uma cadeia de autorizações assim que a recuperação de software falha. Alguém deve determinar se o defeito está na máquina virtual, no hipervisor, no host físico, no sistema de armazenamento, na alimentação do rack, na interconexão, na fibra metropolitana ou na rede upstream. Cada limite pode envolver uma equipe, um fornecedor e um relógio diferentes.
Oacordo de nível de serviçoda Vocus oferece acesso 24 horas ao seu centro de suporte e descreve os canais de telefone, e-mail, portal e alertas automáticos. Indica que os incidentes podem ser escalados para recursos e fornecedores competentes. Também indica que os tempos de restauração são objetivos, e não garantias, e que a Vocus envidará esforços razoáveis para alcançá-los. Essa diferença é importante em caso de defeito físico. Um objetivo de quatro horas é um objetivo operacional; não é a prova de que um componente de reposição, uma equipe de fibra ou um acompanhante de edifício estará disponível em quatro horas.
O acordo exige que os clientes relatem incidentes graves por telefone e forneçam informações de identificação e diagnóstico. Permite escalonamento por meio de uma matriz disponibilizada na entrega do serviço ou mediante solicitação. Para um incidente de prioridade 1, um cliente pode solicitar um relatório pós-incidente, que a Vocus declara fornecer com esforços razoáveis nos prazos indicados. Esses são mecanismos de suporte significativos. São mecanismos atuais da Vocus, e o site público da WCG não fornece um caminho de escalonamento atual separado.
Um comprador da WCG deve ter o nome da Vocus ou de outro processo aplicável no pedido antes que uma falha ocorra.
Os trabalhos planejados constituem uma exposição distinta. O acordo descreve as categorias de manutenção: perigo, impacto no serviço, falha e emergência. Um aviso de manutenção com falha tem como alvo geralmente dez dias úteis; os trabalhos de emergência podem ser anunciados assim que razoavelmente possível, com um objetivo de oito horas de aviso prévio. Para trabalhos de colocation ou manutenção realizada por terceiros, a Vocus promete o máximo de aviso possível nas circunstâncias. A manutenção planejada é excluída dos créditos de disponibilidade comuns.
A colocation de terceiros torna o limite ainda mais claro. O cronograma NEXTDC define as mãos remotas como um serviço adicional limitado a tarefas técnicas menores especificadas. Dá à equipe do local a autoridade para controlar o acesso em caso de emergência, segurança e exigências legais. Coloca as obrigações de manutenção do equipamento do cliente sobre o cliente e exige compatibilidade com a conectividade do local. Novamente, isso não é uma prova de um rack WCG na NEXTDC. Mostra o tipo de dependência que um serviço do grupo pode herdar quando o edifício, o cliente do rack e o cliente de hospedagem são partes diferentes.
Os arranjos da Equinix têm sua própria cadeia. O cronograma Equinix IBX Centre da Vocus indica que a Equinix mantém o título de seu centro e descreve as configurações de estrutura de nuvem redundantes como exigindo portas duplas. Um cliente comprando uma única porta não comprou a configuração redundante simplesmente por estar em um edifício Equinix.
Um projeto de reparo crível nomeia, portanto, o proprietário de cada camada. Diz quem monitora o host, quem pode abrir o rack, quem armazena as peças, quem pode aprovar uma mudança de interconexão, quando as mãos remotas estão disponíveis e quais exclusões de manutenção do fornecedor se aplicam. Apenas os nomes WCG e Vocus não podem responder a essas perguntas.
A disponibilidade em várias cidades não é um failover automático
Sydney, Melbourne e Perth são pontos de separação úteis. Eles reduzem a exposição a um único edifício e, dependendo do projeto, a um evento metropolitano de energia, fibra ou desastre. A Vocus indica que seus pontos de entrega IaaS são interconectados por sua rede principal, permitindo continuidade entre as instâncias hospedadas em outros pontos de entrega. É uma declaração de capacidade, não uma declaração de que os dados e aplicações de cada cliente são replicados nas três.
O failover requer capacidade, estado e autoridade. O site de recuperação precisa de processamento, memória, armazenamento, licenças e largura de banda reservados suficientes. Os dados da aplicação devem ser copiados com uma frequência consistente com a perda tolerável do cliente. A identidade da rede deve ser transferível ou recriada. A equipe precisa de autorização e instruções testadas para iniciar o ambiente alternativo. Dependências como DNS, autenticação, chaves, monitoramento e listas de permissão de terceiros devem sobreviver à mudança.
O cronograma de nuvem da Vocus indica explicitamente que os serviços de recuperação de desastres não estão incluídos, a menos que indicado de outra forma no pedido de compra. Exclui a importação de máquinas virtuais e dados, bem como a configuração do ambiente, exceto por pedido expresso. Indica que o monitoramento e os alertas das máquinas virtuais do cliente estão fora da descrição básica de computação e armazenamento. Essas exclusões colocam grande parte do projeto de continuidade do lado do cliente.
As disposições de backup também são divididas. A Vocus pode fornecer acesso a um ambiente de backup, mas o cliente continua responsável por aplicar as políticas e verificar o bom funcionamento do backup. No âmbito do Backup as a Service, a Vocus gerencia a plataforma de backup enquanto o cliente gerencia os endpoints, escolhe os dados protegidos, planeja os objetivos de recuperação e realiza os testes. A restauração pode incorrer em custos adicionais, e algumas restaurações são fornecidas com base em esforços razoáveis, e não garantidas.
O cronograma indica que o cliente é responsável por garantir a integridade dos dados copiados, pois a Vocus não pode validar sua natureza, conteúdo e forma.
As diretrizes do governo australiano chegam à mesma conclusão operacional. As diretrizes de segurança em nuvem para executivos do Australian Signals Directorate convidam as organizações a avaliar a continuidade dos negócios, a recuperação de desastres, a conectividade segura, as condições de disponibilidade, a retenção e a portabilidade. Suas recomendações sobre backups regulares defendem backups resilientes e testes de restauração coordenados. Uma réplica que nunca foi restaurada em condições realistas é evidência de cópia, não evidência de recuperação.
Para um serviço com a marca WCG, um comprador deve solicitar o projeto de recuperação em nomes e números: cidade principal, cidade de recuperação, método de replicação, objetivo de ponto de recuperação, objetivo de tempo de recuperação, capacidade reservada, alterações de rota e DNS, administrador de backup, frequência de testes e último exercício bem-sucedido. Uma reivindicação de três pontos de entrega responde apenas à primeira pergunta: onde uma plataforma pode existir.
Uma falha de faturamento pode se tornar uma falha de infraestrutura
A história física é apenas metade da resiliência da hospedagem. Uma carga de trabalho pode estar saudável e se tornar inacessível porque uma fatura, uma licença ou uma condição contratual não é resolvida. É por isso que os contatos de faturamento e as datas de renovação fazem parte do planejamento de continuidade.
O cronograma de nuvem da Vocus indica que os clientes pagam pela alocação em seu pedido, mesmo que o uso real seja inferior. O excesso de largura de banda e os dados de backup podem incorrer em custos adicionais. Aumentos de preço de software de terceiros podem ser repassados com aviso prévio, e o não cumprimento de licenças pode resultar em rescisão imediata em circunstâncias especificadas. O cliente é responsável por manter o número e o tipo corretos de licenças de software.
As condições de colocation tornam as consequências mais tangíveis. O cronograma de colocation de data centers da Vocus vincula as taxas ao espaço e à energia contratados, permite revisão de custos em circunstâncias descritas e trata de restrições de acesso. O cronograma NEXTDC contém direitos relacionados a valores não pagos, suspensão e equipamento do cliente. Essas são proteções comerciais comuns em contratos de infraestrutura, mas mostram que a posse e o acesso podem divergir. Um cliente pode possuir um servidor enquanto depende do status de pagamento e da autorização do local para acessá-lo.
Os contratos de fornecedores criam outro risco de concentração quando um revendedor fica entre o cliente e a instalação. O cliente final pode pagar a WCG, enquanto a Vocus ou outra entidade contrata com o operador do data center. Se o acordo upstream mudar, o comprador deve saber se seu serviço continua, migra ou termina. A pertença corporativa pública não divulga a cadeia contratual para um pedido específico.
Os controles práticos são banais e valiosos: mais de um contato de faturamento autorizado, detalhes de fatura verificados, um procedimento de resolução de disputas documentado, lembretes de renovação, um registro de propriedade de licenças e um plano de continuidade que não dependa da conexão a um serviço suspenso. O cliente também deve saber se os créditos de serviço são automáticos ou precisam ser reivindicados. O acordo da Vocus exige uma solicitação de reembolso por escrito dentro de um prazo definido e aplica os valores aprovados como créditos na conta, e não em dinheiro.
É aqui que a capacidade hospedada revela sua dupla natureza. É uma reserva física e uma permissão legal contínua de usar essa reserva. Um servidor de reserva tem pouco valor se as credenciais do cliente, a alocação de endereço ou o acesso ao local terminarem com o contrato. A recuperabilidade deve incluir o acesso comercial, não apenas a sobrevivência do hardware.
A portabilidade começa antes da instalação da primeira carga de trabalho
Mover uma carga de trabalho hospedada não é uma operação. É um conjunto de exportações e substituições: dados, máquinas virtuais, configuração de aplicação, segredos, logs, nomes de domínio, registros DNS, certificados, endereços IP, licenças e conhecimento de suporte. Cada componente pode ter um proprietário e uma regra de transferência diferentes.
O próprio domínio WCG ilustra a separação. Uma licença de domínio, DNS autoritativo, hospedagem de e-mail e hospedagem web são serviços distintos, mesmo quando um único provedor vende os quatro. O guia da auDA para transferência de um domínio.au indica que um declarante pode mudar para outro provedor elegível e explica o código de autorização de transferência. Isso protege a portabilidade do domínio. Isso não move automaticamente o conteúdo da zona, os dados de e-mail, os arquivos do site ou o ambiente do servidor.
A portabilidade IP é mais restrita. O cronograma de nuvem da Vocus indica que os endereços fornecidos pelo provedor não podem ser transferidos e que o direito de usá-los termina com o serviço. O uso de endereços pertencentes ao cliente está sujeito ao status do registro, aprovação e disponibilidade do serviço. Uma aplicação construída em torno de endereços Vocus pode, portanto, exigir modificações de DNS, atualizações de listas de permissão de parceiros e uma transição cuidadosamente planejada. O antigo registro AS18104 não concede a cada cliente hospedado endereços WCG portáteis.
A portabilidade da computação não é especificada publicamente no nível WCG. A Vocus usa uma tecnologia de virtualização amplamente conhecida e anuncia uma interface de gerenciamento única, mas a familiaridade não é um compromisso de exportação. Um cliente deve saber se pode exportar discos virtuais em um formato documentado, a que velocidade, com qual suporte e a que custo. A consistência do banco de dados, o formato de snapshot e as licenças de software podem determinar se uma imagem exportada realmente inicia em outro lugar.
A largura de banda pode ser a parte mais lenta. Um grande conjunto de dados fácil de armazenar pode levar dias ou semanas para ser copiado em um link restrito. Se o serviço já estiver degradado ou suspenso, a taxa de exportação efetiva pode ser menor. Mídias físicas podem ser mais rápidas para transferências muito grandes, mas o cliente precisa então de criptografia, cadeia de custódia, mídias compatíveis e um processo de devolução acordado. As disposições do cronograma de nuvem sobre fitas, por exemplo, exigem uma solicitação oportuna se as mídias devem ser devolvidas na rescisão e não incluem restauração a partir de fita por padrão.
Um projeto de saída robusto é testado quando o serviço está saudável. O cliente deve exportar uma máquina representativa e um conjunto de dados, reconstruir a rede em um ambiente neutro, girar os segredos, confirmar a autoridade DNS, medir o tempo de transferência e verificar se os backups são legíveis sem a conta de origem. O exercício transforma a palavra "portátil" em uma duração observada e uma lista de dependências.
Para a WCG, nenhum documento público fornece um formato de exportação atual, uma taxa de saída garantida, um escopo de suporte à migração ou um período de retenção pós-rescisão para um serviço com a marca WCG. Não são razões para presumir o pior. São condições que devem ser fornecidas antes que um comprador possa avaliar o custo da saída.
Os pontos de entrega australianos não respondem a todas as questões de localidade
A página pública de IaaS da Vocus indica que seus pontos de entrega estão em Sydney, Melbourne e Perth e que estão hospedados em seus data centers. É uma evidência útil para uma opção de computação primária australiana. É mais específica do que uma reivindicação geral de soberania. Ainda não identifica a localização de cada cópia nem de cada pessoa que pode acessar o ambiente.
A localidade dos dados tem várias camadas. O disco virtual primário pode estar em Sydney. As réplicas podem estar em Melbourne ou Perth. As fitas de backup podem ser mantidas por um terceiro fora do local. Os logs de monitoramento, registros de suporte e informações de conta podem ser processados em outro lugar. Um provedor pode fornecer suporte remoto de outra jurisdição. A interconexão com uma nuvem pública pode mover o tráfego do cliente para um provedor distinto, cujas regiões e arranjos de suporte seguem outro contrato.
O próprio cronograma de nuvem da Vocus indica que os serviços em diferentes zonas podem usar infraestrutura e software diferentes. Indica que o armazenamento externo em fita pode envolver terceiros. Essas disposições não estabelecem armazenamento no exterior, mas impedem que um comprador trate um endereço corporativo australiano como prova de que todos os dados permanecem na Austrália.
Para informações pessoais, as próprias obrigações legais do cliente permanecem relevantes. A página de princípios australianos de privacidade do Office of the Australian Information Commissioner define o APP 8 sobre divulgação transfronteiriça. As diretrizes atuais do Capítulo 8 explicam a estrutura de responsabilidade e as exceções. Saber se uma transferência específica é uma divulgação e quais medidas são razoáveis depende dos fatos e da lei aplicável. Uma cidade de data center em um folheto não pode responder a essa questão jurídica sozinha.
Um cronograma de localidade deve identificar separadamente os dados primários, réplicas, backups, logs, dados de conta, acesso de suporte e subcontratados. Também deve indicar como as mudanças de localidade são notificadas e como os dados são retornados ou destruídos no final. Clientes com cargas de trabalho governamentais, de saúde, financeiras ou outras regulamentadas podem precisar de controles adicionais além da estrutura geral de privacidade.
A conclusão apropriada para a WCG é estreita. Uma opção de hospedagem primária australiana é plausível e apoiada no nível do grupo Vocus. As evidências públicas não estabelecem a arquitetura completa de localidade para qualquer serviço WCG atual. A soberania dos dados é, portanto, uma propriedade no nível do pedido das zonas, cópias, caminhos de acesso e fornecedores selecionados, e não um atributo herdado automaticamente das letras AU em um registro de registro.
Quais evidências atuais preencheriam as maiores lacunas
O registro público da WCG é suficientemente sólido para evitar um erro de identidade e suficientemente fraco para exigir divulgação técnica direta. Um comprador não precisa de uma visão secreta de todo o parque do provedor. Ele precisa de evidências relacionadas ao serviço que efetivamente receberá.
Em primeiro lugar, o provedor deve identificar a entidade contratante, a entidade operacional e a entidade de suporte. Se a Wholesale Communications Group Pty Ltd assina o pedido enquanto a Vocus Pty Ltd opera a rede e outra empresa Vocus controla um contrato de instalação, essa divisão de responsabilidades deve ser explícita. O pedido deve incorporar os termos padrão aplicáveis, o cronograma de nuvem e o acordo de nível de serviço por versão.
Em segundo lugar, a arquitetura deve nomear os sites primário e de recuperação, não apenas o país. Deve identificar se o site é operado pela Vocus ou por um parceiro, se equipamento do cliente ou do provedor está envolvido, e se o serviço usa uma ou duas fontes de alimentação, um ou dois dispositivos de rede, e acesso protegido ou não protegido. Um cliente não precisa saber a localização de cada cabo, mas precisa saber se dois caminhos aparentes compartilham um conduíte, um roteador, uma interconexão ou um fornecedor upstream.
Em terceiro lugar, a evidência de capacidade deve distinguir a alocação atual da margem de manobra em caso de falha. A divulgação útil não é o tamanho total da frota; é saber se a zona de recuperação selecionada possui recursos reservados para a carga de trabalho do cliente, quais limites de desempenho se aplicam em caso de contenção, e qual estoque de reposição e cobertura de fornecedor existem. Um exercício de failover recente é uma evidência mais forte do que um adjetivo de projeto.
Em quarto lugar, o suporte deve ser executável. O cliente precisa do número 24 horas, dos identificadores de serviço, dos níveis de escalonamento nomeados, das definições de gravidade, do método de notificação e da autoridade para solicitar trabalho urgente. Deve saber se as mãos remotas estão incluídas, são cobradas ou fornecidas por terceiros, e se um defeito grave de hardware pode ser tratado fora do horário comercial normal.
Em quinto lugar, a recuperação e a saída exigem testes mensuráveis. O escopo do backup, a retenção, a imutabilidade, a responsabilidade pela restauração, os objetivos de recuperação, o formato de exportação, o método de saída, a transição de endereço e o prazo de exclusão devem ser documentados por escrito. Uma restauração e exportação de amostra devem ser realizadas antes que a dependência em produção se torne profunda.
Finalmente, as evidências de roteamento atuais devem ser coletadas a partir do serviço entregue. O ASN de origem, a propriedade do endereço, os caminhos upstream visíveis e o projeto de conectividade privada podem todos diferir do AS18104. Um trace route, informações BGP quando aplicável, um pedido de compra e um diagrama de rede resolveriam mais do que o texto do registro herdado.
Essas demandas não são uma acusação de que o serviço carece de resiliência. São a tradução normal de uma oferta em nível de grupo para uma dependência em nível de cliente. A combinação incomum da continuidade corporativa da WCG e do roteamento público dormente torna essa tradução impossível de pular.
O veredito operacional
A WCG não é um nome vazio nem um operador de nuvem transparente e independente. A Wholesale Communications Group Pty Ltd está ativa, permanece nas divulgações atuais do grupo Vocus, mantém um espaço de nomes de domínio vivo e está associada ao AS18104. Esses fatos apoiam a identidade e a continuidade.
As evidências de rede apontam em uma direção diferente. O AS18104 está registrado, mas não é atualmente visível como origem. Sua última observação de rota data de 2012. A declaração de site único em Sydney no PeeringDB é antiga e não mostra nenhuma conexão a um ponto de troca público. O domínio da WCG resolve por meio de outra rede Vocus e não fornece um site de venda público funcional. A proposta de hospedagem atual mais sustentável é, portanto, a oferta do grupo Vocus, e não uma plataforma autônoma comprovada pelo ASN WCG.
Essa oferta do grupo tem reivindicações reais de infraestrutura: três cidades IaaS australianas, um parque nacional de data centers, um alcance extenso de instalações externas e suporte 24 horas. Suas condições públicas também tornam a estrutura de dependência legível. A computação pode exigir conectividade contratada separadamente. A presença em várias cidades não inclui recuperação de desastres por padrão. A precisão do backup e os testes de restauração permanecem em parte responsabilidade do cliente. Os endereços IP atribuídos não vão com o cliente. Reparos e manutenção podem atravessar limites de sites e fornecedores.
Os recursos são limitados por objetivos, exclusões e procedimentos de reclamação.
Para os clientes, o risco central não é que a capacidade hospedada seja imaginária. É que a capacidade nominal, a capacidade utilizável e a capacidade recuperável podem ser diferentes, enquanto o nome WCG não revela quais ativos e condições da Vocus preenchem a lacuna. Uma compra sólida identifica o provedor real, o site, a rota, o nível de proteção, a capacidade de reserva, a autoridade de reparo, a reserva de recuperação e o mecanismo de saída.
O julgamento final é, portanto, condicional. A WCG tem um contexto de grupo crível e um lar jurídico identificável, mas o AS18104 atualmente não pode sustentar uma reivindicação de roteamento independente, e os documentos públicos não estabelecem racks específicos da WCG, diversidade de trânsito, estoque de servidores ou failover testado. Os compradores devem tratar a disponibilidade atual como evidência de pedido de compra: forte quando vinculada a recursos Vocus nomeados e recuperação testada, fraca quando inferida a partir de um número de rede herdado ou de um nome corporativo sozinho.

