CloudWatch czy OpenSearch? Jak nie przepalić budżetu na monitoring w AWS
Na spotkaniu SysOps/DevOps Polska Dominik Gubrynowicz z Software Mind pokazał, kiedy natywne narzędzie AWS do monitorowania logów zamienia się w kosztowną pułapkę i czy OpenSearch jest lepszą alternatywą.
Błyskawiczne wdrażanie usług i chmurowa architektura to często przepis na organizacyjny bałagan. Kiedy w grę wchodzą terabajty logów, nieprzemyślane gromadzenie danych w AWS może skończyć się rachunkiem, który zaskoczy każdego finansistę.
Na spotkaniu SysOps/DevOps Polska Dominik Gubrynowicz, Cloud Architect w Software Mind, przyjrzał się bliżej klasycznemu dylematowi zespołów operacyjnych. Przeanalizował, kiedy standardowy CloudWatch zaczyna zawodzić i w jakich sytuacjach lepszym wyborem staje się OpenSearch – chmurowy fork Elasticsearcha.
Dlaczego CloudWatch bywa nazywany „cmentarzyskiem S3” i skąd biorą się jego pułapki kosztowe?
Wiele projektów opartych na AWS startuje od błyskawicznego skonfigurowania infrastruktury przez konsolę. Z czasem jednak ilość logów pochodzących z usług takich jak WAF, CloudFront czy CloudTrail rośnie w tempie lawinowym. W takiej sytuacji inżynierowie najczęściej sięgają domyślnie po Amazon CloudWatch. Narzędzie to daje bogaty zestaw funkcji observability – od Application Signals przez metryki po alerty SLO – ale ma poważną słabość: koszty, które trudno przewidzieć, znane jako pułapka Serverless. W CloudWatchu za sam ingest logów płaci się 50 centów za każdy gigabajt.
Największe problemy finansowe zaczynają się jednak w usłudze Log Insights. Gdy inżynierowie bez zastanowienia odpalają kolejne zapytania analityczne na gigantycznych zbiorach danych, próbując wyłapać błąd, system musi każdorazowo przeskanować cały zestaw logów. Jak zaznacza Dominik Gubrynowicz, niewłaściwe korzystanie z Log Insights bywa w stanie wygenerować rachunki liczone w tysiącach dolarów za jeden dzień debugowania. W efekcie firmy zaczynają masowo przenosić logi na tanie zasoby S3, o których potem nikt nie pamięta, a istotne dane giną w rozproszonych silosach.
Co to jest Amazon OpenSearch i w jakich projektach AWS ma sens jego wdrożenie?
Kiedy koszty CloudWatcha wymykają się spod kontroli, AWS proponuje inne rozwiązanie – OpenSearcha. Powstał on w wyniku konfliktu wokół Elasticsearcha i jego forka, a dziś jest rozwijany jako zaawansowany silnik do analizy logów, system SIEM służący do korelowania zdarzeń związanych z bezpieczeństwem, a od niedawna również baza wektorowa wykorzystywana w projektach AI. Kluczową przewagą biznesową OpenSearcha nad CloudWatchem jest przewidywalność kosztów.
Przy zarządzaniu klastrem, nawet w modelu Managed Domain, architekt planuje z góry poziom zużycia infrastruktury. Jeżeli zespół uruchomi wymagające zapytania analityczne – choćby napędzane nowymi, zasobożernymi agentami AI analizującymi logi – klaster może się na chwilę spowolnić, ale rachunek na koniec miesiąca nie wystrzeli w górę. Dodatkowo darmowy OpenSearch UI pozwala scalić wiele klastrów i budować dashboardy gotowe do prezentacji biznesowi, co obniża bariery w dostępie do informacji i eliminuje konieczność przechodzenia przez niewygodną konsolę AWS. Narzędzie dobrze radzi sobie także z agregacją danych oraz zapytaniami pisanymi w SQL.
Dlaczego wdrożenie OpenSearcha bywa porównywane do przechodzenia przez pole minowe od AWS?
Mimo licznych zalet w przetwarzaniu ogromnych wolumenów logów, konfiguracja OpenSearcha nie jest zadaniem trywialnym i wymaga inżyniera z doświadczeniem w ekosystemie ELK. AWS silnie promuje w tym kontekście podejście Serverless. Przy próbie prostego skonfigurowania potoku ingestu zalecany jest managed Data Prepper, którego koszt startuje od około 175 dolarów miesięcznie za jeden pipeline. Do tego OpenSearch nie ma natywnie dobrego mechanizmu przechowywania metryk, co wymusza sięgnięcie po płatną usługę Amazon Managed Prometheus, jeśli firma chce mieć spójny panel APM do monitorowania wydajności aplikacji. Choć narzędzie umożliwia odpytywanie archiwalnych logów prosto z S3 w modelu Zero-ETL z wykorzystaniem AWS Glue, w tle uruchamiane są kosztowne jednostki obliczeniowe OCU, czyli OpenSearch Compute Units. Bez odpowiedniego doświadczenia inżyniera usługa może pochłaniać budżet równie szybko, jak nieprzemyślane zapytania w CloudWatchu.
Zapanuj nad monitoringiem i kosztami chmury z SysOps/DevOps Polska!
Stabilna infrastruktura to nie tylko sama obecność w chmurze, ale przede wszystkim umiejętność wyboru właściwych narzędzi na danym etapie życia projektu. Błędne decyzje w tym zakresie to jeden z najprostszych sposobów na przepalenie budżetu firmy.
- Wpadnij na jesienne Meetupy SO/DO: Spotkaj ekspertów na żywo, wymień się doświadczeniami i zadaj pytania prelegentom! Znajdź najbliższe wydarzenie w swoim mieście i zapisz się na: https://www.sysopspolska.pl/.
- Webinary AI Now: Chcesz wiedzieć, jak podpiąć agentów AI do analizy logów w systemach typu OpenSearch bez paraliżowania baz danych i infrastruktury? Weź udział w bezpłatnych webinarach AI Now. Zapisy tutaj: https://www.ainowpolska.pl/.
- Jeśli planujesz wdrażać rozbudowaną infrastrukturę logów i uniknąć bolesnych w skutkach pomyłek finansowych, zajrzyj do oferty edukacyjnej. Sprawdź autorskie warsztaty na: https://www.sysopspolska.pl/szkolenia/.
Pełne nagranie prelekcji „Po co AWS-owi OpenSearch do monitoringu, jak ma CloudWatch?” autorstwa Dominika Gubrynowicza jest dostępne online.
Źródło: SysOps/DevOps Polska


