Lekcja 1 · Dzień 2
AWS na produkcji, nie z tutoriala
JD wymaga płynności w VPC, IAM, ECS i EKS, Lambda, RDS oraz IAM Roles Anywhere. Ćwiczenie z raportu: narysuj multi-account layout dla fintechu z PCI i powiedz, co nie może wychodzić z PCI VPC.
Multi-account — najwyższa ściana segmentacji
AWS w whitepaperze o PCI DSS 4.0 mówi wprost: osobne konto to najsilniejsza granica segmentacji, jaką masz w chmurze. Zasoby w koncie A są logicznie izolowane od konta B nawet wewnątrz Organizations. SCP, IAM, billing — wszystko się rozdziela. Kompromis konta nie-PCI nie daje automatycznie IAM do CDE.
Dla fintechu kartowego, który w JD ma konta dev / staging / prod / PCI, rozsądny layout (zgodny z AWS Organizations + PCI scoping, nie z ich niepublicznym diagramem):
CI identity: GitHub OIDC provider i role do assume — zwykle w każdym koncie docelowym, albo centralnie z assume-role w dół. Long-lived keys w GitHub Secrets to anty-wzorzec; JD tego nie mówi wprost, ale „IAM Roles Anywhere i cert-based auth” plus OIDC to ten sam temat: zero standing credentials.
SCP na PCI OU (przykłady, które warto umieć wymienić): zakaz tworzenia IAM user access keys, zakaz wyłączenia CloudTrail, zakaz publicznych S3/SG 0.0.0.0/0 na bazach, region allow-list, zakaz usuwania KMS z deletion window, GuardDuty on.
Design VPC, o którym mają usłyszeć
- Multi-AZ — minimum dwie AZ na wszystko, co jest w SLO. NAT per AZ (albo NAT-instance, jeśli oszczędzacie — powiedz trade-off: koszt vs blast radius).
- Public / private / isolated. Public: tylko ALB/NLB, ewentualnie NAT. Private: compute. Isolated (no 0.0.0.0/0): RDS, kolejki z CHD. W CDE często w ogóle nie ma public subnet.
- NAT — egress kontrolowany. W PCI: egress przez firewall / prefix lists, nie „wszystko na 443”. VPC endpoints do S3, ECR, Logs, STS, KMS — mniej NAT, mniej powierzchni.
- Peering vs Transit Gateway. Peering: proste, nie-tranzytowe, nie skaluje się (N²). TGW: hub, inspection VPC, segmentacja route table’ami (prod-app nie routuje do PCI, chyba że przez inspection). Dla 4+ kont z PCI — TGW albo Cloud WAN, nie siatka peeringów.
- PrivateLink — preferowany sposób, żeby prod-app wołał serwis w PCI (albo odwrotnie) bez otwierania całej sieci. NLB + endpoint service, security group na NLB.
IAM: least privilege, role vs user, boundary, Roles Anywhere
Role vs user
Ludzie: IAM Identity Center (SSO), permission sets, krótkie sesje. Maszyny: role. IAM user z access key — wyjątek z expiry i ticketem, nie default. W PCI to często twardy zakaz (SCP).
Permission boundary
Maksimum, jakie tożsamość może sobie nadać, nawet jeśli ktoś jej przysłał *:*. Platforma daje product teamom rolę do self-service z boundary: „możesz tworzyć Lambdy i kolejki w swoim namespace, nie możesz ruszać KMS CDE ani IAM oprócz swoich ról”. To jest odpowiedź na ticket hell.
IAM Roles Anywhere — jest w wymaganiach JD
Problem: workload poza AWS (on-prem, partner, HSM, czasem self-hosted runner) potrzebuje AWS API, a nie chcesz wkładać długich kluczy.
Mechanizm (dokumentacja AWS):
- Wystawiasz trust anchor — AWS Private CA albo własna CA.
- Workload ma certyfikat X.509 podpisany przez tę CA.
- Credential helper woła Roles Anywhere, dostaje tymczasowe credsy (jak STS).
- Profil mapuje cert (CN/SAN, atrybuty) na IAM role.
To jest kuzyn GitHub OIDC: tam JWT od GitHuba, tu cert od CA. Oba zabijają long-lived keys. Na rozmowie rozróżnij:
| GitHub Actions → AWS | Roles Anywhere | |
|---|---|---|
| Dowód tożsamości | OIDC JWT | X.509 |
| Typowy use-case | CI | Poza AWS: DC, partner, urządzenie |
| Trust | IdP token.actions.githubusercontent.com | Trust anchor CA |
| Warunek | sub = repo/branch/environment | atrybuty certu |
Jeśli nie używałeś Roles Anywhere: powiedz analogię (IRSA w EKS, instance profile, OIDC) i zaprojektuj. Nie zmyślaj pól API.
ECS vs EKS — kiedy co
Oni mają ECS dziś i migrują na EKS. Musisz umieć koszty, networking, rolling deploy, secrets — bez religii.
| ECS (Fargate/EC2) | EKS | |
|---|---|---|
| Control plane | AWS, prawie niewidoczny | Płacisz ~0,10 USD/h za cluster + twoja operacja (upgrade, addony) |
| Networking | awsvpc: ENI per task, SG per task. Proste, drogie przy gęstości. | VPC CNI (pod = IP z VPC) albo overlay. NetworkPolicy, SG for pods. |
| Deploy | Rolling z minimumHealthyPercent / circuit breaker. CodeDeploy blue/green opcjonalnie. | Deployment/ReplicaSet, Argo/Flux, ingress. Więcej ruchomych części. |
| Secrets | SSM/Secrets Manager → env/files w task def | CSI driver, External Secrets, IRSA. Łatwiej o wyciek przez sidecar. |
| Autoscaling | Service auto scaling (CPU/ALB/custom) | HPA + Karpenter/CA. Karpenter jest w raporcie jako temat operacyjny. |
| PCI | Mniej powierzchni (brak etcd, kubelet API). Łatwiejszy zakres. | Więcej komponentów in-scope, chyba że CDE ma osobny cluster. |
| DevEx / rynek | Dobrze na 20 serwisów o podobnym kształcie | Sidecary, standard rynku, multi-tenant cells, hiring |
Kiedy zostawić ECS/Lambda: crony, spikey workers, proste API bez sidecara, workload PCI, którego nie chcesz wkładać do wspólnego klastra. Kiedy EKS: jednolity deploy, service mesh/sidecary, autoscaling podów, platforma dla 20 zespołów. Szczegóły migracji: lekcja 4.
Lambda: cold start, concurrency, IAM do RDS, EventBridge
- Cold start: nowy execution environment. Go i custom runtime są zwykle szybsze od ciężkiego Pythona z wieloma deps. Provisioned concurrency kupuje ciepłe środowiska za pieniądze. SnapStart (Java) — mniej istotne u nich, bo Lambdy platformowe są Go/Python.
- Concurrency: account limit (domyślnie 1000 w regionie, podnoszone). Reserved concurrency gwarantuje pulę i jednocześnie jest throttlem. Bez reserved jeden gorący worker może zgłodzić resztę — w tym rotację sekretów.
- IAM do RDS: nie wsadzaj hasła w env. IAM database authentication (token 15 min) albo Proxy z IAM. SG: Lambda w VPC, tylko port 5432 do SG bazy. Do PCI RDS — osobna rola, osobne konto, zero z dev.
- EventBridge: szyna do operational tooling (rotacja, dispatch). Rule → Lambda. Dead-letter na SQS. Idempotencja, bo retry jest pewny.
RDS: multi-AZ, backup, parameter groups, kto łączy się z PCI
- Multi-AZ (standby synchroniczny) ≠ read replica. Failover to minuty, nie zero. Na rozmowie nie myl.
- Backup: automated + PITR. W PCI: retention zgodna z polityką, backup zaszyfrowany tym samym (lub osobnym) KMS, restore testowany — backup, którego nikt nie restore’ował, nie istnieje.
- Parameter groups:
ssl=on,log_min_duration,pgaudit/ audit plugin. Zmiana parametru często wymaga reboot — to jest change w oknie, nie „terraform apply w piątek”. - Kto łączy się z PCI account: tylko role z tego konta + ewentualnie break-glass. Bastion w prod-app nie ma trasy. Analitycy dostają zanonimizowany dump w non-PCI, nie read-replica CDE „bo Tableau”.
Co nie może wychodzić z PCI VPC
To jest ćwiczenie z raportu. Lista, którą warto powiedzieć na głos:
- CHD / PAN / SAD — w logach, metrykach, tracingu, ticketach, stagingu, laptopie, Cursorze. Maskowanie PAN (pierwsze 6 + ostatnie 4) to nie jest „wystarczy do CDE”.
- Klucze KMS plaintext, materiał HSM, PEMy Roles Anywhere.
- Bezpośredni egress do internetu z warstwy danych. Egress tylko przez kontrolowany proxy na allow-list (Visa endpoint, OS updates przez repo wewnętrzne).
- Peering „na skróty” z dev. Dev nie routuje do CDE.
- SSH/SSM z osobistego IP. Break-glass: time-bound, nagrywane, dwuosobowe.
- Flow logi i CloudTrail — wychodzą, ale do log-archive, write-once, nie do Slacka.
- Obrazy kontenerów — tylko z ECR w PCI albo signed provenance. Nie z Docker Huba „bo szybko”.
Co może wychodzić: ztokenizowany PAN / last4, kwota, merchant ID, status autoryzacji, metryki bez payloadu, alert „auth_p99 > 200ms”.
Ćwiczenie (8 minut na głos)
Kartka. Narysuj: management, identity, log-archive, shared, prod-app, PCI. Dwie VPC, TGW albo PrivateLink, ALB tylko w app, RDS isolated w PCI. Powiedz trzy SCP i trzy rzeczy, które nie opuszczają CDE. Porównaj z whiteboardem.