Hosting aplikacji: chmura AWS czy własny serwer

Dla większości aplikacji biznesowych, które budujemy, wystarcza jeden dobrze utrzymany serwer z kontenerami Docker i Nginx. Serwer może działać w chmurze albo w serwerowni klienta. Usługi AWS, takie jak ECS Fargate czy Lambda, wybieramy, gdy ruch jest nierówny albo zadania działają w tle. Sięgamy po nie także wtedy, gdy nie chcemy utrzymywać systemu operacyjnego.

Decyzję podejmujemy według kilku kryteriów. Liczy się przewidywalność kosztów, wymagania dotyczące danych i kompetencje zespołu, który będzie aplikację utrzymywał. Ważne jest też, z czym aplikacja musi się łączyć. Poniżej porównanie wariantów i opis tego, jak sami z nich korzystamy.

Warianty hostingu aplikacji webowej

W praktyce wybór sprowadza się do trzech modeli:

Wariant	Co utrzymujesz	Dla jakich aplikacji	Główne ryzyko
Serwer (VPS lub fizyczny) z Docker i Nginx	System operacyjny, aktualizacje, kopie zapasowe, monitoring	Aplikacje z w miarę stałym ruchem, systemy wewnętrzne, aplikacje, które muszą działać blisko innych systemów firmy	Zaniedbane aktualizacje i brak testów odtwarzania kopii
Kontenery w AWS (ECS na Fargate)	Obraz aplikacji i konfigurację usługi; serwerami zarządza AWS	Aplikacje z rosnącym lub zmiennym ruchem, kilka środowisk (test, produkcja)	Złożoność konfiguracji sieci i uprawnień, koszty rosnące razem ze skalą
Funkcje bezserwerowe (AWS Lambda)	Kod funkcji i jej uprawnienia	Krótkie zadania uruchamiane zdarzeniem: webhooki (automatyczne powiadomienia z innych systemów), raporty, integracje	Ograniczenia czasu i pamięci, trudniejsze szukanie błędów

Każdy z tych wariantów da się prowadzić dobrze albo źle. Różnią się tym, kto odpowiada za warstwę pod aplikacją i za co płacisz.

Nasze aplikacje działają w kontenerach Docker

Realizacje z naszego portfolio uruchamiamy w kontenerach Docker za serwerem Nginx. Dotyczy to m.in. Service Quotes, Offer Exchange i INVENTA Licenses. Kontener to spakowana aplikacja razem z zależnościami. Działa tak samo na laptopie programisty, na serwerze testowym i na produkcji.

Dla klienta ma to praktyczną konsekwencję: aplikacja nie jest przywiązana do jednego dostawcy. Ten sam obraz można uruchomić na serwerze w firmie, na wirtualnej maszynie u dowolnego dostawcy albo w usłudze kontenerowej AWS. Jeśli za kilka lat zmienią się wymagania albo ceny, przeniesienie aplikacji nie wymaga przepisywania systemu.

Kiedy własny serwer jest lepszym wyborem?

Serwer (u dostawcy albo w serwerowni klienta) wybieramy, gdy:

• ruch jest przewidywalny (system dla kilkudziesięciu pracowników nie potrzebuje automatycznego skalowania),
• aplikacja musi łączyć się z systemami w sieci firmy, np. z programem na lokalnym serwerze, do którego nie ma dostępu z internetu,
• klient ma własną infrastrukturę i zespół, który ją utrzymuje (wtedy dokładamy aplikację do istniejącego monitoringu i kopii zapasowych),
• liczy się stały, łatwy do zaplanowania koszt (miesięczną opłatę za serwer łatwiej zaplanować w budżecie niż rachunek za zużycie).

Warunek: ktoś musi ten serwer utrzymywać. Aktualizacje systemu, certyfikaty, kopie zapasowe bazy i ich regularne odtwarzanie na próbę to obowiązki, o których łatwo zapomnieć po wdrożeniu. Za infrastrukturę pod naszymi aplikacjami może odpowiadać zespół obsługi informatycznej Conetso Group. Klient nie musi wtedy szukać osobnej firmy do serwera. Co zapisać w umowie o opiekę po wdrożeniu, piszemy we wpisie o umowie utrzymania aplikacji.

Kiedy wybieramy AWS?

W naszych narzędziach wewnętrznych (integracje z CRM, raporty, automatyzacje) korzystamy z AWS, a projekty dla klientów opisujemy na stronie aplikacje w chmurze AWS. Używamy m.in. AWS Lambda, ECS Fargate, App Runner, S3, DynamoDB, Step Functions i CloudFront. Infrastrukturę opisujemy w kodzie (AWS CDK i SAM). Dzięki temu środowiska powstają z repozytorium, bez ręcznych zmian w konsoli.

Z tego doświadczenia wynikają nasze reguły:

• Lambdę stosujemy do krótkich zadań uruchamianych zdarzeniem: webhook z CRM, nocny raport, przetworzenie pliku. Według dokumentacji AWS pojedyncze wywołanie funkcji może trwać maksymalnie 15 minut. Funkcja może mieć do 10 240 MB pamięci (limity AWS Lambda, stan na 30.10.2026). Dłuższe procesy dzielimy na kroki i łączymy w Step Functions.
• ECS na Fargate stosujemy do aplikacji, które działają cały czas. Fargate uruchamia kontenery bez zarządzania serwerami czy klastrami maszyn EC2. Określasz CPU i pamięć zadania, a AWS dba o warstwę pod spodem (dokumentacja AWS Fargate).
• S3 i CloudFront przechowują pliki i statyczne zasoby. Kontener aplikacji musi dać się w każdej chwili usunąć i uruchomić od nowa, więc pliki użytkowników nie mogą leżeć na jego dysku.
• Region przechowywania danych ustalamy z góry. AWS ma regiony na terenie Unii Europejskiej. Jeśli aplikacja przetwarza dane osobowe, miejsce ich przechowywania ustalamy razem z klientem przed wdrożeniem. Nie zostawiamy tego ustawieniom domyślnym.

Jedna zmiana, o której warto wiedzieć: AWS zamknął usługę App Runner dla nowych klientów. Dotychczasowi użytkownicy mogą z niej dalej korzystać, ale AWS nie planuje nowych funkcji. Jako kierunek migracji wskazuje Amazon ECS Express Mode (AWS App Runner availability change, stan na 30.10.2026). Dlatego w nowych projektach nie proponujemy App Runner, nawet tam, gdzie wcześniej był najprostszym wyborem.

Jak porównać koszty chmury i serwera?

Porównanie samych cen za godzinę procesora wprowadza w błąd. Do kosztu wariantu trzeba doliczyć:

1. Czas administracji. Aktualizacje systemu, reagowanie na awarie i odnawianie certyfikatów na serwerze wykonuje człowiek. W usługach zarządzanych część tej pracy przejmuje dostawca.
2. Kopie zapasowe i ich testy. Trzeba je zaprojektować w obu wariantach, a w chmurze płacisz dodatkowo za przechowywanie.
3. Transfer danych. W chmurze ruch wychodzący jest zwykle płatny, na serwerze często mieści się w abonamencie.
4. Środowiska testowe. W chmurze łatwo je uruchomić i wyłączyć, na serwerze zajmują stałe zasoby.
5. Koszt zmiany, czyli to, jak trudno będzie przenieść aplikację, jeśli warunki się zmienią.

Przy małych aplikacjach z równym ruchem serwer zwykle wygrywa prostotą. Usługi zarządzane potrafią się opłacić przy aplikacjach, które mają rosnąć albo działają tylko w określonych godzinach. Wymagają jednak kontroli rachunków i alarmów budżetowych od momentu uruchomienia.

Jak wybieramy wariant w projekcie

Miejsce działania aplikacji ustalamy już na etapie analizy wymagań. Pytamy o:

• liczbę użytkowników i to, czy ruch będzie równy czy skokowy,
• rodzaj danych (np. dane pacjentów) i wymagania co do miejsca ich przechowywania,
• systemy, z którymi aplikacja ma się łączyć, i to, gdzie one działają,
• to, kto będzie utrzymywał aplikację i serwer: Ty, Twój dział IT czy my,
• oczekiwaną dostępność, np. czy kilka minut przerwy w nocy na aktualizację jest akceptowalne.

Na tej podstawie proponujemy wariant i opisujemy, co obejmuje utrzymanie aplikacji. Dzięki kontenerom ta decyzja nie jest ostateczna. Jeśli po roku okaże się, że lepszy byłby inny model, aplikację da się przenieść.

Jeśli zastanawiasz się, gdzie uruchomić swoją aplikację, albo chcesz przenieść istniejącą, napisz do nas. Doradzimy wariant i przygotujemy wycenę wdrożenia i utrzymania.