Alternativa apenas UE a Alibaba Cloud.

A Alibaba Cloud (Aliyun) é o maior cloud provider na Ásia e o terceiro maior globalmente. A Alibaba Group Holding Limited está incorporada nas Ilhas Caimão, mas é operacional e efetivamente controlada a partir da China. A Lei de Inteligência Nacional da RPC (2017), Artigo 7, obriga organizações chinesas a "apoiar, assistir e cooperar com o trabalho de inteligência do Estado" - o equivalente chinês do CLOUD Act dos EUA e discutivelmente mais abrangente. As regiões de Frankfurt e Londres da Alibaba Cloud estão localizadas na UE mas são controladas pela RPC. Para compradores da UE que necessitam de soberania no estilo Schrems II, a Alibaba Cloud levanta uma exposição a país terceiro que é legalmente ainda menos defensável do que os providers dos EUA.

China (RPC) Stack de substituição, apenas UE 12 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Alibaba Cloud
Sede: Hangzhou, CN
Jurisdição: China (RPC)
Regime jurídico: PRC Cybersecurity Law, Data Security Law, National Intelligence Law (Art. 7)

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Alibaba Cloud

A utilização da Alibaba Cloud no mid-market da UE concentra-se em padrões específicos: e-commerce transfronteiriço a servir consumidores chineses, subsidiárias na UE de empresas-mãe chinesas, ou empresas que adotaram a Aliyun para compute genuinamente específico da China e agora encontram o lado da UE sob pressão regulatória. Os gatilhos que observamos para migração: clientes da UE (B2B) a recusar processamento de dados através da Aliyun, classificação de entidade essencial pela NIS2 a sinalizar providers da RPC como risco de supply-chain, ou preocupação a nível de board após o aperto regulatório da UE em 2024 sobre providers chineses de cloud e AI. A stack soberana da UE trata os workloads do lado da UE de forma limpa; workloads específicos da China permanecem num modelo híbrido documentado, quando apropriado.

Alibaba Cloud serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Alibaba Cloud com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Alibaba Cloud serviço	O que usamos no lugar	Nota de engenharia
Elastic Compute Service (ECS)	Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.	Migração de VM padrão. Reconstrução da imagem de CentOS/Aliyun Linux para Rocky/Alma/Debian. A maioria das stacks de aplicações transfere-se sem alterações.
Object Storage Service (OSS)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	O OSS suporta API compatível com S3; a migração resume-se à configuração do endpoint mais sincronização de dados.
ApsaraDB RDS	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	O RDS usa MySQL/PostgreSQL/SQL Server por baixo; a migração é feita via replicação lógica ou dump/restore, dependendo do tamanho.
Container Service for Kubernetes (ACK)	Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.	ACK é Kubernetes upstream com addons específicos da Aliyun; nginx-ingress e cert-manager padrão substituem os equivalentes específicos do ACK.
Function Compute (FaaS)	Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.	A migração de funções é mecânica; os modelos de runtime portam-se sem problemas.
Server Load Balancer (SLB)	Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.	Load balancing L4/L7 padrão em todas as opções europeias.
Anti-DDoS Pro	Binadit Private Infrastructure. Filtragem volumétrica upstream, com rate limiting e CrowdSec na edge da aplicação.	Ataques volumétricos são absorvidos a montante dos seus servers. Abusos na camada de aplicação são tratados onde podem efetivamente ser compreendidos, junto ao seu tráfego.
Web Application Firewall	Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.	Os conjuntos de regras são transferíveis; a cobertura OWASP Top 10 é padrão em todo o lado.
CDN	Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.	A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.
Alibaba Cloud DNS	Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.	Migração de zona padrão.
Tablestore (NoSQL)	Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL com JSONB onde o modelo de documentos é mais simples do que parece.	Para workloads wide-column, ScyllaDB é o padrão open-source moderno.
PolarDB	Binadit Managed Cloud Platform. Failover de PostgreSQL gerido pelo Patroni entre nós, com promoção automática.	O PolarDB é compatível com MySQL/PostgreSQL; a replicação lógica trata da migração.

Elastic Compute Service (ECS)

O que usamos no lugar: Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.
Nota de engenharia: Migração de VM padrão. Reconstrução da imagem de CentOS/Aliyun Linux para Rocky/Alma/Debian. A maioria das stacks de aplicações transfere-se sem alterações.

Object Storage Service (OSS)

O que usamos no lugar: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia: O OSS suporta API compatível com S3; a migração resume-se à configuração do endpoint mais sincronização de dados.

ApsaraDB RDS

O que usamos no lugar: Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
Nota de engenharia: O RDS usa MySQL/PostgreSQL/SQL Server por baixo; a migração é feita via replicação lógica ou dump/restore, dependendo do tamanho.

Container Service for Kubernetes (ACK)

O que usamos no lugar: Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.
Nota de engenharia: ACK é Kubernetes upstream com addons específicos da Aliyun; nginx-ingress e cert-manager padrão substituem os equivalentes específicos do ACK.

Function Compute (FaaS)

O que usamos no lugar: Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia: A migração de funções é mecânica; os modelos de runtime portam-se sem problemas.

Server Load Balancer (SLB)

O que usamos no lugar: Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.
Nota de engenharia: Load balancing L4/L7 padrão em todas as opções europeias.

Anti-DDoS Pro

O que usamos no lugar: Binadit Private Infrastructure. Filtragem volumétrica upstream, com rate limiting e CrowdSec na edge da aplicação.
Nota de engenharia: Ataques volumétricos são absorvidos a montante dos seus servers. Abusos na camada de aplicação são tratados onde podem efetivamente ser compreendidos, junto ao seu tráfego.

Web Application Firewall

O que usamos no lugar: Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.
Nota de engenharia: Os conjuntos de regras são transferíveis; a cobertura OWASP Top 10 é padrão em todo o lado.

CDN

O que usamos no lugar: Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.
Nota de engenharia: A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.

Alibaba Cloud DNS

O que usamos no lugar: Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.
Nota de engenharia: Migração de zona padrão.

Tablestore (NoSQL)

O que usamos no lugar: Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL com JSONB onde o modelo de documentos é mais simples do que parece.
Nota de engenharia: Para workloads wide-column, ScyllaDB é o padrão open-source moderno.

PolarDB

O que usamos no lugar: Binadit Managed Cloud Platform. Failover de PostgreSQL gerido pelo Patroni entre nós, com promoção automática.
Nota de engenharia: O PolarDB é compatível com MySQL/PostgreSQL; a replicação lógica trata da migração.

Como migramos de Alibaba Cloud

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

Semanas 1-3

Auditoria + divisão de regiões de tráfego

Inventariar os serviços Aliyun e classificar por região de tráfego: a servir utilizadores da China continental (pode manter-se no Aliyun, documentar a exposição de dados da UE), a servir utilizadores da UE (migração prioritária para stack soberana na UE). Resultado: plano faseado com fronteira explícita.
Semanas 3-10

Migração de workloads direcionados à UE

Tráfego direcionado à UE migrado gradualmente para a stack soberana da UE. Réplicas de base de dados pré-preparadas. Sincronização de storage. Migrações de edge para Bunny.net.
Semanas 10-14

Descomissionar o lado UE da Aliyun

Migração final dos workloads da UE. Conta Aliyun reduzida a workloads exclusivamente da China continental, caso permaneçam. DPAs de clientes da UE atualizados para refletir a nova lista de processadores.

A comparação de custos entre Aliyun e UE varia mais do que as migrações dos EUA. Para compute puro, a stack soberana da UE é competitiva ou mais barata. Para serviços gerenciados específicos da Aliyun (PolarDB à escala, Tablestore), a migração pode não ser motivada por custo, mas por compliance. O argumento mais forte é regulatório: penalizações de GDPR por salvaguardas inadequadas no estilo Schrems II em providers da RPC podem eclipsar qualquer diferença de custo de infraestrutura.

Perguntas frequentes

Ver todas as perguntas frequentes

Qual é o regime legal que torna a Alibaba Cloud problemática para dados da UE?

Três instrumentos principais: a Lei de Cibersegurança da RPC (2017) exige o armazenamento de determinados dados dentro da China e concede acesso ao governo; a Lei de Segurança de Dados (2021) alarga as obrigações de tratamento de dados e permite aplicação extraterritorial; o Artigo 7.º da Lei de Inteligência Nacional (2017) obriga à cooperação com o trabalho de inteligência do Estado. O efeito combinado é que entidades controladas pela RPC são obrigadas a fornecer acesso a dados a pedido do governo. Para efeitos de RGPD, isto é uma transferência para país terceiro com elevada exposição regulatória.

Mas a Alibaba Cloud International está registada em Singapura - isso altera a situação?

Marginalmente. A Alibaba Cloud Singapore é uma subsidiária da Alibaba Group Holding Limited (Ilhas Caimão), operacionalmente controlada a partir de Hangzhou. A mesma análise de jurisdição da empresa-mãe que afeta subsidiárias dos EUA aplica-se aqui, com a consideração adicional de que as leis da RPC têm disposições extraterritoriais explícitas.

Precisamos de servir clientes na China continental - como é que isso funciona?

Um híbrido documentado: Aliyun (ou outro provedor da RPC) para tráfego servido na China continental, stack soberana da UE para tráfego servido na UE, com uma fronteira estrita sobre dados pessoais. Essa fronteira está documentada no DPA e é revista trimestralmente. Muitos dos nossos clientes de e-commerce transfronteiriço seguem exatamente este padrão.

Existem alternativas soberanas na UE para os serviços específicos da China?

Para serviços que existem especificamente devido a padrões de tráfego do lado da China (PolarDB-X para active-active entre regiões na RPC, Aliyun CDN para entrega no continente), não há equivalentes soberanos da UE porque o caso de uso é específico da China. Para tudo o resto (compute, storage, bases de dados geridas básicas), a stack soberana da UE cobre isso perfeitamente.

Quanto tempo demora uma saída do Alibaba Cloud?

Para workloads típicos do lado da UE (compute, RDS, OSS, ACK): 8-14 semanas de tempo decorrido. Para workloads mistos transfronteiriços em que o lado da China permanece: 6-10 semanas apenas para a migração do lado da UE. O modelo híbrido demora frequentemente mais tempo a desenhar do que a executar.

E quanto à Huawei Cloud ou Tencent Cloud?

Mesma análise jurídica que a Alibaba Cloud. As três são entidades controladas pela RPC, sujeitas à mesma combinação de obrigações da Lei de Cibersegurança, Lei de Segurança de Dados e Lei de Inteligência Nacional. Do ponto de vista do Schrems II, a análise é materialmente idêntica.

Planeie a sua saída de Alibaba Cloud.

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.

Agendar uma chamada Comparar outro fornecedor