Wprowadzenie do chmury AWS

Wstęp

Przeglądając oferty pracy dla programistów, pewnie zauważyłeś, że „znajomość AWS” lub „doświadczenie z chmurą” pojawia się praktycznie wszędzie. Nie ma znaczenia, czy szukasz pracy jako backend developer, fullstack czy DevOps – chmura jest dzisiaj standardem. I to nie jakiś trend, który za chwilę minie. Firmy przenoszą swoje systemy do chmury masowo, a te, które jeszcze tego nie zrobiły, planują to w najbliższych latach.

Dotyczy to też polskiego rynku. Allegro, mBank, PZU, CD Projekt – coraz więcej polskich firm korzysta z AWS lub migruje swoją infrastrukturę do chmury. A za firmami idą oferty pracy, w których „doświadczenie z AWS” przestaje być miłym dodatkiem, a staje się wymaganiem.

Problem w tym, że AWS to ogromny ekosystem. Ponad 200 usług, dziesiątki certyfikacji, nowa usługa co miesiąc. Łatwo się w tym pogubić, szczególnie na początku. Pewnie się zastanawiasz – od czego w ogóle zacząć? Które usługi są naprawdę ważne, a które mogę spokojnie pominąć? Ile to kosztuje i czy przypadkiem nie dostanę rachunku na kilkaset dolarów po pierwszym tygodniu nauki?

Sam zacząłem naukę AWS w 2025 roku i pamiętam ten moment, gdy po raz pierwszy otworzyłem konsolę AWS i zobaczyłem listę 200+ usług. Pierwsza myśl? „Od czego tu w ogóle zacząć?”. Dlatego powstał ten wpis – żeby oszczędzić Ci tego chaosu, przez który sam przechodziłem.

W tym wpisie chcę Ci pokazać czym jest AWS, dlaczego warto go znać jako programista i jak stawiać pierwsze kroki bez stresu o koszty. Przejdziemy przez najważniejsze usługi, pokażę Ci jak założyć konto i na co zwrócić uwagę, żeby uniknąć niespodzianek na fakturze. A na koniec pokażę Ci od czego zacząć naukę AWS.

Czym jest AWS?

Zanim przejdziemy do konkretów, wyjaśnijmy sobie jedną rzecz – czym właściwie jest ta „chmura obliczeniowa”?

Najprościej mówiąc, chmura to nic innego jak cudze komputery 🙂 Brzmi banalnie, ale w gruncie rzeczy tak to działa. Zamiast kupować własne serwery, stawiać je w serwerowni, konfigurować, chłodzić i utrzymywać – wynajmujesz zasoby od kogoś, kto już to wszystko ma. Płacisz za to, czego używasz, i możesz w każdej chwili zwiększyć lub zmniejszyć swoje zasoby.

Wyobraź sobie, że zamiast kupować samochód na własność, korzystasz z wypożyczalni. Potrzebujesz małego auta na co dzień? Proszę bardzo. W weekend planujesz przeprowadzkę i potrzebujesz busa? Zamieniasz na weekend i oddajesz w poniedziałek. Nie martwisz się o przeglądy, ubezpieczenie czy naprawy – tym zajmuje się wypożyczalnia. Z chmurą jest podobnie.

Amazon Web Services (AWS) to największy dostawca usług chmurowych na świecie. Wystartował w 2006 roku, kiedy Amazon postanowił udostępnić swoją infrastrukturę innym firmom. Dzisiaj AWS ma około 29% rynku chmurowego, wyprzedzając Microsoft Azure (~20%) i Google Cloud (~13%). Korzystają z niego firmy od małych startupów po gigantów typu Netflix, Airbnb czy NASA.

Modele usług chmurowych

Dobra, ale co to oznacza w praktyce? AWS oferuje różne modele usług i dobrze je rozróżniać, bo od tego zależy ile pracy bierzesz na siebie, a ile oddajesz dostawcy chmury.

IaaS (Infrastructure as a Service) – dostajesz „goły” serwer w chmurze. Sam instalujesz system operacyjny, konfigurujesz środowisko, dbasz o aktualizacje i bezpieczeństwo. Masz pełną kontrolę, ale też pełną odpowiedzialność – od patchowania systemu po konfigurację firewalla. Przykład w AWS to EC2 – wirtualna maszyna, na której możesz postawić co chcesz. Tworzysz instancję, wybierasz ile CPU i RAM potrzebujesz, instalujesz Javę i odpalasz swojego JAR-a. Jeśli do tej pory stawiałeś aplikacje na VPS-ach (np. na DigitalOcean czy OVH), to EC2 działa na tej samej zasadzie.
PaaS (Platform as a Service) – dostajesz gotową platformę do uruchamiania aplikacji. Nie musisz się martwić o system operacyjny, aktualizacje ani skalowanie – tym zajmuje się AWS. Ty dostarczasz tylko swoją aplikację. Przykład to Elastic Beanstalk – wrzucasz JAR/WAR, a Beanstalk sam konfiguruje serwer, load balancer i auto-scaling. Różnica między IaaS a PaaS? W IaaS konfigurujesz wszystko sam (więcej kontroli, więcej pracy). W PaaS oddajesz kontrolę w zamian za wygodę. Dla większości aplikacji webowych PaaS w zupełności wystarczy, a oszczędza mnóstwo czasu na utrzymanie.
SaaS (Software as a Service) – gotowe oprogramowanie, z którego korzystasz przez przeglądarkę. Nie wdrażasz, nie konfigurujesz, nie utrzymujesz – po prostu logujesz się i używasz. Przykłady z AWS to Amazon WorkMail (poczta e-mail) czy Amazon Chime (wideokonferencje). Poza ekosystemem AWS – SaaS-em jest np. Gmail, Slack czy Jira. Jako programista korzystasz z SaaS-ów codziennie, ale raczej jako użytkownik, nie jako twórca.

Jako programista najczęściej będziesz pracować z usługami z kategorii IaaS i PaaS – to na nich budujesz i wdrażasz swoje aplikacje. Na rozmowach rekrutacyjnych pytanie o różnicę między IaaS, PaaS i SaaS pojawia się zaskakująco często, więc warto mieć to dobrze poukładane w głowie.

Regiony i strefy dostępności

Jeszcze jedna rzecz, o której warto wiedzieć na start – infrastruktura globalna AWS. AWS ma swoje centra danych rozrzucone po całym świecie i organizuje je w kilka warstw. Brzmi skomplikowanie, ale zaraz zobaczysz, że to logiczny podział.

Region to geograficzna lokalizacja, w której AWS ma swoje centra danych. Każdy region ma swoją nazwę kodową – np. eu-central-1 to Frankfurt, us-east-1 to Wirginia, eu-west-1 to Irlandia. Aktualnie AWS ma ponad 30 regionów na świecie i regularnie dodaje nowe. Przy tworzeniu zasobów (instancji EC2, bazy RDS, bucketa S3) zawsze wybierasz region. Dane zostają w tym regionie – nie są automatycznie kopiowane między regionami. To ważne zarówno ze względu na wydajność (im bliżej użytkowników, tym mniejsze opóźnienia), jak i na regulacje prawne (np. RODO wymaga, żeby dane obywateli UE były przetwarzane na terenie UE).
Dla nas, programistów z Polski, najbliższy region to eu-central-1 (Frankfurt). Warto o tym pamiętać przy tworzeniu zasobów i ustawiać go jako domyślny.
Availability Zone (AZ) to fizycznie oddzielne centrum danych w ramach jednego regionu. Każdy region ma minimum dwie, a zazwyczaj trzy strefy dostępności. Są one połączone szybką, prywatną siecią, ale znajdują się w oddzielnych budynkach, z osobnym zasilaniem i chłodzeniem. Po co? Żeby jeśli jedno centrum padnie (pożar, powódź, awaria prądu), Twoja aplikacja nadal działała w pozostałych strefach. Kiedy tworzysz instancję EC2, wybierasz konkretną AZ (np. eu-central-1a). Żeby mieć wysoką dostępność, uruchamiasz instancje w co najmniej dwóch AZ – jeśli jedna padnie, ruch automatycznie przechodzi na drugą.
Local Zone to rozszerzenie regionu, umieszczone bliżej konkretnych miast. Wyobraź sobie, że masz aplikację dla użytkowników w Warszawie, ale najbliższy region AWS to Frankfurt. Opóźnienie na trasie Warszawa-Frankfurt to kilkanaście milisekund. Dla większości aplikacji webowych to niezauważalne. Ale jeśli budujesz coś, co wymaga minimalnych opóźnień (np. gry online, streaming wideo, aplikacje real-time), te milisekundy mają znaczenie. Local Zone pozwala uruchomić wybrane usługi (np. EC2, EBS) bliżej użytkowników. Na ten moment Local Zones są dostępne głównie w dużych miastach USA – ale AWS sukcesywnie dodaje nowe lokalizacje.
Edge Location to infrastruktura AWS najbliżej użytkownika końcowego. To nie są pełne centra danych, a raczej serwery cache’ujące rozmieszczone w ponad 400 lokalizacjach na świecie (w tym w Warszawie). Używa ich przede wszystkim CloudFront – usługa CDN (Content Delivery Network) od AWS. Jak to działa? Załóżmy, że Twoja aplikacja serwuje zdjęcia z bucketa S3 we Frankfurcie. Użytkownik z Tokio pobierałby te zdjęcia z Europy – wolno. Z CloudFront i Edge Locations zdjęcia są cache’owane na serwerze w Tokio, więc kolejni użytkownicy z Japonii dostają je błyskawicznie. Na początek nauki AWS nie musisz się martwić o Edge Locations – ale dobrze wiedzieć, że istnieją i do czego służą.

AWS a praca programisty

Pewnie się teraz zastanawiasz – „okej, ale ja jestem programistą, nie administratorem serwerów. Dlaczego miałbym się uczyć AWS?”.

Z reguły jest tak, że jeszcze kilka lat temu programista pisał kod, a ktoś inny (admin, DevOps) zajmował się infrastrukturą. Dzisiaj granica między tymi rolami mocno się zatarła. Coraz więcej firm oczekuje, że developer będzie rozumiał, jak jego aplikacja działa w chmurze. Nie chodzi o to, żebyś został specjalistą od infrastruktury – ale żebyś wiedział, jak wdrożyć swoją aplikację, jak ją skonfigurować i jak rozwiązywać problemy produkcyjne.

Z mojego doświadczenia wynika, że znajomość chmury realnie wpływa na to, jakie oferty pracy dostajesz i jakie stawki możesz negocjować. Programista Java ze znajomością AWS to inna liga niż programista Java bez tego doświadczenia. Na rynku pracy w 2026 roku wymaganie „znajomość AWS lub Azure” pojawia się w większości ofert dla seniorów i mid-developerów.

A jak to wygląda z perspektywy Java/Spring developera? Całkiem naturalnie się to łączy. Twoja aplikacja Spring Boot, którą do tej pory uruchamiałeś lokalnie albo na firmowym serwerze, w chmurze może działać na kilka sposobów:

Jako kontener Docker na ECS (Elastic Container Service) lub EKS (Elastic Kubernetes Service) – jeśli śledzisz moje wpisy o Dockerze, to wiesz jak zbudować obraz aplikacji. W AWS możesz ten obraz uruchomić w zarządzanym klastrze kontenerów.
Jako aplikacja na Elastic Beanstalk – wrzucasz JAR-a, a AWS konfiguruje serwer, load balancer i auto-scaling za Ciebie.
Jako funkcja Lambda – jeśli Twoja logika to pojedyncze endpointy, możesz je uruchomić jako funkcje serverless, które działają tylko wtedy, gdy ktoś je wywołuje (dla AWS Lambda zrobiłem wpis jak ją połączyć z AI).

Osobiście jestem teraz na etapie intensywnej nauki AWS – przygotowuję się do certyfikacji AWS Solutions Architect i AWS Developer. Zacząłem od tego, bo widzę, jak bardzo rynek idzie w stronę chmury, szczególnie w kontekście Javy i mikroserwisów. W pracy korzystam z Kubernetes i kontenerów, więc przejście na zarządzany Kubernetes w AWS (EKS) było dla mnie naturalnym krokiem.

Żeby było jasne – bez AWS jak najbardziej znajdziesz pracę. Ale z chmurą w CV otwierasz sobie drzwi do projektów, które bez tego doświadczenia po prostu byś nie dostał. Migracje systemów do chmury, budowanie nowych aplikacji cloud-native, praca w zespołach rozproszonych z infrastrukturą w AWS – to są projekty, na których możesz naprawdę dużo się nauczyć. A przy okazji – stawki w takich projektach są z reguły wyższe niż w tradycyjnych aplikacjach on-premise.

Usługi w AWS

No dobra, to teraz przejdźmy do tego, co AWS właściwie oferuje. Jak już wspomniałem, usług jest ponad 200. Ale spokojnie – w codziennej pracy jako programista będziesz korzystać z może 10-15 z nich. Reszta to usługi specjalistyczne, do których sięgniesz, gdy będziesz ich potrzebować.

Pogrupujmy najważniejsze usługi tematycznie.

Compute (obliczenia)

Od tego zaczyna się większość projektów w chmurze – potrzebujesz gdzieś uruchomić swoją aplikację. AWS daje Ci kilka opcji, od klasycznych wirtualnych maszyn po serverless, gdzie nie zarządzasz żadną infrastrukturą.

EC2 (Elastic Compute Cloud) – wirtualna maszyna w chmurze. Wybierasz typ instancji (ile CPU, RAM, dysku), system operacyjny i uruchamiasz na niej co chcesz. Załóżmy, że potrzebujesz serwera do swojej aplikacji Spring Boot – tworzysz instancję EC2, instalujesz na niej Javę i odpalasz JAR-a. Masz pełną kontrolę nad konfiguracją, ale sam odpowiadasz za aktualizacje systemu i bezpieczeństwo.
Lambda – usługa typu serverless. Piszesz funkcję (np. w Javie, Pythonie, Node.js), wrzucasz do AWS, a Lambda uruchamia ją automatycznie w odpowiedzi na zdarzenia. Nie zarządzasz żadnym serwerem – nie musisz myśleć o systemie operacyjnym, patchach czy skalowaniu. Płacisz za czas wykonania funkcji, nie za stałe utrzymanie maszyny. Przykład? Użytkownik wrzuca zdjęcie na S3, Lambda automatycznie się uruchamia i tworzy miniaturkę tego zdjęcia.
ECS / EKS – usługi do uruchamiania kontenerów Docker. ECS (Elastic Container Service) to natywne rozwiązanie AWS – definiujesz zadania (task definitions), a ECS zarządza tym, gdzie i jak Twoje kontenery działają. EKS (Elastic Kubernetes Service) to zarządzany Kubernetes – jeśli śledzisz moje wpisy o Dockerze i znasz Kubernetes, Jeśli już pracujesz z Kubernetes, EKS pozwoli Ci przenieść istniejące klastry do AWS bez zmiany narzędzi.

Storage (przechowywanie danych)

Każda aplikacja generuje dane – pliki użytkowników, logi, backupy, artefakty z buildów. W AWS masz do dyspozycji kilka typów storage’u, dopasowanych do różnych scenariuszy. Najważniejsze to zrozumieć różnicę między nimi, bo każdy ma inne zastosowanie i inny model cenowy.

S3 (Simple Storage Service) – obiektowy storage w chmurze, czyli miejsce do przechowywania plików dowolnego typu. Zdjęcia, logi aplikacji, backupy baz danych, statyczne strony internetowe – wszystko możesz trzymać w S3. Pliki organizujesz w „bucketach” (takich folderach najwyższego poziomu), a każdy plik może mieć rozmiar do 5 TB. Praktycznie każdy projekt, w którym pracowałem, korzystał z S3 w jakiś sposób – do przechowywania uploadów użytkowników, eksportów danych albo artefaktów z buildów.
EBS (Elastic Block Store) – dyski do instancji EC2. Działa jak zwykły dysk twardy podłączony do wirtualnej maszyny – instalujesz na nim system operacyjny, trzymasz dane aplikacji. Ważna różnica w porównaniu do S3: EBS jest „podłączony” do konkretnej instancji EC2, a S3 jest dostępny z dowolnego miejsca przez API.
EFS (Elastic File System) – współdzielony system plików, do którego mogą podłączyć się różne instancje EC2 jednocześnie. Przydaje się, gdy masz kilka serwerów, które muszą mieć dostęp do tych samych plików – np. współdzielone konfiguracje albo katalog z uploadami.

Bazy danych

Pewnie masz doświadczenie z bazami danych – PostgreSQL, MySQL albo chociaż H2 na potrzeby testów. W AWS nie musisz stawiać bazy na własnym serwerze i pilnować backupów ręcznie. Dostajesz zarządzane usługi bazodanowe, gdzie AWS bierze na siebie administrację, a Ty skupiasz się na pisaniu zapytań.

RDS (Relational Database Service) – zarządzane bazy relacyjne w chmurze. Wybierasz silnik bazy danych (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server), a AWS zajmuje się resztą – backupy, aktualizacje, replikacja, monitorowanie. Jako Java developer pewnie znasz PostgreSQL – w RDS możesz mieć zarządzanego Postgresa i nie martwić się o administrację. Załóżmy, że masz aplikację Spring Boot z bazą PostgreSQL, którą do tej pory stawiałeś na własnym serwerze. W RDS tworzysz instancję bazy w kilka kliknięć, podajesz connection string w application.yml i gotowe.
DynamoDB – baza NoSQL typu klucz-wartość i dokumentowa. Skaluje się automatycznie i obsługuje miliony zapytań na sekundę. Nie musisz planować pojemności ani martwić się o sharding – DynamoDB robi to za Ciebie. Sprawdza się w scenariuszach, gdzie masz prostą strukturę danych, ale wymagasz bardzo szybkiego czasu odpowiedzi – np. sesje użytkowników, koszyki w sklepie internetowym, cache konfiguracji.
ElastiCache – zarządzany Redis lub Memcached w chmurze. Jeśli w swoich aplikacjach Spring Boot korzystasz z cache’owania (a powinieneś :)), to ElastiCache pozwala postawić Redisa bez instalacji i konfiguracji od zera. Podłączasz się do niego tak samo jak do lokalnego Redisa – zmienia się tylko host w konfiguracji.

Networking (sieć)

Bez sieci Twoja aplikacja w chmurze byłaby odcięta od świata. Usługi sieciowe w AWS pozwalają Ci kontrolować, jak Twoje zasoby komunikują się ze sobą i z internetem. To temat, który na początku może wydawać się skomplikowany, ale sprowadza się do kilku podstawowych konceptów.

VPC (Virtual Private Cloud) – Twoja prywatna sieć w chmurze. To jak Twój własny, odizolowany pokój w dużym biurowcu – definiujesz podsieci (publiczne i prywatne), reguły firewalla (Security Groups), tablice routingu. Każda aplikacja produkcyjna powinna działać w VPC. W praktyce to wygląda tak: tworzysz VPC z podsiecią publiczną (dla load balancera) i prywatną (dla instancji EC2 i bazy RDS), dzięki czemu baza danych nie jest dostępna z internetu.
Route 53 – usługa DNS od AWS. Nazwa pochodzi od portu 53, na którym działa protokół DNS. Rejestrujesz domeny, konfigurujesz rekordy DNS (A, CNAME, MX), a Route 53 kieruje ruch do Twoich zasobów. Obsługuje też health checki i automatyczny failover – jeśli Twój serwer w jednym regionie padnie, Route 53 może przekierować ruch do serwera w innym regionie.
API Gateway – brama dla Twoich API. Stawiasz ją „przed” swoim backendem i API Gateway obsługuje autoryzację, rate limiting, transformacje requestów, wersjonowanie endpointów. Często używana razem z Lambda – definiujesz endpointy w API Gateway, a każdy endpoint wywołuje odpowiednią funkcję Lambda. Dzięki temu masz w pełni serverlessowe API bez zarządzania serwerami.

Monitoring i zarządzanie

Wrzuciłeś aplikację na EC2, baza działa na RDS – super. Ale skąd wiesz, że wszystko działa poprawnie? Monitoring i zarządzanie uprawnieniami to dwie rzeczy, które musisz ogarnąć od samego początku. Bez nich lecisz na ślepo.

CloudWatch – monitoring, logi i alarmy w jednym miejscu. Zbiera metryki z Twoich usług (CPU, pamięć, liczba requestów), pozwala ustawiać alarmy (np. „wyślij maila, gdy CPU na EC2 przekroczy 80% przez 5 minut”), agreguje logi z aplikacji. Możesz też tworzyć dashboardy z wykresami, żeby mieć szybki podgląd na stan swoich usług. Jako programista regularnie będziesz zaglądać do CloudWatch Logs, żeby sprawdzić logi swojej aplikacji na EC2 czy Lambda.
IAM (Identity and Access Management) – zarządzanie użytkownikami, rolami i uprawnieniami. Kto może czytać dane z S3? Która Lambda ma dostęp do bazy RDS? Jakie uprawnienia ma nowy developer w zespole? To wszystko konfigurujesz w IAM. Ta usługa dotyka wszystkiego w AWS – każda inna usługa sprawdza uprawnienia przez IAM. Dlatego powinieneś ją poznać jako pierwszą.

Kolejki i powiadomienia

Gdy Twoja aplikacja rośnie, prędzej czy później trafisz na sytuację, gdzie jeden serwis musi przekazać zadanie drugiemu bez czekania na wynik. Kolejki wiadomości i systemy powiadomień rozwiązują ten problem – pozwalają na asynchroniczną komunikację między serwisami.

SQS (Simple Queue Service) – kolejka wiadomości w chmurze. Jeśli czytałeś mój wpis o RabbitMQ, to SQS to odpowiednik kolejki wiadomości, ale w pełni zarządzany przez AWS. Nie musisz stawiać własnego brokera, konfigurować klastra ani martwić się o dostępność. Serwis A wysyła wiadomość do kolejki, serwis B ją odbiera i przetwarza – klasyczny wzorzec producer-consumer. SQS obsługuje dwa typy kolejek: standardową (najszybsza, ale kolejność wiadomości nie jest gwarantowana) i FIFO (gwarantowana kolejność, ale wolniejsza).
SNS (Simple Notification Service) – usługa do powiadomień w modelu publish-subscribe. Tworzysz temat (topic), subskrybujesz odbiorców, a SNS rozsyła każdą wiadomość do wszystkich subskrybentów. Odbiorcy mogą być różni – maile, SMS-y, endpointy HTTP, kolejki SQS, funkcje Lambda. Przykład? Twoja aplikacja wykrywa podejrzane logowanie – wysyła wiadomość do tematu SNS, a ten powiadamia zespół bezpieczeństwa mailem i jednocześnie odpala Lambda, która blokuje konto.

CI/CD i deployment

Masz kod, masz testy – teraz trzeba to wdrożyć. AWS oferuje własny zestaw narzędzi do ciągłej integracji i wdrażania, dzięki czemu cały pipeline od commita po produkcję możesz zbudować w ramach jednego ekosystemu. Jeśli znasz Jenkinsa albo GitHub Actions, poniższe usługi będą Ci koncepcyjnie znajome.

CodeCommit – repozytorium Git w AWS. Odpowiednik GitHuba czy GitLaba, ale w ekosystemie AWS. Osobiście wolę GitHuba, ale w niektórych firmach polityka bezpieczeństwa wymaga trzymania kodu w ramach AWS. Jedna uwaga – CodeCommit przeszedł krótki okres deprecjacji w 2024 roku, ale po fali krytyki ze strony użytkowników AWS przywrócił go do pełnej dostępności w listopadzie 2025. Planują nawet wsparcie dla Git LFS i ekspansję na nowe regiony.
CodeBuild – usługa do budowania projektów. Definiujesz plik buildspec.yml, w którym opisujesz kroki builda – pobranie zależności, kompilacja, uruchomienie testów, wygenerowanie artefaktu. Dla projektu Java to np. mvn clean package. CodeBuild uruchamia build w izolowanym kontenerze i zwraca wynik. Jak Jenkins, ale nie musisz go instalować ani utrzymywać.
CodeDeploy – automatyzacja wdrożeń na EC2, ECS czy Lambda. Obsługuje różne strategie deploymentu – in-place (zamiana na miejscu), blue/green (dwie wersje, przełączenie ruchu), canary (stopniowe przenoszenie ruchu). Razem z CodeBuild i CodeCommit tworzą pipeline CI/CD w AWS, znany jako CodePipeline.

Pierwsze kroki z AWS

Okej, wiemy już czym jest AWS i jakie usługi oferuje. Pora na praktykę.

Zakładanie konta

Żeby zacząć, potrzebujesz konta AWS. Wchodzisz na aws.amazon.com, klikasz „Create an AWS Account” i podajesz podstawowe dane – email, hasło, dane karty płatniczej. Tak, karta jest wymagana, ale spokojnie – za chwilę powiem Ci jak się zabezpieczyć przed niechcianymi kosztami.

Po utworzeniu konta logujesz się jako root user – to użytkownik z pełnymi uprawnieniami do absolutnie wszystkiego na Twoim koncie AWS. Może tworzyć i usuwać usługi, zmieniać dane rozliczeniowe, a nawet zamknąć całe konto. Dlatego nie używaj konta root do codziennej pracy. Zaloguj się na niego raz, zabezpiecz i odłóż na bok.

Co zrobić zaraz po rejestracji? Trzy rzeczy:

Włącz MFA (Multi-Factor Authentication) na koncie root – najlepiej przez aplikację typu Google Authenticator lub Authy. Nawet jeśli ktoś pozna Twoje hasło, bez kodu z telefonu nie zaloguje się na konto. To absolutna podstawa bezpieczeństwa w AWS.
Utwórz osobnego użytkownika IAM z uprawnieniami administratora (polityka AdministratorAccess) i od teraz loguj się tylko na niego. Ma te same możliwości zarządzania usługami, ale nie może np. zamknąć konta ani zmienić danych płatniczych.
Konto root zostawiasz wyłącznie na sytuacje, których nie da się zrobić inaczej – zmiana danych rozliczeniowych, zamknięcie konta, przywracanie dostępu do IAM.

Brzmi jak dużo zachodu? Może, ale zaufaj mi – jedna wyciekła konfiguracja z uprawnieniami roota i ktoś może Ci postawić farmę kryptowalut za kilka tysięcy dolarów. To nie jest scenariusz teoretyczny, takie rzeczy się zdarzają.

AWS Free Tier

AWS pozwala Ci uczyć się i testować usługi bez wydawania pieniędzy – i to nie jest żadna wersja demo z obciętymi funkcjami. Dostajesz dostęp do prawdziwych usług produkcyjnych, tylko z limitami na zużycie. Dla kogoś, kto dopiero zaczyna, to najlepsza opcja.

Od lipca 2025 AWS zmienił model darmowego planu. Nowe konta otrzymują AWS Free Plan z kredytem do 200 USD – 100 USD dostajesz od razu przy rejestracji, a kolejne 100 USD możesz odblokować korzystając z wybranych usług (EC2, RDS, Lambda, Bedrock, Budgets). Free Plan działa przez 6 miesięcy od założenia konta lub do wyczerpania kredytów – w zależności co nastąpi wcześniej.

Co ważne – przy rejestracji wybierasz typ konta: Free Plan (darmowy, bez opłat do wyczerpania kredytów) albo Paid Plan (płatny, z pełnym dostępem do wszystkich usług). Jeśli dopiero zaczynasz naukę, wybierz Free Plan – zabezpiecza Cię przed niechcianymi kosztami, bo po wyczerpaniu kredytów usługi po prostu się zatrzymują zamiast generować rachunki.

W ramach Free Plan masz dostęp do większości popularnych usług z takimi limitami:

EC2 – 750 godzin miesięcznie instancji t2.micro (albo t3.micro w niektórych regionach). To wystarczy, żeby mieć jedną małą maszynę uruchomioną 24/7 przez cały miesiąc.
S3 – 5 GB przestrzeni dyskowej.
RDS – 750 godzin miesięcznie instancji db.t2.micro albo db.t3.micro. Wystarczy na jedną bazę danych do nauki.
Lambda – 1 milion wywołań i 400 000 GB-sekund czasu obliczeń miesięcznie. To naprawdę dużo – darmowy limit Lambda jest bezterminowy, nawet po zakończeniu Free Plan.
DynamoDB – 25 GB przestrzeni i 25 jednostek odczytu/zapisu. Również bezterminowo.

Jeśli Twoje konto powstało przed 15 lipca 2025, działasz w starszym modelu Free Tier z 12-miesięcznym darmowym okresem na usługi typu EC2, S3 czy RDS. Nowe konta mają 6-miesięczne okno z kredytami. Po zakończeniu Free Plan możesz przejść na Paid Plan i nadal korzystać z usług bezterminowo darmowych (Lambda, DynamoDB) w ramach ich limitów.

A co po 6 miesiącach? Jeśli jesteś na Free Plan – usługi się zatrzymują i nic nie płacisz. Możesz wtedy przejść na Paid Plan i zacząć płacić za to, czego używasz. Jeśli od razu wybrałeś Paid Plan – po wyczerpaniu kredytów AWS zaczyna naliczać opłaty według standardowego cennika. Dlatego tak ważne jest ustawienie budżetów i alertów, o czym powiem za chwilę.

Na co uważać?

Nawet na Free Plan są rzeczy, które mogą Cię zaskoczyć:

Publiczne adresy IPv4 – od lutego 2024 AWS nalicza opłatę za każdy publiczny adres IPv4: ~3.60 USD miesięcznie. Dotyczy to też instancji EC2 na Free Plan. Jeśli nie potrzebujesz publicznego IP – nie przypisuj go.
Zapomniane zasoby – to najczęstsza pułapka. Tworzysz instancję EC2 do testów, zapominasz o niej i po miesiącu dostajesz rachunek. Wyrabiaj sobie nawyk: po skończonej nauce wejdź w konsolę i sprawdź, czy nie masz uruchomionych usług, za które płacisz.
Regiony – Free Tier działa per region. Jeśli postawisz EC2 w us-east-1 i drugie w eu-west-1, to zużywasz dwa razy więcej godzin. Na początek trzymaj się jednego regionu.

Pełną listę usług objętych Free Tier znajdziesz na stronie aws.amazon.com/free – polecam ją przejrzeć, bo co jakiś czas AWS dodaje nowe usługi do darmowego planu.

Konsola AWS i AWS CLI

AWS daje Ci dwa główne sposoby na zarządzanie usługami – konsolę webową i wiersz poleceń. Wystarczy konsola, ale dobrze wiedzieć o obu.

Po zalogowaniu trafiasz do AWS Management Console – to webowy panel, z którego zarządzasz wszystkimi usługami. Na początku może wyglądać przytłaczająco, bo widzisz listę 200+ usług. Ale na pasku wyszukiwania wpisujesz np. „EC2” albo „S3” i trafiasz bezpośrednio do danej usługi. Mała rada – kliknij gwiazdkę przy usługach, których używasz najczęściej. Przypną się do górnego paska i nie będziesz ich szukać za każdym razem.

Oprócz konsoli webowej masz do dyspozycji AWS CLI – narzędzie wiersza poleceń. Instalujesz je na swoim komputerze, konfigurujesz klucze dostępu i możesz zarządzać zasobami z terminala. Na początku nauki konsola webowa w zupełności wystarczy, ale z czasem CLI staje się wygodniejsze, szczególnie do powtarzalnych zadań.

Jeśli nie chcesz instalować CLI lokalnie, możesz skorzystać z AWS CloudShell – to terminal dostępny bezpośrednio w przeglądarce, w konsoli AWS. Ma preinstalowane CLI, jest już skonfigurowany z Twoimi uprawnieniami i nie wymaga żadnego setupu. Klikasz ikonkę terminala w górnym pasku konsoli i gotowe.

Żeby zainstalować AWS CLI, wystarczy pobrać instalator ze strony AWS:

# Na Ubuntu/Debianie
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# Sprawdzenie wersji
aws --version

Albo wejść na oficjalną dokumentacje AWS i pobrać odpowiednią wersję.

Po instalacji konfigurujesz CLI kluczami dostępu:

aws configure

Podajesz Access Key ID, Secret Access Key (tworzysz je w konsoli IAM), domyślny region (np. eu-central-1) i format wyjścia (json).

Pierwszy praktyczny krok – bucket S3

Masz już konto, masz konsolę – pora coś w tej chmurze zrobić. Polecam zacząć od stworzenia bucketa S3. Dlaczego akurat S3? Bo to najprostsza usługa w AWS, nie wymaga konfiguracji sieci ani serwerów, a efekt widzisz od razu.

W konsoli webowej: wchodzisz do S3 → „Create bucket” → podajesz unikalną nazwę (musi być unikalna globalnie w całym AWS, więc „test” raczej nie przejdzie :)) → wybierasz region → zostawiasz domyślne ustawienia → „Create bucket”. Gotowe.

Albo z CLI – jedna komenda:

aws s3 mb s3://moj-pierwszy-bucket-uprogramisty --region eu-central-1

Teraz możesz wrzucić plik:

aws s3 cp moj-plik.txt s3://moj-pierwszy-bucket-uprogramisty/

I wylistować zawartość:

aws s3 ls s3://moj-pierwszy-bucket-uprogramisty/

To wszystko. Twój plik jest teraz w chmurze – dostępny przez API z dowolnego miejsca na świecie. W kilka minut masz działający storage, bez stawiania serwera FTP, konfiguracji dysków czy backupów.

S3 to też bezpieczna usługa do nauki – w ramach Free Tier masz 5 GB za darmo, a przypadkowe koszty są minimalne (centy za tysiące requestów). Dużo bezpieczniejsze niż zabawa z EC2, gdzie zapomniana instancja może generować koszty.

Koszty i billing

Pewnie zastanawiasz się ile to wszystko kosztuje. I pewnie słyszałeś historie o tym, jak ktoś zostawił uruchomioną instancję EC2 na weekend i dostał rachunek na kilkaset dolarów. Takie sytuacje się zdarzają, ale da się ich łatwo uniknąć, jeśli od początku wiesz jak działa billing w AWS.

Model pay-as-you-go

Jeśli kiedyś kupowałeś VPS-a na DigitalOcean czy OVH, to pewnie jesteś przyzwyczajony do stałej kwoty miesięcznej – np. 5 USD za serwer i tyle. W AWS to działa inaczej. Płacisz w modelu pay-as-you-go, czyli za to, co faktycznie zużywasz. Każda godzina pracy instancji EC2, każdy GB danych w S3, każde zapytanie do bazy – to osobna pozycja na rachunku. Z jednej strony to elastyczne – nie płacisz za zasoby, których nie używasz. Z drugiej – musisz pilnować, co masz uruchomione.

Ceny zależą od regionu, typu instancji i usługi. Dla przykładu – instancja t3.micro w regionie eu-central-1 kosztuje około 0.0104 USD za godzinę. Brzmi niewiele, ale pomnóż to razy 730 godzin w miesiącu i wychodzi ~7.60 USD. A teraz wyobraź sobie, że przez pomyłkę uruchomiłeś instancję m5.xlarge (0.192 USD/h) i zapomniałeś ją wyłączyć – to ~140 USD miesięcznie. Ceny różnią się też między regionami – us-east-1 (N. Virginia) jest zazwyczaj najtańszy. Na potrzeby nauki możesz z niego korzystać, jeśli nie zależy Ci na niskim opóźnieniu do Europy.

Pay-as-you-go to nie jedyny model cenowy w AWS. Gdy Twoje projekty urosną, możesz sięgnąć po:

Reserved Instances / Savings Plans – zobowiązujesz się na 1 lub 3 lata, a w zamian dostajesz rabat nawet do 72% w porównaniu z ceną on-demand. Ma sens, gdy wiesz że będziesz potrzebować instancji przez dłuższy czas.
Spot Instances – instancje EC2 z nieużywanej puli AWS, dostępne z rabatem do 90%. Haczyk? AWS może je zabrać z 2-minutowym wyprzedzeniem, gdy ktoś inny zapłaci pełną cenę. Sprawdzają się do zadań, które można przerwać i wznowić – np. przetwarzanie wsadowe, testy obciążeniowe.

Nie musisz się tym przejmować – pay-as-you-go w połączeniu z Free Plan w zupełności wystarczy. Ale dobrze wiedzieć, że inne opcje też istnieją.

Zanim cokolwiek uruchomisz, polecam sprawdzić koszty w AWS Pricing Calculator – wpisujesz jakie usługi planujesz użyć, w jakim regionie i na jak długo, a kalkulator szacuje miesięczny koszt. Dzięki temu nie będziesz zaskoczony rachunkiem.

Jak się zabezpieczyć – AWS Budgets

Kalkulator kalkulatorem, ale najlepsza ochrona przed niespodziewanym rachunkiem to ustawienie budżetu i alertów kosztowych. Zrób to zaraz po MFA i użytkowniku IAM – najlepiej tego samego dnia, co zakładanie konta.

Wchodzisz do AWS Budgets (znajdziesz w sekcji Billing and Cost Management), wybierasz „Cost budget” i ustawiasz limit miesięczny. Na początek wystarczy kilka-kilkanaście dolarów. Sam mam ustawiony budżet na 12 USD – poniżej widzisz jak to wygląda na moim koncie:

Widok na listę ustawionych budżetów na koncie w AWS

Widać budżet ustawiony na 12 USD, status „OK” przy progach i „Healthy” przy health status – czyli koszty są pod kontrolą. Po kliknięciu w nazwę budżetu wchodzisz w szczegóły, gdzie konfigurujesz alerty:

AWS domyślnie tworzy 3 alerty: powiadomienie gdy rzeczywiste koszty przekroczą 85% budżetu, gdy przekroczą 100% i gdy prognozowane koszty na koniec miesiąca przekroczą 100%. Nie musisz nic konfigurować ręcznie – te progi ustawiają się automatycznie przy tworzeniu budżetu. Oczywiście możesz je zmienić albo dodać własne, ale na start domyślne w zupełności wystarczą.

Od czego zacząć naukę?

Załóżmy, że masz już konto, ustawiłeś budżet i chcesz zacząć naukę na poważnie. Jaka jest najlepsza ścieżka?

Które usługi poznać w pierwszej kolejności?

Przy ponad 200 usługach łatwo się pogubić, więc na start wybrałbym naukę w takiej kolejności:

IAM → S3 → EC2 → RDS → Elastic Beanstalk → Lambda → CloudWatch.

Dlaczego akurat te?

IAM – bez tego nie ruszysz dalej. Każda usługa w AWS sprawdza uprawnienia przez IAM, więc musisz rozumieć jak działają użytkownicy, role i polityki.
S3 – najprostsza usługa do nauki, a jednocześnie jedna z najczęściej używanych. Szybko zobaczysz efekt swojej pracy.
EC2 – tu uruchomisz swoją pierwszą aplikację w chmurze. Po drodze nauczysz się Security Groups, kluczy SSH i podstaw sieciowych.
RDS – zarządzana baza danych. Jako Java developer pewnie znasz PostgreSQL lub MySQL – w RDS podłączysz je do swojej aplikacji na EC2.
Elastic Beanstalk – najszybszy sposób na wdrożenie aplikacji Spring Boot w AWS. Wrzucasz JAR-a, a Beanstalk sam konfiguruje EC2, load balancer i auto-scaling. Dobrze go poznać po EC2, żeby zobaczyć różnicę między ręcznym a zarządzanym deploymentem.
Lambda – serverless to zupełnie inne podejście niż tradycyjne serwery. Przyda się, żeby wiedzieć kiedy wybrać Lambda, a kiedy EC2.
CloudWatch – monitoring i logi. Bez tego nie zobaczysz co się dzieje z Twoją aplikacją w chmurze.

Te usługi dają Ci solidne podstawy, na których możesz budować dalej. Resztę dodasz stopniowo, w zależności od potrzeb projektu.

Darmowe materiały do nauki

Dobra wiadomość – nie musisz wydawać pieniędzy na kursy, żeby nauczyć się AWS. Sam korzystam z darmowych zasobów i w zupełności wystarczają na solidne podstawy. Oto co polecam:

AWS Skill Builder (skillbuilder.aws) – oficjalna platforma szkoleniowa AWS. Mnóstwo darmowych kursów, w tym oficjalne materiały przygotowawcze do certyfikacji. Polecam kurs „AWS Cloud Practitioner Essentials”.
AWS Workshop Studio (workshops.aws) – oficjalne warsztaty hands-on od AWS. Każdy warsztat to gotowy scenariusz krok po kroku – stawiasz infrastrukturę, konfigurujesz usługi i widzisz efekt. Dużo lepsze niż suche wykłady, bo od razu pracujesz na żywym środowisku.
AWS Documentation (docs.aws.amazon.com) – dokumentacja AWS jest naprawdę dobra. Każda usługa ma sekcję „Getting Started”, która prowadzi Cię krok po kroku.
YouTube – na YouTube znajdziesz mnóstwo darmowych materiałów o AWS. Z kanałów, które polecam, to Be A Better Dev – krótkie, konkretne filmy o poszczególnych usługach AWS, bez lania wody. Dobry format na szybkie zrozumienie tematu przed właściwą nauką z dokumentacji.
AWS Free Tier + hands-on – z samych kursów wideo niewiele wyniesiesz, jeśli nie będziesz jednocześnie klikać po konsoli AWS. Postaw sobie instancję EC2, stwórz bucket S3, podłącz bazę RDS do swojej aplikacji. Nawet jeśli po drodze coś nie zadziała, to właśnie wtedy uczysz się najwięcej. Darmowy plan daje Ci dość zasobów, żeby ćwiczyć przez kilka miesięcy bez wydawania pieniądza.

Praktyka: własne projekty

Najlepsza rada, jaką mogę Ci dać – weź swoją istniejącą aplikację (np. projekt Spring Boot) i spróbuj ją wdrożyć w AWS. Zaczynasz od prostego scenariusza:

Budujesz JAR-a swojej aplikacji
Tworzysz instancję EC2 (t2.micro, Free Tier)
Instalujesz na niej Javę
Wrzucasz JAR-a i uruchamiasz aplikację
Konfigurujesz Security Group, żeby wpuścić ruch na port 8080

To prosty scenariusz, ale po drodze nauczysz się mnóstwa rzeczy – SSH, Security Groups, konfiguracja sieci, podstawy IAM.

Gdy już ogarniesz ręczny deploy na EC2, spróbuj tego samego z Elastic Beanstalk:

Tworzysz nowe środowisko Beanstalk (platforma: Java)
Wrzucasz tego samego JAR-a przez konsolę AWS albo CLI (eb deploy)
Beanstalk sam tworzy EC2, konfiguruje load balancer, ustawia auto-scaling i health checki
Dostajesz gotowy URL, pod którym działa Twoja aplikacja

Różnica? Na EC2 robiłeś wszystko ręcznie – tutaj Beanstalk zrobił to za Ciebie w kilka minut. Zobaczysz wtedy na własnej skórze, czym różni się podejście „robię wszystko sam” od „AWS zarządza infrastrukturą”. A potem możesz iść dalej: dodać bazę RDS zamiast H2, przenieść statyczne pliki na S3, spakować aplikację w Dockera i wrzucić na ECS.

Każdy taki krok to nowa usługa AWS, którą poznajesz w praktyce, a nie z wykładu.

Planuję przygotować osobny wpis, w którym krok po kroku przejdziemy przez wdrożenie aplikacji Spring Boot z prostym frontendem we Vue na AWS. Od zera do działającej aplikacji w chmurze – więc jeśli ten scenariusz Cię interesuje, śledź blog.

Certyfikacje AWS

AWS ma rozbudowaną ścieżkę certyfikacyjną i nawet jeśli nie planujesz zdawać egzaminu, to materiały przygotowawcze do certyfikacji są świetnym sposobem na systematyczną naukę.

Proponuję zacząć od:

AWS Cloud Practitioner (CLF-C02) – certyfikacja wejściowa, ogólna wiedza o chmurze i usługach AWS. Dobra na rozpoznanie terenu i potwierdzenie, że rozumiesz podstawy. Egzamin ma 65 pytań, trwa 90 minut, zdawalność od 700/1000 punktów.
AWS Solutions Architect Associate (SAA-C03) – bardziej techniczna, skupia się na projektowaniu rozwiązań w chmurze. To certyfikacja, którą rynek rozpoznaje i ceni. Jeśli masz już doświadczenie jako developer, możesz rozważyć pominięcie Cloud Practitioner i zaczęcie od razu od tej.
AWS Developer Associate (DVA-C02) – zorientowana na programistów. Pokrywa tematy typu SDK, Lambda, API Gateway, DynamoDB, CI/CD w AWS. Dobra jeśli chcesz skupić się na tworzeniu aplikacji w chmurze, a nie na architekturze infrastruktury.

Sam przygotowuję się do Solutions Architect i Developer Associate. Wybrałbym Solutions Architect – daje szeroką wiedzę o usługach AWS i ich integracji.

Podsumowanie

Wiem, że po przeczytaniu tego wpisu AWS może nadal wydawać się przytłaczający. 200+ usług, regiony, billing – dużo tego. Ale naprawdę nie musisz ogarniać wszystkiego na raz. Załóż konto, ustaw budżet na 5 dolarów, stwórz bucket S3 i wrzuć tam jakiś plik. To zajmie Ci 15 minut, a już będziesz miał za sobą pierwszy kontakt z AWS.

Sam jestem w trakcie tej nauki i przygotowuję się do certyfikacji, więc na blogu pojawią się kolejne wpisy o konkretnych usługach AWS – bardziej praktyczne, z kodem i konfiguracją krok po kroku.

A Ty – pracujesz już z AWS w projekcie? A może dopiero rozważasz naukę? Napisz w komentarzu, ciekawi mnie jak wyglądają Twoje doświadczenia z chmurą 🙂