Kolokacja czy chmura publiczna? Kiedy warto mieć własny sprzęt?

Kiedy chmura publiczna ma sens

Zaczniemy uczciwie: chmura publiczna jest odpowiednim rozwiązaniem dla określonego zestawu przypadków. Startup bez kapitału na własny sprzęt, projekt z dynamicznie zmiennym obciążeniem (kilkadziesiąt instancji w szczycie, kilka w nocy), środowisko deweloperskie z kilkoma nieregularnymi użytkownikami — to są scenariusze, gdzie elastyczność i brak CapEx są realną przewagą.

Chmura ma sens również tam, gdzie szybkość uruchomienia jest priorytetem nad kosztem: nowy produkt, proof-of-concept, kampania sezonowa. Możliwość uruchomienia 50 serwerów w ciągu godziny i ich wyłączenia po tygodniu to coś, czego kolokacja strukturalnie nie oferuje — i nie próbuje oferować.

Problem zaczyna się wtedy, gdy projekt, który zaczął się jako "tymczasowy" w chmurze, staje się infrastrukturą produkcyjną — i nikt nie wrócił do oceny, czy ta decyzja nadal ma sens ekonomicznie.

Gdzie rachunek z AWS zaskakuje

Egress fees — opłaty za transfer danych wychodzących z chmury — to pozycja, która zaskakuje najbardziej. AWS nalicza od 0,08 USD do 0,09 USD za GB transferu do internetu (po pierwszym darmowym gigabajcie). Firma, która obsługuje 50 TB ruchu wychodzącego miesięcznie, płaci za sam egress ponad 4000 USD miesięcznie. To koszt, którego nie ma przy kolokacji z flat-rate transferem lub portem 1 GbE.

Reserved Instances i Savings Plans to mechanizmy rabatowe, które wymagają 1- lub 3-letniego zobowiązania finansowego z góry lub miesięcznego. Przy 3-letnim RI z góry możesz zaoszczędzić do 60% vs on-demand. Brzmi świetnie — ale to zobowiązanie porównywalne z kontraktem kolokacyjnym, tylko bez posiadania sprzętu po zakończeniu okresu.

Snapshot storage, transfer danych między regionami i strefami dostępności, NAT Gateway ($0.045/h plus $0.045/GB), load balancer ($0.008/h za LCU) — każda z tych pozycji jest mała w izolacji i razem tworzy rachunek, który bywa trudny do przewidzenia bez szczegółowego analizy użycia. Nie bez powodu "AWS bill shock" ma własną stronę na Hacker News.

Konkretne porównanie kosztów

Przykład: serwer z 128 GB RAM, 8 rdzeniami fizycznymi (16 vCPU), 4 TB storage NVMe, port 1 GbE z 10 TB transferu/miesiąc. Odpowiednik w AWS to mniej więcej m6i.4xlarge (128 GB RAM, 16 vCPU) + 4 TB gp3 EBS + transfer. Koszt on-demand: ok. 0,768 USD/h za instancję = ok. 556 USD/miesiąc, plus 4 TB EBS gp3 = ok. 320 USD, plus egress za 10 TB = ok. 920 USD. Łącznie: ok. 1800 USD/miesiąc = ok. 64 800 USD przez 3 lata.

Przy 3-letnim Reserved Instance z opłatą z góry można to zbić do ok. 900-1000 USD/miesiąc za instancję i storage (egress pozostaje bez zmian). Łącznie: ok. 1400 USD/miesiąc = ok. 50 000 USD przez 3 lata.

Kolokacja: serwer Dell lub HPE z tymi parametrami kosztuje ok. 8 000-12 000 PLN zakupu (używany, certyfikowany). Miesięczny koszt kolokacji 1U z zasilaniem 500W i portem 1 GbE z 10 TB transferu — od ok. 400 PLN. Przez 3 lata: zakup + kolokacja = ok. 25 000-30 000 PLN = ok. 6 000-7 000 EUR. Różnica jest znacząca.

Przewidywalność kosztów — argument który działa na CFO

Stały miesięczny koszt kolokacji — ten sam niezależnie od tego, ile danych przetransferujesz, ile zapytań obsłużysz i jakim obciążeniem pracuje CPU — to argument, który CFO rozumie bez tłumaczenia. Budżet IT z kolokacją jest deterministyczny. Budżet z chmurą publiczną bez dyscypliny FinOps — nie.

Chmura publiczna nie jest tańsza z natury. Jest droższa w przeliczeniu na stałe zasoby, za to tańsza w przeliczeniu na dynamiczne, zmienne obciążenie. Jeśli Twój workload jest przewidywalny i relatywnie stały — chmura publiczna to płacenie premii za elastyczność, której nie używasz.

Budżetowanie infrastruktury kolokacyjnej jest proste: cena szafy lub U, zasilanie, łącze, ew. cross-connect i remote hands. Wszystko to stałe, kwartalne faktury. Budżetowanie infrastruktury chmurowej wymaga narzędzi FinOps, tagowania zasobów, alertów kosztowych i regularnych przeglądów — bo bez tego rachunek może się podwoić po migracji nowego projektu bez wyraźnego powodu.

Compliance i dane w Polsce

RODO nakłada obowiązek wiedzy o tym, gdzie fizycznie przetwarzane są dane osobowe. Dane "w chmurze" to dane na konkretnych serwerach w konkretnej lokalizacji. AWS eu-central-1 to Frankfurt — terytorium UE, co jest zgodne z RODO co do zasady transferu. Ale: Sub-processorzy, dane trafiające do usług takich jak CloudFront, Route 53 czy Lambda@Edge — mogą być przetwarzane w wielu regionach jednocześnie.

Niektóre branże i instytucje mają dodatkowe wymagania: sektor finansowy regulowany przez KNF, służba zdrowia z danymi osobowymi szczególnej kategorii, instytucje publiczne z wymaganiem przetwarzania danych wyłącznie w Polsce. W tych przypadkach kolokacja w polskim datacenter z jasną dokumentacją lokalizacji przetwarzania jest jedyną bezpieczną opcją — nie dlatego, że chmura jest zła, ale dlatego, że kontrola lokalizacji danych w chmurze publicznej jest trudna do udowodnienia audytorowi.

Kolokacja w InfraZone to dane przetwarzane fizycznie w Polsce, pod polskim prawem, z jasno identyfikowalnym sprzętem i lokalizacją. Jeśli Twój audytor pyta "gdzie leżą dane" — masz precyzyjną odpowiedź.

Model hybrydowy jako realna opcja

Nie ma powodu, żeby wybór był zero-jedynkowy. Wiele firm działa na architekturze hybrydowej z dobrym uzasadnieniem ekonomicznym: produkcja w kolokacji (stałe obciążenie, przewidywalny koszt, dane pod kontrolą), środowiska dev/test w chmurze publicznej (uruchamiane na żądanie, płacisz tylko kiedy używasz), backup offsite w chmurze lub u dostawcy backup-as-a-service.

Model hybrydowy wymaga jednak przemyślanej architektury sieci: VPN site-to-site lub Direct Connect / ExpressRoute między DC a chmurą, spójne zarządzanie tożsamością, jednolity monitoring. Bez tego "hybryda" staje się dwoma osobnymi środowiskami zarządzanymi niezależnie — co podwaja złożoność operacyjną bez proporcjonalnych korzyści.

Dobrze zaprojektowana hybryda pozwala korzystać z najlepszych cech obu światów: własny sprzęt dla workloadów stabilnych i krytycznych, elastyczność chmury dla zmiennych obciążeń i nowych projektów. Klucz to sensowna granica między środowiskami — zdefiniowana przez wymagania, a nie przez przypadkowe decyzje historyczne.

Kto powinien wybrać kolokację

Kolokacja jest właściwym wyborem, gdy: masz stałe, przewidywalne obciążenie przez co najmniej 2-3 lata; przetwarzasz duże wolumeny danych (powyżej kilku TB miesięcznie ruchu lub dziesiątek TB storage) gdzie egress cloud byłby dominującą pozycją kosztową; masz własny sprzęt lub możesz go kupić; podlegasz regulacjom wymagającym precyzyjnej lokalizacji danych.

Kolokacja sprawdza się też dla firm z kompetencjami inżynierskimi do zarządzania własną infrastrukturą. Chmura publiczna eliminuje część zadań operacyjnych (zarządzanie hardware, część sieci) kosztem wyższej ceny i mniejszej kontroli. Jeśli masz zespół, który potrafi to ogarnąć — płacenie premii za managed service nie ma sensu.

Jeśli dopiero budujesz infrastrukturę i nie wiesz, jak urośnie obciążenie — zacznij od chmury, zbierz dane o rzeczywistym użyciu przez 6-12 miesięcy, a potem podejmij decyzję o kolokacji na podstawie liczb. Migracja z chmury do kolokacji, gdy masz dane o obciążeniu, jest znacznie łatwiejsza niż odwrotna droga.