Chmura obliczeniowa — co to jest i czym różnią się IaaS, PaaS i SaaS

Chmura obliczeniowa to nie miejsce, tylko sposób dzielenia pracy. Kiedy firma „przenosi się do chmury”, nie wynosi serwera do nieba — oddaje dostawcy część warstw, które do tej pory utrzymywała sama: sprzęt, system operacyjny, bazę danych, czasem całą aplikację. Za resztę dalej odpowiada ona.

Najbardziej użyteczna definicja pochodzi z amerykańskiego instytutu normalizacyjnego NIST i od 2011 roku pozostaje punktem odniesienia dla całej branży. Chmura obliczeniowa to według niej „model umożliwiający wszechobecny, wygodny dostęp przez sieć, na żądanie, do współdzielonej puli konfigurowalnych zasobów obliczeniowych (np. sieci, serwerów, pamięci masowej, aplikacji i usług), które można szybko przydzielić i zwolnić przy minimalnym wysiłku zarządczym lub interakcji z dostawcą usług” (NIST SP 800-145, tłumaczenie własne).

Angielskie cloud computing znaczy dokładnie to samo — po polsku mówimy „chmura obliczeniowa” albo po prostu „chmura”. Ten tekst wyjaśnia, z czego ta definicja się składa, czym różnią się IaaS, PaaS i SaaS, jakie są rodzaje chmur obliczeniowych i z czego naprawdę korzystają polskie firmy.

Chmura obliczeniowa — co to jest

Definicja NIST opiera się na pięciu cechach. Jeśli usługa ich nie ma, to nie jest chmura, tylko zdalny serwer w cudzej serwerowni — co samo w sobie nie jest złe, ale działa inaczej.

1. Samoobsługa na żądanie. Zasoby — moc obliczeniową, miejsce na dane — zamawiasz sam, w panelu albo przez API, bez rozmowy z handlowcem i bez czekania na technika. Nowy serwer powstaje w minuty, nie w tygodnie.

2. Szeroki dostęp przez sieć. Z usługi korzysta się przez sieć, standardowymi narzędziami — przeglądarką, telefonem, laptopem — a nie wyłącznie z jednego biura.

3. Współdzielona pula zasobów. Dostawca obsługuje wielu klientów na tej samej infrastrukturze i przydziela im zasoby dynamicznie. Klient zwykle nie wie, na którym konkretnie serwerze działa jego system — wie najwyżej, w którym regionie czy centrum danych.

4. Szybka elastyczność. Zasoby można szybko dołożyć i równie szybko oddać, nawet automatycznie. Z punktu widzenia klienta wyglądają na nieograniczone.

5. Mierzona usługa. Zużycie jest mierzone i rozliczane — płacisz za to, czego użyłeś: godziny pracy serwera, gigabajty danych, liczbę użytkowników.

Ta ostatnia cecha jest źródłem największej zmiany dla firmy: wydatek na sprzęt kupowany raz na kilka lat zamienia się w rachunek miesięczny, który rośnie i maleje razem z użyciem. To bywa zaletą przy zmiennym obciążeniu i wadą, gdy obciążenie jest stałe i przewidywalne — wtedy rachunek za lata potrafi przekroczyć koszt własnego sprzętu. Wracamy do tego niżej.

IaaS, PaaS i SaaS — trzy modele usług w chmurze

NIST wyróżnia trzy modele usług. Najprościej zrozumieć je przez pytanie: które warstwy systemu utrzymujesz ty, a które dostawca.

IaaS — infrastruktura jako usługa (Infrastructure as a Service). Dostawca daje ci „surowe” zasoby: moc obliczeniową, pamięć masową, sieć. Według NIST klient może na nich uruchamiać dowolne oprogramowanie, łącznie z systemami operacyjnymi i aplikacjami. Nie zarządza fizyczną infrastrukturą, ale zarządza systemem operacyjnym, danymi i tym, co na nim działa. Przykład z życia każdej firmy: wynajęty serwer wirtualny (VPS) albo maszyna wirtualna w AWS, Azure czy Google Cloud. Serwer masz od ręki, ale aktualizacje systemu, zabezpieczenia i kopie zapasowe — to już twoja praca.

PaaS — platforma jako usługa (Platform as a Service). Dostawca utrzymuje także system operacyjny i środowisko uruchomieniowe. Ty wgrywasz aplikację — napisaną w językach i narzędziach, które platforma obsługuje — i konfigurujesz jej ustawienia. Nie martwisz się łatkami systemu ani skalowaniem serwerów, ale przyjmujesz ograniczenia platformy: jej wersje języków, jej bazę danych, jej sposób wdrażania.

Tu warto wspomnieć o dwóch pojęciach, które każdy programista wymieni w rozmowie o chmurze, choć definicja NIST z 2011 roku ich nie zna. Serverless, w szczególności funkcje jako usługa (FaaS), to dalsze przesunięcie granicy. Według organizacji CNCF serverless oznacza budowanie i uruchamianie aplikacji, które nie wymagają zarządzania serwerami: aplikacja, podzielona na funkcje, jest wgrywana na platformę, a następnie uruchamiana, skalowana i rozliczana dokładnie według bieżącego zapotrzebowania (CNCF Serverless Whitepaper). Nie utrzymujesz więc nawet stale działającej aplikacji, tylko pojedyncze funkcje, które dostawca uruchamia w odpowiedzi na zdarzenie — tak opisuje swoją usługę AWS Lambda: kod uruchamiany bez przygotowywania serwerów i zarządzania nimi (AWS Lambda). Kontenery jako usługa leżą po drugiej stronie: dostarczasz gotowy kontener z aplikacją, a dostawca go uruchamia i skaluje. Oba mieszczą się w logice PaaS — zmienia się tylko to, jak dużo zostaje po twojej stronie.

SaaS — oprogramowanie jako usługa (Software as a Service). Dostawca utrzymuje wszystko: infrastrukturę, platformę i samą aplikację. Ty korzystasz z gotowego programu przez przeglądarkę albo aplikację i najwyżej ustawiasz konfigurację dostępną dla użytkownika. Poczta w przeglądarce, pakiet biurowy online, program do faktur, CRM — to wszystko SaaS. Więcej o samym modelu SaaS, jego zaletach i ograniczeniach piszemy w przewodniku po SaaS.

Przykłady chmury obliczeniowej w każdym modelu

Łatwiej rozpoznać modele po usługach, z którymi większość firm już miała kontakt:

• IaaS — maszyny wirtualne: Amazon EC2, Azure Virtual Machines, Google Compute Engine, a także serwery wirtualne (VPS) oferowane przez firmy hostingowe. Dostajesz system operacyjny do własnej administracji.
• PaaS — platformy do uruchamiania aplikacji: Azure App Service, Google App Engine, zarządzane bazy danych w rodzaju Amazon RDS. Wgrywasz kod albo dane, resztę utrzymuje dostawca.
• Serverless i kontenery — AWS Lambda i Google Cloud Run: pojedyncze funkcje albo gotowe kontenery uruchamiane na żądanie.
• SaaS — Microsoft 365, Google Workspace, programy księgowe i do faktur online, systemy CRM. Logujesz się i pracujesz.

Ta sama firma korzysta zwykle ze wszystkich trzech modeli naraz, często nie wiedząc o tym: poczta w SaaS, strona na serwerze wirtualnym, a program magazynowy u dostawcy, który sam uruchamia go w cudzej chmurze.

Te trzy modele tworzą schody. Im wyżej, tym mniej pracy po twojej stronie i tym mniej swobody: w IaaS możesz zainstalować cokolwiek, w SaaS korzystasz dokładnie z tego, co dostawca zbudował.

Ostatni wiersz tego schematu jest najważniejszy i najczęściej przeoczany. W każdym modelu — także w SaaS — dane, konta i dostęp zostają po stronie klienta. Dostawcy piszą to wprost w swoich opisach modelu współdzielonej odpowiedzialności. AWS dzieli ją na bezpieczeństwo chmury (jego) i bezpieczeństwo w chmurze (klienta) (AWS), a Microsoft zaznacza, że podział zadań zależy od tego, czy system działa w modelu SaaS, PaaS, IaaS, czy we własnej serwerowni (Microsoft). Co to oznacza w praktyce, rozpisujemy w tekście o bezpieczeństwie danych w chmurze.

Chmura publiczna, prywatna i hybrydowa — rodzaje chmur obliczeniowych

Drugi podział dotyczy nie tego, co kupujesz, tylko gdzie i z kim dzielisz infrastrukturę. NIST opisuje cztery modele wdrożenia.

Chmura publiczna — infrastruktura dostawcy, udostępniana wszystkim chętnym. To AWS, Microsoft Azure, Google Cloud, ale też mniejsi dostawcy serwerów wirtualnych. Płacisz za użycie, nie kupujesz sprzętu, dzielisz fizyczne zasoby z innymi klientami (w logicznie odseparowanych środowiskach).

Chmura prywatna — infrastruktura przeznaczona wyłącznie dla jednej organizacji. Może stać w jej własnej serwerowni albo u dostawcy, ale nie jest dzielona z nikim innym. Daje pełną kontrolę kosztem tego, że ktoś musi ją utrzymywać — i że elastyczność kończy się na sprzęcie, który kupiono.

Chmura hybrydowa — połączenie dwóch lub więcej modeli, które pozostają odrębne, ale są spięte tak, żeby dane i aplikacje mogły się między nimi przenosić. Typowy układ: wrażliwe dane i stałe obciążenie w chmurze prywatnej, szczyty ruchu i usługi pomocnicze w publicznej.

Chmura społecznościowa — infrastruktura współdzielona przez grupę organizacji o wspólnych wymaganiach, np. instytucje z jednego sektora. W praktyce firm spotyka się ją najrzadziej.

Chmura publiczna czy prywatna? Dla małej i średniej firmy odpowiedź niemal zawsze brzmi: publiczna — i to w modelu SaaS albo PaaS. Chmura prywatna ma sens, gdy przepisy lub umowy wymagają fizycznej separacji danych albo gdy stałe, duże obciążenie sprawia, że własna infrastruktura wychodzi taniej niż wynajem.

Jak polskie firmy korzystają z chmury

Twarde dane o tym, z czego firmy naprawdę korzystają, publikuje Eurostat w badaniu wykorzystania technologii informacyjnych w przedsiębiorstwach. Najnowsza fala dotyczy 2025 roku i obejmuje firmy zatrudniające co najmniej 10 osób (Eurostat, isoc_cicce_use).

Ogólny wynik jest dla Polski dobry: z płatnych usług chmurowych korzystało 54,7% polskich firm, wobec 52,7% w całej UE. Skala rośnie z wielkością firmy — w Polsce od 50,2% wśród małych przedsiębiorstw (10–49 osób) do 89,8% wśród dużych.

Ciekawsze jest jednak to, do czego firmy używają chmury. Polska wyprzedza UE w liczbie firm korzystających z chmury w ogóle, ale zostaje w tyle przy niemal każdym konkretnym zastosowaniu:

Z tych liczb wynika wyraźny obraz: polskie firmy weszły do chmury głównie przez SaaS — pocztę i programy biurowe — a znacznie rzadziej przeniosły tam własne systemy. Hosting baz danych w chmurze jest w Polsce niemal trzykrotnie rzadszy niż średnio w UE, moc obliczeniowa — prawie trzykrotnie.

Jedno zastrzeżenie do czytania tych danych: Eurostat mierzy odsetek firm, które kupują daną usługę, a nie to, jak intensywnie z niej korzystają. Firma z jedną skrzynką pocztową w chmurze liczy się tak samo jak firma, która przeniosła tam wszystko. Jedną kategorię z badania — platformy do tworzenia i wdrażania aplikacji — świadomie pomijamy: dla Polski wynik jest ponad dwukrotnie wyższy niż w UE, co przy wszystkich pozostałych kategoriach wygląda na zmianę metody w tej fali, a nie na rzeczywistą przewagę.

Kiedy chmura dla firmy ma sens, a kiedy nie

Chmura nie jest z definicji tańsza ani bezpieczniejsza. Jest wygodniejsza w konkretnych sytuacjach i droższa w innych.

Ma sens, gdy:

• obciążenie się zmienia — sezonowy sklep, kampania, system używany intensywnie kilka dni w miesiącu. Płacisz za szczyt tylko wtedy, gdy on trwa;
• nie masz administratora — SaaS i PaaS zdejmują z firmy aktualizacje, łatki bezpieczeństwa i wymianę sprzętu;
• potrzebujesz szybko — nowe środowisko w minuty zamiast tygodni zakupów;
• zespół pracuje z wielu miejsc — dostęp przez sieć jest cechą modelu, nie dodatkiem.

Wymaga ostrożności, gdy:

• obciążenie jest stałe i duże — rachunek miesięczny za lata potrafi przekroczyć koszt własnego sprzętu;
• zależysz od jednego dostawcy — im więcej usług specyficznych dla jednej platformy, tym trudniej i drożej ją opuścić. Warto od początku wiedzieć, w jakim formacie odzyskasz dane;
• przepisy lub umowy wymagają, żeby dane zostały w określonym miejscu — wtedy wybór regionu i dostawcy przestaje być sprawą techniczną.

Pokażemy to na własnym przykładzie. Ta strona nie działa na zarządzanej platformie, tylko na wynajętym serwerze wirtualnym z narzędziem Coolify — czyli na IaaS, na którym sami zbudowaliśmy warstwę przypominającą PaaS. Rachunek i trzy rzeczy, które się w takim układzie psują, opisaliśmy w tekście o self-hostingu Next.js i Payload. Wybraliśmy to świadomie: stałe obciążenie, pełna kontrola nad bazą i kosztami. Ale ta decyzja ma cenę, którą warto znać, zanim się ją podejmie: po naszej stronie została każda warstwa poza sprzętem. Przekonaliśmy się o tym, gdy po restarcie kontenera zniknęły pliki wgrane do jednej z kolekcji — bo system plików kontenera jest ulotny, a trwałego wolumenu dla tej kolekcji nikt nie skonfigurował. Na platformie PaaS tego błędu by nie było; w IaaS to nasza odpowiedzialność, dokładnie tak, jak pokazuje schemat wyżej.

Jeśli rozważasz, czy kupić gotowe oprogramowanie w chmurze, czy zbudować własne, to osobna decyzja — rozpisujemy ją w tekście o oprogramowaniu dedykowanym.

Od czego zacząć przenoszenie firmy do chmury

Jeśli firma dopiero zaczyna, dane Eurostatu podpowiadają naturalną kolejność: najpierw usługi, które większość firm w Europie już przeniosła, potem — jeśli jest powód — własne systemy.

1. Spisz, co masz. Lista systemów, z których korzysta firma: poczta, dokumenty, księgowość, sprzedaż, magazyn, strona, systemy własne. Przy każdym dwie informacje: kto z niego korzysta i jakie dane w nim są. Bez tej listy nie da się ocenić ani kosztu, ani ryzyka.

2. Zacznij od SaaS tam, gdzie wybór jest oczywisty. Poczta, pakiet biurowy i wspólne pliki to obszary, w których średnia unijna wyprzedza Polskę najbardziej — i w których przeniesienie do gotowej usługi jest najmniej ryzykowne. Nie wymagają zmian w procesach, tylko migracji danych i przeszkolenia ludzi.

3. Sklasyfikuj dane. Dane osobowe klientów i pracowników, dane finansowe, tajemnice handlowe — każda z tych grup ma inne wymagania co do miejsca przechowywania i umowy z dostawcą. Od tej klasyfikacji zależy, czy wystarczy dowolny dostawca, czy potrzebny jest konkretny region albo konkretne certyfikaty.

4. Zanim podpiszesz, zaplanuj wyjście. Zapytaj, w jakim formacie i w jakim czasie dostawca odda dane, gdy wypowiesz umowę. To pytanie brzmi pesymistycznie, ale to ono decyduje, czy za trzy lata będziesz mógł zmienić dostawcę, czy zostaniesz z nim, bo przeniesienie jest zbyt kosztowne.

5. Własne systemy przenoś tylko z powodem. Baza danych czy aplikacja przeniesiona do chmury „bo wszyscy tak robią” często kosztuje więcej niż na własnym serwerze, a problemy z wydajnością zostają te same. Dobry powód to zmienne obciążenie, brak osoby, która utrzyma serwer, albo potrzeba szybkiego uruchamiania nowych środowisk.

Bezpieczeństwo danych w chmurze

Pytanie „czy chmura jest bezpieczna” pada w każdej rozmowie o przeniesieniu systemów — i jest źle postawione. Duzi dostawcy chronią swoją infrastrukturę lepiej, niż zrobi to większość firm we własnej serwerowni. Ale po stronie klienta zostają dane, konta i dostęp, a do tego umowa z dostawcą, miejsce przechowywania danych i plan na wypadek awarii. To temat na osobny tekst: bezpieczeństwo danych w chmurze — kto za co odpowiada i o co pytać dostawcę.

Co dalej

Jeśli chcesz zrozumieć sam model SaaS — z którego korzysta większość firm, nawet o tym nie myśląc — zacznij od przewodnika po SaaS. Jeśli myślisz o zbudowaniu własnego produktu w tym modelu, zajrzyj do pomysłów na micro-SaaS.