AWS ECS och Fargate: Guide till containerorkestrering 2026

AWS ECS (Elastic Container Service) har under 2026 blivit ett allt populärare val för containerorkestrering – särskilt när det kombineras med Fargate, den serverless compute-motorn som eliminerar behovet av att hantera underliggande EC2-instanser. För svenska företag som redan använder AWS är ECS ofta ett mer kostnadseffektivt och enklare alternativ än Kubernetes, särskilt när teamet saknar dedikerad Kubernetes-kompetens.

Den här guiden ger dig en komplett genomgång av ECS och Fargate – från arkitektur och task definitions till auto-scaling, CI/CD, säkerhet och när du absolut bör välja ECS över EKS. Jag har hjälpt flera organisationer att migrera från EC2-baserade applikationer till ECS med Fargate, och erfarenheten är att övergången ger både lägre driftkostnader och enklare skalning.

ECS vs EKS vs Fargate – vad är skillnaden?

AWS ECS är en fullt hanterad containerorkestrerare som är djupintegrerad med AWS-tjänster som IAM, VPC, CloudWatch, ALB/NLB och Service Discovery. ECS är AWS egen orkestrerare – den använder inte Kubernetes-begrepp utan har egna koncept som task definitions, services och clusters.

AWS EKS (Elastic Kubernetes Service) är en hanterad Kubernetes-tjänst som är kompatibel med standard Kubernetes API. EKS är rätt val om du redan använder Kubernetes, har K8s-specifik kompetens i teamet, eller använder Kubernetes-ekosystem som Helm, Istio, ArgoCD och Kustomize. EKS är generellt dyrare än ECS på grund av EKS-kontrollplanet som kostar 0,10 USD/timme (72 USD/månad).

AWS Fargate är en serverless compute-motor som kan användas med både ECS och EKS. Med Fargate slipper du hantera EC2-instanser, skalning av instanser och OS-uppdateringar – du definierar dina containers som task definitions och Fargate kör dem. ECS med Fargate är den enklaste och mest AWS-nativa containerlösningen, medan ECS med EC2 (EC2 launch type) ger dig mer kontroll över compute och lägre kostnad vid hög och stabil belastning.

Task Definitions – hjärtat i ECS

En ECS task definition är en JSON-mall som beskriver hur en container (eller flera containers) ska köras. Den innehåller: container-image (från ECR eller Docker Hub), CPU och minne (256 CPU units = 0,25 vCPU, 512 MB – 4 vCPU / 30 GB för Fargate), port mappings, miljövariabler, secrets, volymer, IAM-roll (task role), logging (CloudWatch), hälsokontroller och startordning mellan containers.

Fargate task definitions använder enhetlig CPU/minne-kombination: 256 (.25 vCPU) / 512 MB, 512 (.5 vCPU) / 1–4 GB, 1024 (1 vCPU) / 2–8 GB, 2048 (2 vCPU) / 4–16 GB, 4096 (4 vCPU) / 8–30 GB. Välj CPU/minne baserat på din containers resursbehov – övervaka med CloudWatch Container Insights för att se faktisk användning och justera vid behov.

Använd flera containers i samma task definition för sidecar-mönstret – till exempel en appcontainer + en loggningsagent (FireLens/Fluentd) + en metrics-agent. Containers i samma task delar samma nätverk (localhost) och kan kommunicera via portar. Detta är smidigare än att sätta upp service mesh för enkla sidecar-behov.

ECS Services – kör och underhåll dina tasks

En ECS Service hanterar livscykeln för dina tasks – den ser till att rätt antal tasks körs, startar om tasks som kraschar, och hanterar deployment updates. Du konfigurerar: task definition (vilken version), desired count, deployment type (rolling update eller blue/green via CodeDeploy), load balancer (ALB/NLB), auto-scaling, och hälsoövervakning.

Rolling update är standard – ECS startar gradvis nya tasks och stoppar gamla, med konfigurerbara parametrar för minimum/maximum healthy percentage och deployment circuit breaker. Blue/green deployment via CodeDeploy ger dig möjlighet att testa den nya versionen (green) innan du växlar trafik från den gamla (blue) – rekommenderas för produktionskritiska tjänster.

ECS Services kan vara bakom en Application Load Balancer (ALB) för HTTP/HTTPS-trafik eller Network Load Balancer (NLB) för TCP/UDP-trafik. ALB stöder path-based routing, host-based routing, och WebSockets. NLB är bättre för högpresterande UDP eller när du behöver statiska IP-adresser. Du kan också använda ECS Service Connect för intern service discovery utan load balancer.

Auto-scaling i ECS

ECS auto-scaling använder Application Auto Scaling med CloudWatch metrics för att justera antalet tasks baserat på belastning. De vanligaste metricsen är CPUUtilization, MemoryUtilization och ALBRequestCountPerTarget. Du konfigurerar en scaling policy med min, max och desired capacity – nivåer som spänner från 0 (kan skala ner till noll) till dina önskade maxgränser.

Target tracking-scaling är enklast: du anger ett målvärde (t.ex. CPUUtilization = 70%) och ECS justerar automatiskt antalet tasks för att hålla det värdet. Step scaling ger dig mer kontroll med olika steg – till exempel: lägg till 2 tasks om CPU > 80%, lägg till 4 tasks om CPU > 90%. Scheduled scaling är användbart för kända trafikmönster som kontorstid eller Black Friday.

För att undvika scaling-trashing (konstant upp/ner), konfigurera cooldown-perioder mellan scaling-aktiviteter. Använd ECS Service Auto Scaling med CloudWatch för att övervaka anpassade metrics från din applikation – till exempel antalet aktiva användare, kölängd i SQS eller applikationsspecifik latens.

Service Discovery och nätverk

ECS Service Connect är AWS hanterade service discovery för ECS-tjänster. Det skapar en namespace (AWS Cloud Map) och låter tasks kommunicera med varandra via logiska tjänstenamn som `http://my-service:8080` i stället för att hantera IP-adresser och portar manuellt. Service Connect är enklare och mer AWS-nativt än att sätta upp Consul eller Kubernetes DNS.

För intern trafik mellan ECS-tjänster: använd Service Connect eller ALB/NLB internt. För extern trafik: använd ALB/NLB med internet-facing, eller API Gateway framför ALB för mer avancerad API-hantering (rate limiting, autentisering, versionering). Varje task får en privat IP i ditt VPC – säkerställ att security groups är konfigurerade för att tillåta trafik mellan tjänster och från load balancers.

ECS tasks i Fargate använder AWS awsvpc network mode – varje task får en egen ENI (Elastic Network Interface) med egen privat IP och security groups. Detta ger bättre isolering och säkerhet jämfört med bridge network mode (EC2). Du kan också använda ECS tasks utan VPC (för enkla batch-jobb) men för de flesta applikationer rekommenderas VPC-anslutning.

CI/CD för ECS

CI/CD för ECS följer samma mönster som för andra containerbaserade applikationer med några ECS-specifika steg. En typisk pipeline: koda -> bygg Docker-image -> push till ECR -> uppdatera ECS service med ny task definition. AWS CodePipeline + CodeBuild är den mest AWS-nativa lösningen, men GitHub Actions, GitLab CI och Jenkins fungerar utmärkt.

För att uppdatera en ECS service använder du `aws ecs update-service --force-new-deployment` med en ny task definition image-tagg. Använd image tagging-strategi som `git-commit-sha` eller `build-number` för att spåra vilken kod som körs i produktion – undvik `latest`-taggen eftersom den gör det omöjligt att veta vilken version som körs.

Integrera ECS-deployment med CodeDeploy för blue/green-deployments. CodeDeploy skapar en ny task set (green), väntar på hälsokontroller, och skiftar trafik gradvis från den gamla (blue). Om hälsokontrollerna misslyckas, rullar CodeDeploy automatiskt tillbaka. Detta är branschstandard för produktionskritiska ECS-tjänster.

Övervakning och logging

CloudWatch Container Insights ger detaljerad övervakning för ECS-kluster, tjänster och tasks – inklusive CPU, minne, nätverk och disk-I/O per task och per container. Container Insights samlar också in metrics som task count, service count, och deployment-status. Aktivera Container Insights per kluster – kostar en mindre summa men ger ovärderlig insyn.

ECS tasks kan skicka loggar till CloudWatch Logs via awslogs-logging-drivern i task definitionen. För avancerad logganalys: använd FireLens (Fluent Bit) för att skicka loggar till OpenSearch, S3, Kinesis eller tredjeparts-lösningar som Datadog eller Grafana Loki. Varje task skapar en log stream – använd structured logging (JSON) för att effektivt söka och filtrera i CloudWatch Logs Insights.

För distribuerad tracing: använd AWS X-Ray tillsammans med ECS. X-Ray spårar anrop genom hela din applikation – från ALB till ECS-task till RDS eller DynamoDB. Integrera X-Ray SDK i din applikation för att skicka trace-data. X-Ray är ovärderligt för att identifiera flaskhalsar och felsöka prestandaproblem i distribuerade system.

Säkerhet för ECS

Varje ECS task kan ha en IAM-task role som ger containern åtkomst till AWS-tjänster (S3, DynamoDB, SQS, etc). Följ principen om least privilege – varje task ska ha en egen roll med endast nödvändiga behörigheter. Använd IAM Access Analyzer för att granska och optimera task roller över tid.

Secrets och miljövariabler: lagra känslig information (API-nycklar, databaslösenord) i AWS Secrets Manager eller Parameter Store och referera dem i task definitionen via `secrets`-nyckeln. Använd KMS-kryptering för secrets och miljövariabler i vila. Aktivera översyn av container-images med Amazon Inspector (kontinuerlig sårbarhetsskanning).

Använd ECS Exec för att få shell-åtkomst till en task i produktion för felsökning – detta är säkrare än att SSH:a in i en container eftersom det använder IAM-autentisering och granskas via CloudTrail. För compliance: aktivera CloudTrail för alla ECS API-anrop och granska regelbundet task definitioner och tjänstkonfigurationer.

Prisjämförelse: ECS Fargate vs EC2 vs EKS

ECS Fargate: du betalar per vCPU och GB-minne per sekund (minsta debitering 30 sekunder). För en task med 1 vCPU och 2 GB minne: ca 0,04 USD/timme. Fargate är dyrast per compute-enhet men billigast i drift eftersom du inte betalar för hantering av EC2-instanser eller överkapacitet.

ECS EC2: du betalar för EC2-instanserna (t.ex. t3.medium ca 0,04 USD/timme) plus ECS-kontrollplanet (gratis). För att hantera 10 tasks med 1 vCPU var kan du behöva 3–4 EC2-instanser plus extra kapacitet för failover. EC2 är billigast per compute-enhet men kräver mer operationell overhead.

EKS Fargate: samma Fargate-pris som ECS plus EKS-kontrollplanet (0,10 USD/timme = 72 USD/månad). EKS EC2: EC2-instanser + 72 USD/månad för kontrollplanet. EKS är betydligt dyrare än ECS för mindre kluster, men prisskillnaden minskar i stor skala. För team som redan kan Kubernetes är EKS ofta värt extra kostnaden för tillgången till K8s-ekosystemet.

När väljer du ECS över Kubernetes?

ECS är rätt val när: du redan använder AWS och vill ha djup integration med IAM, VPC, CloudWatch och ALB. Ditt team har inte dedikerad Kubernetes-kompetens. Du vill ha minimal operationell overhead – ECS med Fargate är nästan serverless. Du har enklare containeriserade applikationer (en eller få tjänster, inget behov av Helm, Istio eller Kubernetes-specifika verktyg).

Kubernetes (EKS) är rätt val när: du redan använder Kubernetes på andra platser eller har K8s-specifik kompetens. Du behöver portabilitet mellan molnleverantörer eller on-prem. Du använder Kubernetes-ekosystem som Istio, Helm, ArgoCD, Kustomize, och Knative. Du har mycket komplexa arbetsbelastningar med avancerade nätverkskrav, multi-tenant orkestrering eller GPU-schemaläggning.

ECS stöder cirka 80–90% av containerorkestreringsbehoven för de flesta organisationer. Kubernetes är kraftfullare men komplexiteten är betydande – enligt branschstudier spenderar organisationer i genomsnitt 30–40% av tiden bara på att hantera Kubernetes-infrastrukturen. Välj enklast möjliga alternativ som löser ditt problem.

Sammanfattning: ECS och Fargate best practices

1. Börja med Fargate i stället för EC2 launch type – minskar driftkomplexitet och ger bättre isolering.
2. Använd ECS Service Connect för intern service discovery – enklare och billigare än ALB/NLB internt.
3. Konfigurera target tracking auto-scaling med CPUUtilization ~70% – det täcker de flesta behov.
4. Använd blue/green-deployment via CodeDeploy för produktionskritiska tjänster.
5. Använd separata task-roller per service med least privilege och Secrets Manager för känslig data.
6. Aktivera CloudWatch Container Insights och X-Ray för övervakning och distribuerad tracing.
7. Använd CloudWatch Alarms för ECS metrics som CPU- och minnesanvändning, service count och task count.
8. Optimera task definition CPU/minne baserat på faktisk användning från Container Insights.
9. Använd ECS Exec för felsökning i produktion i stället för SSH.
10. Jämför kostnader mellan Fargate, EC2 och EKS baserat på dina specifika workloads.

Vill du ha hjälp med AWS ECS och Fargate?

Jag hjälper företag att containerisera applikationer och driftsätta med ECS och Fargate. Läs mer om moln- och infratjänster eller boka ett samtal.