Exit‑plan for AWS: hvad der kan flyttes, og hvad der er bygget ind

Hvad der kan flyttes fra AWS, afhænger af, hvad I har bygget på. Virtuelle maskiner og almindelige databaser har en kendt vej ud. Løsninger bygget på AWS’ egne tjenester, fx funktioner, køer og egne databaser, skal ofte laves om. En exit-plan for AWS sorterer derfor jeres miljø efter den forskel.

Mange leder efter en “aws exit strategy”, når ledelsen eller en kunde spørger. Vi læste AWS’ dokumentation og tillæg 6. november 2026, og begge kan ændres. Målestokken er den samme som for de øvrige platforme, og teksten rangerer eller anbefaler ingen. Planen forudsætter ingen beslutning om en aws migrering.

Hvad der er bundet

Forestil jer miljøet i tre lag. Det nederste er standardkomponenter: virtuelle maskiner, filer og databaser, der kører med almindelig software. Det mellemste er styrede udgaver af det samme, fx en database, som AWS driver for jer. Det øverste er tjenester, der kun findes hos udbyderen, og som jeres kode kalder direkte.

Jo højere oppe, desto større binding og som regel desto større hverdagsgevinst. Bindingen er et valg, som ofte var fornuftigt, og planen skal blot vise, hvad det koster af tid at gøre det om. Hertil kommer det, der binder hele miljøet: rettigheder i IAM, netværk, logning og overvågning.

Hvad der kan komme ud

AWS har et tillæg om Data Act (dataforordningen), som indgår i serviceaftalen, når forordningen gælder jeres brug. Af tillægget fremgår dette:

En anmodning om skift sendes til support mindst to måneder før den planlagte start.
Overgangsperioden er 30 kalenderdage. Er det teknisk uigennemførligt, får I besked inden for 14 arbejdsdage med en ny periode på højst syv måneder. Perioden kan forlænges én gang.
Skiftet kan omfatte alle tjenester eller en enkelt tjeneste.
Den konto, der er omfattet, skal være betalerkontoen, være i god stand og have et EU-land som kontoland.
Det er jer, der vælger metoden og udfører udtræk, eksport og import. AWS yder rimelig bistand gennem support og dokumentation.

Fristerne svarer til art. 25 i Data Act, se Data Act og skifteretten. Skiftegebyrer er reguleret i art. 29, og fra 12. januar 2027 må udbydere ikke pålægge dem. Tid hos egne medarbejdere, en ny leverandør og parallel drift skal stadig med i overslaget.

Teknisk kan de fleste instanser eksporteres som virtuelle maskiner til Citrix Xen, Hyper-V eller vSphere med VM Import/Export. Data i lagertjenester kan hentes med almindelige værktøjer. Overførsel ud over nettet ved flytning har sin egen ordning hos AWS, og den kræver en henvendelse til support. EU-kunder henvises til tillægget.

Hvad der mangler

Data, der er undtaget. Tillægget definerer undtagne data som AWS’ eget indhold og data om tjenesternes interne funktion, og henviser til AWS Artifact for en liste. Den liste er ikke læst her, og I bør læse den selv.

Opsætningen. AWS’ værktøj til at generere skabeloner af eksisterende ressourcer laver skabeloner i CloudFormation, som er AWS’ eget format. Skabelonen beskriver miljøet, men kan ikke køres hos en anden udbyder. Den kan bruges som dokumentation. Værktøjer, der kan bruges hos flere udbydere, er mere neutrale i sproget, men opsætningen skal stadig skrives til den nye udbyder. Se containere og flytbarhed.

Rettigheder og sikkerhed. IAM-politikker, nøgler i KMS og overvågning skal beskrives og laves igen. Er data krypteret med nøgler, der bor hos udbyderen, skal planen sige, hvordan de kan læses bagefter.

Lukning. Efter lukning af en konto er der en periode på 90 dage. I den kan I kun få adgang ved at genåbne kontoen, og derefter lukkes den permanent. Efter et fuldt skift skal kontoen enten lukkes eller data slettes, ifølge tillægget.

Hvad der skal testes

Testen er at genskabe en lille, men rigtig del et andet sted:

Vælg en tjeneste på det nederste lag og en på det øverste.
Eksportér data og den virtuelle maskine fra den første, og start den uden for AWS.
Beskriv for den anden, hvad der skal skrives om. Lad en udvikler give et skøn.
Mål overførselstiden, og regn op, se hvor lang tid tager overførslen.

Metoden står i gendannelse et andet sted. Tag gerne testen i en separat konto, så produktion ikke påvirkes.

Hvad planen skal rumme

Planen har en tabel over arbejdsbelastninger med lag, datamængde, afhængigheder af egne tjenester, vej ud og skøn over tid. Den rummer kontostruktur og ejerskab, datoerne fra tillægget med dato for læsning, hvem der skriver til support, og hvad der sker med backup og logfiler. Køber I gennem en partner, skal det også stå, se købt gennem en partner.

Hvad det kræver, og hvad det koster at lade være

En oversigt kræver en arkitekt eller erfaren driftsansvarlig i nogle dage, afhængig af miljøets størrelse. Skønnet over omskrivning kræver en udvikler. Skriv lave og høje skøn pr. arbejdsbelastning, og datér dem.

Uden oversigten ved I ikke, om vejen ud tager uger eller år, og det afgør, hvor længe I kan undvære systemet. Sæt jeres egne tal på et stop, og sammenhold dem med, hvad oversigten giver i dag. I får et billede af bindingen, når nye tjenester skal vælges, og I kan gøre et bevidst valg om, hvor bindingen er det værd.

Det skal I lade være med

At regne tiden ud fra datamængden alene · omskrivning fylder typisk mest.
At tage alle egne tjenester væk på forhånd · bindingen kan være det værd.
At se en CloudFormation-skabelon som vej ud · den er dokumentation.

Det skal planen kunne vise

☐ En tabel over arbejdsbelastninger efter de tre lag.
☐ Hvilken konto der er betalerkonto, og hvem der ejer den.
☐ Frister fra tillægget med dato for læsning.
☐ Listen over undtagne data, læst i AWS Artifact.
☐ En test af mindst én arbejdsbelastning uden for AWS.
☐ Et skøn over omskrivning med dato.

Kilder

Alle læst 6. november 2026. Kilderne er leverandørens egne og på engelsk.

Senest gennemgået: november 2026.

Næste skridt

Bed den, der driver miljøet, om at sortere de vigtigste løsninger efter de tre lag. Vælg derefter én til en prøve, og beslut, hvilke bindinger I accepterer.

Læs også: Exit-plan for Azure · Tilbage i egen drift

→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

Skal I have en plan B?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad der sætter arbejdet i gang. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Eller kontakt os på