Det, der er anderledes, er bredden. Et miljø i AWS kan være bygget af mange af AWS’ egne tjenester til databaser, køer, funktioner, identitet og overvågning, og hver af dem skal have en plads i den nye målarkitektur, før noget flytter.
Artiklen handler om målarkitekturen, altså hvordan miljøet skal se ud hos en europæisk udbyder. Planen for at kunne komme ud af AWS står på exit-plan.dk. Hvad der binder i aftalen, og hvornår forpligtelser udløber, står på vendor-lock-in.dk. Vi beskriver ikke AWS’ enkelte tjenester her. De ændrer sig hurtigt og skal læses hos AWS med dato.
Start med et kort over det, I bruger
Udgangspunktet er en fortegnelse over alle tjenester, miljøet bruger, pr. system. AWS’ egen faktura og jeres infrastrukturkode er gode kilder, fordi de viser, hvad der faktisk kører. Del tjenesterne i kategorier:
Beregning. Virtuelle servere, containere og funktioner, der kører kode uden en server, I selv passer.
Lager. Blokdiske til servere, objektlager og fildeling.
Databaser. Administrerede relationsdatabaser og andre databasetyper, som AWS driver for jer.
Integration. Køer, beskedtjenester og hændelsesstyring mellem systemerne.
Netværk. Virtuelle netværk, adgang udefra, belastningsfordeling, navneopslag og forbindelser til jeres kontor eller datacenter.
Identitet og nøgler. Brugere, roller og rettigheder i AWS, og nøgletjenesten til kryptering.
Drift. Overvågning, logning, alarmer og værktøjerne, der bygger miljøet ud fra kode.
Kortet viser, hvor dybt AWS er bygget ind. Et system, der kun bruger virtuelle servere og blokdiske, er let at placere andre steder. Et system bygget af funktioner, køer og administrerede databaser er et ombygningsprojekt.
Tre valg for hver kategori
For hver kategori, og nogle gange for hvert system, er der tre muligheder i målarkitekturen.
Den europæiske udbyders tilsvarende tjeneste. Europæiske udbydere tilbyder forskellige tjenester ud over virtuelle servere og lager. Bredden er forskellig fra udbyder til udbyder, og den skal sammenholdes tjeneste for tjeneste. Se Hvad mangler hos de europæiske?
Åben software, I selv driver. Mangler en tjeneste, kan den erstattes af åben software på virtuelle servere eller i en container-klynge. Det giver frihed og flytter driften over på jer.
Bliv i AWS. Nogle dele kan blive, fordi de er svære at erstatte, eller fordi de ikke behandler data, der begrunder flytningen. Så er resultatet en hybrid, og den skal planlægges. Se Hybrid som varig løsning.
Valget kan ikke tages uden at kende den europæiske udbyders katalog. Læs det hos udbyderen på den dag, I træffer valget.
Det, der kræver mest arbejde
Funktioner og hændelser. Kode, der kører som funktioner udløst af hændelser i andre AWS-tjenester, er tæt bundet til AWS. Den skal skrives om eller pakkes i containere med en anden måde at udløse den på.
Identitet. Roller og rettigheder i AWS flytter ikke med. Alle adgangsregler skal bygges op igen i den nye udbyders model, og den kan være anderledes. Det er en sikkerhedsopgave, som skal testes. Se Sikkerhedsmodellen følger ikke med.
Infrastrukturkode. Er miljøet bygget med et værktøj, der kun virker mod AWS, skal koden skrives om. Er det bygget med et værktøj, der understøtter flere udbydere, skal modulerne stadig skrives om, men værktøj og arbejdsgang kan blive. Se Terraform og OpenTofu.
Containere. Kører I containere i en Kubernetes-klynge, hjælper det, at Kubernetes er standardiseret. Formålet med CNCF’s program Certified Kubernetes er, at alle certificerede udgaver har de samme påkrævede programmeringsgrænseflader, så en installation kan flyttes fra den ene til den anden. Certificeringen dækker grænsefladerne og ikke drift, support eller de tillægstjenester, klyngen bruger. Se artiklen om administrerede klynger fra de store udbydere.
Målarkitekturen på papir
Resultatet er et dokument med en række pr. system og en kolonne pr. kategori. I hver celle står, hvad der bruges i dag, hvad det bliver, hvem der driver det, og hvor stort arbejdet er. Celler, hvor svaret er ukendt, markeres. Dokumentet er grundlaget for forstudiet, for tilbud fra udbydere og for beslutningen.
Hvad det kræver, og hvad det koster at lade være
Kortet over tjenesterne tager en til to uger for et mellemstort miljø, hvis infrastrukturen er beskrevet i kode. Er den bygget med klik i konsollen, tager det længere. Målarkitekturen tager yderligere nogle uger, fordi den europæiske udbyders katalog skal læses, og fordi valget mellem tilsvarende tjeneste og egen drift skal tages system for system.
Lader I være, bliver tilbuddene fra de europæiske udbydere svære at sammenligne, fordi de ikke ved, hvad de skal erstatte. Og flytningen begynder med de lette systemer, mens de svære dukker op midt i projektet, hvor tidsplan og budget allerede er sat.
Det skal I lade være med
- At kalde det en flytning, når det er en ombygning · systemer på AWS’ egne tjenester skal bygges om.
- At vælge udbyder, før kortet findes · ellers ved I ikke, hvad I sammenligner.
- At glemme identitet og rettigheder · de flytter ikke med og skal bygges op og testes.
Det skal valget kunne vise
- ☐ Fortegnelse over alle AWS-tjenester pr. system.
- ☐ For hver kategori: tilsvarende tjeneste, egen drift eller bliv.
- ☐ Den europæiske udbyders katalog læst med dato.
- ☐ De systemer, der kræver ombygning, og et overslag i tid.
Kilder
- CNCF, Certified Kubernetes Software Conformance, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk listen over tjenester fra fakturaen, og del den op pr. system. Så ser I, hvor dybt AWS er bygget ind.
Læs også: Applikationer bygget på udbyderens egne tjenester · Fra Azure til en europæisk udbyder
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
