Wczorajsza awaria wielu usług chmurowych dostępnych w ramach Amazon Web Services spowodowała jednocześnie brak działania znaczącej liczby znanych serwisów i aplikacji internetowych. Były to m.in. Duolingo, Zoom, Reddit, Tidal, ale też znany w branży informatycznej, wśród osób ceniących prywatność, czy amerykańskich polityków komunikator Signal. W związku z tym pojawiły się pewne słuszne wątpliwości dotyczące wiarygodności tego rozwiązania i ewentualnych „zewnętrznych” wpływów.
Pierwszy uwagę na ten fakt zwrócił Elon Musk w jednym ze swoich ostatnich wpisów w serwisie X.
Pretty weird that an AWS outage caused Signal to fail … https://t.co/MzAtJPjAla
— Elon Musk (@elonmusk) October 20, 2025
Pod tym wpisem znajdziemy tysiące opinii innych użytkowników, którzy w znakomitej większości wyrażają podobne obawy. Pomijając fakt nieistniejącej decentralizacji, trzeba jednoznacznie stwierdzić, że Amazon jest znaczącym „elementem” pośrednio odpowiedzialnym za działanie Signal. Zastosowane szyfrowanie end-to-end powinno zabiegać sytuacji, w której nieuprawnione osoby uzyskują dostęp do jawnej treści konwersacji przeprowadzanych z użyciem Signal. Jednak taka zależność od zewnętrznego dostawcy oznacza, że pod różnymi naciskami może on „wyłączyć” infrastrukturę komunikatora, co uczyni go bezużytecznym – jak miało to miejsce wczoraj. Wydaje się, że od komunikatora określanego powszechnie jako „bezpieczny” można oczekiwać znacznie większej niezależności, jak również dostępności.
Oczywistym jest, że Signal nie posiada możliwości uruchomienia własnej infrastruktury sprzętowej zdolnej do optymalnej obsługi tak dużego ruchu. Użycie różnych dostawców chmurowych (oprócz AWS jest to także Azure i GCP) jest z zasady odpowiednim wyborem w tej sytuacji, co absolutnie nie zmienia oceny, że Signal pozostaje całkowicie zależny od innych podmiotów. Już nie wspominając, że wszystkie z wymienionych usług chmurowych podlegają jurysdykcji Stanów Zjednoczonych, co pod kątem szeroko rozumianej prywatności nie jest zbyt optymistyczną informacją.
Do różnych „codziennych” aktywności Signal na ten moment wciąż pozostaje dobrym rozwiązaniem. Przede wszystkim jest to gotowa, wygodna aplikacja dostępna na wiele platform i nie wymaga zaawansowanej konfiguracji po stronie użytkownika. Jeśli jednak zależy nam na prawdziwie bezpiecznym komunikatorze, to zdecydowanie najlepiej postawić na narzędzia self-hosted, takie jak Mattermost – chodzi o dążenie do takiego stanu, aby żadna treść nie była zapisywana na serwerach należących do jakiegokolwiek zewnętrznego podmiotu.
W zastosowaniach profesjonalnych – produkcyjnych – sprawdzi się podejście, w którym unikamy całkowitej zależności od zewnętrznych dostawców, jak również sytuacji, w której awaria jednego komponentu ma wpływ na całą usługę. Wdrożenie high availability powinno zapewnić działanie danej usługi nawet podczas niedostępności wybranych komponentów. W przykładowym, ale jednocześnie najczęściej spotykanym w praktyce podejściu, zarządza się kilkoma serwerami aplikacyjnymi, klastrem bazy danych (najlepiej z failover, czyli automatycznym przełączeniem na działające instancje) i klastrem storage. Ruch do serwerów aplikacyjnych jest zarządzany przez load balancer, a w środowiskach wymagających znacznie większej dostępności można spotkać nawet klastry serwerów load balancer – wtedy jedynie masowa awaria spowoduje degradację naszej usługi.
