Wybór między Amazon EKS a Google GKE rzadko dotyczy samego Kubernetes - API jest takie samo. Wybór dotyczy wszystkiego wokół klastra: architektury sieciowej, integracji tożsamości, narzędzi compliance, złożoności operacyjnej i struktury kosztów.
Dla zespołów fintech zły wybór oznacza miesiące przeróbek, aby spełnić wymagania audytora. Dobry wybór oznacza, że Twój zespół platform engineering spędza czas na różnicowaniu produktu, a nie na walce z ograniczeniami infrastruktury.
Kontekst regulacyjny: PCI DSS na Kubernetes
Zanim przejdziemy do porównania platform, krótkie wprowadzenie. PCI DSS (Payment Card Industry Data Security Standard) wymaga:
- Segmentacji sieciowej między systemami w zakresie i poza zakresem
- Szyfrowania danych kart w tranzycie i w spoczynku
- Ścisłej kontroli dostępu ze ścieżką audytu
- Zarządzania podatnościami i regularnego patchowania
- Logowania i monitorowania każdego dostępu do danych kart
Obie platformy mogą spełnić te wymagania. Pytanie brzmi: która ułatwia i obniża koszt wykazania zgodności podczas audytu QSA?
Izolacja sieciowa i segmentacja
Architektura sieciowa to obszar, w którym platformy różnią się najbardziej dla regulowanych workload.
Model sieciowy EKS
EKS domyślnie używa wtyczki Amazon VPC CNI. Każdy pod dostaje prawdziwy adres IP z Twojego subnetu VPC. To oznacza:
- Security Groups per pod - możesz przypisać AWS Security Groups bezpośrednio do podów, co daje Ci egzekwowanie polityk sieciowych na poziomie L4 w VPC. Twój audytor widzi znane reguły firewalla, a nie Kubernetes-native NetworkPolicies, których może nie rozumieć.
- Izolacja VPC - Twój klaster żyje w VPC ze standardowymi konstruktami AWS: prywatne subnety, NACLs, Transit Gateway dla łączności cross-VPC. Jeśli Twoja organizacja ma już dobrze zaprojektowany landing zone AWS, EKS wpasowuje się bez nowych koncepcji sieciowych.
- PrivateLink - serwisy komunikujące się z procesorami płatności lub API banków mogą używać VPC PrivateLink endpoints. Ruch nigdy nie dotyka publicznego internetu.
Wada: VPC CNI szybko zużywa adresy IP. Klaster z 200 podami na nodach m5.large (które obsługują ~29 IP każdy) wymaga starannego planowania CIDR. Secondary CIDR blocks lub prefix delegation łagodzą ten problem, ale to dodatkowa złożoność operacyjna.
Model sieciowy GKE
GKE używa modelu VPC-native z alias IP ranges. Pody dostają IP z zakresu wtórnego na subnecie noda. Kluczowe różnice:
- GKE Dataplane V2 (oparty na Cilium) - domyślnie włączony na nowych klastrach. Daje egzekwowanie polityk sieciowych na poziomie kernela z eBPF. Polityki sieciowe nie są opcjonalne ani „miękkie” - są wymuszane na data plane. Audytorzy doceniają, że polityki nie mogą zostać pominięte przez źle skonfigurowane reguły kube-proxy.
- VPC Service Controls - perymetr wokół zasobów GCP, który zapobiega eksfiltracji danych. Nawet jeśli pod jest skompromitowany, VPC Service Controls mogą zablokować wywołania API do zasobów poza zdefiniowanym perymetrem. To specyficzne dla GCP i nie ma bezpośredniego odpowiednika w EKS.
- Private Service Connect - odpowiednik PrivateLink w GCP. Łączność z procesorami płatności i API banków pozostaje w sieci Google.
- Hierarchical Firewalls - polityki firewalla na poziomie organizacji, które kaskadowo schodzą na projekty. Twój zespół bezpieczeństwa może egzekwować bazowe reguły, których poszczególni właściciele projektów nie mogą nadpisać.
Wada: model sieciowy GKE jest mniej znany zespołom przechodzącym z AWS. Abstrakcja jest inna - myślisz w kategoriach VPC, subnetów i reguł firewalla, ale mapowanie na pody działa inaczej niż model „jeden pod = jedno VPC IP” w EKS.
Werdykt: izolacja sieciowa
Dla środowisk PCI DSS GKE ma lekką przewagę dzięki VPC Service Controls (zapobieganie eksfiltracji danych) i egzekwowaniu Dataplane V2 na poziomie kernela. Jednak jeśli Twój zespół już operuje infrastrukturę AWS i Twój audytor jest zaznajomiony z Security Groups - EKS jest łatwiejszy do audytu, ponieważ konstrukty są dobrze rozumiane.
Tożsamość i zarządzanie dostępem
EKS + AWS IAM
EKS używa IAM Roles for Service Accounts (IRSA) lub nowszego EKS Pod Identity do przypisywania ról AWS IAM do podów Kubernetes. To oznacza:
- Pod A (przetwarzanie płatności) dostaje rolę IAM z dostępem do klucza KMS dla danych kart
- Pod B (raportowanie) dostaje inną rolę z dostępem tylko do odczytu zanonimizowanych danych
- Dostęp jest audytowany w CloudTrail na poziomie IAM
Integracja z istniejącymi politykami AWS IAM jest bezszwowa, jeśli zarządzasz już setkami ról. Twój zespół bezpieczeństwa kontynuuje korzystanie z istniejących procesów przeglądu IAM.
GKE + Google Cloud IAM
GKE używa Workload Identity do powiązania Kubernetes service accounts z GCP IAM service accounts. Model jest podobny do IRSA:
- Każde Kubernetes service account mapuje się na GCP service account
- GCP service account ma powiązania IAM do konkretnych zasobów
- Dostęp jest audytowany w Cloud Audit Logs
GKE dodaje Binary Authorization - politykę wymuszającą, że tylko podpisane, zweryfikowane obrazy kontenerów mogą działać na klastrze. Dla przetwarzania płatności oznacza to, że możesz udowodnić audytorom, iż tylko obrazy, które przeszły pipeline skanowania bezpieczeństwa, dotarły na produkcję. EKS ma równoważną funkcjonalność przez AWS Signer i admission controllers, ale Binary Authorization jest wbudowane i wymaga mniej konfiguracji.
Werdykt: tożsamość
W przybliżeniu równorzędne. Wybierz na podstawie istniejącego ekosystemu IAM. Jeśli Twoja organizacja ma dojrzałe zarządzanie AWS IAM - EKS. Jeśli zaczynasz od zera lub już jesteś na Google Cloud - Workload Identity + Binary Authorization w GKE daje nieco szybszą ścieżkę do dowodów zgodności.
Szyfrowanie i zarządzanie kluczami
EKS
- Szyfrowanie secretów: EKS wspiera szyfrowanie kopertowe (envelope encryption) Kubernetes secrets z użyciem AWS KMS.
- Szyfrowanie storage: wolumeny EBS (używane dla PVC) wspierają szyfrowanie KMS domyślnie.
- Szyfrowanie w tranzycie: service mesh (Istio, Linkerd) lub TLS na poziomie aplikacji. Nie jest wymuszane przez platformę.
GKE
- Szyfrowanie secretów: szyfrowanie secretów na warstwie aplikacji z Cloud KMS. Ten sam model szyfrowania kopertowego.
- Szyfrowanie storage: dyski persystentne (Persistent Disk) są szyfrowane domyślnie kluczami zarządzanymi przez Google lub kluczami zarządzanymi przez klienta (CMEK).
- Szyfrowanie w tranzycie: GKE szyfruje cały ruch wewnątrz-nodowy domyślnie przy użyciu WireGuard (Dataplane V2). Ruch pod-to-pod wewnątrz klastra jest szyfrowany bez service mesh.
Szyfrowanie ruchu wewnątrz-nodowego domyślnie w GKE to istotny wyróżnik dla PCI DSS. W EKS potrzebujesz service mesh lub mTLS na warstwie aplikacji, żeby osiągnąć to samo. GKE robi to na warstwie sieciowej transparentnie.
Werdykt: szyfrowanie
GKE wygrywa na domyślnej postawie szyfrowania. Szyfrowanie ruchu wewnątrz-klastrowego bez service mesh upraszcza architekturę i redukuje powierzchnię ataku, którą musisz udokumentować dla audytorów.
Złożoność operacyjna i zarządzane funkcje
EKS: więcej kontroli, więcej odpowiedzialności
- Control plane: zarządzany przez AWS. Ty zarządzasz warstwą wykonawczą - data plane (node groups, networking, add-ons).
- Aktualizacje: Ty planujesz i wykonujesz upgrade. AWS udostępnia rolling updates dla managed node groups, ale timing i testowanie należą do Ciebie.
- Add-ons: CoreDNS, kube-proxy, VPC CNI - zarządzane jako EKS add-ons, ale Ty wybierasz wersje.
- Logowanie: Ty konfigurujesz Fluent Bit lub CloudWatch agent do wysyłki logów.
GKE Autopilot: mniej kontroli, mniej obciążenia
- Control plane + data plane: oba zarządzane. Definiujesz workload, Google zarządza nodami, skalowaniem, patchowaniem i aktualizacjami OS.
- Aktualizacje: automatyczne. Release channels (Rapid, Regular, Stable) pozwalają wybrać poziom agresywności aktualizacji.
- Wbudowane bezpieczeństwo: Shielded GKE nodes, Secure Boot, Container-Optimized OS, automatyczna naprawa nodów. Środowisko jest zabezpieczone na poziomie platformy bez dodatkowej konfiguracji.
- Logowanie: Cloud Logging zintegrowany domyślnie. Brak konfiguracji agentów.
GKE Autopilot jest szczególnie atrakcyjny dla startupów fintech, które chcą skupić wysiłek inżynieryjny na produkcie płatniczym, a nie na utrzymaniu Kubernetes.
Werdykt: operacje
GKE Autopilot jest lepszym wyborem dla małych zespołów fintech (5-20 inżynierów). EKS jest lepszy dla organizacji z dedykowanym zespołem platform engineering (20+ inżynierów), które cenią kontrolę i mają istniejącą ekspertyzę w utrzymaniu AWS.
Porównanie kosztów dla typowego klastra fintech
Reprezentatywny klaster przetwarzania płatności: 3 node pools, 12-20 nodów, uruchamiający miksy API gateway, serwisy orkiestracji płatności, detekcję fraudów i zadania wsadowej rekoncyliacji.
| Komponent | EKS | GKE |
|---|---|---|
| Control plane | $0.10/hr ($73/mies.) | $0.10/hr ($73/mies.) - Standard. Darmowy dla Autopilot |
| Compute (porównywalne instancje) | m5.xlarge: ~$140/mies. | e2-standard-4: ~$120/mies. |
| Storage (100GB SSD PVC) | gp3: ~$8/mies. | pd-ssd: ~$17/mies. |
| NAT Gateway / Cloud NAT | $32/mies. + $0.045/GB | $32/mies. + $0.045/GB |
| Load balancer | ~$16/mies. + opłaty za LCU | ~$18/mies. + opłaty za backend |
| Egress (10 TB/mies.) | ~$900/mies. | ~$850/mies. |
Różnica kosztowa nie jest dramatyczna. GKE jest zazwyczaj 5-10% tańszy na compute, nieco droższy na storage. Prawdziwa różnica kosztowa jest operacyjna: ilu inżynierów potrzebujesz, żeby utrzymać klaster zdrowy i zgodny?
Kiedy wybrać EKS dla przetwarzania płatności
- Twoja organizacja jest już na AWS z dojrzałą architekturą VPC i zarządzaniem IAM
- Twoje procesory płatności oferują łączność AWS PrivateLink
- Masz zespół platform engineering doświadczony z operacjami EKS
- Twój audytor QSA jest zaznajomiony z AWS Security Groups i CloudTrail
- Potrzebujesz specyficznych konfiguracji nodów (custom AMI, GPU dla modeli ML fraud detection, Graviton dla optymalizacji kosztów)
Kiedy wybrać GKE dla przetwarzania płatności
- Budujesz od zera i chcesz maksymalne domyślne zabezpieczenia
- Twój zespół jest niewielki (5-15 inżynierów) i nie możesz dedykować etatu do operacji K8s
- Cenisz szyfrowanie ruchu wewnątrz-klastrowego bez zarządzania service mesh
- Przetwarzasz dane wymagające zapobiegania eksfiltracji (VPC Service Controls)
- Używasz BigQuery do analityki finansowej i chcesz natywną integrację z GCP
- Twój zespół ML/fraud detection korzysta z Vertex AI lub BigQuery ML
Nasze doświadczenie
W Devopsity budowaliśmy i operowaliśmy infrastrukturę przetwarzania płatności na obu platformach. Nasze projekty GCP fintech zazwyczaj obejmują:
- Klastry GKE z Workload Identity i Binary Authorization
- Cloud KMS z kluczami zarządzanymi przez klienta dla szyfrowania danych kart
- Perimetry VPC Service Controls wokół zasobów w zakresie PCI
- Pipeline Cloud Build z bramkami skanowania podatności
- Analitykę transakcji opartą na BigQuery z kontrolą dostępu na poziomie kolumn
Po stronie AWS operujemy klastry EKS dla platform płatniczych z:
- Tożsamością podów opartą na IRSA z granularnym dostępem do KMS
- Security Groups for Pods dla segmentacji sieciowej
- Regułami AWS Config dla ciągłego monitorowania zgodności
- CodePipeline ze skanowaniem obrazów w ECR
Oba podejścia przechodzą audyty PCI DSS. Wybór sprowadza się do ekspertyzy Twojego zespołu, istniejących inwestycji w chmurę i tego, ile obciążenia operacyjnego chcesz wziąć na siebie.
Budujesz infrastrukturę płatniczą na Kubernetes?
Umów darmową 30-minutową rozmowę o architekturze. Omówimy wymagania zgodności i zarekomendujemy właściwą platformę dla Twojego workload.
Najczęściej zadawane pytania
Czy GKE czy EKS jest lepsze pod kątem zgodności PCI DSS?
Obie platformy mogą osiągnąć zgodność PCI DSS. GKE ma więcej funkcji bezpieczeństwa włączonych domyślnie (szyfrowanie ruchu wewnątrz-nodowego, Dataplane V2, VPC Service Controls), co redukuje wysiłek potrzebny na generowanie dowodów zgodności. EKS daje więcej kontroli, ale wymaga jawnej konfiguracji każdej warstwy bezpieczeństwa.
Czy mogę uruchomić workload PCI DSS na GKE Autopilot?
Tak. GKE Autopilot zapewnia zabezpieczone środowisko z Shielded Nodes, Secure Boot i automatycznym patchowaniem. Jednak nie możesz uruchamiać DaemonSetów ani kontenerów uprzywilejowanych, co może ograniczyć niektóre deploymentty agentów monitoringu i bezpieczeństwa. Zweryfikuj, czy Twoje narzędzia runtime security (Falco, Sysdig) wspierają Autopilot przed podjęciem decyzji.
Ile kosztuje klaster Kubernetes zgodny z PCI?
Dla typowej średniej platformy płatniczej (12-20 nodów) spodziewaj się $3,000-$5,000/miesiąc kosztów infrastruktury na każdej z platform. Prawdziwa różnica kosztowa to czas inżynieryjny: GKE zazwyczaj wymaga 0,5-1 FTE mniej na utrzymanie klastra w porównaniu z EKS przy tej samej postawie zgodności.
Co z Azure AKS dla przetwarzania płatności?
AKS jest opcją, szczególnie dla organizacji w ekosystemie Microsoft. Plasuje się między EKS a GKE pod względem zarządzanych funkcji - darmowy control plane, dobre domyślne bezpieczeństwo, ale brak odpowiedników VPC Service Controls i wbudowanego szyfrowania Dataplane V2. Omawiamy AKS w osobnym porównaniu.
Czy potrzebuję service mesh dla PCI DSS na Kubernetes?
Na EKS: prawdopodobnie tak, dla mTLS między serwisami obsługującymi dane kart. Na GKE: niekoniecznie - Dataplane V2 zapewnia szyfrowanie na warstwie sieciowej. Service mesh nadal dodaje wartość dla observability i zarządzania ruchem, ale nie jest ściśle wymagany dla zgodności szyfrowania na GKE.
