Alternatywa tylko UE dla AWS.

Amazon Web Services to oryginalna chmura publiczna - i oryginalny problem Schrems II. Te same regiony UE, które czynią AWS technicznie użytecznym dla europejskich obciążeń, nie zmieniają jurysdykcji podmiotu nadrzędnego: AWS Inc. jest spółką zarejestrowaną w stanie Delaware, AWS EMEA SARL jest luksemburską spółką zależną w pełni przez nią kontrolowaną, a CLOUD Act ma zastosowanie do obu. Dla obciążeń podlegających audytom, branż regulowanych i każdej firmy, której klient zapytał kiedyś "czy wasz dostawca podlega amerykańskim wezwaniom sądowym?", uczciwa odpowiedź w przypadku AWS brzmi: tak. Poniżej znajduje się mapa migracji na poziomie inżynierskim.

Stany Zjednoczone Stack zastępczy, wyłącznie UE 14 zmapowanych usług

Umów rozmowę Najpierw zeskanuj swoją domenę

Dostawca: AWS
Siedziba: Seattle, WA
Jurysdykcja: Stany Zjednoczone
Reżim prawny: CLOUD Act, FISA 702, EO 12333

"Region UE" to nie suwerenność. Decydują cztery pytania.

Rezydencja danych mówi, gdzie leżą bity. Suwerenność mówi, który system prawny może wymusić dostęp. Odpowiedź musi się bronić we wszystkich czterech punktach, inaczej stack nie jest suwerenny.

Rezydencja

Gdzie dane są fizycznie przechowywane?

Nie "w chmurze": które centrum danych, w jakim kraju, pod jaką jurysdykcją.

Podprzetwarzający

Kto jeszcze znajduje się w Państwa ścieżce danych?

Każdy dostawca dotykający danych: CDN, przekaźnik e-mail, tracker błędów, pipeline analityczny.

Jurysdykcja

Czyje prawa mogą wymusić ujawnienie?

Dostawca z siedzibą w USA podlega FISA 702 i CLOUD Act, nawet gdy dane leżą we Frankfurcie.

Depozyt kluczy

Kto faktycznie ma klucze szyfrujące?

Jeśli dostawca chmury trzyma zarówno dane, jak i klucze, może je odczytać, niezależnie od jakiejkolwiek umowy powierzenia.

Nie spełnia AWS · Azure · GCP · Region UE

Nie spełnia kryterium jurysdykcji i depozytu kluczy.

Bity w UE, spółka matka w USA, podprzetwarzający z USA w domyślnej ścieżce, klucze zarządzane przez dostawcę.

Spełnia Stack zarządzany przez Binadit

Spełnia wszystkie cztery kryteria.

Hostowane w UE na infrastrukturze z siedzibą europejską. Zero podprzetwarzających z USA w domyślnej ścieżce. Klucze klienta lub europejskiego KMS. Wymienieni z nazwy w Państwa DPA z Artykułu 28.

Dlaczego zespoły wychodzą AWS

Motywy, które słyszymy podczas rozmów zakresowych, są spójne: wymóg proceduralny narzucający „brak przetwarzania danych przez podmiot z kraju trzeciego” (NIS2, DORA, sektor publiczny), audyt klienta (zazwyczaj enterprise B2B lub ochrona zdrowia), który zakwestionował relację z AWS, rosnące koszty egress i przepustowości, które co kwartał wyglądają gorzej, lub obawy na poziomie zarządu po niepewności wokół mechanizmów transferu danych UE-USA w latach 2024-2025. Wysiłek techniczny związany z odejściem od AWS rzadko jest realną przeszkodą. Prawdziwym utrudnieniem jest koordynacja: migracje baz danych bez przestojów, przełączenie DNS, ciągłość obserwowalności. To właśnie tam partner zarządzający infrastrukturą oszczędza miesiące.

AWS usługi i ich odpowiedniki tylko z UE

Migracja to nie "zamiana jednej skrzynki na drugą". Poniższe mapowanie jest tym, co uruchamiamy dla klientów opuszczających AWS na gruncie Schrems II: pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.

AWS usługa	Czego używamy zamiast tego	Notatka inżynierska
EC2 (compute)	Binadit Managed Cloud Platform. Maszyny wirtualne KVM na Debianie lub Ubuntu, provisionowane za pomocą Terraform i konfigurowane za pomocą Ansible.	Dobieramy rozmiar instancji na podstawie rzeczywistego profilu obciążenia, a nie sztywnych poziomów z cennika, dzięki czemu większość migracji kończy się mniejszą liczbą lepiej wykorzystanych maszyn.
S3 (object storage)	Binadit Managed Cloud Platform. MinIO lub Ceph RGW, kompatybilne z S3.	API kompatybilne z S3 są uniwersalne; w większości przypadków kod aplikacji wymaga jedynie zmiany endpointu. Większość dostawców z UE nie pobiera opłat za egress.
RDS / Aurora (managed DB)	Binadit Managed Cloud Platform. PostgreSQL lub MySQL z Patroni do failover i pgBackRest do point-in-time recovery.	Replikacja strumieniowa umożliwia przełączenie bez przestoju. Ceny zarządzanego PostgreSQL w UE są zwykle o 30-50% niższe niż równoważny RDS.
CloudFront (CDN)	Wdrażamy i utrzymujemy dla Ciebie CDN w UE: Bunny.net lub KeyCDN, z cache'owaniem Nginx i Varnish na Twoim origin.	CDN to jedna z niewielu warstw, których nie utrzymujemy samodzielnie. Wybieramy dostawcę z UE, konfigurujemy nagłówki cache, strategię czyszczenia cache oraz origin shielding, i zarządzamy tym w ramach usługi managed.
Route 53 (DNS)	Binadit Managed Cloud Platform. PowerDNS lub Knot, autorytatywne, podpisane DNSSEC.	Strefy są eksportowane i importowane jako standardowe pliki stref, więc zazwyczaj jest to najmniej problematyczna część migracji. Obniż TTL na tydzień przed migracją.
Lambda (serverless)	Binadit Managed Cloud Platform. Knative lub OpenFaaS na Twoim klastrze Kubernetes.	Dla suwerennych wdrożeń najczystszym rozwiązaniem jest samodzielnie hostowany Knative na zasobach obliczeniowych w UE. Większość obciążeń Lambda mieści się w małym klastrze Kubernetes.
SES (email)	Binadit Managed Cloud Platform. Postfix z DKIM, SPF i DMARC, oraz Rspamd do filtrowania.	Przy wolumenie transakcyjnym poniżej 1 mln miesięcznie, prawidłowo skonfigurowany przekaźnik Postfix jest operacyjnie prostszy i tańszy niż SES.
SQS / SNS	Binadit Managed Cloud Platform. RabbitMQ, NATS lub Redis Streams, w zależności od gwarancji dostarczania.	Zarządzane brokery wiadomości są rzadkością w suwerennym środowisku UE. Standardowym wzorcem jest rozwiązanie self-managed; obsługujemy je dla klientów.
EKS (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes na Debianie lub Talos, z siecią Cilium i cert-manager do certyfikatów.	Zarządzane K8s u dostawców europejskich oferuje pełną funkcjonalną paralelność dla 95% obciążeń.
CloudWatch / X-Ray	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki i Tempo, połączone za pomocą OpenTelemetry.	Standard OpenTelemetry sprawia, że migracja jest trywialna; korzyścią operacyjną są skonsolidowane dashboardy i brak opłat za metrykę.
IAM	Binadit Managed Cloud Platform. Keycloak lub Authentik jako dostawca identity, z OIDC i SAML.	Nie istnieje odpowiednik 1:1; tożsamość międzyplatformowa jest odbudowywana przy użyciu Vault, dostawców OIDC (Keycloak) oraz ról przypisanych do poszczególnych narzędzi.
WAF / Shield	Binadit Managed Cloud Platform. Coraza lub ModSecurity z OWASP Core Rule Set, plus CrowdSec do blokowania behawioralnego.	Reguły są dostrajane na podstawie Twojego ruchu, a nie dostarczane jako domyślny zestaw, co zapobiega sytuacji, w której WAF po cichu blokuje prawdziwych klientów.
KMS	Binadit Private Infrastructure. Vault Transit do zarządzania kluczami, z kluczami wspieranymi przez HSM tam, gdzie wymaga tego reżim zgodności.	Dla scenariuszy HYOK, standardowym suwerennym wzorcem jest lokalny (on-premises) HSM w połączeniu z BYOK po stronie chmury.
Secrets Manager / SSM Parameter Store	Binadit Managed Cloud Platform. HashiCorp Vault lub Infisical, self-hosted, z automatyczną rotacją lease.	Vault na infrastrukturze UE to rozwiązanie produkcyjnej klasy. Wdrażamy je i utrzymujemy.

EC2 (compute)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Maszyny wirtualne KVM na Debianie lub Ubuntu, provisionowane za pomocą Terraform i konfigurowane za pomocą Ansible.
Notatka inżynierska: Dobieramy rozmiar instancji na podstawie rzeczywistego profilu obciążenia, a nie sztywnych poziomów z cennika, dzięki czemu większość migracji kończy się mniejszą liczbą lepiej wykorzystanych maszyn.

S3 (object storage)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. MinIO lub Ceph RGW, kompatybilne z S3.
Notatka inżynierska: API kompatybilne z S3 są uniwersalne; w większości przypadków kod aplikacji wymaga jedynie zmiany endpointu. Większość dostawców z UE nie pobiera opłat za egress.

RDS / Aurora (managed DB)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. PostgreSQL lub MySQL z Patroni do failover i pgBackRest do point-in-time recovery.
Notatka inżynierska: Replikacja strumieniowa umożliwia przełączenie bez przestoju. Ceny zarządzanego PostgreSQL w UE są zwykle o 30-50% niższe niż równoważny RDS.

CloudFront (CDN)

Czego używamy zamiast tego: Wdrażamy i utrzymujemy dla Ciebie CDN w UE: Bunny.net lub KeyCDN, z cache'owaniem Nginx i Varnish na Twoim origin.
Notatka inżynierska: CDN to jedna z niewielu warstw, których nie utrzymujemy samodzielnie. Wybieramy dostawcę z UE, konfigurujemy nagłówki cache, strategię czyszczenia cache oraz origin shielding, i zarządzamy tym w ramach usługi managed.

Route 53 (DNS)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. PowerDNS lub Knot, autorytatywne, podpisane DNSSEC.
Notatka inżynierska: Strefy są eksportowane i importowane jako standardowe pliki stref, więc zazwyczaj jest to najmniej problematyczna część migracji. Obniż TTL na tydzień przed migracją.

Lambda (serverless)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Knative lub OpenFaaS na Twoim klastrze Kubernetes.
Notatka inżynierska: Dla suwerennych wdrożeń najczystszym rozwiązaniem jest samodzielnie hostowany Knative na zasobach obliczeniowych w UE. Większość obciążeń Lambda mieści się w małym klastrze Kubernetes.

SES (email)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Postfix z DKIM, SPF i DMARC, oraz Rspamd do filtrowania.
Notatka inżynierska: Przy wolumenie transakcyjnym poniżej 1 mln miesięcznie, prawidłowo skonfigurowany przekaźnik Postfix jest operacyjnie prostszy i tańszy niż SES.

SQS / SNS

Czego używamy zamiast tego: Binadit Managed Cloud Platform. RabbitMQ, NATS lub Redis Streams, w zależności od gwarancji dostarczania.
Notatka inżynierska: Zarządzane brokery wiadomości są rzadkością w suwerennym środowisku UE. Standardowym wzorcem jest rozwiązanie self-managed; obsługujemy je dla klientów.

EKS (managed Kubernetes)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Kubernetes na Debianie lub Talos, z siecią Cilium i cert-manager do certyfikatów.
Notatka inżynierska: Zarządzane K8s u dostawców europejskich oferuje pełną funkcjonalną paralelność dla 95% obciążeń.

CloudWatch / X-Ray

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki i Tempo, połączone za pomocą OpenTelemetry.
Notatka inżynierska: Standard OpenTelemetry sprawia, że migracja jest trywialna; korzyścią operacyjną są skonsolidowane dashboardy i brak opłat za metrykę.

IAM

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Keycloak lub Authentik jako dostawca identity, z OIDC i SAML.
Notatka inżynierska: Nie istnieje odpowiednik 1:1; tożsamość międzyplatformowa jest odbudowywana przy użyciu Vault, dostawców OIDC (Keycloak) oraz ról przypisanych do poszczególnych narzędzi.

WAF / Shield

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Coraza lub ModSecurity z OWASP Core Rule Set, plus CrowdSec do blokowania behawioralnego.
Notatka inżynierska: Reguły są dostrajane na podstawie Twojego ruchu, a nie dostarczane jako domyślny zestaw, co zapobiega sytuacji, w której WAF po cichu blokuje prawdziwych klientów.

KMS

Czego używamy zamiast tego: Binadit Private Infrastructure. Vault Transit do zarządzania kluczami, z kluczami wspieranymi przez HSM tam, gdzie wymaga tego reżim zgodności.
Notatka inżynierska: Dla scenariuszy HYOK, standardowym suwerennym wzorcem jest lokalny (on-premises) HSM w połączeniu z BYOK po stronie chmury.

Secrets Manager / SSM Parameter Store

Czego używamy zamiast tego: Binadit Managed Cloud Platform. HashiCorp Vault lub Infisical, self-hosted, z automatyczną rotacją lease.
Notatka inżynierska: Vault na infrastrukturze UE to rozwiązanie produkcyjnej klasy. Wdrażamy je i utrzymujemy.

Jak migrujemy z AWS

Typowa migracja segmentu mid-market przebiega w trzech fazach. Poniższe liczby zakładają zespół inżynierski 6-10 osób i umiarkowanie złożony stack aplikacyjny.

Tygodnie 1-2

Audyt i mapa zależności

Zinwentaryzuj każdą używaną usługę AWS, każdą rolę IAM, każdą funkcję Lambda, każde wywołanie między usługami. Oznacz przepływy danych osobowych. Wynik: plan naprawczy z ustaleniami uszeregowanymi według ryzyka oraz szacunkiem nakładu pracy dla każdej usługi.
Tygodnie 3-6

Miękkie zależności i przygotowanie do egress

Najpierw zastąp CloudFront, Route 53, SES i CloudWatch - dla większości bez zmian w kodzie aplikacji. Przenieś kubełki S3 za storage kompatybilny z S3 w UE, z podwójnym zapisem podczas przełączenia. Przygotuj wcześniej repliki RDS w UE.
Tygodnie 6-14

Przełączenie głównego Compute i DB

Migracja compute typu blue-green z przełączeniem ruchu na poziomie DNS. Przełączenie bazy danych ze streaming replication podczas okna niskiego ruchu. Obciążenia EKS przenoszone do zarządzanego K8s w UE lub self-managed Talos. Dekomisja konta AWS po weryfikacji.

Modelowanie 5-letniego TCO na obciążeniach, które faktycznie zmigrowaliśmy: zazwyczaj 30-55% taniej na suwerennej infrastrukturze UE dla przewidywalnych obciążeń, neutralnie do nieco droższego dla mocno zmiennych obciążeń, które korzystają z autoskalowania poniżej sekundy. Same oszczędności na egress często decydują o różnicy między dodatnim a ujemnym ROI.

Często zadawane pytania

Zobacz wszystkie często zadawane pytania

Czy użycie regionu AWS w UE (Frankfurt, Irlandia, Sztokholm) rozwiązuje problem Schrems II?

Nie. Rezydencja danych jest w UE, ale Amazon Web Services Inc. jest administratorem infrastruktury na mocy prawa USA. CLOUD Act pozwala amerykańskim władzom żądać ujawnienia danych przechowywanych przez podmioty kontrolowane przez USA, niezależnie od miejsca na świecie. EDPB wyraźnie zgłosił to jako problem w kontekście Schrems II. AWS EMEA SARL to luksemburska spółka zależna w pełni należąca do AWS Inc.; to właśnie ten łańcuch własności jest kluczowy dla analizy.

Ile w praktyce trwa wyjście z AWS?

Dla aplikacji z segmentu mid-market (10-50 instancji EC2, kilka baz RDS, S3, CloudFront, SES) z zespołem inżynieryjnym liczącym 6-10 osób i kompetentnym wsparciem operacyjnym: 10-16 tygodni czasu trwania. Z partnerem zarządzającym infrastrukturą prowadzącym koordynację (co stanowi większość rzeczywistej pracy): 6-10 tygodni.

A co z AWS GovCloud lub AWS Sovereign Cloud Europe?

AWS GovCloud jest przeznaczony dla amerykańskich obciążeń federalnych i nie ma znaczenia dla nabywców z UE. AWS European Sovereign Cloud (zapowiedziany w 2023 r., w trakcie budowy) jest obsługiwany przez pracowników AWS z siedzibą w UE w regionach unijnych, ale podmiot prawny nadrzędny pozostaje Amazon Web Services Inc. To, czy jest "wystarczająco suwerenny", zależy od konkretnego reżimu zgodności - w wielu analizach Schrems II nie jest to wystarczające, ponieważ jurysdykcja podmiotu nadrzędnego pozostaje bez zmian.

Czy stracimy funkcje, odchodząc od AWS?

Konkretne usługi zarządzane (DynamoDB z opóźnieniami rzędu pojedynczych milisekund, Aurora Serverless v2, dostęp do modeli Bedrock, trening SageMaker na H100) nie mają czystych, suwerennych odpowiedników w UE. Dla 90% obciążeń z segmentu mid-market - aplikacji webowych, API, e-commerce, B2B SaaS, analityki na hurtowniach danych - suwerenny stos UE w pełni to pokrywa. Informujemy z góry, jeśli Twoje obciążenie mieści się w kategorii pozostałych 10%.

Czy możemy zachować część usług AWS i zmigrować resztę?

Tak - model hybrydowy bywa właściwą odpowiedzią. Zasada polega na tym, by AWS wykorzystywać wyłącznie do zadań jednoznacznie niezwiązanych z danymi osobowymi i udokumentować tę granicę w DPA. Realizowaliśmy modele hybrydowe, w których AWS obsługuje trenowanie ML (bez danych osobowych, wyłącznie batch), a suwerenny stos UE obsługuje całą infrastrukturę zorientowaną na klienta.

Ile kosztuje zarządzane wyjście (exit)?

Wycena projektowa, ustalana po audycie. Typowe wyjście z AWS dla firm z segmentu mid-market: 25-80 tys. € za projekt, plus bieżący abonament za zarządzaną infrastrukturę nowego stosu w UE. Oszczędności w pierwszym roku na wydatkach AWS zwykle przewyższają koszt projektu.

Zaplanuj wyjście z AWS.

30-minutowa rozmowa zakresowa. Mapujemy Państwa stack względem alternatyw tylko z UE, szacujemy nakład pracy migracji i mówimy, czy to właściwa decyzja.

Umów rozmowę Porównaj innego dostawcę