CODELEVEL, audyt kosztów AWS
Raport z audytu kosztów
Przykładowe dane
1. Podsumowanie
- Rachunek dziś
- 14 800 zł/mies.
- Do odzyskania
- 5 060 zł/mies.
- Czyli
- 34% rachunku
Znalazłem 10 zmian wartych razem 5 060 zł miesięcznie, czyli 60 720 zł w skali roku. 8 z nich ma niskie ryzyko i daje 2 980 zł miesięcznie; większość to zmiany konfiguracji na kilka godzin. Tylko jedna wymaga pracy Twoich programistów.
Największa pozycja to baza produkcyjna: ma dwa razy więcej mocy i pamięci, niż wynika z trzech miesięcy metryk. Druga to staging, który działa całą dobę, choć używany jest tylko w dni robocze. Proponuję zacząć od sprzątania bez wpływu na aplikację (tydzień 1), a Savings Plan kupić na końcu, dopiero na nowym, niższym poziomie zużycia.
2. Rachunek dziś
Średnia z trzech pełnych miesięcy, netto, według usług.
| Usługa | zł/mies. | Udział |
|---|---|---|
| EC2 (instancje) | 4 720 | |
| RDS | 3 900 | |
| EBS (dyski i snapshoty) | 1 240 | |
| NAT Gateway | 1 090 | |
| CloudWatch | 1 080 | |
| S3 | 820 | |
| Transfer danych na zewnątrz | 540 | |
| Load balancery (ELB) | 520 | |
| ElastiCache | 490 | |
| Pozostałe (Route 53, KMS, ECR, Secrets Manager) | 400 | |
| Razem | 14 800 |
3. Lista zmian
Kwoty netto miesięcznie. Kolejność wdrożenia jest w planie (punkt 5).
| # | Zmiana | zł/mies. | Nakład | Ryzyko |
|---|---|---|---|---|
| 01 | RDS produkcja: db.r5.xlarge na db.r6g.large (Multi-AZ) | 1 690 | 1 dzień | ryzyko średnie |
| 02 | Staging wyłączany nocą i w weekendy | 670 | 4 h | ryzyko niskie |
| 03 | Retencja logów CloudWatch: 30 dni zamiast bez limitu | 490 | 1 h | ryzyko niskie |
| 04 | Endpointy VPC dla S3 i ECR zamiast ruchu przez NAT | 420 | 4 h | ryzyko niskie |
| 05 | API na Gravitonie: 4 × m5.xlarge na 4 × m7g.xlarge | 390 | 2 dni | ryzyko średnie |
| 06 | Compute Savings Plan na 1 rok, bez przedpłaty | 580 | 1 h | ryzyko niskie |
| 07 | Stare snapshoty EBS: 1,6 TB z 1,9 TB | 310 | 1 h | ryzyko niskie |
| 08 | Cykl życia dla bucketu z logami w S3 | 220 | 2 h | ryzyko niskie |
| 09 | Dyski gp2 na gp3 | 170 | 2 h | ryzyko niskie |
| 10 | Nieużywany load balancer i 3 adresy Elastic IP | 120 | 1 h | ryzyko niskie |
| Razem | 5 060 | |||
4. Zmiany po kolei
01 RDS produkcja: db.r5.xlarge na db.r6g.large (Multi-AZ)
1 690 zł miesięcznienakład 1 dzieńryzyko średniebez zmian w kodzie
- Co widzę
- Baza produkcyjna ma średnio 14% CPU (maksimum 41% w szczycie). ReadIOPS są niskie i stałe, także w szczycie, więc dane robocze mieszczą się w pamięci. Czy zmieszczą się w 16 GB, pokaże test na kopii bazy. Rozmiar dobrano przy starcie, dla ruchu, który nie przyszedł.
- Co zmienić
- Test wydajności na kopii bazy w db.r6g.large (Graviton, 16 GB), potem zmiana klasy w oknie serwisowym. Multi-AZ zostaje.
- Wyliczenie
- db.r5.xlarge Multi-AZ ok. 3 090 zł/mies., db.r6g.large Multi-AZ ok. 1 400 zł/mies.
- Jak cofnąć
- Zmiana klasy z powrotem, ok. 15 minut, przełączenie Multi-AZ 1–2 minuty.
02 Staging wyłączany nocą i w weekendy
670 zł miesięcznienakład 4 hryzyko niskiebez zmian w kodzie
- Co widzę
- Staging (2 × m5.large i db.t3.large) działa 168 godzin w tygodniu. Metryki CPU i ruchu sieciowego z CloudWatch pokazują, że pracuje tylko w dni robocze, między 8 a 20. Przez resztę tygodnia stoi bez ruchu.
- Co zmienić
- Harmonogram w EventBridge Scheduler: start 8:00, stop 20:00, w weekend wyłączony. Ręczny start jedną komendą.
- Wyliczenie
- Instancje stagingu 1 040 zł/mies. × 64% godzin, w których stoją nieużywane.
- Jak cofnąć
- Wyłączenie harmonogramu.
03 Retencja logów CloudWatch: 30 dni zamiast bez limitu
490 zł miesięcznienakład 1 hryzyko niskiebez zmian w kodzie
- Co widzę
- Wszystkie grupy logów mają ustawienie „Never expire”. Przechowywanie kosztuje 610 zł/mies. i rośnie co miesiąc.
- Co zmienić
- Retencja 30 dni dla logów aplikacji, 365 dni dla logów audytowych. Starsze logi, jeśli są potrzebne, eksport do S3.
- Wyliczenie
- Ok. 80% przechowywanych danych jest starsze niż 30 dni: 610 zł × 0,8.
- Jak cofnąć
- Retencję można wydłużyć w każdej chwili, ale usuniętych logów nie da się odzyskać.
04 Endpointy VPC dla S3 i ECR zamiast ruchu przez NAT
420 zł miesięcznienakład 4 hryzyko niskiebez zmian w kodzie
- Co widzę
- Pozycja NatGateway-Bytes to 820 zł/mies. Twój zespół uruchomił moje zapytanie na VPC Flow Logs: 72% danych przechodzących przez NAT Gateway idzie do S3 i ECR, czyli do usług AWS w tym samym regionie.
- Co zmienić
- Gateway endpoint dla S3 (bezpłatny) i interface endpoints dla ECR w dwóch strefach. Wcześniej sprawdzam polityki bucketów z warunkiem na adres IP.
- Wyliczenie
- Przetwarzanie w NAT 820 zł × 0,72 = 590 zł, minus koszt endpointów ECR ok. 170 zł/mies.
- Jak cofnąć
- Usunięcie endpointów, ruch wraca przez NAT.
05 API na Gravitonie: 4 × m5.xlarge na 4 × m7g.xlarge
390 zł miesięcznienakład 2 dniryzyko średniewymaga pracy programistów
- Co widzę
- Instancje API mają 9% CPU średnio, ale 60% pamięci, więc zmniejszyć się ich nie da. Da się zmienić architekturę procesora.
- Co zmienić
- Budowanie obrazów na arm64 w CI, testy na stagingu, wymiana węzłów po jednym.
- Wyliczenie
- 4 × m5.xlarge ok. 2 450 zł/mies., 4 × m7g.xlarge ok. 2 060 zł/mies.
- Jak cofnąć
- Powrót do poprzedniego szablonu uruchamiania, bez przestoju.
06 Compute Savings Plan na 1 rok, bez przedpłaty
580 zł miesięcznienakład 1 hryzyko niskiebez zmian w kodzie
- Co widzę
- Stała część produkcji (API i 3 workery) działa całą dobę od ponad roku, w całości w cenie on-demand.
- Co zmienić
- Zakup po zmianie 05, na ok. 80% stałego zużycia, żeby nie zapłacić za zapas.
- Wyliczenie
- Produkcja po zmianie 05: ok. 3 610 zł/mies. × 0,8 × ok. 20% rabatu.
- Jak cofnąć
- Zobowiązanie na 12 miesięcy, bez możliwości anulowania. Płacisz za nie także po ewentualnym wyjściu z AWS. Dlatego tylko 80% zużycia.
07 Stare snapshoty EBS: 1,6 TB z 1,9 TB
310 zł miesięcznienakład 1 hryzyko niskiebez zmian w kodzie
- Co widzę
- Snapshoty ręczne sprzed ponad 90 dni i snapshoty dysków, które już nie istnieją, razem 1,6 TB rozliczanej przestrzeni (z Cost Explorer na poziomie zasobów, nie z rozmiaru dysków). Nie należą do żadnego planu AWS Backup.
- Co zmienić
- Po Twoim potwierdzeniu listy usunięcie, a potem reguła w Data Lifecycle Manager.
- Wyliczenie
- 1 600 GB × ok. 0,20 zł za GB miesięcznie.
- Jak cofnąć
- Brak: usunięty snapshot przepada. Dlatego lista idzie do akceptacji.
08 Cykl życia dla bucketu z logami w S3
220 zł miesięcznienakład 2 hryzyko niskiebez zmian w kodzie
- Co widzę
- 3,2 TB logów starszych niż 90 dni w klasie Standard, czytanych raz na kilka miesięcy. Średni obiekt ma ok. 2 MB (z metryk S3), więc minimalny rozmiar 128 KB nie podnosi kosztu.
- Co zmienić
- Reguła cyklu życia: po 90 dniach przeniesienie do Glacier Instant Retrieval.
- Wyliczenie
- 3 200 GB × różnica ok. 0,07 zł za GB miesięcznie.
- Jak cofnąć
- Usunięcie reguły; odczyt starych plików jest droższy, ale natychmiastowy.
09 Dyski gp2 na gp3
170 zł miesięcznienakład 2 hryzyko niskiebez zmian w kodzie
- Co widzę
- 2 TB dysków starszego typu gp2. Żaden nie potrzebuje w szczycie więcej niż 3 000 IOPS i 125 MB/s, czyli tyle, ile gp3 daje w cenie.
- Co zmienić
- Zmiana typu na gp3 w locie, bez restartu instancji.
- Wyliczenie
- 2 000 GB × różnica ok. 0,09 zł za GB miesięcznie.
- Jak cofnąć
- Zmiana typu z powrotem, też w locie (6 godzin po poprzedniej zmianie).
10 Nieużywany load balancer i 3 adresy Elastic IP
120 zł miesięcznienakład 1 hryzyko niskiebez zmian w kodzie
- Co widzę
- Load balancer po starym środowisku testowym bez ruchu od 4 miesięcy i 3 adresy IP bez przypisanej maszyny.
- Co zmienić
- Usunięcie po potwierdzeniu, że nic z nich nie korzysta.
- Wyliczenie
- Load balancer ok. 80 zł/mies., adresy ok. 40 zł/mies.
- Jak cofnąć
- Nowy load balancer w kilka minut; adresy IP będą inne.
5. Plan wdrożenia
Tydzień 1
Sprzątanie bez wpływu na aplikację
03 Retencja logów CloudWatch: 30 dni zamiast bez limitu; 04 Endpointy VPC dla S3 i ECR zamiast ruchu przez NAT; 07 Stare snapshoty EBS: 1,6 TB z 1,9 TB; 08 Cykl życia dla bucketu z logami w S3; 09 Dyski gp2 na gp3; 10 Nieużywany load balancer i 3 adresy Elastic IP.
+1 730 zł
Tydzień 2
Harmonogram stagingu
02 Staging wyłączany nocą i w weekendy.
+670 zł
Tygodnie 3–4
Zmiany z testem: baza i Graviton
01 RDS produkcja: db.r5.xlarge na db.r6g.large (Multi-AZ); 05 API na Gravitonie: 4 × m5.xlarge na 4 × m7g.xlarge.
+2 080 zł
Po 30 dniach stabilnej pracy
Zobowiązanie na nowym poziomie zużycia
06 Compute Savings Plan na 1 rok, bez przedpłaty.
+580 zł
6. Czego nie zmieniam
- RDS po zmianie 01: rezerwacja na rok ma sens po 30 dniach na db.r6g.large. Nie wliczam jej do sumy, bo zależy od wyniku testu wydajności.
- ElastiCache (490 zł/mies.): rozmiar pasuje do obciążenia. Rezerwacja ma sens dopiero po roku stabilnej pracy.
- Transfer danych na zewnątrz (540 zł/mies.): CDN przed API obniżyłby go, ale wymaga zmian w aplikacji. Opisuję to osobno, bez kwoty w sumie.
- Workery (3 × c5.xlarge): kandydat na Graviton w drugim kroku, po sprawdzeniu bibliotek natywnych.
7. Jak liczę
Podstawą każdej kwoty jest średni miesięczny koszt usługi z trzech pełnych miesięcy w Cost Explorer, wyceniony według publicznego cennika AWS z dnia raportu i przeliczony po kursie 3,65 zł/USD. Oszczędność roczna to kwota miesięczna razy 12. Kwoty zmian, które na siebie wpływają (np. Savings Plan po przejściu na Graviton), liczę po kolei, żeby nic nie policzyć dwa razy.
Nie musisz nic wdrażać. Jeśli wolisz, wdrażam zmiany sam, w Terraformie, w Twoim repozytorium.