Inżynieria chmury dla sektora publicznego: czego nauczyliśmy się, korzystając równolegle z AWS, Azure i GCP

„Multi-cloud” jest sprzedawany jako strategia. Zazwyczaj jednak nią nie jest — to raczej konsekwencja. Dany dział ma już środowisko Azure w ramach swojej infrastruktury M365, partner wdrożeniowy zbudował ostatnią usługę na AWS, a zespół ds. analizy danych chce korzystać z BigQuery. Nikt tego nie zaplanował. Ktoś jednak musi to jakoś ogarnąć.

Po dziesięciu latach projektowania platform w środowiskach AWS, Azure i Google Cloud dla klientów z sektora publicznego – oto, co naprawdę ma znaczenie, gdy już przejdzie się przez debatę na temat tego, „która chmura jest najlepsza”, i skupi się na zapewnieniu bezpieczeństwa, zgodności z przepisami oraz opłacalności obciążeń produkcyjnych.

1. Suwerenność i klasyfikacja mają pierwszeństwo przed architekturą

W przypadku projektów komercyjnych wybór regionu jest decyzją dotyczącą wyników. W przypadku projektów rządowych jest to przede wszystkim kwestia prawna.

Zanim powstanie choćby jeden moduł Terraform, ustalamy:

• Jaką klasyfikację mają te dane — „OFICJALNE”, „OFICJALNE – POUFNE” czy wyższą?
• Które regiony spełniają wymóg dotyczący miejsca zamieszkania i czy model wspólnej odpowiedzialności tego dostawcy faktycznie go spełnia, czy tylko tak twierdzi?
• Kto jest w posiadaniu kluczy szyfrujących — dostawca, czy też umowa przewiduje stosowanie kluczy zarządzanych przez klienta (CMK/BYOK)?

# Encryption key ownership is a decision, not a default
resource "aws_kms_key" "official_sensitive" {
  description             = "CMK for OFFICIAL-SENSITIVE workloads"
  deletion_window_in_days = 30
  policy                  = data.aws_iam_policy_document.key_admins.json
  # Key never leaves customer control — no provider-managed fallback
}

Jeśli popełnisz tu błąd, żadne nawet najlepsze rozwiązania inżynieryjne nie będą w stanie tego później naprawić. Widzieliśmy już przypadki, w których migracje były wstrzymywane na miesiące, ponieważ lokalizacja danych została jedynie założona, a nie zweryfikowana.

2. Wybierz odpowiednią chmurę dla danego obciążenia, a nie jedną chmurę do wszystkiego

Zespoły, które borykają się z problemami związanymi z architekturą wielochmurową, to te, które próbują zapewnić przenośność każdego obciążenia w dowolnym miejscu. Zespoły odnoszące sukcesy wybierają głównego dostawcę dla każdego obciążenia w oparciu o jego rzeczywiste mocne strony i ujednolicają procesy łączące poszczególnych dostawców.

Błędem nie jest użycie trzech chmur. Błędem jest użycie trzech chmur bez podjęcia decyzji dlaczego dla każdego z nich.

3. Tylko dzięki Kubernetesowi korzystanie z wielu chmur jest znośne

Interfejsy API związane z obliczeniami, zarządzaniem tożsamością i dostępem (IAM) oraz sieciami różnią się w usługach AWS, Azure i GCP w sposób, którego nie da się w pełni zniwelować. Kubernetes jest rozwiązaniem najbardziej zbliżonym do wspólnej platformy i stanowi jedyną inwestycję, która się opłaca niezależnie od tego, z usług których dostawców ostatecznie skorzystasz.

# Same manifest, three managed control planes
# EKS, AKS and GKE all accept this without modification
apiVersion: apps/v1
kind: Deployment
metadata:
  name: claims-api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: claims-api
          image: registry.internal/claims-api:1.4.2
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }

W tle nadal korzystamy z usług natywnych dla poszczególnych dostawców — RDS, Cosmos DB, Cloud SQL — ponieważ ponowne wdrażanie zarządzanych baz danych w środowisku Kubernetes rzadko się opłaca. Warstwa aplikacji pozostaje jednak przenośna, a właśnie ta przenośność pozwala działowi przenieść obciążenie w przypadku zmiany warunków umowy dotyczącej frameworka.

4. FinOps to cotygodniowy nawyk, a nie coroczny przegląd

Przekroczenia kosztów związanych z chmurą w sektorze publicznym rzadko wynikają z jednej złej decyzji. Wynikają one z tego, że nikt nie zwraca na to uwagi, dopóki faktura nie trafi na biurko dyrektora.

# What an unmanaged multi-cloud bill actually looks like after 12 months
AWS:   forecast £18k/mo → actual £31k/mo  (orphaned EBS volumes, over-provisioned RDS)
Azure: forecast £9k/mo  → actual £14k/mo  (dev/test resources never torn down)
GCP:   forecast £4k/mo  → actual £4.2k/mo (tagged and budget-alerted from day one)

Linia GCP nie bez powodu stanowi wyjątek — od samego początku posiadała alerty budżetowe oraz obowiązkowe oznaczanie, których stosowanie było egzekwowane na mocy zasad. W przypadku pozostałych dwóch linii tak nie było, dopóki tego nie dodaliśmy.

# Tag enforcement at the policy layer, not the honour system
resource "aws_organizations_policy" "require_cost_tags" {
  content = jsonencode({
    tags = {
      "cost-centre" = { tag_key = { "@@assign" = "cost-centre" }, enforced_for = { "@@assign" = ["ec2:instance", "rds:db"] } }
    }
  })
}

Stosowanie tagów, powiadomienia budżetowe oraz cotygodniowy przegląd kosztów stanowią różnicę między prognozą a mrzonką.

5. Infrastruktura jako kod to jedyne wiarygodne źródło informacji — albo nic

Wielochmura bez IaC oznacza trzy konsole, trzy zestawy wiedzy wewnętrznej oraz historię zmian, o której nikt nie pamięta po odejściu z firmy. Terraform (lub OpenTofu) z modułami dla poszczególnych dostawców, dostępnymi za pośrednictwem wspólnego interfejsu, sprawia, że audyty stają się wykonalne.

module "network" {
  source   = "./modules/network/${var.cloud_provider}"
  cidr     = var.network_cidr
  env      = var.environment
}

Każda zmiana przechodzi tę samą procedurę weryfikacji PR, ten sam etap „planuj przed wdrożeniem” oraz tę samą ścieżkę audytową — niezależnie od tego, do której chmury jest skierowana. Dla audytora certyfikacji ISO 27001 lub Cyber Essentials Plus ta spójność ma większe znaczenie niż to, którego dostawcę wybrałeś.

Najważniejsze wnioski

• Najpierw dokonaj klasyfikacji, a dopiero potem opracuj architekturę — suwerenność i własność kluczy to kwestie prawne, a nie infrastrukturalne
• Wybieraj świadomie w zależności od obciążenia — przypadkowa wielochmurowość stanowi słaby punkt; celowa wielochmurowość stanowi atut
• Kubernetes stanowi warstwę przenośności — inwestujcie tam, a nie w dążenie do całkowitej niezależności od chmury we wszystkich obszarach
• FinOps to proces ciągły — egzekwowanie tagów i powiadomienia budżetowe zawsze wygrywają z kwartalnym arkuszem kalkulacyjnym
• IaC to ścieżka audytu — jeśli coś nie zostało zapisane w kodzie i nie przeszło weryfikacji, to tak jakby tego nie było

Strategia wielochmurowa nie jest z natury ani dobra, ani zła. To zestaw ograniczeń, które ktoś inny już ci narzucił. Zadaniem inżynierów jest sprawienie, by te ograniczenia stały się „nudne” — przewidywalne, możliwe do zweryfikowania i tanie w eksploatacji.