Alternativa apenas UE a AWS.

Amazon Web Services is the original public cloud - and the original Schrems II problem. The same EU regions that make AWS technically usable for European workloads do not change the parent jurisdiction: AWS Inc. is a Delaware corporation, AWS EMEA SARL is a Luxembourg subsidiary fully controlled by it, and the CLOUD Act applies to both. For audited workloads, regulated industries and any business that has had a customer ask "is your provider US-subpoenable?", the honest answer on AWS is yes. Below is the engineering-grade map for getting off it.

United States Stack de substituição, apenas UE 14 serviços mapeados
Fornecedor
AWS
Sede
Seattle, WA
Jurisdição
United States
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

The drivers we hear in scoping calls are consistent: a procurement gate that now demands "no third-country data processor" (NIS2, DORA, public sector), a customer audit (typically B2B enterprise or healthcare) that flagged the AWS relationship, escalating egress and bandwidth costs that look worse every quarter, or a leadership-level concern after the 2024-2025 round of EU-US transfer mechanism uncertainty. The technical lift to leave AWS is rarely the blocker it appears to be. The real friction is choreography: zero-downtime database migrations, DNS cutover, observability continuity. That is where a managed-infrastructure partner saves months.

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.

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.

  1. Weeks 1-2

    Audit & dependency map

    Inventory every AWS service in use, every IAM role, every Lambda, every cross-service call. Tag personal data flows. Output: a remediation plan with risk-ranked findings and an effort estimate per service.

  2. Weeks 3-6

    Soft dependencies & egress prep

    Replace CloudFront, Route 53, SES and CloudWatch first - zero application code changes for most. Move S3 buckets behind S3-compatible EU storage with dual-write during cutover. Pre-stage replicas of RDS in EU.

  3. Weeks 6-14

    Core compute & DB cutover

    Blue-green compute migration with DNS-level traffic shift. Streaming-replication database cutover during a low-traffic window. EKS workloads moved to managed EU K8s or self-managed Talos. Decommission AWS account once verified.

5-year TCO modelling on workloads we have actually migrated: typically 30-55% cheaper on EU sovereign infrastructure for predictable workloads, neutral to slightly higher for highly bursty workloads that benefit from sub-second autoscaling. Egress savings alone are often the difference between a positive and negative ROI.

Does using an AWS EU region (Frankfurt, Ireland, Stockholm) solve the Schrems II problem?
No. The data residency is in the EU but Amazon Web Services Inc. is the controller of the infrastructure under US law. The CLOUD Act allows US authorities to compel disclosure of data held by US-controlled entities anywhere in the world. The EDPB has explicitly flagged this as a Schrems II issue. AWS EMEA SARL is a Luxembourg subsidiary fully owned by AWS Inc.; that ownership chain is what the analysis turns on.
How long does an AWS exit take in practice?
For a mid-market application (10-50 EC2 instances, a couple of RDS databases, S3, CloudFront, SES) with a 6-10 person engineering team and competent operational support: 10-16 weeks elapsed time. With a managed-infrastructure partner driving the choreography (which is most of the actual work), 6-10 weeks.
What about AWS GovCloud or AWS Sovereign Cloud Europe?
AWS GovCloud is for US federal workloads and is not relevant to EU buyers. AWS European Sovereign Cloud (announced 2023, in build-out) is operated by EU-headquartered AWS staff in EU regions, but the parent legal entity remains Amazon Web Services Inc. Whether it is "sovereign enough" depends on your specific compliance regime; for many Schrems II analyses it is not sufficient because the parent jurisdiction is unchanged.
Will we lose features by leaving AWS?
Specific managed services (DynamoDB single-digit-ms, Aurora Serverless v2, Bedrock model access, SageMaker training on H100s) have no clean EU sovereign equivalents. For 90% of mid-market workloads - web applications, APIs, e-commerce, B2B SaaS, analytics on warehouses - the EU sovereign stack covers it. We tell you upfront if your workload sits in the 10% category.
Can we keep some AWS services and migrate the rest?
Yes - a hybrid is sometimes the right answer. The discipline is to keep AWS only for clearly non-personal workloads, and document the boundary in your DPA. We have run hybrids where AWS handles ML training (no personal data, batch-only) and the EU sovereign stack handles all customer-facing infrastructure.
What does a managed exit cost?
Project-based pricing, scoped after the audit. Typical mid-market AWS exit: €25-80k for the project, plus the ongoing managed-infrastructure retainer for the new EU stack. The first-year savings on AWS spend usually exceed the project cost.

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.