Alternativa apenas UE a Alibaba Cloud.

Alibaba Cloud (Aliyun) is the largest cloud provider in Asia and the third-largest globally. Alibaba Group Holding Limited is incorporated in the Cayman Islands but operationally and effectively controlled from China. The PRC National Intelligence Law (2017) Article 7 obliges Chinese organisations to "support, assist and cooperate with state intelligence work" - which is the Chinese equivalent of the US CLOUD Act and arguably broader. The Frankfurt and London regions of Alibaba Cloud are EU-located but PRC-controlled. For EU buyers needing Schrems II-style sovereignty, Alibaba Cloud raises a third-country exposure that is legally even less defensible than US providers.

China (PRC) 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 (PRC)
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

Alibaba Cloud usage in EU mid-market is concentrated in specific patterns: cross-border e-commerce serving Chinese consumers, EU subsidiaries of Chinese parent companies, or companies that adopted Aliyun for genuinely China-specific compute and now find the EU side under regulatory pressure. The triggers we see for migration: EU customers (B2B) refusing data processing through Aliyun, NIS2 essential-entity classification flagging PRC providers as supply-chain risk, or board-level concern after the 2024 EU regulatory tightening on Chinese cloud and AI providers. The EU sovereign stack handles the EU-side workloads cleanly; China-specific workloads remain on a documented hybrid where appropriate.

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.

Weeks 1-3

Audit + traffic-region split

Inventory Aliyun services and classify by traffic region: serving Chinese mainland users (may stay on Aliyun, document exposure for EU data), serving EU users (priority migration to sovereign EU stack). Output: phased plan with explicit boundary.
Weeks 3-10

EU-facing workloads cutover

EU traffic gradually shifted to the EU sovereign stack. Database replicas pre-staged. Storage sync. Edge migrations to Bunny.net.
Weeks 10-14

Decommission EU side of Aliyun

Final cutover of EU workloads. Aliyun account scoped down to China-mainland-only workloads if those remain. EU customer DPAs updated to reflect new processor list.

Aliyun-to-EU cost comparison varies more than US migrations. For pure compute, EU sovereign stack is competitive or cheaper. For Aliyun-specific managed services (PolarDB at scale, Tablestore), the migration may not be cost-driven but compliance-driven. The strongest case is regulatory: GDPR penalties for inadequate Schrems II-style safeguards on PRC providers can dwarf any infrastructure cost difference.

Perguntas frequentes

Ver todas as perguntas frequentes

What is the legal regime that makes Alibaba Cloud problematic for EU data?

Three primary instruments: the PRC Cybersecurity Law (2017) requires storage of certain data within China and grants government access; the Data Security Law (2021) extends data-handling obligations and allows extraterritorial application; Article 7 of the National Intelligence Law (2017) compels cooperation with state intelligence work. The combined effect is that PRC-controlled entities are required to provide access to data on government request. For GDPR purposes, this is a third-country transfer with high regulatory exposure.

But Alibaba Cloud International is registered in Singapore - does that change things?

Marginally. Alibaba Cloud Singapore is a subsidiary of Alibaba Group Holding Limited (Cayman Islands) which is operationally controlled from Hangzhou. The same parent jurisdiction analysis that affects US subsidiaries applies here, with the additional consideration that PRC laws have explicit extraterritorial provisions.

We need to serve customers in mainland China - how does that work?

A documented hybrid: Aliyun (or another PRC provider) for China-mainland-served traffic, EU sovereign stack for EU-served traffic, with a strict boundary on personal data. The boundary is documented in the DPA and reviewed quarterly. Many of our cross-border e-commerce clients run exactly this pattern.

Are there sovereign EU alternatives for the China-specific services?

For services that exist specifically because of China-side traffic patterns (PolarDB-X for cross-region active-active in PRC, Aliyun CDN for mainland delivery), there are no EU sovereign equivalents because the use case is China-specific. For everything else (compute, storage, basic managed databases), the EU sovereign stack covers it cleanly.

How long does an Alibaba Cloud exit take?

For typical EU-side workloads (compute, RDS, OSS, ACK): 8-14 weeks elapsed time. For mixed cross-border workloads where the China side stays: 6-10 weeks for the EU-side migration only. The hybrid model often takes longer to design than execute.

What about Huawei Cloud or Tencent Cloud?

Same legal analysis as Alibaba Cloud. All three are PRC-controlled entities subject to the same combination of Cybersecurity Law, Data Security Law and National Intelligence Law obligations. From a Schrems II perspective, the analysis is materially identical.

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