VPC, subnets, NAT gateways, security groups, VPN och transit gateways – denna omfattande guide täcker allt du behöver veta för att designa säker och skalbar molnnätverk i AWS, Azure och GCP.
Virtual Private Cloud (VPC) är den logiska isoleringsgränsen i alla stora molnplattformar. Oavsett om du använder AWS, Azure eller GCP är VPC-designen grunden för din molnarkitektur – den påverkar säkerhet, prestanda, skalbarhet och kostnad. En väldesignad VPC kan växa med din verksamhet i åratal, medan en dåligt designad VPC kan bli en dyr och komplex ombyggnad.
Den här guiden ger dig en komplett genomgång av moderna molnnätverk – från grundläggande VPC-design och subnät till avancerade ämnen som transit gateways, multi-account networking och svenska sovereign cloud-överväganden. Jag har designat nätverk för allt från startups till myndigheter och delar här mina bästa lärdomar.
VPC-design – grundprinciper
En VPC är din privata virtuella nätverksmiljö i molnet. Du väljer IP-adressintervall (CIDR-block) för ditt VPC, skapar subnät inom intervallet, och konfigurerar routing, security groups och nätverksgateways. I AWS och GCP är VPC regional (spänner över alla AZ i regionen), medan Azure använder virtuella nätverk (VNet) som också är regionala.
IP-adressplanering är viktigast i VPC-designen. Välj ett CIDR-block som är tillräckligt stort för framtida tillväxt men inte överlappar med andra nätverk (on-prem, andra VPC:er). Rekommenderade intervall från RFC 1918: 10.0.0.0/8 (störst, 16+ miljoner adresser), 172.16.0.0/12, 192.168.0.0/16. För de flesta organisationer räcker 10.0.0.0/16 (65 536 adresser) per VPC.
Använd en konsekvent namngivning och taggning av VPC-resurser: `vpc-production-eu-west-1`, `subnet-public-web-a`, `subnet-private-app-b`. Tagga alla resurser med Environment, Owner, CostCenter och Compliance. Detta förenklar administration, kostnadsallokering och automatisering med Infrastructure as Code.
Subnets – organisera ditt nätverk
Subnät delar upp ditt VPC i logiska segment. Det vanligaste mönstret är att skapa publika och privata subnät i varje Availability Zone (minst 2 AZ för hög tillgänglighet). Publika subnät har direkt åtkomst till internet via en Internet Gateway – använd för lastbalanserare, API-endpoints, och bastion hosts. Privata subnät har ingen direkt internetåtkomst – använd för applikationsservrar, databaser, och caches.
Dela upp dina privata subnät efter funktion: app-subnet (applikationsservrar), data-subnet (databaser, caches), och reserved-subnet (för framtida expansion). Varje subnet har en egen route table och security group/network ACL. Använd /24-subnät (256 adresser) som standard – tillräckligt för de flesta tjänster, och enkelt att expandera vid behov.
Subnätsstorlek bör planeras med marginal: /24 för de flesta tjänster, /20 (4096 adresser) för tjänster med hög skalning (serverless, containers), och /27 (32 adresser) för enkla tjänster som aldrig skalar. AWS reserverar 5 IP-adresser per subnet för nätverksadministration – ta med det i planeringen.
Routing och NAT Gateways
Route tables styr trafikflödet i ditt VPC. Varje subnet har en route table som definierar vart trafik ska skickas baserat på destination. Standard (lokala) routes hanterar trafik inom VPC. För internetåtkomst från publika subnät: 0.0.0.0/0 -> Internet Gateway. För internetåtkomst från privata subnät: 0.0.0.0/0 -> NAT Gateway/VPC endpoint.
NAT Gateway (AWS) / NAT-instans låter privata instanser nå internet (för uppdateringar, hämtning av beroenden) men förhindrar internet från att initiera anslutningar till dem. NAT Gateway är en hanterad tjänst som skalar automatiskt – dyrare än en NAT-instans men mycket mer driftsäker. Använd en NAT Gateway per AZ för hög tillgänglighet (eller en för testmiljöer).
För Azure: Azure Firewall eller NAT Gateway. För GCP: Cloud NAT. Alla tre molnleverantörer har hanterade NAT-tjänster – använd dem i stället för att bygga egna NAT-instanser som kräver manuell administration och failover.
Security Groups och NACLs
Security Groups (AWS) / Network Security Groups (Azure) / Firewall Rules (GCP) är stateful brandväggsregler som styr trafik till och från resurser (EC2-instanser, ALB:er, RDS-databaser). Varje security group har regler för inbound och outbound trafik. Security groups är stateful – om du tillåter inbound trafik på port 80, tillåts outbound response-trafik automatiskt.
Network ACLs (NACLs) är stateless brandväggsregler som gäller på subnet-nivå. NACLs är ett extra säkerhetslager – använd dem för att blockera specifik trafik på subnet-nivå (t.ex. blockera alla inbound-ports utom 80/443 från internet). NACLs kräver explicita allow-regler för både in- och utgående trafik (eftersom de är stateless).
Bästa praxis: använd security groups som primärt säkerhetslager per resurs, och NACLs som ett extra lager på subnet-nivå för breda blockeringar (t.ex. blockera all trafik från specifika länder eller portar). Security groups är enklare att hantera och mer granulära – de flesta organisationer klarar sig med security groups och en NACL per subnet som default-deny.
VPN, Direct Connect och hybridnätverk
Site-to-Site VPN kopplar ditt on-prem-nätverk till ditt moln-VPC via internet med IPsec-kryptering. AWS VPN, Azure VPN Gateway och GCP Cloud VPN stöder alla IPsec VPN med dynamisk routing (BGP) eller statisk routing. VPN är enkelt att sätta upp, kostnadseffektivt och tillräckligt för de flesta hybridscenarier – men prestanda begränsas av internetanslutningen (vanligtvis 1–10 Gbps).
AWS Direct Connect, Azure ExpressRoute och GCP Dedicated Interconnect ger dedikerad nätverksanslutning mellan ditt on-prem och molnleverantören. Dessa tjänster ger högre prestanda (1–100 Gbps), lägre latens och högre tillförlitlighet än VPN över internet. De kräver fysisk korskoppling i en molnleverantörens colocation-facility och har längre ledtider (veckor till månader).
Använd VPN för utvecklingsmiljöer och mindre kritiska arbetsbelastningar. Använd Direct Connect/ExpressRoute för produktionskritiska system med höga prestandakrav, låg latens, eller compliance-krav som kräver att trafik inte går över internet. Många organisationer använder båda: Direct Connect som primär anslutning och VPN som backup.
Transit Gateways och VPC-peering
VPC-peering kopplar samman två VPC:er så att de kan kommunicera som om de vore i samma nätverk. Peering är 1:1 – du måste skapa peering-anslutningar mellan varje VPC-par. För många VPC:er (mer än 5–10) blir detta ohanterligt. AWS Transit Gateway, Azure Virtual WAN och GCP Network Connectivity Center löser detta med en hub-and-spoke-modell.
Transit Gateway är en hub som kopplar samman alla dina VPC:er (spokes). Du ansluter varje VPC till Transit Gateway (via VPC-attachment), och Transit Gateway hanterar routing mellan alla VPC:er. Transit Gateway stöder också VPN-anslutningar, Direct Connect, och multicast. Detta är standardarkitekturen för organisationer med fler än 3–5 VPC:er.
Hub-and-spoke-arkitektur med Transit Gateway: hub-VPC delar tjänster (DNS, Active Directory, central loggning, nätverkssäkerhet) med alla spoke-VPC:er. Spoke-VPC:er kör applikationer isolerade från varandra (ingen direct peering mellan spokes). Detta ger central administration, isolering mellan applikationer, och enkel expansion – lägg till en ny VPC genom att ansluta den till Transit Gateway.
Multi-account networking
Molnmogna organisationer använder flera konton för isolering: ett konto per miljö (dev, test, staging, production), per affärsenhet, eller per compliance-nivå. AWS Organizations, Azure Management Groups och GCP Resource Hierarchy organiserar konton i en hierarki. Nätverksanslutning mellan konton kräver att du använder Transit Gateway eller VPC-peering över konton.
Referensarkitektur för multi-account: ett centralt nätverkskonto (Network Hub) med en Transit Gateway, VPN-anslutning och Direct Connect. Alla andra konton ansluts till den centrala Transit Gateway via VPC-attachments. Detta ger central nätverksadministration, gemensamma internetutgångar (NAT Gateway, Firewall) och enhetliga säkerhetspolicyer över alla konton.
Använd AWS RAM (Resource Access Manager) för att dela Transit Gateway, VPC-subnets, och nätverksresurser över konton. Azure använder Resource Sharing för samma syfte. GCP använder Shared VPC (Host Project med Service Projects). Alla tre plattformar har stöd för att centralisera nätverksresurser – utnyttja detta för att minska komplexiteten.
Svenska sovereign cloud-överväganden
Svenska företag, särskilt inom offentlig sektor och kritisk infrastruktur, har specifika krav på dataresidens och suveränitet. AWS har en region i Stockholm (eu-north-1) sedan 2018 som uppfyller GDPR-krav för svenska organisationer. Data lagras och bearbetas inom EU/EES – viktigt för organisationer som inte får lagra data utanför Sverige.
Azure har regioner i Stavanger (Norge), Helsingfors (Finland) och Köpenhamn (Danmark) – ingen i Sverige. För organisationer som kräver svensk dataresidens kan detta vara en begränsning. GCP har en region i Stockholm (europe-north1) sedan 2017 med låg CO2-utsläpp (100% förnybar energi).
För myndigheter och säkerhetskänsliga organisationer: AWS GovCloud (USA), Azure Government (USA) och svenska molntjänster som Iteam, Safespring eller GleSYS. Dessa leverantörer erbjuder molntjänster med data som stannar inom Sveriges gränser och uppfyller särskilda säkerhetskrav. Överväg också att använda hybrid-arkitektur där känslig data lagras on-prem och mindre känslig data i molnet.
Nätverkssäkerhet och övervakning
Nätverkssäkerhet i molnet bygger på djupförsvar: VPC-isolering, security groups, NACLs, brandväggar (AWS Network Firewall, Azure Firewall, GCP Cloud Armor), och intrångsdetektering (IDS/IPS). Använd VPC Flow Logs (AWS), NSG Flow Logs (Azure), eller VPC Flow Logs (GCP) för att logga all nätverkstrafik och analysera mönster.
Använd AWS GuardDuty, Azure Defender eller GCP Security Command Center för hotdetektering i nätverkslagret. Dessa tjänster använder maskininlärning för att upptäcka avvikande trafikmönster – port scanning, data exfiltration, och anslutningar till kända skadliga IP-adresser.
Nätverkssäkerhet är ett delat ansvar mellan molnleverantören och dig som kund. Molnleverantören ansvarar för den fysiska nätverksinfrastrukturen. Du ansvarar för konfiguration av VPC, security groups, NACLs, VPN-anslutningar och kryptering av data i transit. Använd AWS Config, Azure Policy och GCP Organization Policies för att automatisk granska och upprätthålla nätverkssäkerhetsregler.
Sammanfattning: VPC best practices
- Planera IP-adressintervall noggrant – använd 10.0.0.0/8-intervall och undvik överlapp med on-prem och andra VPC:er.
- Använd minst 3 Availability Zones per region för hög tillgänglighet – skapa subnät per AZ och funktion.
- Använd Transit Gateway för nätverkshub mellan VPC:er – undvik komplexa peering-mesh:ar.
- Använd security groups som primärt säkerhetslager och NACLs som extra lager.
- Använd hanterade NAT-tjänster (NAT Gateway, Cloud NAT, Azure Firewall) i stället för egna NAT-instanser.
- Använd Direct Connect/ExpressRoute för produktionskritiska hybridanslutningar med VPN som backup.
- Använd VPC Flow Logs och nätverkssäkerhetsövervakning (GuardDuty, Defender) för insyn.
- Tagga alla nätverksresurser med Environment, Owner och CostCenter.
- Använd Infrastructure as Code (Terraform, CloudFormation) för att versionshantera nätverkskonfiguration.
- Designa för tillväxt – välj CIDR-block och subnät med marginal för framtida expansion.
VPC-design är en av de viktigaste tekniska besluten du fattar i molnet. En väldesignad VPC gör det enkelt och säkert att driva applikationer i flera år. En dåligt designad VPC kan kräva en smärtsam ombyggnad. Investera tid i planering – det lönar sig många gånger om.
Vill du ha hjälp med molnnätverk?
Jag hjälper företag att designa och implementera säkra molnnätverk. Läs mer om moln- och infratjänster eller boka ett samtal.
“Din VPC-design är som grunden till ett hus – felaktig från början blir den dyr att rätta till senare. Planera med framtida tillväxt i åtanke.”
- Simon Axelsson
Vanliga frågor
- Hur stort CIDR-block ska jag välja för mitt VPC?
- Min rekommendation är /16 (65 536 adresser) för produktions-VPC:er. Det ger gott om utrymme för subnät, framtida tjänster och expansion utan att överlappa med andra VPC:er eller on-prem-nätverk. /20 (4 096 adresser) är minimum för de flesta produktionsscenarier. /24 (256 adresser) räcker bara för enkla testmiljöer.
- Vad är skillnaden mellan Security Groups och NACLs?
- Security Groups är stateful brandväggsregler per resurs (instans, ALB, RDS). NACLs är stateless brandväggsregler per subnet. Stateful = om du tillåter inbound trafik, tillåts outbound response automatiskt. Stateless = du måste specificera både in- och utgående regler explicit. Security Groups är enklare och mer granulära och bör användas som primärt säkerhetslager.
- Behöver jag en NAT Gateway i varje AZ?
- För hög tillgänglighet, ja – en NAT Gateway per AZ. Om NAT Gateway i en AZ fallerar, har instanser i den AZ:en ingen internetåtkomst. För utvecklingsmiljöer kan en NAT Gateway räcka. Kostnad: ca 32 USD/månad per NAT Gateway + dataöverföring (0,045 USD/GB). Azure NAT Gateway kostar ca 3 USD/månad + data. GCP Cloud NAT kostar per hanterad gateway.
- När ska jag använda VPC-peering vs Transit Gateway?
- Använd VPC-peering för enkla 1:1-anslutningar mellan få VPC:er (max 3–5). Använd Transit Gateway när du har fler än 3–5 VPC:er, behöver centraliserad routing, eller har hybridanslutningar (VPN, Direct Connect). Transit Gateway kostar per ansluten VPC (ca 36 USD/månad per attachment) och per bearbetad GB data.
- Kan en svensk myndighet använda AWS eller Azure?
- Ja, med begränsningar. AWS Stockholm-region (eu-north-1) uppfyller GDPR och är lämplig för de flesta kommuner och regioner. För säkerhetskänslig verksamhet (MSB, Försvarsmakten) krävs särskilda leverantörer som GovStack, Safespring, GleSYS eller Iteam – dessa erbjuder svensk molninfrastruktur med data inom Sveriges gränser och uppfyller säkerhetsskyddslagen.
Om författaren
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar av Simon