Varför bedömningen är affärskritisk – inte bara teknisk

Flexeras State of the Cloud har konsekvent visat att kostnadshantering och säkerhet är de största utmaningarna för organisationer i molnet. Det överraskande är att de flesta av dessa problem hade kunnat förutses – och undvikas – med en grundligare beredskapsbedömning.

Från Opsios SOC/NOC i Karlstad ser vi mönstret upprepas: organisationer som hoppar över eller hastar igenom bedömningsfasen hamnar i en situation där de sex månader efter migrering kämpar med oväntat höga kostnader, säkerhetsincidenter som beror på felkonfigurerade IAM-roller, och applikationer som presterar sämre i molnet än on-prem.

De tre vanligaste missarna

1. Underskattade licenskostnader. Att flytta en Windows Server med SQL Server Enterprise till EC2 innebär inte automatiskt lägre kostnad. Utan BYOL-avtal (Bring Your Own License) eller licensoptimering kan kostnaden bli mångdubbelt högre. Bedömningen ska innehålla en detaljerad licensinventering.

2. Säkerhet som eftertanke. Vi ser regelbundet organisationer som migrerar först och säkrar sedan. I en svensk kontext, där NIS2-direktivet nu ställer explicita krav på riskhantering och incidentrapportering, är det en riskabel strategi. IMY har visat sig vara aktiva i sin tillsyn, och bristande dataskyddskonsekvensbedömningar vid molnmigrering är en reell risk.

3. Avsaknad av FinOps-tänk. Många organisationer jämför sin nuvarande hostingkostnad med AWS on-demand-priser och drar felaktiga slutsatser – åt båda hållen. En korrekt TCO-analys kräver att du modellerar Reserved Instances, Savings Plans, spot-instanser och den faktiska arbetsbelastningsmixen. Cloud FinOps

Steg-för-steg: Genomföra en AWS-beredskapsbedömning

Steg 1: Definiera mål och scope

Börja med varför. Är drivkraften kostnadsreduktion, skalbarhet, innovation eller ett regulatoriskt krav? Svaret styr bedömningens fokus.

Avgränsa scope: bedömer ni hela IT-miljön eller en specifik affärsenhet? En vanlig strategi är att starta med en avgränsad del – exempelvis en intern applikation med måttlig komplexitet – för att bygga erfarenhet innan kritiska system utvärderas.

Involvera rätt intressenter tidigt. IT-arkitekter, säkerhetsteam, ekonomiansvariga och verksamhetsledare ska alla ha en roll. En bedömning driven enbart av IT missar affärsperspektivet; en driven enbart av ledningen missar tekniska realiteter.

Steg 2: Inventera och kartlägg nuvarande miljö

Använd verktyg som AWS Application Discovery Service, AWS Migration Hub eller tredjepartsalternativ som Cloudamize eller Flexera för att automatisera inventeringen. Manuell inventering fungerar för små miljöer men skalar dåligt.

Kartlägg:

• Alla servrar (fysiska och virtuella), deras konfiguration och utnyttjandegrad
• Applikationer, deras beroenden och dataflöden
• Nätverkstopologi, brandväggsregler och DNS-konfiguration
• Databaser, deras storlek, typ och replikeringsmodell
• Tredjepartsintegrationer och API-beroenden

Steg 3: Bedöm säkerhet och regelefterlevnad

I en svensk kontext innebär detta minst:

• GDPR-analys: Var lagras personuppgifter? Vilka dataflöden korsar gränser? Behöver ni en dataskyddskonsekvensbedömning (DPIA) för migreringen?
• NIS2-bedömning: Om ni är en väsentlig eller viktig entitet enligt NIS2, vilka krav ställer det på er molnarkitektur? Incidentrapportering inom 24 timmar kräver specifik teknisk förmåga.
• Datalokalisering: eu-north-1 (Stockholm) löser den fysiska placeringen, men molntjänster involverar ofta globala kontrollplan. Förstå exakt var metadata och krypteringsnycklar hanteras.

Molnsäkerhet

Steg 4: Kategorisera applikationer med 6 R-modellen

AWS 6 R-modell ger ett ramverk för att avgöra migrationsstrategi per applikation:

Erfarenheten visar att de flesta organisationer initialt överskattar andelen applikationer som lämpar sig för refactor och underskattar andelen som bör avvecklas helt. En ärlig bedömning sparar enorma resurser. Molnmigrering

Steg 5: Modellera kostnader och skapa business case

Använd AWS Pricing Calculator och AWS Migration Evaluator för att skapa en realistisk kostnadsmodell. Jämför inte enbart löpande kostnader – inkludera migreringskostnader, kompetensutveckling, parallellkörningsperioden och eventuella arkitekturförändringar.

En trovärdig TCO-analys bör visa:

• Nuvarande totalkostnad (inklusive dolda kostnader som personal, lokaler, kylning)
• Projicerad AWS-kostnad med specificerad prismodell
• Migreringskostnad (engång)
• Break-even-tidpunkt
• Riskjusterad uppskattning (lägg till 15–25 % marginal för oförutsedda händelser)

Steg 6: Identifiera kompetensgap och organisatorisk beredskap

Molnmigrering misslyckas sällan på grund av teknik – den misslyckas på grund av människor och processer. Bedöm:

• Har teamet erfarenhet av IaC (Terraform, CloudFormation)?
• Finns DevOps- eller SRE-kompetens?
• Hur mogen är CI/CD-pipelinen?
• Finns det en incidenthanteringsprocess som fungerar i en molnmiljö?

Om svaret på flera av dessa frågor är nej, behöver ni antingen investera i kompetensutveckling, rekrytera, eller anlita en managerad tjänsteleverantör som komplement. Managerad DevOps

Bedömningens leverabler: Vad ni ska ha i handen efteråt

En genomförd AWS-beredskapsbedömning ska resultera i konkreta dokument – inte en PowerPoint med hög abstraktionsnivå. Förvänta er:

1. Nulägesanalys – dokumenterad inventering av infrastruktur, applikationer och beroenden

2. Gap-analys – identifierade brister i säkerhet, kompetens, processer och arkitektur

3. Migrationsplan – prioriterade arbetsbelastningar, vald strategi per applikation (6 R), tidsplan

4. Kostnadsmodell – TCO-jämförelse med specificerade antaganden

5. Riskregister – identifierade risker med sannolikhet, konsekvens och åtgärdsförslag

6. Rekommendationer – specifika åtgärder att genomföra innan migrering påbörjas

När ni bör ta hjälp – och vad Opsio bidrar med

Små organisationer med en handfull arbetsbelastningar kan ofta genomföra en grundläggande bedömning internt med hjälp av AWS egna verktyg. Men för organisationer med komplexa miljöer, regulatoriska krav eller begränsad molnerfarenhet tillför en extern partner tre saker som är svåra att replikera internt:

• Jämförelsedata – vi har genomfört bedömningar för dussintals organisationer och vet vad som är normalt och vad som är en varningsflagga
• Driftsperspektiv – vår 24/7 SOC/NOC ser dagligen vad som faktiskt går fel i produktionsmiljöer på AWS, inte bara vad som kan gå fel i teorin
• Regulatorisk erfarenhet – svensk och europeisk regelefterlevnad i molnet kräver specifik kompetens som generiska AWS-partners ofta saknar

Managerade molntjänster

Att investera tid och resurser i en grundlig beredskapsbedömning är inte ett hinder för snabb migrering – det är en förutsättning. Organisationer som gör hemläxan ordentligt migrerar snabbare, billigare och med färre incidenter. De som inte gör det betalar priset i form av omarbete, säkerhetsincidenter och förlorad verksamhetstid.

Vanliga frågor

Hur lång tid tar en AWS-beredskapsbedömning?

Tidsramen varierar med organisationens storlek och komplexitet. En grundläggande bedömning för ett medelstort företag tar typiskt 2–4 veckor. Mer komplexa miljöer med hundratals applikationer och strikta regulatoriska krav kan kräva 6–8 veckor. Med en erfaren partner som Opsio kan processen accelereras eftersom vi har etablerade ramverk och checklistor.

Vad kostar en AWS-beredskapsbedömning?

AWS erbjuder sin Migration Readiness Assessment (MRA) kostnadsfritt genom AWS-partners. En fördjupad bedömning med detaljerad kostnadsmodellering, säkerhetsanalys och migrationsplan kostar dock mer och beror på scope. Investera i en ordentlig bedömning – kostnaden är marginell jämfört med att upptäcka problem mitt i en pågående migrering.

Kan vi göra bedömningen själva eller behöver vi en partner?

Tekniskt sett kan ni genomföra en bedömning internt med hjälp av AWS Well-Architected Framework och AWS Migration Hub. I praktiken ser vi dock att organisationer utan molnerfarenhet missar kritiska punkter – särskilt kring säkerhet, licensoptimering och kostnadsmodellering. En partner med driftserfarenhet tillför perspektiv som interna team sällan har.

Hur skiljer sig en bedömning för svenska organisationer från internationella?

Svensk och europeisk lagstiftning ställer specifika krav. GDPR med Schrems II-implikationer påverkar var data får lagras, NIS2-direktivet ställer krav på incidentrapportering och riskhantering, och IMY:s tolkningar kan vara striktare än andra EU-länders. En bedömning måste ta hänsyn till att eu-north-1 (Stockholm) och Sweden Central inte automatiskt löser alla datalokaliseringsfrågor.

Vad händer efter bedömningen?

Bedömningen resulterar i en färdplan med prioriterade arbetsbelastningar, rekommenderad migrationsstrategi per applikation (6 R:en), kostnadsuppskattning och riskregister. Nästa steg är typiskt en pilotmigrering av en icke-kritisk arbetsbelastning för att validera antagandena innan full utrullning.