Managerad EKS kontra självförvaltad EKS: en ärlig jämförelse

Poängen är inte att intern kompetens saknar värde – tvärtom. Men Kubernetes-drift är ett specialistområde som kräver kontinuerlig uppmärksamhet. Enligt Flexeras State of the Cloud-rapport är brist på molnkompetens konsekvent en av de tre största utmaningarna organisationer rapporterar. En managerad tjänst frigör dina utvecklare att fokusera på applikationslogik istället för infrastrukturproblem.

Hur Opsio konfigurerar och driftar EKS-kluster

Grundarkitektur i eu-north-1

Vi utgår från AWS Well-Architected Framework och konfigurerar EKS-kluster med följande standardarkitektur:

• Multi-AZ-deployment i eu-north-1 (Stockholm) med arbetsnoder spridda över minst tre tillgänglighetszoner
• Privata subnät för pods och arbetsnoder, med publika subnät enbart för ALB/NLB ingress
• Karpenter som nodprovisionerare – ersätter Cluster Autoscaler med snabbare och mer kostnadseffektiv skalning
• Spot-instanser för stateless arbetsbelastningar, med on-demand fallback för kritiska tjänster
• EKS Pod Identity istället för äldre IRSA-kopplingar, för renare IAM-integration
• Secrets Manager eller External Secrets Operator för hemlighetshantering – aldrig klartext i ConfigMaps

Säkerhet och efterlevnad

NIS2-direktivet, som trädde i kraft 2024 och nu genomförs i nationell lagstiftning, ställer explicita krav på incidentrapportering inom 24 timmar, supply chain-säkerhet och dokumenterade säkerhetsprocesser. Det påverkar direkt hur vi konfigurerar EKS:

• Audit-loggning aktiveras för API-servern och dirigeras till CloudTrail och CloudWatch Logs med retention enligt krav
• Pod Security Standards tillämpas i restricted-läge som standard
• Image scanning via Amazon ECR med automatisk blockering av images med kända CVE:er
• Network Policies via Cilium för mikrosegmentering mellan namnområden
• Krypterad etcd – aktiveras automatiskt i EKS, men vi verifierar att envelope encryption med KMS är konfigurerad

GDPR kräver dessutom att persondata som passerar klustret skyddas med åtkomstkontroll och loggas korrekt. Vi konfigurerar Kubernetes RBAC så att utvecklarteam enbart har åtkomst till sina egna namnområden, och all åtkomst auditeras.

Molnsäkerhet

24/7-övervakning från SOC/NOC

Opsios SOC/NOC i Karlstad och Bangalore bevakar EKS-kluster dygnet runt. Vår övervakningsstack inkluderar:

• Prometheus + Grafana för realtidsmetriker på pod-, nod- och klusternivå
• Alertmanager med konfigurerade eskaleringskedjor – larm som inte åtgärdas inom SLA eskaleras automatiskt
• Falco för runtime-säkerhetsdetektering – upptäcker avvikande beteende i containrar, exempelvis oväntade processer eller nätverksanrop
• Flux CD eller ArgoCD för GitOps-baserade deployments med automatisk drift-detection

Vi ser regelbundet att organisationer sätter upp övervakning initialt men aldrig uppdaterar larmtrösklar eller eskaleringsrutiner. Resultatet är alert fatigue – hundratals larm som ingen agerar på. Vår approach är att kontinuerligt trimma larmregler baserat på faktiska incidentmönster.

Managerad DevOps

Kostnadsoptimering: FinOps för EKS

Kubernetes-kluster har en tendens att växa okontrollerat. Pods begär resurser med generösa marginaler, noder körs underutnyttjade och orphaned resurser ackumuleras. Flexeras State of the Cloud har konsekvent visat att molnkostnadshantering är den absolut största utmaningen för organisationer – och Kubernetes-miljöer är inget undantag.

Vår FinOps-process för EKS inkluderar:

1. Rightsizing av requests och limits – vi analyserar faktisk CPU- och minnesanvändning och justerar pod-specifikationer

2. Karpenter-optimering – konfiguration av consolidation policies som automatiskt migrerar pods till färre, bättre utnyttjade noder

3. Spot-strategi – diversifiering över flera instanstyper och tillgänglighetszoner för att minimera avbrott

4. Namespace-baserad kostnadsallokering – med Kubecost eller OpenCost får varje team insyn i sina faktiska kostnader

5. Savings Plans – reserverade kapacitetsavtal för baslast, kompletterade med Spot för variabel last

Kombinationen av dessa åtgärder ger typiskt en kostnadsreduktion på 30–50 % jämfört med en EKS-miljö som körts utan aktiv optimering.

Cloud FinOps

Migrering till EKS: praktiska steg

Att flytta befintliga applikationer till EKS kräver mer än att bara containerisera och deploya. Vår migreringsmetodik följer dessa faser:

1. Discovery och assessment – kartläggning av befintliga applikationer, beroenden, dataflöden och prestandakrav

2. Containeriseringsstrategi – beslut om vilka applikationer som ska containeriseras direkt, vilka som behöver refaktorisering och vilka som bör stanna kvar utanför Kubernetes

3. Plattformsuppbyggnad – IaC-baserad (Terraform) uppsättning av EKS-kluster, nätverk, observerbarhet och CI/CD-pipelines

4. Applikationsmigrering – iterativ flytt med canary deployments och parallellkörning

5. Optimering och överlämning – prestandatrimning, dokumentation och kunskapsöverföring

Vi avråder från "big bang"-migreringar. Varje applikation migreras individuellt med tydliga rollback-kriterier. Erfarenheten visar att en kontrollerad, iterativ approach halverar risken för produktionsincidenter under migreringen.

Molnmigrering

När EKS inte är rätt val

Vi skulle inte vara trovärdiga om vi inte sa det rakt ut: EKS passar inte alla. Om din organisation har en handfull enkla webbtjänster utan krav på horisontell skalning, kan AWS ECS med Fargate eller till och med AWS Lambda vara ett bättre alternativ – enklare att drifta och lägre operativ overhead.

EKS motiveras när du har:

• Tiotals till hundratals mikrotjänster som behöver orkestreras
• Krav på portabilitet mellan molnleverantörer (Kubernetes är leverantörsoberoende i sin kärna)
• Team som redan arbetar med containeriserade arbetsbelastningar
• Avancerade deploymentmönster som canary, blue-green eller progressive delivery
• Behov av finkornig resurskontroll och namnområdesbaserad multitenancy

Vanliga frågor

Vad är skillnaden mellan Amazon EKS och managerad EKS från en MSP?

Amazon EKS är AWS:s tjänst som hanterar Kubernetes kontrollplan. En managerad EKS-tjänst från en MSP som Opsio tar helhetsansvar – inklusive arbetsnoder, nätverkskonfiguration, säkerhetshärdning, patchning, övervakning och incidenthantering. Du får en produktionsklar plattform utan att behöva bygga intern Kubernetes-kompetens.

Vilka arbetsbelastningar passar bäst för EKS?

EKS lämpar sig för mikrotjänstarkitekturer, API-gateways, ML-inferens, batchbearbetning och applikationer som kräver horisontell autoskalning. Monolitiska applikationer utan containerstrategi bör moderniseras innan de flyttas till EKS.

Hur påverkar NIS2 och GDPR konfigurationen av EKS-kluster?

NIS2 kräver dokumenterad incidenthantering, loggning och supply chain-säkerhet. GDPR ställer krav på dataminimering och åtkomstkontroll. I praktiken innebär det krypterade secrets, nätverkspolicyer, audit-loggning till CloudTrail/CloudWatch och strikt RBAC – konfigurationer som många missar vid initial uppsättning.

Vad kostar managerad EKS?

AWS tar ut en fast avgift per EKS-kluster (cirka 0,10 USD/timme) plus kostnaden för compute (EC2 eller Fargate). Den managerade tjänsten från Opsio adderar ett driftabonnemang som inkluderar övervakning, patchning och incidenthantering – typiskt betydligt billigare än att anställa dedikerade Kubernetes-ingenjörer internt.

Kan vi köra EKS i eu-north-1 (Stockholm) för att uppfylla svenska datakrav?

Ja. EKS är fullt tillgängligt i eu-north-1. Vi rekommenderar den regionen som standard för svenska organisationer som behöver dataresidenskrav. Multi-region-setup mot eu-west-1 (Irland) kan konfigureras för disaster recovery.