Beslutningsguide
AWS kommer op i næsten hver infrastruktur-samtale — enten fordi teamet allerede har en konto, fordi en enterprise-kunde kræver det, eller fordi nogen læste at "rigtige" produkter kører der. Alle tre grunde kan være gyldige. Ingen af dem betyder automatisk at I skal starte med ECS, EKS og et dusin managed services.
Vi kører produktion på AWS, Vercel og Cloudflare — afhængigt af produktet. Valget er ikke hvilken leverandør der vinder på Twitter. Det er hvilken kombination der giver jer det mindste ansvar for det I faktisk skal levere denne måned.
TL;DR
De vigtigste pointer
- AWS giver mening når compliance, netværk, data-placering eller eksisterende cloud-mandat dikterer valget.
- For mange Next.js-produkter er Vercel eller Cloudflare hurtigere i drift med mindre platform-arbejde.
- Hybrid er normalt: frontend på edge, database og tunge jobs på AWS — ikke alt i én kasse.
- Den skjulte omkostning er driftkompetence: IAM, VPC, patching og alarm-støj skal nogen eje.
- Portabilitet slår perfekt arkitektur: hold appen deploybar flere steder indtil constraints er reelle.
Hvad AWS reelt er god til
AWS er stærkest når I har brug for kontrol: specifik region, private netværk, KMS, dedikerede databaser, køer, batch-jobs, eller integration til eksisterende VPC og on-prem via Direct Connect. Det er infrastrukturen store organisationer allerede har kompetence til og kontrakter omkring.
Managed services som RDS Postgres, SQS, S3 og Lambda dækker mange SaaS-behov uden at I skal køre Kubernetes — hvis I accepterer AWS-specifikke APIs og lærer IAM ordentligt. Container-platforme (ECS, EKS) giver mening når I har mange services, eksisterende Docker-workflows, eller et team der allerede drifter K8s.
Det AWS ikke automatisk løser er produktivitet for frontend-teams. Next.js deploy, preview-miljøer og edge-caching kan I få hurtigere andre steder. At lægge hele produktet på AWS "fordi det skalerer" uden konkret skaleringskrav er ofte at købe en helt afdeling I ikke har ansat endnu.
AWS, Vercel eller Cloudflare — hvornår hvad
Venstre er situationen — højre er hvad vi typisk anbefaler som udgangspunkt.
Jeres situation
Enterprise-kunde eller kontrakt kræver AWS og specifik region
Typisk anbefaling
AWS — accepter kompleksiteten og dokumentér arkitekturen tidligt.
Jeres situation
Produktet er Next.js med auth, marketing og app i samme repo
Typisk anbefaling
Vercel eller Cloudflare til frontend; AWS til data og jobs hvis nødvendigt.
Jeres situation
I har allerede et DevOps-team der drifter AWS dagligt
Typisk anbefaling
AWS — udnyt eksisterende kompetence frem for at introducere ny platform.
Jeres situation
I er to udviklere der skal i produktion inden for få uger
Typisk anbefaling
Undgå EKS. Vælg managed platform (Vercel/Cloudflare + managed Postgres) først.
Jeres situation
Tunge baggrundsjob, fil-processing eller lange køer dominerer
Typisk anbefaling
AWS (Lambda, SQS, ECS) — edge er til request/response, ikke alt.
Jeres situation
I vil kunne skifte host uden rewrite
Typisk anbefaling
Hold app portable; brug AWS kun hvor constraint tvinger jer — ikke som default.
Den hybride model de fleste ender med
Det setup vi ser oftest i produktion er opdelt: offentlige sider og app-shell på Vercel eller Cloudflare for preview-deploys, CDN og lav friktion; database på RDS, Neon, Supabase eller tilsvarende; async arbejde på SQS plus workers når der er rapporter, imports eller webhooks der ikke må blokere HTTP.
Det kræver klare grænser: hvilke env-vars findes hvor, hvordan secrets roteres, og hvordan I logger på tværs. Det er mere integration end ren AWS — men mindre end at I selv bygger en PaaS oven på EC2.
Hvis I starter hybrid, dokumentér det som en bevidst beslutning med en trigger for "flyt mere til AWS" — fx data-residens-krav, trafikmønster eller et køb der allerede betaler for dedikeret infra. Uden trigger ender hybrid i permanent kompleksitet uden gevinst.
Før I standardiserer på AWS
Hvis I ikke kan sige ja til de fleste af de her punkter, er det for tidligt — eller forkert leverandør.
- Vi kan navngive en konkret constraint (compliance, region, eksisterende VPC) — ikke bare "skalerbarhed".
- Der er en person eller et team der ejer IAM, backup, alarmer og omkostningsoversigt månedligt.
- Vi har tegnet netværk og data-flow: hvad er public, hvad er private subnets, hvor ligger Postgres.
- Vi ved hvordan vi deployer — ikke kun hvordan vi klikker i konsollen én gang.
- Der findes en plan for staging der ligner produktion uden at koste det samme som produktion.
- Exit eller multi-cloud er overvejet: hvad er AWS-specifikt, og hvad er portable standarder?
Spørgsmål vi får igen og igen
Hvordan vælger I mellem AWS og Vercel?
Efter constraints: lange jobs, privat netværk, compliance eller tung backend trækker ofte AWS. Hurtig Next.js-leverance med lav driftsfriktion trækker Vercel. Vi sammenligner total cost of ownership — driftstid og risiko inkluderet — ikke hypen om rå compute.
Skal vi bruge Terraform fra dag ét?
Når mere end én person rører infra, ja — eller et tilsvarende IaC-værktøj I vil eje. Klik-ops i konsollen skalerer dårligt og er svært at gennemgå i due diligence. For en tidlig spike kan det vente; for produktion med kundedata bør det være på plads før go-live.
Kan vi køre Next.js på AWS?
Ja — via container, Amplify eller OpenNext-lignende mønstre. Spørgsmålet er om I får nok ud af det versus Vercel/Cloudflare til at retfærdiggøre ekstra drift. Vi vælger efter team og constraints, ikke efter hvad der er muligt.
Hvad med serverless vs. containere?
Lambda passer til event-drevet arbejde med korte kørsler. Containere passer til steady HTTP, længere processer og eksisterende Docker-images. Mange produkter bruger begge. Start med det der matcher jeres dominerende workload — bland ikke to compute-modeller uden grund.
Hvordan undgår vi vendor lock-in på AWS?
Brug portable lag hvor det er billigt: Postgres, S3-kompatible API'er hvor muligt, standard OAuth og undgå AWS-only features i applikationskernen indtil I har brug for dem. Lock-in er ofte acceptabelt når constraint'en er reel — bare tag det som en bevidst beslutning.
Usikker på cloud-valget?
Lad os matche stack til jeres constraints — ikke til et diagram.
Vi gennemgår produkt, team og compliance og anbefaler AWS, hybrid eller en simplere vej — også når svaret ikke er AWS.