Alternativa apenas UE a AWS.

A Amazon Web Services é o public cloud original - e o problema Schrems II original. As mesmas regiões da UE que tornam a AWS tecnicamente utilizável para workloads europeus não alteram a jurisdição parent: a AWS Inc. é uma corporação de Delaware, a AWS EMEA SARL é uma subsidiária no Luxemburgo totalmente controlada por ela, e o CLOUD Act aplica-se a ambas. Para workloads auditados, indústrias reguladas e qualquer negócio a quem um cliente já tenha perguntado "o seu provider está sujeito a subpoena dos EUA?", a resposta honesta sobre a AWS é sim. Abaixo está o mapa de nível de engenharia para saída.

Estados Unidos Stack de substituição, apenas UE 14 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: AWS
Sede: Seattle, WA
Jurisdição: Estados Unidos
Regime jurídico: CLOUD Act, FISA 702, EO 12333

"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 AWS

Os motivos que ouvimos nas chamadas de scoping são consistentes: um requisito de procurement que agora exige "nenhum processador de dados de país terceiro" (NIS2, DORA, setor público), uma auditoria de cliente (tipicamente enterprise B2B ou saúde) que sinalizou a relação com a AWS, custos crescentes de egress e bandwidth que parecem piores a cada trimestre, ou uma preocupação a nível de liderança após a ronda de incerteza de 2024-2025 sobre o mecanismo de transferência UE-EUA. O esforço técnico para sair da AWS raramente é o bloqueio que parece ser. O verdadeiro atrito está na coreografia: migrações de bases de dados sem downtime, cutover de DNS, continuidade de observability. É aí que um parceiro de infraestrutura gerida poupa meses.

AWS 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 AWS com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

AWS serviço	O que usamos no lugar	Nota de engenharia
EC2 (compute)	Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.	Dimensionamos as instâncias de acordo com o seu perfil de carga real, em vez de um tier de catálogo, pelo que a maioria das migrações resulta em menos máquinas, e melhor utilizadas.
S3 (object storage)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	As APIs compatíveis com S3 são universais; a maior parte do código da aplicação requer apenas a alteração de um endpoint. Sem taxas de egress na maioria dos fornecedores europeus.
RDS / Aurora (managed DB)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	A replicação em streaming permite uma transição sem downtime. O preço do PostgreSQL gerido na UE é tipicamente 30-50% mais baixo do que o RDS equivalente.
CloudFront (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.
Route 53 (DNS)	Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.	As zones são exportadas e importadas como ficheiros de zone standard, pelo que esta é geralmente a parte menos problemática de uma migração. Reduza os TTLs uma semana antes.
Lambda (serverless)	Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.	Para deployments soberanos, Knative self-hosted em compute na UE é a solução mais limpa. A maioria dos workloads Lambda encaixa num pequeno cluster Kubernetes.
SES (email)	Binadit Managed Cloud Platform. Postfix com DKIM, SPF e DMARC, e Rspamd para filtragem.	Para volume transacional abaixo de 1M/mês, um relay Postfix devidamente configurado é operacionalmente mais simples e económico do que o SES.
SQS / SNS	Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, dependendo das garantias de entrega.	Message brokers geridos são raros no espaço soberano da UE. O modelo self-managed é o padrão; nós operamos isso para clientes.
EKS (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.	O K8s gerido em providers da UE tem paridade de funcionalidades para 95% das cargas de trabalho.
CloudWatch / X-Ray	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.	O padrão OpenTelemetry torna a migração trivial; o ganho operacional está nos dashboards consolidados e no preço zero por métrica.
IAM	Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.	Não existe substituto 1:1; a identidade cross-platform é reconstruída com Vault, providers OIDC (Keycloak) e roles por ferramenta.
WAF / Shield	Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.	As regras são ajustadas com base no seu tráfego em vez de serem entregues como um conjunto predefinido, o que é o que impede um WAF de bloquear silenciosamente clientes reais.
KMS	Binadit Private Infrastructure. Vault Transit para gestão de chaves, com chaves suportadas por HSM onde o regime de compliance o exigir.	Para cenários HYOK, HSM on-premises com BYOK do lado da cloud é o padrão soberano standard.
Secrets Manager / SSM Parameter Store	Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, com rotação automática de leases.	O Vault em infraestrutura europeia é a resposta de nível de produção. Nós fazemos o deployment e operamo-lo.

EC2 (compute)

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: Dimensionamos as instâncias de acordo com o seu perfil de carga real, em vez de um tier de catálogo, pelo que a maioria das migrações resulta em menos máquinas, e melhor utilizadas.

S3 (object storage)

O que usamos no lugar: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia: As APIs compatíveis com S3 são universais; a maior parte do código da aplicação requer apenas a alteração de um endpoint. Sem taxas de egress na maioria dos fornecedores europeus.

RDS / Aurora (managed DB)

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: A replicação em streaming permite uma transição sem downtime. O preço do PostgreSQL gerido na UE é tipicamente 30-50% mais baixo do que o RDS equivalente.

CloudFront (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.

Route 53 (DNS)

O que usamos no lugar: Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.
Nota de engenharia: As zones são exportadas e importadas como ficheiros de zone standard, pelo que esta é geralmente a parte menos problemática de uma migração. Reduza os TTLs uma semana antes.

Lambda (serverless)

O que usamos no lugar: Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia: Para deployments soberanos, Knative self-hosted em compute na UE é a solução mais limpa. A maioria dos workloads Lambda encaixa num pequeno cluster Kubernetes.

SES (email)

O que usamos no lugar: Binadit Managed Cloud Platform. Postfix com DKIM, SPF e DMARC, e Rspamd para filtragem.
Nota de engenharia: Para volume transacional abaixo de 1M/mês, um relay Postfix devidamente configurado é operacionalmente mais simples e económico do que o SES.

SQS / SNS

O que usamos no lugar: Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, dependendo das garantias de entrega.
Nota de engenharia: Message brokers geridos são raros no espaço soberano da UE. O modelo self-managed é o padrão; nós operamos isso para clientes.

EKS (managed Kubernetes)

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: O K8s gerido em providers da UE tem paridade de funcionalidades para 95% das cargas de trabalho.

CloudWatch / X-Ray

O que usamos no lugar: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.
Nota de engenharia: O padrão OpenTelemetry torna a migração trivial; o ganho operacional está nos dashboards consolidados e no preço zero por métrica.

IAM

O que usamos no lugar: Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.
Nota de engenharia: Não existe substituto 1:1; a identidade cross-platform é reconstruída com Vault, providers OIDC (Keycloak) e roles por ferramenta.

WAF / Shield

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: As regras são ajustadas com base no seu tráfego em vez de serem entregues como um conjunto predefinido, o que é o que impede um WAF de bloquear silenciosamente clientes reais.

KMS

O que usamos no lugar: Binadit Private Infrastructure. Vault Transit para gestão de chaves, com chaves suportadas por HSM onde o regime de compliance o exigir.
Nota de engenharia: Para cenários HYOK, HSM on-premises com BYOK do lado da cloud é o padrão soberano standard.

Secrets Manager / SSM Parameter Store

O que usamos no lugar: Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, com rotação automática de leases.
Nota de engenharia: O Vault em infraestrutura europeia é a resposta de nível de produção. Nós fazemos o deployment e operamo-lo.

Como migramos de AWS

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-2

Auditoria e mapa de dependências

Inventariar todos os serviços AWS em uso, todas as roles IAM, todas as Lambdas, todas as chamadas entre serviços. Marcar os fluxos de dados pessoais. Resultado: um plano de remediação com conclusões classificadas por risco e uma estimativa de esforço por serviço.
Semanas 3-6

Preparação de dependências soft e egress

Substituir primeiro o CloudFront, Route 53, SES e CloudWatch - zero alterações ao código da aplicação na maioria dos casos. Mover os buckets S3 para armazenamento compatível com S3 na UE com escrita dupla durante o corte. Pré-preparar réplicas do RDS na UE.
Semanas 6-14

Cutover principal de Compute & DB

Migração de compute blue-green com transição de tráfego ao nível de DNS. Cutover da base de dados por streaming replication numa janela de baixo tráfego. Workloads EKS movidos para K8s gerido na UE ou Talos self-managed. Desativação da conta AWS após verificação.

Modelação de TCO a 5 anos em workloads que já migrámos efetivamente: normalmente 30-55% mais barato em infraestrutura soberana da UE para workloads previsíveis, neutro a ligeiramente mais caro para workloads altamente instáveis que beneficiam de autoscaling sub-segundo. As poupanças em egress são muitas vezes, por si só, a diferença entre um ROI positivo e negativo.

Perguntas frequentes

Ver todas as perguntas frequentes

Usar uma região EU da AWS (Frankfurt, Irlanda, Estocolmo) resolve o problema do Schrems II?

Não. A residência dos dados é na UE, mas a Amazon Web Services Inc. é a controladora da infraestrutura ao abrigo da lei dos EUA. O CLOUD Act permite que as autoridades dos EUA obriguem à divulgação de dados detidos por entidades controladas pelos EUA em qualquer parte do mundo. O EDPB já sinalizou explicitamente isto como uma questão de Schrems II. A AWS EMEA SARL é uma subsidiária no Luxemburgo totalmente detida pela AWS Inc.; é essa cadeia de propriedade que determina a análise.

Quanto tempo demora uma saída da AWS na prática?

Para uma aplicação mid-market (10-50 instâncias EC2, algumas bases de dados RDS, S3, CloudFront, SES) com uma equipa de engenharia de 6-10 pessoas e suporte operacional competente: 10-16 semanas de tempo decorrido. Com um parceiro de infraestrutura managed a coordenar a coreografia (que é a maior parte do trabalho real), 6-10 semanas.

E quanto à AWS GovCloud ou AWS Sovereign Cloud Europe?

A AWS GovCloud é destinada a workloads federais dos EUA e não é relevante para compradores da UE. A AWS European Sovereign Cloud (anunciada em 2023, em construção) é operada por staff da AWS sediado na UE em regiões da UE, mas a entidade legal parent continua a ser a Amazon Web Services Inc. Se é "soberana o suficiente" depende do seu regime de compliance específico; para muitas análises Schrems II não é suficiente, porque a jurisdição parent permanece inalterada.

Vamos perder funcionalidades ao deixar a AWS?

Serviços geridos específicos (DynamoDB com latência de dígito único em ms, Aurora Serverless v2, acesso a modelos Bedrock, treino SageMaker em H100s) não têm equivalentes soberanos UE limpos. Para 90% dos workloads de mid-market - aplicações web, APIs, e-commerce, B2B SaaS, analytics sobre warehouses - a stack soberana UE cobre isso. Informamos-lhe antecipadamente se o seu workload se enquadra na categoria dos 10%.

Podemos manter alguns serviços AWS e migrar o resto?

Sim - um modelo híbrido é por vezes a resposta certa. A disciplina é manter a AWS apenas para cargas de trabalho claramente não pessoais, e documentar a fronteira no seu DPA. Já implementámos modelos híbridos em que a AWS trata o treino de ML (sem dados pessoais, apenas em batch) e a stack soberana da UE trata toda a infraestrutura voltada para o cliente.

Quanto custa uma saída gerida?

Preços baseados em projeto, definidos após a auditoria. Saída típica de mid-market da AWS: €25-80k pelo projeto, mais a mensalidade contínua de infraestrutura gerida para a nova stack na UE. As poupanças no primeiro ano em despesa AWS normalmente excedem o custo do projeto.

Planeie a sua saída de AWS.

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