W jaki sposób liczone są opłaty za kontener w chmurze (Azure, AWS, Google Cloud)?

Załóżmy, że stawiam aplikację webową, którą odwiedza 10 osób dziennie. Aplikacja musi oczywiście działać przez 24/7, ale czy zapłacę za cały czas dostępności? Dla uproszczenia przyjmijmy, że każda osoba wchodząc na stronę wyświetla tylko stronę główną, a więc kontener musi obsłużyć zaledwie 10 requestów dziennie. Czy dobrze rozumiem, że naliczone zostaną opłaty tylko za ten czas, kiedy kontener zużywa zasoby do obsługi tych requestów? Jeśli te 10 requestów będzie sprawiać, że kontenery będą zużywać czas procesora jedynie przez 10 sekund dziennie to za pozostałe 23h 59 min i 50 sekund dziennie nie zapłacę nic? Innymi słowy, czas "idle" nie powoduje naliczenia opłat? W takiej sytuacji zakładam, że jest stała opłata za przestrzeń, jaką zajmuje dany kontener niezależnie czy jest busy, idle czy w ogóle wyłączony.

Przykładowo dla Azure koszt kontenera z 1 GB RAM oraz 1 vCPU przy łącznym stanie użycia przez 300 sekund miesięcznie to jedynie $0.01, czyli "gratis". Według Google tak to właśnie działa "Cloud Run charges you only for the resources you use, rounded up to the nearest 100 millisecond.".

Jak to ma się jeszcze do procentowego użycia zasobów? Jeśli obciążenie procesora będzie na poziomie X% to naliczony koszt za sekundę wykorzystania RAM/CPU będzie wynosić tylko X% opłaty za sekundę użycia tego zasobu?

Zadaję takie pytanie, bo w przypadku małych aplikacji to są naprawdę bardzo niskie koszty, kilkakrotnie mniejsze niż jakiś tani VPS, za którego trzeba płacić stałą opłatę co miesiąc.

A w przypadku Azure o jakiej usłudze mówisz?

Jeśli Container Instances to nie - zapłacisz za cały czas kiedy twój kontener jest uruchomiony, nawet jeśli przez 23 godziny i 59 minut dziennie będzie się nudzić to i tak za ten czas zapłacisz.

Z pricingu:

Container group duration is calculated from the time that we start to pull your first container's image (for a new deployment) or your container group is restarted (if already deployed), until the container group is stopped.

W takim razie jak to liczy Google? Mają kalkulator dla ich usługi Cloud Run. Mogę zaznaczyć opcję "CPU is only allocated during request processing ". Wybrałem 1 CPU, 512 MB RAM. Załóżmy, że czas obsługi jednego requesta to będzie średnio 300 ms. Mamy 1000 użytkowników, każdy średnio robi dziennie 50 requestów, co w skali miesiąca daje 1,5 mln requestów. Dla tych danych Google wyliczyło mi $9.86 miesięcznie: https://cloud.google.com/products/calculator/#id=db2db8fa-6a97-43ba-ae0b-de496d346f64

No jak widać liczy inaczej, nie mam doświadczenia z GCP to nie wiem, ale to co napisałeś wygląda sensownie ;)
Wynika z tego, że na GCP możesz postawić kontener i masz rozliczanie bardziej "serverlessowe", czyli płatność za rzeczywiste zużycie, a nie alokację zasobów.

Podłączam się do pytania. Korci mnie, żeby spróbować Azure. Chciałbym zacząć od postawienia apki .Net5 + MSSQL (może kilku apek). Ale niejasność i ewentualna wysokość opłat mnie przeraża. Ktoś tam już był? Wymagam SSL (Let's Encrypt), własnej domeny i możliwości postawienia do 5 aplikacji. Aktualnie używam HostedWindows i jest git. Tyle, że tam mogę mieć 2 apki w tym najniższym pakiecie.

W Azure możesz skorzystać z Azure Kubernetes Service, który działa tak, że pod spodem masz klaster maszyn wirtualnych (Scale Set) w którym możesz mieć ile chcesz maszyn. Na tych VM'kach uruchomiona jest twoja instancja Kubernetes, w której chodzi jakiś zestaw podów (instancji kontenerów).
AKS oferuje ci 2 poziomy skalowania:

• pod scalling, czyli jak zostają spełnione jakieś kryteria, to podnoszone są kolejne instancje podów, lub są ubijane (działa szybko, jak to start kontenera)
• node scalling - jeżeli pody wysycą dostępną wydajność, to uruchamiane są kolejne instancje VM i dodawane do node pool (działa wolno, bo startuje cała VM'ka, z systemem operacyjnym itd. czas liczony w minutach)

Jeżeli masz system działający na ~100 VMkach, a ruch nie jest 0-1, albo jesteś w stanie zaakceptować, że jak pojawi się 1, to trzeba poczekać, będzie OK. Czyli układ taki, że masz jakąś usługę dostępną głównie w PL, w nocy nie korzysta z niej nikt, w cągu dnia musisz obsłużyć tysiące żądań na sekundę, ruch pojawia się stopniowo - w nocy chodzi ci wtedy kilka node'ów, od rana w miarę zwiększania się ruchu będą podnoszone kolejne instancje node'ów i pod'ów, a wieczorem będą one kolejno wygaszane. Wtedy w szczycie będziesz miał przez powiedzmy 15 minut maksymalną liczbę node'ów.
Jedyny problem w powyższym, to że nawet jak nikt nie używa twojego systemu musi istnieć ileś tam pod'ów, które w minimalnej konfiguracji będą potrzebowały przynajmniej 1 VM'ki za którą płacisz, bo jednak sam klaster musi istnieć. Jeżeli mówimy o sensownym wykorzystaniu możliwości Kubernetes, to każdy obraz kontenera powinien mieć przynajmniej 3 instancje (da się ograniczyć do 1, ale niekoniecznie ma to sens).

Podsumowując - dla 20 VM'ki potrzebnej przez 5 minut miesięcznie koszt będzie faktycznie na poziomie tego $0.01, ale dla pierwszej absolutnie nie, bo ona i tak musi chodzić cały czas, chyba, ze zdecydujesz się na ręczne / wymuszone harmonogramem uruchamianie klastra.

W GCP (ale mogę mieć stare informacje) działa to inaczej: Google ma jakąś własną pulę node'ów, za którą nie płacisz, a płacisz tylko za działające pod'y. Czas podniesienia pod'a to sekundy, a pierwsza instancja kiedyś łapała się na warstwę darmową. Czyli W sprzyjających warunkach można było małą aplikację utrzymywać za darmo (przynajmniej jeśli chodzi o moc obliczeniową), a potencjalne zwiększanie mocy klastra było prawie niezauważalne dla użytkownika (zależy głównie od tego jak szybko wystartuje ci to co masz w kontenerze). Specjaliści od security mają lekkie problemy z akceptacją, że aplikacja chodzi na VM, do której nie mają dostępu i nie mogą sprawdzić, czy np. wszystkie poprawki systemu zostały zainstalowane, ale można z tym żyć.