Mapowanie usług kontenerowych AWS do Azure: ECS, Fargate, ECR i ich odpowiedniki
Szybka referencja mapowania usług kontenerowych AWS (ECS, Fargate, ECR, App Runner) na ich odpowiedniki Azure (Container Apps, ACI, ACR, Web App for Containers) z poradami kiedy co stosować.
Jeśli potrzebujesz głębszego porównania z diagramami architektury i analizą strategii wdrożeń, przeczytaj nasz pełny artykuł: porównanie strategii wdrażania kontenerów AWS vs Azure.
Mapowanie
| Usługa AWS | Odpowiednik Azure | Uwagi |
|---|---|---|
| ECS (EC2 launch type) | Azure Container Apps (dedicated plan) | Oba uruchamiają kontenery na zasobach, którymi zarządzasz. Container Apps z dedykowanym profilem workload jest najbliższy ECS na instancjach EC2. |
| ECS (Fargate launch type) | Azure Container Apps (consumption plan) | Kontenery serverless. Brak zarządzania klastrem. Płacisz za vCPU/pamięć na sekundę. Warstwa consumption Container Apps to bezpośredni odpowiednik. |
| Fargate (samodzielnie) | Azure Container Instances (ACI) | Pojedyncze zadania, kontenery krótkotrwałe. ACI mapuje się na Fargate dla zadań wsadowych (batch), kontenerów sidecar i workloadów szczytowych. Nie do długo działających serwisów. |
| ECR (Elastic Container Registry) | ACR (Azure Container Registry) | Prywatne rejestry obrazów kontenerowych. Oba wspierają geo-replikację, skanowanie podatności i artefakty OCI. |
| App Runner | Azure Web App for Containers | Od kodu źródłowego do URL z minimalną konfiguracją. Oba abstrahują warstwę orkiestracji. Najlepsze dla prostych aplikacji webowych i API. |
| EKS (Elastic Kubernetes Service) | AKS (Azure Kubernetes Service) | Zarządzany Kubernetes. Oba obsługują control plane. AKS ma darmową warstwę control plane; EKS pobiera $0.10/godzinę za klaster. |
| App Mesh | Azure Service Mesh (oparty na Istio) | Service mesh do observability i kontroli ruchu. Azure oferuje teraz zarządzane Istio jako dodatek do AKS. |
| Cloud Map | Azure Private DNS + Container Apps service discovery | Odkrywanie serwisów (service discovery) dla kontenerów. Cloud Map jest samodzielny; Azure wbudowuje odkrywanie w Container Apps i AKS natywnie. |
| ECS Service Connect | Wbudowane odkrywanie serwisów Container Apps | Komunikacja serwis-do-serwisu bez pełnego mesh. Oba używają Envoy pod spodem. |
| Copilot CLI | Azure Developer CLI (azd) | Opiniowane narzędzia do wdrożeń. Oba tworzą szkielet infrastruktury i CI/CD z kodu aplikacji. |
Kluczowe różnice, które łamią mapowanie 1:1
Model orkiestracji
AWS rozdziela orkiestrację (ECS) od obliczeń (EC2/Fargate). Wybierasz „launch type” per serwis. Azure łączy oba w Container Apps, gdzie wybierasz typ planu (consumption vs dedicated) na poziomie środowiska, nie per serwis.
Sieć
Taski ECS dostają ENI podpięte do subnetu VPC. Azure Container Apps działają wewnątrz Container Apps Environment, które można wstrzyknąć do VNet, ale używa innego modelu sieciowego (ingress oparty na Envoy, flagi widoczności internal vs external).
Skalowanie
ECS używa Application Auto Scaling z politykami target tracking lub step. Container Apps używają reguł skalowania opartych na KEDA z wbudowanym wsparciem dla współbieżnych żądań HTTP, CPU, pamięci i niestandardowych metryk z dowolnego skalera KEDA.
Model kosztów
| Wymiar | AWS (Fargate) | Azure (Container Apps consumption) |
|---|---|---|
| Obliczenia | za vCPU-sekundę + za GB-sekundę | za vCPU-sekundę + za GiB-sekundę |
| Minimalny czas naliczania | 1 minuta | 0 (skalowanie do zera) |
| Koszt w bezczynności | Działające taski zawsze generują koszty | Skalowanie do zera = zero kosztów w bezczynności |
| Darmowa warstwa | Brak | 180 000 vCPU-sekund/miesiąc za darmo |
Azure Container Apps może skalować się do zera i ma znaczącą darmową warstwę. Fargate zawsze działa (minimum 1 task jeśli serwis jest aktywny).
Drzewo decyzyjne migracji
Twój workload AWS to...
├── Długo działający serwis webowy na ECS/Fargate
│ └── Azure Container Apps (plan consumption lub dedicated)
│
├── Zadanie wsadowe / zaplanowane na Fargate
│ └── Azure Container Instances (ACI) z triggerem Logic Apps
│ LUB Container Apps Job
│
├── Prosta aplikacja webowa na App Runner
│ └── Azure Web App for Containers
│
├── Kubernetes workload na EKS
│ └── AKS (najbardziej przenośne, te same manifesty z drobnymi zmianami)
│
└── Procesor zdarzeń / kolejek na ECS
└── Container Apps z regułą skalowania KEDA
(skaluje do zera przy pustej kolejce)
Częste pułapki
- Tłumaczenie IAM na RBAC. Role tasków ECS mapują się na Azure Managed Identities, nie na role RBAC. Model uprawnień jest fundamentalnie inny.
- Różnice w load balancerach. Funkcje ALB (routing po ścieżkach, weighted targets, slow start) są obsługiwane natywnie przez ingress Container Apps. Nie tworzysz osobnego load balancera.
- Zarządzanie sekretami. ECS pobiera sekrety z Secrets Manager/SSM przy starcie taska. Container Apps odwołują się do sekretów z Azure Key Vault lub sekretów na poziomie środowiska. Mechanizm wstrzykiwania różni się.
- Logowanie. ECS używa CloudWatch Logs z driverem awslogs. Container Apps wysyłają logi do Azure Monitor / Log Analytics domyślnie. Zaplanuj migrację pipeline logów.
- Złożoność service mesh. Jeśli używasz App Mesh, nie zakładaj że potrzebujesz Istio na Azure. Container Apps zapewniają większość funkcji mesh (mTLS, dzielenie ruchu, observability) bez osobnej warstwy mesh.
Weryfikacja
Jeśli oceniasz migrację, zweryfikuj mapowanie na swoich konkretnych workloadach:
# 1. Wylistuj serwisy ECS i ich launch type
aws ecs list-services --cluster twoj-klaster \
--query 'serviceArns[*]' --output table
# 2. Sprawdź alokację zasobów per serwis
aws ecs describe-services --cluster twoj-klaster \
--services twoj-serwis \
--query 'services[*].{name:serviceName,cpu:cpu,memory:memory,launchType:launchType}'
# 3. Zamapuj każdy na odpowiednik Azure używając tabeli powyżej
# Długo działający + Fargate → Container Apps (consumption)
# Długo działający + EC2 → Container Apps (dedicated) lub AKS
# Batch + Fargate → ACI lub Container Apps Job
Dla workloadów EKS migracja jest bardziej bezpośrednia, ponieważ manifesty Kubernetes są w dużej mierze przenośne. Główne zmiany to kontrolery ingress, persistent volume claims (EBS na Azure Disk) i mapowanie IAM na Managed Identity.
Strategie kontenerowe multi-cloud często zaczynają się od „co mapuje się na co”. Ale prawdziwa złożoność tkwi w sieci, IAM i narzędziach operacyjnych. Najpierw ustal prawidłowe mapowanie serwisów, a potem planuj migrację operacyjną osobno.
Planujesz strategię kontenerową multi-cloud?
Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom migrować workloady kontenerowe między AWS i Azure z minimalnym przestojem.