Zrozumienie kosztów transferu danych dla usług kontenerowych AWS

Wstęp

Koszty transferu danych mogą odgrywać znaczącą rolę w określaniu ogólnego projektu systemu. Usługi Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Container Service (Amazon ECS), oraz Amazon Elastic Kubernetes Service (Amazon EKS) mogą wiązać się z opłatami za transfer danych w zależności od różnych czynników. Może być trudno wyobrazić sobie, co to oznacza w odniesieniu do wdrożenia Amazon ECS lub Amazon EKS. Ten post obrazuje typowe wzorce wdrażania usług kontenerowych AWS i wyjaśnia wynikające z tego opłaty za transfer danych, które mogą zostać poniesione.

Amazon ECR

Istnieją dwa rodzaje rejestrów Amazon ECR — typu public i private — a każdy z nich ma inne opłaty za transfer danych.

Rejestr Amazon ECR Public

Amazon ECR Public to zarządzana usługa rejestru obrazów kontenerów AWS, która jest bezpieczna, skalowalna i niezawodna. Amazon ECR obsługuje publiczne repozytoria obrazów z uprawnieniami opartymi na zasobach przy użyciu AWS Identity and Access Management (IAM), dzięki czemu poszczególni użytkownicy mogą uzyskać dostęp do publicznych repozytoriów w celu przesyłania obrazów. Deweloperzy mogą używać preferowanego interfejsu wiersza poleceń (CLI) do przesyłania i zarządzania obrazami platformy Docker, obrazami Open Container Initiative (OCI) oraz artefaktami zgodnymi z OCI. Obrazy są publicznie dostępne do pobrania, anonimowo lub za pośrednictwem tokena uwierzytelniania Amazon ECR Public.

Wszystkie dane przesyłane do Amazon ECR Public nie podlegają opłatom ze strony Amazon ECR. Przesyłane dane podlegają opłatom, gdy więcej niż 5 TB miesięcznie jest przesyłanych do miejsc docelowych innych niż AWS, a użytkownik został uwierzytelniony w Amazon ECR za pomocą konta AWS. Limit miesięczny danych wynosi 500 GB, które można anonimowo przenieść do miejsc docelowych innych niż AWS do klientów, którzy nie zostali uwierzytelnieni. Po osiągnięciu tego limitu dalsze anonimowe przesyłanie danych nie jest dozwolone.

Rysunek 1. Rejestr Amazon ECR Public

Rejestr Amazon ECR Private

Rejestr Amazon ECR Private przechowuje obrazy kontenerów w wysoce dostępnej i skalowalnej architekturze. Za pomocą rejestru Amazon ECR Private można zarządzać prywatnymi repozytoriami obrazów składającymi się z obrazów i artefaktów Docker i OCI.

Dane przesyłane do prywatnego rejestru Amazon ECR nie podlegają opłatom ze strony Amazon ECR. Dane przesyłane między Amazon ECR a innymi usługami w tym samym regionie są bezpłatne. Dane przesyłane między Amazon ECR a innymi usługami w różnych regionach są rozliczane według stawek za transfer danych internetowych po obu stronach transferu. Należy pamiętać, że jest to agregowane z innymi wychodzącymi transferami danych w wielu usługach, a poziomy stawek są stosowane na podstawie ilości przesyłanych danych.

Rysunek 2. Rejestr Amazon ECR Private

Amazon ECR oferuje wbudowaną funkcjonalność do replikowania obrazów kontenerów do różnych lokalizacji. Może to być przydatne do celów odzyskiwania po awarii, pipeline’u promote-to-production oraz redukcji image pull time i kosztów transferu danych podczas uruchamiania kontenerów w różnych regionach. Ten transfer danych jest rozliczany według stawek transferu danych między regionami opisanych na stronie Amazon Elastic Compute Cloud (Amazon EC2) On-Demand Pricing.

Więcej informacji można znaleźć na stronach Amazon ECR Pricing i Amazon EC2 On-Demand Pricing.

Transfer danych do usługi Amazon ECS

Trzy popularne modele wdrażania dla Amazon ECS to Amazon ECS Anywhere, klastry z dostępem do sieci zewnętrznej i klastry bez dostępu do sieci zewnętrznej.

Amazon ECS Anywhere

Amazon ECS Anywhere to funkcja Amazon ECS, która umożliwia łatwe uruchamianie i zarządzanie aplikacjami opartymi na kontenerach typu on premises, w tym na własnych maszynach wirtualnych (VM) i serwerach typu bare-metal. Dzięki Amazon ECS Anywhere nie musisz instalować ani obsługiwać lokalnego oprogramowania do orkiestracji kontenerów, co zmniejsza koszty operacyjne. Amazon ECS Anywhere oferuje w pełni zarządzane rozwiązanie, które umożliwia standaryzację zarządzania kontenerami we wszystkich środowiskach.

Opłaty za transfer danych są naliczane na podstawie sposobu, w jaki infrastruktura zarządzana przez klienta łączy się z warstwą sterowania Amazon ECS Anywhere. W przypadku połączenia przez Internet (Rysunek 3) nie ma opłat za transfer danych, gdy komunikacja odbywa się między warstwą kontroli Amazon ECS Anywhere a agentem Amazon ECS.

Rysunek 3. Komunikacja Amazon ECS Anywhere przez Internet

W przypadku łączenia się przez AWS Site-to-Site VPN lub AWS Direct Connect (Rysunek 4), standardowe opłaty za transfer danych mają zastosowanie do Site-to-Site VPN lub Direct Connect, gdy następuje komunikacja między warstwą sterowania Amazon ECS Anywhere i agentem Amazon ECS za pośrednictwem Site-to-Site VPN lub łącza Direct Connect.

Rysunek 4. Amazon ECS Anywhere z AWS Direct Connect

Więcej informacji można znaleźć na stronach Amazon ECS Anywhere Pricing, AWS Site-to-Site VPN Pricing, and AWS Direct Connect Pricing. 

Klastry Amazon ECS z dostępem zewnętrznym

Przepustowość obliczeniową instancji kontenerów w Amazon ECS można wdrożyć w ramach wirtualnych chmur prywatnych (VPC), które umożliwiają dostęp do punktu końcowego usługi Amazon ECS za pośrednictwem Internetu. Na przykład moc obliczeniowa instancji kontenera może być wdrożona w publicznych podsieciach (z bramą internetową) lub prywatnych (z bramą a NAT gateway — jak pokazano na rysunku 5) lub może kierować do Internetu przez inny VPC, taki jak Amazon Virtual Private Cloud (Amazon VPC), wykorzystująca AWS Transit Gateway. Zarówno usługa Amazon EC2, jak i AWS Fargate mogą być wykorzystywane jako platformy w tego typu wdrożeniu i nie ma różnicy w kosztach transferu danych w zależności od wybranej usługi.

Rysunek 5. Wdrożenie Amazon ECS z dostępem do internetu

Następujące transfery danych nie są naliczane w przykładowym wdrożeniu:

• Dane przesyłane z warstwy kontrolnej Amazon ECS (odpowiedzi na wywołania API z płaszczyzny danych) i Amazon ECR (pobieranie obrazu)
• Komunikacja między taskami a modułem Application Load Balancer (zakładając, że cele są dostępne w każdej strefie dostępności i unikają równoważenia obciążenia między strefami)
• Komunikacja między taskami a instancją bazy danych w tej samej Strefie Dostępności

W tym wdrożeniu opłaty za transfer danych są naliczane za:

• Dane przesyłane przez bramę NAT, w tym ruch odpytujący od agenta Amazon ECS do warstwy kontrolnej Amazon ECS i dane wychodzące do Amazon ECR
• Ruch między strefami dostępności do bazy danych

Należy zauważyć, że chociaż brama NAT nie pobiera opłat za przesyłane dane, nadal istnieje opłata za przetwarzanie danych za gigabajt danych przepływających przez bramę NAT, niezależnie od kierunku. Opłaty za transfer danych są dodatkiem do tej opłaty. Cennik bramy NAT można znaleźć na stronie Amazon VPC Pricing.

Klastry Amazon ECS bez zewnątrznego dostępu

Innym powszechnym wzorcem wdrażania workload’ów Amazon ECS jest ograniczenie dostępu do sieci zewnętrznej (Rysunek 6). Ponieważ instancje kontenerów w klastrach Amazon ECS wymagają dostępu do sieci zewnętrznej, aby komunikować się z punktem końcowym usługi Amazon ECS, do komunikacji z punktami końcowymi usługi musi być używany AWS PrivateLink.

Ponownie, zarówno Amazon EC2, jak i Fargate mogą być wykorzystywane jako platforma w tego typu wdrożeniu. Istnieje jednak różnica w kosztach transferu danych w zależności od tego, która usługa jest wybierana.

Następujące transfery danych nie są naliczane w przykładowym wdrożeniu:

• Komunikacja między taskami a Application Load Balancer
• Komunikacja między taskami a instancją bazy danych w tej samej Strefie Dostępności

W tym wdrożeniu opłaty za transfer danych są naliczane za ruch między strefami dostępności do bazy danych.

Diagram przedstawia punkty końcowe interfejsu Amazon ECS i Amazon ECR PrivateLink VPC jako pojedyncze obiekty. Jednak w rzeczywistości dla każdego wymagane jest wiele punktów końcowych. Opis wymagań dotyczących punktów końcowych można znaleźć na blogu AWS Compute lub w dokumentacji Amazon ECS i Amazon ECR.

Rysunek 6. Wdrożenie Amazon ECS w sieci prywatnej

Chociaż nie ma opłaty za transfer danych, PrivateLink nakłada zarówno opłatę za godzinę usługi, jak i opłatę za przetwarzanie danych za gigabajt danych przetwarzanych przez każdy punkt końcowy VPC, rozliczane według strefy dostępności. Więcej szczegółów można znaleźć na stronie AWS PrivateLink Pricing.

Korzystanie z AWS Fargate w prywatnych klastrach Amazon ECS

Jeśli usługa Fargate zapewnia moc obliczeniową dla klastra Amazon ECS, punkty końcowe PrivateLink dla Amazon ECS nie są wymagane. Pozwala to pozbyć się opłat godzinowych i opłat za przetwarzanie danych za komunikację z punktem końcowym usługi Amazon ECS. Pamiętaj, że punkty końcowe PrivateLink VPC dla Amazon ECR nadal są wymagane do pobierania obrazów z Amazon ECR.

Transfer danych dla Amazon EKS

Podobnie jak w przypadku Amazon ECS, opłaty za transfer danych Amazon EKS są zgodne z wytycznymi opisanymi na stronie z cennikiem Amazon EC2. Rysunek 7 przedstawia przykładowy workload Amazon EKS z dwoma podami wdrożonymi w różnych węzłach roboczych Amazon EKS w różnych strefach dostępności.

W tym przykładzie następujące transfery danych nie są naliczane:

• Ruch do i z warstwy kontrolnej (nie pokazano na schemacie)
• Pobieranie obrazu z Amazon ECR (nie pokazano na schemacie)
• Komunikację między podami a Application Load Balancer
• Komunikację między podami a instancją bazy danych w tej samej strefie dostępności

W tym przykładzie naliczono opłaty za transfery danych:

• Transfer danych między podami Kubernetes’a a bazą danych w innej strefie dostępności
• Dane wychodzące (egress) z modułu Application Load Balancer
• Komunikację między podami w różnych Strefach Dostępności

Rysunek 7. Przykładowe zastosowanie wdrożenia Amazon EKS

There are several other configuration options and deployment strategies to consider in an Amazon EKS deployment relative to data transfer costs, such as cluster access (public or private), pod-to-pod communication, and communication between the pods and the load balancer.

Istnieje kilka innych opcji konfiguracji i strategii wdrażania, które należy wziąć pod uwagę we wdrożeniu Amazon EKS w odniesieniu do kosztów transferu danych, takich jak dostęp do klastra (publiczny lub prywatny), komunikacja pod-to-pod oraz komunikacja między podami i modułem load balancer.

Publiczne klastry Amazon EKS

Publiczne klastry Amazon EKS (rysunek 8) mają włączony dostęp do publicznego punktu końcowego i wyłączony prywatny punkt końcowy. Komunikacja między warstwą sterowania a węzłami roboczymi wychodzi z VPC na podstawie routingu VPC. W przypadku węzłów roboczych w prywatnych podsieciach komunikacja przechodzi przez bramę NAT i wychodzi przez bramę internetową. Nie jest z tym związana opłata za transfer danych. Istnieje jednak opłata za przetwarzanie danych przez bramę NAT za gigabajt. Ponadto węzły robocze, które nie znajdują się w tej samej strefie dostępności co brama NAT, ponoszą opłatę za transfer danych za gigabajt za ruch w różnych strefach dostępności. W przypadku węzłów roboczych w podsieciach publicznych komunikacja opuszcza bramę internetową i nie jest naliczana opłata.

Rysunek 8. Publiczny klaster Amazon EKS

Prywatne klastry Amazon EKS

W klastrze z prywatnymi punktami końcowymi Amazon EKS (Rysunek 9), węzły robocze komunikują się z prywatnymi punktami końcowymi. Adres URL punktu końcowego serwera interfejsu Kubernetes API jest rozpoznawany jako elastyczne interfejsy sieciowe w ramach VPC. Węzły robocze wewnątrz VPC komunikują się z tymi interfejsami sieciowymi. W tym modelu wdrażania istnieje prawdopodobieństwo, że węzeł roboczy komunikuje się z interfejsem sieciowym w innej strefie dostępności. Komunikacja ta podlega opłacie za transfer danych w różnych strefach dostępności.

Rysunek 9. Prywatny klaster Amazon EKS

Komunikacja pod-to-pod

Aplikacje Kubernetes często korzystają z komunikacji między kontenerami i podami (rysunek 10).

Kontenery w tym samym podzie mają gwarancję, że znajdują się w tym samym węźle i komunikują się za pośrednictwem urządzenia pętli zwrotnej, co skutkuje brakiem opłat za transfer danych. Opłaty za transfer danych między podami zależą od umiejscowienia podów:

• Nie ma opłaty za transfer danych dla podów wdrożonych w tym samym węźle lub w tej samej strefie dostępności
• Pody, które komunikują się i są umieszczone w różnych strefach dostępności, podlegają opłacie za transfer danych

Rysunek 10. Komunikacja pod-to-pod

Komunikacja Load balancer-to-pod

Workloady Amazon EKS często zawierają moduł load balancera, który równomiernie rozprowadza ruch w podach. Pody są wdrażane razem z obiektami Kubernetes Service i Ingress. Dodatek AWS Load Balancer Controller monitoruje te obiekty i automatycznie udostępnia zasoby modułu AWS load balancera. Ścieżka ruchu i wynikające z niej opłaty za transfer danych zależą od konfiguracji obiektów Service i Ingress. Istnieją dwie popularne metody konfiguracji.

Pierwsza metoda polega na posiadaniu grupy docelowej, która składa się ze wszystkich węzłów roboczych w klastrze (Rysunek 11). Ta grupa obejmuje Service: LoadBalancer, Service: NodePort i Ingress TargetType: instance. W tym przypadku port efemeryczny (NodePort) jest otwierany na każdym węźle w klastrze, a ruch jest równomiernie rozprowadzany we wszystkich węzłach. Jeśli docelowy pod znajduje się w węźle, nie następuje żaden dodatkowy transfer danych. Jeśli pod docelowy jest uruchomiony w innym węźle, opłaty za transfer danych mogą zostać naliczone, jeśli pod docelowy znajduje się w innej strefie dostępności.

Rysunek 11. Komunikacja Load balancer-to-pod za pomocą TargetType: instance

Druga metoda obejmuje grupę docelową składającą się z adresów IP podu (Rysunek 12). W tej metodzie cele load balancera to adresy IP podów. Komunikacja omija kube-proxy i kieruje ją bezpośrednio do podu, utrzymując ruch w tej samej strefie dostępności i unikając opłat za transfer danych.

Rysunek 12. Komunikacja load balancer-to-pod za pomocą TargetType: IP

Wskazówki

Poniżej znajdują się wskazówki, jak uniknąć nadmiernych opłat za transfer danych i przetwarzanie danych w workloadach kontenera:

• Dodatkowe komponenty w ścieżce sieciowej, takie jak bramy NAT, PrivateLink lub Transit Gateway, mogą wiązać się z dodatkowymi opłatami za transfer danych lub przetwarzanie danych.
• Sprawdź potencjalne opłaty za transfer danych zarówno u źródła, jak i celu Twojego kanału komunikacji. Pamiętaj, że „data transfer in” do miejsca docelowego to także „data transfer out” ze źródła.
• Jeśli to możliwe, ogranicz transfer danych między regionami. Użyj wbudowanych funkcji replikacji międzyregionalnej Amazon ECR, aby ograniczyć replikację.
• Używaj replikacji danych między regionami, aby replikować obrazy w Amazon ECR do dodatkowych regionów, a następnie pobrać obrazy z regionu lokalnego.
• Spróbuj ograniczyć obrazy kontenerów tylko do niezbędnych elementów wymaganych do uruchomienia workloadu. Obrazy z obcymi plikami binarnymi kosztują więcej do przechowywania i przesyłania, wydłużają czas uruchamiania i zwiększają obszar ataku.
• Określ najbardziej wydajną ścieżkę sieciową dla Twojego ruchu. Na przykład, czy Twoje wymagania wskazują na potrzebę prywatnego klastra bez łączności zewnętrznej? W miarę dodawania kolejnych komponentów sieciowych wzrastają koszty przesyłania danych.
• Rozważ konsolidację punktów końcowych PrivateLink w centralnym VPC połączonym przez bramę tranzytową, opisaną w tym dokumencie AWS PrivateLink.
• W przypadku wdrożenia Amazon ECS bez zewnętrznej łączności sieciowej rozważ użycie Fargate do obsługi kontenerów. Eliminuje to potrzebę korzystania z punktu końcowego PrivateLink dla Amazon ECS.
• W przypadku korzystania z load balancer’a dla workloadu Amazon EKS należy unikać usług NodePort i kierować pody bezpośrednio przy użyciu TargetType opartego na adresie IP dla grup docelowych.

Podsumowanie

Aby określić najbardziej ekonomiczną architekturę dla workloadów opartych na kontenerach, ważne jest, aby zrozumieć, w jaki sposób obliczane są opłaty za transfer danych. Decyzje projektowe związane z wdrażaniem mocy obliczeniowej, dostępem do publicznych usług AWS i ogólną architekturą sieci mają wpływ na opłaty za transfer danych.

Chcesz dowiedzieć się więcej? Zapoznaj się z wpisem nOverview of Data Transfer Costs for Common Architectures, aby dowiedzieć się o opłatach za transfer danych dla popularnych architektur sieciowych, i odwiedź blog AWS Containers, aby uzyskać więcej świetnych treści związanych z kontenerami.

Źródło: AWS