Halloween to dobry moment na straszne historie. Tylko że ja nie mam do opowiedzenia nic o duchach. Mam za to coś dużo bardziej strasznego: rachunki z AWS 👻.
Pominąłem historie o kluczach wrzuconych na GitHuba i koparkach kryptowalut. To temat dla działu bezpieczeństwa. Mnie bardziej przerażają te, w których nikt niczego nie ukradł. Konto było bezpieczne, kod działał, a rachunek i tak wystrzelił w kosmos.
Bo AWS rozlicza wykonaną pracę, a nie jej wartość dla Twojego biznesu. Jeśli coś wykona tę samą pracę milion razy, zapłacisz milion razy więcej.
Zebrałem dziesięć takich historii, w tym też własne. Razem to około 258 tys. USD przed zwrotami (z czego jedna to wyjątkowo podstępna historia). Tam, gdzie źródło podaje wolumen, przeliczyłem kwotę z cennika AWS. Czasem zgadza się co do centa. Przy każdej historii sprawdziłem też, czy potwór nadal żyje, bo AWS część pułapek w międzyczasie zamknął. Wszystkie ceny podaję dla us-east-1. W regionach europejskich bywają trochę wyższe.
Na końcu znajdziesz listę kontrolną na 15 minut. Możesz ją przejść na swoim koncie jeszcze dziś wieczorem. 🎃
Obcy pukają do drzwi
Pierwsze trzy historie łączy jedno: rachunek wygenerował ktoś, kogo właściciel konta nie znał i nie zapraszał.
1. Nawiedzony dom: pusty bucket za 1 300 USD
Zacznę od klasyka. I do tego z polskim akcentem.
W kwietniu 2024 roku Maciej Pocwierz utworzył prywatny, pusty bucket S3 w regionie eu-west-1. Potrzebował go do prostego proof of concept. Dwa dni później zajrzał do billingu, żeby upewnić się, że mieści się w Free Tier. Zobaczył ponad 1 300 USD.
Nazwa jego bucketu była identyczna z wartością domyślną w konfiguracji popularnego narzędzia open source do backupów. Wszystkie instalacje, których nikt nie przekonfigurował, próbowały wrzucać swoje kopie zapasowe do jego bucketu. Prawie 100 milionów żądań PUT w jeden dzień. Każde odrzucone z błędem 403 Access Denied.
Z perspektywy uprawnień wszystko działało prawidłowo: nikt obcy nie zapisał ani jednego pliku. Z perspektywy rachunku już nie, bo za każde odrzucone żądanie zapłacił właściciel bucketu.
AWS najpierw odpowiedział, że to „oczekiwane zachowanie”. Rachunek ostatecznie anulowano, z zaznaczeniem, że to wyjątek. Historia obiegła internet, a Jeff Barr publicznie przyznał, że trzeba to naprawić.
Przeliczyłem: 100 mln PUT × 0,005 USD za 1 000 żądań = 500 USD za dzień. Kwota 1 300 USD to więc około dwóch i pół dnia przy tym tempie. Do tego żądania bez wskazanego regionu trafiały najpierw do us-east-1 i były przekierowywane, co dokładało koszty. Rząd wielkości się zgadza.
Czy potwór żyje? Nie. To jedyny potwór w tym zestawieniu, którego AWS naprawdę zabił. Zmianę ogłoszono 13 maja 2024, a w sierpniu 2024 objęła wszystkie API i regiony S3. Uważaj jednak na szczegół: darmowe są tylko te błędy 403, które pochodzą spoza Twojego konta lub AWS Organization. Jeśli to Twoja własna aplikacja wali w bucket bez uprawnień, nadal płacisz.
Egzorcyzm: unikalne nazwy bucketów (z losowym sufiksem), a nie backup, data czy test.
2. Mumia: plik, który obudził się po latach
W lipcu 2020 roku Chris Short otworzył maila z rachunkiem. Zwykle płacił około 23 USD miesięcznie. Za czerwiec: 2 657,68 USD.
W publicznym buckecie S3 leżał obraz maszyny wirtualnej o rozmiarze 13,7 GB. Przed bucketem stał Cloudflare, więc Chris był spokojny, że CDN wszystko zbuforuje. Ale Cloudflare w planach Free, Pro i Business nie przechowuje w cache plików większych niż 512 MB. Każde pobranie szło więc prosto do S3, a S3 liczył transfer do internetu. Ponad 30,6 TB w dwie doby: 1 011,59 USD 23 czerwca i 1 639,07 USD 24 czerwca.
Kto pobierał ten plik? Do dziś nie wiadomo. Corey Quinn skomentował to krótko: Chris nie zrobił nic złego. AWS zwrócił wszystko oprócz około 40 USD.
Przeliczyłem: pierwsze 10 TB × 0,09 USD/GB + kolejne 20,6 TB × 0,085 USD/GB ≈ 2 650 USD. Różnica z rachunkiem to mniej niż 1%.
To samo w wersji 2026: w marcu użytkownik r/aws opisał, jak po promocji jego strony na jednym z subredditów ktoś przez trzy dni bez przerwy pobierał pliki z jego bucketu. Około 160 TB i około 15 500 USD. AWS najpierw tylko częściowo obniżył rachunek, a autor nadal nie był w stanie zapłacić reszty. Pozostałą kwotę AWS umorzył dopiero po sześciu tygodniach i po tym, jak autor, za radą jednego z komentujących, napisał do Jeffa Barra. Sam transfer 160 TB to według cennika około 12 tys. USD, więc rząd wielkości się zgadza. Zastrzeżenie: to relacja z anonimowego konta na Reddicie, bez rozbicia reszty kwoty.
Czy potwór żyje? Tak. Zmiana z 2024 roku tu nie pomaga, bo pobranie pliku z bucketu, do którego ktoś ma dostęp, to poprawne, płatne żądanie.
Egzorcyzm: nie wystawiaj S3 bezpośrednio do internetu. Pliki serwuj przez CloudFront z Origin Access Control i sprawdź, czy Twój CDN naprawdę buforuje duże obiekty.
3. Chmara nietoperzy: 207 milionów żądań w trzy godziny
Web Dev Cody, youtuber znany w świecie JavaScriptu, w marcu 2024 roku obudził się z mailem z AWS Budgets. Ustawił alert na około 10 USD. Rachunek wynosił 269 USD, z czego prawie 260 USD to CloudFront.
Jego aplikacja Icon Generator przez mniej więcej trzy godziny, gdy Cody spał, przyjęła ponad 207 milionów żądań. Na samą stronę /community trafiło ich około 25 milionów i te odpowiedzi pochodziły z cache. Aplikacja nie musiała nic liczyć, a mimo to każde żądanie HTTPS było płatne. Cody podejrzewał atak DoS albo skrypt. Ruch ustał sam. Rachunek został, Cody nie wspomina o żadnym zwrocie.
Przeliczyłem: na rachunku z jego filmu widać pozycję 207 146 239 żądań HTTPS w regionie US. × 0,01 USD za 10 000 żądań = 207,15 USD. Dokładnie tyle stoi przy tej pozycji. Co do centa. Do tego 31,37 USD za transfer (to dwie pozycje z pokazanego fragmentu rachunku, nie pełne rozbicie).
Alert zadziałał jako powiadomienie, a nie jako hamulec. Próg 10 USD, rachunek 269 USD, a ruch ustał, zanim Cody wstał. Dzięki alertowi dowiedział się jednak tego samego dnia. Dodał regułę rate limit w AWS WAF i zamknął temat.
Czy potwór żyje? Osłabiony. Od 18 listopada 2025 CloudFront ma plany ze stałą opłatą (od darmowego Free po Premium za 1 000 USD miesięcznie) bez opłat za przekroczenie limitu. Zablokowane ataki DDoS i żądania odrzucone przez WAF nie liczą się do limitu. Ale to opcja, a nie domyślne ustawienie. Plan obejmuje konkretną dystrybucję, a nie cały backend aplikacji. Istniejąca dystrybucja nie dostaje go automatycznie. W klasycznym modelu pay-as-you-go potwór żyje dalej.
Egzorcyzm: reguła rate limit w AWS WAF albo plan flat-rate dla projektów, które nie zarabiają na ruchu.
Pętle, które same się karmią
4. Poltergeist: funkcja, która wywołuje samą siebie
Czerwiec 2022. Ruslan Gainutdinov uruchomił stronę na Next.js z Lambda@Edge. Przez pomyłkę funkcja zaczęła wywoływać własną dystrybucję CloudFront. Według autora rekurencyjne żądania leciały w tempie około 17 tysięcy na sekundę, każde z 30-sekundowym timeoutem.
Rachunek: około 4 500 USD.
Najciekawszy jest jednak inny szczegół. Ruslan miał ustawiony alert budżetowy na 300 USD. Alert przyszedł, gdy naliczone opłaty wynosiły już 1 484 USD. Opłaty za CloudFront potrafią pojawić się na rachunku z opóźnieniem do 24 godzin. Autor policzył, że gdyby alert przyszedł na czas, zapłaciłby około 400 USD.
Przeliczyłem: zakładając 128 MB pamięci, jedno 30-sekundowe wywołanie to 3,75 GB-s × 0,00005001 USD ≈ 0,00019 USD. 4 500 USD to więc około 24 mln wywołań. Przy stałym tempie 17 tys. na sekundę to niecałe pół godziny. Tempo było pewnie szczytowe, ale rząd wielkości się zgadza.
Czy potwór żyje? W tej postaci tak. AWS wykrywa i przerywa pętle Lambdy (od lipca 2023 dla SQS i SNS, od października 2024 dla S3, a według obecnej dokumentacji także dla własnych szyn EventBridge). Pętla przez CloudFront i HTTP nie jest na tej liście.
Egzorcyzm: rate limit w WAF na dystrybucji, nagłówek albo licznik, który przerywa rekurencję, i alarm w CloudWatch na liczbę wywołań (metryki Lambda@Edge są w regionach, w których działały repliki). Liczba wywołań rośnie od razu. Dolary pojawiają się po kilku godzinach.
5. Mój własny poltergeist
Tę historię znam najlepiej, bo sam ją sobie napisałem.
Kiedy uczyłem się serverless i architektury sterowanej zdarzeniami, zbudowałem prosty przepływ. Plik trafia do S3, zdarzenie uruchamia Lambdę, Lambda startuje maszynę stanów w Step Functions, a ta przetwarza plik i zapisuje wynik z powrotem do S3.
Nic podejrzanego. Tyle że prefiks źródłowy i wynikowy ustawiłem w tym samym miejscu.
Zapis wyniku był więc początkiem kolejnego przetwarzania. Zbudowałem nieskończoną pętlę i przez jakiś czas zwyczajnie tego nie zauważyłem. Otrzeźwienie przyszło mailem: wykorzystałem Free Tier dla Step Functions. Po kilkudziesięciu minutach zabawy. 😅
Na szczęście wtedy przerwałem testy. I to ja zatrzymałem pętlę, a nie AWS. Na kontach z klasycznym Free Tier jego wyczerpanie niczego nie zatrzymuje, tylko zaczyna naliczać opłaty.
Skala: Free Tier dla Step Functions (Standard) to 4 000 przejść między stanami miesięcznie. Maszyna z kilkoma stanami zużyje to w kilkuset uruchomieniach, a pętla robi je w kilka minut. Potem każde 1 000 przejść kosztuje 0,025 USD.
Nie mam tu do pokazania sześciocyfrowego rachunku. Mam za to bardzo osobiste wspomnienie chwili, w której zrozumiałem, że automatyzacja powtarza mój błąd równie sprawnie jak potrzebną pracę.
Czy potwór żyje? Tak. Wykrywanie pętli w Lambdzie obejmuje S3, ale mój łańcuch szedł przez Step Functions. Nie zakładałbym, że detekcja go złapie.
Egzorcyzm: wejście i wyjście w osobnych bucketach albo przynajmniej w osobnych prefiksach z filtrem na zdarzeniu S3.
Dobre intencje, fatalny rachunek
W tej kategorii nikt nie zrobił nic głupiego. Wszyscy próbowali zrobić coś porządnie.
6. Wampir: NAT Gateway, który pije każdy gigabajt
Listopad 2025. Zespół Geocodio przygotował nowy proces, który synchronizował duże zbiory danych z EC2 do S3. Autorzy wiedzieli, że transfer między EC2 a S3 w tym samym regionie jest darmowy. I to prawda.
Kilka dni później przyszedł alert z AWS Cost Anomaly Detection. W jeden dzień przez NAT Gateway przeszło 20 167,32 GB.
Skąd więc rachunek? Z drogi, którą szły dane.
Instancje stały w podsieci prywatnej. Gdyby stały w publicznej, ruch w ogóle nie szedłby przez NAT. Podsieć prywatna nie ma bezpośredniej trasy na zewnątrz VPC. Jej tablica routingu kieruje cały ruch spoza VPC (0.0.0.0/0) do NAT Gateway. A S3 nie jest częścią Twojego VPC. To usługa z publicznym adresem. Bez S3 Gateway Endpoint każde żądanie do S3 przechodzi więc przez NAT Gateway, potem przez Internet Gateway, i dopiero trafia do publicznego endpointu S3.
Ważny szczegół: ten ruch nie trafia do publicznego internetu. Według FAQ Amazon VPC ruch między zasobami AWS zostaje w sieci AWS, nawet gdy idzie na publiczne adresy. Sam transfer z EC2 do S3 też nadal jest darmowy, dokładnie tak, jak mówi cennik.
Płacisz za coś innego. NAT Gateway liczy 0,045 USD za każdy przetworzony gigabajt, niezależnie od tego, dokąd ten gigabajt jedzie. Transfer był darmowy. Bramka, przez którą przechodził, już nie.
Instancja w podsieci publicznej (z publicznym IP i trasą do Internet Gateway) nie miałaby tego problemu, bo Internet Gateway nie liczy opłat za przetwarzanie danych. A Gateway Endpoint dodaje do tablicy routingu bezpośrednią trasę do S3, z pominięciem NAT. I nic nie kosztuje.
Przeliczyłem: 20 167,32 GB × 0,045 USD = 907,53 USD. Dokładnie tyle podaje Geocodio za ten jeden dzień. W styczniu 2026 dopisali, że AWS zwrócił całą kwotę.
Czy potwór żyje? Tak. Gateway Endpoint dla S3 i DynamoDB jest darmowy, ale nadal trzeba go dodać samemu.
Egzorcyzm: Gateway Endpoint dla S3 i DynamoDB w każdym VPC, najlepiej w szablonie IaC, żeby nikt o nim nie zapomniał.
7. Duch w logach: jeden print za 1 500 USD
4 sierpnia 2020 roku Michael Malis, CEO Freshpaint, dostał maila z alertem budżetowym. Był czwarty dzień miesiąca, a firma wydała już ponad 1 600 USD przy budżecie 1 000 USD na cały miesiąc.
Prawie 1 500 USD poszło na CloudWatch. Przyczyna: instrukcja print dodana podczas debugowania, która wypisywała każde zdarzenie przechodzące przez backend. Trafiła na produkcję i wygenerowała terabajty logów. Cały koszt to jedna pozycja: DataProcessing-Bytes, czyli przyjmowanie logów do CloudWatch po 0,50 USD za GB (we Frankfurcie 0,63 USD).
Przeliczyłem: 1 500 USD / 0,50 USD = 3 000 GB, czyli około 3 TB logów. Autor pisze o „wielu terabajtach”. Zgadza się.
Ważny szczegół: skrócenie retencji niczego by tu nie zmieniło. Płacisz za przyjęcie logów, a nie tylko za ich przechowywanie.
Czy potwór żyje? Tak. Klasa logów Infrequent Access jest tańsza, ale wolumen nadal kosztuje.
Egzorcyzm: poziom logowania ustawiany w konfiguracji, a nie w kodzie, i alarm na wolumen logów w każdej grupie.
8. Klątwa domyślnych ustawień: CloudTrail za 200 000 USD
To jest moim zdaniem najstraszniejsza historia w tym zestawieniu. Właśnie dlatego, że jest taka nudna.
Bharath Nadar opisał, jak podczas onboardingu narzędzia bezpieczeństwa ktoś zaakceptował jego domyślną konfigurację: CloudTrail Data Events dla wszystkich odczytów i zapisów we wszystkich bucketach S3, w całej organizacji AWS. Pełny audyt, compliance, bezpieczeństwo. Kto by się sprzeciwił?
Tylko że CloudTrail liczy 0,10 USD za każde 100 000 zdarzeń danych. A buckety, z których aplikacje czytają pliki miliardy razy w miesiącu, generują miliardy zdarzeń.
Koszt rósł powoli: od około 1 000 USD miesięcznie w 2024 do około 30 000 USD miesięcznie w 2025. Nie było nagłego skoku, więc nic nie zaalarmowało. Autor ujął to tak: „It didn’t spike. It crept.” Znalazł problem ręcznie, w Cost Explorerze, pod koniec 2025 roku. Łączna strata: około 200 000 USD. Naprawa zajęła 5 minut: zmiana logowania na same zapisy.
Przeliczyłem: autor podaje 8,98 mld zdarzeń S3 w grudniu, w samym us-east-1. × 0,10 USD za 100 000 = 8 980 USD w jednym miesiącu i jednym regionie. To spójne z kwotą rzędu 10 tys. USD miesięcznie, którą autor podaje dla jednego konta produkcyjnego.
Zastrzeżenie: to relacja jednej osoby, bez nazwy firmy. Mechanizm i liczby są jednak spójne.
Czy potwór żyje? Tak. Data Events dla odczytów S3 o dużym wolumenie zawsze będą drogie.
Egzorcyzm: zawężaj Data Events selektorami do konkretnych bucketów i do zapisów. I zanim włączysz nowe narzędzie, sprawdź, ile kosztują usługi, które ono włącza.
Potwory, których nie widać
9. Zombie: usunąłeś, a ono dalej chodzi
Październik 2024. Elliott King budował po godzinach projekt na AWS Amplify Gen 2 i dostał rachunek na około 1 125 USD.
Usunął środowisko sandbox poleceniem npx ampx sandbox delete. Tabele DynamoDB zniknęły. Domeny Amazon OpenSearch Service zostały i działały dalej. Każde kolejne utworzenie sandboxa dokładało następną domenę.
AWS skorygował rachunek jako jednorazowy gest dobrej woli. Pod jego wpisem na Hacker News zebrała się długa dyskusja, więc Elliott zdecydowanie nie był sam.
Czy potwór żyje? Nie wiem. Pod koniec października 2024 autor pisał, że problem nadal występuje. Nie znalazłem potwierdzenia, że został naprawiony. Wiem za to, że zombie żyje zawsze, gdy ufasz poleceniu delete bez sprawdzenia, co po nim zostało.
Egzorcyzm: po każdym usuwaniu środowiska sprawdź zasoby po tagach (Tag Editor w Resource Groups). I ustaw budżet na każdym koncie, także na tym „do zabawy”.
10. Niewidzialny potwór: 30 000 USD za Claude Opus
Ta historia jest najświeższa. Maj 2026, The Register. Jeden z czytelników tego serwisu używał modelu Claude Opus przez Amazon Bedrock. Miał skonfigurowane Cost Anomaly Detection. Pierwszym sygnałem, że coś jest nie tak, była faktura: 30 141,33 USD za kwiecień, plus około 675 USD innych opłat.
Dlaczego detekcja anomalii milczała? Modele firm trzecich w Bedrock są rozliczane przez AWS Marketplace. A Cost Anomaly Detection wtedy w ogóle nie widziało opłat z Marketplace. Rzecznik AWS potwierdził to wprost w odpowiedzi dla The Register.
Do tego kredyty AWS Activate po cichu pokryły pierwsze 8 026,54 USD. Gdy się skończyły, nikt nie dostał powiadomienia.
Czy potwór żyje? Osłabiony. 19 sierpnia 2026 AWS ogłosił, że Cost Anomaly Detection obejmuje teraz modele firm trzecich w Bedrock, bez dodatkowej konfiguracji. Dokumentacja nadal mówi jednak, że inne opłaty z Marketplace nie są monitorowane. Do nich potrzebujesz AWS Budgets.
Egzorcyzm: budżet na całkowity koszt konta (obejmuje Marketplace) i osobny alert na kończące się kredyty.
Dlaczego alarm nie zadzwonił
Kiedy ułożyłem te historie obok siebie, zobaczyłem coś ciekawszego niż same kwoty. Część osób nie miała żadnego alarmu. Ale tam, gdzie alarm był, zawodził na cztery sposoby.
1. Alarm był spóźniony. Ruslan miał alert na 300 USD, który przyszedł przy 1 484 USD. Cody miał alert na 10 USD i zapłacił 269 USD. To nie był błąd. Według dokumentacji AWS Budgets aktualizuje dane do trzech razy na dobę, zwykle co 8 do 12 godzin. AWS sam pisze, że wydatki mogą przekroczyć próg, zanim dostaniesz maila. Cost Anomaly Detection korzysta z danych Cost Explorera i potrzebuje do 24 godzin na wykrycie anomalii.
2. Alarm był ślepy. Czytelnik The Register miał Cost Anomaly Detection, ale ono nie widziało kosztów z Marketplace. Kredyty ukryły pierwsze 8 tys. USD. Alarm patrzył w inną stronę.
3. Potwór się skradał. CloudTrail rósł przez ponad rok. Detekcja anomalii uczy się wzorca wydatków i według dokumentacji uwzględnia naturalny wzrost. Stały, powolny wzrost łatwo więc uznać za normę. (Autor nie napisał, czy miał detekcję anomalii. Ale nawet gdyby miał, nie liczyłbym na nią.)
4. Potwór był nowy. Ten szczegół mało kto zna: dla nowo używanej usługi Cost Anomaly Detection potrzebuje 10 dni historii, zanim zacznie wykrywać anomalie. Usługa, którą włączyłeś wczoraj i która dziś wymknęła się spod kontroli, jest dla niego niewidoczna.
Alerty, które zadziałały (Cody, Geocodio, Freshpaint), dały jedno: wiedzę po godzinach lub dniach, a nie na koniec miesiąca. Żaden niczego nie zatrzymał. Alert to czujnik dymu, a nie gaśnica.
A czy AWS wreszcie dał nam hamulec?
Częściowo. Przez lata odpowiedź brzmiała „nie ma twardego limitu wydatków”. Budget Actions potrafią zastosować politykę IAM lub SCP albo zatrzymać konkretne instancje EC2 i RDS. Lambdy, S3 czy Bedrocka nie zatrzymają.
16 września 2026 AWS wprowadził nowy sposób zakładania kont, oparty na projektach. W płatnym planie możesz ustawić dla projektu limit wydatków (spend limit). Minimum to 20 USD albo szacunek Twoich wydatków, jeśli jest wyższy. Limit dotyczy kosztów przed podatkiem i nie uwzględnia kredytów. Po jego osiągnięciu AWS wstrzymuje projekt i zatrzymuje zasoby. Są też opcjonalne wcześniejsze progi, uruchamiane na kilka dni przed prognozowanym przekroczeniem: blokada tworzenia nowych zasobów, pauza bezczynnych zasobów, a nawet pauza największych źródeł kosztu, w tym Lambdy i Bedrocka.
Brzmi świetnie. Ale są trzy haczyki:
- Limity wydatków działają tylko w nowym modelu kont (AWS Settings). Dla tradycyjnych kont, czyli w praktyce dla każdej istniejącej firmy, porównanie w dokumentacji AWS mówi wprost: niedostępne.
- Spend limit to rodzaj AWS Budgets, więc korzysta z tych samych, spóźnionych danych. Pętla, która pali tysiące dolarów w pół godziny, zdąży to zrobić.
- Jeśli projekt jest wstrzymany i przez 90 dni nic z nim nie zrobisz, AWS trwale usuwa jego dane. Hamulec, który zamiast zwolnić, kasuje samochód.
Do nauki i eksperymentów to świetny kierunek. Na produkcji nadal musisz liczyć na siebie.
Czy te potwory nadal żyją?
| Potwór | Mechanizm | Status w październiku 2026 |
|---|---|---|
| 1. Pusty bucket | Opłaty za odrzucone żądania 403 | ⚰️ Martwy dla żądań spoza Twojego konta i organizacji (od 2024) |
| 2. Mumia (13,7 GB) | Transfer z S3 do internetu | 🧟 Żyje |
| 3. 207 mln żądań | Opłata za każde żądanie CloudFront | 🩹 Osłabiony plany flat-rate od 11.2025, jeśli je wybierzesz |
| 4. Lambda@Edge | Rekurencja przez HTTP | 🧟 Żyje detekcja pętli nie obejmuje tej ścieżki |
| 5. Moja pętla | S3, Lambda i Step Functions | 🧟 Żyje |
| 6. Geocodio | NAT Gateway zamiast Gateway Endpoint | 🧟 Żyje |
| 7. Freshpaint | Przyjmowanie logów do CloudWatch | 🧟 Żyje |
| 8. CloudTrail | Data Events dla odczytów S3 | 🧟 Żyje |
| 9. Zombie OpenSearch | Zasoby, które przeżyły delete |
❓ Brak dowodu naprawy |
| 10. Claude na Bedrock | Opłaty poza zasięgiem detekcji anomalii | 🩹 Osłabiony detekcja od 08.2026 |
Jeden martwy, dwa osłabione, sześć żywych i jeden, o którym nie wiem nic pewnego. AWS naprawia te pułapki, ale powoli. A w dwóch przypadkach (1 i 10) dopiero po tym, jak ktoś opisał problem publicznie.
Polowanie na potwory w 15 minut
Każdy z tych potworów zostawia ślad w danych kosztowych. Otwórz Cost Explorer, wybierz ostatnie 3 miesiące, ustaw Group by: Usage type i poszukaj tych śladów. Typy użycia mają prefiks regionu, na przykład EUC1-DataProcessing-Bytes dla Frankfurtu.
| Potwór | Czego szukać | Co zrobić |
|---|---|---|
| 🧛 Wampir (NAT) | Typ użycia z NatGateway-Bytes w nazwie(w kategorii EC2-Other) |
Dodaj Gateway Endpoint dla S3 i DynamoDB |
| 🏺 Mumia (transfer) | DataTransfer-Out-Bytes przy S3 |
Przenieś publiczne pliki za CloudFront |
| 👻 Duch w logach | DataProcessing-Bytes przy CloudWatch |
Znajdź grupę logów z największym wolumenem |
| 🧙 Klątwa CloudTrail | Koszt CloudTrail rosnący miesiąc do miesiąca | Sprawdź selektory Data Events |
| 🦇 Nietoperze (CloudFront) | Koszt żądań CloudFront większy niż koszt transferu | Rate limit w WAF albo plan flat-rate |
Potem kilka szybkich sprawdzeń w terminalu. Które VPC mają endpoint do S3 i jakiego typu (wynik porównaj z listą z aws ec2 describe-vpcs):
1 | aws ec2 describe-vpc-endpoints --region eu-central-1 --filters Name=service-name,Values=com.amazonaws.eu-central-1.s3 --query 'VpcEndpoints[].{Id:VpcEndpointId,Vpc:VpcId,Type:VpcEndpointType}' |
Co dokładnie loguje Twój trail CloudTrail (szukaj DataResources albo AdvancedEventSelectors z S3):
1 | aws cloudtrail get-event-selectors --trail-name NAZWA_TRAILA |
Czy masz budżet, monitor anomalii i subskrypcję, która wyśle alert:
1 | aws budgets describe-budgets --account-id ID_KONTA |
1 | aws ce get-anomaly-monitors |
1 | aws ce get-anomaly-subscriptions |
Sam monitor anomalii bez subskrypcji nikogo nie powiadomi. Jeśli brakuje budżetu, monitora albo subskrypcji, to wiesz, co robisz jeszcze dziś. 😉
Co z tego wynika
Po dziesięciu historiach widać jedno: AWS prawie zawsze liczył dokładnie tak, jak napisał w cenniku. W historiach Geocodio i Cody’ego przeliczenie zgadza się co do centa. Potwory rzadko biorą się z błędów w naliczaniu opłat. Częściej z domyślnych ustawień i z cennika czytanego bez kontekstu własnej architektury.
Dlatego przed każdym wdrożeniem chciałbym umieć odpowiedzieć na trzy pytania:
- Co w tej architekturze może wykonywać się wielokrotnie, nie dostarczając żadnej nowej wartości?
- Po czym poznam, że właśnie tak się dzieje?
- Jak zatrzymam ten proces i kto podejmie decyzję?
A po wdrożeniu robię trzy rzeczy:
- Ustawiam AWS Budgets i Cost Anomaly Detection. Wiedząc, że to czujniki dymu, a nie gaśnice. Dzwonią z opóźnieniem i nie widzą wszystkiego.
- Patrzę na mechanizm, a nie na usługę. Kwota przy „S3” niewiele mówi. Ważne, czy płacisz za storage, żądania czy transfer. Kwota przy „EC2-Other” mówi jeszcze mniej.
- Przeglądam trendy, a nie tylko skoki. Najdroższa historia w tym zestawieniu nie miała ani jednego skoku. Rosła spokojnie przez rok.
I jeszcze jedno. W co najmniej czterech z tych historii AWS oddał pieniądze. Ale zwykle jako jednorazowy gest dobrej woli, często dopiero po publicznym wpisie. To nie jest strategia FinOps.
Ja taki przegląd robię na co dzień w CloudPouch, bo z dokładnie takiego bólu ta aplikacja powstała. Pisałem o tym w artykule Dlaczego AWS Cost Explorer to za mało. Ale niezależnie od narzędzia, zrób ten przegląd. Zanim Twoja historia trafi do kolejnego takiego zestawienia.
A jeśli masz własny horror z rachunkiem AWS (bez wycieku kluczy!), napisz w komentarzu. Chętnie przeczytam. 🎃
Źródła
- Maciej Pocwierz, How an empty S3 bucket can make your AWS bill explode, relacja InfoQ i relacja The Register
- AWS, ogłoszenie z 13 maja 2024, ogłoszenie z sierpnia 2024 i Billing for Amazon S3 error responses
- Chris Short, The AWS bill heard around the world
- r/aws, $15,000 S3 Bill for DDoS, AWS reduced my $15k S3 bill to $10.5k after a DDoS, Update: My $15.5k AWS S3 DDoS bill has been fully resolved
- Web Dev Cody, I got my first DDoS (and what you can do to help prevent it) (rachunek widać około 40. sekundy)
- AWS, CloudFront flat-rate pricing plans, dokumentacja planów i cennik CloudFront
- Ruslan Gainutdinov, I DDoSed myself using CloudFront and Lambda@Edge and got a $4.5k bill i dyskusja na Hacker News z komentarzami autora
- AWS, Lambda recursive loop detection i ogłoszenie dla S3 z października 2024
- Mathias Hansen (Geocodio), The $1,000 AWS mistake i FAQ Amazon VPC (ruch na publiczne adresy AWS zostaje w sieci AWS)
- Michael Malis (Freshpaint), Avoiding a Surprise AWS Bill
- Bharath Nadar, A $200,000 AWS bill nobody noticed
- Elliott King, Amplify overcharge
- The Register, Bedrock and a hard place: Claude adventure leaves AWS user staring down $30K invoice
- AWS, Cost Anomaly Detection supports third-party models on Amazon Bedrock i dokumentacja Cost Anomaly Detection
- AWS, AWS Budgets: częstotliwość odświeżania danych i Budget Actions
- AWS, ogłoszenie nowego sposobu zakładania kont z 16 września 2026, spend limits w AWS Settings i porównanie sposobów zakładania kont
- Cenniki AWS: S3, VPC i NAT Gateway, CloudWatch, CloudTrail, Lambda, Step Functions
