Zanim przejdziemy do sedna, bądźmy szczerzy - kalkulator cen AWS jest mylący. Częściowo wynika to z oferowanej przez AWS metody płatności a la carte. To sprawia, że uzyskanie dobrej wyceny przez klienta jest trudne. Mam nadzieję, że ten artykuł rzuci trochę światła na faktyczne koszty uruchomienia aplikacji, jak również kilka sposobów na ich zmniejszenie.
Zarządzam aplikacją internetową dla Node w ELB od około dwóch lat. Pierwszy rok był świetny, Amazon dawał nam (prawie) wszystko za darmo! Potem trzeba było zacząć płacić za rzeczy, takie jak instancje EC2.
W tym artykule skupię się na wymaganiach dotyczących mojej konkretnej aplikacji, która jest aplikacją Express opartą na Node, hostowaną na Elastic Beanstalk.
Po szczegółowe informacje na temat budowy, rzuć okiem na mój poprzedni artykuł tutaj.
Oto, co obecnie uruchamiam w AWS:
Pojedyncze środowisko EBS (region zachodni USA):
18 USD (za Load Balancer) + 5 USD (za EC2 z RI) + 0,50 USD (za Route 53) + 0,17 USD (za S3) + 0,21 USD (transfer danych) = mniej więcej 25 USD miesięcznie.
Dodatkowo, hostuje MongoDB gdzie indziej, więc jeśli planujesz hosting DB na AWS, zapłacisz więcej. Podzielmy różne koszty.
Jest to najdroższa część stosu. Kosztuje:
Oznacza to, że jeśli aplikacja pracuje 24 godziny na dobę, będzie Cię to kosztować około $18 + opłaty za transfer danych, co miesiąc.
Instancje EC2 na żądanie są droższe niż powinny. Aby zaoszczędzić trochę pieniędzy, zapoznaj się z sekcją dotyczącą Zarezerwowanych instancji EC2. Jeśli się nad tym zastanawiasz to uruchomienie tego samego typu instancji EC2, jak powyżej, na żądanie, kosztowałoby cię 8,40$.
Mam kilka bucketów S3. Jeden dla mojej statycznej strony głównej, jeden do przechowywania obrazów i jeden do przechowywania wersji aplikacji. O ile wiem, ELB automatycznie tworzy bucket, który służy do zarządzania wersjami aplikacji.
S3 jest dość tani, więc nie jestem zbytnio zaniepokojony płaceniem za niego, ale są sposoby, aby zaoszczędzić pieniądze za pośrednictwem ich systemu Glacier.
Hostuje MongoDB DB w mLab, który wkrótce kończy działalność. Zaktualizuję ten tekst gdy będę zmuszony przenieść się do Atlasu Mongo i kiedy ustale, ile to będzie kosztować.
Porozmawiajmy o instancjach zastrzeżonych (RI). Skomplikowany system rozliczeniowy Amazon jest najbardziej mylącą częścią zarządzania czymkolwiek w AWS. Instancje zastrzeżone mogą zmniejszyć część kosztów, ale są również bardzo skomplikowane.
Po wielu lekturach i rozmowach z działem obsługi klienta AWS, oto, do jakich doszedłem wniosków.
Po pierwsze, istnieją dwa różne sposoby rezerwowania miejsca, w którym znajduje się RI: Strefa regionalna i strefa dostępności. Regionalne oznacza, że jest on specyficzny dla jednego z głównych regionów, np. US-West-2 (Oregon). Strefa dostępności (AZ) jest specyficzna dla strefy w obrębie tego regionu, np. us-west-2a (Oregon).
Kupiłem RI wewnątrz US-West-2 i zostało to automatycznie zastosowane do mojej instancji działającej w tym obszarze. Jeśli kupisz jedną z nich w ramach jednej strefy dostępności, będzie ona miała zastosowanie tylko do konkretnej AZ, np. US-West-2a, więc jeśli ELB podniesie instancję EC2 w US-West-2b, to masz problem.
Dodatkowo istnieją "standardowe" i "zamienne" typy RI. Nie jestem w 100% pewny, co to znaczy, ale z tego, co rozumiem, zamienne są bardziej elastyczne w kwestii tego, na co można je zamienić, ale są droższe.
Ostatecznie, istnieją trzy rodzaje płatności: Nie z góry, częściowo z góry, całkowicie z góry. Jest to dość proste, płacisz nic, część lub całość, gdy rezerwujesz instancję. Nie widzę w żadnej z nich jakiejś specjalnej korzyści. Jednakże, jako nowy użytkownik, najprawdopodobniej nie masz możliwości zapłacenia z góry.
Według wsparcia klienta AWS:
Żadne podane z góry zarezerwowane instancje (RI) nie mogą stwarzać znacznego ryzyka związanego z fakturowaniem nowych rachunków, ponieważ są one umownym zobowiązaniem do comiesięcznej zapłaty za cały okres RI. Z tego powodu, nowe konta i mało używane konta nie są w stanie zapisać się do No Upfront RIs, dopóki nie powstanie prawidłowa historia rozliczeń.
Możesz natknąć się na ten błąd, jeśli spróbujesz kupić "no up-front".
Błąd: Obecna kwota nie pozwala na zakup wymaganej liczby zarezerwowanych instancji ((Service: Amazon EC2; Status Code: 400; Error Code: ReservedInstancesLimitExceeded;)
Zastrzeżenie: Z jakiegokolwiek powodu, zarezerwowana instancja potrzebuję trochę czasu, aby się “odpalić”, co oznacza, że pierwszy dzień miesiąca zawsze będzie kosztował więcej. Nie jestem pewien, dlaczego tak jest, ale jeśli się dowiem, zaktualizuję to. Rzuć okiem na wykres poniżej:
Istnieją pewne drobne skargi dotyczące całego EBS, które pomyślałem, że dołączę do mojego artykułu jako dodatek, na wypadek, gdybyś był ciekawy.
Node nie jest kompatybilny między wersjami.
Zobacz poniżej jak zmieniam wersje Linuksa, gdy Node nie działa.
Posiadanie środowiska deweloperskiego i jednocześnie uruchomionej produkcji jest łatwe, ale kosztowne. Koszta są tak naprawdę wręcz podwojone. Dlatego zazwyczaj demontuje swoje środowisko dev, jak tylko z nim skończę.
AWS-owi nie służy, że jest tak duży.. To jeden z powodów dla których piszę ten artykuł. Naprawdę ciężko było znaleźć odpowiedzi na moje konkretne potrzeby.
Mam dwie oddzielne instancje mojego repo git zainstalowane na moim laptopie. Jedna dla Deva, a druga dla produkcji.
Używam środowiska dev do, no cóż, rozwoju! Bez owijania w bawełnę. Używam folderu produkcyjnego wyłącznie w celu pobierania aktualizacji z głównej gałęzi Git, uruchamiania konfiguracji mojego webpacka i wgrywania na serwer produkcyjny.
Powodem, dla którego są one odrębne, jest to, że mogę utrzymywać oddzielne konfiguracje elastic beanstalk i nie muszę się martwić o wgranie kodu w niewłaściwe miejsce.
W przypadku aktualizacji niewymagających żadnych zmian w środowisku linuksowym, jest to tak proste jak uruchomienie eb deploy w terminalu. To niesamowite i trwa jedynie około 10 minut.
Czasami będziesz chciał zaktualizować środowisko Linuksa, ale nie będziesz mógł tego zrobić, ponieważ AWS jest szalenie głupie (jestem pewien, że jest ku temu powód) i zezwala tylko na niektóre wersje Node na każdej kompilacji Linuksa. Przez to, jest to trochę bardziej skomplikowane, ale wciąż możliwe do opanowania.
Proszę bardzo. Oto, jak zarządzać aktualizacjami. Nie jest to trudne. Wesołego kodowania!
Oryginalny tekst w języku angielskim przeczytasz tutaj.