Modele zakupu EC2

Instancje maszyn wirtualnych w usłudze EC2 możemy kupować na kilka sposobów:

On-demand

Najpopularniejszym jest model On-demand, w którym mamy największą elastyczność przy tworzeniu i używaniu maszyn wirtualnych, płacimy tylko za czas, w którym te maszyny pracują. Za tą elastyczność ponosimy jednak największe koszty.

Jest to chyba najpopularniejszy model, który sprawdza się wszędzie tam, gdzie nie jesteśmy w stanie określić dokładnie czego tak naprawdę potrzebujemy, w przypadku maszyn, które pracują tylko przez określony czas, przy testach. W skrócie, ten model sprawdzi się wszędzie tam, gdzie nasze aplikacje pracują przez krótki czas, są dopiero rozwijane lub testowane.

Spots

Nie każda aplikacja potrzebuje jednak środowiska, które musi działać niezakłócone, bez przerwy. Jeżeli mamy do czynienia z aplikacjami, które mogą wznawiać bez problemu swoje działanie, ich uruchomienie i zakończenie nie musi odbywać się w określonym czasie, powinniśmy spojrzeć w kierunku instancji typu Spot.

AWS ma bardzo wiele zasobów, z których wiele jest niewykorzystanych. Takie zasoby są udostępniane w cenie niżej nawet o 90%. Co więcej, to my w pewnym sensie o tej cenie decydujemy, określamy jej maksymalny pułap, który nas interesuje. I dopóki nikt nie będzie gotowy zapłacić więcej lub AWS nie będzie potrzebował naszych zasobów to będą one dla nas dostępne. Mogą jednak one w każdej chwili nam zostać odebrane (dostaniemy oczywiście ostrzeżenie), nasze aplikacje muszą być więc na to gotowe.

Floty maszyn typu spot możemy jednak tak zaprojektować, że nawet produkcyjne klastry Kubernetesa będą bardzo dobrze z nimi pracowały, a nasze koszty będą o wiele niższe. Takie usługi jak Amazon ECS, Amazon EMR, Amazon Sagemaer czy AWS Batch także mogą skorzystać z instancji typu spot.

Reserved

Chmura publiczna to nie tylko możliwość elastycznego korzystania z zasobów. W wielu przypadkach wiemy, że nasze będą uruchomione przez dłuższy czas oraz znamy ich zapotrzebowanie na zasoby. W tym przypadku warto sięgnąć po zasoby typu Reserved, gdzie oszczędność w porównaniu do instancji on-demand może wynieść nawet 72%.

Wartość ta zależy od kilku czynników:

• na jak długi okres wykupimy rezerwację;
• czy chcemy zapłacić za zasoby z góry;
• czy rezerwacja będzie standardowa, czy konwertowalna;
• czy rezerwujemy zasoby w regionie czy w konkretnej availability zonie.

Instancje typu Reserved dajną nam najmniejszą elastyczność, ale odwdzięczają się niską ceną i pewnością, że nasze zasoby nie zostaną nam odebrane. Co więcej, w przypadku dokonania rezerwacji w ramach availability zony, mamy pewność, że nasze zasoby będą na nas czekały.

Savings plans

Kolejnym sposobem na obniżenie rachunków w AWS jest skorzystanie z tak zwanych Savings Plans, w którym nasze zasoby dostaniemy także w cenie niższej od modelu on-demand. W tym przypadku nie rezerwujemy konkretnych typów maszyn, zobowiązujemy się tylko, że przez określony czas (rok lub 3 lata) będziemy wydawali na zasoby konkretną ilość pieniędzy.

Dostępne są trzy rodzaj takich planów:

• Compute Savings Plans, które dają oszczędności do 66% i możemy je wykorzystać w przypadku usług EC2, Fargate, a nawet funkcji Lambda. Wszystko to, w wielu regionach AWS.
• EC2 Savings Plans oferujące oszczędności do 72% w ramach rodziny instancji maszyn wirtualnych pracujących o obrębie jednego regionu.
• SageMaker Savings Plans, w którym oszczędności mogą sięgnąć 64% i może być wykorzystany w wielu rodzajach instancji, regionach oraz komponentach SageMakera.

Optymalizacja zasobów

Oprócz szukania sposobu na jak najniższe ceny na wykorzystywane zasoby, dobrze jest także starać się jak najlepiej zoptymalizować wykorzystywane usługi. Warto przyjrzeć się raportom w usłudze AWS Cost Explorer, przejrzeć rady w AWS Trusted Advisor. Przede wszystkim trzeba jednak śledzić użycie zasobów, przeglądać metryki utylizacji itd. Jeżeli na przykład nasze maszyny wirtualne wykorzystywane są w 30%, to coś jest nie tak i warto to zmienić. Może taniej wyjdzie udostępnianie zasobów poprzez usługę CloudFront, zamiast serwowania plikó bezpośrednio z S3.

Serverless

Coraz więcej aplikacji w chmurze wdrażanych jest jednak już w modelu serverless. W przypadku tego rodzaju aplikacji spory wpływ na koszty będzie miał także sposób ich napisania. Starajmy się przetwarzać dane w batchach zamiast pojedynczo, wybierzmy S3 zamiast bazy danych (jeżeli jest to możliwe) do przechowywania danych, wykorzystajmy odpowiedni typ API w usłudze API Gateway. Spory wpływ na miesięczne koszty będzie miała także konfiguracja samych zasobów. Tutaj jednym z głównych aktorów będzie na pewno funkcja Lambda.

Poniżej widać wykresy czasu działania Lambdy oraz poniesionych kosztów dla funkcji liczącej ciąg Fibonacciego dla liczby 20000000. Jak widać najniższy koszt dla tej funkcji osiągniemy, gdy przydzielimy jej 512 MB pamięci.

Jeżeli chodzi o DynamoDB to też sprawdźmy, jak zadziałają dla nas różne modele płatności. Filtrujmy dane w usłudze SNS, czy wreszcie postarajmy się o jak najmniejszy rozmiar naszych obrazków, które przetwarzamy i wysyłamy do klientów. Takich czynników wpływających na koszty jest naprawdę wiele i nie sposób wszystkie tu wymienić.

Podsumowanie

Na miesięczny rachunek za usługi w AWS wpływ ma bardzo wiele czynników. Począwszy od tego jak napiszemy nasze aplikacje, poprzez odpowiednie dobranie zasobów w chmurze, ich konfigurację i wreszcie model płatności, który wybierzemy. Możemy próbować estymować przyszłe koszty, na przykład przy pomocy kalkulatora usług AWS, ale rzeczywistość pewnie i tak przyniesie nam wiele niespodzianek. Pamiętajmy też o tym, aby koniecznie przyglądać się temu co dzieje się na naszych kontach, jak wykorzystujemy to za co płacimy. Prawie zawsze da się znaleźć oszczędności.