Dlaczego rachunek AWS rośnie, choć ruch się nie zmienia

Jeśli rachunek AWS rośnie z miesiąca na miesiąc, a ruch w aplikacji się nie zmienia, przyczyną jest zwykle jedna z trzech rzeczy. Przybywa danych, których nikt nie kasuje, skończył się rabat albo od konkretnego dnia doszła nowa opłata. Każdą z nich znajdziesz sam w Cost Explorer, gdy porównasz miesiąc sprzed wzrostu z ostatnim.

Porównaj dwa miesiące w Cost Explorer

Otwórz w Cost Explorer bezpłatny widok Compare w panelu Report parameters, ustaw dwa miesiące z ostatnich 13 i pogrupuj wynik po usłudze. Compare według dokumentacji podświetla trzy największe zmiany i przy każdej podaje powód: zmianę zużycia, zmianę rabatu albo inne opłaty i kredyty.

Zużycie, które co miesiąc rośnie o podobną kwotę, wskazuje na dane, które tylko przybywają. Jeśli Compare podaje jako powód zmianę rabatu albo kredytów, przy stałym ruchu zwykle wygasł Savings Plan lub rezerwacja albo skończyły się kredyty. Usługę, która rośnie, odfiltruj potem w zwykłym widoku Cost Explorer i pogrupuj po Usage type.

Przy powolnym wzroście alertu zwykle nie ma. Cost Anomaly Detection w domyślnej konfiguracji wysyła go dopiero, gdy anomalia przekracza 40% oczekiwanego wydatku i jednocześnie 100 USD. Budżet z niższym progiem ustawisz według wpisu o alertach kosztów.

Wersje w S3, obrazy w ECR i dysk RDS

W buckecie z włączonym wersjonowaniem S3 trzyma każdą wersję pliku jako osobny, pełny obiekt i za każdą liczy zwykłą stawkę. Usunięcie pliku nie zwalnia miejsca, bo S3 wstawia wtedy tylko znacznik usunięcia. Rosną też niedokończone uploady wieloczęściowe: S3 liczy za przesłane części, dopóki ktoś nie dokończy albo nie przerwie wysyłki. Oba problemy pokaże S3 Storage Lens w bezpłatnych metrykach Noncurrent version bytes i Incomplete multipart upload bytes.

Pipeline, który przy każdym deployu wypycha nowy obraz do ECR, rejestru obrazów kontenerów, zostawia tam wszystkie poprzednie. Stare usunie polityka cyklu życia według liczby albo wieku. AWS radzi najpierw sprawdzić w podglądzie polityki, co reguła skasuje. Zostaw tyle ostatnich obrazów, żeby dało się wrócić do poprzedniej wersji.

Na RDS rośnie dysk. Z włączonym autoscalingiem AWS sam go powiększa, gdy kończy się miejsce, ale nigdy go nie zmniejsza, więc za dodane gigabajty płacisz także po skasowaniu danych. Ręcznych snapshotów RDS nie kasuje okres retencji, więc leżą i kosztują, dopóki ich nie usuniesz.

Logi w CloudWatch domyślnie nie wygasają nigdy. O nich i o snapshotach EBS po starych skryptach piszę we wpisie o tym, co sprawdzam w audycie kosztów AWS.

Reguła lifecycle dla S3

Poniższa reguła działa na cały bucket: kasuje wersje, które od 30 dni nie są bieżące, i przerywa uploady starsze niż 7 dni. Drugie polecenie zastępuje wszystkie obecne reguły bucketu, więc jeśli bucket ma już reguły, odczytaj je pierwszym poleceniem i dopisz do pliku. Jeśli któraś z nich trzyma stare wersje dłużej niż 30 dni, nie dodawaj tej reguły, bo gdy reguły się nakładają, S3 kasuje według krótszego terminu. Polecenia są dla AWS CLI v2.

aws s3api \
  get-bucket-lifecycle-configuration \
  --bucket nazwa-bucketu

Zapisz regułę jako lifecycle.json:

{
  "Rules": [
    {
      "ID": "sprzatanie",
      "Status": "Enabled",
      "Filter": { "Prefix": "" },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30
      },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

aws s3api \
  put-bucket-lifecycle-configuration \
  --bucket nazwa-bucketu \
  --lifecycle-configuration \
  file://lifecycle.json

Skasowanych wersji nie da się odzyskać, więc jeśli wracasz do starych plików po dłuższym czasie, zwiększ NoncurrentDays.

Koniec Savings Plan albo rezerwacji

Savings Plan ani rezerwacja nie odnawiają się same. Baza RDS, której rezerwacja wygasła, płaci od tego dnia stawkę on-demand. Przed końcem Savings Plan możesz zakolejkować zakup nowego planu albo użyć przycisku Renew Savings Plan. Włącz w zakładce Savings Plans, pod Manage alert subscriptions, e-mail przed końcem planu.

Trzeci rok Extended Support w RDS

RDS dolicza opłatę Extended Support za wersje MySQL i PostgreSQL, których standardowe wsparcie się skończyło, a w trzecim roku ją podwaja. Według cennika RDS na dzień 11 listopada 2026 baza z 2 vCPU na MySQL 5.7 płaciła we Frankfurcie za samo wsparcie ok. 178 USD miesięcznie, a od 1 marca 2026 płaci ok. 356 USD. Opłata obejmuje też instancję zapasową w Multi-AZ.

Dla PostgreSQL 11 trzeci rok zaczął się 1 kwietnia 2026, a PostgreSQL 12 wejdzie w niego 1 marca 2027. Opłata znika sama po aktualizacji bazy do wersji ze standardowym wsparciem. MySQL 8.0 jest w Extended Support od 1 sierpnia 2026, co opisałem we wpisie o opłacie za MySQL 8.0.

Stare snapshoty EBS taniej w archiwum

Jedyny snapshot, który został po usuniętym serwerze, możesz przenieść do archiwum snapshotów EBS. Według cennika EBS na dzień 11 listopada 2026 taka kopia z 500 GB danych kosztuje we Frankfurcie 27 USD miesięcznie w klasie standardowej i 6,75 USD w archiwum. Jedno przywrócenie kosztuje 16,20 USD.

Archiwum ma minimum 90 dni, więc za wcześniejsze usunięcie płacisz do końca tego okresu. Przywrócenie trwa do 72 godzin i dopiero po nim utworzysz z kopii dysk.

Nie archiwizuj snapshotów dysku, którego dalej używasz i który ma nowsze kopie, dzienne, tygodniowe czy miesięczne. Nowsze kopie dzielą z nim większość bloków, więc według wskazówek AWS w klasie standardowej prawie nic się nie zwolni, a archiwum doliczy pełny rozmiar kopii.

Co to znaczy dla małej firmy

Raz w miesiącu, po fakturze, otwórz Compare i porównaj ostatni miesiąc z tym sprzed pół roku. W tym tygodniu sprawdź w Storage Lens dwie metryki S3 z tego wpisu i dodaj regułę lifecycle w bucketach, w których nie są zerowe. Na liście baz RDS sprawdź wersje silników, a w konsoli rozliczeń daty końca Savings Plan i rezerwacji.

Jeśli masz bazę na PostgreSQL 12, zaplanuj jej aktualizację przed 1 marca 2027, bo od tego dnia RDS liczy za nią podwójną stawkę Extended Support.