AWS Landing Zone för svenska scale-ups: Multi-account från dag 1

Nästan varje svensk scale-up jag möter började sin AWS-resa i ett enda konto. Det fungerade när teamet var fem personer och det fanns en miljö. Sedan kom test, sedan kom en kund som krävde isolerad data, sedan kom en investerare som ville granska säkerheten - och plötsligt sitter allt i samma konto, med behörigheter ingen längre överblickar. En AWS Landing Zone löser det genom att lägga en styrd, flerkontosgrund från start. Den här guiden visar hur jag gör det med Control Tower som motor.

Varför multi-account redan från dag 1

AWS-konton är gratis och utgör den hårdaste säkerhets- och faktureringsgräns plattformen erbjuder. Ett misstag eller intrång i ett konto sprider sig inte automatiskt vidare. Du får ren kostnadsallokering, separata kvoter och möjlighet att sätta olika policy för olika delar. För en scale-up som vet att den ska växa är frågan inte om ni behöver flera konton, utan hur tidigt ni lägger grunden.

Jag möter ofta invändningen att flera konton låter krångligt att administrera. Det är precis tvärtom när det görs rätt. Det krångliga är ett enda konto där produktion, test och en halvfärdig labbmiljö samsas om samma resurser och samma kostnadsrad. Med flera konton blir varje gräns explicit i stället för implicit, och en investerares due diligence går från en plågsam genomgång av ett rörigt konto till en rundtur i en tydlig struktur.

Control Tower som motor

Control Tower är en hanterad tjänst som sätter upp och underhåller grundkomponenterna åt dig: ett loggarkivkonto, ett revisionskonto, en uppsättning skyddsräcken och Account Factory som skapar nya konton enligt en mall. Det stora värdet för en scale-up är tiden till en granskningsbar grund. I stället för att veckovis bygga landningszonens inälvor lägger ni tiden på era arbetsbelastningar, medan AWS ansvarar för att grunden hänger ihop när tjänsten utvecklas.

Det är värt att förstå avgränsningen. Control Tower äger livscykeln för grunden men hindrar dig inte från att lägga egen automation ovanpå. Ett vanligt och välfungerande upplägg är att låta Control Tower sköta kontolivscykel och baslinjeguardrails, och komplettera med egen Terraform för det som är specifikt för er - nätverk, delade tjänster, applikationsnära resurser.

Organisationsenheter efter funktion

Jag grupperar konton i organisationsenheter efter funktion, inte efter team. En struktur jag ofta landar i för ett växande bolag:

• En enhet för arbetsbelastningar, delad i produktion och icke-produktion.
• En enhet för delade tjänster som central nätverksinfrastruktur.
• En enhet för säkerhet med konton för loggning och revision.
• En enhet för sandlådor där utvecklare får experimentera inom snäva ramar.

Funktionsindelningen gör att policy kan sättas där den hör hemma och ärvas nedåt, i stället för att upprepas konto för konto allt eftersom ni växer.

Guardrails och Account Factory

Skyddsräcken, eller guardrails, är det som gör landningszonen till något annat än en ritning. De är obligatoriska eller starkt rekommenderade regler som gäller över organisationsenheter: begränsa till godkända regioner, neka att stänga av loggning, förhindra publika lagringsytor. När ett nytt konto skapas via Account Factory föds det redan med dessa räcken på plats. Det betyder att ett nytt team-konto är styrt från första sekunden, inte efter att någon kommit ihåg att konfigurera det. Den som vill ha hjälp att lägga grunden kan läsa mer om min molninfrastruktur.

Loggning och identitet

Två saker måste sitta rätt från start. All revisionsloggning ska skickas till det centrala loggarkivkontot och låsas där, så att en angripare som tar sig in i ett arbetsbelastningskonto inte kan radera spåren. Och identiteten ska federera mot er källa via IAM Identity Center, så att ingen behöver lokala användare per konto. Lokala användare är svåra att spåra, lätta att glömma och en vanlig väg in.

Med federation på plats loggar en utvecklare in en gång och når de konton hen har rätt till, med behörighet kopplad till grupper i stället för till enskilda personer. När någon byter team eller slutar ändras gruppmedlemskapet på ett ställe, och åtkomsten följer med. Det är den enkelheten som gör att en flerkontosmiljö skalar utan att behörighetshanteringen blir ett heltidsjobb.

Kostnad blir tydlig på köpet

En underskattad vinst med en genomtänkt kontostruktur är att kostnaden blir läsbar. När varje arbetsbelastning och miljö ligger i sitt eget konto blir kontogränsen en naturlig kostnadsgräns, helt utan extra taggning. Ni ser direkt vad produktion kostar jämfört med test, och vilka team som driver notan. Det gör det möjligt att fatta kostnadsbeslut tidigt, innan utgifterna hunnit växa till något ingen längre överblickar, och det lägger grunden för ett FinOps-arbete längre fram. För en scale-up som närmar sig en runda är det dessutom en konkret fördel att kunna visa kostnad per produkt och miljö i stället för en enda klumpsumma.

Vanliga felval

• För få konton, så att gränserna mellan miljöer blir suddiga när ni växer.
• Arbetsbelastningar i hanteringskontot, som ska hållas tomt och skyddat.
• Organisationsenheter efter team i stället för funktion, vilket sprider policyn.
• Loggning kvar i arbetsbelastningskontona där den kan raderas.

Det vanligaste av dessa är att börja för smått av rädsla för administration. Men en struktur med för få konton blir svårare att städa ju längre ni väntar, eftersom resurser och behörigheter hinner växa ihop. Att börja med en handfull tydliga konton kostar ingenting extra och sparar ett smärtsamt omtag senare.

Relaterat

• Sovereign cloud i Sverige: Bahnhof, Glesys och Elastx för NIS2-compliance
• Kubernetes på EKS vs GKE vs AKS: Driftkostnad och developer experience
• Serverless i 2026: Cloudflare Workers, Vercel Functions, AWS Lambda

Vill du ta det vidare?

Ska ni lägga en AWS-grund som håller när bolaget växer hjälper jag er från kontostruktur till guardrails. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.