Pierwsze kroki z AWS: jak założyć konto, ustawić budżet i uruchomić tani serwer

Co to jest AWS i kiedy ma sens dla początkującego

Amazon Web Services w praktycznym skrócie

Amazon Web Services (AWS) to platforma chmurowa, która dostarcza gotową infrastrukturę: serwery, dyski, bazy danych, sieć, kolejki, systemy do analityki i dziesiątki innych usług. Zamiast kupować fizyczny serwer, płacisz za czas działania i wykorzystane zasoby, które są uruchamiane w centrach danych Amazona.

Największa różnica w stosunku do klasycznego hostingu polega na elastyczności. W hostingu współdzielonym masz z góry określony „pakiet”: określoną ilość miejsca, limit domen, czasem ograniczenia CPU. W AWS sam składasz swój zestaw z klocków: dobierasz typ serwera (instancja EC2), dysk (EBS), sieć (VPC, security group), ewentualnie bazę danych (RDS) i inne usługi. Daje to większą kontrolę, ale wymaga też trochę więcej wiedzy.

W kontekście pierwszych kroków najważniejsza usługa to EC2 (Elastic Compute Cloud), czyli wirtualny serwer, który można skonfigurować niemal jak fizyczną maszynę. Do tego dochodzi kilka pojęć sieciowych (VPC, security group) i dysk (EBS). Całość można uruchomić w kilka minut i zapłacić tylko za czas działania.

Typowe zastosowania AWS dla początkującego

Dla osoby, która dopiero zaczyna przygodę z chmurą, AWS sprawdza się przede wszystkim w trzech scenariuszach:

• Mała strona WWW – prosty blog, wizytówka firmy, landing page. Można uruchomić serwer HTTP (np. nginx, Apache) i podpiąć domenę. Przy Free Tier da się to zrobić praktycznie bez kosztów na początek.
• Testowe API lub aplikacja webowa – backend REST/GraphQL, panel administracyjny, mały projekt hobbystyczny. AWS pozwala szybko stawiać środowiska testowe, bawić się CI/CD, monitorowaniem.
• Nauka DevOps / chmury – idealne środowisko do eksperymentów z infrastrukturą jako kod (Terraform, CloudFormation), automatyzacją, kontenerami (Docker, ECS, EKS) czy obserwowalnością (CloudWatch).

Przykład praktyczny: chcesz nauczyć się administracji Linuksem i jednocześnie wystawić mały serwis w sieci. Na zwykłym hostingu współdzielonym nie masz dostępu root do systemu. Na AWS możesz uruchomić własny serwer z pełnym dostępem i konfiguracją prawie jak na VPS, tylko w modelu „na żądanie”.

Kiedy AWS ma sens, a kiedy lepszy będzie zwykły hosting

AWS nie zawsze jest najlepszym pierwszym wyborem. Dobrze sprawdza się, gdy:

• chcesz mieć pełną kontrolę nad serwerem (root, wybór systemu, frajda z dłubania),
• planujesz rozwój projektu i nie chcesz się blokować na ograniczeniach hostingu współdzielonego,
• uczyć się chcesz technologii chmurowych (DevOps, site reliability, automatyzacja),
• zależy ci na elastycznym skalowaniu w przyszłości (np. w razie ruchu po kampanii marketingowej).

Zwykły hosting współdzielony będzie lepszy, gdy:

• potrzebujesz tylko prostego hostingu WordPressa, bez kombinacji,
• nie chcesz dotykać konsoli, konfiguracji serwerów, rekordów DNS ani niczego „technicznego”,
• absolutnym priorytetem jest prostota i przewidywalna, stała opłata miesięczna.

Podejście praktyczne: jeśli musisz mieć własny serwer, chcesz się uczyć i jesteś gotów poświęcić trochę czasu na naukę – AWS ma sens. Jeśli interesuje cię wyłącznie kliknięcie „instaluj WordPress” i zapomnienie o reszcie – klasyczny hosting będzie mniej problematyczny.

Model „płacisz za zużycie” i konsekwencje dla portfela

Usługi AWS są rozliczane w modelu pay-as-you-go – płacisz za to, co faktycznie zużywasz: godziny pracy serwera, ilość danych zapisanych na dysku, transfer wychodzący, wywołania API. Można to porównać do licznika energii elektrycznej: licznik zlicza zużycie, a ty dostajesz rachunek na koniec okresu rozliczeniowego.

Korzyści są oczywiste: nie musisz kupować sprzętu, płacisz tylko za użycie, możesz wyłączać serwer, kiedy go nie potrzebujesz. Z drugiej strony łatwo „przeklikać” sobie dodatkowe zasoby (np. większy dysk, dodatkowe IP, kilka instancji) i obudzić się z rachunkiem większym niż planowałeś. Dlatego tak ważne jest zrozumienie Free Tier, konfiguracja budżetu i pilnowanie uruchomionych zasobów.

Do pierwszych eksperymentów dobrze przyjąć prostą zasadę: wszystko, czego nie rozumiesz – nie włączasz. AWS daje dużo opcji, ale początkowo wystarczy mała instancja EC2, domyślne VPC i podstawowa security group. Cała reszta to „cukier” na później.

Jak działa Free Tier i realne koszty na starcie

Free Tier – darmowy poziom dla nowych kont

Free Tier to zestaw limitów, w ramach których nowy użytkownik AWS może korzystać z części usług bez dodatkowych opłat. Istnieją trzy główne typy darmowych limitów:

• 12 miesięcy od założenia konta – np. 750 godzin miesięcznie instancji t2.micro czy t3.micro, 30 GB EBS, 1 GB transferu z S3 itp.
• Na stałe (Always Free) – część usług ma stałe, małe darmowe limity, np. pewna liczba wywołań Lambda, mały Elastic Container Registry itp.
• Trial czasowy – niektóre usługi mają np. 30-dniowe pełne triale po pierwszym uruchomieniu.

Dla startu z tanim serwerem najważniejsza jest kategoria 12-miesięczna – to ona pozwala odpalić małą instancję EC2 bez płacenia za samą maszynę (przy rozsądnym użyciu). Trzeba jednak pamiętać, że darmowe limity nie obejmują wszystkiego: np. nadmiarowego transferu, dodatkowych dysków, snapshotów czy dodatkowych usług sieciowych.

Co jest realnie „za darmo”, a gdzie mogą pojawić się koszty

Przy pierwszym serwerze w AWS, w ramach Free Tier, na ogół korzystasz z:

• EC2 t2.micro lub t3.micro (1 vCPU, 1 GB RAM) – do 750 godzin miesięcznie (czyli jedna instancja non stop),
• EBS – do ok. 30 GB pojemności dysków typu General Purpose SSD,
• Transfer danych – część ruchu wychodzącego ma darmowy limit, szczególnie w ramach testów.

W praktyce przy prostym serwerze webowym i rozsądnej liczbie odwiedzających mieścisz się w darmowych limitach. Koszty mogą się jednak pojawić, jeśli:

• uruchomisz więcej niż jedną instancję lub przekroczysz 750 godzin (kilka instancji równolegle sumuje się),
• wybierzesz większy typ instancji (np. t3.small, t3.medium), który nie jest objęty Free Tier,
• przekroczysz darmowy limit pojemności EBS (np. 80 GB zamiast 30 GB),
• będziesz miał duży transfer wychodzący z serwera (np. serwer plików, streaming wideo),
• skorzystasz z innych usług, które nie są w darmowej puli (RDS, Route 53, drogie IP itp.).

Od strony praktycznej: jeśli celem jest wyłącznie nauka i mały serwer webowy, trzymaj się jednej instancji t2.micro / t3.micro, dysku ok. 10–20 GB i nie uruchamiaj dodatkowych usług bez zrozumienia cennika.

Przykładowy zestaw usług dla prostego, darmowego serwera

Dla prostego serwera WWW w AWS, działającego w ramach Free Tier, typowy zestaw wygląda tak:

• Instancja t2.micro lub t3.micro (Linux) – jedna sztuka, 24/7,
• Dysk EBS 10–20 GB, typ GP2/GP3 (General Purpose SSD),
• Domyślne VPC i subnet w wybranym regionie,
• Jedna security group z otwartymi portami 22 (SSH), 80 (HTTP) i ewentualnie 443 (HTTPS),
• Domena zarządzana poza AWS albo przez Route 53 (ale Route 53 to już dodatkowy koszt, kilka USD rocznie).

Na takim zestawie stawiasz serwer HTTP (np. nginx) i wystawiasz stronę. Jeśli nie przesadzisz z ruchem i dodatkowymi usługami, utrzymasz się blisko zera złotych (poza ewentualną domeną i minimalnymi kosztami spoza Free Tier).

Zasoby „przy okazji”, które potrafią generować rachunek

Najczęstsze pułapki kosztowe u początkujących to zasoby, które „zostają po testach” lub włączają się przy okazji:

• Elastic IP (EIP) – publiczne, stałe IP. Samo w sobie jest tanie, ale:
  • gdy jest przypisane do działającej instancji – w większości regionów jest darmowe w ograniczonej liczbie,
  • gdy je zostawisz bez przypisanej instancji – może pojawić się drobna opłata.
• Nieodłączone wolumeny EBS – jeśli usuniesz instancję, ale pozostawisz dysk (detached EBS), dalej płacisz za jego pojemność.
• Snapshoty EBS – kopie zapasowe dysków tworzone ręcznie lub automatycznie. Każdy snapshot zajmuje miejsce w S3 i generuje koszt.
• Dodatkowe instancje pomocnicze – np. ktoś kliknął „Launch more like this” i stworzył drugi serwer, o którym zapomniał.

Bezpieczna praktyka: raz na tydzień zajrzeć do zakładki EC2 i EBS i upewnić się, że:
(1) działa tylko ta instancja, której faktycznie używasz,
(2) nie wiszą żadne nieużywane, odłączone dyski EBS ani niepotrzebne EIP.

Zakładanie konta AWS krok po kroku (od zera)

Co jest potrzebne do rejestracji konta AWS

Aby zarejestrować konto AWS, potrzebne są:

• Adres e-mail – najlepiej prywatny, do którego masz długoterminowy dostęp (unikaj efemerycznych aliasów).
• Karta płatnicza / debetowa – obsługująca płatności internetowe (Visa/Mastercard). AWS wykona na niej niewielką autoryzację (czasem równowartość kilku złotych).
• Numer telefonu – do weryfikacji SMS lub głosowej.
• Dane rozliczeniowe – imię i nazwisko lub dane firmy, adres, kraj.

Bez karty płatniczej nie przejdziesz pełnej rejestracji. AWS musi móc zweryfikować, że jesteś realną osobą (lub firmą) i w przyszłości ściągnąć ewentualne należności za ponadlimitowe użycie.

Różnica między kontem root a użytkownikiem IAM

Podczas zakładania konta tworzysz tzw. konto root – powiązane bezpośrednio z twoim adresem e-mail i kartą. To konto ma pełne, nieograniczone uprawnienia do wszystkiego w AWS: tworzenia, usuwania zasobów, zmiany danych rozliczeniowych, zamykania konta. Takim kontem nie pracuje się na co dzień, podobnie jak nie używa się konta „root” w Linuksie do codziennych zadań.

Do normalnej pracy służą użytkownicy IAM (Identity and Access Management). Tworzysz użytkownika IAM z uprawnieniami administracyjnymi (np. policy AdministratorAccess) i logujesz się jako ten użytkownik, zostawiając konto root tylko do operacji administracyjnych najwyższego poziomu (MFA, dane płatnicze, zamknięcie konta).

Ten podział jest kluczowy dla bezpieczeństwa. Jeśli ktoś przejmie twoje konto root, ma pełen dostęp nie tylko do zasobów, ale i do części finansowej. Jeśli przejmie pojedynczego użytkownika IAM, możesz go wyłączyć, zmienić hasło i naprawić szkody znacznie łatwiej.

Formularz rejestracyjny: krok po kroku

Rejestracja zaczyna się od wejścia na stronę AWS i kliknięcia przycisku typu „Create an AWS Account”. Dalej:

1. Podajesz e-mail i hasło – e-mail będzie powiązany z kontem root. Wymyśl silne hasło, bo ten login daje pełny dostęp.
2. Wybierasz nazwę konta AWS (Account name) – to nazwa widoczna w konsoli i w fakturach, np. „Moje konto dev” lub nazwa firmy.
3. Wybierasz typ konta: „Personal” (osobiste) lub „Business” (firmowe). Typ wpływa na to, jak będą wystawiane faktury i jak AWS będzie cię traktował w kontaktach B2B, ale technicznie możliwości są podobne.
4. Wypełniasz dane adresowe – imię, nazwisko lub nazwa firmy, adres, kraj. Dane te pojawią się na fakturach AWS.

Na tym etapie nic jeszcze nie płacisz. AWS musi natomiast przeprowadzić weryfikację telefonu i karty, zanim puści cię do konsoli.

Weryfikacja telefonu i karty płatniczej

Potwierdzenie tożsamości i pierwszy dostęp do konsoli

Po wprowadzeniu danych pojawią się dwa etapy: weryfikacja telefonu oraz karty płatniczej.

1. Weryfikacja telefonu – podajesz numer, wybierasz SMS lub połączenie głosowe. AWS wysyła kod, który przepisujesz w formularzu. Zdarza się chwilowe opóźnienie, więc nie klikaj „wyślij ponownie” w panice co 5 sekund.
2. Autoryzacja karty – AWS wykona niewielką blokadę na karcie (często kilka jednostek lokalnej waluty). Po chwili blokada znika. Jeśli transakcja zostanie odrzucona, nie przejdziesz dalej.

Na końcu wybierasz plan wsparcia. Do nauki wybierz „Basic support – Free”: płatne plany typu Developer/Business mają sens dopiero przy produkcyjnych projektach.

Gdy wszystkie kroki przejdą poprawnie, po kilku minutach dostajesz e-mail z potwierdzeniem aktywacji konta. Od tej chwili możesz logować się do AWS Management Console używając adresu e-mail i hasła konta root.

Pierwsze logowanie i zabezpieczenie konta (MFA, IAM)

Pierwsze wejście do konsoli i wybór regionu

Po zalogowaniu do konsoli AWS pierwsze, co rzuca się w oczy, to wybór regionu (prawy górny róg interfejsu). Region to fizyczna lokalizacja centrum danych (np. eu-central-1 – Frankfurt, eu-west-1 – Irlandia).

Dobrą praktyką jest od razu „przyklejenie się” do jednego regionu, np. Frankfurt (eu-central-1) dla użytkownika z Polski. Dzięki temu zasoby będą blisko geograficznie (mniejsze opóźnienia) i rozliczenia będą spójne. Później przy każdym logowaniu zwracaj uwagę, czy w prawym górnym rogu nadal masz ten sam region, bo zasoby są powiązane właśnie z nim.

Włączenie MFA (Multi-Factor Authentication) na koncie root

Konto root ma pełnię władzy, więc musi być maksymalnie zabezpieczone. Pierwszy krok po zalogowaniu:

1. Przejdź do IAM (w wyszukiwarce usług wpisz „IAM”).
2. W menu wybierz Dashboard. Powinien tam być widoczny kafelek z ostrzeżeniem, że konto root nie ma MFA.
3. Kliknij „Add MFA” przy koncie root i wybierz typ urządzenia:
   • Virtual MFA device – aplikacja w telefonie (np. Authy, Google Authenticator, 1Password).
   • Fizyczny token – raczej niepotrzebny na start.
4. Zeskanuj kod QR aplikacją, wpisz dwa kolejne wygenerowane kody i zatwierdź.

Od teraz logowanie na konto root będzie wymagało hasła i jednorazowego kodu z aplikacji. To ratuje przed skutkami wycieku hasła.

Założenie osobnego użytkownika IAM do codziennej pracy

Następny krok to stworzenie użytkownika IAM z uprawnieniami administracyjnymi i odłożenie konta root na półkę.

1. W IAM przejdź do Users → Add users.
2. Wpisz nazwę użytkownika, np. admin-dev.
3. Zaznacz opcję AWS Management Console access.
4. Wybierz „I want to create an IAM user” z własnym hasłem, ustaw silne hasło i zaznacz wymuszenie zmiany przy pierwszym logowaniu, jeśli chcesz.
5. W kroku z uprawnieniami wybierz:
   • Add user to group, a następnie utwórz nową grupę, np. Admins.
   • Do grupy przypisz policy AdministratorAccess (pełne uprawnienia administracyjne w ramach usług, bez aspektów billingowych konta root).
6. Zatwierdź tworzenie użytkownika. Zapisz adres login URL (tzw. IAM sign-in link) lub numer konta (Account ID) – będzie potrzebny do logowania.

Od tej chwili loguj się na co dzień jako ten użytkownik IAM. Konto root będzie potrzebne rzadko, np. do zmiany metody płatności czy zamknięcia konta.

MFA dla użytkownika IAM i higiena haseł

Użytkownik IAM też powinien mieć włączone MFA. Procedura jest bardzo podobna do tej dla konta root:

1. Zaloguj się jako nowo utworzony użytkownik IAM.
2. W prawym górnym rogu kliknij nazwę użytkownika → Security credentials.
3. W sekcji Multi-factor authentication kliknij Assign MFA device i przejdź podobny proces z aplikacją OTP.

Przy okazji ogarnij kilka prostych zasad:

• nie używaj tego samego hasła, co do e-maila lub innych serwisów,
• hasło trzymaj w menedżerze haseł, nie w notatniku na pulpicie,
• nie wysyłaj linku do logowania IAM innym osobom – każda osoba powinna mieć własnego użytkownika.

Konfiguracja budżetu i alertów kosztowych

Włączenie AWS Billing i dostęp do Cost Management

Aby tworzyć budżety, użytkownik IAM musi mieć dostęp do sekcji rozliczeń. Na początek zrób to z konta root:

1. Zaloguj się jako root i przejdź do Billing & Cost Management (ikonka swojego profilu → Billing).
2. W sekcji IAM User and Role Access to Billing Information zaznacz, że użytkownicy IAM mogą widzieć dane billingowe.

Następnie wyloguj się z konta root i wróć do użytkownika IAM. Teraz w konsoli wpisz w wyszukiwarce „Billing” lub przejdź do sekcji Cost Management.

Ustawienie prostego budżetu miesięcznego

Najprostszy, a bardzo skuteczny mechanizm to budżet typu „Monthly cost budget” z alertem mailowym. Przykładowa konfiguracja:

1. W zakładce Budgets kliknij Create budget.
2. Wybierz typ Cost budget (budżet kosztowy) i tryb miesięczny.
3. Wpisz kwotę, która ma być „bezpiecznym sufitem” – np. 5 USD na sam początek nauki.
4. Przejdź do sekcji Alerts:
   • Dodaj alert np. przy 80% budżetu (czyli 4 USD) oraz opcjonalnie przy 100%.
   • Podaj adres e-mail, na który ma przyjść powiadomienie (najlepiej prywatny, który regularnie czytasz).
5. Zapisz budżet.

Od teraz, gdy przewidywane lub realne koszty w danym miesiącu zbliżą się do zdefiniowanej kwoty, dostaniesz e-mail. To nie zatrzyma automatycznie usług, ale da sygnał, że coś się dzieje – np. przypadkiem uruchomiona druga instancja.

Alerty na poziomie Free Tier (wczesne ostrzeżenie)

Oprócz budżetu ogólnego przydaje się włączyć Free Tier usage alerts:

1. W zakładce Billing przejdź do Free Tier.
2. Zaznacz opcję wysyłania powiadomień e-mail, gdy zbliżasz się do limitów Free Tier.
3. Dodaj adres e-mail (może być ten sam, co w budżetach).

Ten mechanizm ostrzega, gdy np. zużywasz nietypowo dużo godzin EC2 lub miejsca w EBS. Przy nauce i krótkich eksperymentach to bardzo dobre „wczesne ostrzeżenie”.

Podstawowe pojęcia AWS, które trzeba ogarnąć przed pierwszym serwerem

Region, Availability Zone i VPC – gdzie właściwie jest twój serwer

Kluczowe pojęcia z warstwy „gdzie to wszystko stoi”:

• Region – grupa centrów danych w określonym kraju/obszarze (np. eu-central-1 – Niemcy). Wybierasz go raz i w nim tworzysz większość zasobów.
• Availability Zone (AZ) – pojedyncze centrum danych w regionie, oznaczone literą: eu-central-1a, eu-central-1b itd. Dla prostego serwera zwykle nic z tym nie robisz ręcznie – AWS sam wybierze AZ.
• VPC (Virtual Private Cloud) – logiczna, prywatna sieć w AWS, w której żyją twoje instancje. Każde konto dostaje domyślne VPC w każdym regionie.

Na start możesz spokojnie korzystać z domyślnego VPC i automatycznie przypisywanego subnetu oraz AZ. Własną topologią sieciową zajmiesz się później.

EC2, EBS, S3 – podstawowy „trójkąt” usług

Dla prostego serwera WWW kluczowe są trzy usługi:

• EC2 (Elastic Compute Cloud) – instancje, czyli wirtualne serwery (VM). Wybierasz typ, system i konfigurację.
• EBS (Elastic Block Store) – dyski blokowe podpinane do instancji EC2. Dla serwera to odpowiednik dysku systemowego/SSD.
• S3 (Simple Storage Service) – obiektowa przestrzeń na pliki (bucket + obiekty). Przydaje się do kopii, statycznych plików, snapshotów itd.

Twój „tani serwer” to w praktyce: jedna instancja EC2, jeden dysk EBS i ewentualnie jakiś bucket S3 w tle, np. na backupy. Reszta usług (RDS, ElastiCache, ALB) na początek może zostać nieużywana, żeby nie przepalać budżetu.

Security Group i Network ACL – kto może się połączyć

Na poziomie bezpieczeństwa sieci liczą się dwa mechanizmy:

• Security Group (SG) – coś jak wirtualny firewall dla instancji. Określa, z jakich adresów IP i na jakie porty można się łączyć. Działa na poziomie instancji.
• Network ACL (Access Control List) – filtr na poziomie subnetu, mniej wygodny na start. Zwykle nie trzeba go ruszać, domyślna konfiguracja jest wystarczająca.

Dla prostego serwera zajmiesz się głównie Security Group: otworzysz port 22 (SSH), 80 (HTTP) i 443 (HTTPS), resztę zostawiając domyślnie zamkniętą.

Public IP, Elastic IP i DNS – jak się dostać do serwera

Instancja EC2 może mieć przypisane publiczne IP, dzięki czemu można się z nią łączyć z internetu. Są dwa warianty:

• Dynamiczne public IP – przydzielane automatycznie. Zmienia się po zatrzymaniu i ponownym uruchomieniu instancji.
• Elastic IP (EIP) – stałe publiczne IP przypisane do konta. Można je przepinać między instancjami.

Do nauki i prostego serwera wystarczy dynamiczne public IP i rekord DNS w zewnętrznym panelu domeny wskazujący na ten adres. Elastic IP ma sens, jeśli często będziesz restartować instancję i chcesz zachować stały adres.

Plan na tani serwer: co dokładnie będziesz uruchamiać

Założenia: jeden serwer, minimalna konfiguracja

Solidny, „budżetowy” plan wygląda tak:

• Region: eu-central-1 (Frankfurt) lub inny europejski.
• Instancja: t2.micro lub t3.micro z Linuxem (np. Amazon Linux 2, Ubuntu LTS).
• Dysk: 10–20 GB EBS typu GP3 (General Purpose SSD).
• Sieć: domyślne VPC, publiczny subnet, automatyczne publiczne IP.
• Security Group: porty 22, 80, 443 otwarte z odpowiednich adresów.
• Oprogramowanie: nginx lub Apache, ewentualnie Docker dla prostych kontenerów.

Taki zestaw jest w dużej mierze w obrębie Free Tier, o ile nie przekroczysz limitu godzin i przestrzeni dyskowej. Nadaje się zarówno do statycznej strony, jak i prostego backendu (np. małe API w Node.js czy Pythonie).

Wybór systemu operacyjnego i AMI

Przy uruchamianiu instancji EC2 wybierasz AMI (Amazon Machine Image) – szablon systemu z preinstalowanymi komponentami. Do pierwszego serwera:

• Amazon Linux 2 – dobra, „domyślna” dystrybucja AWS; lekkie, dobrze wspierane, sensowne do nauki.
• Ubuntu Server LTS – jeśli lubisz Ubuntu i masz już z nim doświadczenie.

Oba obrazy mają bezproblemowy dostęp do repozytoriów pakietów i dokumentacji. Komercyjne AMI z preinstalowanymi aplikacjami (np. panele hostingowe) często są płatne – na start nie ma sensu ich używać.

Co z backupem i logami na początek

W pierwszej wersji serwera wystarczą bardzo proste rozwiązania:

• okazjonalny snapshot EBS wykonywany ręcznie z konsoli (np. przed większymi zmianami),

• zrzut bazy danych / plików na lokalny komputer lub inne zewnętrzne konto (np. drugi bucket S3 w innym regionie),
• logi systemowe (np. /var/log) trzymane lokalnie, rotowane narzędziem typu logrotate.

Na dalszym etapie możesz dołożyć AWS Backup lub wysyłanie logów do CloudWatch Logs, ale na pierwsze tygodnie nauki prosty snapshot + kopia danych aplikacji w zupełności wystarczą.

Konfiguracja sieci: VPC, subnet, security group bez nadmiaru magii

Użycie domyślnego VPC zamiast ręcznego projektowania

Każdy region ma na świeżym koncie AWS domyślne VPC z kilkoma publicznymi subnetami i bramą internetową (Internet Gateway). Do pierwszego serwera nie ma sensu tego ruszać. Przy uruchamianiu EC2:

• zostaw Default VPC,
• wybierz dowolny subnet oznaczony jako „Public” (ma trasę do internetu),
• upewnij się, że Auto-assign public IP jest ustawione na Enable.

Taka konfiguracja zapewnia dostęp serwera do internetu i możliwość wejścia na niego z zewnątrz. Własne prywatne subnety, NAT Gateway i inne klocki przydadzą się dopiero przy bardziej złożonej architekturze.

Tworzenie Security Group dla pierwszego serwera

Security Group zdefiniujesz podczas tworzenia instancji EC2 lub osobno w sekcji VPC. Rozsądna konfiguracja startowa wygląda tak:

1. Utwórz nową Security Group w tym samym VPC, w którym będzie instancja.
2. Nadaj jej czytelną nazwę, np. webserver-basic-sg.
3. W zakładce Inbound rules dodaj reguły:
   • SSH (22) – Source: My IP, żeby logować się tylko z własnego adresu (nie 0.0.0.0/0).
   • HTTP (80) – Source: 0.0.0.0/0, jeśli serwis ma być publiczny.
   • HTTPS (443) – również 0.0.0.0/0, pod przyszły certyfikat TLS.
4. Outbound rules zostaw domyślnie na Allow all, aby serwer mógł aktualizować pakiety i łączyć się z zewnętrznymi serwisami.

Jeśli korzystasz z internetu mobilnego (dynamiczne IP), regułę SSH z My IP trzeba będzie czasem przeedytować. Alternatywą jest tunel przez VPN lub narzędzie typu AWS Systems Manager Session Manager, ale to już kolejny poziom zabawy.

Publiczny vs prywatny subnet – co to zmienia

Subnet staje się „publiczny”, gdy ma trasę do Internet Gateway oraz instancja w nim ma publiczne IP. W praktyce:

• serwer WWW dla nauki ląduje w publicznym subnecie,
• bazy danych, wewnętrzne API itd. zwykle umieszcza się później w prywatnym subnecie bez publicznych IP, z dostępem tylko z aplikacji.

Przy jednym serwerze nie ma sensu bawić się w dodatkowe subnety. Wystarczy domyślny publiczny subnet, Security Group z ograniczonym SSH oraz regularne aktualizacje systemu.

Routing i dostęp do internetu w skrócie

Żeby instancja mogła gadać z internetem, musi mieć:

• trasę 0.0.0.0/0 → Internet Gateway w tablicy routingu subnetu,
• publiczne IP (dynamiczne lub Elastic IP) przypisane do interfejsu sieciowego,
• Security Group pozwalającą na ruch wychodzący.

Domyślne VPC i publiczny subnet mają to skonfigurowane. Jeśli nagle przestaniesz mieć dostęp po SSH, a nic nie ruszałeś w systemie, zwykle problem leży w SG (zmieniona reguła) albo w tym, że instancja straciła publiczne IP po zatrzymaniu i ponownym starcie.

Statyczny adres: kiedy użyć Elastic IP

Dla testów wystarczy dynamiczne publiczne IP i szybkie sprawdzenie adresu w konsoli EC2. Jeśli jednak:

• podpinasz pod serwer własną domenę,
• nie chcesz poprawiać rekordu DNS po każdym restarcie instancji,
• planujesz np. małe API używane przez inne usługi,

rozsądnie jest przydzielić Elastic IP i podpiąć je do instancji. EIP jest darmowe, o ile jest przypięte do działającej instancji. Koszty pojawiają się wtedy, gdy trzymasz EIP „luzem” lub masz ich kilka nieużywanych.

Krótki przegląd bezpieczeństwa sieci na start

Przy jednym serwerze najczęstsze błędy, które kończą się nieprzyjemnymi rachunkami albo skanowaniem z całego świata:

• otwarty SSH (22) na 0.0.0.0/0 – boty będą próbowały logowania słownikowego niemal od razu,
• zbędne porty otwarte „na wszelki wypadek” – lepiej dodać regułę, gdy faktycznie jej potrzebujesz,
• brak aktualizacji i domyślne hasła w panelach webowych (np. phpMyAdmin) dostępnych z internetu.

W praktyce: ogranicz SSH do swojego IP lub używaj kluczy SSH bez logowania hasłem, włącz regularne aktualizacje i usuwaj serwisy, których nie używasz. To już mocno podnosi poziom bezpieczeństwa przy minimalnym wysiłku.

Uruchomienie instancji EC2 krok po kroku (wariant uproszczony)

Start kreatora EC2 i wybór regionu

Najpierw ustaw poprawny region w prawym górnym rogu konsoli (np. EU (Frankfurt) eu-central-1). Potem:

1. przejdź do usługi EC2,
2. w sekcji Instances kliknij Launch instance.

Kreator przeprowadzi przez kolejne kroki: nazwę, wybór AMI, typ instancji, klucz SSH, dysk i sieć.

Minimalna konfiguracja instancji

Przy pierwszym serwerze możesz użyć takiego zestawu ustawień:

1. Name and tags – nadaj nazwę instancji, np. dev-web-1. Tag Name ułatwia później ogarnięcie wielu maszyn.
2. Application and OS Images (AMI) – wybierz Amazon Linux 2 lub Ubuntu Server LTS, wersję x86 (nie ARM), żeby uniknąć niespodzianek z kompatybilnością narzędzi.
3. Instance type – zaznacz t2.micro lub t3.micro (zależnie od dostępności Free Tier w twoim regionie).
4. Key pair (login) – utwórz nowy klucz:
   • podaj nazwę, np. dev-key-eu,
   • format PEM (dla SSH na Linux/macOS) lub PPK (dla PuTTY na Windows),
   • zapisz plik w bezpiecznym miejscu, z odpowiednimi uprawnieniami.
5. Network settings:
   • VPC: Default,
   • Subnet: dowolny publiczny,
   • Auto-assign public IP: Enable,
   • Security Group: wybierz utworzoną wcześniej SG z portami 22/80/443.
6. Configure storage:
   • typ: gp3,
   • rozmiar: 10–20 GB,
   • Encryption: Enabled (szyfrowanie dysku; bez dodatkowych kosztów).

Na koniec sprawdź podsumowanie, czy gdzieś po drodze kreator nie dodał dodatkowych płatnych usług (np. dedykowanego monitoringu zewnętrznego), i kliknij Launch instance.

Logowanie SSH do nowej instancji

Gdy status instancji będzie running, możesz się zalogować. Najpierw odczytaj jej publiczne IP z konsoli EC2. Następnie:

• Linux/macOS:

  chmod 600 dev-key-eu.pem
  ssh -i dev-key-eu.pem ec2-user@TWOJE_PUBLICZNE_IP    # Amazon Linux
  # albo
  ssh -i dev-key-eu.pem ubuntu@TWOJE_PUBLICZNE_IP      # Ubuntu

• Windows (PuTTY):
  1. przekonwertuj klucz PEM do PPK w PuTTYgen (jeśli trzeba),
  2. w PuTTY ustaw hostname: ec2-user@TWOJE_PUBLICZNE_IP lub ubuntu@...,
  3. w Connection → SSH → Auth wskaż plik .ppk.

Po pierwszym zalogowaniu zrób od razu aktualizację pakietów, np. sudo yum update -y lub sudo apt update && sudo apt upgrade -y.

Instalacja prostego stacku WWW

Na świeżej instancji warto od razu doinstalować minimalne środowisko do serwowania stron. Na przykład na Amazon Linux 2:

# Amazon Linux 2
sudo yum install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx

Na Ubuntu komendy będą analogiczne, tylko z użyciem apt. Po uruchomieniu nginx:

• wejdź w przeglądarce na http://TWOJE_PUBLICZNE_IP,
• powinieneś zobaczyć domyślną stronę powitalną nginx – to znak, że sieć i SG są poprawnie ustawione.

Dalej możesz podmienić katalog /usr/share/nginx/html na własną aplikację lub skonfigurować wirtualne hosty.

Podstawowe praktyki oszczędzania kosztów przy jednym serwerze

Zatrzymywanie instancji, gdy jej nie używasz

Instancja EC2 liczy się do rozliczeń za każdą rozpoczętą godzinę działania. Jeżeli używasz jej tylko do nauki wieczorami:

• po zakończeniu pracy w konsoli EC2 wybierz instancję → Instance state → Stop,
• przy kolejnym logowaniu uruchom ją z powrotem,
• pamiętaj, że przy dynamicznym IP adres się zmieni – sprawdź go w konsoli.

Sam dysk EBS jest nadal płatny, ale to znacznie mniejszy koszt niż ciągłe działanie instancji. W Free Tier i tak masz pewien zapas godzin, jednak nawyk wyłączania „zabawek” zaprocentuje przy większych projektach.

Kontrola wolumenów EBS i snapshotów

Najczęstsza pułapka początkujących to zapomniane dyski i snapshoty:

• po usunięciu instancji sprawdź w sekcji Volumes, czy nie został odpięty EBS, który nadal generuje koszty,
• przejrzyj Snapshots – stare, niepotrzebne kopie można śmiało kasować.

Tip: zanim usuniesz wolumen lub snapshot, upewnij się, że nie jest to jedyna kopia danych, których możesz jeszcze potrzebować.

Minimalizacja transferu danych

Transfer wyjściowy (z AWS do internetu) po przekroczeniu darmowego limitu również kosztuje. Przy pojedynczym dev-serwerze to zwykle grosze, ale są dwa scenariusze, które potrafią zrobić rachunek:

• udostępnianie dużych plików (backupy, wideo, archiwa) wprost z EC2,
• publiczne API, które jest scraperowane / nadużywane.

Do dużych plików lepiej wykorzystać S3 + ewentualnie CloudFront, a API ograniczyć np. przez prosty rate limiting w nginx lub w samej aplikacji.

Regularne przeglądy Cost Explorer

Raz na tydzień dobrze jest rzucić okiem w Cost Explorer (Billing → Cost Explorer):

• ustaw widok na aktualny miesiąc i grupowanie po Service,
• sprawdź, które usługi generują koszty (przy prostym serwerze głównie EC2 + EBS),
• jeśli widzisz coś niespodziewanego (np. NAT Gateway, Lambda, S3 w innym regionie) – kliknij w szczegóły i reaguj.

To proste narzędzie bardzo szybko pokazuje, czy budżet trzyma się w ryzach, czy coś wymknęło się spod kontroli.

Najczęściej zadawane pytania (FAQ)

Czy AWS jest dobrym wyborem na mój pierwszy serwer, czy lepiej wziąć zwykły hosting?

Jeśli chcesz mieć pełny dostęp do systemu (root), uczyć się Linuksa, sieci i narzędzi DevOps, AWS będzie lepszym wyborem niż klasyczny hosting współdzielony. Dostajesz wirtualną maszynę (EC2), którą konfigurujesz tak jak VPS: wybierasz system, pakiety, firewall, automatyzację.

Jeśli natomiast Twoim celem jest tylko prosty WordPress, bez grzebania w konfiguracji, wygodniejszy i spokojniejszy finansowo będzie zwykły hosting z panelem „1‑click install”. AWS ma większą elastyczność, ale wymaga też zrozumienia kilku dodatkowych klocków (EC2, EBS, VPC, security group).

Ile realnie kosztuje pierwszy, mały serwer na AWS dla początkującego?

Nowe konto AWS korzysta z Free Tier, który przez 12 miesięcy pozwala uruchomić małą instancję t2.micro lub t3.micro (1 vCPU, 1 GB RAM) przez ok. 750 godzin miesięcznie, czyli jedną maszynę działającą non stop. Do tego masz ok. 30 GB dysku EBS typu General Purpose SSD w cenie.

Przy scenariuszu: jedna instancja t2.micro / t3.micro, dysk 10–20 GB, mały ruch i brak dodatkowych usług, rachunek zwykle oscyluje w okolicy zera lub kilku dolarów miesięcznie. Koszty zaczynają rosnąć, gdy: podnosisz typ instancji, dodajesz kolejne maszyny, zwiększasz pojemność dysku albo generujesz duży transfer wychodzący (np. serwer plików, wideo).

Jak korzystać z Free Tier AWS, żeby nie przepłacić?

Podstawowa zasada: trzymaj się zasobów oznaczonych jako „Free Tier eligible” i minimalnej konfiguracji. Dla prostego serwera WWW oznacza to: jedną instancję t2.micro / t3.micro, jeden dysk EBS do 20–30 GB, domyślne VPC i jedną security group z otwartymi portami 22, 80 i ewentualnie 443.

Unikaj uruchamiania wielu instancji równolegle, wybierania większych typów maszyn (np. t3.small, t3.medium), zakładania dużych dysków i włączania dodatkowych usług (np. RDS, zaawansowane usługi sieciowe), jeśli nie wiesz dokładnie, jak są rozliczane. Tip: wszystko, czego nie rozumiesz w konsoli AWS – zostaw na później.

Jak ustawić budżet na AWS, żeby nie dostać niespodziewanego rachunku?

Budżet ustawia się w usłudze AWS Budgets. Tworzysz nowy budżet kosztowy, definiujesz miesięczny limit (np. 5 USD lub 20 zł) i konfigurujesz alerty e‑mail przy przekroczeniu określonego progu (np. 50%, 80%, 100% budżetu). Dzięki temu przy pierwszych odchyleniach od planu dostajesz ostrzeżenie.

Dodatkowo dobrze jest regularnie zaglądać do Cost Explorer i do listy uruchomionych zasobów (EC2, EBS, Elastic IP). Uwaga: budżet sam w sobie nie wyłącza zasobów – tylko informuje. To Ty musisz ręcznie zatrzymać lub skasować instancje, których już nie potrzebujesz.

Jaką minimalną konfigurację EC2 wybrać na tani serwer WWW?

Do nauki i małej strony WWW zwykle wystarczy:

• typ instancji: t2.micro lub t3.micro (Free Tier eligible),
• system: lekka dystrybucja Linuksa (np. Amazon Linux, Ubuntu Server),
• dysk EBS: 10–20 GB typu GP2/GP3 (General Purpose SSD),
• sieć: domyślne VPC i subnet,
• security group: otwarte porty 22 (SSH), 80 (HTTP) i opcjonalnie 443 (HTTPS).

Na takim serwerze postawisz nginx lub Apache, prostą aplikację webową czy testowe API. Do bardziej zasobożernych zastosowań (ciężki WordPress z wieloma wtyczkami, większe bazy danych) może być potrzebna mocniejsza instancja, ale to wyjdzie dopiero w testach.

Jakie są najczęstsze pułapki kosztowe na AWS dla początkujących?

Najczęstszy problem to „zapomniane” zasoby, które nadal naliczają opłaty. Typowe przykłady: dodatkowe dyski EBS pozostawione po skasowaniu instancji, snapshoty, nieużywane Elastic IP, drugie i trzecie instancje odpalone „na chwilę” do testów, które zostają włączone na stałe.

Dobry nawyk: po każdej sesji testów sprawdź w konsoli EC2 listę instancji, dysków i adresów IP, a w zakładce Billing & Cost Management – podgląd bieżących kosztów. Jeśli czegoś już nie potrzebujesz, nie zatrzymuj tylko – usuń, szczególnie w przypadku dysków i snapshotów.

Czy do prostej strony WWW na AWS muszę od razu używać wszystkich „zaawansowanych” usług?

Nie. Na start wystarczy absolutne minimum: EC2 (instancja serwera), EBS (dysk), domyślne VPC i jedna security group. Reszta usług (RDS, load balancery, kolejki, kontenery) to narzędzia na później – gdy pojawi się realna potrzeba skalowania albo chęć nauki konkretnych rozwiązań.

W praktyce dużo osób odpala jedną małą instancję z nginxem, podpina domenę (DNS może być poza AWS) i w tym środowisku spokojnie uczy się administracji, backupów, deployu aplikacji czy automatyzacji. Rozszerzanie architektury o kolejne usługi ma sens dopiero wtedy, gdy rozumiesz ich rolę i koszt.

Najważniejsze punkty

• AWS to elastyczna platforma chmurowa, na której sam składasz infrastrukturę z klocków (EC2 – serwer, EBS – dysk, VPC/security group – sieć), zamiast kupować gotowy „pakiet” jak w hostingu współdzielonym.
• Dla początkujących AWS ma najwięcej sensu przy małych stronach WWW, testowych API/aplikacjach webowych oraz do nauki DevOps i chmury (Terraform, kontenery, monitoring).
• AWS wygrywa, gdy potrzebujesz pełnego dostępu do systemu (root), chcesz się uczyć administracji i skalowania oraz nie chcesz blokować się ograniczeniami klasycznego hostingu; typowy hosting jest lepszy, gdy liczysz na „kliknij i działa” bez grzebania w konsoli.
• Model pay-as-you-go (płacisz za zużycie) daje dużą elastyczność – możesz włączać i wyłączać serwery jak potrzebujesz – ale łatwo przeklikać drogie opcje (większe dyski, kilka instancji, dodatkowe IP) i wygenerować nieplanowany rachunek.
• Free Tier daje nowym kontom konkretne darmowe limity, np. 12 miesięcy instancji t2.micro/t3.micro do 750 godzin miesięcznie i ok. 30 GB dysku EBS, ale nie obejmuje wszystkiego (nadmiarowy transfer, dodatkowe dyski, snapshoty).
• Bezpieczne pierwsze kroki to trzymanie się jednej małej instancji EC2 w Free Tier, domyślnego VPC i prostej security group oraz zasada: jeśli nie rozumiesz danej usługi lub opcji – nie włączaj jej.

Opracowano na podstawie

• Overview of Amazon Web Services. Amazon Web Services (2023) – Przegląd głównych usług AWS: EC2, EBS, VPC, RDS, S3 i inne
• Amazon EC2 User Guide for Linux Instances. Amazon Web Services (2023) – Szczegóły działania instancji EC2, typy, rozliczanie godzinowe
• Cloud Computing: Concepts, Technology & Architecture. Prentice Hall (2013) – Ogólne modele chmury, IaaS vs hosting tradycyjny, rozliczanie za zużycie